Существует ли кодовая страница, совпадающая с ASCII и позволяющая сделать двустороннюю конвертацию в Unicode?

Это перевод Is there a code page that matches ASCII and can round trip arbitrary bytes through Unicode? Автор: Реймонд Чен.

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

Конвертируем между LCID и кодами языков RFC 1766

Это перевод Converting between LCIDs and RFC 1766 language codes. Автор: Реймонд Чен.

Время от времени я вижу, как кто-то спрашивает функцию, которая конвертирует LCID (это такие штуки вроде $0409 для English-US) в языковые идентификаторы RFC 1766 (а это - "en-us") и наоборот. Ну, тут есть простое правило: если то, о чём вы спрашиваете, - это языковая штука, которая требуется web-браузеру, то вам нужно начать поиски с библиотеки MLang. В нашем случае нас будет интересовать метод IMultiLanguage.GetRfc1766FromLcid.

UTF-8 всё ещё не является вариантом по умолчанию в Блокноте

Это перевод UTF-8 default isn't in the latest Notepad, either. Автор: Майкл Каплан.

Да, это правда: часто я начинаю посты с "простых вопросов", которые в итоге имеют сложные ответы.

А когда ответы просты, то они оказываются простыми в плохом смысле: вроде слова НЕТ.

И это один из таких постов...

The game is over, people!

Это перевод The game is over, people! Автор: Майкл Каплан.

Блокнот добавляет BOM (Byte Order Mark), когда вы сохраняете файл в кодировке UTF-8.

Всегда¹.

Если вы подумаете, что Блокнот Windows делал это на протяжении 319680000 секунд², и что общее время использования Windows 2000³, Windows XP, Windows Server 2003, Windows XP 64-bit, Vista, Windows Server 2008, Windows 7 и Windows Server 2008 R2 настолько велико, что взорвёт вам мозг, если вы попробуете его сосчитать - то можно подумать, что люди уже научились с этим жить.

Но нет.

Почему вообще Shell-скрипты UNIX в UTF-8 создают или редактируют в Блокноте Windows?

Это перевод Why are UTF-8 encoded Unix shell scripts *ever* written or edited in Notepad? Автор: Майкл Каплан.

Все ненавидят Microsoft.

Ну, не совсем все.

Но ругание Microsoft кажется весьма популярным занятием...

unicodeFFFE... Microsoft рехнулась?

Это перевод unicodeFFFE... is Microsoft off its rocker? Автор: Майкл Каплан.

Это вопрос, который был открыт какое-то время.

Тогда в феврале (боже, я действительно писал в блог целый год?) я объяснил разницу между Big Endian и Little Endian Unicode. В январе я также говорил про Byte Order Mark.

Но этот пост не про это.

Этот пост - про Preferred Charset Label для web-страниц, которые кодируются в Big Endian Unicode (или 'Unicode (Big Endian)', как любит называть его Блокнот).

Это на самом деле unicodeFFFE.

У каждого символа есть история №4: U+feff

Это перевод Every character has a story #4: U+feff (alternate title: UTF-8 is the BOM, dude!). Автор: Майкл Каплан.

U+feff работает на двух работах в стандарте Unicode.

Почему кодовая страница OEM часто называется ANSI?

Это перевод Why is the OEM code page often called ANSI? Автор: Реймонд Чен.

Denis Bider указал, что документация к программе cmd.exe говорит:

/A - приводит к тому, что вывод от внутренних команд в канал или файл будет происходить в ANSI

даже хотя вывод будет вообще-то в OEM. Почему существует такая и подобные ошибки?

Потому что иногда ANSI означает OEM.

Как [то, что вызывают] общие элементы управления, конвертирует строки между ANSI и Unicode?

Это перевод How do[es what] the common controls [call ]convert between ANSI and Unicode? Автор: Майкл Каплан.

Ранее Реймонд Чен писал о том, Как общие элементы управления конвертируют строки между ANSI и Unicode?, отвечая на вопрос в его suggestion box:

В контексте ansi (не unicode) приложения: как общие элементы управления (к примеру, listview) решают, какую использовать кодовую страницу для перевода многобайтовых строк в widestring?

