ここでは、JIS漢字(JIS X 0208)とUCS (ISO/IEC 10646-1, JIS X 0221, Unicode)の文字の対応関係について述べる。この文書の内容は、JISとUnicode の間の妥当なコード変換を理解するために必要となる。 制定されたばかりでまだ規格票の 出版されていない新JIS漢字 (JIS X 0213)については詳しく触れることができなかった。【追記: 今後 記述予定】
UCS (Unicode) の各文字には、文字を一意に識別するための名前が付けられている。一 方、JIS漢字の各文字にも、これに対応する文字名称が1997年の改正において 付けられた。これによってJIS漢字とUCSの各文字について対応を知ることがで きる。
ただし、シフトJISの場合には1文字(FULLWIDTH OVERLINE)だけ例外がある。 付録Cを参照されたい。
コード変換の実装の際に参考になる、テキスト形式の変換表を公開してい るサイトを以下に掲げる。これらのサイトにある変換表は、標準に則っている。
また、GNU C Libraryのiconvで、妥当な変換表を挙げると以下のようにな る。
一方、CP932 (MS社のプロプライエタリな変換表) などは、異種プラット フォーム間のデータ交換で支障が出るので、一般には使うべきでない。(ただ し、MS 社製品の内部処理用としては使わざるを得ないことがある。その場合、 CP932で変換したUnicode (MS-Unicode) はメモリ上でのみ用い、外部に流出 させないような工夫が必要である)
JIS漢字とUCSとでは、例示字形が同じに見えてもそのコードポイントが表 現し得る字形の範囲に違いのある漢字がある。
たとえば、JIS X 0208:1997の「解説」に示されている例に、JIS漢字の 「姫」という字に対応する文字がUCSには2種類あるということがある。
つまり、JIS漢字とUCSとでは漢字のコードポイントが一対一に対応しない。 これはUCSの「統合漢字」における原規格分離規則(source separation rule) による。この規則は、「統合漢字」の元になった各文字コード規格において異 なるコードポイントに当てられている漢字は、UCSにおいても別のコードポイ ントを与える(つまり、分離する)というものである。上の例においては、日本 の規格で分離しない字体が中国と台湾の規格で分離されていたためにUCSでも 分離されているのである。
UCSで採用された「文字名称」という識別方法は、このような多対一の対応 関係を記述できない。便宜的な解決法としては、対応する複数の文字のうち、 例示字形の似ている方の文字名称を採用するという考え方が妥当だろう。これ はあくまでも便宜的な解決であって、論理的には、より精密な記述方法が考え られるべきである。
漢字以外の文字・記号については、対応関係の問題はほとんど存在しない。
ただし、実際に使われているコード変換プログラムには、文字名称と食い 違うやりかたで変換するものがあることが知られている。(というよりは寧ろ、 困ったことに、大抵のコード変換器はどこかで間違っている)
JIS漢字の波ダッシュ(〜)の名前はWAVE DASHである。対応するUCSのコード ポイントはU+301Cである。
ところが、シフトJISからUCSへの変換で、この記号をUCSのFULLWIDTH TILDEに変換するものがある。
この変換は次の点でおかしい。
また、Unicode 2.0の仕様書ではWAVE DASHに「JIS punctuation」との注釈 があり、JISの波ダッシュに対応させる意図が読み取れる。
JIS漢字の全角ダッシュ(―)はEM DASHである。対応するUCSのコードポイン トはU+2014である。
しかし、Unicodeコンソーシアムが提供する変換表では、Unicodeで対応す る文字はEM DASHでなくHORINZONTAL BAR (U+2015)になっている。
これはUnicodeの変換表の間違いであろう。仮にJISの文字名称を見ないこ とにしても、JISの規格票では記号の意味として「ダッシュ(全角)」と記され ているので、EM DASHとHORINZONTAL BARのどちらが適切かといえばEM DASHで ある。
JIS漢字の負符号(−)はMINUS SIGNである。対応するUCSのコードポイント はU+2212である。
これをUCSのFULLWIDTH HYPHEN-MINUSに変換するものがあるが、このような 変換は、文字集合の体系としての理解に基づいているとはいえない。
JIS漢字においては、負符号とハイフン(‐)とは明確に分離されており、紛 れがない。一方、HYPHEN-MINUSはASCIIの「-」のことで、ハイフンにも負符号 にも使われる、意味の曖昧な記号である。JIS漢字にHYPHEN-MINUSは存在しな い。よって上のような変換は不適切である。
対応関係を整理すると次の表のようになる。
文字名称 | ASCII (ISO 646) | JIS X 0208 | UCS |
---|---|---|---|
HYPHEN-MINUS | 2/13 | 無し (JIS X 0213にはある) | U+002D |
HYPHEN | 無し | 1-30 | U+2010 |
MINUS SIGN | 無し | 1-61 | U+2212 |
JIS漢字のセント記号(¢)はCENT SIGNである。対応するUCSのコードポイン トはU+00A2である。
ところが、これをUCSのFULLWIDTH CENT SIGNに変換するものがある。ASCII にもJIS X 0201にもセント記号はないので、これが「FULLWIDTH」になる理由 はない。従ってこの変換は不適切である。
JIS漢字のポンド記号(£)はPOUND SIGNである。対応するUCSのコードポ イントはU+00A3である。
ところが、これをUCSのFULLWIDTH POUND SIGNに変換するものがある。 ASCIIにもJIS X 0201にもポンド記号はないので、これが「FULLWIDTH」になる 理由はない。従ってこの変換は不適切である。
JIS漢字の否定記号(¬)はNOT SIGNである。対応するUCSのコードポイント はU+00ACである。
ところが、これをUCSのFULLWIDTH NOT SIGNに変換するものがある。ASCII にもJIS X 0201にも否定記号はないので、これが「FULLWIDTH」になる理由は ない。従ってこの変換は不適切である。
JIS漢字の双柱(‖)はDOUBLE VERTICAL LINEである。対応するUCSのコード ポイントはU+2016である。
これをUCSのPARALLEL TOに変換するものがある。こちらは数学で「平行」 を表す記号である。双柱と平行とは、実際のテキストの中で使われる文脈から 切り離すと形の上からは区別しがたい。また、90JISではこの文字の説明とし て「双柱」とともに「平行」をも挙げていた。
しかしJIS漢字の「‖」が双柱か平行かといえば、双柱とするのが適当であ り、平行とはしがたい。区点の並びの中で双柱は、斜線や波ダッシュ、縦線な どとともに一般的な記述記号のグループの中にあり、学術記号(角∠、垂直⊥、 弧⌒等が含まれる)のグループとは区別されているからである。
なお、JIS X 0213では、学術記号としての「平行」(PARALLEL TO)が「平行 の否定」(NOT PARALLEL TO)とともに追加された。
JIS漢字の「大きな丸」(◯)はLARGE CIRCLEである。対応するUCSのコード ポイントはU+25EFである。
JISではこれは元々「合成用」という位置付けだったが、どのような文字を どうすれば合成できるのかが不明であり、また実際にも合成することはできな かったので、97JISではとうとう「合成のために用いてはならない」とされる こととなった。
Unicode 2.0仕様書のCOMBINING ENCLOSING CIRCLE (U+20DD)の注釈には 「JIS composition circle」とあるが、Unicodeコンソーシアムの提供する変 換表にはこの文字は現れず、JISの文字名称と同じLARGE CIRCLE (U+25EF)が対 応させられているので問題はない。
シフトJISコードはJIS X 0201 (ラテン文字・片仮名の両方)とJIS漢字とを 符号化する符号化文字集合である。(97JISの附属書1を参照のこと)
オーバライン「 ̄」(OVERLINE)はJIS X 0201とJIS X 0208の両方に存在す るので、シフトJISにおいては、JIS X 0208の方のオーバラインは代替名称の FULLWIDTH OVERLINEとなる。(JIS X 0208のオーバラインが本質的に 「FULLWIDTH」なのではなく、JIS X 0201ともに使う場合にはオーバラインが 重複してしまうために片方が代替名称になるのだということに注意されたい)
ところが、現在のUCSには、このFULLWIDTH OVERLINEが存在しない。この1 文字に関してはシフトJISとUCSとの間で往復変換の結果が保証されないという ことになる。また、代替名称とはいえ、「UCSはシフトJISをカバーしきれてい ない」という言い方もできよう。
Unicodeコンソーシアムの変換表では、FULLWIDTH OVERLINEにあたる文字が 「FULLWIDTH MACRON」になっている。もしこれがシフトJISの「FULLWIDTH OVERLINE」の役割を果たすつもりのものであったならば、UCS側の文字名称の 付け間違いである。
従って、シフトJISからUCSへの変換では、FULLWIDTH OVERLINEについて、 変換先の候補が二つあることになる。OVERLINEとFULLWIDTH MACRONである。
UCSの意図からすると、シフトJISとの往復変換を保証するつもりであった 筈であるから、とりあえずFULLWIDTH MACRONにうつしておき、この文字名称が FULLWIDTH OVERLINEに訂正されるのを待つというのが無難な考え方といえよう。 ただし、代替名称にあたる文字が無いのだから、FULLWIDTHでないOVERLINEに 変換することも間違いとはいいきれない。
シフトJISにおけるバイト値0x20〜0x7fの範囲はJIS X 0201と同等であって、 ASCII (ISO/IEC 646 IRV)ではない。これはシフトJISの由来による。日本のパ ソコンでJIS X 0201の8ビットコード(ラテン文字・片仮名)を使っていたとこ ろに、これと互換性を保ちながらJIS漢字をも使おうとして生み出されたのが、 既存のコードの隙間にJIS漢字を「シフト」して強引に詰め込む「シフトJIS」 コードであった。よって、シフトJISの1バイトコードはJIS X 0201なのであり、 ASCIIではあり得ない。
(ちなみに、シフトJISでなくEUCの場合は、UnixでASCIIを使っ ていたところに漢字コードを追加したコードなので、0x20〜0x7fはASCIIであ る)
従って、シフトJISにおけるバイト値0x5cは円記号(YEN SIGN)であり、 ASCIIで同じバイト値の逆斜線(REVERSE SOLIDUS。「バックスラッシュ」とも) ではない。
さりながら、シフトJISの円記号をUCSの逆斜線(REVERSE SOLIDUS)に変換す るものがある。
バイト値が同じであるために円記号と逆斜線を混同して使われてきた経緯 があるので、状況に応じて、円記号を逆斜線に変換することがあるかもしれな い。しかしそれは特殊な目的のための変換であり、常用するものではないこと に注意されたい。
なお、シフトJISのYEN SIGNをREVERSE SOLIDUSに変換し、FULLWIDTH YEN SIGNをそのままの文字名称としてUCSに変換するものがあるが、この方法では FULLWIDTHでない普通のYEN SIGNが存在しないことになる。
円記号およびチルダについて、シフトJISとEUCの違いを正しくまとめると 次のようになる。少々込み入って見えるが、要は「ASCII/JISラテン文字とJIS 漢字とで重複している文字があるとき、JIS漢字の方がFULLWIDTHになる」とい うことである。シフトJISにチルダが無いのは意外かもしれないが、規格をよ く読むとこれが正しいということが分かる。新JIS漢字にはチルダが入るので、 シフトJISでもチルダを表現できることになる。
シフトJISの場合、円記号とオーバラインには1バイトのものが使われ る。2バイトの方は代替名称(FULLWIDTH)になる。逆斜線は(1バイトのものはな いので)2バイトのものが使われる(つまりFULLWIDTHにはならない)。チルダは どこにも存在しない。
EUCの場合、逆斜線とチルダには1バイトのものが使われる。2バイトの 逆斜線は代替名称(FULLWIDTH)になる。円記号とオーバラインは(1バイトのも のはないので)2バイトの方が使われる(つまりFULLWIDTHにはならない)。チル ダは重複しないが、もし補助漢字(JIS X 0212)を使うと、その中のチルダは FULLWIDTH TILDEになる。
文字名称 | EUC (ASCII + JIS漢字) | シフトJIS (JISラテン文字 + JIS漢字) |
---|---|---|
YEN SIGN | 0xa1ef | 0x5c |
FULLWIDTH YEN SIGN | - | 0x818f |
REVERSE SOLIDUS | 0x5c | 0x815f |
FULLWIDTH REVERSE SOLIDUS | 0xa1c0 | - |
OVERLINE | 0xa1b1 | 0x7e |
FULLWIDTH OVERLINE | - | 0x8150 |
TILDE | 0x7e | - |
FULLWIDTH TILDE | - | - |
ただし、97JISをよく読むと、代替名称「FULLWIDTH REVERSE SOLIDUS」が どこにも見当たらない。これは編集上の誤りのようだ。
本稿では具体的にどの実装がどのようなコード変換を行うかについては立 ち入らない。下記の資料を参考にされたい。
日本で使われる文字コードとUCSとの間の変換については既にいくつかの文 書で言及されているが、今回敢えてこのような文書を作成したのは以下のよう な理由による。
それらの文書で有力なものは、JIS X 0208の1997年改正より前に書か れたものらしく、97JISの成果が取り入れられていない。UCSとの対応について は97JISで一通りの決着を見ている。
「全角・半角」等についての理解が必ずしも正確でない解説が見受け られる。
特に前者については、変換プログラムによって違いのある文字について、 97JISを参照するのみならず、90JISでの記述に溯って97JISで付けられた文字 名称の検討を行った。その結果、規格の一貫性という点からみても十分に妥当 な文字名称が付けられていることを確認できた。(付録 B)
文字集合は体系として理解される。例えば、ラテン文字とギリシャ文字と を含む文字集合があり、両方のアルファベットの最初の文字「A」を区別しな かったとする。だとすれば、きっと「B」も「D」も「E」も、形の同じものは 全部統合している筈だと考えるのが普通である。ところが、もし「M」と「Μ」 だけは区別していたとしたら不思議である。何か特別な理由があるとすれば、 文字集合の表にでもその理由が付せられていることだろう。合理的な理由が見 つからないとなると、統合のし忘れと考えられる。JIS漢字で「飲」と「飮」 が統合されていないのを97JISの附属書7が「第1次規格の見落とし」と判断し たのは、JIS漢字を体系として調査した成果である。この附属書では「見落と し」の原因も推測されている。
近頃、体系としての理解を等閑にし、文字や記号の意味を無視し、ただバ イト値だけしか見ていない文字コード論を見かけることがある。このような議 論は極端に走るほど文字コードの本質からかけ離れてゆく。誤った理解に基づ いたコード変換プログラムの実装だけを根拠にして既存の文字コード規格を欠 陥呼ばわりするなどはその最たるものであり――この手の言い種は特定のコー ド系のプロパガンダだけを目的としており、論理性などはもとより期待すべく もないが――本末転倒も甚だしい。規格票のように紙に印刷された資料を掘り 起こすことを厭わずに確かな調査を行い、深い理解に基づいた議論が展開され ることを切望する。