XMLの符号化宣言は，各実体の内部ラベルとして機能し，どの文字符号化方式を使用するかを示す。しかし，XMLプロセサは内部ラベルを読む前にどの文字符号化方式を使われているかを知る必要があり，これが，内部ラベルが示そうとしていることに他ならない。一般的には，これは絶望的な状態となる。しかし，XMLにおいては，完全には絶望的ではない。これは，XMLが次の二つの点で一般的な場合に対する制限を加えていることによる。一つの制限は，どの実装も有限個の文字符号化方式だけをサポートするものと見なす。他の一つは，XMLの符号化宣言の位置及び内容を制限して，各実体で使用する文字符号化方式の自動検出を可能にする。また，多くの場合に，XMLのデータストリームに加え，他の情報が利用できる。ここでは，XMLの実体がプロセサに渡されるとき，(外部)情報を伴うかどうかによって，二つの場合に分ける。まず最初の場合を示す。

UTF-8形式又はUTF-16形式ではないXML実体は，最初の文字列を'<?xml'とするXML符号化宣言で始めなければならないので，どの適合したプロセサも，入力にある2オクテット又は4オクテットを調べれば，次のどの場合があてはまるかを検出できる。このリストを読む際には，UCS-4の'<'が"#x0000003C"，'?'が"#x0000003F"，及びUTF-16のデータストリームの必要とするバイト順マークが"#xFEFF"ということを知っておくと役立つ。

• a) 00 00 00 3C: UCS-4, big-endian マシン (1234順)
• b) 3C 00 00 00: UCS-4, little-endian マシン (4321順)
• c) 00 00 3C 00: UCS-4, 普通ではないオクテット順 (2143)
• d) 00 3C 00 00: UCS-4, 普通ではないオクテット順 (3412)
• e) FE FF: UTF-16, big-endian
• f) FF FE: UTF-16, little-endian
• g) 00 3C 00 3F: UTF-16, big-endian, バイト順マークなし(したがって，厳密にいえば，エラー。)。
• h) 3C 00 3F 00: UTF-16, little-endian, バイト順マークなし(したがって，厳密にいえば，エラー。)。
• i) 3C 3F 78 6D: UTF-8, ISO 646, ASCII, ISO 8859の各パート，Shift-JIS，EUC，並びに任意の他の7ビット，8ビット又は混在幅の符号化方式であって，ASCII文字を通常の位置，幅及び値とすることを保証するもの。これらのどれに対応するかを検出するためには，実際の符号化宣言を読み込まなければならない。しかし，これらすべての符号化方式は，ASCII文字に対して同じビットパターンを使用するので，符号化宣言自体は，正確に読込むことができる。
• j) 4C 6F A7 94: EBCDIC (又はその変種。どのコードページを使用するかを知るためには，符号化宣言全体を読み込まれなければならない。)
• k) その他: 符号化宣言なしのUTF-8。そうでないときには，データストリームが壊れているか，文書の断片であるか，何らかの形式に従って埋め込まれている。

この程度の自動判別でも，XMLの符号化宣言を読み込み，文字符号化方式の識別子を十分解析できる。識別子の解析は，類似する各々の符号化方式の一つ一つを区別するために必要になる(例えば，UTF-8及び8859を区別するため，8859の各パートを区別するため，使用している特定のEBCDICコードページを区別するため。)。

符号化宣言の内容をASCII文字に限定しているので，どの系統の符号化方式が使用されているかを検出すれば，プロセサは符号化宣言全体を正確に読み込むことができる。現実問題として，広く使用されている文字符号化方式は前述の系統のいずれかにあてはまるので，オペレーティングシステム又は伝送プロトコルが与える外部情報を信頼できないときでも，内部ラベルで文字符号化方式をかなり正確に示すことがXML符号化宣言によって可能となる。

プロセサが文書の符号化方式を検出しさえすれば，それぞれの場合に対して別の入力ルーチンを呼び出すか，又は入力する各文字に対し適切な変換関数を呼び出すことによって，適切に動作することができる。

自分自体にラベル付けをするいかなるシステムでも同様だが，ソフトウェアが，符号化宣言を更新せずに実体の文字集合又は符号化方式を変えれば，XMLの符号化宣言は機能しない。文字符号化ルーチンの実装者は，実体のラベル付けに使用する内部及び外部の情報の正確さの保証に注意すべきである。

[訳注(これは原規定にはない）] 以下の記述はRFC 2376によって，すでに取って代わられているので，そちらを参照されたい。MIME型application/xmlの場合の扱いはRFC 2376では変更されている。

2番目の場合は，XMLの実体の他に，符号化方式についての情報が存在するときである。いくつかのファイルシステム及びネットワークプロトコルでは，その符号化方式についての情報が存在する。複数の情報が利用できるとき，それらの相対的な優先度と，それらが矛盾したときの望ましい処理方法とは，XMLの配送に使用するより高水準のプロトコルの一部として規定するのがよい。例えば，内部ラベル及び外部ヘッダに存在するMIME形式のラベルの相対的な優先度についての規則は，MIME型text/xml及びapplication/xmlを定義するRFC文書の一部となるのが望ましい。しかし，相互運用性のため，次の規則を推薦する。

• a) XMLの実体がファイルに存在すれば，バイト順マーク及び符号化宣言PIは，(存在すれば)文字符号化方式を決定するために使用する。他のすべてのヒューリスティック及び情報は，エラー回復のためだけに用いる。
• b) XMLの実体をMIME型text/xmlで配送するときは，このMIME型のもつcharsetパラメタが文字符号化方式を決定する。他のすべてのヒューリスティック及び情報は，エラー回復のためだけに用いる。
• c) XMLの実体をMIME型application/xmlで配送するときは，バイト順マーク及び符号化宣言PIを(存在すれば)文字符号化方式の決定のために使用する。他のすべてのヒューリスティック及び情報はエラー回復のためだけに用いる。