Windows 1251 в utf 8: utf 8 — Utf-8 в windows-1251(android)

PostgreSQL : Документация: 10: 23.3. Поддержка кодировок : Компания Postgres Professional

23.3. Поддержка кодировок

Поддержка кодировок в PostgreSQL позволяет хранить текст в различных кодировках, включая однобайтовые кодировки, такие как входящие в семейство ISO 8859 и многобайтовые кодировки, такие как EUC (Extended Unix Code), UTF-8 и внутренний код Mule. Все поддерживаемые кодировки могут прозрачно использоваться клиентами, но некоторые не поддерживаются сервером (в качестве серверной кодировки). Кодировка по умолчанию выбирается при инициализации кластера базы данных PostgreSQL при помощи initdb. Она может быть переопределена при создании базы данных, что позволяет иметь несколько баз данных с разными кодировками.

Важным ограничением, однако, является то, что кодировка каждой базы данных должна быть совместима с параметрами локали базы данных LC_CTYPE (классификация символов) и LC_COLLATE (порядок сортировки строк). Для локали C или POSIX подойдёт любой набор символов, но для других локалей, предоставляемых библиотекой libc, есть только один набор символов, который будет работать правильно. (Однако в среде Windows кодировка UTF-8 может использоваться с любой локалью.) Если у вас включена поддержка ICU, локали, предоставляемые библиотекой ICU, можно использовать с большинством (но не всеми) кодировками на стороне сервера.

23.3.1. Поддерживаемые кодировки

Таблица 23.1 показывает кодировки, доступные для использования в PostgreSQL.

Таблица 23.1. Кодировки PostgreSQL

Имя	Описание	Язык	Поддержка на сервере	ICU?	Байтов на символ	Псевдонимы
BIG5	Big Five	Традиционные китайские иероглифы	Нет	Нет	1-2	WIN950, Windows950
EUC_CN	Extended UNIX Code-CN	Упрощённые китайские иероглифы	Да	Да	1-3
EUC_JP	Extended UNIX Code-JP	Японский	Да	Да	1-3
EUC_JIS_2004	Extended UNIX Code-JP, JIS X 0213	Японский	Да	Нет	1-3
EUC_KR	Extended UNIX Code-KR	Корейский	Да	Да	1-3
EUC_TW	Extended UNIX Code-TW	Традиционные китайские иероглифы, тайваньский	Да	Да	1-3
GB18030	Национальный стандарт	Китайский	Нет	Нет	1-4
GBK	Расширенный национальный стандарт	Упрощённые китайские иероглифы	Нет	Нет	1-2	WIN936, Windows936
ISO_8859_5	ISO 8859-5, ECMA 113	Латинский/Кириллица	Да	Да	1
ISO_8859_6	ISO 8859-6, ECMA 114	Латинский/Арабский	Да	Да	1
ISO_8859_7	ISO 8859-7, ECMA 118	Латинский/Греческий	Да	Да	1
ISO_8859_8	ISO 8859-8, ECMA 121	Латинский/Иврит	Да	Да	1
JOHAB	JOHAB	Корейский (Хангыль)	Нет	Нет	1-3
KOI8R	KOI8-R	Кириллица (Русский)	Да	Да	1	KOI8
KOI8U	KOI8-U	Кириллица (Украинский)	Да	Да	1
LATIN1	ISO 8859-1, ECMA 94	Западноевропейские	Да	Да	1	ISO88591
LATIN2	ISO 8859-2, ECMA 94	Центральноевропейские	Да	Да	1	ISO88592
LATIN3	ISO 8859-3, ECMA 94	Южноевропейские	Да	Да	1	ISO88593
LATIN4	ISO 8859-4, ECMA 94	Североевропейские	Да	Да	1	ISO88594
LATIN5	ISO 8859-9, ECMA 128	Турецкий	Да	Да	1	ISO88599
LATIN6	ISO 8859-10, ECMA 144	Скандинавские	Да	Да	1	ISO885910
LATIN7	ISO 8859-13	Балтийские	Да	Да	1	ISO885913
LATIN8	ISO 8859-14	Кельтские	Да	Да	1	ISO885914
LATIN9	ISO 8859-15	LATIN1 c европейскими языками и диалектами	Да	Да	1	ISO885915
LATIN10	ISO 8859-16, ASRO SR 14111	Румынский	Да	Нет	1	ISO885916
MULE_INTERNAL	Внутренний код Mule	Мультиязычный редактор Emacs	Да	Нет	1-4
SJIS	Shift JIS	Японский	Нет	Нет	1-2	Mskanji, ShiftJIS, WIN932, Windows932
SHIFT_JIS_2004	Shift JIS, JIS X 0213	Японский	Нет	Нет	1-2
SQL_ASCII	не указан (см. текст)	any	Да	Нет	1
UHC	Унифицированный код Хангыль	Корейский	Нет	Нет	1-2	WIN949, Windows949
UTF8	Unicode, 8-bit	все	Да	Да	1-4	Unicode
WIN866	Windows CP866	Кириллица	Да	Да	1	ALT
WIN874	Windows CP874	Тайский	Да	Нет	1
WIN1250	Windows CP1250	Центральноевропейские	Да	Да	1
WIN1251	Windows CP1251	Кириллица	Да	Да	1	WIN
WIN1252	Windows CP1252	Западноевропейские	Да	Да	1
WIN1253	Windows CP1253	Греческий	Да	Да	1
WIN1254	Windows CP1254	Турецкий	Да	Да	1
WIN1255	Windows CP1255	Иврит	Да	Да	1
WIN1256	Windows CP1256	Арабский	Да	Да	1
WIN1257	Windows CP1257	Балтийские	Да	Да	1
WIN1258	Windows CP1258	Вьетнамский	Да	Да	1	ABC, TCVN, TCVN5712, VSCII

Не все клиентские API поддерживают все перечисленные кодировки. Например, драйвер интерфейса JDBC PostgreSQL не поддерживает MULE_INTERNAL, LATIN6, LATIN8 и LATIN10.

Поведение кодировки SQL_ASCII существенно отличается от других. Когда набором символов сервера является SQL_ASCII, сервер интерпретирует значения от 0 до 127 байт согласно кодировке ASCII, тогда как значения от 128 до 255 воспринимаются как незначимые. Перекодировка не будет выполнена при выборе SQL_ASCII. Таким образом, этот вариант является не столько объявлением того, что используется определённая кодировка, сколько объявлением того, что кодировка игнорируется. В большинстве случаев, если вы работаете с любыми данными, отличными от ASCII, не стоит использовать SQL_ASCII, так как PostgreSQL не сможет преобразовать или проверить символы, отличные от ASCII.

23.3.2. Настройка кодировки

initdb определяет кодировку по умолчанию для кластера PostgreSQL. Например,

initdb -E EUC_JP

настраивает кодировку по умолчанию на EUC_JP (Расширенная система кодирования для японского языка). Можно использовать --encoding вместо -E в случае предпочтения более длинных имён параметров. Если параметр -E или --encoding не задан, initdb пытается определить подходящую кодировку в зависимости от указанной или заданной по умолчанию локали.

При создании базы данных можно указать кодировку, отличную от заданной по умолчанию, если эта кодировка совместима с выбранной локалью:

createdb -E EUC_KR -T template0 --lc-collate=ko_KR.euckr --lc-ctype=ko_KR.euckr korean

Это создаст базу данных с именем korean, которая использует кодировку EUC_KR и локаль ko_KR. Также, получить желаемый результат можно с помощью данной SQL-команды:

CREATE DATABASE korean WITH ENCODING 'EUC_KR' LC_COLLATE='ko_KR.euckr' LC_CTYPE='ko_KR. euckr' TEMPLATE=template0;

Заметьте, что приведённые выше команды задают копирование базы данных template0. При копировании любой другой базы данных, параметры локали и кодировку исходной базы изменить нельзя, так как это может привести к искажению данных. Более подробное описание приведено в Разделе 22.3.

Кодировка базы данных хранится в системном каталоге pg_database. Её можно увидеть при помощи параметра psql -l или команды \l.

$ psql -l
                                         List of databases
   Name    |  Owner   | Encoding  |  Collation  |    Ctype    |          Access Privileges          
