5 HTML文書の表現

目次

  1. 文書文字集合
  2. 文字符号化方法
    1. 符号化の選択
    2. 文字符号化方法の指定
  3. 文字参照
    1. 数値文字参照
    2. 文字実体参照
  4. 表示できない文字

この章では、HTML文書がコンピュータ内部やインターネット上でどのように表現されるかを記す。

文書文字集合の節では、どんな抽象文字がHTML文書を構成し得るかという話題を示す。ここで扱う文字には、ラテン文字の「A」やキリル文字の「И」、漢字の「水」などが含まれる。

文字符号化方法の節では、これらの文字が、ファイル中にある際やインターネット上を転送される際にどのように表現されるかという話題を示す。文字符号化方法の中には、著者が文書に含めたい文字のすべてを直接表現できないようなものもあるため、HTMLでは文字符号化方法とは異なる文字参照という機構を用いてあらゆる文字を参照できるようになっている。

人類の言語全体では膨大な数の文字が存在し、この文字を表現する方法も非常に多様であるため、世界中のユーザエージェントが文書を理解できるよう、細心の注意を払う必要がある。

5.1 文書文字集合

相互運用性を増すため、SGML規定はHTMLを含むどのSGML応用系に対しても、 文書文字集合を定義するよう求めている。文書文字集合は、以下から成り立つ。

HTML文書を含むどのSGML文書も、各々のレパートリにある文字の連鎖である。コンピュータシステムは符号位置により各文字を識別する。例えば、ASCII文字集合では、符号位置65、66、67は、各々「A」、「B」、「C」を指す。

Webのように地球規模の情報システムにおいては、ASCII文字集合は十分ではないので、HTMLでは国際符号化文字集合(UCS)と呼ばれる、より完璧を目指して[ISO10646]で定義された文字集合を使用する。この規格は世界中のコミュニティで使用されている何十万もの文字のレパートリを定義している。

[ISO10646]で定義された文字集合【の基本多言語面】はすべての文字がユニコード【2.0】([UNICODE])と等価である。 両規格は日々新しい文字で更新されているので、Webサイトで改訂情報の確認が必要である。 現在の本仕様書は、[ISO10646]は文書文字集合としての参照に用い、[UNICODE]はユニコードの双方向性テキストアルゴリズムへの参照として予約するに留まる。

しかし文書文字集合は、HTML文書の典型的な交換時において――すなわちファイル内部やネットワーク伝送の際にバイト列として符号化された状態で――、ユーザエージェントがHTML文書を正しく解釈できることを保証するには十分ではない。 ユーザエージェントは、文書を文字列からバイト列へと変換するのに使われた特定の文字符号化方法について理解する必要がある。

5.2 文字符号化方法

本仕様が文字符号化方法と呼ぶものは、 他の仕様では異なる名前で呼ばれているので、いくらか混乱の元になるかもしれない。しかしインターネット界では、概念自体は大筋で一致している。更に、通信プロトコルのヘッダ、属性、文字符号化方法を参照するパラメータの3つが、同じ「charset」という名称を共有し、同じ [IANA]登録値を使用する。(登録の完全リストについては[CHARSETS]を参照のこと。)

このcharsetパラメータは、バイト列から文字列への変換手段であるところの文字符号化方法についての、識別子である。 この変換は、サーバがHTML文書をユーザエージェントにバイト列として送り、ユーザエージェントがバイト列を文字列へと解釈するという、Webが働く仕組みに、自然に適合している。変換手段には、単純な1対1対応のものからスキームやアルゴリズムが切り替え式である複雑なものまで、幅広く存在する。

単純に1バイトが1文字に対応する符号化技術は、[ISO10646]と同等規模の文字レパートリから成るテキスト列には不充分である。符号化には、 [ISO10646]の部分集合を扱う各種符号化に加えて、UCS-4のように[ISO10646]全体を扱う符号化もある。

5.2.1 符号化の選択

テキストエディタ等のオーサリングツールは、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 に正確に合致させねばならない。(または、合致させるかのように動作しなければならない。)

特定の符号化に関する注意 

HTMLテキストをUTF-16 (charset=UTF-16)で伝送する場合、テキストデータはネットワークバイト順(「ビッグエンディアン」すなわち上位バイトが先)とする必要がある。これは [ISO10646]の6.3及び[UNICODE]C3の3-1ページに従うものである。

