528

システム/制御/情報，Vol. 45, No. 9, pp. 528–535, 2001||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

解説

日本における最新文字コード 事情 (前編)
※本原稿は著者によるゲラ刷りであり，最終稿とは異なっている．
本原稿を引用する場合は，必ず印刷された最終稿を確認すること．

安岡 孝一*||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

1.

文字コード 前史の名に用いることのできる漢字は，さらに 92 字が追加されることになった．

1946 年 11 月，当用漢字表 [1,2] が告示された．この加えて 1954 年 3 月に，国語審議会から当用漢字補正

表は，前文に「現代國語を書きあらわすために，日常使用する漢字の範囲を，次の表のように定める」とあると

案 [8] が報告されるに至って，日本の漢字制限はグラグ

おり，漢字制限を主眼としたものである．すなわち，日ラと揺らぎ始めるのである．

本で用いる漢字は，この表の 1850 字に制限するという

文字コード の黎明期

2.

のが，当用漢字表の最大の目的である．文字コード の立場から考えた場合，使用する漢字の数が制限されている

1950 年 11 月に中川機械 (現，松下冷機) と毎日新聞にというのは，有限のビット数で漢字を表すことができる

よって，日本初のリモートコントロール邦文モノタイプという点で，非常にうれしい．この漢字制限が徹底され「 SC-R 」が開発されて以後，日本では数多くの漢字テレていたならば，日本の文字コードはもっと簡単なものにタイプや電算写植機が製作されていた．これらにおいてなっていただろう．しかし ，当用漢字表の漢字制限は，は，各社が各様の文字種や漢字コードを用いていたため，いくつかの点で不徹底であった．一つは字体に関してで会社が違えば互いにデータ交換できないというシロモノ

あり，当用漢字表の字体は，簡易字体といわゆる旧字体であった．1960 年代までは，それでも特に問題はなかっとが混然となったものであった．もう一つは，まえがきたのである．当時のテレタイプやネットワークは，基本に「固有名詞については，法規上その他に関係するとこ的に各社がそれぞれ社内でだけ用いるものだったからでろが大きいので，別に考えることにした」とあるとおり，ある．会社をまたいでデータ交換をおこないたい場合は，人名や地名にはこの漢字制限を及ぼさなかったという点

例えば 1959 年 8 月に制作された 6 社協定新聞社用コーである．

ド 表 (CO.-59)[9] のように，交換用の文字コード を決めておいて，それをオペレータが打ち直せば，特に大きな

当用漢字字体表 [4] は，当用漢字表の簡易字体をさらに問題はなかったのである．

徹底させるために，1949 年 4 月に告示されたもので，当

実際，1969 年 6 月に制定された JIS 初の文字コード 1で用漢字表の各漢字に一対一に対応する 1850 字の表である．これにより，例えば，当用漢字表での「國」は「国」「 鬪」は「 闘」に，それぞれ字体に，「 漢 」は「 漢」に，まれていなかった．JIS C 6220 は，基本的には 8 ビットの文字コード 2であり，02/1 〜 07/14 (16 進数で書くとが改められた．あるいは，当用漢字表で既に簡易字体に21 〜 7E) にはローマ文字3 ，10/1 〜 13/15 (16 進数で書くと A1 〜 DF) には片仮名，00/0 〜 02/0 および 07/15(16 進数で書くと 00 〜 20 および 7F) には制御文字が収録されていた．ただし ，JIS C 6220 に漢字が含まれていなかったのには，別に大きな理由がある．JIS は文字
コード の開発に際して，国際規格 (ISO) との整合性を第なっていた「 礼 」(原字は「禮」) は，当用漢字字体表では「礼」に改められた．当用漢字字体表によって，当用漢字表に掲げられた字体は全て改められ，日本で用いることのできる漢字は 1850 字に制限されたはずだった．
ところが，人名はそうはいかなかった．司法省 (現，法務省) は 1948 年の時点では，子の名に用いることのできる漢字として，当用漢字表の 1850 字のみを認めてい1

た [3]．だが当用漢字字体表が告示されるに至って，当用漢字表と当用漢字字体表の両方を，子の名に用いることのできる漢字とみなしたのである [5,6]．この結果，字体が改められたはずの「國」も「 漢 」も「鬪」も「 礼 」も，「国」や「漢」や「闘」や「礼」と共に，子の名として用いることができるということになったのである．その上，1951 年 5 月に人名用漢字別表 [7] が告示された結果，子∗ある JIS C 6220 (現，JIS X 0201) には，漢字は全く含

これに先行して 1961 年 11 月に，JIS C 0803 印刷電
信機のケン盤配列および符号 (1987 年 3 月 JIS X 6001に改称) が制定されているが，当時の国際的文字コード だった International Telegraph Alphabet No.2 とも互換性がなく，結局 1994 年 6 月に廃止されている．
2
7 ビット版も規定されているが，ここでは割愛する．
3
03/0 〜 03/9 が数字，04/1 〜 05/10 が英大文字，06/1〜 07/10 が英小文字で，残りは特殊文字である．05/12の「￥」，07/14 の「￣」を除いて，ASCII と同じである．

京都大学人文科学研究所附属漢字情報研究センター– 26 –

安岡孝一：日本における最新文字コード 事情

529

一に考えていた．文字コードは国内のみのデータ交換に

字4 ，1973 年 8 月現在の大蔵省主計局収容漢字表 4276

とど まるものではない，という認識からである．JIS C

字，1973 年 8 月現在の国立国会図書館収容漢字表 3956

6220 にしても，10/1 〜 13/15 の部分に，日本で最低限必要な片仮名を追加しているが，00/0 〜 07/15 の部分
で ISO 646 と整合性を保っている．しかしながら JIS は，字5 ，1973 年 8 月現在の日本生命収容人名漢字 3044 字，

国際規格と整合性を持った漢字コード の開発を，あきら

1972 年度の国土行政区画総覧使用漢字 3251 字，の 8 つの表の対応を作り，官報における漢字の使用頻度 (1972年) を加えて，行政管理庁が作成したものであった．こめていたわけではない．日本が必要とする漢字コードに，の資料に基づき行政管理庁は，行政情報処理用標準漢字

国際規格の方を合わせるべく，虎視眈々と狙っていたの(案)6 2817 字を選定していた7が，それはこれらの表に現である．

れる頻度が高い漢字を集めたものであった．例えば「椣」

その頃 ISO では，ISO 646 の 21 〜 7E の部分に，別のや「樮」や「樶」は，この資料によれば，国土行政区画

文字コードを呼び出すための仕掛けを，国際規格として総覧使用漢字に「頻度 1 」で現れるのみであったことか

開発中であった．この 94 字の部分を切り替えることで，ら，行政情報処理用標準漢字 (案) には含まれていなかっ複数の文字コードを扱えるようにする仕掛けである．したのである．

かし，漢字を含む文字コードを考えると，94 字ではあまところが，この資料に対する漢字符号標準化調査研究りに少ない．1971 年 10 月に情報処理学会漢字コード 委

委員会の視点は，行政管理庁とは異なっていた．委員会

員会が報告した標準コード 用漢字表 (試案) ですら，6086

は，「 椣」や「樮」や「樶」が日本の地名に使用されてい字を含んでいた1ので，単純に計算しても 65 種類の文字

る8ならば ，これらを日本の漢字コード 規格に収録すべ

コードに漢字を分散し，それらを次々に切り替えながらきだと考えたのである．そこで委員会は，この資料から，使うしかない，ということになってしまうのである．そもっと大きな漢字集合を制作することにした．すなわち，

こで JIS は ISO に対し，この 94 字の部分に，複数バイ

行政情報処理用標準漢字 (案) と情報処理学会漢字コード

トの文字コードを呼び出せるよう提案した．すなわち 94

委員会標準コード 用漢字表 (試案) を合わせた上に，地名

× 94=8836 字，94 × 94 × 94=830584 字，あるいはそとして国土行政区画総覧使用漢字を，人名として日本生

れ以上の字数を収録可能な文字コードを使えるようにし

命収容人名漢字を，全て加えた漢字集合を制作したので

よう，というアイデアであり，日本はこれで漢字コードある．

を開発しようと考えたのである．結果としてこの提案はさらに ，この漢字集合を第 1 水準と第 2 水準に分け承認され，国際規格 ISO 2022 に取り入れられることとるために，委員会は全部で 37 の漢字表を集めた．それ

2なり，さらにその翻訳規格 である JIS C 6228 (現，JISら 37 の漢字表から 2934 字を抽出した後，当用漢字字体

X 0202) が，1975 年 3 月に制定された．これで，94 字

表 [4]，当用漢字補正案 [8]，人名用漢字別表 [7]，都道府を超える字数を収録可能な文字コードが，国際規格に整県名，当時の市区町村名および郡名，を加えて9 第 1 水準合する形で開発可能となったのである．

とした．そして，先の 4 漢字表で制作した漢字集合から，
第 1 水準の漢字を除いて第 2 水準としたのである．この世界初の ISO 準拠複数バイト コード

3.

上で，第 1 水準の漢字は五十音順，第 2 水準の漢字は康1974 年 4 月，日本情報処理開発センター (現，日本情煕字典順とすることが決められ，その順序に並べるとい報処理開発協会) でおこなわれた漢字符号標準化調査研

う作業がおこなわれた．

究委員会に，行政管理庁行政管理局 (現，総務省行政管

これら第 1 水準，第 2 水準の漢字に，数字，ローマ字，理局) から，一つの分厚い手書き資料が提出された．行

平仮名，片仮名，ギリシア文字，ロシア文字，そして 108

政情報処理用標準漢字選定のための漢字使用頻度および個の特殊文字を加え，JIS C 6228 に準拠するように 94

対応分析結果，という長い名前のその資料は，情報処理

4[10,24] によれば，この時点での漢字数は 1861 字のはずである．
5[11] によれば，漢字は 3965 字収容されていたはずである．
6
翌年，行政情報処理用基本漢字という名称になった．
7
実際の資料作成および漢字選定は，受託先である谷村
株式会社新興製作所 (現，新興製作所) がおこなった．
8「椣」に関しては，奈良県生駒郡平群町に椣原 (しではら ) という地名がある．
「 樮」に関しては，和歌山県日高郡印南町に樮川 (ほくそがわ ) という地名がある．し

学会漢字コード 委員会標準コード 用漢字表 (試案) 6086
字，6 社協定新聞社用コード 表 (CO.-59) 1985 字3 ，1973
年 8 月現在の内閣調査室収容漢字表 3181 字，1973 年

8 月現在の日本科学技術情報センター収容漢字表 186412[12] には，なぜか，漢字 6100 字とある．
ISO の規格は，基本的に英語かフランス語で書かれている．これに対し日本では，対応する JIS を制定する

かし，「 樶」を含む日本の地名は発見されておらず，岡山市の?(さい) を誤った可能性が考えられる．
9
作業漏れがあったらしく，例えば，千葉県印旛郡や熊本県菊池郡泗水町は，第 1 水準だけでは書けなかった．

ことになっている．
3[9] によれば，漢字は 1987 字 (漢数字の「〇」を含む)である．

– 27 –

530

システム/制御/情報

第 45 巻

第9号(2001)× 94 の形に並べた文字表が，漢字符号標準化調査研究委

用頻度および対応分析結果を典拠としたため，日本国内員会の報告書 (1976 年 3 月) にまとめられた．この後，委の実際の地名とは乖離してしまったことである．例えば，

員会は JIS の委員会として作業を継続し，1976 年 6 月に鹿児島県の吐?喇 (とから) 列島の「 ? 」は，JIS C 6226

告示された人名用漢字追加表 28 字 [13] への対応や，JISに含まれていなかった．沼津市の?町 (くまたかちょう)，10

C 6228 で用いるエスケープシーケンスの取得 などを岡山市の?(さい) など も，JIS C 6226 では書けなかっ

おこない，1978 年 1 月に JIS C 6226 (現，JIS X 0208)

た．あるいは，「 樮」が JIS C 6226 の 60 区 51 点に収録を制定した．
「 通常の国語の文章の表記に用いる図形文字