-----------+----------+-----------+-------------+-------------+-------------------------------------
 clocaledb | hlinnaka | SQL_ASCII | C           | C           | 
 englishdb | hlinnaka | UTF8      | en_GB.UTF8  | en_GB.UTF8  | 
 japanese  | hlinnaka | UTF8      | ja_JP.UTF8  | ja_JP. UTF8  | 
 korean    | hlinnaka | EUC_KR    | ko_KR.euckr | ko_KR.euckr | 
 postgres  | hlinnaka | UTF8      | fi_FI.UTF8  | fi_FI.UTF8  | 
 template0 | hlinnaka | UTF8      | fi_FI.UTF8  | fi_FI.UTF8  | {=c/hlinnaka,hlinnaka=CTc/hlinnaka}
 template1 | hlinnaka | UTF8      | fi_FI.UTF8  | fi_FI.UTF8  | {=c/hlinnaka,hlinnaka=CTc/hlinnaka}
(7 rows)

Важно

На большинстве современных операционных систем PostgreSQL может определить, какая кодировка подразумевается параметром LC_CTYPE, что обеспечит использование только соответствующей кодировки базы данных. На более старых системах необходимо самостоятельно следить за тем, чтобы использовалась кодировка, соответствующая выбранной языковой среде. Ошибка в этой области, скорее всего, приведёт к странному поведению зависимых от локали операций, таких как сортировка.

PostgreSQL позволит суперпользователям создавать базы данных с кодировкой SQL_ASCII, даже когда значение LC_CTYPE не установлено в C или POSIX. Как было сказано выше, SQL_ASCII не гарантирует, что данные, хранящиеся в базе, имеют определённую кодировку, и таким образом, этот выбор чреват сбоями, связанными с локалью. Использование данной комбинации устарело и, возможно, будет полностью запрещено.

23.3.3. Автоматическая перекодировка между сервером и клиентом

PostgreSQL поддерживает автоматическую перекодировку между сервером и клиентом для определённых комбинаций кодировок. Информация, касающаяся перекодировки, хранится в системном каталоге pg_conversion. PostgreSQL включает в себя некоторые предопределённые кодировки, как показано в Таблице 23.2. Есть возможность создать новую перекодировку при помощи SQL-команды CREATE CONVERSION.

Таблица 23.2. Клиент-серверные перекодировки наборов символов

Чтобы включить автоматическую перекодировку символов, необходимо сообщить PostgreSQL кодировку, которую вы хотели бы использовать на стороне клиента. Это можно выполнить несколькими способами:

• Использование команды \encoding в psql. \encoding позволяет оперативно изменять клиентскую кодировку. Например, чтобы изменить кодировку на SJIS, введите:

  \encoding SJIS

• libpq (Раздел 33.10) имеет функции, для управления клиентской кодировкой.

• Использование SET client_encoding TO. Клиентская кодировка устанавливается следующей SQL-командой:

  SET CLIENT_ENCODING TO 'value';

  Также, для этой цели можно использовать стандартный синтаксис SQL SET NAMES:

  SET NAMES 'value';

  Получить текущую клиентскую кодировку:

  SHOW client_encoding;

  Вернуть кодировку по умолчанию:

  RESET client_encoding;

• Использование PGCLIENTENCODING. Если установлена переменная окружения PGCLIENTENCODING, то эта клиентская кодировка выбирается автоматически при подключении к серверу. (В дальнейшем это может быть переопределено при помощи любого из методов, указанных выше.)

• Использование переменной конфигурации client_encoding. Если задана переменная client_encoding, указанная клиентская кодировка выбирается автоматически при подключении к серверу. (В дальнейшем это может быть переопределено при помощи любого из методов, указанных выше.)

Если перекодировка определённого символа невозможна (предположим, выбраны EUC_JP для сервера и LATIN1 для клиента, и передаются некоторые японские иероглифы, не представленные в LATIN1), возникает ошибка.

Если клиентская кодировка определена как SQL_ASCII, перекодировка отключается вне зависимости от кодировки сервера. Что же касается сервера, не стоит использовать SQL_ASCII, если только вы не работаете с данными, которые полностью соответствуют ASCII.

23.3.4. Дополнительные источники информации

Рекомендуемые источники для начала изучения различных видов систем кодирования.

Обработка информации на китайском, японском, корейском & вьетнамском языках.

Содержит подробные объяснения по EUC_JP, EUC_CN, EUC_KR, EUC_TW.

http://www.unicode.org/

Сайт Unicode Consortium.

RFC 3629

UTF-8 (формат преобразования 8-битного UCS/Unicode) определён здесь.

сведения о кодировке символов — PowerShell

• 
  10/21/2020
• Чтение занимает 5 мин

В этой статье

Краткое описание

Описывает, как PowerShell использует кодировку символов для ввода и вывода строковых данных.

Подробное описание

Юникод — это мировой стандарт кодировки символов. Система использует Юникод исключительно для обработки символов и строк. Подробное описание всех аспектов Юникода см. в стандарте Юникода.

Windows поддерживает Юникод и традиционные наборы символов. Традиционные кодировки, например кодовые страницы Windows, используют 8-разрядные значения или сочетания 8-разрядных значений для представления символов, используемых в определенном языке или географических регионах.

По умолчанию PowerShell использует набор символов Юникода. Однако несколько командлетов имеют параметр кодирования , который может указывать кодировку для другой кодировки. Этот параметр позволяет выбрать конкретную кодировку символов, необходимую для взаимодействия с другими системами и приложениями.

Следующие командлеты имеют параметр Encoding :

• Microsoft.PowerShell.Management
  • Add-Content
  • Get-Content
  • Set-Content
• Microsoft.PowerShell.Utility
  • Export-Clixml
  • Export-Csv
  • Export-PSSession
  • Format-Hex
  • Import-Csv
  • Out-File
  • Select-String
  • Send-MailMessage

Пометка порядка байтов

Символ-пометка (BOM) — это сигнатура в Юникоде в первых нескольких байтах файла или текстового потока, указывающих, какая кодировка Юникода используется для данных. Дополнительные сведения см. в документации по метке порядка байтов .

В Windows PowerShell любая Кодировка Юникода, за исключением UTF7 , всегда создает спецификацию. По умолчанию PowerShell Core имеет значение utf8NoBOM для всех текстовых выходных данных.

Для обеспечения оптимальной совместимости Избегайте использования спецификаций в файлах UTF-8. Платформы UNIX и служебные программы Unix-Heritage, которые также используются на платформах Windows, не поддерживают спецификации.

Аналогичным образом UTF7 следует избегать кодирования. UTF-7 не является стандартной кодировкой Юникода и записывается без спецификации во всех версиях PowerShell.

Создание сценариев PowerShell на платформе, похожем на UNIX, или использовании кросс-платформенного редактора в Windows, например Visual Studio Code, приводит к созданию файла, закодированного с помощью UTF8NoBOM . Эти файлы прекрасно работают в PowerShell Core, но могут нарушить работу Windows PowerShell, если файл содержит символы, отличные от ASCII.

Если в скриптах необходимо использовать символы, отличные от ASCII, сохраните их как UTF-8 с помощью BOM. Без спецификации Windows PowerShell ошибочно интерпретирует скрипт как закодированный в устаревшей кодовой странице ANSI. И наоборот, файлы, имеющие СПЕЦИФИКАЦИю UTF-8, могут быть проблематичными для платформ, подобных Unix. Многие средства UNIX, такие как cat ,, sed awk и некоторые редакторы, например, gedit не узнают, как обрабатывать спецификацию.

Кодировка символов в Windows PowerShell

В PowerShell 5,1 параметр Encoding поддерживает следующие значения:

• Ascii Использует кодировку ASCII (7-разрядных).
• BigEndianUnicode Использует UTF-16 с обратным порядком байтов.
• BigEndianUTF32 Использует UTF-32 с обратным порядком байтов.
• Byte Кодирует набор символов в последовательность байтов.
• Default Использует кодировку, соответствующую активной кодовой странице системы (обычно ANSI).
• Oem Использует кодировку, соответствующую текущей кодовой странице OEM системы.
• String аналогичен Unicode.
• Unicode Использует UTF-16 с прямым порядком байтов.
• Unknown аналогичен Unicode.
• UTF32 Использует UTF-32 с прямым порядком байтов.
• UTF7 Использует UTF-7.
• UTF8 Использует UTF-8 (с BOM).