Мне пришлось отлаживать ansi приложение, которое показывало испорченные строки на системе с традиционным китайским, потому что шрифт диалога привёл к тому, что listview использовал иную кодовую страницу, нежели системную ACP, при переводи multibyte в widechar.

Хотя я редко, если вообще когда-нибудь, не соглашусь с чем-то, что исходит из лагеря команды Оболочки, конкретно в этом случае я знаю два конкретных исключения из правила CP_ACP, которое вы обычно видите, хотя эти отличия могут иметь мало общего с кодом Shell / comctl32, так что Реймонд может быть прав в своей области :-)

Что это за волшебная настройка, которая синтезирует Unicode из не-Unicode?

Это перевод What is this magic setting that synthesizes Unicode from non-Unicode? Автор: Реймонд Чен.

Комментатор dan g. спросил как Windows может обращаться с не-Unicode приложениями как с Unicode приложениями через апплет Региональные и языковые настройки Панели управления (перевод поста), особенно в части, которая даёт вам выбрать язык для не-Unicode программ. "Я всегда считал, что единственным способом показывать, скажем, китайские символы будет компиляция программы в Unicode, но эта настройка, кажется, намного проще".

Почему CP_ACP не может быть UTF-8?

Это перевод Why can't the CP_ACP be UTF-8? Автор: Майкл Каплан.

Bart van der Werf спросил:

Я работаю над приложением с 8-битовыми строками, которое работает с несколькими языками. И я был удивлён, узнав, что ACP (кодовая страница ANSI) не может принять utf8 как допустимую MBCS кодировку.

Почему так? Разве это не позволило бы всевозможным старым приложениям как-то стать многоязычными за одну ночь?

Может ли CP_ACP быть UTF-8?

Это перевод Can the CP_ACP be UTF-8? Автор: Майкл Каплан.

Только что Сергей спросил в Suggestion Box:

Привет, Майкл!

Разве не было бы здорово, если бы можно было установить UTF-8 в качестве мультибайтовой кодовой страницы в Windows? Что ты думаешь?

Ну, да, я думаю, что это было бы здорово :-)

Может ли кодовая страница меняться? Как насчёт кодовой страницы, на которую указывает локаль?

Это перевод Can a codepage be changed? How about which codepage a locale points to? Автор: Майкл Каплан.

Ранее сегодня я рассмотрел вопрос, можно ли добавлять символы в Unicode, но Иван Петров также спрашивал, можно ли изменить кодовую страницу 1251, поскольку в ней пропущено 20 кирилических символов.

К сожалению, с этим ничего нельзя сделать по нескольким причинам.

За Нормановским "Кому нужен этот Unicode?"

Это перевод Behind Norman's 'Who needs Unicode?' post. Автор: Майкл Каплан.

Постоянный участник Norman Diamond в своём обычном очаровательном стиле создал в microsoft.public.win32.programmer.international и microsoft.public.word.international такую тему:

На моём жёстком диске есть файл, путь к которому, вероятно, будет обрезан Outlook Express:

C:\Program Files\Windows CE Tools\wce500\Windows Mobile 5.0 Smartphone SDK\Samples\CPP\Win32\Mapirule\readme.txt

Среди полезных кусочков информации было найдено следующее:

> Client痴 transport (SMS, ActiveSync, POP3) arrives.

и:

> where <clsid> represents the COM object痴 class ID GUID

Это заслуживает награды за самоописание. Производитель таких вещей как ОС для смартфонов Windows Mobile 5.0, SDK для той же платформы и компиляторов снова для неё же, просто знал, что им не обязательно нужно использовать Unicode в документах, потому что кодовая страница ANSI прекрасно донесёт их сообщение. Кодовая страница ANSI, конечно же, - так, что используется Блокнотом на настольных системах Windows вроде XP, и по умолчанию равна кодовой странице 932. Слово 痴 вообще-то описывает процесс, который приводит к отображению слова 痴.

