Метка: китайские программы и софт

Здравствуйте уважаемые читатели «Магазеты». Наверное, каждый из вас помнит момент, когда он впервые увидел китайский (корейский, японский) IME (Input Method Editor – Редактор метода ввода). После этого волновавший многих извечный вопрос: «А сколько же клавиш на китайской клавиатуре?», в принципе, отпадал сам собой. У меня это было где-то в 1998 г., когда я изучал одну китайскую обучающую программку для DOS, называлась она KongZi. Потом, постепенно стали  доступны Microsoft Simplified (Traditional) Chinese IME98 и т.п. Собственно, на этом можно было бы и закончить эту статью, но…

В конце 90-х – начале 2000-х я сталкивался со следующей проблемой. В Win2000 часто из разных дистрибутивных CD-дисков (сами понимаете, какого они «благородного» происхождения были в те годы) предельно жестко вырезались все установочные файлы поддержки иероглифической письменности языков Восточной Азии. «Да кому они вообще нужны в русской версии Win2000?» – в принципе довольно справедливое утверждение-вопрос. А занимали эти файлы довольно много места, особенно качественно хинтованные азиатские шрифты Batang, MingLiU и другие, ведь, «лишние» 50 МБ – это было довольно ощутимо для CD тех лет. В итоге, куда ни ткнись, на компьютерах (кроме, разумеется, моего домашнего PC), просто не было возможности установить в систему редакторы ввода китайского, японского и корейского языков. Меня это, мягко говоря, выводило из себя. И вот я не выдержал…

С VBA-макросами в MS Word я быстро научился работать ещё в 1999 г. Это были самые обычные вещи: то «самую русскую» букву — «ё» — надо было в тексте заменить на «е», то  результат печатания транслитом или результаты набора текста без переключения английской раскладки нужно было как то привести в кириллически-читабельный вид и др. вполне приземленные функции. После того, как я впервые увидел ввод иероглифов через IME в MS Windows 98, я подумал: «А почему бы и нет?», — ведь достаточно одной формы, текстового поля ввода, десяти кнопок и подписей к ним, чтобы сделать простейший IME на VBA-макросах.  Да, в системе они не будут работать, но в открытом документе приложения Microsoft Word — пожалуйста.

Специфика ввода китайского текста в MS Word VBA всегда предполагает внешние таблицы двоичных или строковых данных. Т.е. реализовать такой ввод исключительно внутри VBA-кода макросов — невозможно, слишком много информации. Поэтому необходимо использование файлов внешних данных (таблиц). Подобные таблицы можно грубо разделить на два типа:

1. таблицы для фонетических методов ввода (PinYin, ZhuYin…);
2. таблицы для структурных методов ввода (CangJie, DaYi…).

Для фонетических методов простейшей структурой здесь являются две связанные таблицы данных: таблица фонем и линейный список иероглифов (двухбайтовых символов). Таблица фонем состоит из двух полей: самой строки фонемы (для путунхуа пиньинь – это не более 8 однобайтовых символов строки фонемы с указанием тона) и указателя (4 байта). А таблица иероглифов состоит из последовательности двухбайтовых символов, на которые ссылаются указатели, заданные в таблице фонем.

Первая таблица PHONEME_TABLE

• Phoneme_Str   (8 B)  –  строка фонемы (null-terminated представление строки)
• HZ_List_Pointer  (4 B)  –  указатель на линейный список иероглифов

Все фонемы отсортированы в таблице по алфавиту.

Вторая  таблица HZ_LIST —

это просто линейный список всех юникодовских индексов иероглифов, на которые ссылаются указатели из таблицы фонем.

|HZ_List_Pointer1->HZ1,HZ2,HZ3,HZ4….|HZ_List_Pointer2->HZ5,HZ6,HZ7,HZ8….|HZ_List_Pointer3->HZ9,HZ10,HZ11…|

Указатели определяют каждый раз короткий список иероглифов, принадлежащих одной фонеме.