В общем случае Windows PowerShell по умолчанию использует кодировку Юникод UTF-16LE . Однако кодировка по умолчанию, используемая командлетами в Windows PowerShell, не согласуется.

Примечание

При использовании любой кодировки Юникода, за исключением UTF7 , всегда создает спецификацию.

Для командлетов, записывающих выходные данные в файлы:

• Out-File и операторы перенаправления > и >> создают UTF-16LE, который, в свою очередь, отличается от Set-Content и Add-Content .

• New-ModuleManifest а Export-CliXml также создавать файлы UTF-16LE.

• Если целевой файл пуст или не существует, Set-Content и Add-Content Используйте Default кодировку. Default — это кодировка, определяемая кодовой страницей устаревшей версии ANSI на языке активного системы.

• Export-Csv создает Ascii файлы, но использует другую кодировку при использовании параметра append (см. ниже).

• Export-PSSession по умолчанию создает файлы UTF-8 с BOM.

• New-Item -Type File -Value создает файл UTF-8 с кодировкой BOM.

• Send-MailMessage по Default умолчанию использует кодировку.

• Start-Transcript создает Utf8 файлы с помощью спецификации. При использовании параметра append кодировка может отличаться (см. ниже).

Для команд, которые добавляют к существующему файлу:

• Out-File -Append и >> оператор перенаправления не пытается сопоставить кодировку содержимого существующего целевого файла. Вместо этого они используют кодировку по умолчанию, если не используется параметр Encoding . При добавлении содержимого необходимо использовать исходную кодировку файлов.

• При отсутствии явного параметра кодировки Add-Content обнаруживает существующую кодировку и автоматически применяет ее к новому содержимому. Если имеющееся содержимое не имеет BOM, Default используется кодировка ANSI. Поведение аналогично Add-Content в PowerShell Core (V6 и более поздних версиях), кроме кодировки по умолчанию — Utf8 .

• Export-Csv -Append соответствует существующей кодировке, если целевой файл содержит СПЕЦИФИКАЦИю. В отсутствие спецификации используется Utf8 Кодировка.

• Start-Transcript -Append соответствует существующей кодировке файлов, включающих СПЕЦИФИКАЦИю. При отсутствии спецификации по умолчанию используется Ascii Кодировка. Такая кодировка может привести к утере данных или повреждению символов, если данные в записи содержат многобайтовые символы.

Для командлетов, считывающих строковые данные в отсутствие спецификации:

• Get-Content и Import-PowerShellDataFile использует Default кодировку ANSI. ANSI также используется механизмом PowerShell при чтении исходного кода из файлов.

• Import-Csv, Import-CliXml и Select-String предполагают Utf8 отсутствие спецификации.

Кодировка символов в PowerShell Core

В PowerShell Core (V6 и более поздних версий) параметр Encoding поддерживает следующие значения:

• ascii: Использует кодировку для набора символов ASCII (7-разрядных).
• bigendianunicode: Кодируется в формате UTF-16 с обратным порядком байтов.
• oem: Использует кодировку по умолчанию для программ MS-DOS и консолей.
• unicode: Кодируется в формате UTF-16 с прямым порядком байтов.
• utf7: Кодируется в формате UTF-7.
• utf8: Кодирует в формате UTF-8 (без спецификации).
• utf8BOM: Кодирует в формате UTF-8 с меткой порядка байтов (BOM)
• utf8NoBOM: Кодирует в формате UTF-8 без метки порядка байтов (BOM)
• utf32: Кодируется в формате UTF-32.

По умолчанию PowerShell Core имеет значение utf8NoBOM для всех выходных данных.

Начиная с PowerShell 6,2, параметр кодировки также разрешает числовые идентификаторы зарегистрированных кодовых страниц (например -Encoding 1251 ,) или строковых имен зарегистрированных кодовых страниц (например -Encoding "windows-1251" ,). Дополнительные сведения см. в документации .NET по кодированию. codepage.

Изменение кодировки по умолчанию

В PowerShell есть две переменные по умолчанию, которые можно использовать для изменения поведения кодировки по умолчанию.

• $PSDefaultParameterValues
• $OutputEncoding

Дополнительные сведения см. в разделе about_Preference_Variables.

Начиная с PowerShell 5,1, операторы перенаправления ( > и >> ) вызывают Out-File командлет. Таким образом, можно задать кодировку по умолчанию для них с помощью $PSDefaultParameterValues переменной предпочтений, как показано в следующем примере:

$PSDefaultParameterValues['Out-File:Encoding'] = 'utf8'

Используйте следующую инструкцию, чтобы изменить кодировку по умолчанию для всех командлетов, имеющих параметр Encoding .

$PSDefaultParameterValues['*:Encoding'] = 'utf8'

Важно!

При размещении этой команды в профиле PowerShell предпочтение влияет на глобальные параметры сеанса, влияющие на все команды и скрипты, которые явно не задают кодировку.

Аналогичным образом следует включить такие команды в скрипты или модули, которые должны вести себя одинаково. Использование этих команд гарантирует, что командлеты ведут себя одинаково даже при запуске другого пользователя, на другом компьютере или в другой версии PowerShell.

Автоматическая переменная $OutputEncoding влияет на кодирование, используемое PowerShell для взаимодействия с внешними программами. Он не влияет на кодировку, которую операторы перенаправления вывода и командлеты PowerShell используют для сохранения в файлах.

См. также

Перекодировка документа CP1251 в UTF-8 в Linux

13 Nov 2016 | Автор: dd |

Перевозил тут пачку сайтов с LAMP на LNAMP, где фронтэндом выступает NGINX. И все бы ничего, если бы не пачка статических сателлитов в кодировке Windows-1251 (cp1251).

Как тут прикололся девака – при анализе сайта, надо сначала чекать кодировку и в случае обнаружения кодировки сайта cp1251 – проверку возраста можно не осуществлять. Но, тем не менее, в инетах до сих пор встречаются такие мастадонты, которые клепают сайты в кодировке CP1251.

Под апачем, при добавлении сайта в ISP Panel это даже не заметишь, а вот при попытке добавить этот же сайт в Vesta CP, получаешь гемор на задницу с крикозябрами. Поэтому надо редактировать конфиг Nginx, предварительно прикрутив туда виндовую кодировку. Но, насколько я помню, у меня этот танец с бубнами не задался и в тот раз, я просто повесил саты на LAMP.

Так что оставалось либо плясать с бубнами вокруг прикручивания виндовой кодировки к NGINX, либо перекодивать файлы в родную для нжинкса UTF-8. Сделать это можно средствами текстового редактора Notepad++ путем перевода кодировки документа и последующего сохранения; либо же в самом линухе.  Как я выше заметил, саты статические, то есть на файлах, без использования базы данных. Поэтому перекодировать надо было именно файлы. С базой данных все происходило бы несколько иначе.

Перекодировка файла из CP1251 в UTF-8 производится в консоли через команду iconv
# iconv -f cp1251 -t utf8 FILE-CP1251 -o FILE-UTF8
либо же можно переписать файл в самого себя
# iconv -f cp1251 -t utf8 file. txt -o file.txt

Но поскольку мне надо было перекодировать большое число файлов php, содержащихся в разных папках, то мне пришлось составить  небольшое предложение:
# find /path-to-files/ -type f -name \*php -exec iconv -f cp1251 -t utf-8 '{}' -o '{}' \;

Конвертит все в лет.

Для конвертации кодировок есть еще утилита enconv, входящая в состав пакета enca – вот он как раз конвертит сам в себя по умолчанию, перезаписывая файл выходной кодировкой:
# enconv -c file.txt

но, к сожалению, я его не смог подружить с русским языком, т.к даже при указании языка через ключик -L russian скрипт матерился на ошибки. Но с другой стороны, все нормально решилось и через iconv

VN:F [1.9.21_1169]

Rating: 4.9/10 (15 votes cast)

VN:F [1.9.21_1169]

Rating: +1 (from 3 votes)

Смена кодировки сайта из CP1251 на UTF-8, 4.9 out of 10 based on 15 ratings

Теги: centos, сайты

Как настроить кодировку сайта самостоятельно

Как кодировка влияет на отображение сайта, чем отличается UTF-8 от Windows 1251 и где указать кодировку.

Разбираем, на что влияет кодировка, нужно ли указывать ее самостоятельно, и почему могут появиться так называемые «кракозябры» на сайте.