Можно задуматься, не мог бы производитель тонн документации по Unicode научиться пользоваться Блокнотом, чтобы он сохранял .txt файл в кодировке Unicode, так что документация могла бы предоставлять информацию, используя другие символы, нежели 痴. Определённая компания, которая известна своим 痴, могла бы иметь способность научить их. Но определённая компания, известная своим 痴, может не захотеть учиться у них.

Он умеет использовать слова (см. строку со спонсором этого поста - 痴 (U+75f4), если вы не знаете значения 痴 и хотите понять юмор Нормана!).

Здесь важно подняться над словами, чтобы увидеть о чём мы тут говорим :-)

Ничто не пахнет хуже локали потока, чем кодовая страница потока

Это перевод Nothing stinks worse than the thread locale, other than the thread code page. Автор: Майкл Каплан.

Вот кусок из письма, которое я получил от Ken:

Привет, Майкл.

Я встретился с чем-то, что, как я считаю, является багом в MultibyteToWideChar и WideCharToMultibyte, когда параметр кодовой страницы устанавливается в CP_THREAD_ACP, 'язык по-умолчанию для не-Unicode приложений' - установленный в иврит. Это видно, когда используется вспомогательный макрос из atlconv.h вроде T2WC.

Я создал простое тестовое приложение, которое показывает неожиданные результаты на некоторых системах. Кодовая страница от CP_THREAD_ACP получается не той же самой, что GetACP. Я воспроизвёл это на двух системах с ивритом, но не на системах, где стоит традиционный китайский - одна из которым имеет полностью локализированный в традиционном китайском UI. Исходник является частью консольного проекта .NET 2003 по умолчанию.

#include "stdafx.h"
#include <ostream>
int _tmain(int argc, _TCHAR* argv[])
{
    std::cout << "default code page is " << GetACP() << std::endl;
    std::cout << "_AtlGetConversionACP code page is " << ATL::_AtlGetConversionACP() << std::endl;

    CPINFOEX cpinfo = {};
    GetCPInfoEx(ATL::_AtlGetConversionACP(), 0, &cpinfo);

    std::cout << "Thread code page is " << cpinfo.CodePage << std::endl;
    return 0;
}

Мои результаты:

default code page is 1255
_AtlGetConversionACP code page is 3
Thread code page is 1252

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

Спасибо за потраченное на меня время,
Ken

Постоянные читатели могут вспомнить, почему я не люблю локаль потока.

(Фактически, меня не так давно попросили помочь вычистить несколько плохих случаев использования локали потока в различных частях Windows в shell32.dll и shlwapi.dll - наверное, скоро я за это засяду!)

CP_ACP против GetACP

Это перевод CP_ACP vs. GetACP. Автор: Майкл Каплан.

Несколько дней назад PEK спросил в newsgroups насчёт WideCharToMultiByte и MultiByteToWideChar:

Я несколько смущён первым параметром в MultiBytToWideChar. Он говорит какую использовать кодовую страницу. Вы можете использовать значение CP_ACP ("кодовая страница ANSI"), но что оно означает? Это значение, возвращаемое GetACP или это просто кодовая страница 1252?

Я хочу знать, одинаковые ли результаты дают вызовы:

MultiByteToWideChar(CP_ACP, ...)

и:

MultiByteToWideChar(GetACP, ...)

Ответ: они действительно действуют одинаково. Первый способ - это константа, которая говорит: "меня не волнует, какая сейчас у системы кодовая страница - просто используй её". А второй способ сначала спрашивает "какая у системы кодовая страница по умолчанию?".

Естественный вопрос: почему есть два способа добиться одного и того же. И какой из них будет быстрее - кэширование GetACP, либо передача CP_ACP?

За "Как сломать Блокнот"

Это перевод Behind 'How to break Windows Notepad'. Автор: Майкл Каплан.

Ларри Остерман указал мне на статью, названную "Как сломать Блокнот Windows", которая проводит такой эксперимент:

Вот как это сделать:

1. Откройте Блокнот (не Wordpad, не Word и не любой другой текстовый редактор)
2. Впечатайте в точности это предложение (без кавычек): "this app can break" (перевод: "это приложение может сломаться").
3. Сохраните файл.
4. Закройте Блокнот.
5. Откройте сохранённый файл двойным щелчком.