Алгоритм фонетического ввода:

1. Набор текста фонемы в обычной латинской раскладке с фокусом ввода в текстовом окне VBA-формы MS Word;
2. Ввод или генерация признака окончания ввода фонемы (у каждого метода он свой). Например, это может быть ввод последней цифры от 1 до 5 (тон), что действительно означает гарантированное окончание процесса ввода фонемы в текстовом окне;

1. Начинается поиск фонемы в таблице фонем PHONEME_TABLE;
2. Фонема найдена, определяются её указатель на список из иероглифов HZ_LIST, и такой же указатель от следующей по порядку фонемы в таблице PHONEME_TABLE. Это нужно для того, чтобы знать количество иероглифов в предлагаемом списке выбора;
3. Выборка иероглифов и создание списка выбора. От первого указателя до второго найденного указателя, из таблицы HZ_LIST происходит копирование иероглифов в промежуточный массив;
4. Отображение списка выбора. Переключение формы в режим выбора иероглифа, когда действующими будут только нажатия клавиш 0,1, 2…9, а также клавиши для осуществления прокрутки списка выбора;
5. Нужный иероглиф нажатием одной из клавиш 0,1, 2…9 вводится в текст открытого документа MS Word;

Для таблиц структурных методов ввода простейшим по способу организации является следующий тип данных. Для этого необходима одна таблица STRUCT_CODE:

Code_String (5 B) — у большинства структурных методов ввода длина кодирующей строки редко превосходит 5 байт (null-terminated представление строки).

Code_HZ (2 B) – Юникод-индекс иероглифа, который соответствует кодирующей строке Code_String.

Алгоритм структурного ввода:

1. Ввод текстовой строки в виде простых однобайтовых символов, но желательно с  отображением вводимого в виде иероглифических символов той или иной системы ввода. Т.е. в машинной памяти обычная строка ABC, а в текстовом поле путём простого перекодирования знаков, в случае, например, метода Цанцзе, будет  срока из иероглифов: «день», «луна», «металл».
2. Обнаружение признака завершения ввода кодировочной строки. Либо пробел — принудительное окончание ввода, либо превышение или равенство числа знаков в строке четырём или пяти символам (макс. длина строки). Максимальная длина строки — это один из важнейших параметров любого структурного метода ввода иероглифов. Кстати, у структурных методов вообще можно не ждать признака окончания ввода, а постоянно «на лету» генерировать список выбора иероглифов.
3. Поиск кодировочной строки во всех строках таблицы STRUCT_CODE.
4. Выборка каждого иероглифа, у которого все строки полностью тождественны введённой строке по длине и символам. Либо другой критерий отбора — начальная часть символов в строках, хранимых в таблице STRUCT_CODE  может быть тождественна введённой строке. В таком случае список выбора будет содержать намного большее число знаков. Это два разных типа создания списка выбора в структурных методах, каждый из которых по-своему удобен при вводе.
5. Вывод списка выбора. Переключение формы в режим выбора иероглифа, когда действующими будут только нажатия клавиш 0,1, 2…9, а также клавиши для осуществления прокрутки списка выбора;
6. Найденный иероглиф нажатием одной из клавиш 0,1, 2…9 вводится в текст открытого документа MS Word;

По организации хранения данных и программной реализации структурные методы ввода китайских иероглифов немного проще, чем фонетические методы.

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

Вторым в описываемой эпопее было японское направление реализации ввода. У меня уже имелась простая тестовая таблица следующего типа:

Hira_String (var length) – двухбайтовые строки хираганы;

KanJi_String (var length) – соответствующие им строки кандзи либо кандзи+хирагана.

Методов ввода сразу можно было легко реализовать два: ромадзи и клавиатурная хирагана, разумеется, с возможностью переключения на катакану. Так получился простой и удобный японский IME на VBA макросах. Можно было печатать: хираганой, хираганой с возможностью включения выбора списка кандзи, а также  катаканой.