更に、適切な解釈の可能性を最大化するため、UTF-16で伝送する文書は常にZERO-WIDTH NON-BREAKING SPACE文字(十六進のFEFF)――バイト順マーク(BOM)とも言う――で始まることが推奨される。バイト逆転の場合にはこれが、割り当てられないことが保証されている文字(十六進のFFFE)となる。これにより、テキストの最初のバイト組として十六進のFFFEを受信したユーザエージェントは、残りのテキストに関してバイトを逆転する必要があることが認識できる。

[ISO10646]の変換形式 UTF-1 (IANAにISO-10646-UTF-1として登録されている)については、これを使ってはいけない。 ISO 8859-8及び双方向アルゴリズムについては、 双方向性と文字符号化方法に関する注意を参照のこと。

5.2.2 文字符号化方法の指定

サーバは、提供する文書についてどの文字符号化方法を適用すべきかを、どのように決めているのだろうか。文書の最初の数バイトをチェックするようなサーバもあれば、ファイル形式と符号化の関係についてデータベースと突合せを行うサーバもある。 最近のサーバの多くは、過去のサーバよりも、管理者がcharset設定ついてより多くの操作を行えるようになっている。 管理者はこれらの機構を用いて可能な限り常にcharsetパラメータを送り出すようにしなければならないが、誤ったcharsetパラメータ値によって文書を識別させてしまわないよう注意を払う必要がある。

ユーザエージェントは、使われている文字符号化方法が何であるかを、どのようにして知るのか。サーバがこれを知らせる必要がある。サーバがユーザエージェントに文書の文字符号化方法について情報提供する最も直截な方法は、HTTPプロトコルの Content-Typeヘッダフィールドでcharsetパラメータを使うことである。 ([RFC2616]の3.4と14.17を参照のこと。) 例えば、次のHTTPヘッダは、文字符号化方法がEUC-JPであることを示している。

Content-Type: text/html; charset=EUC-JP

text/htmlの定義については、適合条件の項を参照のこと。

HTTPプロトコル([RFC2616]の3.7.1)は、Content-Typeヘッダフィールドにcharsetパラメータが存在しない場合のデフォルト文字符号化方法をISO-8859-1とすると述べている。 実際のところは、この勧告は役立たないことが証明されている。なぜならサーバの中にはcharsetパラメータを送信できないものもあれば、パラメータを送らないよう設定されているものもあるのからだ。従って、ユーザエージェントは、charsetパラメータとして如何なる値も仮定してはいけない。

サーバへの指示あるいは設定上の制限を示すため、HTML文書は自身の文字符号化方法に関する明示的な情報を含んでもよい。ユーザエージェントに文字符号化方法の情報を伝える目的には、 META要素を使うことができる。

例えば、当該文書の文字符号化方法をEUC-JPと指定するには、 文書が次の META宣言を含む必要がある。

<META http-equiv="Content-Type" content="text/html; charset=EUC-JP">

META宣言は、少なくともそのMETA要素がパースされるまでの間はASCIIの範囲内のバイト値がASCIIと同じ文字を表すような文字符号化方法が使われている場合にのみ用いることができる。 META宣言は、 HEAD要素の、可能な限り先頭の方に現れねばならない。

HTTPプロトコルと META要素のどちらも当該文書の文字符号化方法に関する情報を提供していない場合でも、HTMLには charset属性値を取る要素が幾つかある。 これらの機構を組み合わせることで、著者は、ユーザがリソースを取得する際にユーザエージェントが文字符号化方法を識別できる可能性を増やせる。

以上を要約すると、本仕様に適合するユーザエージェントは、文書の文字符号化方法を決定する場合に次の 優先順位を守らねばならないということである。優先順位の高いものから低いもの順に以下の通り。

  1. HTTPヘッダのContent-Typeフィールドの、charsetパラメータ。
  2. META要素で、http-equiv属性値がContent-Typeかつvalue属性の値にcharset情報があるもの。
  3. 外部リソースを指している要素に設定されているcharset属性値。

この優先順リストに加えて、ユーザエージェントは、経験的判定法やユーザの設定を用いてもよい。例えば、多くのユーザエージェントは日本語テキストの各種符号化の識別に経験的判定法を用いている。また、ユーザエージェントは一般に、文字符号化方法の情報が得られない場合に利用するローカルなデフォルト文字符号化方法を、ユーザが設定できるようになっている。

ユーザエージェントは、誤ったcharset情報をユーザが上書きできるような機能を備えてもよい。ただし、この機能はページを読む際にだけ提供することとし、著述の際には機能しないようにする必要がある。これは誤ったcharsetパラメータを持つWebページの生成を防ぐためである。