Зачем нужна кодировка

Кодировка (Charset) — способ отображения кода на экране, соответствие набора символов набору числовых значений. О ней сообщает строка Content-Type и сервер в header запросе.

Несовпадение кодировок сервера и страницы будет причиной появления ошибок. Если они не совпадают, информация декодируется некорректно, так что контент на сайте будет отображаться в виде набора бессвязных букв, иероглифов и символов, в народе называемых «кракозябрами». Такой текст прочитать невозможно, так что пользователь просто уйдет с сайта и найдет другой ресурс. Или останется, если ему не очень важно содержание:

Студентка списывала реферат с формулами, а на сайте слетела кодировка. Реальная история

Google рекомендует всегда указывать сведения о кодировке, чтобы текст точно корректно отображался в браузере пользователя.

Кодировка влияет на SEO?

Разберемся, как кодировка на сайте влияет на индексацию в Яндекс и Google.

Яндекс четко заявляет:

«Тип используемой на сайте кодировки не влияет на индексирование сайта. Если ваш сервер не передает в заголовке кодировку, робот Яндекса также определит ее самостоятельно».

Позиция Google такая же. Поисковики не рассматривают Charset как фактор ранжирования или сигнал для индексирования, тем не менее, она косвенно влияет на трафик и позиции.

Если кодировка сервера не совпадает с той, что указана на сайте, пользователи увидят нечитабельные символы вместо контента. На таком сайте сложно что-либо понять, так что скорее всего пользователи сбегут, а на сайте будут расти отказы.

Пример страницы со слетевшей кодировкой

Поэтому она важна для SEO, хоть и влияет на него косвенно через поведенческие. Пользователи должны видеть читабельный текст на человеческом языке, чтобы работать с сайтом.

Виды кодировок

Существует довольно много видов, но сейчас распространены два:

UTF-8

Unicode Transformation Format — универсальный стандарт кодирования, который работает с символами почти всех языков мира. Символы могут занимать от 1 до 4 байт, такое кодирование позволяет создавать мультиязычные сайты.

Есть несколько вариантов — UTF-8, 16, 32, но чаще используют восьмибитное.

Windows-1251

Этот вид занимает второе место по популярности после UTF-8. Windows-1251 — кодирование для кириллицы, созданное на базе кодировок, использовавшихся в русификаторах операционной системы Windows. В ней есть все символы, которые используются в русской типографике, кроме значка ударения. Символы занимают 1 байт.

Выбор кодировки остается на усмотрение веб-мастера, но UTF-8 используют намного чаще — ее поддерживают все популярные браузеры и распознают поисковики, а еще ее удобнее использовать для сайтов на разных языках.

Определить кодировку страницы своего или чужого сайта можно через исходный код страницы. Откройте страницу сайта, выберите «Просмотр кода страницы» (сочетание горячих клавиш Ctrl+U» в Google Chrome) и найдите упоминание «charset» внутри тега head.

На странице сайта используется кодировка UTF-8:

Указание кодировки в коде страницы

Узнать вид кодирования можно с помощью «Анализа сайта». Сервис проверяет в том числе и техническую сторону ресурса: анализирует серверную информацию, определяет кодировку, проверяет редиректы и другие пункты.

Фрагмент анализа серверной информации сайта

С помощью этого же сервиса можно проверить корректность указанного кодирования. Аудит внутренних страниц «Анализа сайта» проверяет кодировку сервера и сравнивает ее с той, которая указана на внутренней странице. Найденные ошибки Анализ покажет в результатах проверки, и вы сразу узнаете, где нужно исправить.

Отчет о технических данных
Кодировка сервера и страницы

Проверить кодировку еще можно через сервис Validator.w3, о котором писали в статье о проверке валидации кода. Нужная надпись находится внизу страницы.

Кодировка сайта в валидаторе

Если валидатор не обнаружит Charset, он покажет ошибку:

Ошибка указания кодировки

Но валидатор работает не точно: он проверяет только синтаксис разметки, поэтому может не показать ошибку, даже если кодирование указано неправильно.

Если кодировка не отображается

Если вы зашли на чужой сайт с абракадаброй, а вам все равно очень интересно почитать контент, то в Справке Google объясняют, как исправить кодирование текста через браузер.

О проблеме возникновения абракадабры на вашем сайте будут сигнализировать метрики поведения: вырастут отказы, уменьшится глубина просмотров. Но скорее всего вы и раньше заметите, что что-то пошло не так.

Главное правило — для всех файлов, скриптов, баз данных сайта и сервера должна быть указана одна кодировка. Ошибка может возникнуть, если вы случайно указали на сайте разные виды кодировки.

Яндекс советует использовать одинаковую кодировку для страниц и кириллических адресов структуры. К примеру, если робот встретит ссылку href=»/корзина» на странице с кодировкой UTF-8, он сохранит ее в этом же UTF-8, так что страница должна быть доступна по адресу «/%D0%BA%D0%BE%D1%80%D0%B7%D0%B8%D0%BD%D0%B0».

Где указать кодировку сайта

Если проблема возникла на вашем сайте, способ исправления зависит от вида сайта. Для одностраничника достаточно указать кодировку в мета-теге страницы, а для большого сайта есть разные варианты:

• кодировка в мета-теге;
• кодировка в .htaccess;
• кодировка документа;
• кодировка в базе данных MySQL.

Кодировка в мета-теге

Добавьте указание кодировки в head файла шаблона сайта.

При создании документа HTML укажите тег meta в начале в блоке head. Некоторые браузеры могут не распознать указание кодировки, если оно будет ниже.

Мета-тег может выглядеть так:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

или так:

<meta charset="utf-8">

В HTML5 они эквивалентны.

Тег кодировки в HTML

В темах WordPress обычно тег «charset» с кодировкой указан по умолчанию, но лучше проверить.

Кодировка в файле httpd.conf

Инструкции для сервера находятся в файле httpd.conf, обычно его можно найти на пути «/usr/local/apache/conf/».

Если вам нужно сменить кодировку Windows-1251 на UTF-8, замените строчку «AddDefaultCharset windows-1251» на «AddDefaultCharset utf-8».

Осторожнее: если вы измените в файле кодировку по умолчанию, то она изменится для всех проектов на этом сервере.

Убедитесь, что сервер не передает HTTP-заголовки с конфликтующими кодировками.

Кодировка в .htaccess

Добавьте кодировку в файл .htaccess:

1. Откройте панель управления хостингом.
2. Перейдите в корневую папку сайта.
3. В файле .htaccess добавьте в самое начало код:
   1. для указания кодировки UTF-8 — AddDefaultCharset UTF-8;
   2. для указания кодировки Windows-1251 — AddDefaultCharset WINDOWS-1251.
4. Перейдите на сайт и очистите кэш браузера.

Кодировка документа

Готовые файлы HTML важно сохранять в нужной кодировке сайта. Узнать текущую кодировку файла можно через Notepad++: откройте файл и зайдите в «Encoding». Меняется она там же: чтобы сменить кодировку на UTF-8, выберите «Convert to UTF-8 without BOOM». Нужно выбрать «без BOOM», чтобы не было пустых символов.

Кодировка Базы данных

Выбирайте нужную кодировку сразу при создании базы данных. Распространенный вариант — «UTF-8 general ci».

Где менять кодировку у БД:

1. Кликните по названию нужной базы в утилите управления БД phpMyAdmin и откройте ее.
2. Кликните на раздел «Операции»:
3. Введите нужную кодировку для базы данных MySQL:
4. Перейдите на сайт и очистите кэш.

С новой БД проще, но если вы меняете кодировку у существующей базы, то у созданных таблиц и колонок заданы свои кодировки, которые тоже нужно поменять.

Для всех таблиц, колонок, файлов, сервера и вообще всего, что связано с сайтом, должна быть одна кодировка.

Проблема может не решиться, если все дело в кодировке подключения к базе данных. Что делать:

1. Подключитесь к серверу с правами mysql root пользователя:
   mysql -u root -p
2. Выберите нужную базу:
   USE имя_базы;
3. Выполните запрос:
   SET NAMES ‘utf8’;

Если вы хотите указать Windows-1251, то пишите не «utf-8», а «cp1251» — обозначение для кодировки Windows-1251 у MySQL.