Следующим по порядку было «взято» корейское направление. Здесь я начал с реализации простой стандартной корейской раскладки знаков хангыля. Реализация ввода существенно отличалась от принципов китайского и японского IME. С добавлением очередной буквы хангыль джамо изменяется скрытая строка ввода VBA-формы IME, затем в поле текста документа у постоянно выделенного одного корейского символа соответственно добавляется новый «крючочек». Когда строка ввода становится более  5 символов – букв хангыль джамо, то изменение корейской фонемы прекращается, и курсор переходит на следующую позицию в строке текстового документа для формирования нового символа. Следует отметить, что ввод всех 11072 символов хангыля для фонем корейского языка  вообще не требует каких-либо таблиц. Однако в корейском языке из предлагаемых Юникодом 11 тыс. знаков используется менее половины. Отсюда, в соответствии с правилами хорошего тона, я  вынужден был добавить таблицу, отсекающую ненужные знаки, которые не включены в стандарт KSC. Корейская стандартная раскладка, конечно же, продумана и удобна, но некорейцу всё таки удобнее будет ввод латинской раскладкой, в которой, кстати, размывается привычная для нас жесткость парадигмы «звонкий-глухой» (Вводи KIM или GIM – всё равно получишь김). Год назад, в рамках ревизии проекта, я всё же добавил ввод хангыля через латинскую романизацию. Получилось очень удобно и органично, по крайней мере, для новичков. Уже имея на входе фонему хангыля, через аналогичную фонетическую таблицу, легко можно было реализовать и ввод через список выбора ханджа, т.е. иероглифов. Это реализовано с помощью двух связанных таблиц:

Первая таблица HG_TABLE

• HG_Str   (2 B)  –  фонема хангыля;
• HJ_List_Pointer  (4 B)  –  указатель на последовательный список иероглифов

Все фонемы отсортированы в таблице по алфавиту.

Вторая таблица HJ_LIST — полный аналог HZ_LIST (см. выше).

Последним было вьетнамское направление ввода. Мною на тех же VBA-макросах давно уже были реализованы два типа ввода букв вьетнамского алфавита по системам VIQR и VNI. Оставалось лишь «прикрутить» возможность ввода иероглифов тьы-ном из списка выбора. Это иероглифы, которые в нынешнее время для вьетнамского языка актуальны только с исторических позиций.

A вот сейчас читателю самое время сказать: «Ну а зачем же ты всё это сделал, паренёк? Ведь это уже давно реализовано в виде разнообразнейших системных IME». Да, действительно, «портирование» IME на VBA-макросы в MS Word выглядит совсем ненужным и избыточным, если бы не одно но…

Имеющиеся стандартные (системные) IME позволяют лишь вводить азиатские знаки всевозможными методами, но не позволяют выполнять текстовые преобразования с иероглифическими символами, которые бывают очень часто необходимы пользователю. Это уже прерогатива не программы-IME, а приложения более высокого уровня – текстового процессора. Именно поэтому совместная реализация концепции «Ввод + Работа с текстом» в рамках VBA-макросов на базе документов MS Word оказалась весьма удачной. Простейшая концепция действий текстового преобразования: «Выдели часть текста + Нажми кнопку» выглядит весьма заманчивой для органичного объединения возможностей IME с простыми функциями текстового процессора. Мгновенное осознание этого факта придало мне новых сил не бросать проект и развивать его далее.

Какие же текстовые «фичи» можно придумать для работы с китайским иероглифическим и не только иероглифическим текстом? Грубо такие функции можно разделить на две категории: иероглифические и фонетические (транскрипционные). Начну излагать с более простых — иероглифических текстовых функций.

