対応するJIS規格が「情報交換符号の拡張法」と呼ばれているように、4.1節で挙げたような様々な文字集合をどのように組み合わせて使用するかを定めた規格である。(詳しくは規格本体を参照のこと。MuleのInfoに含まれているmule-jpのISO2022の項目も参考になると思う)。0208という3つの文字集合を組み合わせるためのエンコーディングを考えてみよう。2022の7単位符号系における利用例である。7単位符号系とは7ビットの組合せで文字を表現するものである。おけるエンコーディングの例となる。2022に基づくエンコーディングのひとつである。(これはかつて「JUNETコード」と呼ばれていたものとほぼ同じものである)。(ISO-2022-JPについての詳細は直接RFC-1468を参照して欲しい)。単なる文字集合ではない」と述べたが、その理由は、ISO-2022-JPはその中で使用される4つの文字集合に加えて、それらをどのようにエンコーディングするかを規定したものであり、単なる文字集合以上の意味を持っているという点にある。その定義から明らかなように、ISO-2022-JPは日本語と英語のみが使用可能なエンコーディングである。ISO-2022-JP-2で使用可能な文字集合の一覧を以下に示す。メーリング・リストなどで実際に使用されている。10646はひとつの文字集合で世界中の文字全てを表そうとするものである。2022のようなエンコーディングの技法は不要であるように思われる。2022の枠組みを使用することは出来ないことになっている。10646は単に文字の集合とその中の各文字に対応する符号を定めたものであり、かつ、その符号には今まで制御文字として使用されていたオクテットが含まれるているため、「これらの符号を従来の計算機あるいはネットワーク上で利用可能なビットパターンとして表現」するための「エンコーディング」の問題が依然として残ることになってしまった。Webなどの広域情報システムを例にして説明する。画像や音声などの非テキスト情報の表現などを可能にすることを目的とするものである。2つの規格から構成される。いう文字集合を用いて書かれている」ということを宣言するものである。高田敏弘という文字列を表現したものである。MIMEにおける非ASCII文字の取扱いの中心にある思想は、「そのテキストで使用されている文字集合を常に明確に宣言する」というものである。これは、裏返せば、MIMEには使用される文字集合を宣言するだけの能力しかないと言い換えることができ、メッセージの国際化に際しては、実際に「国際化された文字集合」が存在しない限り、MIMEの宣言はほとんど役に立たない。存在するが、これらが実際に使用されている例は筆者はまだ見たことがない。2022に基づくものに変更しようという提案もある。広域情報システムである。これらのアプリケーションでも、そこで取り扱われるテキストの国際化の問題が存在する。世界各国では、これらの広域情報システムで自国の言語や文字を取り扱うための試みが行なわれている。日本においてはISO-2022-JPが主として使用されている。電子メールなどとは若干状況が異なり、これらの広域情報システムではISO-2022-JPに対応したソフトウェアがまだ充分に整備されていないため、依然として日本語EUCやShift-JISも混在して使用されているのが現状である。詳しく書かれているのでそちらを参照して欲しい。ここで強調しておきたい点は、現時点ではWWWの国際化については「何も決まっていない」ということである。このような状況はGopherやWAISについても同様である。その他の問題点インターネットおける国際化に関しては、今まで挙げた他にもいくつかの問題点が存在する。ここではそれらの中から、言語情報をどのように表記するかという問題と、テキストの「双方向性」について触れることにする。電子メールや広域情報システムにおいて、同一内容の情報を複数の言語で記述したものが用意されている場合、ユーザがそれらの中から自分が希望する言語で書かれた情報を取り出したいといったケースがあり得るだろう。このような場合、ある文書が何語で書かれているかを表記する方法が必要になる。639で定められた2文字の名前で指定することを提案したものである。同一の名称を持つ言語でも使われる国の違いや方言によってそれらを区別する必要が生じることも予想される。このような場合は上記の言語名の後ろに副言語名を付け、それらを区別する。639で定義されていない言語名や副言語名を登録する方法も定められている。テキストの双方向性ヘブライ語やアラビア語などの右から左に書かれる言語の取扱いも、国際化においては欠くことのできないポイントである。混在した場合の取扱いである。このようなテキストは、左から右といった単一方向ではなく双方向の流れを持つため、与えられたテキストを表示する際にどのような順序で文字を表示するかを決める必要がある。(bi-directionality)」と呼ぶ。テキストの双方向性としては以下の3種類がある。Visual:与えられたテキスト・データを単に左から右に表示する。この場合、右から左に書かれるべきテキストについては、あらかじめ逆向きに書かれたデータを作成する必要がある。隣り合う文字との関係から決定される。定義されたコントロール・シーケンスを用いてテキストを表示する方向を指定する。(ヘブライ語用とアラビア語用のものがあるので、計6種類の文字集合が定義されている)。これは、本来なら文字集合情報のみを表すべき所に双方向性に関する情報を埋め込んでしまったという点で、あまり美しくない解決策であると言えるだろう。2022に基づくほとんど全てのエンコーディングを扱うことが可能であり、MULE上で電子メールやネットワーク・ニュースを読み書きするソフトウェア、あるいは、WWWのクライアントなどを動かすことにより、これらを国際化された環境下で利用することが可能になる。Systemがかなりの範囲で国際化をサポートしている。(具体的にはwide-characterとしてUCS-4を、multibyte-characterとしてUTF-8を使用している)。まとめ今まで述べてきたように、国際化については様々な問題が複雑に絡まっており、その決定的な解は未だに得られていない。10646を採用して国際化を行なうべきだという声が大きいことは事実である。10646自体の設計の不味さなどを指摘する人も多い。2022を用いて切り換えて使用する手法にもいくつかの問題がある。2022に基づく枠組みを使用する限り、その中でどのような種類の言語や文字が取り扱えるのかが文字集合の存在に制限される点にある。10646以外に存在しない言語が計79種列挙されている。2022の使いようがない。このような状況の中、インターネット上の国際化の手法がどうなるかという議論の最終的な行方は依然として不明確なままである。一刻も早い解決が望まれることだけは確かであろう。インターネットにおける国際化というものは、単に自分の使いたい言語や文字が、自分の気に入った方法で表現できれば良いというものではない。インターネット社会が国際化の手法そのものを共有しないことには、情報のやりとりは不可能である。接続された全ての人々の間で自由に情報の交換や共有ができてこそ、インターネットなのではないだろうか。Toshihiro[index]。