XMLの符号化宣言は，各実体の内部ラベルとして機能し，どの文字符号化を使用するかを示す。しかし，XMLプロセサは内部ラベルを読む前にどの文字符号化を使われているかを知る必要があり，これが，内部ラベルが示そうとしていることに他ならない。一般的には，これは絶望的な状態となる。しかし，XMLにおいては，完全には絶望的ではない。これは，一般的な場合に対する次の二つの制限を，XMLが加えていることによる。一つの制限は，どの実装も有限個の文字符号化だけをサポートするものと見なす。他の一つは，XMLの符号化宣言の位置及び内容を制限して，各実体で使用する文字符号化の自動検出を可能にする。また，多くの場合に，XMLのデータストリームに加え，他の情報が利用できる。ここでは，XMLの実体がプロセサに渡されるとき，(外部)情報を伴うかどうかによって，二つの場合に分ける。まず最初の場合を示す。
外部の符号化情報をともなわず，
UTF-8又はUTF-16符号化ではないXML実体は，最初の文字列を'<?xml'とするXML符号化宣言で始めなければならないので，どの適合したプロセサも，入力にある2オクテット又は4オクテットを調べれば，附属書F表1, 表2に示すどの場合があてはまるかを検出できる。このリストを読む際には，UCS-4の'<'が"#x0000003C"，'?'が"#x0000003F"，及びUTF-16のデータストリームの必要とする“印”(しるし)が"#xFEFF"ということを知っておくと役立つ。
##記法は任意のバイト値を表すが，連続する二つの## が両方とも00であることはないという例外がある。
00 00 FE FF |
UCS-4, big-endianマシン (1234 order) |
FF FE 00 00 |
UCS-4, little-endianマシン(4321 order) |
00 00 FF FE |
UCS-4, 普通でないオクテット順(2143) |
FE FF 00 00 |
UCS-4, 普通でないオクテット順(3412) |
FE FF ## ## |
UTF-16, big-endian |
FF FE ## ## |
UTF-16, little-endian |
EF BB BF |
UTF-8 |
00 00 00 3C |
UCS-4。又は，他の符号化であって，32ビットのコード単位をもち，ASCII 文字をASCIIコード値として符号化するもの。それぞれ，big-endian (1234), little-endian (4321), 二つの普通ではないオクテット順 (2143と 3412)とする。 UCS-4とその他の32ビットの符号化とのどちらであるかを決定するためには，符号化宣言を読み込まなくてはならない． |
3C 00 00 00 | |
00 00 3C 00 | |
00 3C 00 00 | |
00 3C 00 3F |
UTF-16BEかbig-endianの ISO-10646-UCS-2。又は，その他の16ビットのコード単位をもつbig-endianの符号化方式であって，ASCII文字をASCIIコード値として符号化するもの。(これらのうちどの符号化方式であるかを判定するためには，符号化宣言を読み込まなくてはならない。) |
3C 00 3F 00 |
UTF-16LEかlittle-endianの ISO-10646-UCS-2。又は，その他の16ビットのコード単位をもつlittle-endianの符号化方式であって，ASCII文字をASCIIコード値として符号化するもの。(これらのうちどの符号化方式であるかを判定するためには，符号化宣言を読み込まなくてはならない。) |
3C 3F 78 6D |
UTF-8, ISO 646, ASCII, ISO 8859の各パート，Shift-JIS，EUC，並びに任意の他の7ビット，8ビット又は混在幅の符号化方式であって，ASCII文字を通常の位置，幅及び値とすることを保証するもの。これらのどれが使われているかを検出するためには，実際の符号化宣言を読み込まなければならない。しかし，これらすべての符号化方式は，関係するASCII文字に対して同じビットパターンを使用するので，符号化宣言自体は，正確に読込むことができる。 |
4C 6F A7 94 |
EBCDIC (又はその変種。どのコードページを使用するかを知るためには，符号化宣言全体を読み込まれなければならない。) |
| その他 | 符号化宣言なしのUTF-8。そうでないときには，データストリームに誤ったラベルが付されている(必要な符号化宣言が欠落している)か，損傷しているか，文書の断片であるか，何らかの形式に従って埋め込まれている。 |
備考 これらの場合のうち，符号化を決めるために符号化宣言を読む必要がない場合においても，4.3.3は，符号化宣言(もし存在するなら)を読み込むことを要求しており，符号化の名前が実体の実際の符号化とマッチすることを確かめることを要求している．また，符号化を決めるために符号化宣言を用いる必要が現在はなくても，新しい文字符号化 が発明されることによって符号化宣言を用いることが必要になることもあり得る。
この程度の自動判別でも，XMLの符号化宣言を読み込み，文字符号化の識別子を十分解析できる。識別子の解析は，類似する各々の符号化の一つ一つを区別するために必要になる(例えば，UTF-8を8859から区別するため，若しくは8859の各パートを区別するため，又は使用している特定のEBCDICコードページを区別するため。)。
符号化宣言の内容を ASCIIレパートリーにある文字(どのように符号化される場合であっても)に限定しているので，どの系統の符号化が使用されているかを検出すれば，プロセサは符号化宣言全体を正確に読み込むことができる。現実問題として，広く使用されている文字符号化は前述の系統のいずれかにあてはまるので，オペレーティングシステム又は伝送プロトコルが与える外部情報を信頼できないときでも，内部ラベルで文字符号化をかなり正確に示すことがXML符号化宣言によって可能となる。 ASCIIのコード値をもつバイトを過度に用いる文字符号化(例えばUTF-7) は，確実に検出できないことがある。
プロセサが文書の符号化を検出しさえすれば，それぞれの場合に対して別の入力ルーチンを呼び出すか，又は入力する各文字に対し適切な変換関数を呼び出すことによって，適切に動作することができる。
自分自体にラベル付けをするいかなるシステムでも同様だが，ソフトウェアが，符号化宣言を更新せずに実体の文字集合又は符号化を変えれば，XMLの符号化宣言は機能しない。文字符号化ルーチンの実装者は，実体のラベル付けに使用する内部及び外部の情報の正確さの保証に注意すべきである。
2番目の場合は，XMLの実体の他に，符号化についての情報が存在するときである。幾つかのファイルシステム及びネットワークプロトコルでは，その符号化についての情報が存在する。複数の情報が利用できるとき，それらの相対的な優先度と，それらが矛盾したときの望ましい処理方法とは，XMLの配送に使用するより高水準のプロトコルの一部として規定するのがよい。特に，[IETF
RFC 3023]又はその後継RFCを参照されたい。このRFCはMIMEタイプtext/xmlと
application/xmlを定義しており，幾つかの有用な指示を与えている．相互運用性のため，次の規則を推奨する。
| a) | XMLの実体がファイルに存在すれば，“印”(しるし)及び符号化宣言は，(存在すれば)文字符号化を決定するために使用する。 |