Чтобы установить UTF-8 по умолчанию, откройте на сервере my.cnf и добавьте следующее:

В области [client]:

default-character-set=utf8

В области [mysql]:

default-character-set=utf8

В области [mysqld]:

collation-server = utf8_unicode_ci
init-connect='SET NAMES utf8'

character-set-server = utf8

Вы когда-нибудь сталкивались с проблемами кодировки на сайте?

Массовое конвертирование файлов из WINDOWS-1251 в UTF-8

Понадобилось поработать с одним сайтиком, который весь сделан в кодировке cp-1251, а у меня Linux. В Линуксе всё в кодировке UTF-8. Да и перенести этот сайтик надо на сервер, где всё под UTF-8 заточено. Пришлось делать скриптик в bash, что бы конвертация была автоматическая и массовая. Что бы скрипт все файлы разом в текущей папке и во всех вложенных папках конвертировал, не трогая при этом нетекстовые файлы.

Вот такой вот получился скриптик:

#!/bin/bash
# Наш скриптик
# Этот скрипт конвертирует все файлы в текущей папке и во всех
# вложенных папках из кодировки CP-1251 в UTF-8. Скрипт не определяет,
# в какой кодировке находится файл, поэтому надо избегать двойного конвертирования,
# а то получится каша.
# по ходу дела скрипт заменяет html-тег WINDOWS-1251 на html-тег UTF-8 во всех файлах,
# где найдёт. Замена тегов регистронезависимая.
echo
echo
echo \»Конвертирование файлов из CP-1251 в UTF-8 запущено\»

work_in_directory()
{
  if [ «$dirx» != «./» ] && [ «$dirx» != «» ]
    then
      echo \»cd \’$dirx\’\»
      cd «$dirx»
    else
      echo \»\’$dirx\’ равен \’./\’ или \’\’ \»
  fi

  dirxs=*
  for dirx in $dirxs
  do
    if [ -d «$dirx» ]
      then
         echo \»Найден каталог \’$dirx\’\»
         work_in_directory «$dirx»
      else
         if [ «./$dirx» != «$0» ]
          then
            whatAFile=`file «$dirx» | egrep ‘text’`
              if [ «$whatAFile» != «» ]
                then
                  echo \»Converting file \’$(pwd)/$dirx\’ to UTF-8 encoding…\»
                  mv «$dirx» «$dirx». icv
                  sed s/windows-1251/utf-8/Ig «$dirx».icv | iconv -f WINDOWS-1251 -t UTF-8 > «./$dirx»
                  rm -f «$dirx».icv
                else
                  echo \»Нетекстовый файл \(\’$(pwd)/$dirx\’\) не конвертируем\»
                fi
          else
              echo \»Сценарий не конвертирует сам себя \(\’$0\’\)\»
         fi
    fi
  done
  cd ..
}

work_in_directory «./»

echo \»Конвертирование завершено.\»

exit 0

Декодер Involta: дешифратор кодировок текста онлайн

1. Инвольта
2. Инструменты
3. Смена кодировки

CP-1251UTF-8Base64TranslitUnicode EscapePercent EncodingKOI8-RKOI8-UCP866CP855CP437CP1250CP1252CP1253CP1254CP1255CP1256CP1257CP1258ISO-8859-1ISO-8859-2ISO-8859-3ISO-8859-4ISO-8859-5ISO-8859-6ISO-8859-7ISO-8859-8ISO-8859-9ISO-8859-10ISO-8859-11ISO-8859-12ISO-8859-13ISO-8859-14ISO-8859-15ISO-8859-16GB2312EUC-JPEUC-KRCP-1251UTF-8Base64TranslitUnicode EscapePercent EncodingKOI8-RKOI8-UCP866CP855CP437CP1250CP1252CP1253CP1254CP1255CP1256CP1257CP1258ISO-8859-1ISO-8859-2ISO-8859-3ISO-8859-4ISO-8859-5ISO-8859-6ISO-8859-7ISO-8859-8ISO-8859-9ISO-8859-10ISO-8859-11ISO-8859-12ISO-8859-13ISO-8859-14ISO-8859-15ISO-8859-16GB2312EUC-JPEUC-KR Расшифровать

При онлайн передаче электронных документов (почтовая рассылка, скачивание с сайта и т. д.) в файле может сбиться кодировка. В результате вместо привычных слов, предложений и абзацев вы получаете последовательность непонятных символов. Так случается из-за того, что кодирование и декодирование информации происходит некорректно, и устройства отправителя и получателя просто не понимают друг друга. Чтобы расшифровать зашифрованный текст, обратитесь к нашему онлайн декодеру. Decoder (дешифратор или декодер онлайн) от компании Involta способен подобрать нужную кодировку и изменить текст так, чтобы Вы смогли быстро прочитать непонятные «иероглифы».

Наш инструмент имеет множество возможностей для декодирования. Он позволяет расшифровать base64 и определить исходные данные, а также перевести информацию в любую другую кодировку онлайн, например, UTF-8, CP-1251, ASCII. Encoder может функционировать как шифратор и дешифратор, то есть вы можете закодировать текст и защитить его содержимое от посторонних глаз. Если вам прислали ссылку с непонятным адресом, то URL-decoder online покажет, на какой сайт она ведет. Еще одна полезная функция сервиса – создать или раскодировать транслит, если нужно сделать перевод с кириллицы на латиницу и наоборот. Декодер работает в режиме онлайн и доступен на любом устройстве с доступом в интернет.

Модуль ngx_http_charset_module

Модуль ngx_http_charset_module

Модуль ngx_http_charset_module добавляет указанный
charset в поле заголовка ответа Content-Type.
Кроме того, модуль может конвертировать данные из одной кодировки в другую,
с некоторыми ограничениями:

• конвертация осуществляется в одну сторону — от сервера к клиенту,
• могут быть преобразованы только однобайтовые кодировки
• или однобайтовые кодировки в / из UTF-8.

Пример конфигурации

включить conf / koi-win;

кодировка windows-1251;
source_charset koi8-r;
 

Директивы

 charset off; 

Добавляет указанную кодировку в Content-Type.
поле заголовка ответа.Если эта кодировка отличается от указанной
в директиве source_charset выполняется преобразование.

Параметр off отменяет добавление кодировки.
в поле заголовка ответа Content-Type.

Кодировку можно определить с помощью переменной:

charset $ charset;
 

В таком случае должны присутствовать все возможные значения переменной.
в конфигурации хотя бы один раз в виде
charset_map, charset или
source_charset директивы.Для utf-8 , windows-1251 и
koi8-r кодировок, достаточно включить файлы
conf / koi-win , conf / koi-utf и
conf / win-utf в конфигурацию.
Для других кодировок просто создание фиктивной таблицы преобразования работает,
Например:

charset_map iso-8859-5 _ {}
 

Кроме того, кодировку можно установить в
Поле заголовка ответа «X-Accel-Charset».
Эту возможность можно отключить с помощью
proxy_ignore_headers,
fastcgi_ignore_headers,
uwsgi_ignore_headers,
scgi_ignore_headers,
а также
grpc_ignore_headers
директивы.

Описывает таблицу преобразования из одной кодировки в другую.Таблица обратного преобразования строится с использованием тех же данных.
Коды символов даны в шестнадцатеричном формате.
Отсутствующие символы в диапазоне 80-FF заменяются на «? ».
При преобразовании из UTF-8 символы отсутствуют в однобайтовой кодировке.
заменяются на « & # XXXX; ».

Пример:

charset_map koi8-r windows-1251 {
    C0 FE; # маленький ю
    C1 E0; # маленький а
    C2 E1; # маленький б
    C3 F6; # small ts
    . ..
}
 

При описании таблицы преобразования в UTF-8 коды для кодировки UTF-8 должны
быть приведенным во втором столбце, например:

charset_map koi8-r utf-8 {
    C0 D18E; # маленький ю
    C1 D0B0; # маленький а
    C2 D0B1; # маленький б
    C3 D186; # small ts
    ...
}
 

Полные таблицы преобразования из koi8-r в
windows-1251 , а от koi8-r и
окна-1251 до utf-8
представлены в файлах раздачи conf / koi-win ,
conf / koi-utf и conf / win-utf .

 charset_types текст / HTML текст / XML текст / простой текст / vnd. wap.wml
приложение / javascript приложение / rss + xml; 

Эта директива появилась в версии 0.7.9.

