みなさんは、WWWブラウザの初期設定の中に、次のような項目があることにお気づきでしょうか。この項目には、「使用している言語によって、異なるページを発信するサイトがあります。」と書かれています。それはどういう仕組みによって行われているのでしょうか。
このページでは、Asahiネットで1999年4月末から一介のページ作者として異なるページを発信できるようになったことを受けて、Asahiネットでこの仕組みをどのように使えるのかの概略を記します。Asahiネット事務局から正式な利用ガイドが出るまでの間の非公式ガイドとして皆様のお役に立てば幸いです。
わたくしたちがWWWブラウザで何かある「ページ」を眺めようとする際、ユーザの操作としては「ページ」のURIを入力するだけで、後はブラウザがどうにかしてくれているわけですが、WWWブラウザとWWWサーバの間ではHTTP (HTTP 1.1: [RFC2068]) という通信規約に基づく折衝が行われます。
この折衝の際、単純に「これこれのURIのリソースを送ってよこせ」という要求とそれに対する応答が為されるだけではありません。WWWブラウザは、初期設定等に基づいて、「もし選べるんだったら日本語のページを送ってね」とか「文字符号化方式はEUC-JPがいいなぁ」といった情報も送っていて、WWWサーバは、(もしこれに応じられるよう設定されていれば)適切なリソースを選んで送信しているのです。
この、言語や文字符号化方式などの違いのことを「リソースの表現形(representation of a resource)」と呼び、WWWブラウザとWWWサーバの間で最も都合の良い表現形は何かということの情報交換を行うことを「Content Negotiation」と呼びます。Asahiネットでは、1999年4月末から MultiViews による [Negotiation] が有効になりましたので、このページで概説するような、リソースの多次元的表現が可能になりました。
実は冒頭の初期設定は、この Content Negotiation の際に「もし選べるんだったら何語のページを送ってほしいか」という情報をWWWブラウザからWWWサーバに送らせるために、設定するものなのでした。
WWWの「ページ」は、URI (Uniform Resource Identifire) で各々を指し示すようになっています。このような「ページ」のことを [URI] の枠組で呼び替えると、「ある1つの固有名を持つリソース」という言い回しになります。これまでわたくしたちは(というか、わたくしは)「1つの固有名を持つリソースというのはすなわち1つの固有名を持つファイルである」と思っていましたけれど、実は、そうではないリソースの在り方があるのです。
ここに、言語以外は全く同じ内容を持つHTMLファイルがあるとしましょう。双方がインデックス「ページ」であるとします。この「英語のindex.htmlファイル」と「日本語のindex.htmlファイル」をファイル名のみで区別したい場合、「index.html / index-j.html」といった名前をつけるのが過去のわたくしの常でした。これとは違い、複数言語のファイルを識別するために複数の拡張子を設けるというアイディアもあり得ます。「index.en.html / index.ja.html」といった具合です。
実は Content Negotiation の機能は、「ページ」の書き手の立場で眺めれば、「複数の拡張子を用いて識別している複数のファイルのWWWでの呼び名を、1つのURIで代表させる」ということによって実現されています。上の最後の例で言うと、拡張子の順番を変えて、「index.html.ja」ファイルと「index.html.en」ファイルのURIを「index.html」だということにしておけば、追加されている言語識別子をWWWサーバとWWWブラウザの間での「望ましい言語」に関する折衝の情報に利用できる、というわけです[*]。
AsahiネットがWWWサーバに用いているApache(1.3.6)の場合、1つのURIで表せるリソースの表現形には次の4つの次元があります[**]。
どの次元を区別したいかによって、ファイル名のつけかたとURIのつけかたが異なって来ます。例えば「XMLファイルとHTMLファイルのどちらかから選ばせたい」と考える場合、ファイル名は「hoge.xml / hoge.html」でURIは「hoge」というものになりますし、「このHTMLファイルの文字符号化方式を選ばせたい」という場合のファイル名は「hogege.html.jis / hogege.html.utf-8」でURIが「hogege.html」といった具合になるでしょう。
ファイル名 | 有効なURI | 無効なURI |
---|---|---|
foo.html.ja | foo foo.html | - |
foo.ja.html | foo | foo.html |
foo.html.ja.jis | foo foo.html | foo.html.jis |
foo.ja.html.jis | foo foo.ja.html | foo.html foo.html.jis |
foo.ja.jis.html | foo | foo.html |
ここに、ファイル名とURIの関係を表にしてみました。もちろんファイル名を完全に記した場合も有効なURIではありますが、Content Negotiation の役には立ちません。
有効・無効について、各々すべての組み合わせを掲げたわけではありませんが、ある法則性があることにお気づきいただけるでしょうか。
この法則を十分に理解し、目的に応じたファイル名/URIの組み合わせを考えましょう[***]。
MIMEタイプ、言語、符号化方式の3次元に関してはデファクトスタンダードを含めて世界標準がありますが、文字符号化方式の次元に関しては現在まだ標準はありません(そもそも、文字符号化方式の次元をMIMEタイプとは独立した1つの別次元として扱えるよう設定されているWWWサーバは、Asahiネットの他、日本イソターネット協会など、限られた数しか稼動していないようです)。
文字符号化方式 | 識別子 |
---|---|
US-ASCII | ascii |
ISO-8859-1 | 8859-1 |
ISO-8859-2 | 8859-2 |
ISO-8859-3 | 8859-3 |
ISO-8859-4 | 8859-4 |
ISO-8859-5 | 8859-5 |
ISO-8859-6 | 8859-6 |
ISO-8859-7 | 8859-7 |
ISO-8859-8 | 8859-8 |
ISO-8859-9 | 8859-9 |
Shift_JIS | shift_jis sjis |
EUC-JP | euc-jp |
ISO-2022-KR | 2022kr iso-2022-kr |
EUC-KR | euc-kr |
ISO-2022-JP | 2022jp jis iso-2022-jp |
ISO-2022-JP-1 | 2022jp1 iso-2022-jp-1 |
ISO-2022-JP-2 | 2022jp2 iso-2022-jp-2 |
ISO-2022-JP-3 | 2022jp3 iso-2022-jp-3 |
UTF-7 | utf-7 |
UTF-8 | utf-8 |
UTF-16 | utf-16 |
GB2312 | gb2312 |
Big5 | big5 |
KOI8-R | koi8-r |
ともあれ、文字符号化方式の識別子として、Asahiネットでは現在、わたくしが世界に提案中(^^;)の [CharsetConf] による識別子セットをベースにした識別子を用いています。
MIMEタイプの識別子には、通常わたくしたちがファイルの拡張子として用いているものが使われます。符号化方式の識別子もまた、「gz」や「bz2」など、非常にポピュラーなものでしょう。
言語の識別子には、HTML 4.0 のlang属性値と同じく、[RFC1766] の言語識別子が用いられます。なお、現在のAsahiネットの設定は、「ja-JP」や「en-US」のように地域情報との組み合わせではなく、「ja」「en」のような形式でないと、言語の識別子としては認識されないようです[*4*]。
また言語情報に関しては少々面白い機能があり、バイリンガル/マルチリンガル文書の言語情報を記す場合には優先順に「language.html.ja.en.fr」のようなファイル名にすれば、各言語識別子が表す言語情報が、ファイル名の拡張子として記した順番通りの優先度をもつものとして扱われます。
現在W3Cでは "次世代HTML" である [XHTML] の仕様策定の作業が進められています。これは [XML] によって HTML 4.0 DTDを書き直す作業と平行してDTDのモジュール化をおこなっているものです。
XHTMLに限らず、XMLベースのWWW「ページ」が一般化していく過程である種の障害となりかねない注意点があります。インターネットメディアタイプ「text/xml」を規定する [RFC2376] の共著者らが『Charsetパラメタの勧め』で述べているように、XMLファイルの場合、HTTP応答ヘッダ中にサブタイプとして適切なcharset情報を掲げることが必須なので、HTMLで言うところの「METAタグ」ではない方法で、正しいcharset情報を文書の書き手がサーバに与え、またサーバがクライアントに知らせる仕組みが必要なのです。
Asahiネットでは AddCharsetパッチと Content Negotiation + MultiViews の機能によって、全てのtext系メディアに関してcharset識別子を与えられ、これによってHTTP応答ヘッダ中にcharset情報を付加させられますので、リソースを多次元化しない場合にも、charset識別子を利用することをお勧めします。
多次元的な表現形が用意されているリソースについて、WWWサーバとWWWブラウザの間で「受け取り可能な (Acceptable)」表現形に関する折衝が行われた結果、ブラウザ側の受け取り可能な表現形が存在しないと判った場合、サーバは「406 Not Acceptable」というメッセージを返します。このメッセージは「404 Not Found」とは異なり、「当該URIのリソースは確かに存在するけれども要求された形式の表現形は存在しない」ということを表します。
よく設計されたWWWブラウザなら、この際、WWWサーバから「Available Variants」に関する情報を受け取りますので、その一覧から選び直してもらえます。
なお、例えば「index.html.jis」「index.html.utf-8」「index.html」というファイルを用意しておいた場合、ISO-2022-JPもUTF-8も受け取れないWWWブラウザはindex.htmlを見に行く――という優先順になりますので、文字符号化方法と言語の次元に関しては、表現形に関する「最後の砦」として当該次元の識別子が無いファイルを用意しておくことも可能です。
望ましい言語の折衝について、「Primary Language in HTML」という W3C note があり、そこでは次のようなMETA宣言によって Content Negotiation が機能するかのようなことが書かれています。
<META HTTP-EQUIV="Content-Language" Content="fr">
しかし、charset情報を記したMETA宣言をHTTP応答ヘッダに反映させるWWWサーバが存在しないのと同様、このMETA宣言もクライアント/サーバ間での Content Negotiation には無効です。
幸いAsahiネットでは言語識別子となる拡張子を用いることで、サーバに反映される言語情報をページの書き手が提供できますから、この場合は次のようなファイル名を記すようにしましょう。
primary-language.html.fr
また、同ノートの主眼である「マルチリンガルな文書だった場合にその主言語と副言語をどのように表すか」という点も、この図からお分かりいただけるように、「複数の言語識別子を優先順で並記する」ことによって実現されます。(「jikken.html.fr.de.8859-1」ファイルと「jikken.html.de.fr.8859-1」ファイルが、どういうvariantsとして表現されているかにご注目ください。ノートが述べているように、HTTP応答ヘッダのContent-Languageフィールドには、複数の言語が含まれる場合に優先度順にコンマ区切りで情報が記載されるのですが、その通りの情報が掲げられていますね。)
Content Negotiation + MultiViews 様々です。
Apache HTTP server が実装している次元は「MIMEタイプ」「言語」「文字符号化方法」「符号化方法」ですが、HTTPの Transparent Content Negotiation を規定している [RFC2295] が述べている次元は「MIME type」「Charset」「Language」「Features」となっています。この「Feature」としては、「HTMLのバージョン」「色深度」「出力メディア/サイズ」等が挙げられています。
こうしたFeatureの類に関しては、少なくともAsahiネットのように多種多様なコンテンツが作られ得るサイトにおいては、他の次元と同様にファイル名の拡張子を識別子に用いると収拾がつかなくなるんじゃないか? という気がします。まぁ現在は使えない次元なので心配する必要はないんですけれど。
わたくし、この「ページ」の画像ファイルに少々悪戯をほどこしました。「hoge.gazou.png」式に命名したPNG画像と「hoge.gazou.gif」式に命名したGIF画像を用意し、Content Negotiation でお好みの形式を選んでいただけるようにしたのです。
このMIMEタイプが変わっても同じURIが利用できるというのは、考えようによってはかなり便利です。
例えばWWWで流通させられるメジャーな画像形式が変わった場合でも、画像ファイルさえ差し換えてしまえばHTMLソースを変更することなく同じコンテンツを提供できます。また、Apacheの [Negotiation] の解説ページに書いてある例では、「今はHTMLファイルだけれど将来はSHTMLにしたい」なんていう場合でも「hoge.html」ではなく「hoge」をURIとしておけば "住所変更" の必要がありません(今なら「HTMLからXMLへ」でしょうか)。
1999年9月28日現在で利用可能な言語識別子は次の通りです。
識別子 | Language name | 言語名 |
---|---|---|
ar | Arabic | アラビア語 |
da | Danish | デンマーク語 |
de | German | ドイツ語 |
el | Greek | ギリシャ語 |
en | English | 英語 |
eo | Esperanto | エスペラント |
es | Spanish | スペイン語 |
fr | French | フランス語 |
he | Hebrew | ヘブライ語 |
hi | Hindi | ヒンディ語 |
id | Indonesian | インドネシア語 |
it | Italian | イタリア語 |
ja | Japanese | 日本語 |
ko | Korean | 韓国語/朝鮮語 |
nl | Dutch | オランダ語 |
pt | Portuguese | ポルトガル語 |
ru | Russian | ロシア語 |
sa | Sanskrit | 梵語 |
th | Thai | タイ語 |
ur | Urdu | ウルドゥ語 |
vi | Vietnamese | ベトナム語 |
zh | Chinese | 中国語 |
プライマリ識別子に不足がある方や、セカンダリ識別子が欲しい方(例えば北京の中国語zh_CNと台湾の中国語zh_TWを区別したいなど)は、BBSのsupport/html会議室で事務局に頼めば追加登録してくださるでしょう。