Message-ID: <1993Dec24.050247.21153@kuis.kyoto-u.ac.jp> Newsgroups: ku.misc From: hgt2531@hiuxm.kuec.kyoto-u.ac.jp (NIDE Naoyuki) Subject: moji code (revised) Organization: Educational Center for Information Processing, Kyoto University Date: Fri, 24 Dec 1993 05:02:47 GMT 新出@奈良女子大でございます。先に、 > 先に、「最近、文字コードの関する怪しげな理解を見聞きする機会が段々増え > てきたので、これは放置しとけないかなとか思って、こんな文書を作りました。」 > とのふれこみのもと、教育センターのVOS3 BBSに書きのような文書を掲示したの > ですが、何にも反応がなかったので図にのって:-)、このたび(若干の修正の上) > kuにも投稿してみます。より多くの方々から誤りなどのご教示を頂けるのではな > いかと思っております。 というふれこみのもと投稿した文書に、実際に多くの方々から誤りなどのご教示 を頂け、感謝しております。このたび修正版を掲示してみますので、今後も誤り の指摘などよろしくお願いいたします。 # なお、UNICODEの話は、誰か補って下さい:-) ------------------------------------------------------------------------ 文字コードの国際規格について 新出尚之(nide@nara-wu.ac.jp) 93.12.24 Ver 1.04 コンピュータ内で文字データを扱うときは、文字を整数によって符号化して扱っ ています。この符号化の方法は、ISO(国際標準化機構)によって国際規格が定め られています。 正確にはその規格はあくまで「情報交換用の」(つまりコンピュータ同士の通 信などに使われる)符号を定めたものであり、コンピュータ内に文字情報を蓄え ておくときにどんな符号を使うかにまで言及してはいないのですが、実際には多 くのコンピュータで、情報交換に使われるのと同じ、もしくは準じた符号が、内 部に文字情報を蓄えておくときにも使われています。 しかしこの規格が、現状では必ずしも一般的に正しく理解されているとは言え ません。というより、誤解されていることの方が多いと言えましょう。 典型的な例では、パソコン通信で超有名なWTERMという通信ソフトのドキュメ ントにも、規格を誤解した大嘘が書いてある始末です(1993年6月20日現在のもの で確認)。仮にも「通信」に使われるソフトが、情報交換用符号の規格を全く理 解せずに作られていることに、さむけを覚えずにはいられません。しかも困った ことに、このソフトは広く使われているので、規格の誤解という害毒を広く撒き 散らしていることにもなります。 この他、ちまたの書籍や雑誌などにも、規格に対する誤った記述が、そこらじゅ うに散見され、誤解を広めています。 今やコンピュータの世界は、多国語対応化、国際化の動きが急速に進展してい ます。いつまでもいい加減な文字コードの理解のしかたのままでは、世界に取り 残されるのは確実だという気がします。 何とかしなければ、との思いから、筆者はこの文章をまとめました。活用して 頂ければ幸いです。 この文書は、一切の変更を加えない場合に限りコピーフリーとします。 なお、注意して書いたつもりですが、筆者自身の誤解や不注意による誤りもあ るかと思います。気付かれた点がありましたらお知らせ頂ければ幸いです。 1. ASCIIコード 文字の符号化の国際規格の基本となっているのは、米国でANSI(米国規格協会) によって定められた「ASCIIコード」と呼ばれるものです。 多くのコンピュータでは、内部に蓄える情報の量の最小単位(1バイト)は、2進 数8桁(8ビットという)にあたります(1バイトが8ビットでないコンピュータもあ り、その場合は8ビットを表す言葉として「1オクテット」を使いますが、本稿で は「1バイト＝8ビット」だとして話を進めます)。8ビットでは、00000000から 11111111まで(10進数では0から255まで)の256通りの文字を表せますが、ASCIIコー ドでは最上位の1ビットは常に0とし、下位7ビットだけを使いますので、128通り の文字が表現できることになります。 文字コードの話をするときは、よく、8ビットの上位・下位4ビットずつをそれ ぞれ16進数の1桁(0, 1, 2, …, 14, 15)で表し、それを「/」で区切って表記し ます。例えば01001101は「4/13」のように書きます。ASCIIコードでの符号と文 字の対応は次のようになります。 下位4ビット | 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 -----+--------------------------------------------------------------- 0 | BEL BS TAB LF FF CR SO SI 上 1 | ESC 位 2 |SPC ! " # $ % & ' ( ) * + , - . / ４ 3 | 0 1 2 3 4 5 6 7 8 9 : ; < = > ? ビ 4 | @ A B C D E F G H I J K L M N O ッ 5 | P Q R S T U V W X Y Z [ ＼ ] ^ _ ト 6 | ` a b c d e f g h i j k l m n o 7 | p q r s t u v w x y z { | } 〜 DEL 例えば、符号4/13は「M」という文字を表しています。なお、5/12はバックス ラッシュ、7/14はチルドと呼ばれる文字です。 上表のうち、0/0から2/0までと7/15の部分は「制御文字領域」と呼ばれます。 これら34個は、普通の文字ではなく、文字データの中に混じって特別な機能を表 すものです(上の表で特に何も書いていないところにも、それぞれの制御文字が 割り当てられています)。例えば2/0は空白(スペース)文字、0/10は改行文字、 7/15は一文字削除を表します。また、1/11はエスケープ文字と呼ばれ、文字コー ドの様々な拡張などに用いられます。 ASCIIコードは米国で使われる文字を表現するために作られた規格ですが、他 国でもこの規格を基にした文字コードが使われるようになり、そのためにISO646 BCT(Basic Code Table)という規格が作られました。この規格はおおむねASCII コードに基づいていますが、次の12個の領域には、ASCIIコードとは別な文字を 割り当てても良いことになっています。 符号 |2/3 2/4 4/0 5/11 5/12 5/13 5/14 6/0 7/11 7/12 7/13 7/14 ---------+-------------------------------------------------------- ASCII文字| # $ @ [ ＼ ] ^ ` { | } 〜 このため日本では、5/12のバックスラッシュの代わりに円記号「￥」を割り当 て、7/14のチルドの代わりに「￣」(オーバースコア文字)を割り当てて使ってい ます。これが「JIS X0201ローマ字」という規格(以前は「JIS C 6220」と呼ばれ ていたもの。「ローマ字」と断る理由は後述の「JIS X0201片仮名」と区別する ため)であり、俗に「JIS 1バイト英数文字」とか「JISローマ字」などと呼ばれ ています。よく、C言語の教科書などでバックスラッシュ文字を使っているのに、 日本の端末では円記号で代用せざるを得なかったりするのは、こういうわけです。 また他国でも、例えば英国では2/3に「£」を割り当てたり(ISO646英国、BSI 4730)、ドイツではAOUのウムラウトを割り当てる(ISO646ドイツ、DIN 6083)など、 各国の実情に合わせて使っています。 ちなみに、JIS X0201ローマ字とASCIIの違いは前述の2文字だけです。文献に よっては「ASCIIでは6/0がバッククォート、7/12の『|』は一本線であるが、JIS ローマ字では6/0が空白、7/12の『|』文字は線が上下2つに分かれている」とし ているものもありますが、誤りです。NEC製のものなど一部のマシンが、勝手に そのように表示しているに過ぎません。特に、6/0を空白で表示することについ ては、「`」という文字を多用するLISP言語などのユーザが昔から迷惑しており、 悪名高い話です。また、「|」文字を上下に分かれた形で表示することについて は、「l」との区別や感嘆符とのからみでの変遷など諸説ありますが、いずれに しても、表示に使うフォント(文字の形)の問題であり、文字コードの規格とは別 な話です。 2. 多バイトコード コンピュータで扱える文字は、当初はASCIIコード文字のように、文字の種類 の少ないものばかりでした。コンピュータで日本語を扱うに際しても、最初は使 えるのは片仮名(と若干の記号)だけでした。片仮名の文字コードも、やはりJIS 規格で「JIS X0201片仮名」として定められています(「JIS 1バイト片仮名」な どとも俗称されます)。一応紹介しておきましょう。 下位4ビット | 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 -------+--------------------------------------------------------------- 上 2 | 。 「 」 、 ・ ヲ ァ ィ ゥ ェ ォ ャ ュ ョ ッ ビ位 3 |ー ア イ ウ エ オ カ キ ク ケ コ サ シ ス セ ソ ッ４ 4 |タ チ ツ テ ト ナ ニ ヌ ネ ノ ハ ヒ フ ヘ ホ マ ト 5 |ミ ム メ モ ヤ ユ ヨ ラ リ ル レ ロ ワ ン ゛ ゜ 上表のうち2/0は片仮名としては定義されていません。結局JIS X0201片仮名と しては2/1〜5/15の63個の領域が使われていることになります。 しかし、コンピュータの処理能力の増大により、文字の種類の多い言語も扱え るようになってきました。日本語についても片仮名だけではなく、平仮名や漢字 を含めてコンピュータで扱うことが可能になりました。 日本語で使う文字は、漢字だけでも数千個あるいはそれを上回ります。1バイ トで表現できる文字の数はどうやっても256を超えられないので、1バイトで日本 語文字の全てを表すことはできません。このため、日本語文字を表すには、1文 字あたり2バイトを使います。このように、1文字を表現するのに2バイト以上を 使う文字コードを「多バイトコード」と呼んでいます。 日本語の文字コードは、「JIS X0208」という規格で定められています(以前は 「JIS C 6226」と呼ばれていたもの。「JIS漢字」とも俗称されます)。この規格 では、2/1から7/14までの94通りの符号2つの組み合わせで1つの日本語文字を表 します。下位7ビットだけを使い、しかもASCIIコードで機能文字が割り当てられ ている領域は使っていないわけです。例えば「漢」という文字は3/4 4/1という 2バイトで表現されます。但し、2バイトの組み合わせ全てに文字が割り当てられ ているわけではなく、例えば2/13 2/1という組み合わせには文字が割り当てられ ていません。 実はJIS X0208には旧版と新版があり、それぞれ規格の制定された年号を付け て、JIS X0208-1978およびJIS X0208-1983と呼ばれます(さらに新しいJIS X0208 -1990というものもあるのですが、本稿では触れません)。2つの違いは、同じ文 字の旧字体と新字体が一部で入れ替わったことと、新版では漢字が4文字、特殊 文字が39文字、罫線素片が32文字増えた(つまり、2バイトの組み合わせのうち旧 版で文字を割り当てられていないものの一部に、新版では新たに文字を割り当て た)ことですが、あまり大きく違ってはいないと言えるでしょう。例えば新版で は、2/2 6/5に開平(ルート)記号、2/8 2/12に太い横の罫線文字を割り当ててい ますが、旧版ではこれらに何の文字も割り当てていません。 下はJIS X0208での符号と文字の対応表の一部です。なお、2/1 2/1のところは (日本語文字としての)空白文字です。 2バイト目 |2/1 2/2 2/3 2/4 2/5 2/6 2/7 … 3/0 3/1 3/2 3/3 3/4 3/5 … ----+----------------------------------------------------------- 2/1 | 　 、 。 ， ． ・ ： … ＾ ￣ ＿ ヽ ヾ ゝ … : | : : : : : : : : : : : : : １ 2/4 | ぁ あ ぃ い ぅ う ぇ … ぐ け げ こ ご さ … バ 2/5 | ァ ア ィ イ ゥ ウ ェ … グ ケ ゲ コ ゴ サ … イ 2/6 | Α Β Γ Δ Ε Ζ Η … Π Ρ Σ Τ Υ Φ … ト : | : : : : : : : : : : : : : 目 3/0 | 亜 唖 娃 阿 哀 愛 挨 … 旭 葦 芦 鯵 梓 圧 … 3/1 | 院 陰 隠 韻 吋 右 宇 … 碓 臼 渦 嘘 唄 欝 … : | : : : : : : : : : : : : : ちなみに、JIS X0208では片仮名のコードもJIS X0201片仮名とは別個に定めて います。例えば片仮名の「カ」はJIS X0208では2/5 2/11で表されます。従って JIS X0208があれば、JIS X0201の片仮名は使わなくて済むことになり、実際使わ ないべきだという意見が増えてきています。また、いくつかの文字セットを混在 して使う場合(この先で詳述)において、日本語を表すコードにJIS X0201片仮名 とJIS X0208の混在を許すと、コード体系や、日本語文書を扱うソフトウェアの 仕様・実現などが非常に汚くなるため、JIS X0201片仮名は、文字コード規格を きちんと理解している人の間では嫌われる傾向にあります。 3. 文字コードの拡張法 ASCII文字やJISローマ字(JIS X0201)、日本語漢字(JIS X0208)のような文字セッ トを「図形文字セット」と言います(SPC, CR, ESC, DELなどは機能文字と言い、 「機能文字セット」と呼ばれるものが別に存在します)。これまではそれらのう ち、同時には1つしか使わないとして話を進めてきました。しかし実際には、複 数の文字セットを混ぜて使う必要が多く起こります。その場合、1つ問題が発生 します。 例えば、ASCII文字の「0$」という2文字の次にJIS X0208の「阿」が来るよう な文字列は、文字コードで表すとこうなります。 コード 3/0 2/4 3/0 2/4 文字 0 $ 阿 これでは、3/0 2/4という2バイトがASCII文字の「0$」という2文字なのか、JIS X0208の「阿」という漢字なのか、コードの上では区別がつきません。 そこで、このような区別ができるようにするため、特殊なコード列をはさむこ とによって、「ここから先はこの文字セットの文字」という宣言を行ってやりま す。これによって、複数の文字セットを混在して使うことが可能になります。こ の混在のさせ方は、やはり国際規格で、情報交換用符号の拡張法(ISO 2022、そ れの日本語訳がJIS X0202)として定められています。 3.1 7単位符号の拡張法 ISO 2022には、符号の拡張法として「7単位符号の拡張方法」と「8単位符号の 拡張方法」が定められています。前者を先に説明します。 いくつかの図形文字セットの文字を混在して使うには、それらの図形文字セッ トをとっかえひっかえして使う必要があります。そのためには、「これからどの 図形文字セットを使うか」を指定しなければならないのですが、この指定は一般 的には2段構えになっています。 7 単 位 環 境 +------+ invoke | 図形 | +------------------->|文字表| | | | | +------+ | +------+ +------+ +------+ +------+ バッファ | G0 | | G1 | | G2 | | G3 | +------+ +------+ +------+ +------+ ^ | designate +------------------------------------------+ | +-----+ +------+ +--------+ +------+ +----------+ 図形文字 | | |ISO646| | JIS | | JIS | | JIS | セット |ASCII| | 英国 | | X0201 | | X0201| |X0208-1983| … | | | | |ローマ字| |片仮名| | 漢字 | +-----+ +------+ +--------+ +------+ +----------+ 3.1.1 バッファと「指示する」(designate) まず、使うべき図形文字セットを「取り出しておく」ための「バッファ」とい うものがあると考えます。バッファは4つあり、それぞれG0, G1, G2, G3と呼ば れています。ある図形文字セットを使おうとするときには、それを一旦4つのう ちいずれかのバッファに取り出します。これを「指示する」(designate)と言い ます。(ここでいうバッファや「指示する」とは概念的なものであり、計算機の 中のどこかにバッファに相当するメモリ領域があったり、「指示する」ことによっ て何かのデータがメモリに取り出されたりするわけではありません。) 指示を行うには次のような符号列(シーケンス)を使います。1/11(ASCIIコード の中に出てくる制御文字のESC)から始まっているため、よくこれらを「エスケー プシーケンス」と呼びます。 ある1バイト94領域の図形文字セットをG0に指示するには 1/11 2/8 F G1 〃 1/11 2/9 F G2 〃 1/11 2/10 F G3 〃 1/11 2/11 F ある多バイト94領域の図形文字セットをG0に指示するには 1/11 2/4 2/8 F (例外あり、後述) G1 〃 1/11 2/4 2/9 F G2 〃 1/11 2/4 2/10 F G3 〃 1/11 2/4 2/11 F ある1バイト96領域の図形文字セットをG0に指示するには 1/11 2/13 F (以下略) ここでFとは、(ASCIIコードで「F」を表す4/6ではなく)「終端文字」と呼ばれ るもので、図形文字セット毎に決まっています。抜粋しますと | 図形文字セット 終端文字 --------------+----------------------------------------- | ASCII 4/2 1バイト94領域 | ISO646英国 4/1 図形文字セット| ISO646スウェーデン名前文字 4/8 | JIS X0201ローマ字 4/10 | JIS X0201片仮名 4/9 --------------+----------------------------------------- | JIS X0208-1978 4/0 多バイト94領域| JIS X0208-1983 4/2 図形文字セット| JIS X0212-1990(補助漢字) 4/4 | 中国語漢字 4/1 | 朝鮮語Hangul/Hanja 4/3 のようになります。 さて、「1バイト94領域の図形文字セット」のような言い方をしましたが、こ れは「1文字を表すのに1バイトを使い、文字セット全体で94個の領域を使う図形 文字セットということです(本稿で便宜上使っている語であり、正式な用語では ありません)。例えばASCIIは(機能文字セットが占めている部分を除くと)94個の 領域を使っていますから「1バイト94領域の図形文字セット」の1つです。JIS X0201ローマ字もそうです。JIS X0201片仮名は63個の領域しか使っていませんが、 この仲間に入れます。一方、JIS X0208は94領域を使いますが、2バイトで1文字 を表すので「多バイト94領域の図形文字セット」となります。なお、本稿では96 領域の図形文字セットについては述べません。 そこで、例えばJIS X0201ローマ字をG0に指示するには1/11 2/8 4/10という符 号列を使うわけです。ASCIIの対応する文字で表記すれば、「ESC ( J」となりま す。JIS X0208-1983をG0に指示するには1/11 2/4 2/8 4/2、と言いたいところで すが、歴史的事情から「終端文字が4/0〜4/2の時だけ、1/11 2/4 2/8 Fの代わり に1/11 2/4 Fを使う」という例外があるため、1/11 2/4 4/2(対応するASCII文字 で表示すると「ESC $ B」)となります。 ちなみに、別な図形文字セットをバッファに取り出すと、そのバッファにそれ まであったものは無効になります。 3.1.2 図形文字表と「呼び出す」(invoke) 次に、バッファのいずれかの図形文字セットを、7単位環境の「図形文字表」 というものへ持ち込むことによって、その文字セットの文字が使えるようになり ます。この操作を「呼び出す」(invoke)といい、以下のシーケンスによって行い ます。 バッファG0から7単位の図形文字表に呼び出すには 0/15 (SI・shift in) 〃 G1 〃 0/14 (SO・shift out) 〃 G2 〃 1/11 6/14 〃 G3 〃 1/11 6/15 そこで、例えば 1/11 2/8 4/10 1/11 2/9 4/9 0/15 4/1 4/2 4/3 0/14 3/1 3/2 3/3 というシーケンスは、JISローマ字の「ABC」の後にJIS 1バイト片仮名の「アイ ウ」がつながった文字列を表すことになります。このように、「1/11 2/8 4/10」 でJISローマ字をG0に、「1/11 2/9 4/9」でJIS 1バイト片仮名をG1に指示してお けば、SI・SOコードで両者を切り換えながら使えることになります。 以上で説明した拡張法では、1バイトのうち最上位ビットの立った符号は使わ れず、下位7ビットだけが使われます。そこでこれを「7単位符号の拡張法」と呼 ぶわけです。 3.2 8単位符号の拡張法 8単位符号の拡張法と言われるものも、7単位のものとほぼ同様ですが、図形文 字表が「左」と「右」の2つある点が異なります。 8 単 位 環 境 +--------+ +--------+ | 図形 | | 図形 | |文字表左| |文字表右| |(GL領域)| |(GR領域)| +--------+ +--------+ ^ invoke | +-------------+ | +------+ +------+ +------+ +------+ バッファ | G0 | | G1 | | G2 | | G3 | +------+ +------+ +------+ +------+ ^ | designate +------------------------------------------+ | +-----+ +------+ +--------+ +------+ +----------+ 図形文字 | | |ISO646| | JIS | | JIS | | JIS | セット |ASCII| | 英国 | | X0201 | | X0201| |X0208-1983| … | | | | |ローマ字| |片仮名| | 漢字 | +-----+ +------+ +--------+ +------+ +----------+ 指示するためのシーケンスは7単位の場合と同じです。呼び出すための符号列 は次のようになります。 どれかのバッファから左の図形文字表に呼び出すには 7単位の場合と同じ バッファG1から 右の図形文字表に呼び出すには 1/11 7/14 〃 G2 〃 1/11 7/13 〃 G3 〃 1/11 7/12 (歴史的理由で、バッファG0から右の図形文字表に呼び出すことはできない) このとき、左の図形文字表に呼び出された文字を使うにはそのままの符号を使 用しますが、右の図形文字表に呼び出された文字を使うには、最上位ビットを1 に変えて表します。例えば 1/11 2/8 4/10 1/11 2/4 2/9 4/2 0/15 1/11 7/14 というシーケンスによって、JISローマ字をG0に、JIS漢字をG1に指示しておき、 G0から左の、G1から右の図形文字表に呼び出しておけば 3/0 2/4 11/0 10/4 という符号列は「0$阿」という文字列を表すことになります。11/0 10/4は、3/0 2/4という2バイトのそれぞれ最上位ビットを1にしたものであるため、右の図形 文字表に呼び出されている文字セット、すなわちJIS漢字を表すことになるから です。また、G1にJIS漢字ではなくJIS 1バイト仮名を指示しておけば 3/0 2/4 11/1 11/2 は「0$」の次にJIS 1バイト仮名の「アイ」が続く文字列を表します。 1バイト中の8つのビット全てを使って拡張するため、これを「8単位符号の拡 張法」と呼びます。また、この拡張法では、8/0〜9/15の領域も(0/0〜1/15とは 別の)機能文字として使われます。 SS2(8/14)およびSS3(8/15)という機能文字を使うと、その次の1文字分だけ、 右の図形文字表にG2やG3から呼び出すことができます。例えば、上述した、JIS ローマ字をG0に、JIS漢字をG1に指示する例において、さらに「1/11 2/10 4/9」 でJIS 1バイト片仮名をG2に指示しておけば 3/0 2/4 8/14 11/1 11/0 10/4 という符号列は、JISローマ字の「0$」の次にJIS 1バイト片仮名の「ア」、続い て漢字の「阿」が続く文字列を表すことになります。 3.3 アナウンサとその省略 ここまでに説明したように、ある図形文字セットの文字を使うには、まずその 図形文字セットをバッファに指示し、次にそれを図形文字表に呼び出して使う、 というのが正式です。しかし、それが面倒だという場合には、特定のバッファを 図形文字表に直結しておき、指示しただけで自動的に呼び出されて即使えるよう にする手段も用意されています。 そのためには、使う前に「アナウンサ」という符号列を送ります。例えば1/11 2/0 4/1というアナウンサを送ると、「バッファはG0しか使わない。そのかわり、 G0へ指示したものはすぐ図形文字表へ呼び出す。但し8単位環境の場合は(2つあ るうちの)左の図形文字表へ呼び出す」という意味になります。 しかし、情報交換当事者間の合意があればアナウンサさえも省略してよいこと になっています。例えば「常に1/11 2/0 4/1のアナウンサが先行していることに し、そのアナウンサを省略する」旨当事者間で取り決めておけば、 3/0 2/4 1/11 2/4 4/2 3/0 2/4 という符号列は「$0阿」という文字列を表すことになります(但し、ここにはも う一つ、「何もしなければ最初はG0にはASCII文字セットが指示されているもの とする」という暗黙の前提があることになります)。 本稿ではアナウンサについては詳述しません。 3.4 機能文字セット 先述したように、機能文字の文字セットは英数文字や漢字などの図形文字セッ トとは別に存在します。切り換えの方法も異なるので、図形文字セットのほうを 切り換えながら使っていても、機能文字のほうは影響を受けません。例えばTAB, ESC, CRやLF(改行)などの文字は、図形文字として現在何を使っているかに関わ らず使えるわけです。例えば、(「1/11 2/0 4/1」のアナウンサが先行している として) 1/11 2/4 4/2 3/0 2/1 0/10 3/0 2/4 という符号列は「亜」(3/0 2/1)のあとにLF(改行)、続いて「阿」という文字列 を表すことになります。改行を入れるためには、一旦G0に漢字ではなくASCII文 字を指示しておかなければならない、などということは一切ありません。 本稿では機能文字セットについても詳述しません。 4. よく使われる日本語コード これまで述べてきた文字コードの拡張法は全体としてはかなり複雑なので、現 実にはその一部分(サブセット)だけを使って文字コードの拡張を行う場合がほと んどです。サブセットといってもちゃんと規格に準拠していることには変わりな いので、これらは国際的に通用する拡張法といえます。日本語の場合、このサブ セットによる拡張法でよく使われているものには、JUNETコード(「いわゆるJIS コード」)と日本語EUCがあります。また、広く使われるようになったXウィンド ウシステムの最近の版では、国際化に対応するため、Compound Textという、や はりサブセットの拡張法を使っています。 4.1 JUNETコード この拡張法は、一般には「JISコード」あるいは「7ビットJIS」と呼ばれたり していますが、ISO 2022のサブセットであり、これをJISで定められている文字 規格全体と区別する必要がある場合には「JUNETコード」の名があります。その 由来は、コンピュータ・ネットワークの「JUNET」で、日本語を含む電子メール や電子ニュースのやり取りに使われてきた実績があるためです。今ではこのコー ドは、インターネットなどのネットワークで日本語のメッセージをやり取りする 際の標準となり、電子ニュースfjでも特別なニュースグループを除きこのコード を使う約束になっています。また、現在ではこの拡張法は規格文書の「RFC1468」 に記載されて、「ISO-2022-JP」という公式名をもらっており、これらの番号で 呼ばれることもあります。 このコードでは7単位の拡張法を用います。また、常に「1/11 2/0 4/1」とい うアナウンサが先行しているものと考え、情報交換当事者間の合意があったもの としてそれを略します。(さらに、暗黙の初期状態として、最初G0にはASCIIが指 示されているとします。) そして、次の4つの文字セットを、G0に指示すること によって切り換えながら使います(個人的なメールや、ローカルな電子ニュース などでは、関係者の合意の上で、1/11 2/8 4/9でJIS 1バイト片仮名を使うとか、 他の文字セットを使うこともあります)。 文字セット |G0に指示するための符号列|対応するASCII文字で表すと -------------------+------------------------+------------------------- ASCII | 1/11 2/8 4/2 | ESC ( B JISローマ字 | 1/11 2/8 4/10 | ESC ( J JIS漢字旧版 | 1/11 2/4 4/0 | ESC $ @ JIS漢字新版 | 1/11 2/4 4/2 | ESC $ B 例えば 3/0 2/4 1/11 2/4 4/2 3/0 2/4 0/10 3/0 2/1 という符号列は「0$阿」+改行+「亜」という文字列を表します。先述したように、 改行を挟むために一旦ASCIIに切り換える必要はないことに注意して下さい(実際 にはfj電子ニュースなどでは、種々の理由から、改行は一旦ASCIIかJISローマ字 を指示してから行う、などの取り決めが加えられています)。また、 1/11 2/4 4/0 4/15 3/6 1/11 2/4 4/2 4/15 3/6 1/11 2/8 4/2 5/12 1/11 2/8 4/10 5/12 という符号列は、(4/15 3/6という符号列がJIS漢字旧版で「篭」「籠」の簡単な 方を表し、新版では難しいほうを表すため)「『篭』『籠』の簡単な方」+「『篭』 『籠』の難しい方」+ASCIIの「＼」(バックスラッシュ)+JISローマ字の「￥」と いう文字列を表します。 JUNETコードの変形として、JIS 1バイト片仮名だけはあらかじめG1に指示され ている(そのためのシーケンスは省略)と考え、それを使いたい場合はSOコードで 呼び出し、終わればSIコードで再度他の文字セットをG0から呼び出す、というや り方も考えられます。この方式では 1/11 2/4 4/2 3/0 2/4 0/14 3/1 1/11 2/8 4/10 3/2 0/15 3/0 0/14 3/3 1/11 2/4 4/2 3/4 0/15 3/0 2/1 は「阿」+JIS 1バイト仮名の「アイ」+「0」+JIS 1バイト仮名の「ウエ」+「亜」 という文字列を表します。途中で、JISローマ字や漢字をG0に指示しただけでは まだ、図形文字表には1バイト仮名が呼び出されたままであり、G0から図形文字 表に呼び出して初めて、2/1〜7/14の符号がJISローマ字や漢字を表すように変わ る点に注意して下さい。 この方式はJUNETコードの一部にはなっておらず、fj電子ニュースなどでも使 われていませんが、1バイト仮名を混在する場合にまれに使われるようです。例 えば、sseというUNIX上のフリーソフトのエディタは、この方法を使うそうです。 JUNETコードの長所の1つは、(後述するEUCコードと異なり)英語と日本語を混 在させるだけではなく、必要ならその他の言語も(対応する指示シーケンスを使っ て)一度に混在させうるということです。また、1バイトのうちの下位7ビットし か使わないため、情報交換の際に最上位ビットを落としてしまうような多くのネッ トワークにおいても、正常に情報を交換できることも利点であり、昔からJUNET においてこのコードがメールやニュースの交換に一般的に用いられてきたのも、 それが1つの大きな理由です。 一方、短所の1つは、符号列の中のある1バイトだけを取り出したとき、それが 1バイト文字なのか、2バイト文字の一部なのか区別が付かないということです。 このために、1バイト英数文字と日本語文字の混じった文書を処理するようなソ フトウェアが作りにくくなってしまいます。 4.2 日本語EUCコード 日本でただ単に「EUCコード」というとこの日本語EUCのことを指すことが多い ようですが、厳密にはEUCコードとは、ASCII文字と他のどれか1つの言語の文字 を混在できる拡張法であり、「中国語EUC」「韓国語EUC」などがあります。そし て、日本語EUCコードもその一種です。(日本語EUCのことを「UJIS」と俗称する ことがありますが、これは通産省主導で一時期進められ結局ポシャった「Σプロ ジェクト」でそう呼んでいたことに由来します。) EUCもやはりISO 2022のサブセットで、8単位の拡張法を用います。そして、G0 〜G3の各バッファにあらかじめ4つの文字セットが指示されているものと仮定し、 指示するシーケンスは一切省略します。4バッファのうち、G0に指示されるもの は常にASCIIと決められており、残り3つは各国語によって異なります。日本語の 場合は G1 JIS漢字 G2 JIS 1バイト仮名 G3 JIS X0212補助漢字 です。そして(ここからは各国語に共通)、左の図形文字表には常にG0、右の図形 文字表には常にG1が呼び出されているとし、呼び出すシーケンスも一切省略しま す。G2やG3の文字セットを使いたければ、SS2やSS3を使って一文字だけ右の図形 文字表に呼び出す手法を使います。 従って、EUCではエスケープシーケンスは一切使いません。そして日本語EUCの 場合、ASCII文字はそのまま、JIS漢字は2バイトのそれぞれの最上位ビットを1に 変えたもので表し、1バイト仮名は最上位ビットを1にした上で前に8/14を付けて 表すことになります。例えば 3/0 2/4 11/0 10/4 8/14 11/1 は「0$阿」の次に1バイト仮名の「ア」がついた文字列を表します。 EUCの長所は、JUNETコードとは逆に、文字列の中のある1バイトを見れば、そ れが1バイト文字か2バイト文字の一部か判別が付くため、1バイト英数文字と日 本語文字の混じった文書を処理するようなソフトウェアも作りやすい点です。こ のため、UNIXの日本語化には日本語EUCがよく使われてきました。(EUCという語は Extended UNIX Code、「拡張UNIXコード」から来ています。またこのため、EUC を、UNIXの開発元の名を取って「AT&Tコード」と別称することもまれにあるよう です。) また、エスケープシーケンスが不要なので、英語と日本語が混じるよう な文書を計算機内にファイルとして保存しておく場合、ファイルの容量が小さく てすみます。 一方短所は、JUNETコードのようなやり方と異なり、ASCII文字とせいぜい一ヶ 国語との混在しかできないことです。例えば、ASCII文字とJIS漢字と中国語漢字 の混ざった文書をEUCで表現することができないのです。このため、「図書館の 蔵書管理システム」(蔵書の題名は3ヶ国語以上ありうる)のように、多国語を混 在させる必要がある応用には向きません。 4.3 Compound Text Compound Textもやはり8単位の拡張法を用います。バッファはG0, G1だけを使 い、左の図形文字表には常にG0、右の図形文字表には常にG1が呼び出されている とします。呼び出しのシーケンスは一切使わず、EUCのようなSS2, SS3による拡 張も使いません。そしてG0, G1に必要に応じて図形文字セットを指示しながら使 います。G0とG1のどちらか一方にしか指示できないことになっている文字セット と、どちらにも指示できる文字セットがあります。 |図形文字セット | 指示するシーケンス ----------------+---------------+---------------------- G0にしか指示でき|ASCII |1/11 2/8 4/2 ないものの例 |JISローマ字 |1/11 2/8 4/10 ----------------+---------------+---------------------- G1にしか指示でき|JIS 1バイト仮名|1/11 2/9 4/9 ないものの例 |ギリシャ文字 |1/11 2/13 4/6 ----------------+---------------+---------------------- どちらにも指示 |JIS漢字 |G0には1/11 2/4 2/8 4/2 できるものの例 | |G1には1/11 2/4 2/9 4/2 |中国語漢字 |G0には1/11 2/4 2/8 4/1 | |G1には1/11 2/4 2/9 4/1 |朝鮮語Hangul |G0には1/11 2/4 2/8 4/3 | /Hanja|G1には1/11 2/4 2/9 4/3 EUCと異なり、何ヶ国語でも混在が可能です。そこでXウィンドウシステムでは、 クライアント(Xウィンドウシステムのもとで動くプログラム)同士でのデータの 受け渡しを、一旦Compound Textに変換することによって行います。こうすれば、 個々のクライアントが内部でどのような文字コードを使っていても、矛盾なくデー タの受け渡しができるからです。 なお、先に述べたように、規格では「終端文字が4/0〜4/2の時だけ、1/11 2/4 2/8 Fの代わりに1/11 2/4 Fを使う」としているのですが、Compound Textは終端 文字が4/0〜4/2であっても1/11 2/4 2/8 Fを使っているので、厳密にはこの点で わずかに規格を逸脱していると言えます。 5. 国際規格に基づかない文字コード 残念ながら現実には、以上説明したような国際規格に基づいた(つまり国際的 に通用する)文字コードでないものが、あちこちで使われています。 例えば、アルファベットの表し方はASCIIに準じているものの、漢字を扱うた めの拡張法が国際規格に基づいていないものがあります。代表的なものは、MS漢 字コード(いわゆる「シフトJIS」)と、(現在では比較的マイナーになりましたが) いわゆる「NEC漢字コード」と呼ばれるものでしょう。また、そもそもアルファ ベットの表し方からしてASCIIと異なるコードもあります。その代表例がEBCDIC と呼ばれるものです。 5.1 MS漢字コード 現在、パソコンで使われているオペレーティング・システムの代表的なものが、 Microsoft社で開発されたMS-DOSですが、これはそもそも米国で開発されたもの なので、開発の時点では日本語の使用は念頭に置かれていませんでした。その後、 日本向けのパソコンにもMS-DOSを導入することになって、MS-DOSを、日本語文字 を扱えるように拡張する必要が出てきました。その際、日本語文字を表すコード としてMicrosoft社が(勝手に)作り、採用したのがこのMS漢字コードです。 このコードでは漢字は、JIS X0208による2バイト表現をある簡単な計算式によっ て変換したもので表します。このため、JISを変換(シフト)したコードであるこ とから俗に「シフトJIS」と呼ばれるのですが、JIS規格に定められた文字コード ではありません。従って、文字コード規格をきちんと理解している人の間ではもっ ぱら嫌われものになっています。 このコードではJIS 1バイト仮名を、最上位ビットを1にした10/1から13/15ま でのコードで表します。漢字を扱えなかったそれまでのパソコンが、仮名を含む 全ての文字を1バイトで表しており、10/1〜13/15の領域に仮名を割り当てていた ため、その過去を引きずってそう決めたようです。そのため、漢字を表す2バイ トのうち1バイト目は、仮名やASCII文字と区別するために、8/1から9/15までと 14/0から15/10までの領域に(無理やり)収めます。ちなみにこのうち、JIS X0208 で定義されている漢字を表すのは、1バイト目が8/1〜9/15と14/0〜14/15の範囲 内の場合に限られており、残りの15/0〜15/10は、このコードで勝手に拡張した 部分です。マシン毎に定義する「外字」を入れるための領域だそうなので、この 部分のコードを使ってもマシン間の互換性は一切ないことになります。 このような決め方のため、いろいろな歪みを生んでいます。例えば、国際規格 では本来、8/0から9/15までは制御文字用の領域なのですが、このコードではこ こにも勝手に図形文字を割り当ててしまっています。さらに、JIS X0212で新た に定められた補助漢字をMS漢字コードで表すことは、もうこれ以上拡張の余地が ないために不可能になってしまいました。 もう一つ問題となるのは、漢字の1バイト目こそ仮名やASCIIと重ならないよう に決めてありますが、2バイト目は4/0から15/12まで(7/15を除く)を使うため、 ASCIIや仮名と重なってしまう点です。特に、UNIXをはじめ様々なソフトで特殊 文字としてよく使われたり、MS-DOSでファイル名のパスの区切りに使われたりす る「\」記号がこの範囲にもろに入ってしまうため、日本語を扱うソフトを作る 際にやっかいな障害となります。 いずれにせよ、このコードは一企業が勝手に決めた漢字コードです。これを使 わざるを得ないMS-DOS上ならともかく、ワークステーション上などのように、 JUNETコードや日本語EUCが代わりに使える状況においては、使わないべきでしょ う。 5.2 NEC漢字コード NECが作った漢字コードで、MS-DOSの普及まではパソコン上の標準言語だった BASICの上で漢字を扱うために作られました。一企業が勝手に決めた漢字コード であるという点ではMS漢字コードと事情が似ています。 このコードでは、1/11 4/11(ESC K)という符号列があるとそこから先がJIS漢 字となり、1/11 4/8(ESC H)があるとそこからが1バイト文字に戻ります。そして、 1バイト文字のうち0/0〜7/15まではJISローマ字と同じですが、8/0〜15/15の部 分には罫線文字やトランプのスーツのマークなど、それまでのパソコンで多用さ れていた文字(仮名を除いて国際的文字規格には依存していません)を受け継いで います。エスケープシーケンスで漢字と1バイト文字を切り換える点がJUNETコー ドに似ているため、「NEC JIS」とも俗称されたりしますが、JISに規定された拡 張法ではありません。 幸いにも、BASICが廃れてきたのに合わせて、このコードも廃れてきたようで す。 5.3 EBCDICコード このコードは主に、大型計算機上の時代遅れのオペレーティング・システムな どで多用されています。もともとIBM社が、自社の大型計算機で使うために制定 したものですが、それと互換性を取った他社の大型機でも、これと同じあるいは 準じたコードが使われるようになりました。しかし、もっぱら計算機内に文字デー タを格納するときにだけ使われ、計算機どうしの情報交換にはさすがに国際規格 のコードを使うことが多いようです(かな? 筆者は寡聞にしてよく知りません)。 EBCDICの文字コード割り当ては、例えばA〜Zのコードが(ASCIIで連続になって いるのと違って)飛び飛びになっていたりして、非常に使いにくいものになって います。また日本のメーカーではEBCDICを拡張して、1バイト仮名や2バイトの漢 字も割り当てたのですが、漢字の表し方が会社間で全く統一性がなかったり、あ るいは同じ会社のもの同士でも、1バイト仮名を入れて「拡張」したものが実は 拡張前のものの上位互換ではなかったり、などいろいろ奇怪な現象が起きていま す。とにかく、一度見れば一生使いたくなくなるコードです。 5.4 UNICODE 文字コードの国際化のもう一つの方法として、現行のISO規格と全く別個に作 られ、新しい国際規格の候補として提案されているものに、UNICODEなるものが あります。世界中の全ての文字を2バイトで表そうというものです(4バイトとい う話を聞いたこともあるような気がする。でも4バイトだと後述の「65536通り」 という話と矛盾するし…UNICODEのことははっきり言ってよくわかりません)。 しかし、従来使われてきた文字コードとは全く互換性がありません。また、2 バイトでは65536通りの符号が表せますが、漢字などの文字種の多い文字を入れ て考えると、世界中の文字全部を収めるには不十分なため、例えば日本語と中国 語の漢字で、形が「似ている」ものを強引に一つにしてしまう(そのくせギリシ ャ文字のΑと英語のＡは区別するそうな)など、文化的に見ても問題の多いコー ドと言われています。さらに、最近はそれでも65536通りには収まらないという ことになって、現ISO規格と同じような(?)文字コードの拡張法を導入するという 話が出ているそうなので、これによって、「1文字あたりのバイト数が一定なの で文字データの取り扱いが簡単」という、数少ない利点まで失われようとしてい ます。 6. さまざまな誤解 国際規格に対する誤った理解も、残念ながらやはり広く流布しています。その 代表的と思われるものをここに挙げてみました。 6.1 漢字インと漢字アウト? もっとも代表的な誤解はやはり、「ESC $ Bが漢字イン(略してKI)で、ESC ( J が漢字アウト(略してKO)だ」というものでしょう(1/11 2/4 4/2などと書く方が、 ASCII文字セットに依存しない議論ができるので厳密なのですが、ここでは俗な 理解に合わせてASCII文字で表記することにします)。 これまでに説明したように、エスケープシーケンスによる文字セットの切り換 えは常に、「ここからはどの文字セット」というようなものであり、いわばGOTO です。「漢字」という状態があって、ESC $ Bでそこへ入り、ESC ( Jでそこから 抜けるというような、一種のサブルーチン的な考え方は正しくないのです。 それでも「ESC $ Bで英数から漢字へ移行し、ESC ( Jで漢字から英数に移行す るのだから、便宜的に漢字イン・アウトのような捉え方をしたほうが理解しやす いのではないか」と思うかも知れません。しかし、JUNETコードの説明のところ で出した例を見れば分かりますが、符号列の中にESC $ Bがあってもそれは「非 漢字状態」から「漢字状態」への移行とは限りません。実際、そこの例の2番目 ではJIS漢字旧版から同新版への移行にESC $ Bを使っていますから、ESC $ Bよ り前も、2/1〜7/14の符号は「漢字」を表している状態です。3番目の例に至って は、ESC $ Bの直後も漢字ではなく1バイト仮名が選択されている状態です(これ は、JUNETコードのようにG0以外のバッファを使わないやり方なら起こりません が)。ESC ( Jも同様に、「漢字状態」から「非漢字状態」への移行とは限りませ ん。「漢字イン・アウト」という捉え方ではこれらのことが理解不能になります。 このように、「ESC $ Bが漢字インでESC ( Jが漢字アウト」という考え方は、 「明白な間違い」であるだけでなく「有害な間違い」でもあるのです。 (「漢字イン・アウト」という言い方が根強く残っており、そう言わないと理 解されにくいような文化圏が存在する、という議論もあります。しかし、そのよ うな文化圏でも、やはりかつては誤用が一般的だった「PDS」という言葉につい て、最近正しい使用が叫ばれるようになったという実績もあります。必要な注意 を払えば、言葉の誤用は正していくことが可能なのではないでしょうか。) 6.2 JISの新旧と「ESC ( H」 「JISの新版ではESC $ Bが漢字インでESC ( Jが漢字アウト、旧版では ESC $ @が漢字インでESC ( Hが漢字アウト」というのもよく見る間違いです。「漢字イ ン・アウト」という捉え方が不適切であることは既に述べましたが、それ以外に もここには2つの誤解があります。 まず、ESC $ BがJIS漢字新版のG0への指示、ESC $ @が同旧版のG0への指示、 というのは本当です。しかし、JISローマ字のG0への指示シーケンスはESC ( Jが あるだけで、新版も旧版もありません。これが誤解の1つ。(ついでながら、ESC $ BとESC $ @を混ぜて使えることも、JUNETコードの説明のところに出てきた通 りです。) ではESC ( Hとは何か。3.1.1の表で終端文字が4/8(ASCIIでH)になっているの が「ISO646スウェーデン名前文字」(以下「スウェーデン名前文字」と呼びます) という文字セットであることからもわかるように、これは「スウェーデン名前文 字」をG0に指示するものです。JISとは何の関係もありません。しかし、一時期 これが誤ってよく用いられました。 その理由は、JIS X0201の仮名とローマ字を指示するシーケンスのF(終端文字) を国際規格で割り当ててもらうべく登録手続きをしていた当時、「終端文字はそ れぞれGとHになりそうだ」と予想して、JISの規格記述にそう書いてしまったこ とに端を発します。実際には、その頃同じく登録手続き中だった「スウェーデン 基本文字」と「スウェーデン名前文字」がGとHを取ってしまい、JISの仮名とロー マ字はIとJになってしまいました。あわてて正誤表を発行したのですが、徹底せ ず、当初は「JISローマ字をG0に指示するにはESC ( H」という誤解が広まってし まいました。 幸いにもJUNETでは、7年以上も前にこの誤解が指摘され、このシーケンスを使 う人はかなり減りました。しかし、規格をよく理解していない人の間ではこの誤 りが今でも尾を引きずっているのです。これが、2つ目の誤解です。 ちなみに「スウェーデン名前文字」は、2/4が「$」ではなく太陽マークと呼ば れる通貨記号であるなど、11個の領域でJISローマ字と異なっています。 ところで、インターネットの電子メールやfj電子ニュースなどでは、ESC ( H ではなくESC ( Bが、ESC ( Jと並んで、もう一つの「英数文字をG0に指示するシ ーケンス」として多用されています。これがまた、国際規格を知らない人に多々 誤解されているようです。中にはこのシーケンスがJISに記述されていないこと から、「ESC ( Bというのは規格の誤解」としている文献(本稿の冒頭に述べた、 WTERMのドキュメント1993年6月20日版がまさにそれです)もあり、とんだお笑い です。しかもそういう文献に限って「JIS旧版では漢字アウトはESC ( H」などと あるのです。書いている本人こそ誤解している(「漢字アウト」、1バイト英数へ の移行の「旧版」、「ESC ( H」と3重もの誤解)! むろんこれは、ASCII文字をG0に指示するシーケンスです。米国用の文字セッ トだからJIS規格には載っているはずがありませんが、もちろんちゃんとISO 2022に準拠したシーケンスです。 6.3 全角・半角? ISOやJISの規格では、どの符号がどの文字を表すかということを決めてあるだ けです。どの文字がどんな字形か、どれくらいの幅を持つか、などといったこと は、実はそれらの規格にはどこにも規定してありません。 だから、実際にコンピュータのディスプレイに表示するときに、例えばASCII 文字を一定の幅で表示しようがばらばらの幅で表示しようが、または斜体やイタ リックで表示しようが、規格には反しない、というより規格には関係ないことな のです。実際、最近では、場合によってはASCII文字をプロポーショナル(字幅ば らばら)で表示するようなシステムも出始めています。同様に、JIS 1バイト仮名 を漢字の半分の幅で表示しようが同じ幅で表示しようが、規格には無関係です。 しかし現実の多くの端末では、ASCIIやJISローマ字、JIS 1バイト仮名は全て 同じ幅で表示され、JIS漢字はまた全て同じ幅であって、後者は前者の倍の幅、 というようになっています。このため、前者を「半角文字」、後者を「全角文字」 と呼ぶことも実際問題としては多々あります。 けれども、ある文字が全角か半角かは、その文字を表示したり印刷したりした 時点ではじめて生じる概念であり、あくまでISOやJISの規格とは関係ない話です。 例えば、あなたの端末で「A」という文字が「Ａ」という文字の半分の幅で表示 されているなら、前者は半角文字、後者は全角文字、というのは(多分)正しいで しょう。しかし、日本語EUCコードで「4/1」が半角文字、「10/3 12/1」が全角 文字だというのは誤解です。たとえあなたの端末が、「4/1」に対し半角の「A」 を、「10/3 12/1」に対し全角の「Ａ」を表示していようと、それはあなたの端 末がそうしているというに過ぎません。(「4/1」が1バイト文字であり、「10/3 12/1」が2バイト文字である、という文章なら正しいです。当然ですね。) とはいえ、文字コードに関する完全な理解を前提とせずに説明用の文書を書く 場合は、不正確な用語であることを承知の上で、「いわゆる」全角文字、とか 「いわゆる」半角文字、とか書く人もいるようです。実際筆者もこの書き方をす ることが時にありますが、最近では不正確な用語であることを断った上で行うよ うにしています。 6.4 独自拡張文字 文字コード規格の誤解という話からはちょっと外れますが、JIS X0208におい て2バイトの組み合わせのうち文字を割り当てられていない領域に対して、ソフ トウェアやマシンによっては勝手な拡張を行っています。これも、往々にしてス ムーズな情報交換を妨げる原因となっています。 代表的なものは、NECのパソコンの独自文字でしょう。例えば2/13 2/1は、JIS X0208では文字を割り当てていませんが、NEC製のパソコンはここに勝手に「丸1」 (1を丸印で囲んだもの)という文字を新しく作って割り当てています。困ったこ とにこの文字が、NECのパソコンで作った文書のファイルにはよく登場するので す。しかし、むろんNECの勝手な拡張ですから、その文書を他社のマシン(わざと NECと互換性を確保しているEPSONなどの機種を除く)に持って行って読もうとし ても、「丸1」のところは文字が見えません。かくして、正常な情報交換は阻害 されてしまうのです。2/12 2/4などの領域にやはりNECが勝手に割り当てている 罫線文字も、同様な問題をよく引き起こしています(ちなみにJIS漢字の新版では、 2/8 2/1以降の領域に罫線文字を割り当てています)。 自分のパソコンだけで使うデータや文書にならともかく、他システムとの情報 交換に使う場合には、そのようなコードは使わないべきです。 ちなみに、あるマシンで作成した文書の中の文字が、別なシステムでは見えな い、といったことは他の原因でも起こることがあります。よくあるのは、JIS漢 字の新版と旧版の違いに絡むものです。例えばMS漢字コードの9/8 5/5, 8/4 9/15という2文字は、JIS X0208ではそれぞれ4/15 3/6, 2/8 2/1に当たりますが、 JIS漢字の新版では前者は「篭」「籠」の難しい方、後者は横の細い罫線文字を 表すのに対し、旧版では前者は「篭」「籠」の簡単な方、後者は文字が割り当て られていません。このため、例えば「篭」を含むような人名が文書の中に出てく る場合、あるマシンでは正しく表示されるのに、別なマシンでは間違った字が表 示されるとか、あるマシンでは罫線文字が見えるのに別なマシンでは見えない、 などの現象が起こります。 また、かつてよく見られたのは、「第二水準」の漢字がマシンによっては表示 できないという現象です。JIS X0208で定義されている漢字は「第一水準」と「 第二水準」に分かれており、ハードの制約などから後者を表示できないマシンが 昔はよく見られたため、JUNETなどでは「固有名詞などでやむを得ない場合以外 は、できるだけ第二水準の漢字を使わないようにしよう」などと言われていまし た。しかし、第二水準漢字を表示できないマシンが減ったため、最近ではそんな ことを気にする必要は薄れてきています。 いずれにせよ、情報交換にあたって重要なのは、受け取り手がきちんと情報を 受け取れるかどうかです。相手の環境で困らずに読めることを常に考え、自分の システムだけとか特定の環境だけで通用するような、独り善がりなコードは使わ ないようにしていくべきでしょう。 7. 参考文献 1) 「JISの解説とJUNETへの提案」、小川貴英(解説部分は和田英一)、JUNET電 子ニュースfj.kanjiの記事、1986 2) 「UNIXの日本語処理がわかる本 最新Wnn活用ガイド」、よしだともこ、日 刊工業新聞社、1993 3) RFC1468、J. Murai・M. Crispin・E. van der Poel、fj電子ニュースfj. questions.unixに佐藤裕さんによって掲載されたもの、1993 しかし、最善の参考文献は、何といってもJISやISOの規格の本文を直接読むこ とでしょう。(なお、JIS規格の一部は「JISハンドブック」で読むことができま すが、ハンドブックは必ずしもすべての規格を採録しているわけではなく、また、 採録している規格についても付属文書は省略していることがよくあります。さら に、規格が改正されてからハンドブックの記述が変更されるまでの時間的ずれも あります。従って、ソフトウェアの作成に関してJIS規格を調査する必要がある 時は、「JISハンドブック」ではなく「JIS規格票」を参照することをお勧めしま す。) この文書の改善について、以下の方々の意見や指摘を参考にさせて頂きました。 お礼申し上げます。(肩書きは参考となる意見を提示して下さった当時) 小山洋一さん@京都大学工学部 鵜飼文敏さん@京都大学大学院工学研究科 戸田 孝さん@滋賀県立琵琶湖博物館(準) 鴨 浩靖さん@奈良女子大学理学部(直上の「JISハンドブック」に関する 注意書きは鴨さんによります。) 服部隆志さん@京都大学数理解析研究所