За Нормановским "Кому нужен этот 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), если вы не знаете значения 痴 и хотите понять юмор Нормана!).

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

Те, кто читал За "Как сломать Блокнот", могут увидеть подсказку на то, что здесь происходит - мы снова видим одну из этих проблем "неверно понятые байты в файле". Хотя в этом случае это не ANSI файл, принятый за Unicode; это ANSI файл в одной кодовой странице, просматриваемый на машине с другой CP_ACP...

Я должен признать, что рассчитывать на что-то настолько ненадёжное и изменчивое как системная кодовая страница в readme файле для примера, выглядит очень глупо.

Если вы сконвертируете 痴 в кодовую страницу 932, то вы получите $9273, что, будучи рассматриваемо в кодовой странице 1252, было бы ’s - клитика, используемая в английском, чтобы указать притяжательный падеж. Итого, оригинальные строки должны быть:

> Client’s transport (SMS, ActiveSync, POP3) arrives.

и:

> where <clsid> represents the COM object’s class ID GUID

где ’s - это $92 и $73, что становится U+2019 и U+0073 через кодовую страницу 1252.

Это потому что Microsoft Word обычно берёт ' (U+0027) и автозаменяет её на ’ (U+2019).

Ни одна клавиатура Microsoft не вносит U+2019 в файл, так что проблема выглядит так, что файл был в какой-то момент отредактирован в Word. То, что это превратилось в 痴, действительно ирония, которая помогла Норману указать на ироничный баг и помогла мне с хорошей историей из списка Unicode Lame List :-)

This post brought to you by 痴 (U+75f4, a.k.a. Unicode Han Character 'foolish, stupid, dumb, silly')
Иероглиф CJK, означающий "глупый"!