国際化メッセージ

1. はじめに

2. 各国語化と国際化

それに対して、単に自国語と英語の2つの言語だけではなく、複数の言語を取り扱うための試みが「国際化 (internationalization)」と呼ばれるものである。理想的には、国際化された環境が提供されていれば、何の変更もなしにユーザは好きな言語や文字を扱うことが可能になるはずである。しかし実際は国際化に関しては未解決の問題が数多く残されており、現時点ではこのような完全な形で国際化された環境は存在しない。

3. 概念の整理

To: Hitoaki Sakamoto <hitoaki@sphere.csl.ntt.jp>
From: TAKADA Toshihiro (=?ISO-2022-JP?B?GyRCOWJFRElSOTAbKEI=?= ) <takada>
Subject: Re: Camera for Takada
Date: Mon, 04 Apr 1994 18:57:11 -0700
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"

> おおい、いま忙しいのかな？

nvでは、そっち見えるよ。vatは聞こえない。

更にこの例では、これらの文字集合やエンコーディングと、電子メール・システムとを結び付ける「インタフェース」として、MIME (Multipurpose Internet Mail Extensions) を利用している。具体的には、メールの中にある

Content-Type: text/plain; charset="ISO-2022-JP"

このように一口に国際化と言っても、それを構成する要素はいくつかの概念に分類することができる。以下ではこれらの概念を、

• 文字集合
• エンコーディング
• アプリケーションとのインタフェース

4. 文字集合

4.1 様々な文字集合

• 1バイト文字集合

  ISO 646:1991 USA				(ASCIIと同等)
  ISO 8859-1:1987 Latin alphabet No.1		
  ISO 8859-2:1987 Latin alphabet No.2		
  ISO 8859-3:1988 Latin alphabet No.3		
  ISO 8859-4:1988 Latin alphabet No.4		
  ISO/IEC 8859-5:1988 Latin/Cyrillic alphabet	(キリル文字)
  ISO 8859-6:1987 Latin/Arabic alphabet		(アラビア文字)
  ISO 8859-7:1987 Latin/Greek alphabet		(ギリシャ文字)
  ISO 8859-8:1988  Latin/Hebrew alphabet		(ヘブライ文字)
  ISO/IEC 8859-9:1989 Latin alphabet No.5
  ISO/IEC 8859-10:1992 Latin alphabet No.6       
  JIS X 0201-1976					(日本の国内規格、ローマ字と片仮名)
         

• 2バイト文字集合

  JIS X 0208-1990		(日本の国内規格、JIS第1水準と第2水準)
  JIS X 0212-1990		(日本の国内規格、補助漢字)
  GB 2312-1980		(中国の国内規格)
  KS C 5601-1992		(韓国の国内規格)
  CNS 11643-1986		(台湾の国内規格)
         

4.2 ISO/IEC 10646

5. エンコーディング

5.1 ISO 2022を用いたエンコーディング

例えば日本で良く使われているASCII, JIS X 0201, JIS X 0208という3つの文字集合を組み合わせるためのエンコーディングを考えてみよう。その1つが現在インターネットで標準的に用いられているISO-2022-JPであり、これはISO 2022の7単位符号系における利用例である。7単位符号系とは7ビットの組合せで文字を表現するものである。

また日本語化されたUNIX環境などで使用されている日本語EUC (Extended Unix Code) は、ISO 2022の8単位符号系 (8ビットの組合せで文字を表現する) におけるエンコーディングの例となる。その他、X Window Systemで用いられているCompound Text Encoding [7] もISO 2022に基づくエンコーディングのひとつである。

5.2 ISO-2022-JPとその後継