В 2000 г. я начал с самых простых функций текстового преобразования. Первое, что мне понадобилось — это преобразование FanTi<->JianTi. Нужно было выбрать пары иероглифов «Упрощённый-Традиционный» и создать простейшую бинарную таблицу. Идея оказалась весьма плодотворной. Далее я смог реализовать без каких-либо таблиц преобразование HanZi->BuShouZi (ключевой знак). Вообще, ключевое деление заложено в саму сортировку Юникода для основного и расширенных наборов CJK-иероглифов. Достаточно было вручную просмотреть коды пограничных знаков в ключах и функция преобразования HZtoBuSHouZi(HZ as String) as String была готова. Правда есть иероглифы с так называемыми трудноопределимыми или спорными ключами – тут тогда необходима только табличная реализация, как говорится, «персональная работа с каждым знаком». Т.е. для каждого «трудного» ханьцзы можно предусмотреть несколько полей в новой бинарной таблице для записи номера различных ключей, под которыми он проходит в разных иероглифических словарях. Сейчас, благодаря разнообразным свободным CJKV-базам, реализовать такие расширенные функции преобразования иероглиф -> ключ стало не проблемой. Из иероглифических функций я ещё могу отметить следующие: преобразование HZ->CangJie ABCString, преобразование HZ->Variants (Compatible, Special, Simpl, Trad). В перспективе, у меня намечено выделение вообще отдельного блока макросов под новые иероглифические текстовые преобразования:

• Иероглиф -> Декомпозиция на два знака (澇->氵[LR]勞);
• Иероглиф -> Не ключевой элемент (澇->勞);
• Иероглиф -> Количество строк общее и присоединённое к ключу (澇->15(12));
• Иероглиф -> Множество ключевых графем (澇->[水火冖力]).

Особенно мне сложно и тяжело одному реализовать таблицы декомпозиции. Над этим я работаю уже более года с перерывами.

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

Другой тип функций — «фонетический», они также востребованы сегодня. Общеизвестно, что для китайских диалектов, каких только транскрипций не существует! Единая унификация и создание функций взаимного преобразования из одной транскрипционной схемы в другую в рамках одного диалекта — это очень благородная задача. Вот примерный перечень, той малой части потенциально возможных функций, что я сумел реализовать:

• PinYin -> Palladius
• PinYin -> ZhuYin
• PinYin -> HanYu PinYin (tone marks)
• PinYin -> IPA
• PinYin -> IPA
• ZhuYin -> PinYin

Но это были перечислены функции, работающие по принципу «транскрипция <-> транскрипция». Естественно, что для максимальной полноценности и удобства преобразования, необходимо добавить хотя бы одну функцию преобразования «иероглиф -> транскрипция». Для минимизации возможных направлений преобразования необходимо придерживаться концепции «центральной» транскрипционной системы, так же как английский язык зачастую является «ядром» в многоязыковых системах-переводчиках.

Сейчас, в рамках подобной концепции, я уже реализовал наборы текстовых функций фонетических преобразований для путунхуа и кантонского. В перспективе планируется отделение фонетической части в отдельный блок макросов, по причине банальной нехватки места на панелях под кнопки всевозможных функций. Т.е. кнопки будут сгруппированы по пунктам меню на панелях. Каждый пункт меню будет посвящён отдельной диалектной группе. Для каждой диалектной группы обязательно должна быть хотя бы одна функция преобразования «иероглиф -> транскрипция», причём транскрипционная система должна быть максимально удобной и «центральной» для других преобразований типа  «иероглиф -> транскрипция». Примеры таких «центральных» и надёжных систем: PinYin (v вместо ü) – для путунхуа и JyutPing – для кантонского диалекта, с  указанием номера тона цифрами.