注意。 もし仮に、特定用途のために[ISO10646]にない文字を参照する必要がある場合、そうした文字は、現在の規格及び将来の規格との衝突を避けるため、私用ゾーンに割り当てる必要がある。 しかしながら、ポータビリティの観点から、私用領域の利用は極力避けるべきである。

5.3 文字参照

ある所与の文字符号化方法が、文書文字集合の全ての文字を表現できるとは限らない。こうした符号化を利用する際や、文書中の文字について直接入力できないよう設定されているハードウエアやソフトウエアを使っている場合、著者はSGML文字参照を用いてよい。 文字参照とは、文字符号化方法に依存せずに文書文字集合の全ての文字を示す手法である。

HTMLの文字参照には、次の2つの形式がある。

コメント中の文字参照は、特別な意味を持たず、単なるコメントデータであるに過ぎない。

注意。 HTMLには文字データを表現するための他の手法も用意されている。特にインライン画像が、これにあたる

注意。 SGMLでは、改行文字やタグの直前に文字参照がある際など、文字参照の末尾の「;」を省略できる場合がある。逆に単語の途中の場合などのように省略できない場合もある。 本仕様は、如何なる場合も「;」を用いて、セミコロンが必要なユーザエージェントで問題が起きないようにするよう、強く勧める

5.3.1 数値文字参照

数値文字参照は、文書文字集合における当該文字の 符合位置を指定するものである。数値文字参照には、次の2つの形式がある。

数値文字参照の例を幾つか挙げる。

注意。 十六進による表現は[ISO8879]では定義されていないが、 [WEBSGML]の記述に見られるように、改訂が望まれている。 文字に関する規格は一般に十六進の表現を行うため、十六進の利用は非常に有用である

5.3.2 文字実体参照

著者がより直感的に文字の参照を行えるよう、HTMLでは文字実体参照を使えるようになっている。 文字実体参照ではシンボリックな名称を用いるため、著者は符号位置の数値を覚える必要がない。 例えば、文字実体参照「&aring;」は「上にリングがついた小文字のa」を参照するが、「&aring;」は「&#229;」よりも覚えやすい。

HTML 4 では、文書文字集合の全ての文字について文字実体参照を定義することはしない。例えば、キリル大文字「И」の文字実体参照はない。HTML 4での定義は全文字実体参照リストを参照のこと。

文字実体参照は、 大文字小文字を区別する。 従って、「&Aring;」(リングつき大文字Aの参照)は、「&aring;」(リングつき小文字aの参照)とは異なる文字を参照する。

特定の文字をエスケープするために頻繁に用いる4つの文字実体参照を、ここに特記しておく。

テキスト中に「<」記号を記したい場合、著者は「&lt;」(ASCII十進60)を用い、タグの冒頭――開始タグの開始区切り子――と誤解される可能性を回避するべきである。同様に、テキスト中に「>」記号を記したい場合、仮に二重引用符で囲った属性値としてであっても、著者は「>」を直接記すのではなく「&gt;」(ASCII十進62)を用い、古いユーザエージェントがこれをタグの末尾――タグの終了区切り子――と誤解してしまう問題を、回避すべきである。

また、著者は、「&」の代わりに「&amp;」(ASCII十進38)を用い、文字参照の冒頭――文字実体参照の開始区切り子――と誤解されるのを避けるべきである。 CDATA型の属性値には文字参照が出現できるので、著者は属性値においても「&amp;」を用いる必要がある。

二重引用符が属性値の区切り子にもなり得るため、二重引用符のインスタンスを符号化して「&quot;」を用いる著者もあろう。

5.4 表示できない文字

文書中の全ての文字を有意に レンダリングすることができないユーザエージェントもあり得る。 例えば、適切なフォントが得られない場合や、ユーザエージェントの内部コードでは表現できない値を持つ文字に出くわした場合などがこれに当たる。

こうしたケースで為され得ることは多岐に渡るため、本仕様は特定の動作を定めない。 実装に依存するため、表示できない文字はアプリケーション自体ではなく基盤となるディスプレイシステムによって処理される。 特定の表記系や言語の要求などに見合った、より洗練された動作が存在しない場合、本仕様はユーザエージェントに対し次の動作を勧める。

  1. 欠落したリソースがあることを、明確かつ控えめに、ユーザに気づかせる仕組みを用意する。
  2. 欠落した文字を数値で表現する場合は、十進ではなく、十六進形式で示す。文字集合の規格で十六進形式が使われるからである。

訳者代表: 内田明 (UCHIDA Akira)
email: uchida@happy.email.ne.jp