*Другая* работа LCMapString

Это перевод LCMapString's *other* job. Автор: Майкл Каплан.

Для меня NLS API функция LCMapString делает постоянную работу, которая является критичной для фундамента Windows - генерацию ключей сортировки. Я знаю, что это критично, потому что когда я случайно напутаю в таблицах, то находятся компоненты, которые не дадут Windows запуститься, опасаясь порчи информации!

Очевидно, что порядок важен. А поэтому равно важна и способность создавать индексы. Вы знаете, не случайно этот блог называется Sorting It All Out (прим.пер.: букв. - "сортируем всё это", "раскладываем всё по полочкам"). Хранить данные в одном и том же порядке, не важно, насколько они сложны (так что вы сможете как-то разобраться с ними) - это чрезвычайно важная операция, которая является центром нашей работы (для меня). И это не только работа по интернационализации - если мы облажаемся с такой простой вещью, то как мы вообще можем надеяться достигнуть чего-то большего?

Однако, равно как и художнику иногда нужно обслуживать людей за столиками в ресторане, чтобы оплатить плату за комнату, так и LCMapString пришлось делать дополнительную работу :-)

(Ладно, я знаю, что это полностью ревизионистской способ смотреть на вещи, и я знаю, что на самом деле всё немного не так. Но для меня это более удобная точка зрения на вещи, как и модель Бора для атома. Я собираюсь использовать "не совсем точную" модель, так как это удобный способ смотреть на вещи!)

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

Я сделал подсказку на некоторые из вещей в своём предыдущем посте, но теперь я собираюсь разобраться с ними раз и навсегда.

В качестве примечания: Джули Беннетт однажды сказала мне, что раньше она думала, что эта функция является хаком. Не потому, что функция не была полезна, а потому что она делала слишком много всего сразу. Ей бы быть несколькими отдельными функциями. Я думаю, что это опасность принятия на себя слишком много вторичных работ - никто не знает, чем и где вы сейчас занимаетесь!

Итак, вот дополнительные флаги функции и их значение:

LCMAP_BYTEREV - очень удобное преобразование, не важно используется ли оно само по себе или с другими опциями - оно обращает порядок байтов в каждом слове (в смысле битового размера) строки. Как указано в справке, к примеру, если вы передадите #$3450 #$4822, то результат будет #$5034 #$2248. Хорошая, честная подработка для нашей девочки!

LCMAP_FULLWIDTH - конвертирует каждый символ половинной ширины в полноширинный (все прочие символы не изменяются). Так, ﾎ (U+ff8e a.k.a. HALFWIDTH KATAKANA LETTER HO) станет ホ (U+30db a.k.a. KATAKANA LETTER HO). В старой японской кодовой странице полноширинные символы занимали в два раза больше места (полуширинные символы находились в "верхней" ANSI - больше $7f, но меньше $ff, в то время как полноширинные символы занимали два байта). По соглашению полноширинные символы также имеют вдвое большую визуальную ширину - и, согласно мнению некоторых людей, менее привлекательный вид. В Unicode, очевидно, оба варианта занимают два байта, но они по-прежнему отличаются визуально - так что типографская традиция продолжается. Это уже не вопрос устаревшей кодовой страницы, а настоящая разница с точки зрения типографии.

LCMAP_HALFWIDTH - конвертирует каждый символ полной ширины в полуширинный (все прочие символы не изменяются). Так, ワ (U+30ef a.k.a. KATAKANA LETTER WA) становится ﾜ (U+ff9c a.k.a. HALFWIDTH KATAKANA LETTER WA). См. предыдущий пункт с LCMAP_FULLWIDTH для обсуждения разницы между ними.

LCMAP_HIRAGANA - конвертирует каждый символ катаканы в эквивалентный символ хираганы (все прочие символы не изменяются). Так, ヅ (U+30c5 a.k.a. KATAKANA LETTER DU) становится づ (U+3065 a.k.a. HIRAGANA LETTER DU). Буквальное значение хираганы - "гладкая кана". Разница между хираганой и катаканой лежит за пределом темы этого поста, но у нас есть интересная статья Википедии, которая рассказывает об этом, а также включает в себя поэму Iroha-uta ("Песнь цветов"). Эта поэма датируется 10-м веком и использует каждый символ хираганы всего один раз (и доказывает мне, что хирагана гораздо лучше подходит для таких целей, чем "Съешь же ещё этих мягких французских булок, да выпей чаю" или "The quick brown fox jumps over the lazy dog"!):

いろはにほへと	Iro ha nihohe to	Even if colours have sweet perfume
ちにぬるを	chirinuru wo	eventually they fade away
わかよたれそ	wakayo tare so	What in this world
つねならむ	tsune naramu	is eternal?
うゐのおくやま	uwi no okuyama	The deep montains of vanity
けふこえて	kefu koete	I cross them today
あさきゆめみし	asaki yume mishi	renouncing the superficial dreeams
ゑひもせすね	wehi mo sesu ne	not giving in to their madness any more

Прим. пер.: я не рискнул это переводить.

LCMAP_KATAKANA - конвертирует каждый символ хираганы в эквивалентный символ катаканы (все прочие символы не изменяются). Так, ま (U+307e a.k.a. HIRAGANA LETTER MA) становится マ (U+30de a.k.a. KATAKANA LETTER MA). Буквальное значение катаканы - "частичная кана". И снова, разница между хираганой и катаканой - не тема этого поста, но у нас снова есть статья в Википедии. Статья упоминает одно важное отличие в использовании обоих алфавитов:

Катакана произносится немного иначе, чем хирагана. В хирагане для обозначения долгих гласных производится добавлением второй гласной каны, а катакана использует отметку удлинения гласной. Этот знак является короткой линией вдоль направления текста (горизонтальной для горизонтального текста и вертикальной в вертикальном тексте).

Ни поддержка катаканы, ни хираганы в Windows не покрывают эту особенность, хотя было бы здорово её когда-нибудь реализовать, как какое-нибудь расширение к "лингвистическому приведению регистра", о котором я ещё поговорю. Интересная идея для новой фишки :-)

LCMAP_UPPERCASE - проецирует символы нижнего регистра в символы верхнего регистра, оставляя прочие символы неизменными. Так, ç (U+00e7, a.k.a. LATIN SMALL LETTER C WITH CEDILLA) становится Ç (U+00c7 a.k.a. LATIN CAPITAL LETTER C WITH CEDILLA). Это поведение меняется при одновременном указании флага LCMAP_LINGUISTIC_CASING, который включает в работу новые сценарии, которые я обсудил ранее, и которые играют фундаментальную роль во всех регистровых операциях, кроме локали "C" и некоторых функций вроде CharUpper, которыми, хотя я технически не владею этими функциями, на самом деле я ими владею (ну, разве выделение - это не здорово? <grin>). Заметьте, что никто из таких оболочек не использует флаг LCMAP_LINGUISTIC_CASING, что означает, что если только они не вызывают LCMapStringA, они абсолютно не зависят от локали. И любые утверждения иначе в документации - это баг, который находится в длинном и долгом процессе исправления. Последнее слово, что я хотел сказать о верхнем регистре, это - грузинский.

LCMAP_LOWERCASE - проецирует символы верхнего регистра в символы нижнего регистра, оставляя прочие символы неизменными. Так, Ħ (U+0126, a.k.a. LATIN CAPITAL LETTER H WITH STROKE) становится ħ (U+0127, a.k.a. LATIN SMALL LETTER H WITH STROKE). Это поведение меняется при одновременном указании флага LCMAP_LINGUISTIC_CASING, который включает в работу новые сценарии, которые я обсудил ранее, и которые играют фундаментальную роль во всех регистровых операциях, кроме локали "C" и некоторых функций вроде CharLower, которыми, хотя я технически не владею этими функциями, на самом деле я ими владею (ну, разве выделение - это не здорово? <grin>). Заметьте, что никто из таких оболочек не использует флаг LCMAP_LINGUISTIC_CASING, что означает, что если только они не вызывают LCMapStringA, они абсолютно не зависят от локали. И любые утверждения иначе в документации - это баг, который находится в длинном и долгом процессе исправления. Последнее слово, что я хотел сказать о нижнем регистре, это - сигма.

LCMAP_SIMPLIFIED_CHINESE - проецирует символы традиционного китайского на упрощённый китайский, не изменяя остальные символы. Так, 樂 (U+6a02) становится 乐 (U+4e50). Словарь этого преобразования достаточно мал (только 2'620 иероглифов) и не обновлялся с тех самых пор, когда его добавили в NT 4.0 (он был добавлен по просьбе ребят из команды Office, но они в итоге остановились на использовании своего собственного решения, которое и работает лучше и использует больше правил. Хотя изменение регистра, ширины и каны могут быть выполнены на месте, то это невозможно для преобразования традиционный -> упрощённый китайский - даже хотя это ограничение (неизменность длины строки) применимо и здесь. Если кто-то из NLS тестеров захочет отправить это как баг - я подумаю, как это можно будет исправить!

LCMAP_TRADITIONAL_CHINESE - проецирует символы упрощённого китайского на традиционный китайский, не изменяя остальные символы. Так, 儈 (U+5108) становится 侩 (U+4fa9). Словарь этого преобразования ещё меньше (только 2'191 иероглиф) - поскольку несколько разных символом традиционного китайского проецируются в один символ упрощённого китайского, так что это и предыдущее преобразование не являются 100% обратными друг к другу. Словарь не обновлялся с тех самых пор, когда его добавили, плюс тут есть та же проблема с размером строки. Если кто-то из NLS тестеров захочет отправить это как баг - я помечу это как дубликат предыдущего бага!

OK, на сегодня это, наверное, всё. Не забудьте дать функции на чай!

This post brought you by "ﾎホワﾜヅづまマçÇĦħ樂乐儈侩" (U+ff8e U+30db U+30ef U+ff9c U+30c5 U+3065 U+307e U+30de U+00e7 U+00c7 U+0126 U+0127 U+6a02 U+4e50 U+5108 U+4fa9 a.k.a. HALFWIDTH KATAKANA LETTER HO, KATAKANA LETTER HO, KATAKANA LETTER WA, HALFWIDTH KATAKANA LETTER WA, KATAKANA LETTER DU, HIRAGANA LETTER DU, HIRAGANA LETTER MA, KATAKANA LETTER MA, LATIN SMALL LETTER C WITH CEDILLA, LATIN CAPITAL LETTER C WITH CEDILLA, LATIN CAPITAL LETTER H WITH STROKE, LATIN SMALL LETTER H WITH STROKE, HAPPY, HAPPY, BROKER, BROKER)
(Группа символов, которые были счастливы продемонстрировать технологии LCMapString!)