Почему UTF-8 не разрешен в качестве кодовой страницы "ANSI"? - PullRequest
18 голосов
/ 08 июня 2010

Функция Windows _setmbcp позволяет использовать любую допустимую кодовую страницу ...

(кроме UTF-7 и UTF-8, которые не являются поддерживается)

ОК, не поддерживает UTF-7, имеет смысл: символы имеют неуникальные представления, что создает риски сложности и безопасности.

Но почему не UTF-8?

Насколько я понимаю, версии API-функций Windows ANSI преобразуют свои аргументы в UTF-16, вызывают эквивалентную функцию "W" и преобразуют любые строки в выводе в "ANSI". Это то, что я делал вручную. Так почему Windows не может сделать это для меня?

Ответы [ 3 ]

9 голосов
/ 08 июня 2010

Кодовая страница "ANSI" в основном устаревшая: эпоха Windows 9X. В любом случае, все современное программное обеспечение должно быть на основе Unicode (то есть UTF-16).

По сути, когда исходная кодовая страница Ansi была разработана, UTF-8 даже не был изобретен, и поэтому поддержка многобайтовых кодировок была довольно случайной (то есть большинство кодовых страниц Ansi являются однобайтовыми, за исключением некоторых восточных Азиатские кодовые страницы, которые являются одним или двумя байтами). Добавление поддержки «правильных» многобайтовых кодировок, вероятно, считалось не стоящим усилий, когда все новые разработки должны быть выполнены в UTF-16 в любом случае.

5 голосов
/ 22 июля 2010

_setmbcp() - это функция RTL VC ++, а не функция Win32 API. Это влияет только на то, как RTL интерпретирует строки. Это никак не влияет на функции Win32 API A. При внутреннем вызове своих коллег W функции A всегда используют MultiByteToWideChar() и WideCharToMultiByte(), указав кодовую страницу 0 (CP_ACP), чтобы использовать системную кодовую страницу Ansi по умолчанию для преобразований.

4 голосов
/ 03 февраля 2014

Майкл Каплан, эксперт по интернационализации из Microsoft, попытался ответить на этот вопрос в своем блоге .

По сути, его объяснение состоит в том, что, хотя версии функций API Windows «ANSI» предназначены для обработки разных кодовых страниц, исторически существовало неявное ожидание, что кодирование символов будет требовать не более двух байтов на кодовую точку. UTF-8 не соответствует этим ожиданиям, и изменение всех этих функций сейчас потребует огромного количества испытаний.

...