Введение

Попытка сопоставления символов CJK в Unicode — это усилия авторов Unicode и Universal Character Set по объединению множества наборов символов, использующих иероглифы хань в так называемых языках CJK, в единый унифицированный набор символов. Иероглифы хань являются общей чертой письменных китайского (ханьцзы), японского (кандзи), корейского (ханджа) и вьетнамского (чу хан) языков. Современные китайские, японские и корейские шрифты обычно используют региональные или исторические варианты конкретного иероглифа хань. При разработке Unicode была предпринята попытка унифицировать эти варианты, рассматривая их как аллографы – различные графические формы, представляющие одну и ту же "графему" или орфографическую единицу, отсюда и термин "унификация хань", а полученный набор символов иногда сокращенно называют Unihan. Тем не менее, для многих символов существуют региональные варианты, которым присвоены разные кодовые точки, например, традиционный 個 (U+500B) и упрощенный 个 (U+4E2A).

Графемы против глифов

Графема — это наименьшая абстрактная единица значения в системе письма. Любая графема имеет множество возможных графических выражений (глифов), но все они распознаются как одна и та же графема теми, кто умеет читать и писать на данной системе письма. Хотя Юникод обычно сопоставляет символы кодовым точкам для представления графем в системе письма, стандарт Юникода (раздел 3.4 D7) предостерегает: абстрактный символ не обязательно соответствует тому, что пользователь понимает под «символом», и его не следует путать с графемой. |source= The Unicode® Standard Version 15.0 – Core Specification §3.4 Characters and Encoding

Однако эта цитата указывает на то, что некоторые графемы состоят из нескольких графических элементов или «символов». Например, символ в сочетании с (образуя комбинацию "å") может восприниматься пользователем как единая графема, хотя и состоит из нескольких абстрактных символов Юникода. Кроме того, Юникод присваивает кодовые точки небольшому числу (исключая причины совместимости) символов форматирования, пробельных символов и других абстрактных символов, которые не являются графемами, а используются для управления разрывами между строками, словами, графемами и кластерами графем. В случае с унифицированными иероглифами хань стандарт Юникода отходит от прежней практики, присваивая абстрактные символы не как графемы, а в соответствии с базовым значением графемы — тем, что лингвисты иногда называют семемами. Этот отход, следовательно, не объясняется просто часто цитируемым различием между абстрактным символом и глифом, а скорее коренится в различии между абстрактным символом, присвоенным как графема, и абстрактным символом, присвоенным как семема. В отличие от этого, рассмотрим унификацию пунктуации и диакритических знаков в ASCII, где графемы с совершенно разными значениями (например, апостроф и одинарная кавычка) объединяются, поскольку глифы идентичны. Для Юнихана символы объединяются не по внешнему виду, а по определению или значению. Если графема представлена различными глифами, это означает, что у графемы есть вариации глифов, которые обычно определяются выбором одного или другого шрифта или использованием функций замены глифов, когда несколько глифов включены в один шрифт. Юникод рассматривает такие вариации глифов как особенность протоколов с богатым текстом и не соответствующую целям Юникода в области простого текста. Однако, когда изменение с одного глифа на другой представляет собой изменение с одной графемы на другую — когда глиф больше не может означать ту же графему, понимаемую как строчная буква «a», — Юникод разделяет их на отдельные кодовые точки. Для Юнихана то же самое делается всякий раз, когда изменяется абстрактное значение, однако вместо того, чтобы говорить об абстрактном значении графемы (буквы «a»), объединение иероглифов хань присваивает новую кодовую точку для каждого различного значения, даже если это значение выражено различными графемами на разных языках. Хотя графема, такая как «ö», может означать что-то другое во французском языке (как используется в слове Noël), чем в немецком языке (как используется в слове Österreich), это все равно одна и та же графема, и ее можно легко унифицировать, чтобы английский и немецкий языки могли использовать общую абстрактную латинскую систему письма (наряду с самой латынью). Этот пример также указывает на другую причину, по которой «абстрактный символ» и графема как абстрактная единица в письменном языке не обязательно соответствуют друг другу один к одному. В английском языке сочетание диакритического знака «¨» и модифицируемого им «o» может рассматриваться как две отдельные графемы, в то время как в таких языках, как шведский, буква «ö» может рассматриваться как одна графема. Аналогично, в английском языке точка над «i» понимается как часть графемы «i», в то время как в других языках, таких как турецкий, точка может рассматриваться как отдельная графема, добавленная к букве «ı» без точки. Для решения проблемы использования различных графем для одного и того же семемы Юнихана Юникод использовал несколько механизмов, особенно в отношении рендеринга текста. Один из них — рассматривать это просто как проблему шрифта, чтобы разные шрифты можно было использовать для рендеринга китайского, японского или корейского текста. Кроме того, форматы шрифтов, такие как OpenType, позволяют отображать альтернативные глифы в соответствии с языком, чтобы система рендеринга текста могла обратиться к настройкам среды пользователя, чтобы определить, какой глиф использовать. Проблема этих подходов заключается в том, что они не соответствуют целям Юникода по определению согласованного способа кодирования многоязычного текста. Поэтому, вместо того чтобы рассматривать эту проблему как проблему богатого текста с альтернативными глифами, Юникод добавил концепцию селекторов вариаций, впервые представленную в версии 3.2 и дополненную в версии 4.0. Хотя селекторы вариаций рассматриваются как объединяющие символы, они не имеют связанных диакритических знаков или отметок. Вместо этого, объединяясь с базовым символом, они сигнализируют, что двухсимвольная последовательность выбирает вариацию (обычно в терминах графемы, но также и в терминах базового значения, как в случае названия места или другого собственного имени) базового символа. Это, следовательно, не выбор альтернативного глифа, а выбор вариации графемы или вариации базового абстрактного символа. Однако такую двухсимвольную последовательность можно легко сопоставить с отдельным глифом в современных шрифтах. Поскольку Юникод присвоил 256 отдельных селекторов вариаций, он может присвоить 256 вариаций для любого иероглифа хань. Такие вариации могут быть специфичными для того или иного языка и позволяют кодировать простой текст, включающий такие вариации графем.

Юнихан "абстрактные символы"

Поскольку стандарт Unihan кодирует «абстрактные символы», а не «глифы», графические артефакты, создаваемые Unicode, рассматривались как временные технические препятствия и, в лучшем случае, косметические. Однако, вновь, особенно в Японии, отчасти из-за того, как китайские иероглифы были включены в японские системы письма исторически, невозможность указать конкретный вариант считалась существенным препятствием для использования Unicode в научных исследованиях. Например, унификация «травы» (описанная выше) означает, что исторический текст нельзя закодировать так, чтобы сохранить его своеобразную орфографию. Вместо этого, например, исследователю потребовалось бы найти желаемый глиф в определенном шрифте, чтобы передать текст в исходном виде, что противоречит цели унифицированного набора символов. Unicode отреагировал на эти потребности, назначив селекторы вариантов, чтобы авторы могли выбирать варианты графем конкретных идеограмм (или даже других символов), но не включил представителей правительств Восточной Азии. Изначальной целью разработки было создание 16-битного стандарта, и унификация хань была, следовательно, критическим шагом для предотвращения десятков тысяч дублирований символов. Это требование 16-битной кодировки позже было отменено, что сделало размер набора символов менее актуальным сегодня. Споры позже распространились на международно-представительную ISO: первоначальная Совместная исследовательская группа CJK (CJK JRG) поддержала предложение (DIS 10646) о не унифицированном наборе символов, «которое было отклонено в пользу унификации с унифицированным набором символов Консорциума Unicode голосами американских и европейских членов ISO» (даже несмотря на то, что японская позиция оставалась неясной). Поддержка унификации Han в Unicode была необходимым шагом для завершения слияния ISO 10646 и Unicode. Значительная часть споров вокруг унификации Han основана на различии между глифами, как они определены в Unicode, и связанной, но отличной концепцией графем. Unicode присваивает абстрактные символы (графемы), в отличие от глифов, которые являются конкретными визуальными представлениями символа в определенном шрифте. Один символ может быть представлен множеством различных глифов, например, «g» или «a», оба из которых могут иметь одну петлю (,) или две (,,). Однако для читателя языков на основе латинского алфавита обе вариации символа «a» распознаются как одна и та же графема. Графемы, присутствующие в национальных стандартах кодирования символов, были добавлены в Unicode в соответствии с правилом разделения источников Unicode, даже если они могут быть составлены из уже доступных символов. Национальные стандарты кодирования символов, существующие в языках CJK, значительно сложнее, учитывая технологические ограничения, в которых они развивались, и поэтому официальные участники CJK в унификации Han вполне могли быть готовы к реформам. В отличие от европейских версий, шрифты Unicode CJK, из-за унификации Han, имеют большие, но нерегулярные области перекрытия, что требует использования языкоспецифичных шрифтов. К сожалению, языкоспецифичные шрифты также затрудняют доступ к варианту, который, как в случае с «травой», чаще встречается в другом языковом стиле. (То есть, было бы трудно получить доступ к «траве» с четырехштриховым радикалом, более типичным для традиционного китайского языка в японской среде, где шрифты обычно отображают трехштриховый радикал.) Сторонники Unihan склонны отдавать предпочтение языкам разметки для определения строковых данных, но это не гарантирует использование конкретного варианта в данном случае, а лишь языкоспецифичного шрифта, который с большей вероятностью отобразит символ в этом варианте. (На данном этапе вступают в силу лишь стилистические различия, поскольку выбор японских и китайских шрифтов, вероятно, не будет визуально совместим.) Китайские пользователи, по-видимому, меньше возражают против унификации Han, в основном потому, что Unicode не пытался объединить упрощенные китайские иероглифы с традиционными китайскими иероглифами. (Упрощенные китайские иероглифы используются среди носителей китайского языка в Китайской Народной Республике, Сингапуре и Малайзии. Традиционные китайские иероглифы используются в Гонконге и Тайване (Big5), и они, с некоторыми различиями, более знакомы корейским и японским пользователям.) Unicode рассматривается как нейтральный в этом политически чувствительном вопросе и кодирует упрощенные и традиционные китайские глифы отдельно (например, иероглиф для «выбросить» — 丟 U+4E1F для традиционного китайского Big5 #A5E1 и 丢 U+4E22 для упрощенного китайского GB #2210). Также отмечается, что традиционные и упрощенные иероглифы должны кодироваться отдельно в соответствии с правилами унификации Han в Unicode, поскольку они различаются в существующих наборах символов КНР. Кроме того, как и в случае с другими вариантами, преобразование из традиционного в упрощенный не является однозначным.

Слияние всех эквивалентных символов

Не было никаких усилий по полному семантическому унифицированию всех семантически связанных символов, хотя идея заключалась в одинаковом отношении к пользователям восточноазиатских языков, пишущим на корейском, упрощенном китайском, традиционном китайском, японском кю:дзитай, японском синдзитай или вьетнамском языках. Вместо того чтобы некоторые варианты имели отдельные кодовые точки, а другим группам вариантов приходилось использовать общие кодовые точки, все варианты могли бы надежно представляться только с помощью метаданных (например, CSS-форматирования на веб-страницах). Бремя этого лежало бы на всех, кто использует различные версии 直, 別, 兩, 兔, независимо от того, обусловлено ли это упрощением, международными различиями или внутринациональными различиями. Однако для некоторых платформ (например, смартфонов) устройство может поставляться только с одним предустановленным шрифтом. Системный шрифт должен принимать решение о глифе по умолчанию для каждой кодовой точки, и эти глифы могут сильно различаться, отражая различные базовые графемы. Следовательно, подход, основанный на языковой разметке, сталкивается с двумя основными проблемами. Во-первых, существуют контексты, где языковая разметка недоступна (коммиты кода, обычный текст). Во-вторых, любое решение потребует предустановки множества глифов для семантически идентичных символов с множеством вариантов во всех операционных системах. Помимо стандартных наборов символов для упрощенного китайского, традиционного китайского, корейского, вьетнамского, японского кю:дзитай и японского синдзитай, существуют также «древние» формы символов, представляющие интерес для историков, лингвистов и филологов. База данных Unicode Unihan уже установила связи между многими символами. База данных Unicode уже каталогизирует связи между вариантами символов с различными кодовыми точками. Однако для символов с общей кодовой точкой эталонный образ глифа обычно склоняется к традиционной китайской версии. Кроме того, решение о классификации пар как семантических вариантов или z-вариантов не всегда последовательно или ясно, несмотря на обоснования в руководстве. Так называемые семантические варианты 丟 (U+4E1F) и 丢 (U+4E22) являются примерами, которые Unicode приводит как значительно отличающиеся по своим абстрактным формам, в то время как Unicode перечисляет 佛 и 仏 как z-варианты, отличающиеся только стилем шрифта. Парадоксально, но Unicode считает 兩 и 両 почти идентичными z-вариантами, одновременно классифицируя их как значительно различные семантические варианты. Существуют также случаи, когда некоторые пары символов одновременно являются семантическими вариантами, специализированными семантическими вариантами и упрощенными вариантами: 個 (U+500B) и 个 (U+4E2A). Встречаются случаи не взаимной эквивалентности. Например, запись в базе данных Unihan для 亀 (U+4E80) считает 龜 (U+9F9C) своим z-вариантом, но запись для 龜 не перечисляет 亀 как z-вариант, хотя 龜, очевидно, уже присутствовала в базе данных на момент написания записи для 亀. Некоторые опечатки привели к дублированию совершенно идентичных символов, таких как 﨣 (U+FA23) и 𧺯 (U+27EAF). Если шрифт имеет глифы, закодированные в обе точки, так что один шрифт используется для обоих, они должны выглядеть идентично. Эти случаи перечислены как z-варианты, несмотря на полное отсутствие различий. Преднамеренно дублированные символы были добавлены для облегчения преобразования «туда и обратно» побитово. Поскольку преобразование «туда и обратно» было ранним преимуществом Unicode, это означало, что если национальный стандарт необоснованно дублировал символ, Unicode должен был сделать то же самое. Unicode называет эти преднамеренные дубликации «вариантами совместимости», например, 漢 (U+FA9A), который называет 漢 (U+6F22) своим вариантом совместимости. Если приложение использует один и тот же шрифт для обоих, они должны выглядеть идентично. Иногда, как в случае с 車 с U+8ECA и U+F902, добавленный символ совместимости перечисляет уже существующую версию 車 как вариант совместимости и z-вариант. Поле вариантов совместимости переопределяет поле z-вариантов, принуждая к нормализации во всех формах, включая каноническую эквивалентность. Несмотря на название, варианты совместимости фактически канонически эквивалентны и объединяются в любой схеме нормализации Unicode, а не только в нормализации совместимости. Это аналогично тому, как канонически эквивалентно предварительно составленному. Многие программные обеспечения (например, MediaWiki, на котором размещена Wikipedia) заменяют все канонически эквивалентные символы, которые не рекомендуются (например, символ ангстрема), на рекомендуемые эквиваленты. Несмотря на название, CJK «варианты совместимости» являются канонически эквивалентными символами, а не символами совместимости. 漢 (U+FA9A) был добавлен в базу данных позже, чем 漢 (U+6F22), и его запись информирует пользователя о информации о совместимости. С другой стороны, 漢 (U+6F22) не содержит этой информации о эквивалентности в своей записи. Unicode требует, чтобы все записи, после принятия, не могли изменять совместимость или эквивалентность, чтобы правила нормализации для существующих символов не менялись. Некоторые пары традиционных и упрощенных символов также считаются семантическими вариантами. Согласно определениям Unicode, логично, что все упрощения (которые не приводят к слиянию совершенно разных символов из-за их омофонии) будут формой семантического варианта. Unicode классифицирует 丟 и 丢 как взаимные традиционные и упрощенные варианты, а также как взаимные семантические варианты. Однако, хотя Unicode классифицирует 億 (U+5104) и 亿 (U+4EBF) как взаимные традиционные и упрощенные варианты, Unicode не считает 億 и 亿 семантическими вариантами друг друга. Unicode утверждает, что «в идеале в стандарте Unicode не должно быть пар z-вариантов». Путем регистрации коллекций глифов в базе данных идеографических вариаций (IVD) можно использовать селекторы идеографических вариаций для формирования последовательностей идеографических вариаций (IVS) для указания или ограничения соответствующего глифа при обработке текста в среде Unicode.

Международные идеографы

Международное ядро идеограмм (IICore) — это подмножество, состоящее из 9810 идеограмм, извлеченных из таблиц унифицированных идеограмм CJK, разработанное для реализации в устройствах с ограниченным объемом памяти, возможностями ввода-вывода и/или в приложениях, где использование полного набора идеограмм ISO 10646 нецелесообразно. В текущем стандарте содержится 9810 символов.

Файлы базы данных Unihan

Проект Unihan всегда стремился сделать свою базу данных построения общедоступной. Все таблицы в этой базе данных находятся в пятой нормальной форме. libUnihan распространяется под лицензией LGPL, а сама база данных, UnihanDb, – под лицензией MIT.