Web ページの多言語化について
Multilingualization of WWW pages

大岩 寛
Yutaka Oiwa

東京大学理学部情報科学科. oiwa@is.s.u-tokyo.ac.jp.

1. はじめに

インターネットの世界規模の発展にともない、もともと英語圏でスタートした WWW も、日本国内でも広く使われるようになりました。しかし、世界規模である ということは、当然複数の言語、複数の文字が存在するわけで、それらの扱いは 無視できなくなってきました。そのため、WWW のデータの転送手段である HTTP/1.0 [1] では、MIME [2] によるインターネット・メールの拡張を準用して、 文字コードの複数ある環境に適応しました。また、HTTP/1.1 [3] では、新たに "Content Negotiation" という機構が盛り込まれました。これは、クライアン ト側が言語や文字などについての要求を送信し、サーバ側で同じ URL から別の 内容を返すものです。

Apache httpd [4] は、極めて高性能・高機能な http サーバとして有名ですが、 Content Negotiation による条件つき送信に完全に対応しています。今 回は、この機能を用いて WWW ページを多言語に対応させる方法を、実際の設定 例を用いて説明します。なお、サーバのバージョンは 1.3.1 を利用しています。

2. 文字コードについて

現在、多くの言語を母語にする人々がコンピュータを用いています。これら複数 の言語圏では、それぞれ違った文字セットを用いてそれぞれの言語スクリプトを 計算機上で表現しています。また、日本語だけを見ても、複数の文字コードの表 現が存在しています。不特定多数を受信者とする WWW の様なメディアでは、正 しく文書を送受信するには、これらの言語の表記で使われる複数の文字セットを、 確実な方法で判別できる必要があります。今回は、日本語のコードに限って話を 進めます。

日本国内で使われている文字集合は JIS コードと呼ばれるもので、JIS X 0208 [5] に定義されているものです。これを実際に計算機上で表現する方法と して、現状では4つの文字コードセットが主に用いられています。これらのコー ド系の詳細は、「文字コードの話」 [6] などに詳しく述べられていますが、 簡単に説明します。

まず、俗に JIS コードといわれるものは、ISO-2022-JP [7] に定められている 文字の表現法で、多言語を同時に扱う際の国際規格 ISO 2022 [8] のサブセット になっており、このデータだけで、文書が具体的にどの文字を表現しているのか を一意に確定することができます。日本語の WWW 文書は、可能な限りこの形式 に統一することをお勧めします。

日本語 EUC は (Extended Unix Code) の名の通り、主に Unix の世界で使われ てきた文字の表現法です。ISO 2022 に準拠していますが、「この文書が日本語 EUC で書かれている」という情報がなければ、他の文字コード、例えば英語及び 西欧諸語のための文字コードである ISO-8859-1 や韓国語の EUC コードなどと 判別することができません。

Shift-JIS は、これは主に日本の MS-DOS の世界で広く使われてきたコードです。 ISO 2022 非準拠であること、拡張性に乏しいこと、扱いが EUC と比べて繁雑な こと、ISO 2022 の制御コードの領域を使っているため他コードセット と誤認した際に問題が生じることなどからあまり好ましくないコードですが、 Windows, Macintosh の両環境のネイティブ文字コードであることから、 現実には多くの使用例が見られます。

"日本語Unicode" は、主に最近の Windows 環境でサポートされています。上 記で触れた JIS X0208 の文字を、ISO 10646-1 [9] (Unicode) に基づいて並べ たもので、ISO 10646-1 で2つ以上の文字が統合されたコードを、強制的に日本 語の文字と解釈することになります。実際には他国語、特に中国・韓国・台湾語 の Unicode 文書と混同すること、さらには JIS との対応関係ですら OS によっ て微妙に異なることから、複数環境での情報交換が必要な WWW では使い物にな らないのが現実です。これらの問題点についてはあまり深く触れませんが、詳し くは「従来の文字コードと Unicode に関する諸問題」 [10], 「いま日本語が 危ない」 [11] を参照して下さい。実際にはこのコードで送信されると変換す らできない環境がありますから、設計的な問題点に目をつぶるとしても現状では 用いない方が無難でしょう。

現状では、これら4通りのコードが混然一体となって送信されているため、受信 側で統計的にこれらのコードを見分けるという、いかにもいい加減な処理がなさ れています。ISO-2022-JP は、データの中に日本語のデータであるという情報が 含まれるので、まだましな方ですが、その他の文字コードではこういった処理は ほぼ不可能です。日本語 Unicode も、Unicode であることは判別できますが、 具体的に日本語のデータであることは決定できません。

