Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Microsoft была одной из первых компаний, внедривших Unicode в свои продукты. Windows NT была первой операционной системой, которая использовала «широкие символы» в системных вызовах . Использование UCS-2 схемы кодирования во - первых, он был повышен до UTF-16 , начиная с Windows 2000 , позволяя представление дополнительных плоскостей с суррогатных пар. Тем не менее Microsoft не поддерживала UTF-8 до 2017 года. В мае 2019 года Microsoft изменила курс и начала рекомендовать использование исключительно UTF-8. [1]

В различных семействах Windows [ править ]

Системы на базе Windows NT [ править ]

Текущие версии Windows, а также все предыдущие версии Windows XP и Windows NT (3.x, 4.0) поставляются с системными библиотеками, которые поддерживают кодировку строк двух типов: 16-битный «Unicode» ( UTF-16 начиная с Windows 2000 ) и ( иногда многобайтовая) кодировка называется « кодовой страницей » (или неправильно именуется кодовой страницей ANSI ). 16-битные функции имеют имена с суффиксом «W» (от «широкий» ), например SetWindowTextW. Функции, ориентированные на кодовую страницу, используют суффикс 'A' для ANSI, например SetWindowTextA(некоторые другие соглашения использовались для API, которые были скопированы из других систем,такие как _wfopen/fopenилиwcslen/strlen). Это разделение было необходимо, потому что многие языки, включая C , не обеспечивали чистый способ передачи 8-битных и 16-битных строк в одну и ту же функцию.

Функции «A» реализованы как оболочки, которые переводят текст с использованием текущей кодовой страницы в UTF-16, а затем вызывают соответствующие функции «W». [ необходима цитата ] Функции 'A', возвращающие строки, выполняют противоположное преобразование, превращая символы, которые не существуют в текущем языковом стандарте, в '?'.

Microsoft попыталась поддерживать Unicode «переносимо», предоставив компилятору переключатель «UNICODE», который переключает нефиксированные «общие» вызовы с интерфейса «A» на интерфейс «W» и преобразует все строковые константы в «широкие» версии UTF-16. . [2] [3] На самом деле это не работает, потому что он не переводит UTF-8 за пределы строковых констант, в результате код, который пытается открывать файлы, просто не компилируется. [ необходима цитата ]

Ранее, независимо от переключателя «UNICODE», Windows также предоставляла переключатель API многобайтовых наборов символов (MBCS). [4] Это изменяет некоторые функции, которые не работают в MBCS, например, на функции, strrevподдерживающие MBCS, такие как _mbsrev. [5] [6]

В документации Microsoft термин «Unicode» используется для обозначения «не 8-битной кодировки». [ необходима цитата ]

Windows CE [ править ]

В Windows CE UTF-16 использовался почти исключительно, а API A в основном отсутствовал. [7] Ограниченный набор ANSI API доступен в Windows CE 5.0 для использования в сокращенном наборе локалей, которые могут быть выборочно встроены в образ среды выполнения. [8]

Windows 9x [ править ]

В 2001 году Microsoft выпустила специальное дополнение к старым системам Microsoft Windows 9x . Он включает библиотеку динамической компоновки unicows.dll (всего 240 КБ), содержащую 16-битную версию (те, которые имеют букву W в конце) всех основных функций Windows API. Это просто уровень перевода: SetWindowTextWпросто преобразует его ввод, используя текущую кодовую страницу, и вызовет SetWindowTextA.

UTF-8 [ править ]

В Microsoft Windows есть кодовая страница, предназначенная для UTF-8 , кодовая страница 65001. [9] До Windows 10 Insider build 17035 (ноябрь 2017 г.) [10] было невозможно установить кодовую страницу локали на 65001, оставив эту кодовую страницу доступно только для (а) явных функций преобразования, таких как MultiByteToWideChar и / или (б) консольной команды Win32chcp 65001 для преобразования stdin / out между UTF-8 и UTF-16. Это означает, что "узкие" функции, в частности fopen(которые открывают файлы), не могут быть вызваны со строками UTF-8, и фактически нет возможности открыть все возможные файлы, используяfopenнезависимо от того, какой языковой стандарт установлен и / или какие байты помещены в строку, поскольку ни один из доступных языковых стандартов не может воспроизводить все возможные символы UTF-16. Эта проблема также относится ко всем другим API-интерфейсам, которые принимают или возвращают 8-битные строки, включая такие API Windows, как SetWindowText.

Microsoft заявила, что локаль UTF-8 может нарушить некоторые функции, поскольку они были написаны с учетом того, что многобайтовые кодировки используют не более 2 байтов на символ, поэтому кодовые страницы с большим количеством байтов, такие как UTF-8 (а также GB 18030 , cp54936), не могут быть установленным как локаль. [11]

