Двойное тайное ANSI, часть 1 (где-то на полпути от ANSI к Unicode)

Это перевод Double Secret ANSI, part 1 (Somewhere between ANSI and Unicode). Автор: Майкл Каплан.

Любой, кто читает меня регулярно, знает, что я всегда предпочитаю увидеть, что приложение работает с Unicode.

Но, очевидно, в мире есть приложения, которые не поддерживают Unicode. По крайней мере сегодня.

Некоторые из этих приложений существовали уже какое-то время и они работают с ANSI довольно хорошо.

И некоторые их них даже поддерживают ANSI великолепно - вплоть до уровня "двойное тайное ANSI".

(Кстати, эти приложения не должны растягивать свои запястья, чтобы погладить сами себя по спине (и похвалить самих себя) - потому что для более чем 40% локалей, поставляемых с Vista, эти приложения не менее великолепно покажут пользователю часть или даже весь их текст, переведенный в знаки вопроса - диалект, который никто не знает настолько хорошо, чтобы читать на нём!)

Но, увы, я отвлекся.

Я собирался объяснить, что я имел ввиду, когда говорил, что приложение поддерживает двойное тайное ANSI.

Давайте на минутку подумаем о Windows 95/98/Me.

В них было много Unicode - от интерфейсов Оболочки (Shell), шрифтов и многих внутренностей GDI. Но всё испортили ANSI-интерфейсы. И, чтобы посыпать соль на рану, вы даже не можете изменить локаль системы по умолчанию (default system locale), "язык для не-Unicode программ", как он стал известен позже.

Тогда почему у Windows Me был список локалей для более чем 100 языков, многие из которых использовали совершенно не пересекающиеся кодовые страницы?

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

Как Windows Me могла поддерживать список локалей из 100 с лишним языков, многие из которых использовали совершенно не пересекающиеся кодовые страницы?

Давайте разделим вопрос на части и начнём с простой части, вроде клавиатурных раскладок. Как en-US версия Windows Me поддерживала русскую клавиатурную раскладку?

(Не забывайте, что этот же ответ будет применим и к не-Unicode приложениям, работающим на NT-версиях Windows!)

Оказывается, что клавиатурным раскладкам в не-Unicode приложении дан способ проявить себя - используя кодовую страницу системы по-умолчанию (default system code page) от LANGID, который получается из значения KLID клавиатурной раскладки (не из её значения HKL!).

Большинство приложений не обращают никакого внимания на эту информацию, и забирают к себе либо испорченный текст, либо вопросительные знаки.

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

Вы можете отображать текст, используя TextOutW/ExtTextOutW, вы можете конвертировать его в Unicode или хранить текст вместе с кодовой страницей. Вы можете положить его в буфер обмена и пристыковать к нему тэг CF_LOCALE, так что другие будут знать, в какой кодовой странице он находится. Вы можете вызвать API функции NLS с правильным LCID, чтобы получить данные для использования и управлять текстом через эту кодовую страницу. Вы можете положить текст в e-mail и отправить его кому-то ещё. И так далее.

Это ещё не Unicode, но такие действия дадут вам возможность поддерживать больше языков, чем покрывается кодовой страницей системы по-умолчанию на вашей машине.

Как я уже сказал, большинство людей не заморачиваются этой ерундой. И это те приложения, которые не являются приложениями с поддержкой двойного скрытого ANSI.

This post brought to you by A (U+0041, LATIN CAPITAL LETTER A)