ここでは、ウェブで公開する文書の文字コードについての私の方針につい て説明する。以下の記述は近い将来、「新JIS漢字」規格の制定・ 普及に伴って変更される可能性が高い。
私がウェブで公開する日本語HTML文書の文字コードを次のようにすること にした。HTML文書だけでなく、CSSスタイルシートやXML文書等も(日本文字を 含む場合には)同様の符号化を行う予定である。
JIS X 0208:1997で規定される「国際基準版・漢字用8ビット符号」(規 格の7.2.2、『JIS漢字字典』横組みpp.245-246)によって符号化する。
ウェブサーバから文書を送信する際、HTTP応答ヘッダのcharsetパラメー タで“EUC-JP”を指定する。
今後公開するページはこの方針を採るが、既存のページで他の文字コード によって符号化されているものについては、ある時期に一斉にコードを切り替 えることはしない。ページの更新などの際に順次変更していく。
上のように符号化された文書をHTML 4.0の文書文字集合であるUCS-4に変換 する場合は、上記で参照する規格で規定される文字の名前に従って変換するこ とが望ましい。この方法によって、「EUC」のどの文字がUCSのどの文字になる のかが、厳密に決定できる。
例えば、16進表現で0xa5a2の文字(片仮名の「ア」)の名前は、“KATAKANA LETTER A”であるし、0xa1dd (マイナス記号「−」)は“MINUS SIGN”である から、これらをUCSに変換する際にはUCSの中の同じ名前を持つ文字と対応付け れば良い。
ただし、利用者の目的に応じてそれ以外の変換表を用いることは自由であ る。例えば、JIS漢字とUCSとの間で包摂規準の異なる文字を変換する場合に、 その方が適切と考えられるときには、EUCでの文字の名前と異なるUCSの文字に 変換することがあっても良い。
以下では、上の「方針」についてその理由等の解説を行う。
上で述べた文字コードは所謂「日本語EUC」であるが、目立つ違いとして以 下が挙げられる。
EUCではG2にJIS X 0201片仮名が割り当てられているが、これを使用し ない。
X0201にある文字はG1のJIS X 0208に全て揃っているので、敢えてX0201を 割り当てても実用的な価値は無い。強いて言えば、シフトJISコードからの往 復変換に使えるぐらいである。また、EUCはISO 2022 (国内規格ではJIS X 0202)を利用しているが、この規格の一意な符号化の制限を適用すると、同じ 文字がある場合にはG番号の小さい方のみが採用されることになるので、G2の JIS X 0201の方の文字は全滅する。
EUCではG3にJIS X 0212補助漢字が割り当てられているが、これを使用 しない。
補助漢字は実装されていないことが多く、情報も不足していることなどか ら、利用は稀である。また、新JIS漢字が制定されれば利用する必然性はほと んど無い。
こういった違いはあるが、このコードで符号化された文書はMIMEで使われ る“EUC-JP”というcharset名で問題なくデコードできる。むしろ、片仮名の 重複符号化を最初から排除している分、元々のEUCよりも好ましい符号化であ ると考えられる。また、ISO/IEC 646 IRV (ASCIIと同等)とJIS X 0208で重複 している文字についても、重複符号化を原則として行わないことがJISの規定 の中で明記されている。
私のページでは以前からISO-2022-JPで符号化していたが、敢えてEUCに変 える理由としては以下が挙げられる。
サイズの節約。私が公開しているページでは、ISO-2022-JPからEUCへ の変換によって1割程度小さくなる。
ISO-2022-JPではJIS X 0201のラテン文字が指示され得る。この指示が 使われることをあり得なくすることによって、円記号とバックスラッシュ、な らびにチルダとオーバーラインの混同を避けることができる。EUCで符号化し ている限り、(Windowsがそれをどう表示しようとも)0x5cは円記号でなくバッ クスラッシュである。(なお、新JIS漢字で策定されるISO-2022-JP-3ではJISラ テン文字の指示は廃止される予定なのでこの問題は起こらない)
一方、ウェブでISO-2022-JPを使う利点としては、ビットパターンからの自 動判別がたやすくできることがある。しかし、今回の方針のようにHTTPで “charset”を指定すれば、より確実に符号化方式情報をウェブクライアント に与えることができる。ただし、この情報が有効に利用されるかどうかはクラ イアント次第である。
charsetの付加については、適切に行えないISPが多いと思うが、私が利用 しているASAHIネットでは、ファ イル名の拡張子によってcharset情報付きで文書を送ることができるので、こ れを利用する(詳しくは内田明 氏による解説を参照のこと)。
EUCやISO-2022-JPでなく、パソコン等で広く普及しているシフトJISコード を使うことも考えられる。だが、ウェブで使う際には、URIにしばしば使われ る記号である「~」(チルダ)が無いことが問題である(厳密に解釈すれば、だが)。 シフトJISではASCIIでなくJISラテン文字が使われているので、0x7eはチルダ (TILDE)でなくオーバーライン(OVERLINE)である。このため、シフトJISでは URIの中のチルダを生のまま書くことはできず、“%7e”のように書く必要があ るのである。
なお、UCS系の文字コードを利用するという手もあるが、利用できる計算機 環境が限定されるし(なにより私の環境では編集できない)、情報も不足してい るので、コストに見合わないと判断し、当分は見送ることとした。EUCならば、 UNIX環境はもちろんのこと、Windowsでも、広く使われているMeadowやless、 Perl、Lynx、あるいはNamazu等のソフトウェアで自在に扱うことができる。
HTML 4.0の文書文字集合はUCS-4 (ISO/IEC 10646-1)であり、HTML文書がこ のコードに変換して処理される可能性がありながら(実際には常にそうされて いるわけでは全く無いし、HTMLの仕様はそれを要求してもいない)、その他の 文字コードとUCSとの間の変換について様々な見解や実装があることを考慮し、 コード変換について特に節を立てることとした。
もっとも、ここで述べているのはUCSとJIS漢字規格とを利用すれば自然に 出てくる解であり、新しいことではない。ただ、現状における実際の変換には、 規格で規定される文字の名前(character name)に従わない複数の異なった実装 が使われているので、注意が必要である。