В Китае через каждые 10 ли меняется говор, через каждые 100 ли – наречие, через каждые 1000 ли – язык.
— отечественный синолог XIX в. проф. В.П.Васильев
Здравствуйте уважаемые читатели «Магазеты». Позвольте мне в сегодняшней статье коснуться информационных аспектов фонологии диалектных произношений китайских иероглифов. Те, кто всё ещё боится таинственных значков международной фонетической транскрипции IPA больше, чем самих ханьцзы – попрошу не пугаться, поскольку постараюсь довести до вас мысль в максимально понятной форме, не требующей специальных знаний.
На подобную идею унификации меня подтолкнуло недавнее изучение базовых основ фонетики шанхайского диалекта, в котором, как мне сперва показалось, гласных звуков было чуть ли не больше чем самих согласных. Также именно для шанхайского диалекта была более всего заметна общая несогласованность транскрипционных систем, т. е. в одной транскрипции, даже c использованием IPA, отдельную фонему выделяют, а в другой системе транскрипции её вообще нет и т. п. Латинская транскрипция используется намного реже для задач записи чтений в том же шанхайском диалекте. Но, всем понятно, что универсальных латинских транскрипций, в которых можно было бы однозначно и без потерь передать чтение для любой диалектной группы, похоже, никому не удастся создать. Вот поэтому то, чтения в Шанхайском диалекте чаще всего представлены сразу в фонетической транскрипции IPA. По сути, создать на основе латиницы транскрипцию, идеально передающую чтение даже в пределах одного диалекта бывает довольно сложно и чревато неоднозначностью. Поэтому, за основу, для наиболее точной передачи любого звучания, необходимо взять нечто более универсальное – конечно же, ещё со школьной скамьи знакомый всем (не-)любителям английского языка международный фонетический алфавит IPA. Поэтому, не старенькая Бопомофо и не специально разработанные латинизированные аналоги Пиньинь, а жёстко стандартизованные, однозначные (но, всё же, пугающие значки алфавита IPA) смогут обеспечить унификацию диалектных чтений в китайском языке!
Вспомним, как сейчас представлены чтения в различных базах иероглифов – CJKLib, Unihan и пр.? Это чаще всего таблица с записанной латинской транскрипцией и численными обозначениями тонов. Конечно, такой способ хранения чтений очень удобен для реализации в IME методов фонетического ввода для любой из диалектных групп. Ведь для этого нужны всего лишь клавиши от A-Z, и цифровые клавиши от 1 до 6 или 9, в зависимости количества тонов в диалекте. Либо вообще возможен бестоновый набор слов и фраз. Поэтому, если в одной латинизированной фонеме из шанхайского диалекта объединились два звука, очень близких по звучанию гласного, то для ввода нескольких иероглифов это, согласитесь, не критично. И только для шанхайского диалекта я недавно увидел действительно грамотное применение значков IPA для транскрипции фонемы и для регистра и контура тонов. Но реализация на клавиатуре самого чисто фонетического ввода с алфавитом IPA – это не совсем простая задача. Ради интереса, если кто-нибудь попытается реализовать ввод значками IPA для самой обыкновенной стандартной Pinyin, то я не думаю, что у многих пользователей скорость ввода от такого «нововведения» останется прежней. Но мы отклонились от темы, теперь нужно перейти от задач фонетического ввода, к задаче хранения и анализа фонетической информации.
А что, если представлять чтения иероглифов не в виде некой текстовой строки, а взять и побитно закодировать инициаль, медиаль, терминаль и контур тона? Например, уложить всё это в 4 байта (32 бита). Во-первых, тогда сразу будет экономия места для хранения в базах данных. Для справки, самая длинная по буквам фонема на Пиньинь – zhuang с тоном в текстовом виде будет занимать 7 байт. А с подходом числового кодирования становится возможным хранение максимально неискажённых данных о чтении на тончайшем уровне внутридиалектных фонетических различий для любого китайского иероглифического знака.
Рассмотрим 32-битовое кодирование одной фонемы подробнее. Здесь, конечно же, здорово помогают фундаментальные правила формирования китайского слога – это жёсткое деление его на три независимые части: инициаль, медиаль и терминаль. Разные авторы ещё и объединяют медиаль и терминаль в финаль.
Инициаль
Мой анализ фонемных рядов транскрипционной записи согласных инициали для различных диалектных групп привел вот к такой таблице. Система классификации согласных в таблице несколько произвольна, но интуитивно понятна.
Таблица 1. Согласные инициали
Итак, инициаль кодируется 7 битами. 3 бита отведены под указатель столбца в таблице согласных, а 4 бита отведены под указатель номера строки в таблице. Как заметно выше, таблица не до конца заполнена (свободно 43/128), и если будет необходимость, то можно, в нарушение вышеприведенной структуры организации таблицы, внести дополнительные согласные. В подсчитанное число вакантных мест в таблице вошли коды с INIT_ROW=0, но с INIT_СOL=(1…7), поскольку эти значения могут быть использованы, как отдельные согласные. А сочетание INIT_СOL=0 и INIT_ROW=0 уже занято в качестве нулевой инициали.
Медиаль
Здесь пришлось собрать в кучу все встреченные в транскрипциях гласные, хотя именно существенный разнобой в записи гласных звуков не даёт пока говорить о полной согласованности фонетической записи чтений алфавитом IPA, используемого различными авторами даже для стандартной Pinyin. Почти все используемые в транскрипции гласные из классификационной трапеции IPA, как раз удачно вписываются в 31 ячейке таблицы. Нулевая медиаль также кодируется нулевым значением MED1=0 и MED2=0. Но есть еще дифтонги и более сложные сочетания гласных. Поэтому необходимо использовать два числа для кодирования гласных звуков, и MED1 кодирует первый в строке транскрипции гласный звук, а MED2 – второй. Если присутствует один гласный звук, то значение присваивается только MED1, а MED2 должен быть равен нулю. Одинаковое значение MED1=MED2 просто удлиняет гласный звук – например [ɛ:]. Также, как резервная информационная ёмкость, может быть использована ситуация с MED1=0 и MED2≠0. Это еще 31 зарезервированное место в таблице гласных, либо для заранее составленных дифтонгов или для дополнительных одиночных гласных. Но для гарантии вводится ещё и модификатор размером в 1 бит. Если модификатор равен 0, то схема образования пары гласных идет обычным вышеописанным способом с резервом в 31 гласную или дифтонг. Если модификатор имеет ненулевое значение, тогда MED1 и MED2 используются для общего 10 битного кодирования расширенных гласных или дифтонгов. И тогда дополнительный резерв кода для медиали достигает 1024 мест. Ниже приведена таблица списка гласных медиали (MED1 или MED2). Порядок обозначений гласных звуков в таблице фонетически не систематизирован и является произвольным.
Таблица 2. Список гласных медиали
Терминаль
Здесь ещё проще, достаточно всего 31 место под символы терминали. В таблице порядок обозначений гласных или согласных звуков также фонетически не систематизирован и является произвольным.
Таблица 3. Список гласных и согласных терминали
Свободными остаются 14/31 мест.
Тональность
Тон, по авторитетному мнению IPA, может быть регистровым (ровный) или ломаным. Для обозначения регистра или контура тона достаточно цифр в регистре верхнего индекса 1,2,3,4,5. Всего контур может проходить максимум по трём точкам – под это понадобятся участки кода TONE1, TONE2, TONE3. Если точек оказывается больше, то предложенное в статье кодирование не уместится в 4 байта (32 бита). Поэтому принимаем, что для ломаного тона необходимы три числа от 1 до 5 (каждое по 3 бита информации), например 3-ий тон путунхуа запишется 214. А для регистрового тона можно использовать 1 или 2 или 3 одинаковых числа, что, кстати, дополнительно позволяет ещё и оперировать длительностью фонемы. По крайне мере, короткие регистровые тоны могут быть записаны одной цифрой. Отсутствие тональности может быть записано как TONE1=0, TONE2=0, TONE3=0. Всего необходимо на запись информации о тональности 9 бит.
Фонетический код (PHONETIC_CODE)
Теперь можно посмотреть, как выглядит целиком 32-битное кодирование для отдельной фонемы.
Таблица 4. Структура фонетического кода
Конечно, информационная ёмкость предложенного структурированного фонетического кода используется не полностью. Для справки, путём обработки таблиц IME для кантонского диалекта я выделил около 2205 отдельных фонем (с тонами, разумеется). В путунхуа где-то около 1400 самостоятельных фонем с тонами. А если вспомнить, что 2^32=4G, то становится очевидно, что недоиспользование 32 битного кода очень существенно. Но структурированность и избыточность как раз и порождают удобство кодирования и декодирования.
Геоинформационное кодирование (GEO_CODE)
Особо внимательный читатель, конечно же, заметил ещё и упоминание о пространственной составляющей кодирования в названии статьи. Да, пора, в буквальном, смысле спуститься с заоблачных абстрактно-теоретических высот на землю. А что, если снабдить каждое чтение в базе данных ещё пространственной информацией – т.е. это будет некий идентификатор местоположения, в котором будут указаны координаты точки, уезда, провинции, в пределах которой зарегистрировано данное чтение для отдельно выбранного ханьцзы. Получается некий интересный метод для решения задач картирования китайской диалектной фонологии в геоинформационных системах. Тогда, можно просто выделив некий иероглиф (конечно же, общеупотребительный) на фонетической карте Китая по нескольку десятков точек пространственно анализировать изменения звучания инициали, финали, структуры тона и т.д. В простейшей базе данных для хранения чтений китайских иероглифов структура записи для хранения фонетической информации выглядит следующим образом:
Таблица 5. Структура записи о фонеме в базе данных
HANZI_ID – идентификатор иероглифа (например номер в таблице UNICODE) (4 байта)
PHONETIC_CODE – представленный выше 32-битный фонетический код иероглифа, (4 байта).
GEO_CODE_ID – идентификатор записи о географическом месте в таблице пространственного положения для точек зарегистрированного чтения, (4 байта).
Теперь можно представить себе и минимальный размер в байтах для такой базы данных. Количество пространственных точек равно в узком смысле количеству всевозможных диалектов внутри основных языковых групп китайского языка. На страничке Википедии про диалекты (http://en.wikipedia.org/wiki/List_of_Chinese_dialects) я, у основных диалектных (языковых) групп, насчитал столько диалектов: Гань, 贛語 (9); Мандарин, 官話 (60); Хуэй, 徽語 (4); Цзинь, 晉語 (6); Хакка, 客家話 (10); Минь, 閩語 (64); У, 吳語 (43); Сян湘語, (23); Кантонский (Юэ) 粵語, (67); Итого 286. С учётом внутридиалектных наречий это число в разы больше. Теперь возьмём максимальное на сегодня число ханьцзы в стандарте Юникод около 75 000 иероглифов (хотя, на самом деле, пока в свободном доступе число иероглифов с китайскими чтениями несколько меньше, для базы Unihan где-то около 27 000 знаков). Длина одной записи (табл.5) для отдельной фонемы в байтах равна 4*3=12 байт. Тогда ориентировочный размер подобной базы данных, без учета внутридиалектных наречий, будет равен 75 000*12*286=245 МБт, что не может не внушать уважение. Да, и это строго при одном чтении на один иероглиф. Т.е. в реальности при учёте наречий этот объем информации может быть в районе значений 1–2 ГБт.
Следующий, уже технический вопрос – порядок выполнения кодирования. С большой долей вероятности можно утверждать, что значительная часть исходных данных будет представлена текстом в разных системах латинской транскрипции в виде таблиц. Прежде всего, для латинской транскрипции внутри каждой диалектной группы необходимо предусмотреть сначала максимально достижимую однозначность схемы романизации и функцию конверсии в промежуточный транскрипционный 32-битный код, в котором предусмотрен простой порядковый номер для используемой в диалекте инициали, медиали, терминали и тона, каждый из которых занимает размер 1 байт. Т.е. заранее необходимо составить таблицы порядкового перечисления всех выделенных из фонем инициалей, медиалей и т.д. Из такого промежуточного кода конверсию в универсальный фонетический код IPA выполнять намного легче. Т. е. пошагово, схема формирования фонетического кода базы чтений внутри каждого диалекта выглядит следующим образом (VBA):
1) CODE = LatTranscriptionToCODE(LatTranscriptionStr as String)
2) UNIVERSAL_IPA_CODE = CODEToUniversalIPACode(CODE as long)
Для функции преобразования строки в промежуточный код LatTranscriptionToCODE также следует отслеживать и варианты, в которых из-за несовершенства латинской транскрипции может потеряться точная информация, особенно об одном из гласных звуков. Зато преобразование в строку символов IPA для строки транскрипции выполняется только одной общей для всех диалектов функцией.
IPA_STRING = UniversalIPACodeToStr(IPA_CODE as Long).
Я резюмирую.
Какие выгоды сулит представленный в статье подход?:
1) Возможность наглядной пространственной визуализации всей фонологии китайских диалектов.
2) Составление обобщающих схем и правил переходов и изменения для всех четырёх компонентов, слагающих китайскую фонему;
3) Простая организация баз данных, в которых хранятся точные диалектные произношения иероглифов, выводимые в международной фонетической транскрипции. Это весьма полезно в задачах обучения произношению всевозможных диалектных групп;
Благодарю за внимание.