されていても，この字がど ういう読みでど ういう用例がの集合とその符号」としての，世界初の ISO 準拠複数バ

あるのかは，ほとんどの人には全く謎だったのである．
さらなる問題は，JIS C 6226 における人名に関する

イトコード の誕生である．

JIS C 6226 では，94 × 94 の文字表の各符号位置は，
1 区 1 点から 94 区 94 点までの区点番号で示されており，
7 ビットあるいは 8 ビットコード の 21 〜 7E の部分に呼び出して用いることが想定されている．区は 1 バイト目，
点は 2 バイト目に対応し，21 〜 7E の部分に呼び出された時，例えば 16 区 1 点の「亜」は 30 21 という 2 バイトで表される．なお，特殊文字は 1 区 1 点〜 2 区 14 点，
数字は 3 区 16 〜 25 点，英大文字は 3 区 33 〜 58 点，英小文字は 3 区 65 〜 90 点，平仮名は 4 区 1 〜 83 点，片仮名は 5 区 1 〜 86 点，ギリシア大文字は 6 区 1 〜 24 点，
ギリシア小文字は 6 区 33 〜 56 点，ロシア大文字は 7 区
1 〜 33 点，ロシア小文字は 7 区 49 〜 81 点，第 1 水準の漢字は 16 区 1 点〜 47 区 51 点，第 2 水準の漢字は 48 区
1 点〜 83 区 94 点に，それぞれ収録されており，残りの扱いが，当時の法務省の扱いとは必ずしも合致していな
かったことである．一例を挙げよう．
「 富」と「冨」は「人名で使い分けられている」ことから，41 区 57 点と 41 区

58 点という別々の符号位置が与えられている．これに対し，「 巣」と「 巣 」は「字形の違いがわずかであると認める」ことから，33 区 67 点という符号位置に合併されて「 富」と「冨」は書き分いる．つまり，JIS C 6226 では，けることができるが，「 巣」と「 巣 」は書き分けられないのである．ところが，当時の法務省の基準では，「 冨」は子の名に用いることができなかったが，「 富」や「巣」や「 巣 」はいずれも子の名に用いることができた3 ．つまり，「巣」と「 巣 」は，子の名において使い分けることができるにもかかわらず，JIS C 6226 では使い分けることができなかったのである．

符号位置は空きである．

このような問題を，開発当初から内包していたため，

このように，多大な労力を傾注して開発された JIS C

シフト JIS と呼ばれる規格違反の符号化や，外字による

6226 だったが，開発当初の時点で既に重大な問題をいく
つか抱えていた．一つは，JIS C 6226 が，JIS C 6220

文字化けが，JIS C 6226 にはつきまとうことになるのである．

の上位互換になっていなかったことである．そもそも当

常用漢字表と人名用漢字許容字体表

4.

初の計画では，JIS C 6226 の 1 区にはローマ文字，2 区には片仮名，3 区には平仮名，そして 4 区以降に漢字を当用漢字表，当用漢字字体表に 代わ るものとし て ，

収録する予定だった．つまり，JIS C 6226 の 1 〜 2 区は，1981 年 10 月に告示されたのが，常用漢字表 [16] である．

JIS C 6220 のローマ文字および片仮名の部分と上位互換にする計画だった．ところが，実際の JIS C 6226 では，英数字だけは JIS C 6220 と上位互換となるように
3 区にまとめて収録された1 ものの，「 ! 」や「 ? 」のような特殊文字は 1 区にバラバラに収録され 2 ，片仮名は 5 区に JIS C 6220 とは異なる順序で収録された．この結果，
JIS C 6226 は JIS C 6220 の上位互換ではなくなってしまい，JIS C 6220 のデータは，JIS C 6226 に変換でき

この表は，前文に「一般の社会生活において現代の国語「燈」から「灯」への字体変更と，95 字の追加となってなくなってしまったのである．

いる．また，常用漢字表のうち 355 字には，
「 いわゆる康を書き表すための漢字使用の目安」とあるとおり，制限ではなく，あくまで目安である．すなわち，1946 年以来おこなわれてきた 1850 字の漢字制限はこれで終わりを告げ，新たに 1945 字の目安が登場したのである．なお，
当用漢字字体表の 1850 字中 1849 字に関しては，常用漢字表ではそのままの字体が踏襲されており，現実的にはもう一つの問題は，JIS C 6226 が地名に関して，二次熙字典体」が括弧書きで添えられている．
「 これは明治以資料である行政情報処理用標準漢字選定のための漢字使来行われてきた活字の字体とのつながりを示すために添えたものであるが，著しい差異のないものは省いた」と

10

エスケープシーケンスは，「 ESC 2/4 4/0 」(16 進数で書くと 1B 24 40) だった．
1
21 〜 7E に呼び出された時，「 0 」〜「 9 」は 23 30 〜 23
「 A 」〜「 Z 」は 23 41 〜 23 5A に，「 a 」〜「 z 」
39 に，
2

説明されている．
これに合わせて法務省も，子の名に用いることのできる漢字に関して，扱いを変更することになった [15]．概3は 23 61 〜 23 7A になる．
特に，JIS C 6220 では 1 つの符号位置 02/2 に合併されている「 」と「 」が，JIS C 6226 では 1 区 40 点と 1 区 41 点に分離されてしまった [14]．

当用漢字表に「富」と「 巣 」が，当用漢字字体表に「富」と「巣」が含まれていたが，「 冨」はこれらの 2 表，人
名用漢字別表，人名用漢字追加表のいずれにも含まれていなかった．

– 28 –

安岡孝一：日本における最新文字コード 事情

531

要は以下のとおりである．

「 礼 (禮) 」という形の括弧書きを持っていたことから ，(1) 当用漢字字体表が廃止され，常用漢字表がそれに代わるものとなったことから，常用漢字表 1945 字「國」「巣」「 類 」は人名用漢字許容字体表に収録さ「 漢」を全て子の名に用いることのできる漢字とする．

