コンピュータ及びインタネットにおいてHTML文書がどのように表現されるかを, 5.に示す。
文書文字集合の節は，どの抽象的な文字がHTML文書の一部になり得るかという課題に言及する。文字は, ラテン文字の"A", キリル文字の"I", "水"を意味する漢字などを含む。
文字符号化の節は，これらの文字がファイルの中でどのように表現され, いつインタネット上に転送され得るかという課題に言及する。 文書作成者が文書に入れたいと望むすべての文字を直接に表現できない文字符号化もあるため，HTMLは, どのような文字をも参照するために, 文字参照と呼ぶ他の機構を提供する。
自然言語全体では，非常に多くの文字が存在し，それらの文字を表現する極めて多様な方法が存在するため，世界中の利用者エージェントによって文書を理解可能にする適切な配慮がなされなければならない。
相互運用性を促進するために，SGMLは，HTMLを含む各アプリケーションがその文書文字集合を指定することを要求する。 文書文字集合は, 次から成る。
各HTML文書を含む各SGML文書は，レパートリからの文字のシーケンスとなる。コンピュータシステムは，符号位置によって各文字を識別する。例えば，ASCII文字集合では, 符号位置65，66及び67はそれぞれ'A', 'B'及び'C'を参照する。
ASCII文字集合は, ウェブなどの大域的情報システムには, 十分ではない。そこでHTMLは, もっと完全な文字集合を使用する。これは, 国際符号化文字集合(Universal Character Set，以降UCS) と呼ばれ， [ISO10646]で規定される。この規格は, 全世界の社会で使われる数多くの文字のレパートリを規定する。
[ISO10646] が規定する文字集合は，Unicode 2.0と文字毎に 等価になっている。 ([UNICODE]参照)これらの規格はいずれも，時宜を得て新しい文字で更新されており，その修正を各ウェブサイトで考慮することが望ましい。 現在の規定では，ISO/IEC 10646の参照も, Unicodeへの参照も，同じ文書文字集合を意味する。しかし，HTML規定は, 双方向テキストアルゴリズムなどの他の課題についてのUnicode規定をも参照する。
しかし，HTML文書が典型的に交換されるとき, つまり，HTML文書がファイル内又はネットワーク伝送においてバイトのシーケンスとして符号化されるとき, 文書文字集合は, 利用者エージェントに対して正確にHTML文書を解釈させるには十分でない。 利用者エージェントは，文書文字列をバイト列に変換するために使用された特定の文字符号化をも知らなければならない。
この標準情報(TR)でいう文字符号化は，他の規定では別の名前で知られている。そのため多少の混乱が起きるかもしれない。しかし，その概念は, インタネットの環境では概ね異ることはない。文字符号化を参照するプロトコルヘッダ，属性及びパラメタは, 同一の名前"charset"を共有し, [IANA]レジストリからの同じ値(完全リストについては, [CHARSETS] を参照のこと。)を使用する。
"charset"パラメタは，文字符号化を識別し，それは, バイト列を文字列に変換する手段となる。この変換は，ウェブの活動の方式, つまりサーバがバイト列としてHTML文書を利用者エージェントに送信し，利用者エージェントがそれを文字列として解釈することの方式，に自然に適合する。変換方法は，簡単な1対1対応から複雑な方式切替え又はアルゴリズム切替えまで及ぶことができる。
簡単な1文字当たり1バイトの符号化技術は, [ISO10646]と同じくらい大きな文字レパートリに及ぶテキスト文字列には十分ではない。USC-4などの完全文字集合の符号化に加えて，[ISO10646]の一部に関する幾つかの異なる符号化が存在する。
テキストエディタなどの文書作成ツールは，それが選んだ文字符号化でHTML文書を符号化してよい。その選択は, システムソフトウェアが使用する規約に大きく依存する。これらのツールは，符号化が正確にラベル付けされれば，文書中に含まれる文字のほとんどをカバーするどのような便利な符号化をも使ってよい。この符号化の範囲外にある特定文字は, 文字参照によって表現してもよい。これらは常に文字符号化ではなく, 文書文字集合を参照する。
サーバ及びプロキシは，利用者エージェントの要求([RFC2068]の14.2, "Accept-Charset"HTTP要求ヘッダを参照)に合わせるために, 転送符号化と呼ばれる文字符号化を動作中に変更してよい。サーバ及びプロキシは，文書文字集合全体をカバーする文字符号化で文書を提供する必要はない。
ウェブで共通して使用される文字符号化は, ISO-8859-1("Latin-1"としても参照され, ほとんどの西ヨーロッパ言語に使用可能), ISO-8859-5(キリル文字をサポート), SHIFT_JIS(日本語符号化), EUC-JP(もう一つの日本語符号化), 及びUTF-8(多様な文字に関して様々なバイト数を使用するISO 10646の符号化)を含む。文字符号化の名前は, 大文字及び小文字を区別しない。そこで, 例えば，"SHIFT_JIS", "Shift_JIS"及び"shift_jis"は等価となる。
この標準情報(TR)は，利用者エージェントがどの文字符号化をサポートしなければならないかを強制しない。
適合する利用者エージェントは, それが認識する(又は認識するものとして振る舞わなければならない)任意の文字符号化におけるすべての文字をUnicodeに正確に対応付けなければならない。
HTML テキストがUTF-16(charset=UTF-16)で伝送される場合, テキストデータは, [ISO10646], 6.3 及び[UNICODE], C3, ページ 3-1に従って, ネットワークバイト順("ビッグエンディアン", 上位バイト先頭)で伝送されるのが望ましい。
さらに，適切な解釈の機会を最大にするために，UTF-16として伝送された文書は常にZERO-WIDTH NON-BREAKING SPACE文字(16進のFEFF, バイト順マーク(BOM)とも呼ばれる。)で始まることを推奨する。この文字は, バイト反転の場合は16進のFFFEとなり, 決して割り当てられないことを保証した文字となる。したがって，テキストの最初のバイトとして16進のFFFEを受信する利用者エージェントは, テキストの残りに関してバイトを反転しなければならないことがわかる。
IANAによってISO-10646-UTF-1として登録された[ISO10646]のUTF-1転送フォーマットは, 使用しないほうがよい。ISO 8859-8及び双方向アルゴリズムに関する情報については, 双方向性及び文字符号化の節を参照されたい。
サーバが, それが扱う文書にどの文字符号化を適用するかを決定する方法を示す。文書の最初のわずかなバイトを検査したり，わかっているファイル及び符号化のデータベースに対してチェックをするサーバもある。最近のサーバの多くは, 以前のサーバよりも多くのcharset構成制御をウェブマスタに与える。ウェブマスタは, 可能な場合はいつでも"charset"パラメタを送出するこれらの機構を使用することが望ましいが, 間違った"charset"パラメタ値をもつ文書を識別しないことに注意するほうがよい。
どの文字符号化が使用されたかを利用者エージェントが知る方法を示す。サーバは, この情報を提供することが望ましい。サーバが文書の文字符号化に関する情報を利用者エージェントに与える最も単純な方法は, HTTPプロトコルの"Content-Type"ヘッダフィールドの"charset"パラメタ([RFC2068], 3.4及び14.18)を使用することになる。 文字符号化がEUC-JPであることを通知するHTTPヘッダの例を次に示す。
Content-Type: text/html; charset=EUC-JP
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">
ASCII文字が有効である文字符号化の構成がなされているときだけ(少なくとも， META要素が構文解析されるまでに), META宣言を用いなればならない。META宣言は, HEAD要素において, できる限り早く現われることが望ましい。
HTTPプロトコルもMETA要素も文書の文字符号化に関する情報を提供しない場合には, HTMLは, 幾つかの要素についてcharset属性も提供する。 これらの機構を組合わせることによって, 文書作成者は, 利用者の資源検索に際して利用者エージェントが文字符号化を認識する機会を大きく改善できる。
要約すると, 適合する利用者エージェントは，文書の文字符号化を決定するときに，次の優先順位(最大優先順位から最小優先順位へ)を守らなければならない。
この優先順位のリストに加えて，利用者エージェントは, 発見的手法及び利用者設定を用いてもよい。例えば，利用者エージェントの多くは, 発見的手法を使用して，日本語テキストに用いる様々な符号化を区別する。利用者エージェントは，他の指示子がない場合に適用される, 利用者定義可能で局所的なデフォルト文字符号化をももつことが多い。
利用者エージェントは，誤った"charset"情報に利用者が上書き可能にする機構を提供してもよい。しかし，利用者エージェントがその機構を提供するときには, 編集のためではなく閲覧のためにそれを提供するだけとして，誤った"charset"パラメタによってマーク付けされたウェブページの生成を避けることが望ましい。
備考 特定のアプリケーションに関して, [ISO10646]以外の文字を参照することが必要になる場合, 文字を私的領域に割り当てて, 規格の現在の版又は将来の版との衝突を回避することが望ましい。しかし，移植性の理由からこれは決して推奨できない。
一つの与えられた文字符号化が, 必ずしも文書文字集合のすべての文字を表現できないこともある。そんな符号化に関しては，又はハードウェア若しくはソフトウェアの構成が利用者に文書文字を直接入力することを許さない場合には，文書作成者は, SGML文字参照を使用してもよい。文字参照は，文書文字集合のどんな文字をも入力するための，文字符号化非依存の機構とする。
HTMLでの文字参照は, 次の二つの形式で現われる。
コメントの中の文字参照は, 特別な意味をもたず, コメントのデータにすぎない。
備考 HTMLは，文字データを表示するために，他の方法，特に 行内画像を提供する。
備考 SGMLでは, 文字参照の後の最後の";"を削除できる場合(例えば, 行区切りに際して, 又はタグの直前)がある。他の状況(例えば, 単語の中央)では, その削除はできない。この文字が存在すること要求する利用者エージェントとの問題を避けるために, どんな場合でも";"を使用することを強く推奨する。
数値文字参照は，文書文字集合における文字の符号位置を指定する。数値文字参照は, 次の二つの形式をとってよい。
数値文字参照の例を次に示す。
備考 16進表現は, [ISO8879]で定義されていないが, [WEBSGML]に示されるとおり，その改訂版に定義されることが期待される。 文字の規格は通常, 16進表現を用いるため，この規約は特に有用になる。
文書文字集合の文字を参照するもっと直観的な方法を文書作成者に与えるため, HTMLは文字実体参照の集合を提供する。文字実体参照は, 象徴的な名前を使用する。そのため文書作成者は, 符号位置を覚える必要がない。例えば，文字実体参照のåは, 輪を上に載せた小文字の"a"を参照する。"å"は, åより記憶し易い。
HTML 4.0は, 文書文字集合のすべての文字について文字実体参照を定義するわけではない。例えば，キリル大文字"I"に関する文字実体参照は存在しない。HTML 4.0で定義される文字参照の完全リストを参照されたい。
文字実体参照は, 大文字及び 小文字を区別する。したがって, Åは, å(輪の付いた小文字a)とは異なる文字(輪の付いた大文字A)を参照する。
次の四つの文字実体参照が特に言及に値する。これらは特別な文字へのエスケープのためによく使用される。
テキストに"<"文字を置きたい文書作成者は, "<"(ASCII 10進60)を使って, タグの先頭[開始タグの開始の(開きの)区切り子]との可能な混乱を避けるほうがよい。同様に, 文書作成者は, テキスト中で">"の代わりに">"(ASCII 10進62)を使用して，(">"が)引用された属性値に現われる場合に, タグの末尾(タグの終了の区切り子)としてこれを正確に認識しない古い利用者エージェントのもつ問題を避けるほうがよい。
文書作成者は, "&"の代わりに"&"(ASCII 10進38)を使用して, 文字参照の先頭(実体参照の開始の区切り子)との混乱を避けることが望ましい。 文書作成者は, 属性値においても"&"を使用するほうがよい。これは, 文字参照がCDATA属性値内で許容されることによる。
二重引用符(")のインスタンスを符号化するために文字実体参照"""を用いる文書作成者もいる。これは, この文字を属性値を区切るために使用してよいことによる。
利用者エージェントは，すべての文字を文書中で意味のあるものとして レンダリングすることができなくてもよい。例えば, 利用者エージェントが適切なフォントをもたないために，利用者エージェントの内部文字符号化などで表せない値をもつ文字がある。
それらの場合には行ってもよい多くの様々なことがあるので, この標準情報(TR)は, 特定の振る舞いを記述しない。 実装に依存するため, 表示不可能な文字も, アプリケーション自体ではなく, 基礎的な表示システムによって処理される。特定の用字又は言語の要求に合わせた振る舞いなどの, もつと高度な振る舞いがない場合，利用者エージェントに関する次の振る舞いを推奨する。