На всех современных платформах, отличных от Windows, передаваемая строка имени файла fopenфактически имеет формат UTF-8. Это приводит к несовместимости между другими платформами и Windows. Обычный обходной путь - добавить специфичный для Windows код для преобразования UTF-8 в UTF-16 с помощью MultiByteToWideChar и вызвать функцию «wide» вместо fopen. [12] Другой популярный обходной путь - преобразование имени в эквивалент имени файла 8.3 , это необходимо, если fopenфункция находится внутри библиотечной функции, которая принимает строковое имя файла, и, таким образом, вызов другой функции невозможен. Также были предложения добавить новые API в переносимые библиотеки, такие как Boost.сделать необходимое преобразование, добавив новые функции для открытия и переименования файлов. Эти функции будут передавать имена файлов без изменений в Unix, но переводить их в UTF-16 в Windows. Такая библиотека, Boost.Nowide, [13] была принята в Boost [14] и станет частью выпуска 1.73. [ требуется обновление ] Это позволит коду быть «переносимым», но потребует столько же изменений кода, сколько и вызов широких функций.

В апреле 2018 года с инсайдерской сборкой 17035 (номинальная сборка 17134) для Windows 10 появился флажок «Бета: использовать Unicode UTF-8 для всемирной языковой поддержки» для установки кодовой страницы локали в UTF-8. [a] Это позволяет вызывать "узкие" функции, включая fopenи SetWindowTextA, со строками UTF-8. В мае 2019 года Microsoft добавила в программу возможность устанавливать кодовую страницу для самой UTF-8 и начала рекомендовать, чтобы все программы делали это и использовали исключительно UTF-8. [1]

Платформы программирования [ править ]

Компиляторы Microsoft часто не могут создавать строковые константы UTF-8 из исходных файлов UTF-8. Самый надежный метод - отключить UNICODE, не отмечать входной файл как UTF-8 (т. Е. Не использовать спецификацию ) и упорядочить строковые константы так, чтобы они имели байты UTF-8. Если была добавлена ​​спецификация, компилятор Microsoft интерпретирует строки как UTF-8, преобразует их в UTF-16, а затем преобразует их обратно в текущую локаль, тем самым уничтожая UTF-8. [15] Без спецификации и с использованием однобайтовой локали компиляторы Microsoft оставят байты в строке в кавычках без изменений.

См. Также [ править ]

  • Буш скрыл факты , текст в кодировке моджибаке

Заметки [ править ]

  1. ^ Находится под панелью управления, записью «Регион», вкладкой «Администрирование», кнопкой «Изменить языковой стандарт системы».

Ссылки [ править ]

  1. ^ a b «Используйте кодовую страницу Windows UTF-8 - приложения UWP» . docs.microsoft.com . Проверено 6 июня 2020 . Начиная с версии Windows 1903 (обновление за май 2019 г.), вы можете использовать свойство ActiveCodePage в appxmanifest для упакованных приложений или манифест слияния для распакованных приложений, чтобы заставить процесс использовать UTF-8 в качестве кодовой страницы процесса. [..] CP_ACPсоответствует CP_UTF8только при работе в Windows версии 1903 (обновление за май 2019 г.) или выше, а для свойства ActiveCodePage, описанного выше, задано значение UTF-8. В противном случае учитывается устаревшая системная кодовая страница. Мы рекомендуем использовать CP_UTF8явно.
  2. ^ «Юникод в Windows API» . Проверено 7 мая 2018 .
  3. ^ «Соглашения для прототипов функций (Windows)» . MSDN . Проверено 7 мая 2018 .
  4. ^ «Поддержка многобайтовых наборов символов (MBCS)» . Проверено 15 июня 2020 .
  5. ^ «Двухбайтовые наборы символов» . MSDN . 2018-05-31 . Проверено 15 июня 2020 . наши приложения используют кодовые страницы DBCS Windows с "A" версиями функций Windows.
  6. ^ _strrev, _wcsrev, _mbsrev, _mbsrev_l Microsoft Docs
  7. ^ «Различия между реализациями TAPI в Windows CE и Windows NT» . MSDN . Проверено 7 мая 2018 . Windows CE основана на Unicode. Возможно, вам придется перекомпилировать исходный код, написанный для приложения на базе Windows NT.
  8. ^ «Кодовые страницы (Windows CE 5.0)» . Документы Microsoft . Проверено 7 мая 2018 .
  9. ^ «Идентификаторы кодовой страницы (Windows)» . msdn.microsoft.com .
  10. ^ «Windows10 Insider Preview Build 17035 поддерживает UTF-8 как ANSI» . Хакерские новости . Проверено 7 мая 2018 .
  11. ^ Форумы MSDN
  12. ^ «UTF-8 в Windows» . Переполнение стека . Проверено 1 июля 2011 года .
  13. ^ "Boost.Nowide" .
  14. ^ "Увеличить список рассылки" .
  15. ^ UTF-8 Everywhere FAQ: Как мне написать строковый литерал UTF-8 в моем коде C ++?

Внешние ссылки [ править ]

  • «Юникод» . MSDN . Microsoft . Проверено 10 ноября 2016 года .