内容
この章でHTML文書は、コンピュータ上やインターネット上でどのようにして表現されるのかを述べます。
文書文字符号セットのセクションで、HTML文書の一部である抽象的な文字符号にはどのようなものがあるかのかを取り上げます。文字とは、"A"のようなラテン文字・"I"のようなシリリック文字・水を意味する中国字体などがあります。
文字符号コード化のセクションで、これら文字符号がファイル上やインターネット経由中にどの様に表現されるのかを述べます。制作者が文書に書きたいと思っても文字符号を直接書けない文字符号コードもありますので、どんな文字をも参照する文字符号参照という機序をHTMLは提供しています。
人の言語を網羅する文字符号は膨大なものですし、この文字符号の表現方法も様々ですので、十分な注意を払い、文書が世界中のブラウザで見えるようにしなければなりません。
共通性のためにSGMLは、HTMLを含むアプリケーションに文書文字符号セットを特定するよう要求しています。文書文字符号セットは次のものから構成されています：
HTMLを含むSGML文書は、一連の目録文字符号からなっています。コンピュータ・システムは、コード番号から文字符号を決めます。例えばASCII文字符号セットならコード番号65・66・67はそれぞれ 'A'・'B'・'C'になります。
ASCII文字符号セットではウェブのように世界的な情報の表現には不十分なので、 [ISO10646]で定義されている、より完全な文字符号Universal Character Set (UCS)をHTMLでは使います。この標準文字符号は、世界中で使われる多くのものを定義しています。
[ISO10646]で定義されている文字符号セットは、Unicode 2.0にと同じ（equivalent）で文字符号対文字符号です([UNICODE])。この二種類の標準は、新しい文字符号の追加にともなって随時更新され、改正はウェブ・サイトで確認しておいてください。この仕様書では、ISO/IEC-10646かUnicode参照を同じ文書文字符号セットに包含しています。しかしこのHTML仕様書では、 bidirectional text algorithm（双方向テキストアルゴリズム）といった別の問題をもUnicode仕様書に取り込んでいます。
しかしこの文書文字符号セットでは、ファイルやインターネット転送中の一連のバイトにコード化されたHTML文書を正しくブラウザが変換できるとは限りません。ブラウザは、 文字符号コード化を特定して文書文字符号をバイトに変換する方法も知らなくてはなりません。
character encodingとこの仕様書で言っているものは、他の仕様書では別な名前になっています（混乱を生みます）。しかし、この概念はインターネット上では同じです。プロトコール・ヘッダー・属性・文字符号コード化のパラメータ参照は同じ名称---- "charset" --で、 [IANA]登録からの同じ値を使っています（参照：リスト [CHARSETS])
"charset"パラメータは文字符号コード化を規定し、一連のバイトを一連の文字符号に変換する方法です。この変換方法はウェブ機構に適したものです：サーバーはHTML文書を一連のバイトとしてブラウザに送ります；ブラウザはそれを一連の文字符号として解釈します。この変換方法には、簡単な一体一対応のものから複雑な変換機構やアルゴリスムまでの幅があります。
簡単な一バイト一文字符号コード化の技術は、 [ISO10646]のような大きな文字符号レパートリーをテキスト列にするには十分ではありません。幾つか別のコード化もあり、 [ISO10646] entire character set (UCS-4など)というコード化もあります。
制作ツール（テキスト・エディターなど）は、自動的にコード化を選択するものもあり、選択基準はただシステム・ソフトで使われているものにするという便宜な選択をしているものです。ツールによっては、文書の文字符号を考えコード化を適時選択し、そのコード化は 正しくコード化correctly labeledされています。コード化から外れる文字符号でも、 character referencesによって表現できるものもあります。文書文字符号セットを参照していて、文字符号コード化を参照しているのではありません。
サーバーやプロキシーは、文字符号コードを変換（transcoding）転送して、ブラウザの要求に会わせます（参照： セクション14.2 [RFC2068],the "Accept-Charset" HTTP request header）。サーバーやプロキシーは、全ての文書文字符号セットをカバーする文字符号コード化した文書をおくるわけではありません。
ウェブ上で普通Commonly使われる文字符号コード化には、ISO-8859-1 ("Latin-1"といわれ：西欧言語)・ISO-8859-5 (Cyrillicをサポート)・SHIFT_JIS(日本語)・EUC-JP (別の日本語)・ UTF-8(ISO 10646)などがあります。文字符号コード化の名称は、大文字小文字の区別をしません（case-insensitive）ので、"SHIFT_JIS"・"Shift_JIS"・"shift_jis"は同じです。
この仕様書は、ブラウザがどの文字符号コード化をサポートすべきだと指定してはいまん。
適合ブラウザ（Conforming user agents）は、Unicodeに対応しどの文字符号コード化にも対応する文字符号にマッピングしなければなりません。
HTMLテキストがUTF-16(charset=UTF-16)で転送される場合、テキスト・データは [ISO10646]、セクション6.3 と[UNICODE]、 clause C3, page 3-1にそってネットワーク・バイト順 ("big-endian", high-order byte first)で転送されます。
更に適切な解釈をするために、UTF-16として転送される文書は、必ずZERO-WIDTH NON-BREAKING SPACE文字符号 （hexadecimal FEFF 所謂順序マーク・バイトByte Order Mark (BOM)）ではじまるよう勧告されています。逆転バイトの場合、割り当てられるべきではないと言う文字であるhexadecimal FFFEとなります。 表示代行手段は、テキストの最初のバイトとしてhexadecimal FFFEを受け取り、あとのテキストではバイトは逆転されなければならなことを知ることになります。
[ISO10646] (registered by IANA as ISO-10646-UTF-1)の UTF-1 転送フォーマットは、使うべきではありません。ISO-8859-8や双方向アルゴリスムに関する情報は、bidirectionality and character encodingセクションにあります。
サーバーは、どの文字符号コードが文書に適応されているのかを、どのようにして知るのでしょうか。文書の最初の数バイトを調べるものもあり、既知のファイルやコード化のデータベースをチェックするものもあります。最近のサーバーは、旧時代のサーバーよりも文字符号情報をコントロールできるようにウェブ・マスターに情報を与えています。ウェブ・マスターは、できる限り"charset"パラメータを送り出さなければなりませんが、間違った"charset"パラメータの文書を判断することはしません。
ブラウザは、どの文字符号コード化が使われているのかをどのようにして知るのでしょうか。サーバーが、このための情報を提供しなければなりません。文書の文字符号コード化をブラウザに伝える最も素直な方法は、HTTPプロトコールの"charset" parameter of the "Content-Type"ヘッダにある"charset"パラメータを使うことです([RFC2068]、セクション 3.4と14.18)。例えば、次のHTTPヘッダは文字符号コード化はEUC-JPです：
Content-Type: text/html; charset=EUC-JP
セクションconformance for the definition of text/htmlを参照のこと。
HTTPプロトコール（[RFC2068]、セクション3.7.1）は、文書に"charset"パラメータが"Content-Type"ヘッド領域にない場合初期値としてのISO-8859-1と見なします。この勧告は実際には役に立ってていないことがわかりました。サーバーによっては、送られるべき"charset"パラメータを許さないものもあり、このパラメーターを作らないものもあります。従って、"charset"パラメータの初期値をブラウザは推測できません。
サーバーや形式上の限界に会うと、HTML文書には文書の文字符号コード化情報がある部分を持っています。 META要素が、この情報をブラウザに提供します。
例えば、文書の文字符号コード化が"EUC-JP"であると特定するには、文書に以下のような META宣言を記載します：
<META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
META宣言は、基準になっているASCII文字符号の場合でもすべきです（少なくともMETA要素が調べらる迄)。 META宣言は、 HEAD要素の中でも出来るだけ早く見られる所に置くべきです。
HTTPプロトコールやMETA要素で文書の文字符号コード化情報を提供できない場合でも、HTMLでは幾つかの要素に charset属性を用意しています。これらを組み合わせて、ユーザーが資料を付け加えてきたらブラウザがその文字符号コード化を判読できるという機会の可能性に対応できます。
要約すると適合ブラウザは文書の文字符号コード化を決める際次の優先順位(高いものから低いものへ）に気付かなければなりません：
この優先順位に加えて、ブラウザは特別な指示やユーザーの設定を使う場合もあります。例えば、日本語テキスト用に使われる色々なコード化を区別するのに特別な指示をしています。また、ブラウザにユーザー指定のものやローカル文字符号コード化を初期値にしているものもあります。
ブラウザは、不正確な"charset"情報を上書きすることを許す機構を提供しています。しかし、ブラウザがこのような機構を提供するならばブラウザでなく、エディターが不正確な"charset"パラメータを持ったWebページを作成しないようにするためにのみ提供すべきでしょう。
注意： 特別なアプリケーションのために[ISO10646]以外の文字符号を参照する必要がでてきた場合には、文字符号は私的ゾーンのを使用し現在また将来の標準とコンフリクトを起こさないようにしておかなければならない。互換性の面からこれはすすめられません。
既存の文字符号コード化では、文書文字符号セットのすべての文字符号を表現できないかもしれません。そんなコード化やハードウェアー・ソフトウェアーがある種の文書文字符号を直接入力できない場合制作者はSGML 文字符号参照を使えます。文字符号参照は、文書文字符号セットの文字符号を入力する機序とは別の文字符号コード化です。
HTMLの文字符号参照には、二つの型があり：
コメント内にある文字符号参照は、意味をもちません；単にコメントにすぎません。
注意： HTMLでは、特別なinline imagesで、文字符号を表示するのに別の方法を提供しています。
注意： SGMLでは、文字符号参照直後の";" を削除できる場合があります(例えば、強制改行やタグ直前で）し、削除してはいけない場合(例：単語の途中)もあります。ブラウザがこれらの文字符号を表現する際に問題を起こさないようにするために、全てのケースで ";"を使うようにすることを強く薦めます。
数値参照は、文書文字符号セットの文字符号のコード（位置）番号を特定します。数値参照には、二つの型があります：
数値(数文字)参照の例をあげます。
注意 十六進法表現は、 [ISO8879]で定義されていませんが、 [WEBSGML]で記載されている様に、改訂されると思われます。 標準文字符号は十六進法を使いますので、この取り決めは非常に有用です。
文書文字符号セットの文字符号参照でより直観的な参照方法を提供するためにHTMLは、一組の文字符号実体参照を提供しています。文字符号実体参照は、シンボリックな名前を使ってコード（位置）番号を覚える必要がありません。例えば、å は上にリングが付いた小文字aを表わし、åで表わすより覚えやすいものです。
HTML 4.0では、文書文字符号セットの全文字符号について文字符号実体参照を定義していません。例えば、Cyrillic大文字"I"の文字符号実体参照はありません。HTML 4.0で定義されているものは、full list of character referencesを見て下さい。
文字符号実体参照は、大文字小文字の区別case-sensitiveがあります。Å（大文字A）は、å（小文字a）と違った文字を参照します。
特別な文字符号を代行するのによく使われるので、四つの文字符号実体参照について特別に述べておきます：
テキスト内に "<" と記載したい場合 "<"(ASCII decimal 60)を使います。開始タグと混同しないためです。同じように、文中の ">" (ASCII decimal 62)は ">" とします。囲われた属性値で使うと古いブラウザは終了タグと間違うことを避けるためです。
文字符号参照の始めと混同しないために、"&" の変わりに "&" (ASCII decimal 38) を使うべきです。また、属性値では "&" を使うべきです。というのは文字符号参照はCDATA属性値として許されているからです。
属性値を打ち消さないために、文字符号実体参照 """ を二重引用の代わりに使う制作者もいます。
ブラウザは、文書のすべての文字符号を意味あるものに 表示できないこともあります。例えば、ブラウザ側にある文字符号がない場合文字符号は、ブラウザ内部文字符号コード化で表現できない値をもっていることになります。
この様なケースでいろいろ異なったことが起るので、文書は対応ができなくなります。場合によってはundisplayable charactersはアプリケーションでなく現システムによって処理されます。いい対応がない場合、例えば特別なスクリプトや言語要求に仕立てるといったいい対応がない場合、ブラウザは次のように対応するよう薦めます：