ISOはアメリカの発議により、1983年からISO/IEC 2022の延長線上の国際文字コード、ISO 10646の開発に着手していた。1989年に4バイトに拡張した最初の原案がまとまったが、最終段階の国際投票で否決された。最終投票までいきながら否決されたのは、アメリカがユニコード（Unicode）推進に方針を転換したからである。
ユニコードとはアメリカのフォント関係者を中心に進められていた世界共通内部コードの開発プロジェクトで、16ビット固定長の6万5千字余のスペースに全世界のすべての文字を収録しようという遠大な理想をかかげていた。
ユニコードという名称は Universal（普遍的）、Uniform（固定長）、Unique（一意的）というモットーにもとづく。16ビット固定長という点は最初から疑問があったが、固定長をことさらアピールしたのは、内部処理用のコードとして構想されたためであろう。
当初はボランティア・ベースだったが、極東向けに製品をローカライズする煩雑な作業に悩まされていたアメリカのコンピュータ業界の注目するところとなり、1991年、IBM社、アップル社、マイクロソフト社、アドビ社など、錚々たる企業が参加して、ユニコード・コンソーシアムが設立された。
台湾、韓国など、漢字文化圏の諸国は1980年代に目覚ましい経済発展をとげ、コンピュータの有望な市場となったが、2バイトコードへの対応はただでさえ手間がかかる上に、国ごとに文字コードが異なったので、日本語向け、繁体字中国語向け、簡体字中国語向け、韓国語向けと、同じ製品を四回ローカライズしなければならなかった。内部処理を共通漢字コードでおこない、外部に出力する際、その国の標準漢字コードに変換するようにすれば、ローカライズの手間と期間は大幅に軽減される。
国際共通文字コードという点ではISO 10646の最初の原案も同じだが、最初の原案は情報交換を主に設計されていたのに対し、ユニコードはすぐに実用に供せる内部処理用コードという面が重視されていたようである（注7）。
すぐに使えるようにするためには、どうしても16ビットでおさえなければならなかった。ISO 10646の最初の原案は、32ビットの広大なスペースに日中韓台の公的文字コードをそのまま収録することになっていたが、16ビットコードには6万5千字分のスペースしかないので、そんな余裕はない。そこで使われたのが、漢字統合という手法である（次節参照）。
ISO/IEC 10646はユニコードと合体した第二原案が作られ、1993年、正式に国際規格となった。これがISO/IEC 10646-1で、コード構造を規定した部分と、BMP（Basic Multilingual Plane, 基本多言語面）の符号表から構成されている。ISO/IEC 10646は世界中の文字を網羅するところから、UCS（Universal Coded character Set, 国際符号化文字集合）とも呼ばれている。
UCSは32ビットコードという大枠は維持したが、8ビット4バイトではなく、32ビット1バイトになった（後述のUCS2の場合は16ビット1バイト）。ISO/IEC 2022との互換性は無視し、ユニコードと同様の16ビットの文字面（6万5千字）を3万2千枚余集めた構造をとり、21億字が収容可能である（最上位ビットはつねに0にするので、実質31ビット）。
最初の面をBMP（基本多言語面）と呼ぶのは第一原案と同じだが、中味も符号もユニコードそのものに置き換えられた。
決定的なのは、BMPに限り、16ビットコードとしてあつかってよいことにした点で、これをUCS2と称する。UCS2は、即、ユニコードである。
ユニコードは16ビットを1バイトとする内部処理用コードとして開発されたので、ネットワークに流す場合はUTF（UCS Transfomation Format、UCS変換形式）と呼ばれる別形式に変換することになっていた。
さまざまなUTFが提案されたが、最終的にUTF-8が勝ちのこった。ユニコードは冒頭部分にASCIIをそのまま収録しているが、UTF-8はASCII相当部分の符号はそのまま出力し（正確にいえば、頭に0をつけて8ビットにする）、以降の符号は、ネットワークに流しても問題のない2〜6バイトの8ビット符号の組みあわせに変換してから出力する。ユニコードをASCIIの上位互換であるかのようにあつかえる点がUTF-8が選ばれた主たる理由のようである。
ここでユニコードを可能にした漢字統合についてふれたい。
後に自らユニコーダーと名乗ることになる技術者たちは、1980年代半ばから、RLG（Research Library Groupe、全米図書館情報グループ）が策定したEACC（East Asian Common Character 東アジア共通文字表）という書誌用漢字コードをもとに、漢字データベースの構築を進めていた。
EACCの元になったのは台湾の台北国立中央図書館が開発したCCCIIという書誌用漢字コードだった。CCCIIは全体を16群にグループわけし、第1群に伝統字を収録し、第2群には伝統字に対応する簡体字、第3〜12群には異体字、第13群には日本の字体、第14群には韓国の字体をマッピングした。つまり、符号表がそのまま異体字データベースになるような構造をとっていたのである。
RLGは日本の田嶋一夫の「漢字情報処理システムの課題」の示唆により（注8）、異体字を符号位置とは別の方法であらわすという手法を模索していた。ユニコーダーたちはRLGの考え方を踏襲し、異体字はフォント技術によってあらわすという方向で議論を進め、1998年頃、2万字からなる最初の漢字セットをまとめた。
規格によって微妙に字体の異なる漢字は一つの符号に統合された。内部処理では一つの符号であっても、出力する際に元の文字コードにもどせば、既存規格との字体の違いは表面化しない。また、個々の字の字形データをグリフ、グリフの集合をフォントというが、製品に実装されるフォントは、ユニコード収録文字すべてを含む必要はなく、その国の既存規格に含まれる字のグリフだけでよいという考え方である（注9）。
ユニコード関係者は国際共通文字コードがISO 10646とユニコードの二つが並立するのは好ましくないとして、両者の合体を主張し、アメリカの大手コンピュータ企業群の支持のもとにISO加盟各国を説得してまわった。これに対して、日本は漢字統合には国内的合意が得られないこと、既存の文字コードとの変換の際、粒度（字形の揺れの許容範囲）にずれが生じることを理由にあげ、ISO 10646とユニコードの合体に反対した。
日本の発議によって、漢字統合の是非を議論するために、CJK-JRG（CJK Joint Resarch Groupe, 中日韓合同検討委員会）という臨時機関が設置された。中日韓合同検討委員会は制度上はISOから独立していたが、ISO/IEC第一合同技術委員会第二専門委員会と密接な関係にあり、実質的にはその下部委員会といってよかった。
中日韓合同検討委員会には漢字文化圏諸国と地域（香港）の代表とユニコード関係者が参加したが、本格的な議論にはいる前に、ISO/IEC第一合同技術委員会第二専門委員会（ISO/IEC JTC1/SC2）でユニコードとの合体がどんどん既成事実化していったために、中日韓合同検討委員会は漢字統合の可能性を議論する場から、決定版の共通漢字セットを作る場に性格が変わっていった。ユニコード側が用意した漢字セット案は多くの問題があったので、中国が用意したHCC統合漢字表をベースに、中国のリードのもとにできあがったのがCJK統合漢字表で、2万902字を収載する。CJKとはChina、Japan、Koreaの略である（現在は字喃をもつヴェトナムがくわわり、CJKVといっている）。
CJK統合漢字表では符号に対応する日中韓台の字種・字体が四欄に併記され、対応する字種・字体がなかった場合は空欄になる。[図6]
統合漢字表には、その文字の原規格における符号が記載され、原規格との対応関係もISO/IEC 10646規格の一部となった。一度、統合漢字表に載ってしまうと、日本の常用漢字表制定のような国内事情があっても、その国の一存ではISO/IEC 10646との対応関係を変更できなくなるが、これは文字コードのたび重なる改訂に不満をもっていた国際的企業にとっては歓迎すべきことだったろう。
漢字の配列順は『康煕字典』の並び順を第一の拠り所とし、康煕字典にない字は日本の『大漢和辞典』を参照し、『大漢和辞典』で直前に置かれている字の次に挿入することになった。『大漢和辞典』にもない字は中国の『漢語大字典』、それにもない字は韓国の『大字源』を参照する。CJK漢字セットを構築する際に収集されたデータはUnihan.txtとして、ユニコード・コンソーシアムのサイトで公開されている（注10）。
ISO 10646の最初の原案は既存文字コードをそのまま収録していたので、既存文字コードによって符号化した文書をISO 10646原案に変換後、元の文字コードにもどしても、データが変るようなことはなかった。しかし、ユニコード化したISO/IEC 10646では、漢字統合のために元の文字コードとは粒度が異なっており、往復変換をおこなうとデータが変ってしまう怖れがあった。
たとえば、台湾のCNS 11643では「」と「高」は独立の文字としてあつかわれているが、当初のユニコードは「」と「高」を統合していたので、CNS 11643→ユニコード→CNS 11643という往復変換をおこなうと、「」が「高」に化けてしまう。
粒度のズレを問題にしていた日本はISO加盟国の公的規格で独立の文字としてあつかわれている漢字は、統合すべき範囲であっても、別字としてあつかうことを提案し、了承された。これを原規格分離漢字という（注11）。
互換性の問題から別字あつかいが望ましい漢字の中には、原規格分離漢字としてはいれにくい字もあった。
前章でふれたように、KS C 5601では「丹」のような複数の読みをもつ漢字を、読みごととに重複登録している。往復変換による文字化けを避けるには別字としてあつかうしかないが、一国の言語文化の特殊事情によるものとはいえ、まったく同一の漢字に重複して符号をあたえることには強い反対があった。
また、日本IBMは自社の大型機との情報交換のためにJISに追加したIBM拡張漢字のうち、「驕vのような異体字（こちらが本来の字体だが）を独立の文字として収録するよう、カナダを通じて要請した。
こうした字は原規格分離漢字と同列にあつかうわけにはいかなかったので、制限領域（Rゾーン）に互換漢字という特別区画を設けて収録した（注12）。
原規格分離漢字との違いは、互換漢字の字体は統合漢字の中に包含されている点である。たとえば、U+9686は日本欄こそ一本足りない「隆」だが、他の国の欄では本来の「驕vとなっている。U+9686は「驕vと「隆」を統合している以上、U+F9DC として収録されているIBM拡張漢字起源の「驕vは、互換性維持のためだけに用いられる例外的な字で、ISO/IEC 10646環境では「限りなく使用禁止に近い」と位置づけられていた。ただし、ここにもさらに例外があって、「ｱ」、「宦vなどは統合漢字に準ずる字と付属書で規定された、使用が認められていた。
なお、互換漢字の例示字形は一つだけで、各国欄が並べられない併記がおこなわれないという点も、原規格分離漢字とは異なる。この時点では互換漢字は粒度をもたなかったのである。
CNS 11643は1992年に3〜7面が追加され、統合範囲内の異体字が多数収録された。CNSの新たな異体字は日本欄の字体と重なるものが多かったので、原規格分離漢字とするのは無理だった。互換漢字としてなら収録可能なはずだったが、互換漢字の追加は許されなかった。ところが、2000年になると、拡張A審議の最終段階で互換漢字の位置づけが大きく変り、追加が事実上解禁されることになった（次章参照）。
なお、BMPには6400字収用の大きな外字領域があるが、原規格分離漢字や互換漢字として収録するわけにはいかない非公的文字コードの異体字を、ここに外字として配置することになっていたという説がある（注13）。
日本は統合漢字の継続的なメンテナンスの保証をもとめ、国際的に承認された。メンテナンスにはIRG（Ideographic Rapporter Groupe、漢字連絡会）があたることになった。
中国は1万字の漢字追加を提案したが、そのスペースにはハングル完成形（注14）を収録することになってしまったので、まとまった空きとしてはハングルのはいっていた6千500字余のスペースしか残っていなかった。中国は1万字追加に固執したが、漢字合成の可能性を検討するという条件で妥協がはかられ、追加字数は1万字から6千500字余に圧縮された。これが後の拡張Aの原形である。
しかし、漢字合成は技術的に難点がある上に、部首（正確には「漢字構成記述文字」）の勝手な組み合わせによって、実際には使われたことのない漢字もどきが大量に生まれかねなかった。といって、部首の組み合わせを厳密に規定すると、漢字を一字一字収録するのと同じことになってしまい、正攻法の漢字拡張をとった方が、技術的にも規格としても安定する。正攻法での漢字拡張を粘り強く主張していた日本は漢字合成を空文化する動議を提出し、国際的な了解をとりつけた。
この頃には漢字以外にも文字追加要求があいついでおり、BMP外へ拡張することが必要という国際的なコンセンサスが醸成されていた。しかし、32ビットのUCS4に移行するには抵抗が多く、といってISO/IEC 2022のような文字面切り替え方式（注15）をとるのも無理という八方塞がりの状況だった。
窮余の策として、ユニコード側によって提案されたのがサロゲートペア（代理ペア）と呼ばれる拡張法である。
サロゲートペアでは、UCS2の16ビット符号を二つ組みあわせることで一文字をあらわす。外字領域の直前に拡張用の領域を設け、U+D800〜U+DBFEの範囲の1024の符号を第1バイト、U+DC00〜U+DFFFの1024の符号を第2バイトとする。1024×1024=104万8476字が収容できるが、これは6万5千字収用可能な16ビットの文字面の16面分にあたり、BMP（第0面）につづく第1〜16面に見立てる。この工夫によって、UCS2内の符号だけで100万字の拡張が可能になったわけである（16ビット符号だけなので、システムの改造は最小限ですむ）。
サロゲートペアはISOではUTF-16と呼ばれるが、ネットワークにデータを流すために考案された他のUTFとは違い、あくまでUCS2の収録文字数を増やすための便法である。UTF-8に変換する場合は、サロゲートペアのままではなく、一度、UCS4の符号にもどしてから変換する。
漢字に関しては、2000年に旧ハングル領域を使った6582字の漢字追加がおこなわれた（拡張A）。つづいて2001年、UTF-16（サロゲートペア）で使えるようになった第2面（Supplementary Ideographic Plane、補助漢字面）に拡張Bとして4万2711字が追加された。
IRG（漢字連絡会）では漢字文化圏の盟主を自認する中国の積極的な姿勢が目立ち、拡張Bの規格票やグリフは中国側が用意した。拡張Bから各国の例示字形併記をやめ、中国の字形を掲げるのみになったのは、中国の積極策と無関係ではないだろう。
ISO/IEC 10646は誕生からわずか8年間で、当初の構想をはるかに超える7万字近い巨大漢字セットをかかえこむ結果となった。目下、拡張Cの準備が進んでいるが、拡張Cは第2面の残りを埋める2万2千字の拡張C-1と、第3面を使う拡張C-2の二段階にわけて追加されるようである。近い将来、UCS漢字が10万字を超えるのは確実である。
国際規格になったとはいっても、UCSは16ビットないし32ビットを1バイトとする新しい構造の文字コードなので、対応するソフトウェアがなかなか増えなかった。
中国は1995年にGBK（拡張GB 2312という意味の通称で、正式には「漢字内碼拡展規範」）という内部コードの仕様を発表した。
GBKはEUC-CNの空きに、GB 2312未収録のUCS漢字をマッピングした文字コードで、GB 2312の上位互換になっている。フォントをGBK対応のものに交換しさえすれば、従来のシステムでUCS漢字がすべて使えるようになったので、広く普及した（台湾のBig5+、韓国のHCNも類似の拡張である）。
しかし、2000年にUCSに拡張Aが追加されると、問題が起きた。GBKのためにEUC-CNの空きはほぼ埋まっており、6千字を超える拡張Aをいれるスペースがなかったのである。
UCS漢字は拡張B、拡張Cと増補が予定されていたので、中国は2000年にGB 18030という新たな文字コードを国家標準とした。GB 18030はGBKのわずかに残った空き番号を先頭バイトとして4バイトコードを構成するもので、GB 2312およびGBKの上位互換となっている。[図8]GB 18030は新たな文字コードというよりは、ASCII互換のUTF-8に対抗するものと考えた方がよさそうである。
|
| 1stバイト | 2ndバイト | 3rdバイト | 4thバイト | |||
|---|---|---|---|---|---|---|
| 1バイト領域 | 94字 | 33-126 | ASCII互換 | |||
| 2バイト領域 | 23,940字 | 129- 254 | 64-126 128-254 | GBK互換 | ||
| 4バイト領域 | 1,587,600字 | 129- 254 | 48-57 | 129-254 | 48-57 |
日本の場合、デファクト標準化していたシフトJISには4千字ほどの空きしかなかった。しかも、Windows外字のようにベンダーが空きの一部をシステム外字に使っていたために、GBKのような拡張は不可能で、ユニコード実装による正攻法の拡張を選ぶしかなかった。
ユニコードで内部処理をおこなっている製品でも、OSによっては搭載フォントの収録字にかなりの異同がある。
OSの標準フォントにはいっていない文字は、正式のUCS漢字であるにもかかわらず、そのOSでは表示されず、日本語情報交換の障害となっている。こうした文字は特定OSの標準フォントにはいっていないだけで、ISO 10646においては国際的な合意にもとづく符合位置があたえられている以上、機種依存文字とははっきり異なる。WindowsからMacintoshに移植したソフトウェアにWindowsと同じフォントを附属させるというような力まかせの解決法もあるが、そのソフトウェアのはいっていない機械では状況は変らない。
JISではこの問題をどう考えているのだろうか？ ISO/IEC 10646-1を国内規格化したJIS X 0221-1:2001の解説の「3.5.3 J欄の字形の有無」には次のように書かれている。
この規格の統合漢字の詳細符号表でJ欄に字形が示されていない符号化文字について、“その文字は我が国では使用できない。”、“その文字を国語の表記に用いることは誤りである。”などとする解釈を見ることがあるが、それらは誤りである。この規格がJ欄に対応する字形を示していない特定の符号化文字を、我が国の国内の利用で、国語の表記のために用いることを、この規格は禁止していない。J欄に字形を示していない統合漢字の中には、例えば、ある種の中国簡体字のように、我が国で国語の表記に用いることが考えにくいものも含まれている。しかし、規格の上では、Ｊ欄が空であっても、その文字を用いることが適切であれば自由に使ってよい。
情報処理学会試行標準となる「日本コア漢字」のような試みもあるが、日本語表記似に必要な共通文字レパートリーを確定することが緊急に必要だろう。なお、近代の文学作品の電子化については、僻字はUCSのおかげで使えるようになったのに、むしろ見慣れた字のいわゆる康煕字典体がJ欄にないために、依然として使えないという問題がある（該当するのは千数百字だが、平成明朝フォントでは「FDPC追加文字」として、すでにフォント化されている）。
Copyright 2004 Kato Koiti