これらは本来、サーバ側がちゃんとどのコードで送信しているかを明示しなけれ ばならないのですが、実際にはなにも送信されないことがほとんどです。しょう がないのでブラウザには「文書の文字コード」とかいう、本来あってはならない メニューが存在します。

実際のところ、HTTP/1.0 には

The "charset" parameter is used with some media types to define the character set (Section 3.4) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or its subsets must be labelled with an appropriate charset value in order to be consistently interpreted by the recipient.
訳:
charset パラメータはいくつかのメディアタイプにおいて、 データの文字セットを定義するために用いられる。 送り側が文字セットを明示的に指定しなかった場合、 text タイプのサブタイプは HTTP を通じて受信された場合 デフォルトの文字セットである ISO-8859-1 を持つと定義されている。 ISO-8859-1 でもそのサブセットでもないデータは、 受取側で矛盾せずに解釈されるよう、適切な charset 値 によってラベル付けされなければならない。

という記述がありますから、日本語の文章を送る際には、 必ず正しいラベルづけをしなければなりません。

具体的な方法ですが、HTML 文書を HTTP で送信する際は、この文書が HTML で あることを表すために、次のような情報を、WWW サーバが文書のヘッダにつけて 送っています。

Content-Type: text/html

これは、上記の HTTP のルールにより ISO-8859-1 で書かれた文書を表していま すから、これに

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

のように、charset タグを付け加えます。

実際のところ、方法は単純です。これまでも、SSI (Server Side Include) を使 う際などに .htaccess というファイルを使っています。方法は実は SSI を使えるようにする方法とほとんど一緒です。

WWW のファイルがおいてあるディレクトリに、.htaccess というファイルを作ります。このファイルに、次のような1行を 追加します。

AddType "text/html; charset=ISO-2022-JP" html

これは、html という拡張子を持つファイルを全て、 「text/html; charset=ISO-2022-JP」 という 種類のファイルとして送信しなさいという Apache への 指令です。文字セット名は、日本語 EUC の場合は EUC-JP、 Shift-JIS の場合は Shift_JIS にします。*1

*1: Netscape Navigator 3.0 などでは、EUC-JP, Shift_JIS の文字セットを認識ません。その場合、x-euc-jp, x-sjis を使えば認識します。x- で始まるタグは非公式な拡 張を表すもので、EUC-JP などが登録される前に用いられていたもので す。大抵の新しい方のタグを認識するソフトウェアでは、互換性のために古い形 式のものも認識しますが、最終的には正式なものに統一されるべきでしょう。現 状ではまだ登録前のソフトウェアが現役で使われていますので、どちらを使うべ きかは微妙なところです。

SSI も使いたい場合は、

AddHandler server-parsed .html

も一緒に書いておけばいいでしょう。

なお、.htaccess による設定変更は、URL の木構造で、/ までの全ての 親ディレクトリの設定が有効になるので、ディレクトリごとに設定を しないならば、自分の WWW のファイル群をおくトップのディレクトリに 1つおいておけば十分です。

また、どうしても apache に設定ができない場合は、 HTML ファイル内でこれを指定することにします。 HTML のヘッダで、まだ日本語が出てきてない位置に、

<meta http-equiv="Content-Type" 
         content="text/html; charset=ISO-2022-JP">

というタグを埋め込みます。もちろん ISO-2022-JP の部分は文字集合 によって変わります。このタグはメタ情報、すなわちこの文書自身に関する情報 を表しており、http-equiv は、この情報をあたかも HTTP ヘッダに書い てあったかの様に用いることを表しています。

一部の書籍などが、日本語には必ず charset=ISO-2022-JP を つけろなどという間違った記述をしていますが、これは嘘の情報を クライアントに明示するという意味で、無指定よりもさらにたちが悪いです。 実際、charset を認識するブラウザでは自動判別の機能が off に されるので、完全に化けてしまいクライアント側ではどうやっても 内容を読むことができません。ちゃんと内容に合わせた文字セットを 指定して下さい。

3. Content Negotiation による多言語化

ここまでで、日本語の文書の送信の望ましい方法について述べました。次に、 複数の言語の文書を同じ URL から送信する方法について説明します。

一般的には、URL を言語ごとに分けてしまい、例えば日本語は index-j.html, 英語は index-e.html と いったように区別することが行なわれていますが、これだと アクセスする側で、それぞれ勝手なルールで作られた URL を 手動で選択しなければなりません。ここでは、それを自動化すべく、 HTTP/1.1 で定義された Content Negotiation の機能を使います。

