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

  • Статья
  • Чтение занимает 5 мин

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

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

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

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

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

По умолчанию PowerShell использует кодировку Юникода. Однако несколько командлетов имеют параметр

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

Следующие командлеты имеют параметр 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того, всегда создает метку BOM. По умолчанию PowerShell (версия 6 и выше) используется utf8NoBOM для всех текстовых выходных данных.

Чтобы обеспечить оптимальную общую совместимость, не используйте BOM в файлах UTF-8. Платформы Unix и служебные программы unix-heritage также используются на платформах Windows, не поддерживают BOM.

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

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

Если в скриптах необходимо использовать символы, отличные от Ascii, сохраните их как UTF-8 с помощью BOM. Без BOM Windows PowerShell неправильно интерпретирует скрипт как кодируемый в устаревшей кодовой странице ANSI. И наоборот, файлы, имеющие BOM UTF-8, могут быть проблемными на платформах Unix. Многие инструменты Unix, такие как cat, awksedи некоторые редакторы, например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 файлы с помощью модели BOM. Если используется параметр Append , кодировка может отличаться (см.

    ниже).

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

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

  • При отсутствии явного параметра Add-Contentкодирования обнаруживает существующую кодировку и автоматически применяет его к новому содержимому. Если существующее содержимое не имеет BOM,

    Default используется кодировка ANSI. Поведение в PowerShell (версии 6 и более поздних версиях), за исключением кодировки Add-ContentUtf8по умолчанию.

  • Export-Csv -Append сопоставляет существующую кодировку, если целевой файл содержит метку BOM. При отсутствии модели BOM используется Utf8 кодировка.

  • Start-Transcript -Append соответствует существующей кодировке файлов, включающих метку BOM. При отсутствии модели BOM по умолчанию используется кодировка

    Ascii . Эта кодировка может привести к потере данных или повреждению символов, если данные в расшифровке содержат многобайтовые символы.

Для командлетов, которые считывают строковые данные в отсутствие модели BOM:

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

  • Import-Csv, Import-CliXmlи Select-String предполагается Utf8 в отсутствие модели BOM.

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

В PowerShell (версии 6 и более поздних версиях) параметр

Encoding поддерживает следующие значения:

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

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

Начиная с PowerShell 6.2, параметр кодирования также допускает числовые идентификаторы зарегистрированных кодовых страниц (например -Encoding 1251) или строковых имен зарегистрированных кодовых страниц (например -Encoding "windows-1251"). Дополнительные сведения см. в документации по .NET для Encoding.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 для сохранения в файлах.

См. также

  • about_Preference_Variables
  • Метка порядка байтов
  • Кодовые страницы — приложения Win32
  • Encoding.CodePage
  • Общие сведения о кодировании символов в .NET
  • Стандарт Юникода
  • UTF-16LE

Кодировки

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

 Язык   Идентификатор   Кодировка 
 Russian   ru   iso-8859-5, windows-1251, koi8-r 
 English   en   iso-8859-1, windows-1252 
 Afrikaans   af   iso-8859-1, windows-1252 
 Albanian   sq   iso-8859-1, windows-1250 
 Arabic   ar   iso-8859-6, windows-1256
 Basque   eu   iso-8859-1, windows-1252 
 Bulgarian   bg   iso-8859-5, windows-1251
 Belorussian   be   iso-8859-5, windows-1251
 Catalan   ca   iso-8859-15, windows-1252 
 Croatian   hr   iso-8859-2, windows-1250
 Czech   cs   iso-8859-2, windows-1250
 Danish   da   iso-8859-1, windows-1252 
 Dutch   nl   iso-8859-1, windows-1252 
 Esperanto   eo   iso-8859-3 
 Estonian   et   iso-8859-15, windows-1257
 Faroese   fo   iso-8859-1, windows-1252 
 Finnish   fi   iso-8859-1, windows-1252 
 French   fr   iso-8859-1, windows-1252 
 Galician   gl   iso-8859-1, windows-1252 
 German   de   iso-8859-1, windows-1252 
 Greek   el   iso-8859-7 
 Hebrew   iw       iso-8859-8 
 Hungarian   hu   iso-8859-2, windows-1250
 Icelandic   is   iso-8859-1, windows-1252 
 Irish   ga   iso-8859-1, windows-1252 
 Italian   it   iso-8859-1, windows-1252 
 Japanese   ja   shift_jis, iso-2022-jp, euc-jp 
 Korean   ko   euc-kr 
 Latvian   lv   iso-8859-13, windows-1257 
 Lithuanian   lt   iso-8859-13, windows-1257 
 Macedonian   mk   iso-8859-5, windows-1251
 Maltese   mt   iso-8859-3 
 Norwegian   no   iso-8859-1, windows-1252 
 Polish   pl   iso-8859-2, windows-1250 
 Portuguese   pt   iso-8859-1, windows-1252 
 Portuguese (бразильский)   br   iso-8859-1, windows-1252 
 Romanian   ro   iso-8859-2, windows-1250
 Scottish   gd   iso-8859-1, windows-1252 
 Serbian cyrillic  sr   iso-8859-5, windows-1251 
 Serbian latin  sr   iso-8859-2, windows-1250 
 Slovak   sk   iso-8859-2, windows-1250
 Slovenian   sl   iso-8859-2, windows-1250
 Spanish   la   iso-8859-1, windows-1252 
 Swedish   sv   iso-8859-1, windows-1252 
 Turkish   tr   iso-8859-9, windows-1254 
 Ukrainian   ua       windows-1251, koi8-u      