Включает обработку модуля в ответах с указанными типами MIME
в дополнение к « текст / html ».
Специальное значение « * » соответствует любому типу MIME (0.8.29).

До версии 1.5.4 использовалось « application / x-javascript ».
в качестве типа MIME по умолчанию вместо « application / javascript ».

 override_charset off; 

Определяет, нужно ли выполнять преобразование ответов
получено от прокси-сервера или сервера FastCGI / uwsgi / SCGI / gRPC
когда ответы уже содержат кодировку в «Content-Type»
поле заголовка ответа. Если преобразование включено, кодировка указана в полученном
ответ используется как кодировка источника.

Следует отметить, что если ответ получен в подзапросе
затем преобразование из кодировки ответа в кодировку основного запроса
выполняется всегда, независимо от значения override_charset
установка директивы.

Определяет исходную кодировку ответа. Если эта кодировка отличается от указанной
в директиве charset выполняется преобразование.

Encoding 101 — Часть 2: Windows-1252 против UTF-8

Продолжение с Кодировка 101 часть 1

Во второй части будут представлены две наиболее распространенные кодировки, используемые сегодня, и рассмотрены некоторые из их различий.

Различия между разными кодировками

Если бы только вся ИТ-индустрия в свое время договорилась о единой кодировке, сейчас со всем было бы гораздо легче справиться.Тем не менее, это не так. На протяжении многих лет различные компании ставили перед собой задачу решить одну и ту же проблему: как представить текст в виде двоичных данных для хранения или передачи. В результате сегодня существует огромное количество систем кодирования. К сожалению, многие из них почти идентичны, что заставляет усомниться в необходимости их существования еще больше.

Многие современные кодировки основаны на кодировке ASCII, но расширяют ее, чтобы включить больше символов. Это означает, что текст, который содержит только символы, присутствующие в стандарте ASCII, часто также может быть декодирован как ASCII, даже если технически он закодирован с использованием другого стандарта.Это связано с тем, что многие более крупные кодировки по-прежнему используют те же коды, что и ASCII для первых 128 символов, но помимо этих символов эти схемы кодирования отличаются в большей или меньшей степени.

Давайте сравним две наиболее распространенные кодировки, используемые для западных языков, Windows-1252 и UTF-8.

Окна-1252

Это кодировка по умолчанию, используемая системами Windows в большинстве западных стран. Это означает, что текстовые данные, созданные программным обеспечением, работающим в таких системах по умолчанию, будут использовать кодировку Windows-1252, если явно не установлено использование другой кодировки.Некоторое программное обеспечение позволяет пользователю выбирать, какую кодировку использовать, некоторые настроены на использование определенной кодировки, а не по умолчанию, а некоторые оставляют это на усмотрение самой системы.

Windows-1252 — это однобайтовая кодировка, что означает, что каждый символ кодируется как однобайтный, так же, как и в ASCII. Однако, поскольку Windows-1252 использует полные 8 бит каждого байта для своих кодовых точек (в отличие от 7-битных кодов ASCII), она содержит 256 кодовых точек по сравнению с 128 ASCII. Первая половина кодовых точек идентична те, которые определены в ASCII, а вторая половина кодирует дополнительные символы, которых нет в наборе символов ASCII.

UTF-8

UTF-8 — это кодировка из стандарта Unicode. UTF означает формат преобразования Unicode, а цифра 8 в конце означает, что это 8-битная кодировка переменной. Это означает, что каждый символ использует не менее 8 бит для своей кодовой точки, но некоторые могут использовать больше. Как и в Windows-1252, первые 128 кодовых точек идентичны ASCII, но выше эти две кодировки значительно различаются. В то время как Windows-1252 содержит всего 256 кодовых точек, UTF-8 имеет кодовые точки для всего набора символов Unicode. Это делается путем определения некоторых байтовых значений выше 127 в качестве префиксов для дальнейших байтовых значений. Например, символ авторского права (©) кодируется как C2 A9, а знак фунта (£) кодируется как C2 A3. Поскольку байт C2 разработан как байт префикса, это открывает дополнительные 256 2-байтовых кодовых точек с C2 в качестве первого байта.

Этот дизайн означает, что большинство обычных символов, используемых в западных языках, занимают только один байт пространства, в то время как многобайтовые кодировки используются реже.В результате UTF-8 может кодировать любой символ, сохраняя при этом относительно небольшой размер данных. Это полезно как для постоянного хранения (файлы небольшого размера), так и для передачи (например, открытия веб-страницы). Из-за этого UTF-8 в настоящее время является наиболее доминирующей кодировкой, используемой во всемирной паутине, и по состоянию на сентябрь 2019 года на ее долю приходилось 94% всех веб-страниц.

Сравнение кодировок

Давайте посмотрим на конкретном примере того, как эти две кодировки отличаются друг от друга. Мы будем использовать слово «Naïveté», которое содержит два символа, отличных от ASCII (у него есть альтернативные варианты написания без них, но пример — это признанное допустимое написание слова на английском языке).

Как мы видим, символы ï и é существуют в обеих кодировках, но кодируются двумя разными способами. В Windows-1252 все символы кодируются с использованием одного байта, поэтому кодировка содержит всего 256 символов. Однако в UTF-8 эти два символа кодируются с использованием 2 байтов каждый. В результате слово занимает на два байта больше при использовании кодировки UTF-8, чем при использовании кодировки Windows-1252.

Итак, разные кодировки обрабатывают некоторые символы по-разному.В следующей и третьей частях этой серии блогов мы рассмотрим, как это может вызвать у нас проблемы. Найдите здесь «Кодировку 101 — часть 3».

Значения кодировки | Программируемая поисковая система | Разработчики Google

На этой странице перечислены типы кодирования, которые можно использовать для окна поиска и страницы результатов. Кодировка сообщает компьютерам, как хранить и передавать текст по сети.

UTF-8, который является типом кодировки по умолчанию, лучше всего работает в подавляющем большинстве случаев.Фактически, многие проблемы с текстом на странице результатов можно решить, сохранив значение UTF-8 . Единственный раз, когда вам нужно изменить значение кодировки для страницы результатов и окна поиска, — это когда веб-страница хостинга не в UTF-8. Кодировка для программируемой поисковой системы должна соответствовать кодировке вашей веб-страницы.

Вы можете определить кодировку либо на панели управления, либо в файле контекста. На вкладке Basics панели управления вы выбираете язык в раскрывающемся списке Search Engine encoding .В файле контекста вы определяете значение атрибута encoding элемента CustomSearchEngine , как в следующем примере:

В следующей таблице перечислены значения, которые можно использовать с атрибутом кодировки .

Примечание. Если вы не укажете тип кодировки, программируемая поисковая система будет использовать UTF-8 в качестве значения по умолчанию.

Наверх

Поддерживаемые кодировки

java.io.InputStreamReader ,
java.io.OutputStreamWriter ,
java.lang.String классов, а классы в
java.nio.charset пакет может конвертировать между Unicode
и ряд других кодировок символов. Поддерживаемые кодировки
различаются между различными реализациями Java SE 8. Описание класса для
java.nio.charset.Charset
перечисляет кодировки, которые должна поддерживать любая реализация Java SE 8.

JDK 8 для всех платформ
(Solaris, Linux и Microsoft Windows) и JRE 8 для Solaris и Linux
поддерживают все кодировки, показанные на этой странице.JRE 8 для Microsoft Windows может быть
установлена ​​как полная международная версия или как европейская
языковая версия. По умолчанию установщик JRE 8 устанавливает
Версия на европейских языках, если она распознает, что хост, работающий
система поддерживает только европейские языки. Если установщик
признает, что нужен любой другой язык, или если пользователь
запрашивает поддержку неевропейских языков в индивидуальном
установка, устанавливается полная международная версия. В
Версия для европейских языков поддерживает только кодировки, указанные в
следующую таблицу базового набора кодировок.Международная версия
(который включает файл lib / charsets.jar) поддерживает все
кодировки, показанные на этой странице.

В следующих таблицах показаны наборы кодировок, поддерживаемые Java SE.
8. Канонические имена, используемые новыми API-интерфейсами java.nio .
во многих случаях не совпадают с теми, которые используются в
java.io и java.lang API.

для Solaris

Онлайн калькулятор: Кодировка текстового файла