Фонетические текстовые преобразования для японской системы ввода имеют свою специфику. Первое – это простота романизации хираганы и катаканы: «кана <-> ромадзи». Второе – это простота взаимных преобразований «хирагана <-> катакана». Но в противовес простоте каны, имеется самый сложный для реализации момент — это преобразование «кандзи -> хирагана». Здесь нужны грамматические таблицы и анализ соседних символов в контексте. Такую функцию в одиночку и без знания японского языка одному любителю реализовать просто нереально. Из иероглифических функций текстовых преобразований, помимо общих с китайскими функциями, я бы выделил новый тип преобразования — «кокудзи, рякудзи <-> кандзи». Т.е. преобразуем иероглифы чисто японского начертания в иероглифы классического китайского начертания. С чем связана такая необходимость? Иногда встречаются уникальные китайские статьи, переведённые с японского. В них иероглифы, в составе топонимов или других слов, могут быть либо изменены на китайские, либо наоборот оставлены без преобразования японскими. Для точного и гарантированного перевода термина очень принципиально строгое соблюдение кода Юникод для каждого азиатского знака. С применением определённых национально-ориентированных кодировок (GB, BIG5, JIS) на веб-страницах, такая проблема автоматически устраняется. Однако, если при создании странички была применена универсальная кодировка UTF-8 или UTF-16, то японские и китайские иероглифы, без должного «надзора», могут пойти друг с другом вперемешку в переведённых текстах обоих направлений «Яп <-> Кит».

Преобразования текста для корейского письма также имеют свою уникальную специфику. Без каких-либо таблиц можно реализовывать функции перевода HG -> HanGul JaMo. Т.е. фонема хангыля «рассыпается» на составные символы корейских букв (김->ㄱㅣㅁ). Также возможно преобразование  Hanja -> Hangul, которое часто бывает реализовано во многих серьёзных редакторах работы с текстом. Это потребует одой таблицы. Ну и обязательными для некорейцев являются фонетические функции текстового преобразования в транскрипционную систему Концевича и другие системы романизации. Наиболее простыми здесь будут функции преобразования изолированного знака корейской фонемы (김->KIM). При таком преобразовании нет нужды в анализе инициалей и финалей соседних символов в контексте. Хотя, я планирую усовершенствовать и это, чтобы на выходе текстового преобразования «хангыль -> романизация» всё же появилась полноценная стандартная транскрипция корейских знаков на латинице или кириллице.

Вьетнамское текстовое преобразование имеет свои особенности. Наверное, не очень многие знают, что ранее для вьетнамского каких только кодировок не существовало, и все они с чудовищными усилиями, практически на грани фола умудрялись умещаться в однобайтовую кодировку (VISCII). Отсюда, такие преобразования, как «VISCII <-> Unicode» будут весьма полезными. Есть другое востребованное направление преобразования, такое как «VIQR -> VietText». Все эти «неудобные» вещи были порождены в доюникодовскую эпоху, а создание перекодировочных схем и функций существенно облегчит работу перевода текстов из старых кодировок в единую унифицирующую кодировку Юникод. Также, всем будет полезна уже выполненная мною реализация функции «ТьыНом -> Вьетнамский текст». Ну и уж совсем для любителей древности можно будет попробовать реализацию функций работы с чамским письмом, но это уже точно выходит за рамки современных CJKV-стандартов.

В общем, я заканчиваю это своё затянувшееся повествование. Вот ссылка на установочный файл и на архив со шрифтами.

http://rusfolder.ru/33514448 — Установщик файлов

http://rusfolder.ru/33514450 — Архив шрифтов

Наличие именно этих шрифтов некритично, просто размеры текстовых окон оптимально настроены на работы именно с этими азиатскими шрифтами. Файлы *.dot макросов и все остальные дополнительные двоичные файлы устанавливаются в папку по жёстко прописанному пути C:\CJKV_VBA\…

После окончания установки, войдите в MS Word и измените параметры безопасности при работе с макросами до минимального уровня. После чего, запустите любой из *.dot файлов, находящихся в папке C:\CJKV_VBA\… При желании, эти макросы можно будет скопировать в папку автозагрузки вашего MS Word. После чего макросы станут доступными всегда при открытии любого документа MS Word.

Надеюсь, что вам понравится.

WERTA, 2012/11/08