この章では、HTML文書がコンピュータ内部やインターネット上でどのように取り扱われるかを記します。
文書文字集合の節では、実際にどんな文字がHTML文書中に使用できるのかを説明します。例えば、ラテン文字の「A」やキリル文字の「I」、そして「みず<water>」を意味する漢字などが題材となります。
符号化方法に関する節では、HTML文書が実際のファイルとして保存される際やインターネット上を伝送される際に、文書内の文字がどのように扱われるのかを記します。特定の符号化方法では直接的に記述できない文字をHTML文書中で扱う方法文字参照についても記します。
人類が使用する文字は大変膨大であり、またその符号化方法にも様々な種類があるため、世界中どこででも理解可能であるよう、適切な記述を行う必要があります。
相互運用性を保証するため、SGML規格は（HTMLを含めて）どのSGMLアプリケーションに対しても文書文字集合の定義づけを要求しています。文書文字集合とは以下から成り立っています。
どのSGML文書も（HTML文書を含め）、目録に記載されている文字で書かれます。コンピュータは各々の文字をコードに置き換えて把握します。例えば、「ASCII」文字集合では、十進数のコード「65」「66」「67」は、それぞれ「A」「B」「C」の文字を意味します。
Webのように地球規模の情報システムにおいては、ASCII文字集合は十分ではないため、HTMLでは、Universal Character Set (UCS)と呼ばれる、より完璧を目指して [ISO10646]で定義された文字集合が採用されています。この規格は世界中の様々な文化圏で使われている何十万もの文字を掲載した文字目録の実現方法を定めたものです。
この[ISO10646]で定められた文字集合 [の16ビット基本多言語面] は、全ての文字がUnicode 2.0 ([UNICODE]）と等価になっています。ただし両規格は日々刷新されていますので、Webサイトにて確認が必要です。この仕様書が参照した段階では「ISO/IEC-10646」[の基本多言語面] と「Unicode」はどちらを見ても同じ文書文字集合を実現できます。けれども、第8章で述べる左右の書字方向を混在した文書の実現方法など、文字集合以外の観点も含めて、この仕様書は「Unicode」を参照することとしました。
けれども、文書文字集合が定義されてさえいれば、ユーザエージェントが、バイト列として保存されネットワークで伝送されるHTML文書を正確に再生可能であるとは言えません。バイト列として存在するHTML文書を再生するには、文字列とバイト列との変換規則である符号化方法についても理解していなければならないからです。
ここで符号化方法と呼ぶものは、他の仕様では別の名前で呼ばれています（ので、混乱を来す元にもなってしまっています）。けれども、インターネットの世界で指し示そうとする概念自体は大筋で一致しています。そして、「符号化方法（Character encodings）」を指し示す言葉として、通信手段（プロトコル）のヘッダ、属性、変数が、同じ名前「charset」を採用し、その値として[IANA]に登録されている書式を採用しています。（属性値の完全版リストは[CHARSETS]を参照のこと。）
「charset」というパラメータは、文字列とバイト列の変換規則である符号化方法を特定するためのものです。この変換はWeb上の文書交換の際に自然に行われています。サーバはユーザエージェントへとHTML文書データをバイト列として送信し、ユーザエージェントはそれを文字列として解釈していきます。変換の手順に関しては、逐語訳的に行われるものから複数の方法を切り替えていくようなものまで、幅広く存在します。
単純に1文字1バイトの符号化を行う技術は[ISO10646]と同等サイズのレパートリを扱うには不十分です。[ISO10646]全体を扱う符号化方法（例えば「UCS-4」）の他に、その部分集合である文字集合を扱う符号化方法にも様々な符号化方法が存在します。
オーサリングツール（例えば単なるテキストエディタなど）は、HTML文書を、ツール側の都合で符号化しますし、その都合とはシステムソフトウエア [OS] に大きく依存します。オーサリングツールは、その符号化方法を正しく記す限りにおいて、当該文書に含まれるほとんどの文字をカバーするような符号化方法を任意に選べます。その符号化方法では直接的には記述できない文字があった場合は、文字参照が使われます。文字参照とは、文書文字集合中の文字を参照する方法のことで、文字符号化のことではありません。
サーバやプロクシは、ユーザ側のソフトの要求に応じて、文字コードを変えること（コード変換と呼ばれる）もできます。[RFC2068]の第14.2項「HTTPヘッダ」を参照のこと。）サーバもプロクシも、全ての文字集合をカバーする符号化方法をサポートする必要はありません。
Webで広く使われている文字符号は「ISO-8859-1」（「Latin-1」とも呼ばれ、多くの西欧諸語を記述できる）や、「ISO-8859-5」（キリル文字をサポートする）、「SHIFT_JIS」（日本語用の符号）、「EUC-JP」（日本語用の、別の符号）、そして「UTF-8」（ISO10646用の符号で、可変長ビットによるもの）などです。文字符号の記名方法は大文字小文字の区別を行いませんので、「SHIFT_JIS」という記述も「Shift_JIS」も「shift_jis」も同じものを表します。
この仕様書は、ユーザエージェントに対しどの文字符号をサポートする必要があるかを命じるものではありません。
HTML 4.0準拠ユーザエージェントは、元文書の符号が何であれ、そこで記されている文字がUnicodeに含まれる文字であれば、全ての文字を判別できなければなりません。（あるいは、そうであるかのように動作しなければなりません。）
UTF-16で符号化されたHTML文書（「charset="UTF-16"」の指定があるもの）を扱う場合、[ISO10646]の第6章3節並びに[UNICODE]第C3条3-1ページに従って、各バイトは伝送されてくる順序通りに（「ビッグエンディアン」すなわち上位バイトを先に）扱ってください
さらにまた、「UTF-16」で符号化するなら、正確な解釈を保証するために、目印として「バイト順マーク (BOM) 」と呼称されたりする「ZERO-WIDTH NON-BREAKING SPACE」であるところの十六進コードFEFFの文字を先頭に置くことが推奨されます。そうすれば、バイト解釈の順番がずれている場合に、先頭文字が「FFFE」という無意味化されているコードとなって、ずれが発生していることが判明します。
[ISO10646]の付録として用意されている変換符号化方法UTF-1 （IANAでの登録名「ISO-10646-UTF-1」）の使用は、避けるべきです。制御コード等との衝突を起こす可能性があるからです。「ISO-8859-8」と「双方向書字」に関する情報は、8章2節4項の双方向書字と符号化方法との関係に関する注意をご覧下さい。
HTML文書を扱うサーバは、文書の符号化方法をどのように見分けているのでしょうか。サーバによっては、文書の最初の数バイトだけチェックしたり、もっと丁寧にバイト列判定用の辞書とつきあわせたりして符号化方法を判定しているでしょう。多くの現代的なサーバは、古くさいサーバより符号化方法の選定に関してよりきめ細かい操作が可能になっています。管理者の方は、できる限り「charset」パラメータの値を送信するようにして下さい。ただし間違った「charset」パラメータの値で同定してしまわないようにご注意ください。
ユーザエージェントによる符号化方法の見分け方はどうでしょうか。サーバが符号化方法に関する情報を届けるべきなのです。その最も簡単な方法は、HTTPヘッダ部でContent-Typeの値として「charset」の情報を提供することです。（[RFC2068]の第3章4節と第14章18節を参照のこと。）例えば、下記のようなHTTPヘッダは、符号化方法が「EUC-JP」であることを表しています。
Content-Type: text/html; charset=EUC-JP
上記「text/html」の定義については、前章: 準拠状態をご覧下さい。
HTTPプロトコル（[RFC2068]、3.7.1項）では、HTTPヘッダの「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宣言を用いるのは、当該の符号化方法がASCII文字をASCIIコードと同じコードで記すような場合に限定する必要があります。（少なくともMETA要素が解釈されると仮定して。）META宣言は、HEAD要素の、可能な限り先頭行の方に記述されねばなりません。
当該文書の符号化方法についてHTTPヘッダにもMETA要素にも記載がない場合、符号化方法の確認方法として、幾つかの要素に記載されるかもしれないcharset属性を参照するという手があります。こうした複数の手段を組み合わせて用いることで、ユーザエージェントに正しい符号化方法の情報を理解させる可能性が、より確実性を増すでしょう。
HTML 4.0準拠ユーザエージェントは、次の優先順で符号化方法を判定する必要があります。
この優先順位に加えて、実際のユーザエージェントでは、経験的判定方法と、ユーザによる設定が利用可能でしょう。例えば、多くのユーザエージェントは、日本語で書かれた文章に対して用いられる何種類もの符号化方法を識別するための経験的手法を実装しています。さらにユーザ自身の手で符号化方法を設定できるようにもなっています。
中には、間違った「charset」情報をユーザの手で上書きできるようになっているようなユーザエージェントもあるでしょう。けれども、これは読み込みの場合のみに限定すべき機能であって、文書の作成時には、間違った「charset」値を持つWebページを流布させぬよう、上書きを避けられるように設計してあるべきです。
注。 あるアプリケーションが、もし[ISO10646]に規定されていない文字を参照する必要が生じた場合は、現在の規格や将来の規格との衝突を避けるため、その文字はユーザ利用コード領域に割り当てられねばなりません。けれども、文書の流通性を考えると、ユーザ領域の使用は極力避けたいところです。
自分の環境で利用可能な符号化方法では文書文字集合の全ての文字を表現することができない場合もあるでしょう。またハードウエアやソフトウエアの能力による制限から、特定の文字を文書中に直接的には記述できないという場合もあるでしょう。こうした場合には、SGML$B<0文字参照を利用できます。文字参照は、符号化方法に依存せずに文書文字集合に含まれる文字全てを利用可能にする仕掛けです。
HTMLの文字参照には、次の2つの形式が用意されています。
コメント中の文字参照は、コメントデータであること以外に何等の特別な意味を持ちません。
注。 HTMLで文字を表現する他の方法は、特にインライン画像として表すというものです。
注。SGMLでは文字参照の際に「;」を省略できる場合があります。（例えば改行の直前であるとかタグの直前であるとか。）けれども（文の途中など）他の場合には省略できません。ユーザエージェントの混乱を招かぬよう、常に「;」は記しておくように、強く求めます。
数値文字参照は、文書文字集合に関してコード位置を指し示すものです。数値文字参照には、2つの形式が用意されています。
数値文字参照の例を幾つか挙げます。
注。 十六進法の数値文字参照は[ISO8879]では定義されておりませんが、同規格は[WEBSGML]の記述によると改定される見通しとなっています。多くの文字規格が十六進法を用いているので、十六進法での数値文字参照の利便性は高いでしょう。
HTMLでは、より直感的に理解しやすい文字参照の方法として、文字実体参照が利用できます。文字実体参照は、文字・記号の名前から取った符号名による文字参照なので、いちいち数値コード位置を記憶する必要がなくなります。例えば、「å」は小文字の「aリング」を参照するものですが、同じ文字の数値文字参照「å」より覚えやすいでしょう。
HTML 4.0は、文書文字集合のすべての文字に対して文字実体参照を提供しているわけではありません。例えば、キリル文字の大文字の I に対する文字実体参照はありません。別途文字実体参照一覧にてご確認下さい。
文字実体参照は、大文字小文字を区別します。従って、「Å」と「å」は違う文字を参照します（各々大文字の「Aリング」と小文字の「aリング」を参照する）。
マークアップ記号ではなく文字として使用するために頻繁に利用される4つの文字実体参照を列記しておきます。
もし本文中で「<」記号（ASCII十進数コード「60」）を表したい場合には、タグの開始記号だと解釈される可能性を排除するために、「<」というように記述せねばなりません。また、「>」記号（ASCII十進数コード「62$B!W!K$rFs=E0zMQId$G0O$C$?B0@-CM$N0lIt$H$7$F;H$$$?$$>l9g$K$b!"8E$$%f!<%6%(!<%8%'%s%H$,%?%0$N=*N;5-9f$H4*0c$$$7$F$7$^$&$3$H$rHr$1$k$?$a$K!"!V>」と記す必要があります。
文字参照の開始記号として「&」が使われるため、本文中でアンパサンド（ASCII十進数コード「38」）を表すには「&」と書く必要があり、また値の形式としてCDATAを認める属性値の記述にも、「&」を用いる必要があります。
また、二重引用符「"」が属性値の区切り記号として使用されるために、代替手段として「"」という文字参照を利用することもできます。
ユーザエージェントは、文書中の全ての文字を表示できるとは限りません。必要なフォントがなかったり、実装されていない符号化方法で指定されていたりする場合があるからです。
上記のような事例には様々な事情が絡み合っているため、この仕様書では何等明確な指針を立てるものではありません。実装に際して表示できない文字の問題が発生するのは、そのアプリケーション単独の事情ではなくアプリケーションを走らせる環境込みの問題だからです。ある特定の表記法や言語に合わせて繕うような方法以上に洗練された手法がないため、本仕様ではユーザエージェントに対し次の動作を推奨します。