HTTP/1.0 対応の最近のソフトウェアはこの機能を拡張として 提供しており、Apache には version 1.1 の時点で、既にこの機能が組み込まれています。 このモジュール (mod-negotiation.o) は標準の設定で既に 組み込まれています。

3.1 拡張子ベースの選択

まずは、文字コードが共通である、比較的簡単な場合を説明します。 多言語化するファイルの名前は、仮に index.html としておきます。

まず、Negotiation モジュールを使用することを .htaccess で サーバに対して宣言します。.htaccessOptions 行に、 Multiviews オプションを追加します。Options 行が ない場合、Apache 1.2 以降なら

Options +Multiviews

と書いておけばいいでしょう。Apache 1.1 まででは追加の意味の + が使えないので、

Options FollowSymlinks Indexes Multiviews

などと必要な全てのオプションを指定しなければなりません。 詳しくは Apache のマニュアルを参照して下さい。 また、Multiviews を用いる場合には、Apache サーバがそのディレクトリを 探索できることが必要になります。これはどの言語の文書が実際に存在している のかを得るのに不可欠ですので、ディレクトリのリード・パーミッションは 開けておいて下さい。

次に、必要な言語とその拡張子をやはり .htaccess で指定します。

AddLanguage ja .ja
AddLanguage en .en

これは 拡張子 .ja で日本語のファイルを、拡張子 .en で英語のファイルを 提供することを指示します。言語はこのように、ISO 639 [12] で 定められた2文字のコードか、その後に国名をつけた5文字のコードで指定します。

de ドイツ語
en 英語
en-US アメリカ英語
en-GB イギリス英語
es スペイン語
es-ES スペイン語
fr フランス語
fr-FR 本国フランス語
fr-CA カナダフランス語
it イタリア語
ja 日本語
ko 韓国語
pt ポルトガル語
pt-BR ブラジル ポルトガル語
zh 中国語
zh-CN 大陸中国語
zh-TW 台湾中国語
表1: 主な言語の指定

次に、各言語版の文書を例えば index.html.jaindex.html.en などの名前で作成します。 最後に index.html というファイルがないことを確認 して、設定は完了です。これは、Apache が、要求されたファイルが 存在しない場合にのみ各バージョンの検索をするため、index.html が存在すると常にこのファイルを送信してしまうためです。

なお、クライアントから具体的な要求がなかった場合の選択については、 .htaccess に次の指定をすることで決定します。

LanguagePriority en ja

これは、要求がなかったばあい、まず英語の文書を、それがなければ 日本語の文書を検索することを意味します。

なお、言語の設定に関わらず、.ja などの言語タグを含んだ 完全な URL を設定すればそれぞれの言語の文章を得ることができますので、 各ページにそれぞれ英語版・日本語版へのリンクを含ませておくと、 判別がうまくいかない場合に対処できます。

3.2 設定ファイルによる選択

拡張子ベースによる選択では、ドキュメントの種類は言語を除いた拡張子から決 定され、上のような方法では両方とも ".html" として扱われますから、 結果として2つの文書に違う charset を与えることができません。 また、英語版と日本語版の URL が特定の拡張子を持たなければならないので、 融通が効きません。これらに対処する必要がある場合、第2の方法として Apache に設定ファイルを読み込ませるという方法を用います。 再び、多言語化するファイルの名前を仮に index.html とします。

まず英語版と日本語版の文書をそれぞれ適当な URL に置き、 index.html.var というファイルに

Content-type: text/html; level=4; charset=ISO-2022-JP; qs=1
Content-Language: ja
URI: ja_JP.ISO-2022-JP/index.html

Content-type: text/html; level=4; charset=ISO-8859-1; qs=1
Content-Language: en
URI: en_US.ISO-8859-1/index.html

のような「マップファイル」を用意します。このファイルには、 "index.html" という名前で送信できる文書の可能性を列挙しておきます。 この場合、言語 "ja" な HTML ファイルと言語 "en" な HTML ファイル の2つが可能性として存在することを意味します。URI にはそれぞれの 文書のある場所を指定します。

また、.htaccess には、先ほどの設定に加えて

AddHandler type-map var

という行を追加します。これで拡張子 .var にマップファイルがあるこ とを指示します。

この状態でクライアントからアクセスが来ると、サーバ側でそれぞれ 条件に応じて URI: に示したファイルを選択して送信してくれます。