以上，述べてきたとおり，常用漢字表の告示は，こと(2) 従前の人名用漢字別表 92 字と人名用漢字追加表 28
字から，常用漢字表に採用された 8 字を除き，新
たに 54 字を追加して，166 字の人名用漢字別表と人名においては，当用漢字表と当用漢字字体表の差異を「禮」) は収録されなかった．
れ，「 鬪」「 礼 」(および「 ? 」

浮き彫りにすることになった．この解決策として登場したのが，人名用漢字許容字体表だったのである．

する．

シフト JIS の誕生

5.

(3) 当用漢字表 1850 字のうち，常用漢字表に括弧書きで添えられた 195 字に，従来，子の名に用いることができるとされていた 10 字を加え，205 字を人1982 年 4 月，三菱電機から日本初の 16 ビットパソコン「 MULTI 16 」が発売された．暫定的な独自拡張を施した CP/M-86 を OS とするパソコンだったが，OS レベ

名用漢字許容字体表とする．
すなわち，従来の当用漢字字体表，人名用漢字別表，人ルで漢字をサポートしている2という点で画期的だった．

名用漢字追加表に含まれていた漢字は，基本的にそのまこの独自拡張のために開発された文字コード [17,18] が，ま子の名に用いることができるが，当用漢字表に含まれシフト JIS の原型だったのである．
シフト JIS は，JIS C 6220 の隙間に JIS C 6226 の文ていた漢字に関しては，扱いが変わったのである．この字を埋め込んだ 8 ビット 1 〜 2 バイトコードである．す点に関して，多少，細かい解説を加えよう．
常用漢字表が 登場する以前は ，当用漢字字体表も当

なわち，JIS C 6220 の 00 〜 7F と A1 〜 DF はそのまま

用漢字表も，いずれも子の名に用いることができるといにして，94 × 94 の JIS C 6226 の文字表を (31+16) ×

うことになっていた．
「 漢」や「国」や「巣」や「闘」や(63+125) の形に変形し ，1 バイト目には 81 〜 9F と E0「類」や「礼」と共に，「 漢 」も「國」も「 巣 」も「鬪」も〜 EF を，2 バイト目には 40 〜 7E と 80 〜 FC を用いるの「 類 」も「 礼 」も子の名に用いることができたのは，先にである．JIS C 6226 の区点番号との対応は，81 40 が述べたとおりである．ところが当用漢字表が廃止された

1 区 1 点3 ，81 41 が 1 区 2 点，…，81 7E が 1 区 63 点，
81 80 が 1 区 64 点，…，81 9E が 1 区 94 点，81 9F が 2
区 1 点，…，81 FC が 2 区 94 点，82 40 が 3 区 1 点，…，
9F FC が 62 区 94 点，E0 40 が 63 区 1 点，…，EF FC が94 区 94 点となっている．
開発当時のシフト JIS は，単に JIS C 6226 の規格違反の実装の一つに過ぎなかった．しかし，1982 年 12 月に「 MULTI 16 」の日本語 CP/M-86 が完成4し，同じ月に東京芝浦電気 (現，東芝) の「パソピア 16 」に搭載された MS-DOS ver2.0 漢字版が，やはりシフト JIS を採用したことで，日本の 16 ビットパソコン市場は，急速にシフト JIS に傾いていったのである．

「國」
「巣」
「鬪」
「類」
「 礼」
ことによって，これら「 漢 」などに対する扱いをど うするかが，問題となったのである．この問題に対する一つの解決法は，このような漢字を，子の名に用いることを一切認めない，とするものである．しかしこの解決法は，従前に用いることができた
字体を一気に否定することになり，あまりに非現実的である．これとは逆のもう一つの解決法は，このような漢字を全て，引き続き子の名に用いることができる，とするものである．しかしこの解決法は，既に廃止された当用漢字表を，引き続き根拠として認めることになり，非常にまずい．
結局のところ，民事行政審議会がこの問題に対して

JIS C 6226 の 1983 年改正

6.

取った解決法は，上記の二つの解決法のいずれとも異なっ

工業標準化法第 15 条により，日本工業規格 (JIS) は，
5 年毎に見直しをおこなうことが定められている．そのていた．審議会の結論は，このような漢字のうち，常用漢字表に括弧書きで添えられているものに限り，子の名に用いることを認める，というものである．すなわち，際に，改正・廃止の必要があれば改正・廃止し，なけれ

この時点で用いることができた字体をある程度残しながば確認をおこなう，ということになっている．1978 年 1

ら，根拠としては常用漢字表の括弧書きの字体，すなわ

月に制定された JIS C 6226 に対しても，1983 年の見直

ち常用漢字表が著しい差異があるとした字体を用いる，

しの際に，常用漢字表や人名用漢字別表の影響が問題とというものであり，これに基づいて作成されたのが，人なり，1983 年 9 月に改正がおこなわれた．この改正は，

1

1978 年版の JIS C 6226 と「できるだけ互換性を保つ

「國」
「 巣」
「鬪」
名用漢字許容字体表である ．先の「 漢 」「 礼 」を例に取ると，これらに関する常用漢字はそ「 類」

2「国 (國) 」「巣 (巣) 」「闘 (?) 」「類 (類) 」
れぞれ「漢 (漢) 」
1

民事行政審議会は [2] を参照しておらず，その結果「敍」([2] で「敘」に訂正された) が，人名用漢字許容字体表に含まれてしまっている．

– 29 –

CP/M-86 上で動作する M-BASIC plus では漢字が使えたが，CP/M-86 無しに動作するスタンド アロン版
M-BASIC では漢字は使えなかった．
3[17,18] によれば，1 区 1 点の間隔だけは特別に 20 20を使うこと，となっていた．
4
かな漢字変換が，OS レベルでサポートされた．

532

システム/制御/情報

第 45 巻

第9号(2001)

ように努力した」はずだったが，結論から言うと，文字C 6226 では「字形の違いがわずかであると認めるもの」

コード の改正にしては非互換な変更があまりに多く，そのままで放置してしまったのである．この時点で，常用の後の日本の文字コード の混乱を引き起こす最大の原因

漢字表の括弧書きの字体に対する JIS の見解は，一般のとなった．

社会と齟齬をきたすことになった，と言っても過言ではない．

非互換な変更の中で，最も大きな混乱を引き起こした

JIS C 6226 の 1983 年改正における，もう一つの大きのは，既存の文字の符号位置に対する変更である．例えば「堯」は，1978 年版の JIS C 6226 では 22 区 38 点にな非互換変更は，常用漢字や人名用漢字以外の漢字に対収録されていたが，1983 年版ではこれを 84 区 1 点に移して，字形を大きく変えてしまったものがある，という

動してし まった．さらに 1983 年版では，22 区 38 点にことである．これは「常用漢字等の字形との整合を図る「 尭」を収録したのである．このような変更をおこなっことを目的としたもので，別の文字概念を採用したわけ

1

た理由は，
「 常用漢字等 では，新字体を第 1 水準に，旧ではない」と解説にはあるが，元の字形が JIS C 6226

字体を第 2 水準におく」という原則を，新たに人名用漢から消滅してしまったという点で，先の例よりさらにタ

字別表に追加された「尭」に対しても適用しようとした

チが悪い．例えば，18 区 10 点の「 鴎 」は「鴎」に，32

ため [19] である．しかしこれは，既存の文字の符号位置

区 70 点の「 蝉 」は「 蝉」に字形が変更された．あるいを変更してはならない，という文字コード の大原則を，は，39 区 25 点の「 嚢 」は「嚢」に変更されたが，この結無視したものである．このような符号位置の変更をおこ果，兵庫県美嚢郡が JIS C 6226 では書けなくなるとい

なえば，それ以前に蓄積されたデータに対する互換性がう，致命的な事態が起こっている．1978 年の制定時に，完全に失われ，文字コード 規格そのものに対する信頼性

都道府県名，市区町村名および郡名を第 1 水準に補充しが，破壊されることになるのである．

た，という事実を，解説に記しておきながら，1983 年のしかも「常用漢字等では，新字体を第 1 水準に，旧字改正では，当時の郡名や市区町村名が書けなくなる可能

体を第 2 水準におく」という原則を守ろうとした，とい性すら，全く考慮に入れない変更をおこなってしまったう説明自体も非常にアヤシイものである．例えば，
「 瑤」

のである．

は 64 区 86 点から 84 区 4 点に移動させられ ，64 区 86

以上述べてきたように，JIS C 6226 の 1983 年改正

点には代わりに人名用漢字の「瑶」が収録された．しかは，文字コード の改正としてはあまりに非互換なものでし，そもそも 64 区 86 点も 84 区 4 点も第 2 水準であり，あり，かつ一般の社会の文字通念からも乖離したもので

第 2 水準内で文字を移動するということを，平気でおこあった．JIS C 6226 の当初の設計意図も，JIS C 6228 がなっているのである．あるいは，41 区 16 点の「檜」と規定する文字集合の概念も，ましてや常用漢字表と人名

59 区 56 点の「桧」は，1983 年版では入れ替えられてしまった．
「 檜」が 59 区 56 点に，「 桧」が 41 区 16 点に，そ

用漢字別表および人名用漢字許容字体表の関係も，全くれぞれ移動させられてしまったのである．しかし ，「 桧」

疑念すら持たれる．この結果，JIS C 6226 の 1983 年版

も「檜」も人名用漢字ではない．もちろん，常用漢字では，1978 年版とは全く違う文字集合であるとみなされ，もない．しかも，この入れ替えによって，東京都西多摩1978 年版とは異なるエスケープシーケン ス (ESC 2/4
4/2) が付与されるという結果になった．その上，日本電気など 一部のメーカーが 1983 年改正に従わず，1978 年
版の JIS C 6226 の実装を続けるという，異常な事態に理解しないまま改正をおこなったのではないか，という郡檜原村が，第 1 水準だけでは書けなくなってしまった，というオマケ付きである．
その上，非常に不思議なことに，JIS C 6226 の 1983
年改正は，1981 年 10 月に施行された人名用漢字許容字

発展していくのである．

体表に対しては，一瞥もくれていない．JIS C 6226 の7.

「常用漢字等では，新字体を第 1 水準に，旧字体を第 2 水JUNET コード と EUC

準におく」という原則とやらは，人名用漢字別表と人名

1984 年 10 月，日本のインターネットのさきがけとな

用漢字許容字体表との間には，全く適用されなかったのる JUNET が ，慶応大学と東京大学と東京工業大学をである．
「 巣」と「 巣 」は相変わらず 33 区 67 点に合併さ結ぶことで，スタートした．JUNET において，JIS C

れていたし，「 漢」と「 漢 」は 20 区 33 点に合併されたま

6220，JIS C 6226，JIS C 6228 の，いずれも 1982 年以前の版を元に考案されたのが，当時の JUNET コードで
「 1B 24 40 」を漢字イある．当時の JUNET コード は，ン，「 1B 28 48 」を漢字アウトとして，21 〜 7E の部分を切り替える 7 ビットコード であった．7 ビットコード を採用したのは，ARPA インターネットでのテキストメッ
セージ (すなわち電子メール) が，RFC 822 (現，RFC2822) によれば ，7 ビットの ASCII だったからであり，まだった．
「 国」と「國」はそれぞれ 25 区 81 点と 52 区 2点という別の符号位置が与えられていたが，これは 1978年の制定時からのもので，別に 1983 年の改正時に変更したわけではない．すなわち，例えば「巣」と「 巣 」は，
常用漢字表が字体の差異を認めているにも関わらず，JIS
1

当時の JIS C 6226 の解説には，「 常用漢字表および人
名用漢字別表を合わせて常用漢字等と呼ぶ」とある．

これと整合性のある文字コードとしたかったからである．

– 30 –

安岡孝一：日本における最新文字コード 事情

533

同じ頃，日本語 UNIX システム諮問委員会は，UNIX

の提案に基づき，これら 4 つのエスケープシーケンスの上で漢字を扱う方法について，議論を重ねていた．1984「 1B 28 48 」は使わないこといずれを使ってもよい3が，年 11 月に JIS C 6228 が改正されて，複数バ イトコーが協約された．これが新しい JUNET コードである．な2

お，JIS X 0201 (JIS C 6220 が 1987 年 3 月に改称) のドが A1 〜 FE にも呼び出せるようになった こともあり，それに準拠した形での漢字コードを模索していたのであ

片仮名は，JUNET コードでは使わないことが協約される．1985 年 5 月，委員会は，報告書を AT&T に提出し，ている．したがって，シフト JIS の A1 〜 DF 部分あるいこれが EUC の原型となった [20,23]．

は日本語版 EUC の 8E A1 〜 8E DF 部分の片仮名は，そEUC は，JIS C 6228 準拠 (すなわち ISO 2022 準拠)の文字集合を，最大 4 つまで同時に使える 8 ビットコードである．文字集合 0 は，21 〜 7E に割り当てられ，通常は ASCII が用いられる．文字集合 1 は，A1 〜 FE (あるいは A0 〜 FF) に割り当てられる．文字集合 2 も，A1
〜 FE (あるいは A0 〜 FF) に割り当てられるが，各文字の前に 8E を必要とする．文字集合 3 も，A1 〜 FE (あるいは A0 〜 FF) に割り当てられるが，各文字の前に 8F を必要とする．日本語版 EUC においては，文字集合 0 にASCII，文字集合 1 に JIS C 6226，文字集合 2 に JIS C
6220 の片仮名を，それぞれ 用いることになっていた1 ．
すなわち日本語版 EUC では，JIS C 6226 の 1 区 1 点〜
94 区 94 点は，それぞれ A1 A1 〜 FE FE という 2 バイトで表されるのである．あるいは，JIS C 6220 の片仮名
10/1 〜 13/15 は，それぞれ 8E A1 〜 8E DF という 2 バ

れぞれ JIS X 0208 (JIS C 6226 が 1987 年 3 月に改称)

イトで表されると考えてよい．

集していたからである．

中の対応する文字に変換しなければ，電子メールで送ることはできなかった．

補助漢字と平成明朝体

8.

JIS C 6226 への文字追加を要求する声に押され，1985
年 4 月，漢字符号系調査研究委員会が日本規格協会の下で発足した．委員会は，追加希望漢字を調査し，全部で30 の漢字表 (単純合計で 17742 字) を収集した．しかしながら委員会は，これらの漢字表から漢字を選定する作業はおこなわず，日本印刷産業連合会に選定リストの作成を依頼する，という方法を取ることにした．というのも，同じ頃，日本印刷産業連合会の文字コード 委員会においても，JIS C 6226 に含まれていない漢字の調査をおこなっており，9 つの漢字表 (単純合計で 41772 字) を収

一方，JUNET コード で使用されているエ スケープ

日本印刷産業連合会では，これら 39 の漢字表から，大シーケンスが，実は間違っているということが，1986 年

漢和辞典 [22] に収載されている漢字の抽出をおこない，異なり字数で 12924 字を得た．さらに，この 12924 字か

3 月，東京大学の和田英一によって指摘された [21]．すなわち，漢字アウトに「 1B 28 48 」が使用されているが，これは NATS スウェーデン名前用コードを呼び出すためのものであり，JIS C 6220 のローマ文字には「 1B
28 4A 」を用いるべきだ，という点である．ただし，この間違いは，JIS C 6228 初版の解説に「エスケープシー
ケンスの登録の現状」の項があり，JIS C 6220 のローマ文字に対しては「 ESC 2/8 4/8 」が登録されている，と書かれていた2 のが原因である．さらに和田は，1978 年
版の JIS C 6226 に対する「 1B 24 40 」と，JIS C 6220のローマ文字に対する「 1B 28 4A 」に加えて，1983 年
版の JIS C 6226 に対する「 1B 24 42 」と，ASCII に対する「 1B 28 42 」も使用できるようにすべきだ，と提案

ら，「 字形の違いがわずかである」漢字が JIS C 6226 に含まれているものや，39 の漢字表のうち 1 つの漢字表にしか現れないものを削除し，5790 字とした．また，大漢和辞典に収載されていなかった漢字のうち，3 つ以上の漢字表にあるものを選びだし，53 字を得た [25]．
情報交換用漢字符号系改正原案作成委員会 (1987 年 4月に漢字符号系調査研究委員会が改組) は，日本印刷産業連合会が選定したこれらの漢字 5843 字に，非漢字 266
字を加えた文字集合案を，1987 年 12 月に完成した．この段階で委員会は，JIS X 0208 (JIS C 6226 が 1987 年

3 月に改称) への文字追加はおこなわないことを決定した．すなわち，JIS X 0208 はそのまま4にして，これらしている．また，漢字イン，漢字アウトという考え方は6109 字を，JIS X 0208 とは別に規格化することにした

正しくなく，エスケープシーケンスは常に「 GOTO 文」のである．ただし，規格化にあたって，規格票を印刷すだということも強調している．

るためのフォントが必要である，と委員会は考えた．こ1988 年 2 月に作成された JUNET 利用の手引 (第 1 版)

3では，
「 JUNET における漢字利用の約束」として，和田
2

JUNET 利用の手引 (第 1 版) の「メールの文字コード 」の項に，「 JUNET ではメールには 新 JIS コード を使うことになっています」とあることから，「 1B 24 40 」は使えないと解釈する向きもある．しかしながら，少なくとも 1988 年 2 月の時点では，エスケープシーケ

例えば，JIS C 6226 の 16 区 1 点の「亜」を A1 〜 FEに呼び出すと，B0 A1 となる．
1
日本語版 EUC の文字集合 3 に，JIS X 0212 を追加することが合意されたのは，1991 年 12 月のことであり，
これが現在の EUC-JP である．
2
1982 年 6 月に正誤表が出され，「 ESC 2/8 4/10 」に訂正された．

– 31 –

4

ンスを 3 つに絞るという合意はなかった．
ただし，1984 年 11 月に改正された JIS C 6228 (1987年 3 月に JIS X 0202 に改称) と整合させるための改正はおこなうこととされた．

534

システム/制御/情報

第 45 巻

第9号(2001)

れが，文字フォント開発・普及センターの設立 (1988 年

続行し，JIS X 0208 への移動が確定した「凜」，大漢和

11 月) の契機となったのである．

辞典で義未詳となっている漢字，他の漢字と構成要素が文字フォント開発・普及センターの最初の仕事は，JIS同じと見られる大漢和辞典非収載漢字など 42 字を，文1

X 0208 の 6930 字 および文字集合案 6109 字の明朝体と，
JIS X 0208 の 6930 字の角ゴシック体を開発することであった．センターは，1989 年 1 月に明朝体の公募をおこで用いるためのエスケープシーケンスを取得4し ，平成

ない，リョービ イマジクスのデザインが入賞した．後に明朝体で印刷して，JIS X 0212 として制定 (1990 年 10

平成明朝体 W3 と名づけられるフォントの，委託開発の月) した．
「 JIS X 0208 で規定している 通常の国語の文開始である．また，1989 年 3 月におこなった角ゴシック

章の表記に用いる図形文字の集合 に含まれていない図体の公募では，日本タイプライターのデザインが入賞し形文字を必要とする情報交換のために，JIS X 0208 の補字集合案から削除した．委員会はこの 6067 字を，JIS X

0202 に準拠するように 94 × 94 の形に並べ，JIS X 0202

た．後に平成角ゴシック W5 と名づけられるフォントの，助として用いる図形文字の符号」としての，「 補助漢字」

委託開発の開始である．開発完了は 1990 年 5 月という，の誕生である．

はっきり言ってムチャなスケジュールであった．

ばよい，と考えたのである．しかし，63 区 70 点の「煕」

JIS X 0212 では，94 × 94 の文字表の各符号位置は，
JIS X 0208 と同じく区点番号で示されている．呼び出し先は，21 〜 7E のみならず，A1 〜 FE も想定されている．
特殊文字は 2 区 15 〜 25・34 〜 36・75 〜 81 点，ギリシ
アアルファベットは 6 区 65 〜 69・71・73・74・76・81〜 92 点，キリル系アルファベットは 7 区 34 〜 46・82 〜
94 点，ラテン系アルファベットは 9 区 1・2・4・6・8・9・
11 〜 13・15・16・33 〜 48 点に加えて 10 区 1 〜 24・26〜 87 点と 11 区 1 〜 27・29 〜 35・37 〜 87 点に収録されており，これらに関しては，JIS X 0208 の収録文字とは区点番号が衝突しないように工夫されている．漢字は 16
区 1 点〜 77 区 67 点に収録されており，JIS X 0208 の漢の字形を「熙」に変更するのは，問題があった．JIS X

字と区点番号が重なっている．なお，常用漢字表の括弧0208 規格票本文の「用語の定義」の中に，「主としてこうき (康煕) 字典の部首による」という一文があった2のである．委員会は，JIS X 0208 規格票本文も，平成明

書きの字体に対する委員会の見解は，基本的に 1983 年
ど の常用漢字表の括弧書きの字体は，JIS X 0212 にも朝体で印刷することを決めていたので，もし平成明朝体

収録されていない5 ．

ところが，フォント開発完了も間近の 1990 年 3 月，法務省がおこなった人名用漢字別表に対する 118 字の追加 [26] により，JIS X 0208 の見直しをおこなう必要が生じた．情報交換用漢字符号系改正原案作成委員会としては，JIS X 0208 には文字の追加をおこなわない方針だったが，118 字をチェックした結果，少なくとも「凜」は追加する必要があったのである．残る 117 字について
は，規格票に用いる平成明朝体の字形を，人名用漢字に合わせてそれぞれ手直しすればよいだろう，と思われた．
例えば，64 区 2 点の「 燿 」は，字形を「 燿 」に変更すれ時点のものと変更はなく，したがって「 巣 」や「 漢 」なの「煕」を「熙」に変更するならば，規格票本文のこのJIS X 0212 に収録されている文字は全て，JIS X 0208

部分をも変更するのかど うかが問題になる．結論としてには収録されていないはずだが，当時の規格票を丹念に委員会は，「 煕」と「熙」は別字であると確認し，「 凜」を読むと，誤ってこれらの両方に収録されてしまっている

JIS X 0208 の 84 区 5 点に，「 熙」を 84 区 6 点に追加し文字があることがわかる．例えば ，当時の JIS X 0208て，規格票本文の「主としてこうき (康煕) 字典の部首にの解説によれば，JIS X 0208 では「σ」と「 σ 」6を 6

よる」は変更しなかった．これが 1990 年 9 月改正の JIS

区 50 点に合併し ，1 つの符号位置で両方を表している

X 0208 であり，JIS X 0202 でのエスケープシーケンス
も，従来の JIS X 0208 の更新 (ESC 2/6 4/0 ESC 2/4
4/2)3となったのである．

ことになっている．ところがこれに反して，JIS X 0212
「 σ 」は，この時点で，JIS X 0208 と JIS X 0212 の両同時に委員会は，文字集合案の各漢字に対する調査を方に収録されてしまった，ということになる．また，JISは，「 σ 」を 6 区 88 点に収録しているのである．すなわち

C 6226 の 1983 年改正で消滅してしまった漢字に対して，
1

JIS X 9052 ド ットプリンタ用 24 ド ット字形 (1983 年
9 月に JIS C 6234 として制定， 1987 年 3 月に改称)が規定する字数で，当時の JIS X 0208 の 6877 字に加え，縦書き字形 53 字が含まれている．
2
ちなみに常用漢字表は，1981 年当時の大蔵省印刷局活この時点の JIS X 0208 の解説も「別の文字概念を採用したわけではない」と主張している．それにもかかわらず，消滅してしまった漢字のうち 28 字が，JIS X 0212に再収録されている [27] のである．例えば，「 鴎 」は，JIS

X 0212 の 76 区 31 点に収録されており，JIS X 0208 の字を用いていたため，「 康熙字典」となっていた．人名
用漢字の「熙」は，これに倣ったものと推測される．
3
1984 年 11 月の JIS C 6228 (現，JIS X 0202) 改正により，複数バイトコードに与えられるエスケープシー

4

代表的なエスケープシーケンスは，「 ESC 2/4 2/8 4/4 」
である．
574 区 18 点に「 ? 」が収録されているが，常用漢字表の「闘 (?) 」の括弧書きとは字体が異なっている．
6
ギリシア語では，語末のσはσと記す．

ケンスは，指示先に応じて 4 種類となったが，残りの3 つはここでは割愛する．

– 32 –

535

安岡孝一：日本における最新文字コード 事情

18 区 10 点の「鴎」の「文字概念」との間で，齟齬をきたす結果になっている．これらの齟齬は，JIS X 0208 の年号外第 88 号，pp.2-77，1981 年 10 月 1 日．
[17] 長谷川均，岡崎健: 漢字 CP/M?のコード 体系; 情報処理学会マイクロコンピュータ研究会資料，26-2，1983 年 3

本文や解説を書き変えることを，委員会が極度に嫌ったために，引き起こされてしまったものである．すなわち，

1983 年版のままの本文や解説を，1990 年版にも忠実に反映してしまったことが，「 熙」の問題も含めて，JIS X

0208 の 1990 年改正の最大の問題点であるといえる．
後 編 目 次9. 国際符号化文字集合への道
10. MIME と ISO-2022-JP
11. ISO 10646 の Amendment
12. JIS X 0208 の 1997 年改正
13. JIS X 0213 の開発
14. JIS X 0213 の制定
15. そして最新文字コード 事情

月．

[18] 山下省治郎，安藤澄夫，成岡祥匡: 三菱パーソナルコ
ンピュータ《MULTI 16》日本語 CP/M-86 の特長と機能; 三菱電機技報，Vol.57，No.11，pp.52-56，1983 年
11 月．
[19] 野村雅昭: JIS C 6226 情報交換用漢字符号系の改正; 標
準化ジャーナル，Vol.14，No.3，pp.4-9，1984 年 3 月．
[20] NE レポート : 日本語版 Unix の標準案を提案; 日経エレクトロニクス，No.370，pp.111-113，1985 年 6 月．
[21] 小 川 貴 英: JIS no kaisetu to junet heno teian (InJapanese); fj.kanji，Message-ID: <134@tsuda.UUCP>，
1986 年 3 月．
[22] 諸橋轍次: 大漢和辞典 (修訂版); 大修館書店，1986 年 4月．

参 考 文 献[1] 吉田茂: 内閣告示第 32 号，当用漢字表; 官報，昭和 21
年 11 月 16 日号外，pp.1-2，1946 年 11 月 16 日．
[2] 昭和 21 年 11 月 16 日官報号外内閣告示第 32 号中正誤;
官報，第 6118 号，p.63，1947 年 6 月 9 日．
[3] 鈴木義男: 司法省令第 94 号，戸籍法施行規則; 官報，
昭和 22 年 12 月 29 日号外 (4)，pp.1-25，1947 年 12 月
29 日．
[4] 吉田茂: 内閣告示第 1 号，当用漢字字体表; 官報，昭和24 年 4 月 28 日号外 (1)，pp.1-3，1949 年 4 月 28 日．
[5] 昭和 24 年 6 月 29 日民事甲第 1499 號民事局長回答; 戸籍，第 1 號，p.7，1949 年 9 月．
[6] 昭和 24 年 6 月 29 日民事甲第 1501 號民事局長回答; 戸籍研究，第 24 號，p.25，1949 年 9 月．
[7] 吉田茂: 内閣告示第 1 号，人名用漢字別表; 官報，第 7310
号，p.402，1951 年 5 月 25 日．
[8] 国語審議会 (漢字部会): 当用漢字表審議報告; 国語審議会報告書—付 議事要録—，昭和 27 年 4 月〜 29 年 4 月，
文部省/秀英出版，p.6，1954 年 9 月．
[9] 岡本榮一: 漢字テレタイプ機種別の解説; 新聞印刷技術，
第 13 号，pp.2-11，1960 年 3 月．
[10] 高橋達郎，森田朗，広田広三郎: 漢字入出力機器について; 情報管理，Vol.12，No.6，pp.309-319，1969 年 9 月．
[11] 小田泰正: 国立国会図書館の機械化準備; 国立国会図書館月報，No.117，pp.2-9，1970 年 12 月．
[12] 規格委員会: 1971 年における規格委員会の活動; 情報処理，Vol.13，No.7，pp.495-503，1972 年 7 月．
[13] 三木武夫: 内閣告示第 1 号，人名用漢字追加表; 官報，第14869 号，p.5，1976 年 7 月 30 日．
[14] 西村 恕 彦: 漢 字の JIS; 標 準 化ジャーナル ，No.171,
pp.3-8，1978 年 5 月．
[15] 奥野誠亮: 法務省令第 51 号，戸籍法施行規則の一部を改正する省令; 官報，昭和 56 年号外第 88 号，p.1，1981
年 10 月 1 日．
[16] 鈴木善幸: 内閣告示第 1 号，常用漢字表; 官報，昭和 56– 33 –[23] 小野芳彦: UNIX の日本語化の実現方法; 情報処理，
Vol.27，No.12，pp.1393-1400，1986 年 12 月．
[24] 日本科学技術情報センター三十年史編集委員会: 日本
科学技術情報センター三十年史; pp.256-257，1988 年 3月．

[25] 田嶋一夫: JIS 漢字補助集合案の設定と今後の課題; 情報処理学会研究報告，Vol.89，No.13 (情報学基礎研究
会報告 No.12)，89-FI-12-1，1989 年 2 月．
[26] 長谷川信: 法務省令第 5 号，戸籍法施行規則の一部を改正する省令; 官報，平成 2 年号外第 21 号，pp.1-11，
1990 年 3 月 1 日．
[27] 内田富雄: JIS X 0212 (情報交換用漢字符号—補助漢字)の制定; 標準化ジャーナル ，Vol.20，No.11，pp.6-11，
1990 年 11 月．
[28] 安岡孝一，安岡素子: 文字コード の世界; 東京電機大学
出版局，1999 年 9 月．
[29] 小林龍生，安岡孝一，戸村哲，三上喜貴 [編]: インターネット時代の文字コード ; bit 別冊，共立出版，2001 年 4月．

著 者 略 歴
やす おか

こう いち

安 岡

孝 一
1965 年 2 月 18 日生．1988 年 3 月京都大学工学部情報工学科卒業．1990 年 3 月京都大学大学院工学研究科情報工学専攻修士課程修了．同年 4 月京都大学大型計算機センター助手，1997 年 8 月同助教授．2000

年 4 月京都大学人文科学研究所附属漢字情報研究センター助教授，現在に至る．京都大学博士 (工学)．
1996 年 10 月から 2000 年 3 月まで符号化文字集合調査研究委
員会 WG2 委員．2000 年 9 月いきなり二女の父となり，2000
年 12 月から情報処理学会文字コード 標準体系専門委員会委員．文字コードに関する著書に [28,29] がある．電子情報通信学会会員．yasuoka@kanji.zinbun.kyoto-u.ac.jp

687

システム/制御/情報，Vol. 45, No. 12, pp. 687–694, 2001||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

解説

日本における最新文字コード 事情 (後編)
※本原稿は著者によるゲラ刷りであり、最終稿とは異なっている。
本原稿を引用する場合は、必ず印刷された最終稿を確認すること。

安岡 孝一*||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

前 編 目 次において，13 〜 15・90 〜 94 区に漢字を追加収録していた．しかも，GB 8565 での追加に加え，さらに 12 区に

1. 文字コード 前史
2. 文字コード の黎明期
3. 世界初の ISO 準拠複数バイトコード
4. 常用漢字表と人名用漢字許容字体表
5. シフト JIS の誕生
6. JIS C 6226 の 1983 年改正
7. JUNET コードと EUC
8. 補助漢字と平成明朝体

も漢字を追加した文字コード 3を，CCITT (現，ITU-T)の Recommendation T.101 に含めるよう，提案していたのである．すなわち，GB 2312 の 16 区以降だけでは，既におこなっている他の国際提案に比べて，非常に不十分な文字コード となりかねなかった．また，中国国内では 1988 年 3 月に，現代漢語通用字表4が発布されていた．
この 7000 字のうち，407 字が GB 2312 には収録されておらず，その意味でも GB 2312 では不十分だったので

9.

国際符号化文字集合への道

ある．

日本で JIS X 0212 の 開発が 進んでいた (前編 8 章

しかし ，中国はこのような事情はおくびにも出さず，

参照) 頃，ISO では，漢字を含む 32 ビットの文字コー

当時のアメリカやカナダの代表者が主張していた漢字統

ド を国際規格として制定する動きが，具体化していた．

合を，支持する立場を取った．すなわち，ド ラフト第 1

これが ，ISO 10646 である．1989 年 1 月に作成された版では，例えば「一」という漢字ですら，2020306C とISO 10646 のド ラフト 第 1 版では，32 ビット中の各 8ビットで 20 〜 7E と A0 〜 FF のみを 使用し ，合計で(95+96)4 =1330863361 字を収容可能な文字コード としていた．各 8 ビットには ，上から順に Group，Plane，
Row，Cell という名称がつけられており，Group 20 のPlane 20 にあたる (95+96) × (95+96) の部分は，BMP(Basic Multilingual Plane) と呼ばれていた．さらに日本の提案では，BMP の 20203021 〜 20207E7E の部分に，
JIS X 0208 の 16 区 1 点〜 94 区 94 点をそのまま埋め込むことで，JIS X 0208 の漢字部分と互換にすることが期待されていた．また，BMP の 2020B021 〜 2020FE7E に中国の GB 2312 1 の 16 区以降を，2020B0A1 〜 2020FEFEに韓国の KS C 5601 (現，KS X 1001)2 の 16 行以降を，2020D23B と 2020ECE9 の 3ヶ所に収録されてしまう．これは，検索上も非常に不便だし，そもそも文字の一意な符号化という文字コード の基本理念に反するので，一つの符号位置に統合すべきである，という立場である．結局，1991 年 6 月におこなわれた投票の結果，ISO 10646のド ラフト第 1 版は否決され，ド ラフトの改訂がおこなわれることとなった．
ド ラフト第 2 版では，Plane，Row，Cell の値の制限はなくなり，00 〜 FF の全ての値が 使用できることになった．Group に関しては，00 〜 7F のみが 使用できることになっており，実質上 31 ビットの文字コード となっている．BMP は，Group 00 の Plane 00 に移され，

BMP の 00004E00 〜 00009FFF に漢字が収録されるこそれぞれそのまま埋め込むことを提案していた．これにとが決まった．漢字を統合するかど うかは，日中韓の判よって，日中韓の主要な 94 × 94 の文字コードと，ある断に委ねられ，1991 年 7 月，CJK-JRG (China, Japan,

程度互換性が取れるだろう，と考えていた [5] のである．

Korea-Joint Research Group) の最初の会議が開かれた．

この提案に ，中国は 反対であった．中国は 既に GB

この段階で，中国は既に統合漢字表を作成しており，

2312 の拡張を進めており，1988 年 7 月実施の GB 8565

それを CJK-JRG に持ち込んだが，日本はこれに反発，∗

漢字統合はルール・ベースでおこなうことを主張し，漢京都大学人文科学研究所附属漢字情報研究センター
1
1981 年 5 月実施，2001 年 3 月廃止 (GB 18030 に移行)．94 × 94 の文字コードで，16 〜 87 区に簡化字を収録していた．
2
1974 年 9 月制定．1987 年の改正で 94 × 94 の文字コードとなった．16 〜 40 行 (符号位置に対して，区点では字の形による統合ルールを提示した [3]．このルールによ
3
4

なく行列という名称を用いている) にハングル，42 〜
93 行に漢字を収録している．

現在「 ISO-IR 165 」と呼ばれている．
正式名称は，現代漢語通用字表．中国における現代漢字の規範化すなわち一種の漢字制限を目しており，情報処理，機械処理，印刷出版事業の発展に応えるべく，
通常用いられる漢字 7000 字を収録している．

–9–

688

システム/制御/情報

第 45 巻第 12 号(2001)

されていると同時に，F9D0 にも収録されていた1 のであれば，例えば「 飲 」と「飲」と「飮」のような部首の新旧の違いにあたるものは，統合しないことになっていた．

る．Unicode は，ISO 10646 の BMP と互換である，とこれに対し中国は，「 飲 」と「飲」は簡化字と繁体字の関いうのがウリであったから，アメリカの代表者としては，係にあるので，分離するのが適当だが，「 飲」と「飮」は何としても ISO 10646 の 0000F900 〜 0000FA2D に，互単なる書体差だから統合すべきだ，と主張した．そこで換漢字を収録する必要があったのである．
結局，1993 年 5 月に制定された ISO 10646 では，CJK

日本は，統合漢字の採録元となる各国の国内規格において，既に別々の符号位置を与えられている漢字ど うしは，

統合漢字 20902 字が 00004E00 〜 00009FA5 に収録されたとえ統合の対象であっても分離する，という原規格分

ると同時に，互換漢字 302 字が 0000F900 〜 0000FA2D

離を条件に，中国の主張を受け入れた．この結果，「 飲」に収録された 2 ．この結果，JIS X 0208 や GB 2312 とと「飮」は統合の対象ではあるが，原規格 (統合漢字ののラウンド・トリップ・コンバージョンは，CJK 統合漢採録元) の 1 つである JIS X 0208 において，それぞれ 16

字での原規格分離によって保証され るが ，KS C 5601

区 91 点と 61 区 27 点という別々の符号位置が与えられとのラウンド ・トリップ・コンバージョンは，互換漢字ているので，統合をおこなわない，ということになったによって保証される，というヤヤコシイことになってしのである．

まったのである．例えば，「 禄」と「祿」は本来統合されまた，日本は，日本からの原規格を JIS X 0208 と JISるべきものだが，JIS X 0208 に対する原規格分離によっX 0212 の 2 つに限定することを表明，他の国にも，原て，00007984 と 0000797F という別々の符号位置が与規格および収録漢字の範囲を明確にするよう迫った．こえられている．その上，KS C 5601 とのラウンド ・トの際，日本のメーカー外字や人名用漢字許容字体表 (前リップ・コンバージョンのために，0000F93C にも「祿」

編 4 章参照) を採録すべきではないか，との意見があっが収録されているのである．

たが，日本は国内規格のみに固執し，これらの意見を受さらに ，ISO 10646 の翻訳規格である JIS X 0221
(1995 年 1 月制定) には，日本の独自規定3である，日本

け入れなかった．中国は，形の上では原規格の範囲を国内規格に限定したかのように見えたが，実は原規格に含文字部分レパート リが盛り込まれた．日本文字部分レ

まれていない漢字の収録を勝手におこなっていたことが，パートリは，JIS X 0221 の文字 (すなわち ISO 10646 の最近になって判明している [4,6]．韓国にとっては，原規文字) のサブセットであり，この規格を日本で実装する

格の限定はそう問題ではなかったが，原規格分離は多少際に，どのような部分実装を推奨するかを規定したもの

ややこしい問題を含んでいた．KS C 5601 の漢字は，読だと言える．日本文字部分レパートリは，基本日本文字

みのハングル順に並べられており，例えば「 類 」には複集合，追加非漢字集合，追加漢字集合，補助漢字集合，

数の読みがあることから，55 行 30 列 (読みは ?) と 75

その他の漢字集合と，互換用全角英数字集合，互換用半行 26 列 (読みは?) の 2ヶ所に収録されていたのである．

角片仮名集合，の 7 つのサブセットからなっている．こ

原規格分離に完全にしたがうことにすると，全く同じ形のうち，基本日本文字集合は，JIS X 0208 の全文字にの「 類 」が，複数収録されなければならない．しかも，

ASCII を追加した 6884 字4であり，追加漢字集合は，JIS
X 0212 策定の際に，8 つ以上の漢字表に含まれていた漢字を中心とする 918 字5 ，補助漢字集合は，JIS X 0212の残りの漢字 4883 字である．すなわち，日本文字部分レ
パートリというのは，JIS X 0208 と JIS X 0212 の各文

KS C 5601 には，このような漢字が 262 組 530 字もあるのである．結局，韓国は，KS C 5601 にダブって収録されている漢字に関して，原規格分離を要求しなかった．
この結果，CJK-JRG が 1992 年 3 月に完成した CJK 統「 類 」は 1 字しか含まれず，しかも合漢字 20902 字には，

1

「類」と統合されていた．
ところがこれに対し，アメリカの代表者が異を唱えた．
確かに漢字統合という側面からは，「 類 」を複数収録する

KS C 5601 との変換においては，985E が 55 行 30 列，
F9D0 が 75 行 26 列の「 類 」にそれぞれ対応していた．
2「 類 」は，0000985E と 0000F9D0 に収録され，Unicodeと互換となった．なお，0000985E の「 類 」は，「 類」とことがあってはならないから，CJK 統合漢字 20902 字を，そのまま ISO 10646 の 00004E00 〜 00009FA5 に収録すべきである．しかしながら，既存の各国規格とのラ
ウンド・トリップ・コンバージョンも何らかの形で保証すべきではないか，という意見である．ラウンド ・トリッ
プ・コンバージョンの保証とは，すなわち，KS C 5601
で書かれたデータを ISO 10646 に変換し ，それをまたKS C 5601 に再変換した場合に，完全に元に戻る必要がある，という考え方である．しかもアメリカの代表者は，

1992 年 6 月に，Unicode 1.0[2] という 16 ビットの文字
コード を発表していた．そこでは「 類 」は 985E に収録– 10 –

3

統合されている．
2001 年 4 月改正の JIS X 0221 では，日本文字部分レ

4

パートリは，規定から参考に格下げとなった．
ASCII と JIS X 0208 でダブっている文字は，互換用
全角英数字集合に追い出されている．また，当時の JIS
X 0221 の附属書 1 には「 BASIC JAPANESE (基本
日本文字集合) は，JIS X 0201 及び JIS X 0208 で規定された図形文字のうち，全角英数字及び半角片仮名を除いたものとする」とあったが，この記述は誤りであり，2001 年 4 月に全面改正された．
5
当時の JIS X 0221 の解説では，なぜか 890 字となっていた．

安岡孝一：日本における最新文字コード 事情

689

字を JIS X 0221 から選び出したものに過ぎず，日本でのである．

の漢字使用の実態に即したものではない．例えば，人名

これを受ける形で 1993 年 6 月，JUNET コード (前編7 章参照) は RFC 1468 となった．ただし ，文字コードの名前は，JUNET コードではなく，ISO-2022-JP と名づけられた．JPド メイン 1における ISO 2022 準拠2 の文字コード，という意味だったが，JUNET コード とは違い，ISO-2022-JP は ISO 2022 準拠ではない．JUNET
コードでは「 1B 24 42 」を，JIS X 0208 (旧称，JIS C
6226) の 1983 年版 (前編 6 章参照) への切り替えとしていたが，ISO-2022-JP ではこれを，JIS X 0208 の 1990
年版 (前編 8 章参照) への切り替えとみなしてもよい，ということに変更してしまった．すなわち，本来「 1B 26
40 1B 24 42 」であるべきところを，「 1B 24 42 」としてしまったために，ISO-2022-JP は，ISO 2022 非準拠

用漢字許容字体表の「 巣 」や吐?喇列島の「 ? 」は，いずれも JIS X 0221 に収録されている6にもかかわらず，
日本文字部分レパートリでは，その他の漢字集合に入れられてしまっているのである．
以上，述べてきたとおり，ISO 10646 の制定は，日本の漢字を国際規格に収録する絶好のチャンスであった．
これに対し ，日本が 取った態度は ，国内規格の JIS X

0208 と JIS X 0212 に固執し，実際に収録すべき漢字の調査も追加要求もおこなわない，というものであった．
この結果，ISO 10646 の漢字部分は，中国にいいようにされてしまい，それが現在も続いている，というのが正直な印象である．

10.

となってしまったのである．

MIME と ISO-2022-JP

インターネットにおける電子メールのフォーマットは，

RFC 822 (現，RFC 2822) によって定義されている．しかし，RFC 822 は，文字コードとして 7 ビットの ASCIIを想定しているため，それ以外の文字コード，特に 8 ビットの文字コード によるテキストは ，電子メールでは直接送受信することができなかった．この問題を解決するために，1992 年 6 月に RFC 1341 (現，RFC 2045) として提案されたのが ，MIME (Multipurpose Internet

Message Extensions) である．
MIME の最大の特長は，メールヘッダに Content-Type

さらに 1993 年 12 月には，JUNET コード に，JIS X
0212，GB 2312， KS C 5601 (現，KS X 1001) などへの切り替えエスケープシーケン スを加えた 7 ビット
コード ISO-2022-JP-2 が ，RFC 1554 として提案された．ISO-2022-JP-2 は「 1B 24 42 」を，あくまで 1983
年版の JIS X 0208 への切り替えとみなしており，ISO
2022 準拠ではあるが，JIS X 0208 の 1990 年改正で追加された「凜」と「熙」は使用できない3 ．1997 年 11 月にRFC 2237 として提案された ISO-2022-JP-1 4 も，ISO
2022 準拠ではあるが，やはり「凜」と「熙」は使用できない．

フィールドを追加し，メール本文にどのようなものが含

現在，日本の電子メールで用いられている文字コード

まれているかを，明示できるようにしたことである．メー

は，JUNET コード 以来の歴史から，ISO-2022-JP がほル本文の文字コード は，Content-Type 中の charset パ

とんどである．ただし，JIS X 0212 の文字を含むようなラメータで明示されると同時に，もし 8 ビットコードで電子メールにおいては，「 凜」と「熙」の事情もあってか，

あれば，Content-Transfer-Encoding フィールドに 8bit

ISO-2022-JP-1 や ISO-2022-JP-2 はほとんど 用いられを指定すればよいことになっている．Content-Transfer-ず，もっぱら 8 ビットコード の UTF-8 (次章参照) が用

Encoding には，他に quoted-printable と base64 が指定

いられるようである．

可能であり，これらはいずれも 8 ビットデータを，7 ビッ
トに押し込めるための形式である．これらにより，8 ビッ

11.

ISO 10646 の Amendment

Transfer-Encoding が 8bit から quoted-printable もしISO 10646 には，1993 年 5 月の制定後，多くの Amendment が追加されており，文字コード としては，次々に

くは base64 に自動変換されて，ビット落ちなしに送受変更が加えられている．

信できるようになっている．

Amendment 1 (1996 年 10 月制定) である UTF-16 は，
31 ビットコード である ISO 10646 を，16 ビット環境にトデータを 7 ビットの通信路に流す場合でも，Content-

また，メールヘッダに対しては，RFC 1341 と同時に発表された RFC 1342 (現，RFC 2047) によって，ASCII

1以外の文字列を扱う手法が提案された．
「 =? 」と「 ?= 」の間に，文字コードと変換形式 (Q あるいは B) および変換後の文字列を埋め込むことで，ASCII 以外の文字列を2

英数字と若干の記号で表現する手法である．これによって，メールヘッダの From フィールド や To フィールド

6「 巣 」は 00005DE2 に，「 ? 」は 00005676 に収録されている．

– 11 –

ワークとしての活動を，事実上終了した．
すなわち，JIS X 0202 準拠．なお，ISO 2022 と JIS

X 0202 (旧称，JIS C 6228) の関係は，前編 2 章参照．
JIS X 0208 の「 凜」と「 熙」は確かに使用できない
が，KS C 5601 の「凜」と「熙」(符号位置はそれぞれ 55 行 47 列と 93 行 87 列) は使用できる．
4
JUNET コードに，JIS X 0212 の「 1B 24 28 44 」を加えた 7 ビットコード．
3に，ASCII 以外の文字を使うことができるようになった

日本国内のメールアドレスの多くは，トップド メイン
が junet だったが，1990 年 4 月に全て jp に切り替えられた．その後，1991 年 10 月に，JUNET はネット

690

システム/制御/情報

第 45 巻第 12 号(2001)が ，提案から漏れてし まっている．あるいは ，1024 をマッピング するための方法であり，16 ビットコード である Unicode にど のように変換するかを，示したもの意味する「 ? 」のように，メーカー外字に含まれていなであるといえる．ISO 10646 の 00000000 〜 0000D7FF

かった漢字は，この提案には含まれていない．結局，中と 0000E000 〜 0000FFFF は，UTF-16 では ，0000 〜

国 (および台湾) から提案された漢字を中心に，6582 字

D7FF と E000 〜 FFFF にマッピングされる．また，ISO10646 の 00010000 〜 0010FFFF は，UTF-16 では，D800
DC00 〜 DBFF DFFF にマッピングされる．ISO 10646 の00110000 以降の文字は，UTF-16 では使用できない．
Amendment 2 (1996 年 10 月制定) である UTF-8 は，
31 ビットコード である ISO 10646 を，8 ビット環境にの CJK 拡張漢字が，1998 年 4 月に確定し，これを BMPの 00003400 〜 00004DB5 に収録した Amendment 17が，1999 年 7 月に制定された．BMP への漢字追加はこれが最後であり，これ以後の漢字収録は，Group 00 のPlane 02 におこなうことになったのである．
なお，これらの Amendment を全て含める形で，ISO10646 は，2000 年 10 月に改正されており，これに合わ
せて，JIS X 0221 も，2001 年 4 月に改正2 された．

完全にマッピング するための方法である．マッピング
方法は非常に複雑で，00000000 〜 0000007F は 00 〜

7F に ，00000080 〜 000007FF は C2 80 〜 DF BF に ，00000800 〜 0000FFFF は E0 A0 80 〜 EF BF BF に ，00010000 〜 001FFFFF は F0 90 80 80 〜 F7 BF BF
BF に ，00200000 〜 03FFFFFF は F8 88 80 80 80 〜
FB BF BF BF BF に，04000000 〜 7FFFFFFF は FC 84
80 80 80 80 〜 FD BF BF BF BF BF に，それぞれマッ
ピング することになっているが ，2 バ イト 目以降には80 〜 BF しか用いられないことを理解すれば ，機械的には読みやすい形になっている．しかも，ISO 10646 の00000020 〜 0000007E は，ASCII の 20 〜 7E を収録したものであることから，UTF-8 は ASCII と上位互換な
8 ビット 1 〜 6 バイトコードであるといえる．
ISO 10646 における最も大きな変更は，ハングルの符号位置の移動である．1993 年 5 月の制定時には，ハングルは 00003400 〜 00004DFF に 6656 字が収録されており，このうち 00003400 〜 00003D2D の 2350 字は，KS C 5601 の 16 〜 40 行と全く同じ順序に並べられていた．ところが KS C 5601 の附属書 3 には，現代ハング
ル 11172 字を全て符号化可能な 8 ビット 2 バイトコード
Johab が示されて1 おり，これとの対応が問題になったのである．そこで韓国は，ハングルの符号位置を 0000AC00〜 0000D7A3 に移動して，そこに現代ハングル 11172 字を全て収録するよう要求した．この要求は結局，1996 年
8 月に承認され，1997 年 11 月に Amendment 5 として制定された．非常に大きな非互換変更が，ISO 10646 に12.

JIS X 0208 の 1997 年改正

1997 年 2 月，JIS X 0208 の 3 度目の改正3がおこなわれた．改正の中心となったのは，1994 年 4 月に発足した符号化文字集合調査研究委員会 WG2 である．改正の主眼は，JIS X 0208 の各符号位置が，ど ういう文字の情報交換を意図しているかの明確化であり，収録されている

6879 字それ自体については，一切変更をおこなっていな
い．明確化の柱は，収録文字の明確化，字体の合併の明確化，符号化方法の明確化，の大きく 3 つである．
収録文字の明確化に関しては，徹底した典拠調査を，

WG2 はおこなっている．行政情報処理用標準漢字選定のための漢字使用頻度および対応分析結果，という，JIS

X 0208 のいわば 原典 (前編 3 章参照) を発掘したのは，WG2 の最大の成果であるといえよう．あるいは WG2
は，1995 年 8 月時点の国土行政区画総覧に，加除式出版
除去分 33000 ページを加除して，1972 年 11 月時点の国
土行政区画総覧を復元し ，ここから JIS X 0208 の各文
字がどのように収録されたかを明らかにしている．
字体の合併の明確化に対しては，包摂規準が規定された．包摂規準は，1978 年制定の作業時におこなわれた字
体の合併を中心に，その後の JIS C 6226 〜 JIS X 0208
規格票の字体変遷を加味したものである．これにより，
例えば 20 区 54 点は，規格票に示されている「間」のみ
ならず，「 間 」をも包摂していることが，明らかとなった．
各符号位置が表す字体の範囲は，これ以前は合併という対してなされたのである．
ハングルが移動した後の空き領域に対しては，漢字が形で例示的にしか示されていなかったが，包摂規準を規追加収録されることが，1996 年 11 月に決定された．ただ格に含めることで，初めて全てが明示されることになっ

し，BMP への漢字収録は，この 00003400 〜 00004DFFたのである．

を最後にするという条件付きで，である．これに対し ，

符号化方法の明確化としては，日本語版 EUC (前編

日本はメーカー外字 658 字を提案したのみだった．しか7 章参照)，シフト JIS (前編 5 章参照)，ISO-2022-JP

も，提案はメーカー外字の一部にとどまっており，例えが ，初めて規定とし て盛り込まれた．ただし ，日本語ば「 野 」(「野」の異体) のような，人名での使用頻度が版 EUC は，国際基準版・漢字用 8 ビット符号という名高く，しかも複数のメーカーが実装しているような外字2

正確には，JIS X 0221 を廃止し，新たに JIS X 0221-1

1987 年改正以前の KS C 5601 は，94 × 94 の文字コーを制定，という形が取られた．
3
JIS X 0208 (旧称，JIS C 6226) の制定については，

ドではなく，16 ビットコードとして Johab を規定していた．

前編 3 章参照．2 度の改正については，前編 6 章・8 章
参照．

1– 12 –

安岡孝一：日本における最新文字コード 事情

称になっており，JIS X 0201 の片仮名を含んでいない．

691

用漢字および人名用漢字と人名用漢字許容字体は全て，また，ISO-2022-JP は ，本来 7 ビットコード であるべ

JIS X 0213 で書き分けることが可能となったのである．

きところを ，誤って 8 ビットコード とし て規定してししかし，「 間」と「 間 」は，これらを一文の中で使い分け

まった．この結果，一部の電子メール用ソフトウェアが，る例2が，著名な文芸作品 [1] 中に発見されていたにもか

ISO-2022-JP の Content-Transfer-Encoding を 8bit とかわらず，人名用漢字許容字体でも常用漢字表の括弧書してしまう，という事態が起こっており，その意味では，きの字体でもなかったため，JIS X 0213 においても書き符号化方法の明確化に失敗している．

分けることができなくなってしまった．

JIS X 0208 の 1997 年改正は，あくまで規格の明確化を主眼としたものだったが，これにより，JIS X 0208 という規格の持つ問題点が，浮き彫りになった．特に，JIS
X 0208 は本来，日本の地名や人名に用いる漢字を収録

符号化方法の拡張については ，シフト JIS と日本語
版 EUC をそれぞれ拡張した，Shift JISX0213 と EUC-

JISX0213 が，附属書として規定に盛り込まれた．これ
らの拡張のために，WG2 は，JIS X 0213 の構造を以下のように定めた．基本構造は，94 × 94 の文字表を 2 面とする．1 面は，94 × 94 の全てを使用するが，JIS X
0208 の上位互換となるように文字を配置する．2 面は，
1・3 〜 5・8・12 〜 15・78 〜 94 区の 26 × 94=2444 字のしようと意図していたが，その意図が十分に実現されていないことが明らかになった．これが，JIS X 0208 の拡
張規格の開発，という方向に向かっていくのである．

13.

JIS X 0213 の開発部分だけを使用し，残りの部分は空きとする．このよう1996 年 7 月，符号化文字集合調査研究委員会 WG2 は，JIS X 0208 を拡張する規格の開発を表明した．現代日本にしておいて，EUC の文字集合 0 に ASCII，文字集合 1

語文脈で安定して用いられる文字を，できうる限り収録

名，文字集合 3 に JIS X 0213 の 2 面を配置したものを，に JIS X 0213 の 1 面，文字集合 2 に JIS X 0201 の片仮した文字コード JIS X 0213 の，開発開始である．JIS X

EUC-JISX0213 とする．こうすれば ，EUC-JISX0213

0213 は，JIS X 0208 の拡張規格であることから，JIS X
0208 の 1997 年改正で掲げられた 3 つの柱を，それぞれは，日本語版 EUC の拡張であると同時に，EUC-JP 3とはコード の上では衝突しない．しかも，EUC-JP 用に書拡張することとなった．すなわち，収録文字の拡張，包かれたソフトウェアを，簡単に EUC-JISX0213 に流用

摂規準適用除外の拡張，符号化方法の拡張，である．

できる．さらに Shift JISX0213 では，1 面 1 区 1 点〜 1

収録文字を拡張するにあたって，WG2 は，日常生活面 62 区 94 点を 81 40 〜 9F FC，1 面 63 区 1 点〜 1 面に用いられる文字，地名，人名を中心に，用例の収集を

94 区 94 点を E0 40 〜 EF FC，2 面 1 区 1 〜 94 点を F0
40 〜 F0 9E，2 面 3 区 1 点〜 2 面 5 区 94 点を F1 40 〜
F2 9E，2 面 8 区 1 〜 94 点を F0 9F 〜 F0 FC，2 面 12
区 1 点〜 2 面 15 区 94 点を F2 9F 〜 F4 9E，2 面 78 区
1 点〜 2 面 94 区 94 点を F4 9F 〜 FC FC に対応させることで，シフト JIS の拡張を実現している．なお，JIS
X 0202 準拠のエスケープシーケンス4を用いて，JIS X
0213 の 1 面・2 面および ASCII を切り替える 7 ビット
コード ISO-2022-JP-3 も，附属書に盛り込まれており，
ISO-2022-JP からの移行が，多少は考慮されている [7]．
ここまでの作業の後，WG2 は，非漢字 659 字，第 3水準漢字 1249 字，第 4 水準漢字 2436 字を選定し ，JIS
X 0208 の 6879 字と合わせて，11223 字の文字集合5を完成し た．これと並行して WG2 は ，これら 11223 字のうち，ISO 10646 に含まれていない文字全てを，ISOおこなっている．日常生活に用いられる文字としては，

1997 年度および 1998 年度の小学校・中学校・高等学校の文部省検定済教科書の全ページを，委員全員がよってたかってチェックし，異なり字数にして漢字 3241 字，非漢字 1417 字を得ている．地名としては，国土行政区画総覧の除去分 33000 ページのチェックに加え，国土地理協会や国土地理院の協力で，漢字 477 字を得ている．人名
は，当時の NTT 電話帳の全データから，漢字 3241 字を得ている．これらに加え，実際の文字の使用例を広く一般から募り，最終的には，異なり字数にして漢字 13083
字，非漢字 2654 字の，JIS X 0208 未収録文字を収集している．
包摂規準適用除外の拡張に対しては，多数の要望が寄せられていた．
「 巣」と「 巣 」「，漢」と「 漢 」「，間」と「 間 」などは，JIS X 0208 では包摂されていて書き分けられな「 漢」は 1 面 20 区 33 点に，「 漢 」は 1 面 87 区 5 点に，いのだが，これを書き分けることができるようにしてほしい，というものである．これに対し WG2 は，人名用

2

それぞれ収録された．
[1] の 68 ページ 15 行目に「かやうに間?の態度で，有3と無の間に逍遙してゐるのだらう」とある．
日本語版 EUC の文字集合 3 に，JIS X 0212 を追加し

4

た，8 ビット 1 〜 3 バイトコード．
JIS X 0213 の 1 面と 2 面を，JIS X 0202 で用いるため

漢字許容字体 (前編 4 章参照) と常用漢字表の括弧書きの字体に限って包摂規準を曲げることを決定し，それ以外の漢字に関しては，包摂規準の変更を基本的にはおこなわなかった．この結果，「 巣」と「 巣 」あるいは「漢」と「 漢 」は，JIS X 0213 ではそれぞれ別々の符号位置1に収録され，書き分けることが可能になった．つまり，常1「巣」は 1 面 33 区 67 点に，「 巣 」は 1 面 84 区 8 点に，– 13 –の代表的なエスケープシーケンスは，それぞれ「 ESC
2/4 2/8 4/15 」と「 ESC 2/4 2/8 5/0 」である．
5
1999 年 7 月の時点では 11225 字としていたが，翌月「 M̀ 」と「 m̀ 」の 2 字を削除した．

692

システム/制御/情報

第 45 巻10646 の BMP に追加するよう，国際提案することにした．というのも，この時点での ISO 10646 の実装の多く
は，1998 年 7 月に発売された Microsoft Windows 98 日
本語版を含め，UTF-16 の BMP 部分 (別名，UCS-2) のみに限定されており，BMP 以外の部分はほとんど 実装
されていなかったからである．しかし，ISO 10646 の漢字に関しては，CJK 拡張漢字 6582 字 (1998 年 4 月確定)
が最後の BMP 追加ということになっており，この時点での漢字追加は，もう BMP 以外の部分におこなうしかなかったのである．そこで WG2 は，1 字でも多くの漢字を BMP に追加すべく，奇策を用いることにした．常第 12 号(2001)

しかし，ここまでの解説を読んできた読者ならば，これらの主張に疑問を感じるはずである．文字コード のサポートが，本当に ISO 10646 に移行しているならば，なぜ日本電気は，「 野 」など 自社の JIPS 拡張文字を，ISO

10646 に追加提案しなかったのか．ユーザーの資産を守る，というならば，ISO 10646 の BMP に追加提案すべきだったはずなのに，なぜその努力を怠ったのか．あるいは，なぜ日本 IBM は，IBM 拡張文字の「 ? 」を，ISO

10646 に追加提案しなかったのか．しかも，IBM 拡張文
字と ISO 10646 との変換表において，「 ? 」を 000053DDの「 ? 」に誤変換1し，この結果，発生する文字化け 2で，ユーザー資産を破壊し続けているのは，なぜなのか．ISO

用漢字表の括弧書きの字体や人名用漢字許容字体は，互換漢字への追加を提案することにしたのである．例えば，10646 だユーザー資産だと，もっともらしい理屈をつけ「漢」と「 漢 」は，ISO 10646 では 00006F22 に統合されてはいるが，つまるところ，Shift JISX0213 が規定とているので，JIS X 0213 とのラウンド・トリップ・コン

なった場合，それをサポートするのが面倒だ，というだバージョンを保証するために，「 漢 」を互換漢字に追加すけのことではないのか．

る，という提案である．しかもこのようにすれば，例え

実際，1999 年 9 月の情報部会は，紛糾して収拾がつば「 類 」は，既に互換漢字の 0000F9D0 に収録されていかなくなり，JIS X 0213 は継続審議となった．そしてる6 ので，追加提案の必要すらなくなるのである．最終

翌月の情報部会で ，Shift JISX0213，ISO-2022-JP-3，

的に WG2 は，非漢字 128 字，漢字 303 字，互換漢字 60

EUC-JISX0213 の各附属書を，規定から参考に格下げ

字7を，ISO 10646 に追加提案することにした．

する，という形で，何とか JIS X 0213 は，審議を通過

このように，多大な労力を傾注して開発された JIS X
0213 だったが，最終審議の段階になって，とんでもないすることになった．この結果，JIS X 0213 を，規定をドンデン返しが待ちうけていたのである．

ト符号3などの方法しかなくなってしまった．すなわち，満たす形で 実装するには ，国際基準版・漢字用 8 ビッ

調査会の最終審議を受けた後，主務大臣名で制定される．

Shift JISX0213 や ISO-2022-JP-3 だけを実装した場合には，規格違反となってしまうのである．しかも，1999
年 10 月の情報部会は，今後の日本の文字コード に関しては，ISO 2022 から ISO 10646 に移行する，というこ

これが JIS 制定の大きな流れである．符号化文字集合調とを確認した．つまり，各国がそれぞれに開発した文字査研究委員会が作成した JIS X 0213 原案も，1999 年 9

コードを持ち寄る，という ISO 2022 のやり方を放棄し，

14.

JIS X 0213 の制定

原案作成委員会が作成した規格原案は，日本工業標準月に開催された日本工業標準調査会情報部会での最終審

各国がそれぞれに文字を持ち寄る，という ISO 10646 の議の後，JIS X 0213 として制定される予定であった．

やり方に移行する，ということである．言いかえれば ，

ところが，この情報部会において，日本 IBM と日本

この JIS X 0213 を最後に，日本では独自の文字コード

電気が，JIS X 0213 の制定に猛反対したのである．反を開発せず，全てを国際規格の ISO 10646 (とその翻訳対理由は大きく 2 つである．1 つは，シフト JIS の空き

規格の JIS X 0221) に委ねる，ということを，規格の最領域には，各社がメーカー外字を入れて拡張しているの終審議をおこなう情報部会みずからが，宣言したわけでで，JIS X 0213 が Shift JISX0213 を規定すると，それある．JIS X 0213 は，2000 年 1 月に制定され，日本独との間で文字化けが発生し，結果的にユーザーの資産が自の文字コード 開発は，ここに幕を閉じた．

守れない，という主張である．もう 1 つは，文字コードのサポートという点では，各社とも ISO 2022 から ISO

10646 に移行しており，今さら ISO 2022 準拠の文字コー
ドを JIS として制定すべきではない，という主張である．
主張それだけを聞けば，もっともなものであり，賛同も多く得られることだろう．
6

そもそもは，KS C 5601 (現，KS X 1001) とのラウンド・トリップ・コンバージョンを保証するためのも

1「 ? 」は，キュウという音で「急いでいく」意．これ
に対し ，ISO 10646 の 000053DD「 ? 」は，コウという音で「つつしみ告げる」意．これらは，形も音も義も異なる全くの別字である．
2
この文字化けは，Microsoft Windows 98 日本語版の
ワード パッドで，FA8F の「 ? 」を 72 ポイントで入力
し，フォントを MS P ゴシックから MS P 明朝に切り替えるだけでも，発生が確認された．
3
EUC-JISX0213 から，文字集合 2 の JIS X 0201 片仮名を除いた符号．

のである．
「概」と「 概 」は，ISO 10646 において 00006982 と7000069EA に分離されているにもかかわらず，WG2 は「 概 」を誤って互換漢字に追加提案してしまった．

– 14 –

安岡孝一：日本における最新文字コード 事情

15.

そして最新文字コード 事情

693

は，この例示字体を変更したところで，包摂規準の範囲

Group 00 の Plane 02 の漢字を含め，UTF-16 で表すこ

内だから，特に問題はないように思える．しかし，ISO10646 (およびその翻訳規格の JIS X 0221) との関係を考「嘘」
えると，そうは問屋がおろさない．ISO 10646 では，と「 嘘 」は，それぞれ別の符号位置である 00005618 と00005653 に，収録されているのである．つまり，JIS X
0208 の 17 区 19 点の例示字体を変更すると，JIS X 0208と ISO 10646 との対応が変わってしまう．これは，ISO10646 上で JIS X 0208 の文字を扱っている OS 1にとっては，致命的ともいえる変更である．そのような OS では，JIS C 6226 の 1983 年改正 (前編 6 章参照) と同様に，とのできる全ての文字を処理する仕掛けが搭載されてい新たな文字化けを発生させることになるからであり，しる．したがって，BMP 以外の部分に収録される予定のたがって一部のメーカーは，変更に追随しない可能性も

漢字も，フォントさえ実装されれば，今後は徐々に使えあるだろう．そのような意味で，JIS X 0208 の改正は，るようになっていくだろう．

あまりに無謀で危険な選択である．

その後，JIS X 0213 の漢字は，全て ISO 10646 に収録されることが ，国際会議の場で決定された．ただし ，BMP への追加収録は，「 漢 」のような互換漢字に限られ，「 野 」や「 ? 」は Group 00 の Plane 02 への収録4である．JIS X 0213 の非漢字に関しては，その多くが BMPへの収録を予定されているものの，例えば「 æ̀ 」は，「 æ」と「 ` 」の合成にすべきだ，という意見のために，現時点では収録を阻まれている5 ．なお，2001 年 11 月に発売された Microsoft Windows XP 日本語版では，これら日本国内では，2000 年 12 月に国語審議会 (現，文化審では，JIS X 0208 の 17 区 19 点の「 嘘 」はそのままに

議会国語分科会) が答申した表外漢字字体表 [8] に対し ，して，別の空き領域に「 嘘 」を追加するのは，ど うだろ

文字コードをどのようにすべきか，ということが目下の関心事である．表外漢字字体表は，「 法令，公用文書，新う．表外漢字字体表の印刷標準字体 1022 字のうち，JIS
X 0208 の例示字体とは違うもの，および JIS X 0208 に聞，雑誌，放送等，一般の社会生活において表外漢字を収録されていない「 ? 」や「 臈 」を，空き領域に追加す使用する場合の字体選択のよりどころ」として，1022 字るのである．しかしこれも，JIS X 0208 への文字追加とを示したものだが，「 将来的に文字コード の見直しがある考えられる JIS X 0213 に対し ，日本工業標準調査会情場合，表外漢字表の趣旨が生かせる形での改訂が望まれ報部会が示した反応を考えると，現実的な選択とは思わる」と，文字コードへの反映にはっきりと言及している．

れない．しかも，情報部会にとっては，ISO 2022 準拠のしかも，表外漢字の字体に関する問題は文字コード の開発は，もはや終了しているのである．

(1) 一般の書籍類や教科書などで用いられている「 鴎 」

では，情報部会の言うとおり，今後は ISO 10646 のや「 涜 」がワープロ等から打ち出せないことサポートだけをおこなうのならば，表外漢字字体表への(2) 仮に「 鴎」と「 鴎 」の両字体を打ち出すことがで対応は，ど うなるだろう．これならば話は簡単で，表外きたとしても，ど ちらの字体を標準と考えるべき

漢字字体表 1022 字は ISO 10646 に全て含まれているのかの「字体のよりどころ」がないこと

で，実装上の細かい字形差を除けば特に問題はない，との 2 点にまとめられる，というのである．日本のワープロいうことになる．できることといえば ，せいぜい，JISは，東京芝浦電気 (現，東芝) の「 JW-10 」(1979 年 2 月

X 0221 の日本文字部分レパートリに，表外漢字字体表発売) 以来，基本的に JIS X 0208 (旧称，JIS C 6226) にを反映させることぐらいである．しかし，日本文字部分

準拠してきた．したがって，表外漢字の字体に関する問

レパートリは，2001 年 4 月改正の JIS X 0221 で，参考

題は，すなわち JIS X 0208 の字体に関する問題だ [10]，に格下げとなった．その上，日本文字部分レパートリにということになる．

は，常用漢字表も人名用漢字別表も人名用漢字許容字体
表も，全く反映されていないのである．そんな状態の日ならば，JIS X 0208 に例示されている字体を，表外漢字字体表の印刷標準字体に合わせるように，JIS X 0208

本文字部分レパートリに，表外漢字字体表を反映させたを改正すれば，問題はなくなるのか．残念ながら，それ

ところで，大した意味は無いように思える．

はあまりに無謀であり，かつ危険な選択である．一例をあるいは，規格の改正をおこなわず，表外漢字字体表

挙げよう．JIS X 0208 の 17 区 19 点の例示字体は「 嘘 」

1022 字と文字コード との対応だけを示す，という視点からならば ，JIS X 0213 が俎板に上ってくる可能性はある．というのも，JIS X 0213 には，表外漢字字体表1022 字が全て含まれているからである．しかしそれも，である．これに対し，表外漢字字体表の印刷標準字体は「 嘘 」である．そこで，JIS X 0208 の 17 区 19 点の例示
字体を，「 嘘 」に変更したとしよう．JIS X 0208 として「 包摂規準の範囲内で」というただし書きが付くもので

4「 漢 」は 0000FA48，「 野 」は 0002131B，「 ? 」は00025771 に収録予定である．ちなみに「 ? 」も，中あり，「 JIS X 0213 の例示字体は変更しない」という条

国からの提案で，00020AF3 に収録予定である．また，「類」が 00029516 にも収録予定であり，0000985E の「類」との混乱が予想される．
5
ちなみに「 ǽ」は，既に 000001FD に収録されている．

– 15 –

件付きである．なぜなら，JIS X 0213 の例示字体を変更
1

現在の Microsoft Windows 日本語版は，全てこのやり方である．

694

システム/制御/情報

第 45 巻するとなると，JIS X 0208 と同様，
「 嘘 」と「 嘘 」に代表される ISO 10646 との間の問題が発生するからである．
しかも，表外漢字字体表と JIS X 0213 との対応を示し
たからといって，JIS X 0213 の制定に反対した各メーカーが，表外漢字字体表のために改めて JIS X 0213 を実装する可能性は，極めて低いと言わざるをえない．
残念ながら，これが，日本における最新文字コード 事情である．読者諸氏においては，さぞガッカリしたに違いない．しかし ながら，規格の制定や改正というもの
は，権謀術数と妥協の渦巻く，極めて人間臭い作業なのである．しかも，ある規格を制定あるいは改正したからといって，それに携わった者の腹のうちは，それぞれに異なっているのも，また事実である．本稿で述べてきたのも，文字コード 事情のある一側面であって，他の人から見れば，また全く違う側面がありうるはずである．読者諸氏においては，まずは規格そのもの，それもハンドブックではなく規格票そのものを，解説も含め，スミからスミまで熟読するよう心がけられたい．そうすれば ，世の中に流布する上スベリで煽動的な文字コード 論に，振り回されるようなことにはならないはずである．

参 考 文 献[1] 夏 目 漱 石: 草 枕; 新 小説，第 11 年 ，第 9 卷 ，本欄，
pp.1-144，1906 年 9 月．
[2] The Unicode Consortium: The Unicode Standard— Worldwide Character Encoding, Version 1.0;
Addison-Wesley, June 1992.
[3] 小池建夫: 統合化 CJK 漢字集合の実際; しにか，Vol.4，
No.2，pp.37-43，1993 年 2 月．
[4] 安岡孝一，安岡素子: 「 ? 」はなぜ JIS X 0221 に含まれているのか—Unicode 幽霊字研究—; 情報処理学会研究報告，Vol.97，No.80 (人文科学とコンピュータ研究
報告 No.35)，97-CH-35-9，pp.49-54，1997 年 8 月．
[5] 和田英一: Unicode は好きですか？; 情報処理，Vol.39，
No.4，pp.321-323，1998 年 4 月．
[6] 安岡孝一，安岡素子: 文字コード の世界; 東京電機大学
出版局，1999 年 9 月．
[7] 安岡孝一: JIS X 0213 の符号化表現; 人文学と情報処理，
No.26，pp.9-17，2000 年 4 月．
[8] 国語審議会: 表外漢字字体表; 国語審議会答申，2000 年
12 月．
[9] 小林龍生，安岡孝一，戸村哲，三上喜貴 [編]: インターネット時代の文字コード ; bit 別冊，共立出版，2001 年 4月．

第 12 号(2001)

coded character set for information interchange; January 1991.
• ISO/IEC 2022: Information Technology — Character code structure and extension techniques; December
1994 (corrigendum April 1999).
• ISO/IEC 10646-1: Information Technology — Universal Multiple-Octet Coded Character Set (UCS) — Part
1: Architecture and Basic Multilingual Plane; October
2000.
• ITU-T Recommendation S.1: International Telegraph
Alphabet No.2; March 1993.
• ITU-T Recommendation T.101: International Interworking for Videotex Services; November 1994.
• JIS X 0201: 7 ビット及び 8 ビットの情報交換用符号化文
字集合; 1997 年 1 月．
• JIS X 0202: 情報交換用符号の拡張法; 1998 年 1 月．
• JIS X 0208: 7 ビット及び 8 ビットの 2 バイト情報交換用
符号化漢字集合; 1997 年 1 月．
• JIS X 0212: 情報交換用漢字符号—補助漢字; 1990 年 10 月．
• JIS X 0213: 7 ビット及び 8 ビットの 2 バイト情報交換用
符号化拡張漢字集合; 2000 年 1 月．
• JIS X 0221-1: 国際符号化文字集合 (UCS)—第 1 部: 体系
及び基本多言語面; 2001 年 4 月．
• RFC 1468: Japanese Character Encoding for Internet
Messages; June 1993.
• RFC 1554: ISO-2022-JP-2: Multilingual Extension of
ISO-2022-JP; December 1993.
• RFC 2045: Multipurpose Internet Mail Extensions(MIME) Part One: Format of Internet Message Bodies; November 1996.
• RFC 2047: MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for NonASCII Text; November 1996.
• RFC 2237: Japanese Character Encoding for Internet
Messages; November 1997.
• RFC 2822: Internet Message Format; April 2001.

著 者 略 歴
やす おか

こう いち

安 岡

孝 一
1965 年 2 月 18 日生．1988 年 3 月京都大学工学部情報工学科卒業．1990 年 3 月京都大学大学院工学研究科情報工学専攻修士課程修了．同年 4 月京都大学大型計算機センター助手，1997 年 8 月同助教授．2000
年 4 月京都大学人文科学研究所附属漢字情報研究センター助教授，現在に至る．京都大学博士 (工学)．
1996 年 10 月から 2000 年 3 月まで符号化文字集合調査研究委
員会 WG2 委員．2000 年 9 月いきなり二女の父となり，2000
年 12 月から情報処理学会文字コード 標準体系専門委員会委員．2001 年 6 月から符号化文字集合調査研究委員会委員．文字コード に関する著書に [6,9] がある．電子情報通信学会会員．yasuoka@kanji.zinbun.kyoto-u.ac.jp[10] 小林一仁: 漢字政策と「表外漢字字体表」; Science of
Humanity Bensei，Vol.31，pp.16-27，2001 年 4 月．

最 新 参 考 規 格• ANSI X 3.4: Information Systems — Coded Character Sets — 7-bit American National Standard Code forInformation Interchange (7bit ASCII); March 1986.
• ISO/IEC 646: Information Technology — ISO 7-bit– 16 –