Вместо вашего предложения вы увидите набор квадратиков. По какой-то причине Блокнот не может понять что делать с этой последовательностью символов и ломается.

Регулярный мусор в тексте может быть неверной кодовой страницей

Это перевод Consistent garbage text can be incorrect encoding identification (or detection). Автор: Майкл Каплан.

Mushy спросил в Suggestion Box:

Майкл,

Быть может у тебя есть старый пост, который объясняет следующую ситуацию. Если да - то ткни меня в него. Вот в чём проблема. Если ты посмотришь на мой блог, то увидишь как некоторые символы кавычек показываются как ’ вместо ". Когда я сначала публикую материал, их там нет. Как от них избавиться? Вызвано ли это использованием форматов Word, .doc, .txt, .rtf? Что лучше подходит?

P.S. Мне понравился твой блог и я занёс его в закладки.

Thanks,
Mushy

(Для тех, кто заинтересовался, блог Mushy - это Cross+Hairs)

Некоторые люди могут быть знакомы с байтовыми последовательностями; если вы с ними знакомы, то вы - гик :-)

Ещё один налог для отсутствия поддержки Unicode?

Это перевод Yet another cost to not supporting Unicode? Автор: Майкл Каплан.

Очень трудно печатать, когда у тебя растяжение плеча. Слава богу, есть Dragon Dictate! Это я просто так...

Alex спросил меня в Suggestion Box:

Привет, Майкл.

Я погуглил по твоему блогу, но не нашёл ответа на такой вопрос. Этот вопрос довольно популярен (по крайней мере, в России), и я был удивлён, что ты его ещё не покрыл. Так что, быть может, ты расскажешь историю за этим вопросом. Это вопрос про буфер обмена, текст и не Unicode приложения.

Возьми старое не Unicode приложение (вроде блокнота из Win9x) и запусти его на новых Windows (вроде XP), которая имеет два установленных языка (скажем, английский и русский). Предположим, что "Язык для не Unicode приложений" установлен в "Русский".

В Win9x ты мог без проблем скопировать текст через буфер обмена из любого приложения в любое другое. Конечно, старые приложения не заботились об установке CF_LOCALE вместе с CF_TEXT, но всё работало довольно прилично, поскольку приложениями использовалась одна и та же кодовая страница (ладно: почти всеми).

Теперь, возьми современную, "юникодную" ОС, вроде XP. Ты берёшь своё старое приложение, которое верой и правдой служило тебе много лет, копируешь текст в буфер и вставляешь в другое приложение (скажем, блокнот из Windows XP) и... ух ты: ты получаешь вопросительные знаки или белиберду. Что не так? Чёрт, ты забыл переключить клавиатуру на "Русский". Как только ты это сделаешь - всё начнёт работать нормально.

Верхний ряд: слева - блокнот из Win98, справа - блокнот из XP. Нижний ряд: слева - блокнот из XP, справа - из Win98. Текущий язык стоит в "English (United states)" (ну, т.е. мы не переключили на русский). Красные линии указывают операцию копирования текста через буфер обмена (я специально взял два приложения от Microsoft, чтобы указать, что это не баг в каком-то конректном стороннем приложении).

Проблема (как я её вижу) заключается в получении Unicode-текста из ANSI-текста. Почему Windows использует для этого метод ввода, а не "Язык для не Unicode приложений"?

Это ужасное нарушение в опыте использования. Большинство людей считают, что это баг. Я очень часто слышу эту жалобу (чёрт, да я слышу проклятия Microsoft почти всегда в таких случаях). Особенно тяжело объяснить, что это не баг в твоём приложении, написанном много лет назад - оно не виновато.

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

Это звучит очень знакомо.

Иногда, когда вы говорите "исправление разрабатывается", вы именно это и имеете в виду

Это перевод Sometimes when you say 'the fix is in' you mean it in a good way. Автор: Майкл Каплан.

Всего несколько дней назад я говорил про особенно неприятный баг в Windows Vista.