Esc Seq	   Character Set		ISOREG
----------------------------------------------
ESC ( B	   ASCII			     6
ESC ( J	   JIS X 0201-1976 ("Roman" set)    14
ESC $ @	   JIS X 0208-1978		    42
ESC $ B	   JIS X 0208-1983		    87

さて、その定義から明らかなように、ISO-2022-JPは日本語と英語のみが使用可能なエンコーディングである。それに対して、ISO-2022-JPを拡張して日本語以外の文字も表現できるようにしたエンコーディングがISO-2022-JP-2 [9] である。ISO-2022-JP-2で使用可能な文字集合の一覧を以下に示す。

			94 character sets
reg#  character set	 ESC sequence		     designated to
------------------------------------------------------------------
6     ASCII		 ESC 2/8 4/2	  ESC ( B    G0
42    JIS X 0208-1978	 ESC 2/4 4/0	  ESC $ @    G0
87    JIS X 0208-1983	 ESC 2/4 4/2	  ESC $ B    G0
14    JIS X 0201-Roman	 ESC 2/8 4/10	  ESC ( J    G0
58    GB2312-1980	 ESC 2/4 4/1	  ESC $ A    G0
149   KSC5601-1987	 ESC 2/4 2/8 4/3  ESC $ ( C  G0
159   JIS X 0212-1990	 ESC 2/4 2/8 4/4  ESC $ ( D  G0

			96 character sets
reg#  character set	 ESC sequence		     designated to
------------------------------------------------------------------
100   ISO8859-1		 ESC 2/14 4/1	  ESC . A    G2
126   ISO8859-7(Greek)	 ESC 2/14 4/6	  ESC . F    G2

またISO-2022-JP-2から日本での利用状況に依存していた部分を取り除き、更に韓国語のエンコーディングに使用されているISO-2022-KR [10] との整合性を図ったものとして、ISO-2022-INT-1 [11] が提案されている。

5.3 ISO/IEC 10646におけるエンコーディング

しかしその一方で、ISO/IEC 10646は単に文字の集合とその中の各文字に対応する符号を定めたものであり、かつ、その符号には今まで制御文字として使用されていたオクテットが含まれるているため、「これらの符号を従来の計算機あるいはネットワーク上で利用可能なビットパターンとして表現」するための「エンコーディング」の問題が依然として残ることになってしまった。このようなISO/IEC 10646のエンコーディングは、その目的に応じて複数存在し、現在提案されているだけでも、

• UTF-1 (ISO 2022で定義された制御文字領域のコードを含まない表現法)
• UTF-8 (File-System-Safe Transformation Format, UTF-2とも呼ばれる)
• UTF-7 (Mail-Safe Transformation Format)

6. アプリケーションとのインタフェース

6.1 電子メールとネットワーク・ニュースの場合

• 単一メッセージ中への複数のオブジェクトの構造的な包含
• ASCII以外の文字集合の使用
• 画像や音声などの非テキスト情報の表現

第2節のメールの例にあった

Content-Type: text/plain; charset="ISO-2022-JP"

=?ISO-2022-JP?B?GyRCOWJFRElSOTAbKEI=?=

高田敏弘

MIMEにおける非ASCII文字の取扱いの中心にある思想は、「そのテキストで使用されている文字集合を常に明確に宣言する」というものである。これは、裏返せば、MIMEには使用される文字集合を宣言するだけの能力しかないと言い換えることができ、メッセージの国際化に際しては、実際に「国際化された文字集合」が存在しない限り、MIMEの宣言はほとんど役に立たない。国際化された文字集合であるISO/IEC 10646をMIMEの中で使用するための提案 [16] [17] も存在するが、これらが実際に使用されている例は筆者はまだ見たことがない。

メッセージの国際化に関する別のアプローチとして、ISO-2022-INT-1のように、インターネット上のメッセージのデフォールトとなる文字集合を、従来のASCIIからISO 2022に基づくものに変更しようという提案もある。

6.2 Gopher/WAIS/WWW

既に世界各国では、これらの広域情報システムで自国の言語や文字を取り扱うための試みが行なわれている。例えば日本においてはISO-2022-JPが主として使用されている。しかし電子メールなどとは若干状況が異なり、これらの広域情報システムではISO-2022-JPに対応したソフトウェアがまだ充分に整備されていないため、依然として日本語EUCやShift-JISも混在して使用されているのが現状である。

広域情報システムのうち、WWWの日本語化と国際化の現状については [18] に詳しく書かれているのでそちらを参照して欲しい。ここで強調しておきたい点は、現時点ではWWWの国際化については「何も決まっていない」ということである。現在正式に使用が認められている文字集合はISO 8859-1 (Latin-1) のみであり、それ以外の言語や文字の使用に関しては、HTML (HyperText Markup Language)の拡張などに関する議論が続いている最中である [19] [20] 。このような状況はGopherやWAISについても同様である。

7. その他の問題点

7.1 言語情報の表記

この言語情報の表記に対する具体的な提案としては [21] がある。これは言語名をISO 639で定められた2文字の名前で指定することを提案したものである。例えば英語は "en", 日本語は "ja" という名前で表される。また同一の名称を持つ言語でも使われる国の違いや方言によってそれらを区別する必要が生じることも予想される。このような場合は上記の言語名の後ろに副言語名を付け、それらを区別する。例えば英国語は "en-UK", 米国語は "en-US" と表される。その他に、ISO 639で定義されていない言語名や副言語名を登録する方法も定められている。

7.2 テキストの双方向性

• Visual:
  与えられたテキスト・データを単に左から右に表示する。この場合、右から左に書かれるべきテキストについては、あらかじめ逆向きに書かれたデータを作成する必要がある。
• Implicit:
  テキストを表示する方向は、その文字のタイプ (左から右に書かれるべき文字かあるいは右から左に書かれるべき文字か) と隣り合う文字との関係から決定される。
• Explicit:
  [22] で定義されたコントロール・シーケンスを用いてテキストを表示する方向を指定する。

8. 国際化されたソフトウェア

また開発環境としては、X Window Systemがかなりの範囲で国際化をサポートしている。基本的にはX Window Systemの国際化はOSの各国語化 (Locale) に依存する。しかし、例えば Version 11, Release 6 のサンプル・インプリメンテーションでは、ISO/IEC 10646のサポートが実装されている (具体的にはwide-characterとしてUCS-4を、multibyte-characterとしてUTF-8を使用している)。

9. まとめ

一方の、各種文字集合をISO 2022を用いて切り換えて使用する手法にもいくつかの問題がある。一番大きな問題は、ISO 2022に基づく枠組みを使用する限り、その中でどのような種類の言語や文字が取り扱えるのかが文字集合の存在に制限される点にある。例えば [26] には、ISO/IEC 10646でなければ表すことの出来ない文字を含む言語、言い替えれば、それらの文字を含む文字集合がISO/IEC 10646以外に存在しない言語が計79種列挙されている。そもそも使用したい言語を表現し得る文字集合が存在しなければISO 2022の使いようがない。

このような状況の中、インターネット上の国際化の手法がどうなるかという議論の最終的な行方は依然として不明確なままである。しかし一刻も早い解決が望まれることだけは確かであろう。

インターネットにおける国際化というものは、単に自分の使いたい言語や文字が、自分の気に入った方法で表現できれば良いというものではない。インターネット社会が国際化の手法そのものを共有しないことには、情報のやりとりは不可能である。接続された全ての人々の間で自由に情報の交換や共有ができてこそ、インターネットなのではないだろうか。

参考文献

[1] American National Standards Institute:

Coded Character Set -- 7-bit American National Standard Code for Information Interchange, ANSI X3.4-1986, 1986.

[2] 日本工業標準調査会：

情報交換用漢字符号, JIS X 0208-1990, 1990.

[3] Keld Simonsen:

Character Mnemonics & Character Sets, RFC 1345, 1992.
<ftp://ds.internic.net/rfc/rfc1345.txt>.

[4] International Organization for Standardization (ISO):

Information Technology -- Universal Multiple-Octet Coded Character Set (UCS), ISO/IEC 10646-1:1993(E), 1993.

[5] Unicode Consortium:

The Unicode Standard, Version 1.1.

[6] International Organization for Standardization (ISO):

Information processing -- ISO 7-bit and 8-bit coded character sets -- Code extension techniques, ISO 2022:1986(E), 1986.

(日本工業標準調査会： 情報交換符号の拡張法, JIS X 0202-1991, 1991)

[7] Robert W. Scheifler:

Compound Text Encoding, Version 1.1, X Consortium Standard, 1994.

[8] Jun Murai, Mark Crispin and Erik M. van der Poel:

Japanese Character Encoding for Internet Messages, RFC 1468, 1993.
<ftp://ds.internic.net/rfc/rfc1468.txt>.

[9] Masataka Ohta and Ken'ichi Handa:

ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP, RFC 1554, 1993.
<ftp://ds.internic.net/rfc/rfc1554.txt>.

[10] Kilnam Chon, Hyunje Je Park and Uhhyung Choi:

Korean Character Encoding for Internet Messages, RFC 1557, 1993.
<ftp://ds.internic.net/rfc/rfc1557.txt>.

[11] Masataka Ohta and Ken'ichi Handa:

Internet Multilingual Text Encoding: ISO-2022-INT-*, Internet-Draft, 1994.
<ftp://ds.internic.net/internet-drafts/draft-ohta-text-encoding-01.txt>.

[12] David H. Crocker:

Standard for the Format of ARPA Internet Text Messages, RFC 822, 1982.
<ftp://ds.internic.net/rfc/rfc822.txt>.

[13] Mark Horton and R. Adams:

Standard for Interchange of USENET Messages, RFC 1036, 1987.
<ftp://ds.internic.net/rfc/rfc1036.txt>.

[14] Nathaniel S. Borenstein and Ned Freed:

MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies, RFC 1521, 1993.
<ftp://ds.internic.net/rfc/rfc1521.txt>.

[15] Keith Moore:

MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text, RFC 1522, 1993.
<ftp://ds.internic.net/rfc/rfc1522.txt>.

[16] Davis Goldsmith and Mark Davis:

Using Unicode with MIME, RFC 1641, 1994.
<ftp://ds.internic.net/rfc/rfc1641.txt>.

[17] David Goldsmith and Mark Davis:

UTF-7 - A Mail-Safe Transformation Format of Unicode, RFC 1642, 1994.
<ftp://ds.internic.net/rfc/rfc1642.txt>.

[18] 高田敏弘：

World-Wide Webの日本語化・国際化の現状, 日本インターネット協会ニュース, Vol.1, No.2, 1994.
<http://www.ntt.jp/people/takada/docs/www-j10n/>.

[19] David Raggett:

A Review of the HTML+ Document Format, In proceedings of WWW '94, 1994.
<http://www.cern.ch/PapersWWW94/dsr.ps>.

[20] Toshihiro Takada:

Multilingual Information Exchange through the World-Wide Web, In proceedings of WWW '94, 1994.
<http://www.ntt.jp/people/takada/www94/>.

[21] Harald Tveit Alvestrand:

Tags for the Identification of Languages, Internet-Draft, 1993.
<ftp://ds.internic.net/internet-drafts/draft-ietf-mailext-lang-tag-00.txt>.

[22] European Computer Manufactures Association (ECMA):

Handling of Bi-Directional Texts, European Computer Manufacturers Association, TR/53, 1992.

[23] Hank Nussbacher and Yehavi Bourvine:

Hebrew Character Encoding for Internet Messages, RFC 1555, 1993.
<ftp://ds.internic.net/rfc/rfc1555.txt>.

[24] Hank Nussbacher:

Handling of Bi-directional Texts in MIME, RFC 1556, 1993.
<ftp://ds.internic.net/rfc/rfc1556.txt>.

[25] Mikiko Nishikimi, Ken'ichi Handa and Satoru Tomura:

Mule: MULtilingual Enhancement to GNU Emacs, In Proceedings of INET'93, 1993.

[26] Harald Tveit Alvestrand:

Characters and Character Sets for Various Languages, Internet-Draft, 1994.
<ftp://ds.internic.net/internet-drafts/draft-ietf-mailext-lang-char-00.txt>.

[27] Ken Lunde:

Understanding Japanese Information Processing, O'Reilly & Associates, Inc., 1993.

[index]