もちろん、これらの方法を使う場合には、どちらの場合でもクライアントが言語 に関する要求を送信しなければなりません。Netscape Navigator では、Unix 版 の 3.0 では X リソースで、それ以外の 3.0 以降及び Unix の 4.0 ではメニュー 画面から指定ができます。Microsoft Internet Explorer では、どうも日本語版 などクライアントのバージョンに応じて固定的に設定されているようです *1: [補足あり]。 これらの設定は、HTTP の要求送信時に同時にサーバに送られることになります。

4. 応用

これらの機能は、実は必ずしも言語に特化したものではありません。 ドキュメントの種類 (Content-Type) などでも分岐が可能です。 Netscape Navigator 3.04 の送信するリクエストの例を見てみましょう。

GET /test.html HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/3.04 (X11; I; Linux 2.0.33 i586)
Host: localhost:7000
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: ja, en, de

この中で、Accept で始まる行が受け入れられるデータの性質を表してい ます。Accept-Language の方はさきに述べた言語の要求です。この例の場合、 Netscape Navigator はサーバに対して、「言語は日本語、英語、ドイツ語の物 を、データの種類は、優先順位としては GIF, X Bitmap, Jpeg, Progressive Jpeg がこの順にいいけど、まぁなんでもいいよ (*/*)」という要求をし ていることになります。

ですから、Options +Multiviews とした状態で、同じディレクトリに、 例えば pic.gif, pic.png, pic.xbm, pic.txt などと拡張子以外が同じ名前を持つファイルを おいておいて、リンクを書く時に拡張子を省いておくと、画像が表示で きるブラウザでは画像を、そうでないブラウザではテキスト版を表示するなどと いった動作をさせることができます。

この他にも、Apache サーバには極めて多くの機能が実装されているので、 一回マニュアルに目を通しておくと、いろいろと応用が効くと思います。 例えば、僕のホームページでは、ディレクトリの表示の画面を cgi を用いて 大幅にカスタマイズして、ファイルの説明などを一緒に表示できるようにしてい ます。色々と試してみて下さい。

参考文献

これらの文献のうち、RFC である [1,2,4,5] については、僕の web ページの中の http://www.is.s.u-tokyo.ac.jp/~oiwa/distrib/data/rfc/ に ミラーリングしてあります。

[1]
T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext Transfer Protocol -- HTTP/1.0. May 1996. RFC 1945, ftp://ds.internic.net/rfc/rfc1945.txt.
[2]
N. Freed, N. Borenstein, K. Moore, J. Klensin, J. Postel, Multipurpose Internet Mail Extensions (MIME). November 1996. RFC 2045--2049, ftp://ds.internic.net/rfc/rfc204{5,6,7,8,9}.txt.
[3]
Apache Project. http://www.apache.org/.
[4]
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, Hypertext Transfer Protocol -- HTTP/1.1. January 1997. RFC 2068, ftp://ds.internic.net/rfc/rfc2068.txt.
[5]
「7ビットおよび8ビットの2バイト情報交換用符号化文字集合」. JIS X 0208-1997.
[6]
J. Murai, M. Crispin, E. van der Poel, Japanese Character Encoding for Internet Messages. June 1993. RFC 1468, ftp://ds.internic.net/rfc/rfc1468.txt.
[7]
ISO 7-bit and 8-bit Coded Character Sets -- Code Extension Techniques. ISO 2022. 翻訳規格: 「情報交換用符号の拡張法」, JIS X 0202-1991.
[8]
伊藤隆幸, 「文字コードの話」. 理論科学グループ部報 199 号 (43--54ページ), 200 号 (15--38ページ), 1996年. オンライン版: 1998年, http://hp.vector.co.jp/authors/VA001240/article/charcode.html.
[9]
Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. ISO/IEC 10646-1, 1993. 翻訳規格: 「国際符号化文字集合 (UCS) -- 第一部 体系及び基本多言語面」. JIS X 0221-1995.
[10]
伊藤隆幸, 「従来の文字コードと Unicode の対応に関する諸問題」. 1998年. http://hp.vector.co.jp/authors/VA001240/article/ucsnote.html.
[11]
太田昌孝. 「いま日本語が危ない -- 文字コードの誤った国際化」. 丸山学芸図書, 1997年.
[12]
Code for the Representation of Names of Languages. ISO 639. http://www.ics.uci.edu/pub/ietf/http/related/iso639.txt.

補足 (1998/10/15): 次のようなドキュメントが発表されました。述べている方 法は基本的には本稿の方法と同一です。

(1998/11/17): *1 の項ですが、 Internet Explorer 4.0 [Windows] では、「インターネットオプション - 言語」の 項目で言語の優先順位を指定できるそうです。