В предыдущей статье я уже затрагивал тему кодирования текста, более подробно описал Unicode и его представление UTF-8 в виде последовательности символов переменной длины.
Этот калькулятор может преобразовывать текст в несколько устаревших кодировок. Я называю их устаревшими, потому что в современных приложениях можно использовать Unicode и его наиболее удобное представление UTF-8.
Однако старые кодировки также могут быть полезны, когда вам нужно компактно закодировать текст, например, для последующего сжатия и передачи, когда принимающая сторона точно знает, в какой кодировке передается текст. Например, русский текст, закодированный в Windows-1251, займет половину места, чем текст в UTF-8.
Итак, калькулятор ниже позволяет вам загрузить файл в выбранной кодировке или просмотреть шестнадцатеричный дамп закодированного текста.

Закодированный текст

Encoding Atari STCP 856 Hebrew DOS Arabic (CP864) DOS Baltic Rim (CP775) DOS Cyrillic (CP855) DOS Cyrillic Russian (CP866) DOS French Canada (CP863) DOS Greek (CP737) DOS Greek 2 (CP869) DOS Hebrew ( CP862) DOS Исландский (CP861) DOS Latin 1 (CP850) DOS Latin 2 (CP852) DOS Latin США (CP437) DOS Nordic (CP865) DOS Португальский (CP860) DOS Турецкий (CP857) EBCDIC 037 США / Канада EBCDIC 1026 Турецкий EBCDIC 424 Иврит EBCDIC 500 Международный EBCDIC 875 Греческий GSM 03.38ISO 8-битный урду (IBM CP1006) ISO 8859-5ISO 8859-6ISO 8859-7ISO 8859-8ISO 8859-9ISO-IR-68ISO / IEC 8859-1 (Latin-1) ISO / IEC 8859-10 (Latin-6) ISO / IEC 8859-11ISO / IEC 8859-13 (Latin-7) ISO / IEC 8859-14ISO / IEC 8859-15 (Latin-9) ISO / IEC 8859-16 (Latin-10) ISO / IEC 8859-2 ( Latin-2) ISO / IEC 8859-3ISO / IEC 8859-4 (Latin-4) KOI8-RKOI8-UKPS 9566KZ-1048Mac OS CelticMac OS Central EuropeanMac OS CroatianMac OS CyrillicMac OS DingbatsMac OS GaelicMac OS GreekMac OS IcelandicMac OS InuitMac OS Roman Румынский Mac OS ТурецкийUTF-8Windows-1250Windows-1251Windows-1252Windows-1253Windows-1254Windows-1255Windows-1256Windows-1257Windows-1258Windows-874Windows-932Windows-936Windows-949Windows-950To быть или не быть , это вопрос сохранения контента33 900 Сохранить расширение Виджет

Вы можете просмотреть созданный файл с помощью декодера текстовых файлов.

Калькулятор выдаст ошибку, если выбрана несовместимая кодировка. В случае Unicode это невозможно — он содержит символы всех современных языков. Но устаревшие 8-битные кодировки содержат ограниченный набор символов. Для текста на нескольких языках необходимая кодировка может вообще не быть найдена.
За годы до Unicode было изобретено множество кодировок для разных языков и наборов символов, поэтому выбор правильной кодировки для вашего текста может быть сложной задачей.Следующий калькулятор находит все кодировки, совместимые с введенным текстом.

Выберите кодировку текста

Быть или не быть, Вот в чем вопрос Кодировка Atari STCP 856 Иврит DOS Арабский (CP864) DOS Baltic Rim (CP775) DOS Кириллица (CP855) DOS Кириллица Русский (CP866) DOS Французский Канада (CP863) DOS Греческий (CP737) DOS Греческий 2 (CP869) DOS Иврит (CP862) DOS Исландский (CP861) DOS Latin 1 (CP850) DOS Latin 2 (CP852) DOS Latin США (CP437) DOS Nordic (CP865) DOS Португальский (CP860) DOS Турецкий ( CP857) EBCDIC 037 США / Канада EBCDIC 1026 Турецкий EBCDIC 424 Иврит EBCDIC 500 Международный EBCDIC 875 Греческий GSM 03.38ISO 8-битный урду (IBM CP1006) ISO 8859-5ISO 8859-6ISO 8859-7ISO 8859-8ISO 8859-9ISO-IR-68ISO / IEC 8859-1 (Latin-1) ISO / IEC 8859-10 (Latin-6) ISO / IEC 8859-11ISO / IEC 8859-13 (Latin-7) ISO / IEC 8859-14ISO / IEC 8859-15 (Latin-9) ISO / IEC 8859-16 (Latin-10) ISO / IEC 8859-2 ( Latin-2) ISO / IEC 8859-3ISO / IEC 8859-4 (Latin-4) KOI8-RKOI8-UKPS 9566KZ-1048Mac OS CelticMac OS Central EuropeanMac OS CroatianMac OS CyrillicMac OS DingbatsMac OS GaelicMac OS GreekMac OS IcelandicMac OS InuitMac OS Roman Румынский Mac OS ТурецкийUTF-8Windows-1250Windows-1251Windows-1252Windows-1253Windows-1254Windows-1255Windows-1256Windows-1257Windows-1258Windows-874Windows-932Windows-936Windows-949Windows-950

Файл очень большой.Во время загрузки и создания может произойти замедление работы браузера.

Скачать
закрыть

content_copy Ссылка сохранить Сохранить расширение Виджет

Калькуляторы поддерживают 70 различных кодировок:

IBM EBCDIC

EBCDIC — стандартная 8-битная кодировка, разработанная IBM для использования на мэйнфреймах IBM.

ISO 8859 кодировки

Семейство кодировок, совместимых с ASCII, разработанных Международной организацией по стандартизации (ISO) и Международной электротехнической комиссией (IEC)

Семейство кодирования KOI8

KOI8 — 8-битная ASCII-совместимая кодировка для представления букв кириллических алфавитов

Кодировки Mac OS

DOS Cod Pages

кодировок для MS-DOS и аналогичных операционных систем.

Кодировки Windows

Другое

.

Правила преобразования кодировок в Unicode были получены из Unicode.org ^сайт.