© «Битрикс», 2001-2022, «1С-Битрикс», 2022

Наверх

Как исправить отображение кириллицы в Windows 10

Одна из возможных проблем, с которыми можно столкнуться после установки Windows 10 — кракозябры вместо русских букв в интерфейсе программ, а также в документах. Чаще неправильное отображение кириллицы встречается в изначально англоязычных и не совсем лицензионных версиях системы, но бывают и исключения.

В этой инструкции — о том, как исправить «кракозябры» (или иероглифы), а точнее — отображение кириллицы в Windows 10 несколькими способами. Возможно, также будет полезным: Как установить и включить русский язык интерфейса в Windows 10 (для систем на английском и других языках).

Исправление отображения кириллицы с помощью настроек языка и региональных стандартов Windows 10

Самый простой и чаще всего работающий способ убрать кракозябры и вернуть русские буквы в Windows 10 — исправить некоторые неправильные настройки в параметрах системы.

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

  1. Откройте панель управления (для этого можно начать набирать «Панель управления» или «Control Panel» в поиске на панели задач.
  2. Убедитесь, что в поле «Просмотр» (View by) установлено «Значки» (Icons) и выберите пункт «Региональные стандарты» (Region). 
  3. На вкладке «Дополнительно» (Administrative) в разделе «Язык программ, не поддерживающих Юникод» (Language for non-Unicode programs) нажмите по кнопке «Изменить язык системы» (Change system locale). 
  4. Выберите русский язык, нажмите «Ок» и подтвердите перезагрузку компьютера. 

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

Как исправить иероглифы Windows 10 путем изменения кодовых страниц

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

С помощью редактора реестра

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

  1. Нажмите клавиши Win+R на клавиатуре, введите regedit и нажмите Enter, откроется редактор реестра.
  2. Перейдите к разделу реестра
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage
    и в правой части пролистайте значения этого раздела до конца. 
  3. Дважды нажмите по параметру ACP, установите значение 1251 (кодовая страница для кириллицы), нажмите Ок и закройте редактор реестра. 
  4. Перезагрузите компьютер (именно перезагрузка, а не завершение работы и включение, в Windows 10 это может иметь значение).

Обычно, это исправляет проблему с отображением русских букв. Вариация способа с помощью редактора реестра (но менее предпочтительная) — посмотреть на текущее значение параметра ACP (обычно — 1252 для изначально англоязычных систем), затем в том же разделе реестра найти параметр с именем 1252 и изменить его значение с c_1252. nls на c_1251.nls.

Путем подмена файла кодовой страницы на c_1251.nls

Второй, не рекомендуемый мной способ, но иногда выбираемый теми, кто считает, что правка реестра — это слишком сложно или опасно: подмена файла кодовой страницы в C:\ Windows\ System32 (предполагается, что у вас установлена западно-европейская кодовая страница — 1252, обычно это так. Посмотреть текущую кодовую страницу можно в параметре ACP в реестре, как было описано в предыдущем способе).

  1. Зайдите в папку C:\ Windows\ System32 и найдите файл c_1252.NLS, нажмите по нему правой кнопкой мыши, выберите пункт «Свойства» и откройте вкладку «Безопасность». На ней нажмите кнопку «Дополнительно». 
  2. В поле «Владелец» нажмите «Изменить». 
  3. В поле «Введите имена выбираемых объектов» укажите ваше имя пользователя (с правами администратора). Если в Windows 10 используется учетная запись Майкрософт, вместо имени пользователя укажите адрес электронной почты. Нажмите «Ок» в окне, где указывали пользователя и в следующем (Дополнительные параметры безопасности) окне. 
  4. Вы снова окажетесь на вкладке «Безопасность» в свойствах файла. Нажмите кнопку «Изменить».
  5. Выберите пункт «Администраторы» (Administrators) и включите полный доступ для них. Нажмите «Ок» и подтвердите изменение разрешений. Нажмите «Ок» в окне свойств файла. 
  6. Переименуйте файл c_1252.NLS (например, измените расширение на .bak, чтобы не потерять этот файл).
  7. Удерживая клавишу Ctrl, перетащите находящийся там же в C:\Windows\System32 файл c_1251.NLS (кодовая страница для кириллицы) в другое место этого же окна проводника, чтобы создать копию файла. 
  8. Переименуйте копию файла c_1251.NLS в c_1252.NLS.
  9. Перезагрузите компьютер.

После перезагрузки Windows 10 кириллица должна будет отображаться не в виде иероглифов, а как обычные русские буквы.

remontka.pro в Телеграм | Другие способы подписки

Поддержать автора и сайт

кодовых страниц — приложения Win32

  • Статья
  • 5 минут на чтение

Большинство приложений, написанных сегодня, обрабатывают символьные данные в основном как Unicode, используя кодировку UTF-16. Однако многие устаревшие приложения продолжают использовать наборы символов на основе кодовых страниц. Даже новым приложениям иногда приходится работать с кодовыми страницами, часто по одной из следующих причин:

  • Для связи с устаревшими приложениями.
  • Для связи со старыми почтовыми серверами и серверами новостей, которые могут не всегда поддерживать Unicode.
  • Для связи с консолью Windows в устаревших целях. (Консоль поддерживает Unicode, но некоторые устаревшие инструменты командной строки могут не поддерживаться.)

Примечание

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

 

Каждая кодовая страница представлена ​​идентификатором кодовой страницы, например 1252, и обрабатывается функциями API Unicode и набора символов. Список поддерживаемых идентификаторов кодовых страниц см. в разделе Идентификаторы кодовых страниц. Справочник «Кодовые страницы» в Глобальном центре разработчиков Microsoft Go дает полное описание многих кодовых страниц.

Кодовые страницы Windows, обычно называемые «кодовыми страницами ANSI», представляют собой кодовые страницы, для которых значения, отличные от ASCII (значения больше 127), представляют международные символы. Эти кодовые страницы изначально используются в Windows Me, а также доступны в Windows NT и более поздних версиях.

Примечание

Первоначально кодовая страница Windows 1252, кодовая страница, обычно используемая для английского и других западноевропейских языков, была основана на проекте Американского национального института стандартов (ANSI). Этот проект в конечном итоге стал ISO 8859-1, но кодовая страница Windows 1252 была реализована до того, как стандарт стал окончательным, и это не совсем то же самое, что ISO 8859-1.

 

Многие функции Windows API имеют версии «A» (ANSI) и «W» (широкий, Unicode). Версия «A» обрабатывает текст на основе кодовых страниц Windows, а версия «W» обрабатывает текст в формате Unicode. См. Типы данных Windows для строк и Соглашения для прототипов функций.

Кодовые страницы Windows также иногда называют «активными кодовыми страницами» или «системными активными кодовыми страницами». В операционной системе Windows всегда есть одна активная в данный момент кодовая страница Windows. Все версии функций API ANSI используют текущую активную кодовую страницу.

Кодовые страницы производителя оригинального оборудования (OEM) — это кодовые страницы, для которых значения, отличные от ASCII, представляют символы рисования линий и пунктуации. Эти кодовые страницы изначально использовались для MS-DOS и до сих пор используются для консольных приложений. Они также используются для нерасширенных имен файлов в файловых системах FAT12, FAT16 и FAT32, как описано в разделе Наборы символов, используемые в именах файлов. Обычная кодовая страница OEM для английского языка — кодовая страница 437.

Как для кодовых страниц Windows, так и для кодовых страниц OEM значения кода от 0x00 до 0x7F соответствуют 7-битному набору символов ASCII. Кодовые значения от 0x00 до 0x19 и 0x7F всегда представляют собой стандартные управляющие символы, а от 0x20 до 0x7E — стандартизированные отображаемые символы. Символы, представленные остальными кодами, от 0x80 до 0xff, различаются в зависимости от набора символов. Каждый набор символов включает различные специальные символы, обычно настроенные для языка или группы языков. Кодовая страница Windows 1252 и кодовая страница OEM 437 обычно используются в США.

Помимо кодовых страниц Windows и OEM, ваши приложения могут использовать неродные кодовые страницы. Примерами являются кодовые страницы EBCDIC и Macintosh.

Две кодировки Unicode (UTF-7 и UTF-8) реализованы как кодовые страницы. Как и другие кодовые страницы, каждая страница известна по числовому идентификатору и может обрабатываться многими из тех же функций API Unicode и набора символов.

Кодовые страницы могут быть либо страницами однобайтового набора символов (SBCS), либо страницами двухбайтового набора символов (DBCS). На страницах SBCS каждый байт напрямую кодирует один символ, так что можно представить ровно 256 различных символов (включая управляющие символы, буквы, цифры, знаки препинания, символы и т.п.). Кодовые страницы DBCS используются для таких языков, как японский и китайский. В такой кодовой странице некоторые символы имеют двухбайтовую кодировку с определенными значениями байтов (всегда значения больше 127), выступающими в качестве «начальных байтов». Вместо того, чтобы кодировать символы сами по себе, начальные байты могут быть сопоставлены с символом только в сочетании с «конечным байтом».

Некоторые устаревшие протоколы требуют использования кодовых страниц SBCS и DBCS. Каждая кодовая страница SBCS/DBCS поддерживает разные символы, но ни одна кодовая страница не поддерживает весь набор символов, предоставляемых Unicode. Каждая кодовая страница SBCS/DBCS поддерживает разные подмножества, закодированные по-разному.

Примечание

Данные, преобразованные из одной кодовой страницы SBCS или DBCS в другую, могут быть повреждены, поскольку одно и то же значение данных на разных кодовых страницах может кодировать разные символы. Данные, преобразованные из Unicode в SBCS или DBCS, могут быть потеряны, так как данная кодовая страница может не соответствовать каждому символу, используемому в этих конкретных данных Unicode.

 

Помимо кодовых страниц SBCS и DBCS, в ваших приложениях доступны кодовые страницы многобайтовых наборов символов 52936, 54936, 51949 и 5022x, в которых используется подход, аналогичный подходу для DBCS. Однако кодовая страница многобайтового набора символов выходит за рамки двухбайтовых кодировок некоторых символов. UTF-7 и UTF-8 используют аналогичный подход для кодирования Unicode на основе 7-битных и 8-битных байтов соответственно. Дополнительные сведения см. в разделе Юникод.

Несколько функций Unicode и наборов символов позволяют вашим приложениям обрабатывать кодовые страницы. Приложение может использовать GetCPInfo и GetCPInfoEx функции для получения информации о кодовой странице. Эта информация включает символ по умолчанию, используемый, когда символ в преобразованной строке не имеет соответствующей записи на кодовой странице.

Приложение может использовать функции MultiByteToWideChar и WideCharToMultiByte для преобразования между строками на основе кодовых страниц Windows и строк Unicode. Хотя их имена относятся к «MultiByte», эти функции одинаково хорошо работают с кодовыми страницами SBCS, DBCS и многобайтовыми наборами символов.

Примечание

WideCharToMultiByte могут быть потеряны некоторые данные, если предоставленная кодовая страница не может представить все символы в строке Unicode.

 

Ваше приложение может выполнять преобразование между кодовыми страницами Windows и кодовыми страницами OEM с помощью стандартных функций библиотеки времени выполнения C. Однако использование этих функций сопряжено с риском потери данных, поскольку символы, которые могут быть представлены каждой кодовой страницей, не совпадают точно.

Ваши приложения также могут вызывать Функция GetACP . Эта функция извлекает идентификатор текущей кодовой страницы Windows (ANSI).

Наборы символов

 

 

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

  • Статья
  • 5 минут на чтение

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

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

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

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

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

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

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

  • Microsoft.PowerShell.Management
    • Добавить контент
    • Получить содержимое
    • Set-Content
  • Microsoft.PowerShell.Утилита
    • Экспорт-Clixml
    • Экспорт-CSV
    • Экспорт-PSSession
    • Формат-Hex
    • Импорт-CSV
    • Исходящий файл
    • Строка выбора
    • Отправить-MailMessage

Знак порядка байтов

Знак порядка байтов (BOM) представляет собой подпись Unicode в первых нескольких байтах файл или текстовый поток, которые указывают, какая кодировка Unicode используется для данных. За дополнительную информацию см. Документация по меткам порядка байтов.

В Windows PowerShell любая кодировка Unicode, кроме UTF7 , всегда создает Спецификация PowerShell (v6 и выше) по умолчанию использует utf8NoBOM для всего вывода текста.

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

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

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

Если вам нужно использовать символы, отличные от Ascii, в ваших скриптах, сохраните их как UTF-8 с спецификацией. Без спецификации 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 с порядком байтов от старшего к старшему.
  • Байт Кодирует набор символов в последовательность байтов.
  • По умолчанию Использует кодировку, соответствующую активной кодовой странице системы. (обычно ANSI).
  • OEM Использует кодировку, соответствующую текущему OEM-коду системы. страница.
  • Строка То же, что и Юникод .
  • Unicode Использует UTF-16 с прямым порядком байтов.
  • Неизвестно То же, что и Юникод .
  • UTF32 Использует UTF-32 с прямым порядком байтов.
  • UTF7 Использует UTF-7.
  • UTF8 Использует UTF-8 (со спецификацией).

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

Примечание

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

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

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

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

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

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

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

  • New-Item -Type File -Value создает файл UTF-8 без спецификации.

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

  • Start-Transcript создает файлы Utf8 со спецификацией. Когда добавить используется параметр, кодировка может быть другой (см. ниже).

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

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

  • При отсутствии явного параметра Encoding Add-Content обнаруживает существующую кодировку и автоматически применяет ее к новому содержимому. Если существующее содержимое не имеет спецификации, По умолчанию используется кодировка ANSI. Поведение Add-Content аналогичен PowerShell (v6 и выше), за исключением значения по умолчанию. кодировка Utf8 .

  • Export-Csv -Append соответствует существующей кодировке, когда целевой файл содержит спецификацию. При отсутствии спецификации используется кодировка Utf8 .

  • Start-Transcript -Append соответствует существующей кодировке файлов, которые включить спецификацию. При отсутствии спецификации по умолчанию используется кодировка Ascii . Этот кодирование может привести к потере данных или повреждению символов, когда данные в расшифровка содержит многобайтовые символы.

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

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

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

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

В PowerShell (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 по умолчанию использует utf8NoBOM для всех выходных данных.

Начиная с PowerShell 6.2, Параметр кодирования также допускает числовое Идентификаторы зарегистрированных кодовых страниц (например, -Encoding 1251 ) или строковые имена зарегистрированные кодовые страницы (например, -Кодировка "windows-1251" ). Чтобы получить больше информации, см. документацию .NET для Кодировка.Кодовая Страница.

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

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

  • $PSDefaultParameterValues ​​
  • $OutputEncoding

Для получения дополнительной информации см. about_Preference_Variables.

Начиная с PowerShell 5.1 операторы перенаправления ( > и >> ) вызывают Командлет Out-File . Поэтому вы можете установить для них кодировку по умолчанию, используя привилегированная переменная $PSDefaultParameterValues ​​, как показано в этом примере:

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

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

 $PSDefaultParameterValues['*:Кодировка'] = 'utf8'

Important

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

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

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

См. также

  • about_Preference_Variables
  • Метка порядка байтов
  • Кодовые страницы — приложения Win32
  • Кодировка.CodePage
  • Введение в кодировку символов в . NET
  • Стандарт Unicode
  • УТФ-16LE

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

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.

евро
Каноническое имя для java.nio API Каноническое имя для API java.io и API java.lang Псевдоним или Псевдонимы Описание
ЦЭСУ-8 CESU8 CESU8 csCESU-8 Юникод CESU-8
IBM00858 СР858 cp858 858 ПК-многоязычный-850+евро cp00858 ccsid00858 Вариант Cp850 с символом евро
IBM437 CP437 ibm437 437 ibm-437 cspc8codepage437 cp437 windows-437 MS-DOS США, Австралия, Новая Зеландия, Южная Африка
IBM775 CP775 ibm-775 ibm775 775 cp775 ПК Балтика
IBM850 СР850 cp850 cspc850многоязычный ibm850 850 ibm-850 MS-DOS Latin-1
IBM852 СР852 csPCp852 ibm-852 ibm852 852 cp852 Латинская версия MS-DOS-2
IBM855 СР855 ibm855 855 ibm-855 cp855 cspcp855 IBM Кириллица
IBM857 СР857 ibm857 857 cp857 csIBM857 ibm-857 IBM Турецкий
IBM862 СР862 csIBM862 cp862 ibm862 862 cspc862latinhebrew ibm-862 ПК Иврит
IBM866 СР866 ibm866 866 ibm-866 csIBM866 cp866 MS-DOS Русский
ИСО-8859-1 ИСО8859_1 819 ISO8859-1 l1 ISO_8859-1:1987 ISO_8859-1 8859_1 iso-ir-100 латинский1 cp819ISO8859_1 IBM819 ISO_8859_1 IBM-819 csISOLatin1 ISO-8859-1, латинский алфавит № 1
ИСО-8859-2 ИСО8859_2 ISO8859-2 ibm912 l2 ISO_8859-2 8859_2 cp912 ISO_8859-2:1987 iso8859_2 iso-ir-101 latin2 912 csISOLatin2 ibm-912 Латинский алфавит № 2
ИСО-8859-4 ИСО8859_4 8859_4 latin4 l4 cp914 ISO_8859-4:1988 ibm914 ISO_8859-4 iso-ir-110 iso8859_4 csISOLatin4 iso8859-4 914 ибм-914 Латинский алфавит № 4
ИСО-8859-5 ИСО8859_5 ISO_8859-5:1988 csISOLatinCyrillic iso-ir-144 iso8859_5 cp915 8859_5 ibm-915 ISO_8859-5 ibm915 915 кириллица ISO8859-5 Латинский/кириллица
ИСО-8859-7 ИСО8859_7 греческий 8859_7 греческий8 ibm813 ISO_8859-7 iso8859_7 ELOT_928 cp813 ISO_8859-7:1987 sun_eu_greek csISOLatinGreek iso-ir-126 813 iso8859-7 ECMA-118 IBM-813 Латинский/греческий алфавит (ISO-8859-7:2003)
ИСО-8859-9 ИСО8859_9 ibm-920 ISO_8859-9 8859_9 ISO_8859-9:1989 ibm920 латинский5 l5 iso8859_9 cp920 920 iso-ir-148 ISO8859-9 csISOLatin5 Латинский алфавит № 5
ИСО-8859-13 ИСО8859_13 iso_8859-13 ISO8859-13 iso8859_13 8859_13 Латинский алфавит № 7
ИСО-8859-15 ИСО8859_15 ISO8859-15 LATIN0 ISO8859_15_FDIS ISO8859_15 cp923 8859_15 L9 ISO-8859-15 IBM923 csISOlatin9 ISO_8859-15 IBM-923 csISOlatin0 923 ЛАТИН9 Латинский алфавит № 9
КОИ8-Р КОИ8_Р koi8_r koi8 cskoi8r КОИ8-Р, русский
КОИ8-У КОИ8_У кои8_у КОИ8-У, Украинский
US-ASCII ASCII-код ANSI_X3. 4-1968 cp367 csASCII iso-ir-6 ASCII iso_646.irv:1983 ANSI_X3.4-1986 ascii7 по умолчанию ISO_646.irv:1991 ISO646-US IBM367 646 us Американский стандартный код для обмена информацией
UTF-8 UTF8 Юникод-1-1-utf-8 UTF8 Восьмибитный формат преобразования Unicode (или UCS)
UTF-16 UTF-16 Юникод UTF_16 utf16 UnicodeBig Формат преобразования шестнадцатибитного Unicode (или UCS), порядок байтов определяется необязательным знаком порядка байтов
УТФ-16ВЕ UnicodeBigUnmarked X-UTF-16BE UTF_16BE ISO-10646-UCS-2 UnicodeBigUnmarked Формат преобразования шестнадцатибитного Unicode (или UCS), обратный порядок байтов порядок байтов
УТФ-16ЛЕ UnicodeLittleUnmarked UnicodeLittleUnmarked UTF_16LE X-UTF-16LE Шестнадцатибитный формат преобразования Unicode (или UCS), порядок байтов с прямым порядком байтов
UTF-32 UTF_32 UTF_32 UTF32 32-битный формат преобразования Unicode (или UCS), порядок байтов определяется необязательным знаком порядка байтов
УТФ-32БЕ UTF_32BE X-UTF-32BE UTF_32BE 32-битный формат преобразования Unicode (или UCS), байт с обратным порядком байтов заказ
УТФ-32ЛЕ UTF_32LE X-UTF-32LE UTF_32LE 32-битный формат преобразования Unicode (или UCS), обратный порядок байтов порядок байтов
х-UTF-32BE-BOM UTF_32BE_BOM UTF_32BE_BOM UTF-32BE-BOM 32-битный формат преобразования Unicode (или UCS), байт с обратным порядком байтов порядок, с меткой порядка байтов
х-UTF-32LE-BOM UTF_32LE_BOM UTF_32LE_BOM UTF-32LE-BOM 32-битный формат преобразования Unicode (или UCS), обратный порядок байтов порядок байтов, с отметкой порядка байтов
окна-1250 CP1250 ср1250 сп5346 Windows Восточно-Европейский
окна-1251 CP1251 cp5347 анси-1251 cp1251 Windows Кириллица
окна-1252 CP1252 cp5348 cp1252 Windows Latin-1
окна-1253 CP1253 ср1253 сп5349 Windows греческий
окна-1254 CP1254 ср1254 сп5350 Windows Турецкий
окна-1257 CP1257 ср1257 сп5353 Окна Балтика
Нет в наличии ЮникодБольшой Нет в наличии Формат преобразования шестнадцатибитного Unicode (или UCS), обратный порядок байтов порядок байтов, с отметкой порядка байтов
x-IBM737 CP737 cp737 ibm737 737 ibm-737 ПК Греческий
x-IBM874 СР874 ibm-874 ibm874 874 cp874 Тайский IBM
х-UTF-16LE-BOM UnicodeLittle UnicodeLittle Шестнадцатибитный формат преобразования Unicode (или UCS), порядок байтов с прямым порядком байтов, с меткой порядка байтов
Каноническое имя для java. nio API Каноническое имя для API java.io и API java.lang Псевдоним или Псевдонимы Описание
Большой5 Большой5 csBig5 Big5, традиционный китайский
Big5-HKSCS Big5_HKSCS big5-hkscs big5hk Big5_HKSCS big5hkscs Big5 с гонконгскими расширениями, традиционный китайский (включая редакцию 2001 г.)
EUC-JP EUC_JP csEUCPkdFmtjapanese x-euc-jp eucjis Extended_UNIX_Code_Packed_Format_for_Japanese euc_jp eucjp x-eucjp JISX 0201, 0208 и 0212, кодировка EUC для японского языка
ЕСК-КР EUC_KR ksc5601-1987 csEUCKR ksc5601_1987 ksc5601 5601 euc_kr ksc_5601 ks_c_5601-1987 KS C 5601, кодировка EUC, корейский
ГБ18030 ГБ18030 ГБ18030-2000 Упрощенный китайский, стандарт КНР
ГБ2312 EUC_CN gb2312 euc-cn x-EUC-CN eucn EUC_CN gb2312-80 gb2312-1980 GB2312, кодировка EUC, упрощенный китайский
ГБК ГБК CP936 окна-936 ГБК, упрощенный китайский
IBM-тайский СР838 ibm-838 ibm838 838 cp838 IBM Таиланд расширил SBCS
IBM01140 CP1140 cp1140 1140 cp01140 ebcdic-us-037+евро ccsid01140 Вариант Cp037 с символом евро
IBM01141 CP1141 1141 cp1141 cp01141 ccsid01141 ebcdic-de-273+евро Вариант Cp273 с символом евро
IBM01142 CP1142 1142 cp1142 cp01142 ccsid01142 ebcdic-но-277+евро ebcdic-dk-277+евро Вариант Cp277 с символом евро
IBM01143 CP1143 1143 cp01143 ccsid01143 cp1143 ebcdic-fi-278+евро ebcdic-se-278+евро Вариант Cp278 с символом евро
IBM01144 CP1144 cp01144 ccsid01144 ebcdic-it-280+евро cp1144 1144 Вариант Cp280 с символом евро
IBM01145 CP1145 ccsid01145 ebcdic-es-284+евро 1145 cp1145 cp01145 Вариант Cp284 с символом евро
IBM01146 CP1146 ebcdic-gb-285+евро 1146 cp1146 cp01146 ccsid01146 Вариант Cp285 с символом евро
IBM01147 CP1147 cp1147 1147 cp01147 ccsid01147 ebcdic-fr-277+евро Вариант Cp297 с символом евро
IBM01148 CP1148 cp1148 ebcdic-international-500+евро 1148 cp01148 ccsid01148 Вариант Cp500 с символом евро
IBM01149 CP1149 ebcdic-s-871+евро 1149 cp1149 cp01149 ccsid01149 Вариант Cp871 с символом евро
IBM037 CP037 cp037 ibm037 ibm-037 csIBM037 ebcdic-cp-us ebcdic-cp-ca ebcdic-cp-nl ebcdic-cp-wt 037 cpibm37 cs-ebcdic-cp-wt ibm-37 cs-ebcdic-cp-us cs-ebcdic-cp-ca cs-ebcdic-cp-nl США, Канада (двуязычный, французский), Нидерланды, Португалия, Бразилия, Австралия
IBM1026 CP1026 cp1026 ibm-1026 1026 ibm1026 IBM Latin-5, Турция
IBM1047 СР1047 ибм-1047 1047 cp1047 Набор символов Latin-1 для хостов EBCDIC
IBM273 CP273 ibm-273 ibm273 273 cp273 IBM Австрия, Германия
IBM277 CP277 ibm277 277 cp277 ibm-277 IBM Дания, Норвегия
IBM278 CP278 cp278 278 ibm-278 ebcdic-cp-se csIBM278 ibm278 ebcdic-sv IBM Финляндия, Швеция
IBM280 CP280 ибм280 280 ср280 ибм-280 IBM Италия
IBM284 CP284 csIBM284 ibm-284 cpibm284 ibm284 284 cp284 IBM Каталонский/Испанский, испанский Латинская Америка
IBM285 CP285 csIBM285 cp285 ebcdic-gb ibm-285 cpibm285 ibm285 285 ebcdic-cp-gb IBM Великобритания, Ирландия
IBM290 CP290 ibm290 290 cp290 EBCDIC-JP-кана csIBM290 ibm-290 Японский хост IBM Katakana, расширенный SBCS
IBM297 CP297 297 csIBM297 cp297 ibm297 ibm-297 cpibm297 ebcdic-cp-fr IBM Франция
IBM420 CP420 ibm420 420 cp420 csIBM420 ibm-420 ebcdic-cp-ar1 IBM Арабский
IBM424 CP424 ebcdic-cp-he csIBM424 ibm-424 ibm424 424 cp424 IBM Иврит
IBM500 СР500 ibm-500 ibm500 500 ebcdic-cp-bh ebcdic-cp-ch csIBM500 cp500 EBCDIC 500V1
IBM860 СР860 ibm860 860 cp860 csIBM860 ibm-860 MS-DOS Португальский
IBM861 СР861 cp861 ibm861 861 ibm-861 cp-is csIBM861 MS-DOS Исландский
IBM863 СР863 csIBM863 ibm-863 ibm863 863 cp863 MS-DOS Канада Французский
IBM864 СР864 csIBM864 ibm-864 ibm864 864 cp864 ПК Арабский
IBM865 СР865 ibm-865 csIBM865 cp865 ibm865 865 MS-DOS Nordic
IBM868 СР868 ibm868 868 cp868 csIBM868 ibm-868 cp-ar MS-DOS Пакистан
IBM869 СР869 cp869 ibm869 869 ibm-869 cp-gr csIBM869 IBM Современный греческий
IBM870 СР870 870 cp870 csIBM870 ibm-870 ibm870 ebcdic-cp-roece ebcdic-cp-yu IBM Многоязычная латиница-2
IBM871 СР871 ibm871 871 cp871 ebcdic-cp-is csIBM871 ibm-871 IBM Исландия
IBM918 СР918 918 ibm-918 ebcdic-cp-ar2 cp918 IBM Пакистан (урду)
ИСО-2022-CN ИСО2022КН csISO2022CN ISO2022CN GB2312 и CNS11643 в форме ISO 2022 CN, упрощенная и Традиционный китайский (только преобразование в Unicode)
ИСО-2022-JP ИСО2022ДЖП csjisencoding iso2022jp jis_encoding jis csISO2022JP JIS X 0201, 0208, в форме ISO 2022, японский
ИСО-2022-JP-2 ИСО2022ДЖП2 csISO2022JP2 iso2022jp2 JIS X 0201, 0208, 0212 в форме ISO 2022, японский
ИСО-2022-КР ИСО2022КР csISO2022KR ISO2022KR ISO 2022 КР, корейский
ИСО-8859-3 ИСО8859_3 ISO8859-3 ibm913 8859_3 l3 cp913 ISO_8859-3 iso8859_3 latin3 csISOLatin3 913 ISO_8859-3:1988 ibm-913 iso-ir-109 Латинский алфавит № 3
ИСО-8859-6 ИСО8859_6 ASMO-708 8859_6 iso8859_6 ISO_8859-6 csISOLлатинскийарабский ibm1089 арабский язык ibm-1089 1089 ECMA-114 iso-ir-127 ISO_8859-6:1987 ISO8859-6 cp1089 Латинский/арабский алфавит
ИСО-8859-8 ИСО8859_8 8859_8 ISO_8859-8 ISO_8859-8:1988 cp916 iso-ir-138 ISO8859-8 иврит iso8859_8 ibm-916 csISOLatinИврит 916 ibm916 Латинский/ивритский алфавит
JIS_X0201 JIS_X0201 JIS0201 csHalfWidthKatakana X0201 JIS_X0201 ДЖИС Х 0201
JIS_X0212-1990 JIS_X0212-1990 JIS0212 iso-ir-159 x0212 jis_x0212-1990 csISO159JISX02121990 ДЖИС Х 0212
Shift_JIS СИДЖИС shift_jis x-sjis sjis shift-jis ms_kanji csShiftJIS Shift-JIS, японский
ТИС-620 ТИС620 тис620 тис620. 2533 TIS620, тайский
окна-1255 CP1255 ср1255 Windows Иврит
окна-1256 CP1256 ср1256 Windows Арабский
окна-1258 CP1258 ср1258 Windows вьетнамский
окна-31j МС932 MS932 windows-932 csWindows31J Windows Японский
x-Big5-Solaris Big5_Solaris Big5_Solaris Big5 с семью дополнительными сопоставлениями символов идеографии Hanzi для локали Solaris zh_TW.

No related posts.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *