漢民族の統一
Source Han Sansの地域バージョンにおける同じUnicodeコードポイント（U+8FD4）の相違点

漢字統合とは、 Unicodeおよび国際文字集合（Universal Character Set）の作成者による、いわゆるCJK言語の漢字の複数の文字集合を、単一の統一された文字集合にマッピングする取り組みです。漢字は、中国語（漢字）、日本語（漢字）、韓国語（漢字）、ベトナム語（中国語ハングル）の表記に共通する特徴です。

現代の中国語、日本語、韓国語の書体では、特定の漢字の地域的または歴史的な異体字が一般的に使用されています。Unicodeの策定においては、これらの異体字を異字（同じ「書記素」または正書法単位を表す 異なるグリフ）と見なすことで統一する試みがなされました。これが「漢字統合」であり、結果として得られた文字レパートリーはUnihan（ユニハン）と短縮されることもあります。[ 1 ] [ a ]

ただし、多くの文字には、繁体字(U+500B)と簡体字(U+4E2A) のように、異なるコード ポイントに割り当てられた地域的なバリエーションがあります。

根拠と論争

ユニコード規格は、漢字統一の原則を詳述している。[ 5 ] [ 6 ]中国語圏、北朝鮮、韓国、日本、ベトナムなどの国の専門家で構成される表意文字研究グループ （ IRG）がこの作業を担当している。 [ 7 ]

一つの根拠は、Unicode文字セット全体のサイズを制限したいという要望でした。CJK文字は個別の表意文字で表現され、10万文字[ b ]に近づくか、あるいはそれを超える可能性があります。Unicodeバージョン1は16ビットに収まるように設計されており、65,536文字のうち20,940文字（32%）のみがこれらのCJK統合表意文字用に予約されていました。Unicodeは後に21ビットに拡張され、より多くのCJK文字（101,996文字が割り当てられ、さらに余裕があります）が使用可能になりました。

IBMがホストした記事は、漢民族統一の動機の一部を説明しようと試みている。[ 8 ]

問題は、Unicodeが文字をエンコードするのに対し、文字の視覚的表現である「グリフ」をエンコードする点に起因しています。東アジアの文字の形には、繁体字中国語、簡体字中国語、日本語、韓国語の4つの基本的な伝統があります。漢字の語根はCJK言語で同じかもしれませんが、同じ文字に一般的に使用されるグリフは必ずしも同じではありません。例えば、「草」を表す繁体字中国語のグリフでは「草」の部首に4画の画数[ ⺿ ]が使用されていますが、簡体字中国語、日本語、韓国語のグリフ[ ⺾ ]では3画の画数を使用しています。しかし、表記体系に関わらず、「草」を表す文字（U+8349）[草]にはUnicodeポイントが1つしかありません。もう一つの例は、「一」を表す表意文字で、これは中国語、日本語、韓国語で異なります。多くの人は、これら3つのバージョンはそれぞれ異なる方法でエンコードされるべきだと考えています。

実際、「一」を表す3つの漢字（一、壹、壱）は、国別の異体字とはみなされないため、Unicodeでは別々にエンコードされています。最初の漢字は3か国共通の形ですが、2番目と3番目は金融商品において改ざん防止のために使用されています（異体字とみなされる場合もあります）。

漢族の統一は、特に日本の国民の間でかなりの論争を引き起こした。彼らは、日本の知識人とともに、歴史的、文化的に重要な異形の排除に抗議してきた歴史がある。[ 9 ] [ 10 ] （漢字§ 正書法改革と漢字一覧を参照。今日、固有名詞に使用するために公式に認められている文字のリストは、緩やかなペースで拡大し続けている。）

1993 年、日本電子工業開発協会(JEIDA) は、Unicode で採用されているハン統一アプローチに対する主な批判をまとめた、「将来の文字コード体系に私達は不安を感じています。」 (将来の文字コード体系に不安を感じていますJPNO  20985671 ) というタイトルのパンフレットを発行しました。

グラフィムとグリフ

ラテン文字の小文字「a」には、同じ抽象書記素を表す異なるグリフがあります。ラテン文字を母国語とする人にとっては、これら2つのグリフは同じ書記素として認識されますが、他の人にとっては無関係に見えるかもしれません。

グラフィムとは、表記体系における意味の最小単位です。グラフィムには様々なグリフ表現が可能ですが、特定の表記体系の読み書きの知識を持つ人にとっては、どれも同じグラフィムとして認識されます。Unicodeでは通常、表記体系内のグラフィムを表現するために文字にコードポイントを割り当てていますが、Unicode規格（セクション3.4 D7）では次のように注意喚起されています。

抽象文字は、必ずしもユーザーが「文字」と考えるものと一致するとは限らないため、書記素と混同しないでください。

— Unicode® 標準バージョン 16.0 – コア仕様 §3.4 文字とエンコーディング

しかし、この引用は、一部のグラフィムが複数の図形要素、つまり「文字」から構成されているという事実に言及しています。例えば、 U+0061 aラテン小文字 AとU+030A ◌̊結合環（組み合わせ「å」を生成）を組み合わせた文字は、複数の Unicode 抽象文字から構成されているにもかかわらず、ユーザーには単一のグラフィムとして理解される可能性があります。さらに、Unicode は、互換性上の理由以外で、少数の書式設定文字、空白文字、その他の抽象文字にもコードポイントを割り当てています。これらはグラフィムではなく、行、単語、グラフィム、グラフィムクラスター間の区切りを制御するために使用されます。統一された漢字表意文字によって、Unicode 標準は抽象文字をグラフィムとしてではなく、グラフィムの根底にある意味（言語学者がセミームと呼ぶこともある）に従って割り当てるという、従来の慣習から逸脱しています。したがって、この差異は、よく引用される抽象文字とグリフの区別だけで説明できるものではなく、むしろグラフィムとして割り当てられた抽象文字とセミームとして割り当てられた抽象文字の違いに根ざしています。対照的に、ASCIIにおける句読点と分音記号の統合を考えてみましょう。ASCIIでは、意味が大きく異なるグラフィム（例えば、アポストロフィと一重引用符）が、グリフが同じであるため統合されています。Unihanでは、文字は外観ではなく、定義または意味によって統合されています。

グラフィムが様々なグリフで表現されるということは、そのグラフィムにグリフのバリエーションが存在することを意味します。これらのバリエーションは通常、フォントの選択や、複数のグリフを単一のフォントに含めるグリフ置換機能の使用によって決定されます。Unicodeでは、このようなグリフのバリエーションはリッチテキストプロトコルの機能とみなされており、Unicodeのプレーンテキストの目標では適切に処理されません。しかし、あるグリフから別のグリフへの変更が、あるグラフィムから別のグラフィムへの変更となる場合（例えば、あるグリフが小文字の「a」として理解される同じグラフィムを依然として意味し続けることは不可能である場合）、Unicodeはそれらを別々のコードポイントに分離します。Unihanでは、抽象的な意味が変化するたびに同じことが行われますが、グラフィム（文字「a」）の抽象的な意味について語るのではなく、漢字の統一によって、それぞれの異なる意味に新しいコードポイントが割り当てられます。たとえその意味が異なる言語で異なるグラフィムによって表現されていたとしてもです。 「ö」のようなグラフィムは、英語（「coördinated」で使用されている）とドイツ語（「schön」で使用されている）では意味が異なる場合がありますが、それでも同じグラフィムであり、容易に統合できるため、英語とドイツ語は共通の抽象的なラテン語表記体系（ラテン語自体も含む）を共有できます。この例は、「抽象文字」と書き言葉における抽象単位としてのグラフィムが必ずしも一対一で対応しない別の理由も示しています。英語では、結合分音記号⟨◌̈⟩とそれが修飾する「o」は、2つの別々のグラフィムと見なすことができますが、スウェーデン語などの言語では、文字「ö」は単一のグラフィムと見なすことができます。同様に、英語では「i」のドットは「i」グラフィムの一部と理解されますが、トルコ語などの他の言語では、ドットはドットのない「ı」に追加された別のグラフィムと見なすことができます。

同じUnihanセミームに異なるグラフィムを使用する問題に対処するため、Unicodeはいくつかのメカニズムを採用してきました。特にテキストのレンダリングに関しては顕著です。その一つは、これを単なるフォントの問題として扱い、中国語、日本語、韓国語のレンダリングにそれぞれ異なるフォントを使用するというものです。また、OpenTypeなどのフォント形式では、言語に応じて代替グリフをマッピングできるため、テキストレンダリングシステムはユーザーの環境設定を参照して使用するグリフを決定できます。これらのアプローチの問題は、多言語テキストのエンコード方法を一貫して定義するというUnicodeの目標を満たしていないことです。[ 11 ]

そのため、この問題をグリフ代替のリッチテキストの問題として扱うのではなく、Unicode では異体字セレクタの概念を追加しました。これはバージョン 3.2 で初めて導入され、バージョン 4.0 で補足されました。[ 12 ]異体字セレクタは結合文字として扱われますが、関連付けられている分音記号や記号はありません。代わりに、基本文字と組み合わせることで、2 つの文字シーケンスが基本文字の異体字 (通常は書記素の観点ですが、場所名やその他の固有名詞の場合のように根本的な意味の観点でも) を選択することを示します。つまり、これは代替グリフの選択ではなく、書記素の異体字または基本抽象文字の異体字の選択です。ただし、このような 2 文字シーケンスは、現代のフォントでは別の単一のグリフに簡単にマッピングできます。Unicode は 256 個の異体字セレクタを割り当てているため、どの漢字表意文字にも 256 個の異体字を割り当てることができます。このようなバリエーションは、ある言語または別の言語に固有のものであり、このような書記素のバリエーションを含むプレーンテキストのエンコードを可能にします。

ユニハン「抽象文字」

Unihan規格は「グリフ」ではなく「抽象文字」をエンコードするため、Unicodeによって生成されるグラフィック・アーティファクトは一時的な技術的ハードル、せいぜい装飾的なものと考えられてきました。しかし、特に日本においては、漢字が歴史的に日本語の表記体系に組み込まれた経緯もあって、特定の異体を指定できないことが、学術研究におけるUnicodeの使用における大きな障害と考えられていました。例えば、「草」の統一（上記で説明）は、歴史的文書をその独特の綴り方を維持するようにエンコードすることができないことを意味します。その代わりに、例えば、研究者は、書かれたとおりに文書を伝えるために、特定の書体で目的のグリフを見つける必要があり、統一された文字セットの目的が損なわれます。Unicodeは、著者が特定の表意文字（あるいは他の文字でさえ）の書記素の異体を選択できるように、異体セレクタを割り当てることでこれらのニーズに対応しました。[ 12 ]

グラフィック表現における小さな違いは、読みやすさに影響を与えたり、誤った文化的伝統に属したりする場合にも問題となります。一部のUnicodeフォントは、複数の「Unihan言語」を含むテキストでは使用できなくなるだけでなく、人名やその他の綴りが重要な用語が正しく表示されない可能性があります。（固有名詞は特に綴りが保守的になる傾向があります。これは、米国や英国の言語改革に合わせて自分の名前の綴りを変えるのと似ています。）これは、主にグラフィック表現またはレンダリングの問題であり、より洗練されたフォントで克服できると考えられますが、Unicodeの広範な使用により、このような区別を維持することは困難になるでしょう。1つの文字が意味的に異なる概念を表すという問題は、Unicodeのラテン文字にも存在します。曲線アポストロフィを表すUnicode文字は、右シングルクォート（'）を表す文字と同じです。一方、ラテン文字の大文字Aは、ギリシャ文字のΑやキリル文字のΐと統一されていません。これはもちろん、互換性の観点から望ましいことであり、はるかに小さなアルファベット文字セットを扱うことになります。

Unicode の統一性については、上記の理由により一部で議論の的となっていますが、Unicode 自体は現在、多かれ少なかれ古風な性質を持つ、めったに使用されない文字を大量にエンコードしています。

論争の一部は、漢字統一の決定自体が、当時は北米の企業や団体（そのほとんどがカリフォルニア州）のコンソーシアムであった初期のUnicodeコンソーシアムによってなされたという事実に起因している。[ 13 ]東アジアの政府代表は含まれていなかった。当初の設計目標は16ビット標準の作成であったため、[ 14 ]漢字統一は数万文字の重複を避けるための重要なステップであった。この16ビット要件は後に廃止され、文字セットのサイズは今日ではそれほど問題ではなくなった。

この論争は後に国際的に代表的なISOにまで波及した。当初、CJK共同研究グループ（CJK-JRG）は非統一文字セットの提案（DIS 10646）を支持したが、「アメリカとヨーロッパのISOメンバーの投票により、Unicodeコンソーシアムの統一文字セットとの統一が支持され、却下された」（日本の立場は不明瞭であった）。[ 15 ] Unicodeの漢字統一を承認することは、白熱したISO 10646とUnicodeの統合にとって必要なステップであった。

漢字統一をめぐる論争の多くは、 Unicodeで定義されているグリフと、関連はあるものの異なる概念であるグラフィムとの区別に基づいています。Unicodeは、特定の書体における文字の特定の視覚的表現であるグリフとは対照的に、抽象文字（グラフィム）を割り当てています。1つの文字は、例えば「g」や「a」のように、複数の異なるグリフで表される場合があります。どちらもループが1つ（ɑ、ɡ）または2つ（a、g）ある場合があります。しかし、ラテン文字系言語の読者にとっては、「a」の2つのバリエーションはどちらも同じグラフィムとして認識されます。各国の文字コード標準に存在するグラフィムは、Unicodeのソース分離規則の要件に従い、既存の文字で構成されている場合でも、Unicodeに追加されています。 CJK 言語に存在する国家文字コード規格は、その発展過程における技術的な制限を考慮すると、かなり複雑であり、そのため、漢語統一における CJK の公式参加者は改革に前向きであった可能性がある。

ヨーロッパ版とは異なり、CJK Unicodeフォントは漢字統一のため、文字の重なりが大きく不規則なパターンを持つため、言語固有のフォントが必要になります。残念ながら、言語固有のフォントでは、「草」の例のように、他の言語スタイルでより一般的に現れる異体字にアクセスすることが困難です。（つまり、繁体字中国語でより典型的な4画の部首を持つ「草」を、日本語環境では3画の部首を表すフォントで表現することが困難です。）Unihan支持者は、言語文字列の定義にマークアップ言語を好む傾向がありますが、これは特定の異体字が使用されることを保証するものではなく、その異体字として文字を表す可能性が高い言語固有のフォントのみを使用することになります。（この時点では、単にスタイル上の違いが関係します。一部の日本語と中国語のフォントは視覚的に互換性がない可能性が高いためです。）

中国語ユーザーは、Unicodeが簡体字と繁体字の統合を試みなかったことが主な理由で、漢字統一にあまり反対していないようです。（簡体字は中華人民共和国、シンガポール、マレーシアの中国語話者の間で使用されています。繁体字は香港と台湾（Big5）で使用されており、多少の違いはあるものの、韓国語と日本語のユーザーには馴染み深いものです。）Unicodeはこの政治的にデリケートな問題に関しては中立的な立場をとっており、簡体字と繁体字のグリフを別々にエンコードしています（例えば、「discard（捨てる）」の表意文字は、繁体字中国語Big5 #A5E1では丟U+4E1F、簡体字中国語GB #2210では丢U+4E22です）。また、繁体字と簡体字は既存の中華人民共和国文字セットで区別されているため、Unicode漢字統一規則に従って別々にエンコードする必要があることにも留意が必要です。さらに、他の変種と同様に、繁体字と簡体字は1対1の関係ではありません。

代替案

漢字統一の原則に従ってエンコードされていないため、その制限を受けない代替文字セットがいくつかあります。

これらの地域依存の文字セットも、地域固有の性質のため、漢語統一の影響を受けないと考えられています。

  • ISO/IEC 2022（中国語、日本語、韓国語の文字セットを切り替えるためのシーケンスコードに基づくため、統一されていない）
  • Big5拡張機能
  • GCCSとその後継機関であるHKSCS

しかし、これらの代替標準のどれも、 Unicodeほど広く採用されていません。 Unicode は現在、多くの新しい標準やプロトコルの基本文字セットとなり、国際的に採用され、オペレーティング システム ( Microsoft Windows、Apple macOS、および多くのUnix 系システム)、プログラミング言語 ( Perl、Python、C#、Java、Common Lisp、APL、C、C++ )、ライブラリ ( IBM International Components for Unicode (ICU) に加えてPango、Graphite、Scribe、Uniscribe、およびATSUIレンダリング エンジン)、フォント形式 ( TrueTypeおよびOpenType ) などのアーキテクチャに組み込まれています。

1989年3月、(B)TRONベースのシステムが、日本の政府機関である「教育用コンピュータセンター」によって、義務教育を含む学校教育用のシステムとして採用された。[ 16 ]しかし、4月に米国通商代表部（USTR）が発表した「1989年 対外貿易障壁に関する国家貿易評価報告書」では、このシステムが日本における貿易障壁として明確に挙げられていた。この報告書は、日本政府によるTRONベースシステムの採用は日本のメーカーに有利であり、巨大な新市場から米国のオペレーティングシステムを排除することになると主張し、MS-DOS、OS/2、UNIXを具体的な例として挙げている。USTRはマイクロソフトの影響下にあったとされ、USTRの元職員トム・ロバートソンは当時、マイクロソフトから高給のポストを提示されていた。[ 17 ] TRONシステム自体は、1989年5月に組織による抗議を受けて1974年通商法第301条の制裁対象リストから削除されましたが、貿易紛争により、通商産業省は孫正義氏からの、教育用コンピュータの使用のためのTRONベースのシステムの選定を取り消すという要請を受け入れました。 [ 18 ]この事件は、BTRONシステムの勢いの喪失と最終的な終焉を象徴する出来事と見なされており、BTRONシステムは日本でMS-DOSの普及と、その後継であるWindowsでのUnicodeの採用につながりました。

すべての同等の文字の結合

意味的に結びついたすべての文字の意味を完全に統一しようという動きはまだありませんが、この考え方は、韓国語、中国語（簡体）、中国語（繁体）、日本語（旧字体）、日本語（新字体）、ベトナム語など、東アジア言語を使用するユーザーをそれぞれ同じように扱うというものです。一部の異体字に異なるコードポイントを割り当て、他の異体字グループに単一のコードポイントを共有させるのではなく、すべての異体をメタデータタグ（例：WebページのCSSフォーマット）のみで確実に表現することができます。その負担は、簡体化、国際的差異、国内的差異のいずれによるものであれ、直、別、兩、兔の異なるバージョンを使用するすべてのユーザーにかかることになります。ただし、一部のプラットフォーム（例：スマートフォン）では、デバイスにプリインストールされているフォントが1つだけである場合があります。システムフォントは各コードポイントのデフォルトグリフを決定する必要があり、これらのグリフは大きく異なる場合があり、これは基礎となる書記素が異なることを示している可能性があります。

したがって、言語マークアップを全面的に利用するアプローチには、2つの大きな問題が伴います。第一に、言語マークアップが利用できない状況（コードコミット、プレーンテキストなど）があることです。第二に、いかなる解決策も、意味的に同一でありながら多くの異体を持つ文字のグリフを、すべてのオペレーティングシステムにプリインストールする必要があります。簡体字中国語、繁体字中国語、韓国語、ベトナム語、旧字体日本語、新字体日本語といった標準文字セットに加えて、歴史家、言語学者、文献学者にとって興味深い「古代」の文字形態も存在します。

UnicodeのUnihanデータベースは、既に多くの文字間の関連性を描いています。Unicodeデータベースは、異なるコードポイントを持つ異体文字間の関連性を既にカタログ化しています。しかし、共通のコードポイントを持つ文字の場合、参照グリフ画像は繁体字中国語版に偏っていることが多いです。また、文字ペアを意味的異体とz異体に分類するかどうかの判断は、ハンドブックでの解説にもかかわらず、必ずしも一貫性や明確性に欠けています。[ 19 ]

Unicodeでは、丟(U+4E1F)と丢(U+4E22)のいわゆる意味的異体字は、抽象的な形状において大きく異なるものとして挙げられている例です。一方、Unicodeでは佛と仏はフォントスタイルのみが異なるz異体字としてリストされています。逆説的に、Unicodeは兩と両をほぼ同一のz異体字と見なしながらも、同時に大きく異なる意味的異体字として分類しています。また、文字のペアによっては、意味的異体字と特殊意味的異体字、そして簡略化異体字が同時に存在する場合もあります。例えば、個(U+500B)と個(U+4E2A)です。相互に等価でない場合もあります。たとえば、亀(U+4E80)の Unihan データベース エントリでは、龜(U+9F9C) がその z 異形であるとみなされますが、龜のエントリでは、亀のエントリが作成された時点で龜がすでにデータベースに存在していたことは明らかであるにもかかわらず、亀がz 異形としてリストされていません。

誤記により、﨣(U+FA23) と𧺯 (U+27EAF) のような完全に同一の文字が重複して表示されてしまいました。フォントに両方のポイントにエンコードされたグリフがあり、1 つのフォントが両方に使用されている場合、それらは同一に表示されるはずです。これらのケースは、差異がまったくないにもかかわらず、z 異体としてリストされています。意図的に重複した文字は、ビットごとの往復変換を容易にするために追加されました。往復変換は Unicode の初期のセールスポイントであったため、使用中の国家規格で不必要に文字が重複している場合、Unicode も同様に対応しなければなりませんでした。Unicode では、これらの意図的な重複を「互換異体」と呼んでいます。たとえば、漢 (U+FA9A) が漢(U+6F22) を互換異体と呼びます。アプリケーションが両方に同じフォントを使用している限り、それらは同一に表示されるはずです。 U+8ECAとU+F902を持つ「車」の場合のように、追加された互換文字は、既存の「車」を互換異体とz異体の両方としてリストすることがあります。互換異体フィールドはz異体フィールドをオーバーライドし、正準等価性を含むすべての形式で正規化を強制します。名前に反して、互換異体は実際には正準等価であり、互換正規化だけでなく、あらゆるUnicode正規化スキームで統合されます。これは、U+212B Å ANGSTROM SIGNが、事前に構成されたU+00C5 Å LATIN CAPITAL LETTER A WITH RING ABOVEと正準等価であることに似ています。多くのソフトウェア（WikipediaをホストするMediaWikiソフトウェアなど）は、非推奨の正準等価文字（例えば、オングストローム記号）をすべて推奨等価文字に置き換えます。名前に反して、CJKの「互換異体」は正準等価文字であり、互換文字ではありません。

漢 (U+FA9A) は漢(U+6F22)よりも後にデータベースに追加され、そのエントリには互換性に関する情報が記載されています。一方、漢(U+6F22) にはこのエントリに同等性が記載されていません。Unicode では、既存の文字の正規化規則が変更されないように、一度追加されたエントリは互換性や同等性を変更できないように規定されています。

繁体字と簡体字の組み合わせの中には、意味上の異体とみなされるものもあります。Unicodeの定義によれば、（全く異なる文字が同音異義語として結合されることのない）簡体字はすべて意味上の異体の一種であるとされています。Unicodeは丟と丢をそれぞれ繁体字と簡体字の異体として分類し、また意味上の異体としても分類しています。しかし、Unicodeは億(U+5104)と亿(U+4EBF)をそれぞれ繁体字と簡体字の異体として分類している一方で、億と亿を互いの意味上の異体とは見なしていません。

Unicodeは、「理想的には、Unicode標準にはZバリアントのペアは存在しない」と主張しています。[ 19 ]これによると、Unicodeの目標は、少なくともすべてのマイナーバリアント、互換性の冗長性、そして偶発的な冗長性を統一し、区別はフォントと言語タグに委ねることであるように思われます。これは、Unicodeが掲げる目標である、こうしたオーバーヘッドを取り除き、世界中のあらゆる文字種を任意の数だけ、単一のエンコーディングシステムで同一文書に記述できるようにするという目標と矛盾しています。ハンドブックの第1章には、「情報技術業界は、Unicodeの導入により、急増する文字セットをデータの安定性、グローバルな相互運用性とデータ交換、ソフトウェアの簡素化、開発コストの削減に置き換えました。Unicode標準は、ASCII文字セットを出発点としながらも、大文字と小文字のAからZまでしかエンコードできないASCIIの限界をはるかに超えています。世界中の書き言葉で使用されるすべての文字をエンコードする能力を提供し、100万文字以上をエンコードできます。どの言語のどの文字を指定するにも、エスケープシーケンスや制御コードは必要ありません。Unicode文字エンコーディングは、アルファベット文字、表意文字、記号を同等に扱うため、これらを任意の組み合わせで、同等の利便性で使用できます。」と記載されています。[ 11 ]

こうすることで、すべてのz異体字に統一された参照書記素を定めるという選択肢が残されますが、日本国外では佛と仏を同義語と認識する人はほとんどいないため、議論の余地があります。日本国内においても、これらの異体は新字体と呼ばれる大規模な簡略化の両側にあります。Unicodeでは、中国の侣(U+4FA3)とη (U+4FB6)の簡略化は、比較すると非常に大きな違いとなるでしょう。このような計画は、直(U+76F4)や雇(U+96C7)のような、視覚的に非常に特徴的な異体字も排除してしまうでしょう。

すべての簡体字は同時に、繁体字の z 異体字または意味バリアントでもあることが期待されますが、多くはどちらでもありません。意味バリアントが意味バリアントと特殊バリアントの両方である可能性があるという奇妙なケースは、Unicode の定義では、特殊な意味バリアントは特定のコンテキストでのみ同じ意味を持つとされているため、説明が容易になります。言語によって使い方が異なります。日本語では 100% 完全に置換できる文字のペアが、中国語ではそれほど柔軟ではない場合があります。したがって、推奨コード ポイントを包括的に統合する場合は、ある言語ですべてのコンテキストで意味が 100% 同じであっても、外観がわずかに異なるバリアントがいくつか保持される必要があります。これは、別の言語では 2 つの文字が 100% 完全に置換できない可能性があるためです。

言語依存グリフの例

統一されていない漢字の例

場合によっては、変更が最も顕著な場合が多いのですが、Unicode では異体文字がエンコードされているため、フォントやlang属性を切り替える必要がありません。ただし、違いが最小限であると主張できる異体には個別のコードポイントが割り当てられ、変更が大幅にあると主張できるすべての異体に対して一意のコードポイントが割り当てられるわけではありません。例として、入(U+5165) などの文字の場合、異体を表示するには、lang前の表で説明したようにフォント (または属性) を変更するしかありません。一方、內(U+5167) の場合、内(U+5185) の異体に一意のコードポイントが割り当てられます。兌/兑(U+514C/U+5151)など一部の文字では、どちらの方法を使用しても異なるグリフを表示できます。次の表では、各行で異なるコードポイントが割り当てられた異体を比較しています。簡潔にするために、異なる構成要素を持つ新字体の異体字は通常（そして当然のことながら）独自のコードポイント（例：氣/気）を取ることに留意してください。これらはここでは示しません。また、一貫して簡略化された部首を持つ簡体字（例：紅/红、語/语）も示しません。[ 3 ]このリストは網羅的なものではありません。

簡略化 伝統的 日本語 その他の変種 英語
U+4E22丢U+4E1F丟負ける
U+4E24两U+5169兩U+4E21両U+34B3㒳2つ、両方
U+4E58乘U+4E58乘U+4E57乗U+6909椉乗る
U+4EA7产U+7522產U+7523産出産する
U+4FA3侣U+ 4FB6ет仲間
U+5151兑U+514C兌現金化する
U+5185内U+5167內内部
U+522B别U+5225別去る
U+7985禅U+79AA禪U+7985禅瞑想（禅）
U+7A0E税U+7A05稅税金
U+997F饿U+9913餓お腹がすいた
U+9AD8高U+9AD8高U+9AD9髙高い
U+9F9F龟U+9F9C龜U+4E80亀カメ
U+7814研U+784F硏U+7814研研究する
出典：MDBG中英辞典

表意文字異形データベース（IVD）

漢字統一によってもたらされた問題を解決するために、プレーンテキスト環境で特定のグリフを指定するという問題を解決するために、Unicode表意文字異体データベースと呼ばれるUnicode技術標準が作成されました。[ 20 ]グリフコレクションを表意文字異体データベース（IVD）に登録することにより、表意文字異体セレクタを使用して表意文字異体シーケンス（IVS）を形成し、Unicode環境でのテキスト処理で適切なグリフを指定または制限することができます。

Unicodeの範囲

Unicode によって割り当てられた表意文字は、次のブロックに表示されます。

Unicode には、次のブロックの CJKV 部首、画数、句読点、記号、および記号のサポートが含まれています。

追加の互換性文字 (使用は非推奨) は、次のブロックに表示されます。

これらの互換文字（CJK互換表意文字ブロック内の12の統合表意文字を除く）は、従来のテキスト処理システムやその他の従来の文字セットとの互換性のために含まれています。これには、縦書きテキストレイアウト用の文字形式や、Unicodeが他の手段で処理することを推奨しているリッチテキスト文字が含まれます。

国際表意文字コア

国際表意文字コア（IICore）は、CJK統合表意文字表から派生した9810文字の表意文字のサブセットであり、メモリや入出力能力が限られているデバイスや、ISO 10646表意文字レパートリーの完全な使用が不可能なアプリケーションに実装するために設計されています。現在の規格には9810文字が含まれています。[ 22 ]

Unihan データベースファイル

Unihanプロジェクトは常にビルドデータベースを公開する努力をしてきました。[ 2 ]

libUnihanプロジェクトは、正規化されたSQLite Unihanデータベースと対応するCライブラリを提供しています。[ 23 ]このデータベースのすべてのテーブルは第5正規形です。libUnihanはLGPLライセンスの下でリリースされていますが、そのデータベースであるUnihanDbはMITライセンスの下でリリースされています。最終バージョンは2008年10月にリリースされました。

参照

注記

  1. ^ Unihanは、 Unicodeコンソーシアムが管理するUnihanデータベースを指すこともあります。このデータベースは、Unicode標準でエンコードされたすべての統一漢字に関する情報を提供しており、さまざまな国家標準および業界標準へのマッピング、標準辞書の索引、エンコードされた異体、さまざまな言語での発音、英語の定義などが含まれています。データベースはテキストファイル[ 2 ]およびインタラクティブなウェブサイト [ 3 ] で公開されています。 [ 4 ]後者には、無料の日本語EDICTおよび中国語CEDICT辞書プロジェクト（便宜上提供されており、Unicode標準の正式な一部ではありません）から抽出された複合語の代表的なグリフと定義も含まれています。
  2. ^これらのほとんどはレガシー文字や廃止文字ですが、現在または過去に使用されたすべての表記体系をエンコードするという Unicode の目的に従い、読み書き可能と見なされるには 2,000 から 3,000 文字だけが必要です。

参考文献

  1. ^ 「Unicode®標準付録#38 | UNICODE HANデータベース（UNIHAN）」 . Unicodeコンソーシアム. 2023年9月1日.
  2. ^ a b「Unihan.zip」 . Unicode標準. Unicodeコンソーシアム.
  3. ^ a b「Unihanデータベース検索」。Unicode標準。Unicodeコンソーシアム。
  4. ^ 「Unihanデータベース検索：『中』のサンプル検索」 . Unicode標準. Unicodeコンソーシアム.
  5. ^ 「第18章：東アジア、漢民族統一の原則」。Unicode標準。Unicodeコンソーシアム。
  6. ^ Whistler, Ken (2010-10-25). 「Unicodeテクニカルノート26：ラテン文字、ギリシャ文字、キリル文字、漢字のエンコードについて」 .
  7. ^ 「漢統一史」 . Unicode標準. Unicodeコンソーシアム.
  8. ^ 「The secret life of Unicode」 IBM 2013年12月16日。2013年12月16日時点のオリジナルよりアーカイブ。 2023年9月30日閲覧。
  9. ^ Unicode 再考Steven J. Searle; TRON Web ウェブマスター
  10. ^ “IVD/IVSとは - 文字情報基盤整備事業” . mojikiban.ipa.go.jp。
  11. ^ a b「第1章 はじめに」 . Unicode標準. Unicodeコンソーシアム.
  12. ^ a b「Ideographic Variation Database」。Unicodeコンソーシアム。
  13. ^ 「Unicodeの初期」。Unicodeコンソーシアム。
  14. ^ Becker, Joseph D. (1998-08-29). 「Unicode 88」(PDF) .
  15. ^ 「Unicode in Japan: Guide to a technical and psychology struggle」 2009年6月27日時点のオリジナルよりアーカイブ。
  16. ^小林紀興『松下電器の果し状』1章
  17. ^ Krikke, Jan (2003年10月15日). 「世界で最も人気のあるオペレーティングシステム」 . LinuxInsider.com .
  18. ^大下英治『孫正義起業の侵略獅子』（ ISBN） 4-06-208718-9）pp. 285-294
  19. ^ a b "UAX #38: Unicode Han データベース (Unihan)" . www.unicode.org。
  20. ^ 「UTS #37: Unicode表意文字変異データベース」www.unicode.org。
  21. ^ “ウロ” . ccjktype.fonts.adobe.com。
  22. ^ 「OGCIO：ダウンロードエリア：国際漢字コア（IICORE）比較ユーティリティ」www.ogcio.gov.hk。
  23. ^ Chen, Ding-Yi. 「libUnihan - 第5正規形のUnihan文字データベース用ライブラリ」 . libunihan.sourceforge.net .
「 https://en.wikipedia.org/w/index.php?title=Han_unification&oldid=1335285541」より取得