参照とは？
|
文書文字集合の節では、どんな抽象文字がHTML文書を構成し得るかという話題を示す。ここで扱う文字には、ラテン文字の「A」やキリル文字の「И」、漢字の「水」などが含まれる。 文字符号化方法の節では、これらの文字が、ファイル中にある際やインターネット上を転送される際にどのように表現されるかという話題を示す。文字符号化方法の中には、著者が文書に含めたい文字のすべてを直接表現できないようなものもあるため、HTMLでは文字符号化方法とは異なる文字参照という機構を用いてあらゆる文字を参照できるようになっている。 人類の言語全体では膨大な数の文字が存在し、この文字を表現する方法も非常に多様であるため、世界中のユーザエージェントが文書を理解できるよう、細心の注意を払う必要がある。 HTML文書を含むどのSGML文書も、各々のレパートリにある文字の連鎖である。コンピュータシステムは符号位置により各文字を識別する。例えば、ASCII文字集合では、符号位置65、66、67は、各々「A」、「B」、「C」を指す。 Webのように地球規模の情報システムにおいては、ASCII文字集合は十分ではないので、HTMLでは国際符号化文字集合(UCS)と呼ばれる、より完璧を目指して[ISO10646]で定義された文字集合を使用する。この規格は世界中のコミュニティで使用されている何十万もの文字のレパートリを定義している。 [ISO10646]で定義された文字集合【の基本多言語面】はすべての文字がユニコード【2.0】([UNICODE])と等価である。 現在の本仕様書は、[ISO10646]は文書文字集合としての参照に用い、[UNICODE]はユニコードの双方向性テキストアルゴリズムへの参照として予約するに留まる。 しかし文書文字集合は、HTML文書の典型的な交換時において――すなわちファイル内部やネットワーク伝送の際にバイト列として符号化された状態で――、ユーザエージェントがHTML文書を正しく解釈できることを保証するには十分ではない。 ユーザエージェントは、文書を文字列からバイト列へと変換するのに使われた特定の文字符号化方法について理解する必要がある。 他の仕様では異なる名前で呼ばれているので、いくらか混乱の元になるかもしれない。しかしインターネット界では、概念自体は大筋で一致している。更に、通信プロトコルのヘッダ、属性、文字符号化方法を参照するパラメータの3つが、同じ「charset」という名称を共有し、同じ このcharsetパラメータは、バイト列から文字列への変換手段であるところの文字符号化方法についての、識別子である。 この変換は、サーバがHTML文書をユーザエージェントにバイト列として送り、ユーザエージェントがバイト列を文字列へと解釈するという、Webが働く仕組みに、自然に適合している。変換手段には、単純な1対1対応のものからスキームやアルゴリズムが切り替え式である複雑なものまで、幅広く存在する。 単純に1バイトが1文字に対応する符号化技術は、[ISO10646]と同等規模の文字レパートリから成るテキスト列には不充分である。符号化には、 [ISO10646]の部分集合を扱う各種符号化に加えて、UCS-4のように[ISO10646]全体を扱う符号化もある。 テキストエディタ等のオーサリングツールは、HTML文書を独自の選択により文字符号化方法へと符号化し得る。この選択は、使用中のシステムソフトウエアの規定に大きく依存する。 オーサリングツールは、符号化について正しく印をつける限りにおいて、文書中の文字の大半をカバーするような符号化を任意に選んでよい。 選択した符号化の範囲外となる文字については、文字参照で表現できる。文字参照は常に、文字符号化方法ではなく文書文字集合への参照を示すものである。 サーバやプロクシは、ユーザエージェントの要求に応じて文字符号化方法を変更しても良い。(これをコード変換と呼ぶ。[RFC2616]の14.2「Accept-CharsetのHTTP要求ヘッダ」を参照のこと。) 一般的にWebで使われる文字符号化方法には、ISO-8859-1 (「Latin-1」という名でも参照される、西欧言語の大半に使用できる)や、ISO-8859-5 (キリル諸語をサポートする)、SHIFT_JIS (日本語の符号化)、EUC-JP (別の、日本語の符号化)、UTF-8 (ISO 10646の符号化の1つで、各種の文字を可変長バイトで符号化する)などがある。 文字符号化方法の名称は、大文字小文字の別を問わない。従って例えば「SHIFT_JIS」も「Shift_JIS」も「shift_jis」も等価である。 本仕様は、ユーザエージェントがサポートする必要がある文字符号化方法が何であるかについて、強制しない。 仕様に適合するユーザエージェントは、認識できる文字符号化方法に含まれる全ての文字を、ISO 10646 に正確に合致させねばならない。(または、合致させるかのように動作しなければならない。) (charset=UTF-16)で伝送する場合、テキストデータはネットワークバイト順(「ビッグエンディアン」すなわち上位バイトが先)とする必要がある。これは NON-BREAKING SPACE文字(十六進のFEFF)――バイト順マーク(BOM)とも言う――で始まることが推奨される。バイト逆転の場合にはこれが、割り当てられないことが保証されている文字(十六進のFFFE)となる。これにより、テキストの最初のバイト組として十六進のFFFEを受信したユーザエージェントは、残りのテキストに関してバイトを逆転する必要があることが認識できる。 (IANAにISO-10646-UTF-1として登録されている)については、これを使ってはいけない。 サーバは、提供する文書についてどの文字符号化方法を適用すべきかを、どのように決めているのだろうか。文書の最初の数バイトをチェックするようなサーバもあれば、ファイル形式と符号化の関係についてデータベースと突合せを行うサーバもある。 最近のサーバの多くは、過去のサーバよりも、管理者がcharset設定ついてより多くの操作を行えるようになっている。 管理者はこれらの機構を用いて可能な限り常にcharsetパラメータを送り出すようにしなければならないが、誤ったcharsetパラメータ値によって文書を識別させてしまわないよう注意を払う必要がある。 ユーザエージェントは、使われている文字符号化方法が何であるかを、どのようにして知るのか。サーバがこれを知らせる必要がある。サーバがユーザエージェントに文書の文字符号化方法について情報提供する最も直截な方法は、HTTPプロトコルの 実際のところは、この勧告は役立たないことが証明されている。なぜならサーバの中にはcharsetパラメータを送信できないものもあれば、パラメータを送らないよう設定されているものもあるのからだ。従って、ユーザエージェントは、charsetパラメータとして如何なる値も仮定してはいけない。 サーバへの指示あるいは設定上の制限を示すため、HTML文書は自身の文字符号化方法に関する明示的な情報を含んでもよい。ユーザエージェントに文字符号化方法の情報を伝える目的には、 META宣言は、少なくともそのMETA要素がパースされるまでの間はASCIIの範囲内のバイト値がASCIIと同じ文字を表すような文字符号化方法が使われている場合にのみ用いることができる。 これらの機構を組み合わせることで、著者は、ユーザがリソースを取得する際にユーザエージェントが文字符号化方法を識別できる可能性を増やせる。 この優先順リストに加えて、ユーザエージェントは、経験的判定法やユーザの設定を用いてもよい。例えば、多くのユーザエージェントは日本語テキストの各種符号化の識別に経験的判定法を用いている。また、ユーザエージェントは一般に、文字符号化方法の情報が得られない場合に利用するローカルなデフォルト文字符号化方法を、ユーザが設定できるようになっている。 ユーザエージェントは、誤ったcharset情報をユーザが上書きできるような機能を備えてもよい。ただし、この機能はページを読む際にだけ提供することとし、著述の際には機能しないようにする必要がある。これは誤ったcharsetパラメータを持つWebページの生成を防ぐためである。 もし仮に、特定用途のために[ISO10646]にない文字を参照する必要がある場合、そうした文字は、現在の規格及び将来の規格との衝突を避けるため、私用ゾーンに割り当てる必要がある。 ある所与の文字符号化方法が、文書文字集合の全ての文字を表現できるとは限らない。こうした符号化を利用する際や、文書中の文字について直接入力できないよう設定されているハードウエアやソフトウエアを使っている場合、著者はSGML文字参照を用いてよい。 HTMLには文字データを表現するための他の手法も用意されている。特にインライン画像が、これにあたる。 SGMLでは、改行文字やタグの直前に文字参照がある際など、文字参照の末尾の「;」を省略できる場合がある。逆に単語の途中の場合などのように省略できない場合もある。 本仕様は、如何なる場合も「;」を用いて、セミコロンが必要なユーザエージェントで問題が起きないようにするよう、強く勧める。 å (十進)は、ノルウエー語等で使われる、「上に小さい円がついた小文字a」を表現する。 HTML 4 では、文書文字集合の全ての文字について文字実体参照を定義することはしない。例えば、キリル大文字「И」の文字実体参照はない。HTML 4での定義は全文字実体参照リストを参照のこと。 従って、「Å」(リングつき大文字Aの参照)は、「å」(リングつき小文字aの参照)とは異なる文字を参照する。 テキスト中に「<」記号を記したい場合、著者は「<」(ASCII十進60)を用い、タグの冒頭――開始タグの開始区切り子――と誤解される可能性を回避するべきである。同様に、テキスト中に「>」記号を記したい場合、仮に二重引用符で囲った属性値としてであっても、著者は「>」を直接記すのではなく「>」(ASCII十進62)を用い、古いユーザエージェントがこれをタグの末尾――タグの終了区切り子――と誤解してしまう問題を、回避すべきである。 また、著者は、「&」の代わりに「&」(ASCII十進38)を用い、文字参照の冒頭――文字実体参照の開始区切り子――と誤解されるのを避けるべきである。 CDATA型の属性値には文字参照が出現できるので、著者は属性値においても「&」を用いる必要がある。 二重引用符が属性値の区切り子にもなり得るため、二重引用符のインスタンスを符号化して「"」を用いる著者もあろう。 例えば、適切なフォントが得られない場合や、ユーザエージェントの内部コードでは表現できない値を持つ文字に出くわした場合などがこれに当たる。 実装に依存するため、表示できない文字はアプリケーション自体ではなく基盤となるディスプレイシステムによって処理される。 特定の表記系や言語の要求などに見合った、より洗練された動作が存在しない場合、本仕様はユーザエージェントに対し次の動作を勧める。 欠落した文字を数値で表現する場合は、十進ではなく、十六進形式で示す。文字集合の規格で十六進形式が使われるからである。 |
[ 94] HTML Document Representation (ja)
[引用サイト] http://www.asahi-net.or.jp/~sd5a-ucd/rec-html401j/charset.html
