Эта статья требует дополнительных ссылок для проверки . ( июнь 2011 г. ) ( Узнайте, как и когда удалить это сообщение-шаблон ) |
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]
Этот раздел нуждается в расширении . Вы можете помочь, добавив к нему . ( Июнь 2011 г. ) |
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 оставят байты в строке в кавычках без изменений.
См. Также [ править ]
- Буш скрыл факты , текст в кодировке моджибаке
Заметки [ править ]
- ^ Находится под панелью управления, записью «Регион», вкладкой «Администрирование», кнопкой «Изменить языковой стандарт системы».
Ссылки [ править ]
- ^ 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
явно. - ^ «Юникод в Windows API» . Проверено 7 мая 2018 .
- ^ «Соглашения для прототипов функций (Windows)» . MSDN . Проверено 7 мая 2018 .
- ^ «Поддержка многобайтовых наборов символов (MBCS)» . Проверено 15 июня 2020 .
- ^ «Двухбайтовые наборы символов» . MSDN . 2018-05-31 . Проверено 15 июня 2020 .
наши приложения используют кодовые страницы DBCS Windows с "A" версиями функций Windows.
- ^ _strrev, _wcsrev, _mbsrev, _mbsrev_l Microsoft Docs
- ^ «Различия между реализациями TAPI в Windows CE и Windows NT» . MSDN . Проверено 7 мая 2018 .
Windows CE основана на Unicode.
Возможно, вам придется перекомпилировать исходный код, написанный для приложения на базе Windows NT.
- ^ «Кодовые страницы (Windows CE 5.0)» . Документы Microsoft . Проверено 7 мая 2018 .
- ^ «Идентификаторы кодовой страницы (Windows)» . msdn.microsoft.com .
- ^ «Windows10 Insider Preview Build 17035 поддерживает UTF-8 как ANSI» . Хакерские новости . Проверено 7 мая 2018 .
- ^ Форумы MSDN
- ^ «UTF-8 в Windows» . Переполнение стека . Проверено 1 июля 2011 года .
- ^ "Boost.Nowide" .
- ^ "Увеличить список рассылки" .
- ^ UTF-8 Everywhere FAQ: Как мне написать строковый литерал UTF-8 в моем коде C ++?
Внешние ссылки [ править ]
- «Юникод» . MSDN . Microsoft . Проверено 10 ноября 2016 года .