Странный выбор кодировки из некоторых писем при ответе windows-1251 vs. utf-8 (# 723) · Проблемы · GNOME / Geary · GitLab

Странный выбор кодировки из некоторых писем при ответе windows-1251 vs. utf-8

Сводка ошибки
Я пытаюсь ответить на письмо из списка рассылки Shotwell: https://mail.gnome.org/archives/shotwell-list/2020-Feb February/msg00002.html

Ваша установка

Чтобы получить информацию об установке, скопируйте ее из Geary’s Problem
Если отображается диалоговое окно отчета (или откройте Geary Inspector, набрав
Shift + Alt + I), выбрав Система и нажав Копировать
кнопку, затем вставьте сюда.

• Версия Geary: 3.34.2 / 3.35.90 / c205d491
• Метод установки: артефакт flathub / gnome-nightly / flatpak из конвейера, запущенного на этом хэше
• Окружение рабочего стола: GNOME
• Операционная система и версия: Ubuntu 18.04
• Провайдер электронной почты: собственный почтовый сервер

Шаги по воспроизведению

1. Ответ для прессы
2. Отправить на почту
3. Проверить источник почты

Что случилось?

Исходное письмо состоит из нескольких частей, одна часть — Content-Type: text / plain; charset = «UTF-8», другой Ascii.Если я отвечу на него, полученное письмо будет иметь кодировку windows-1251.

Чего вы ожидали?

Используйте UTF-8

Соответствующие логи и / или скриншоты
Исходное письмо:
geary-message-THL6G0.txt
Отвечать:
geary-message-ZGJ1G0.txt

Отредактировано 05 марта 2020 г. , автор Jens Georg

Руководство пользователя

Глава 6: Поддержка Unicode и не-ASCII

Глава 6.Поддержка Unicode и не-ASCII

6.1 Формат для печати в кавычках
6.2 Символы, отличные от ASCII в заголовках
6.3 Unicode и UTF-8
6.4 Поддержка UTF-8 в AspEmail
6.5 Допустимые значения CharSet

6.1 Формат цитируемой печати

AspEmail может отправлять сообщения в алфавитах, отличных от US-ASCII.
за счет поддержки формата «Цитата для печати». Этот формат описан в
RFC-2045.Идея формата заключается в том, что символы с кодами меньше 33 и больше
чем 126 представлены знаком «=», за которым следует двузначное шестнадцатеричное представление.
ценности персонажа. Например, десятичное значение 12 (подача формы US-ASCII)
представлен как = 0C , а десятичное значение 61 (US-ASCII «=») может быть представлено
как = 3D .

AspEmail кодирует тело сообщения в формате Quoted-Printable
автоматически, если для свойства ContentTransferEncoding установлено значение
строка «Quoted-Printable» (регистр букв не имеет значения).Вы также можете установить свойство Charset
к соответствующему набору символов. Следующий фрагмент кода отправляет
сообщение на русском языке:

<% @ codepage = 1251%>

<%
…
Mail.Charset = «Windows-1251»
Mail.Body = «-«.
Mail.ContentTransferEncoding = «Цитата для печати»
%>

Директива <% @ codepage = 1251%> предписывает
интерпретатор ASP для обработки жестко запрограммированных символов в сценарии
в виде русских символов (1251 — русская кодовая страница).Как результат,
Body свойство получит русскую строку Unicode.

6.2 Символы не-ASCII в заголовках

Если вы хотите отправить сообщение с определенными заголовками, например, Тема: ,
To: или From: , содержащие символы, отличные от US-ASCII, следует использовать
метод Mail.EncodeHeader для кодирования строки символов в соответствии с
RFC 1522.Метод принимает один обязательный параметр, строку заголовка,
и один необязательный параметр, набор символов, который по умолчанию равен « ISO-8859-1 ».
Например:

<% @ codepage = 1251%>

<%
Mail.Subject = Mail.EncodeHeader («-«, «Windows-1251»)
Mail.FromName = Mail.EncodeHeader («», «Windows-1251»)
Mail.AddAddress «[email protected]», Mail.EncodeHeader («»)
%>

6.3 Unicode и UTF-8

Из MSDN: «Unicode — это 16-битный стандарт кодировки символов фиксированной ширины, который
охватывает практически все символы, обычно используемые на компьютерах сегодня.
Это включает в себя большинство письменных языков мира, а также издательские персонажи,
математические и технические символы и знаки препинания «.

Из Unicode.org: «Компьютеры … хранят буквы и другие символы
присвоение номера каждому.До изобретения Unicode существовало
сотни различных систем кодирования для присвоения этих чисел.
Ни одна кодировка не может содержать достаточно символов …
Unicode предоставляет уникальный номер для каждого символа,
независимо от того, какая платформа, какая программа, на каком языке ».

Например, основная латинская буква «А» имеет шестнадцатеричный код 0041 (65), русский
буква имеет код Hex 0416 (1046), а китайский иероглиф
имеет код Hex 32A5 (12965).

UTF-8 (формат преобразования Unicode, 8-битная форма кодирования) рекомендуется
формат, который будет использоваться для отправки данных на основе Unicode по сетям, в частности, через Интернет.
UTF-8 представляет значение Unicode как последовательность из 1, 2 или 3 байтов.

Символы Юникода в диапазоне от 0000 до 007F кодируются просто как байты.
00 до 7F. Это означает, что файлы и строки, содержащие только 7-битный ASCII
символы имеют одинаковую кодировку как в ASCII, так и в UTF-8.Следовательно, Unicode 0041 («A») в UTF-8 — это Hex 41.

Символы Юникода в диапазоне от 0080 до 07FF кодируются как последовательность из двух байтов.
Например, Unicode 0416 ()
кодируется как Hex D0 96. Кодируются символы Unicode в диапазоне от Hex 0800 до FFFF.
как последовательность из трех байтов. Например, Unicode 32A5 ()
кодируется как Hex E3 8A A5.

6.4 Поддержка UTF-8 в AspEmail

AspEmail 5.0 предлагает полную поддержку UTF-8 как в теле сообщения, так и в заголовках.
Чтобы отправить сообщение в кодировке UTF-8, вы должны установить CharSet
свойство к строке « UTF-8 » (регистр не имеет значения),
и ContentTransferEncoding на « Quoted-Printable ».
Вы также должны передать « UTF-8 » в качестве второго аргумента для EncodeHeader .

В следующем примере кода демонстрируется использование UTF-8:

<% ‘изменить на адрес вашего собственного SMTP-сервера strHost = «smtp.myisp.net « ‘Включить UTF-8 -> Перевод Unicode для элементов формы Session.CodePage = 65001 ‘Код UTF-8 Если Запрос («Отправить») «» То Установите Mail = Server.CreateObject («Persits.MailSender») ‘введите действительный SMTP-хост Mail.Host = strHost Mail.From = «[email protected]» ‘с адреса Mail.FromName = Mail.EncodeHeader (Запрос («FromName»), «utf-8») Почта.AddAddress Request («Кому») ‘тема сообщения Mail.Subject = Mail.EncodeHeader (Запрос («Тема»), «utf-8») ‘тело сообщения Mail.Body = Request («Body») ‘Параметры UTF-8 Mail.CharSet = «UTF-8» Mail.ContentTransferEncoding = «Цитата для печати» Mail.Send ‘отправить сообщение Response.Write «Сообщение отправлено» & Request («To») Конец, если %> <ТЕЛО> <ТАБЛИЦА ЯЧЕЙКИ = 0 ЯЧЕЙКА = 0>
Введите адрес электронной почты:
Введите свое имя:
Введите тему:
Введите текст:

В этом примере кода есть несколько важных элементов, которые нельзя упускать из виду:

Этот тег META определяет набор символов для этой страницы как UTF-8.Это, помимо прочего, указывает браузеру кодировать все элементы формы в кодировке UTF8.
когда форма отправлена.

Session.CodePage = 65001

Эта строка указывает нашему сценарию ASP преобразовывать элементы формы в кодировке UTF8.
(возвращается коллекцией Request.Form) обратно к обычным строкам Unicode. Номер
65001 — это кодовая страница UTF-8.

Mail.Subject = Mail.EncodeHeader (Запрос («Тема»), «utf-8»)

Второй необязательный аргумент установлен в «UTF-8» для правильного кодирования заголовка.

Mail.CharSet = «UTF-8»
Mail.ContentTransferEncoding = «Quoted-Printable»

Эти две строки обеспечивают правильную кодировку UTF-8 тела сообщения.

Щелкните ссылки ниже, чтобы запустить этот пример кода:

http: //localhost/aspemail/NonAscii/Unicode.asp
http: //localhost/aspemail/NonAscii/Unicode.aspx

6.5 допустимых значений CharSet

Вы можете указать следующие строковые значения для свойства CharSet ,
а также второй необязательный аргумент метода EncodeHeader :

Значение	Значение
«УТФ-8»	UTF-8
«УТФ-7»	UTF-7
«Окна-1250» «cp1250»	ANSI — Центральная Европа
«Окна-1251» «cp1251»	ANSI — кириллица
«Windows-1252» «cp1252» «ascii» «us-ascii»	Латиница I
«Окна-1253» «cp1253»	ANSI — греческий
«Окна-1254» «cp1254»	ANSI — турецкий
«Окна-1255» «cp1255»	ANSI — иврит
«Окна-1256» «cp1256»	ANSI — арабский
«Окна-1257» «cp1257»	ANSI — Балтика
«Окна-1258» «cp1258»	ANSI — вьетнамский
«ISO-8859-1»	Latin I (значение по умолчанию)
«ISO-8859-2»	Центральная Европа
«ISO-8859-3»	Латиница 3
«ISO-8859-4»	Балтика
«ISO-8859-5»	Кириллица
«ISO-8859-6»	Арабский
«ISO-8859-7»	Греческий
«ISO-8859-8»	Еврейский
«ISO-8859-9»	Латиница 5
«ISO-8859-15»	Латиница 9
«cp866»	Русский DOS
«КОИ8-Р»	Русский
«КОИ8-У»	Украинский
«shift_jis»	Японская Windows
«ks_c_5601-1987» «корейский»	Корейский
«EUC-KR» «корейский»	EUC — корейский
«БОЛЬШОЙ5»	Традиционный китайский Windows
«GB2312» «китайский»	Китайский упрощенный
«HZ-GB-2312»	Упрощенный китайский HZ
«EUC-JP»	EUC — японский
«X-EUC-TW»	EUC — традиционный китайский

.