[1] XML 文書は Unicode の文字の列として定義されていますが、 これはいろいろな文字コードによるバイト列として表現できます。

仕様書

実体の文字コード

[115] XML MIME実体は、 UTF-8 を使うべきです >>112。

[143] XML MIME実体では UTF-32 を使うべきではありません >>112。

[85] XML の外部解析対象実体は、それぞれ異なる文字符号化を使うことができます >>84。

[86] XML処理器は、 UTF-8 と UTF-16 の実体を読むことができなければなりません >>84。

UTF-16BE, UTF-16LE, CESU-8 などはこの規定に含まれていません >>84。[3] XML としてはこう規定されていますが、応用によっては UTF-8 のみの利用を認めているものもあります。特定の応用のみで用いられる XML処理器は UTF-8 のみ実装しているかもしれません。 またバイト列ではなく文字列を入力として受け取る XML処理器はどちらにも対応していないかもしれません (ただし XML 本体仕様書はそのような実装の存在を想定していません)。

[113] XML の外部実体で使っている文字コードを示す方法は3つあります >>112。

[91] UTF-8 と UTF-16 の場合を除き、 MIME charset などの外部の文字符号化情報か、 encoding 擬似属性がなければなりません >>84。

[117] XML対応の MIME producer は、 UTF-8 以外で encoding 擬似属性がない XML MIME実体について、 charset 引数と BOM の一方又は両方を指定するべきです >>112。その場合 encoding 擬似属性が実際の文字符号化と一致していないと分かっている時には、 それを修正または削除するべきです >>112。

[127] 実体の文字コードは、次のようにして決定します。

  1. [130] 外部の輸送プロトコルの情報があれば、それに依ります。
    • [131] XML MIME実体では、次のように定義されています >>112。
      1. [128] BOM があれば、それによって決定します >>112。
      2. [129] MIME charset 引数があれば、 それによって決定します >>112。
        • [8] sniffed MIME type ではなく、元々指定された MIME型を使います >>4。
  2. [132] 外部の輸送プロトコルからの情報がない場合、
    1. [133] BOM や encoding 擬似属性があれば、それによって決定します。
    2. [109] UTF-8 か UTF-16 の BOM がなく、 encoding 擬似属性がなく、 UTF-8 でもないのは致死的誤りです >>84。
    3. [134] それ以外なら UTF-8 です。
    • [108] なお、 encoding 擬似属性の値と実際の文字符号化が一致しないのは致死的誤りです >>84。
[135] 外部情報がある場合に外部情報と encoding が一致しないのはエラーとはされていません。[136] >>131 はなぜか SHOULD とされています >>112。[137] charset より BOM が優先されることになっていますが、 これは Webブラウザーの実装や HTML における文字コード判定と一致しています。

[139] XML未対応の MIME consumer は、 charset 引数が無い場合に、既定の文字符号化を仮定するべきではありません >>112。

[138] RFC 3023 時代までは、 text/* で charset 引数がない場合は US-ASCII とみなすことになっていました (XML対応か否かによらず)。 (しかし誰もそれに従っていませんでした。)[140] 仮定せずにどうするべきかは明記されていません。 (text/plain ではなく) application/octet-stream とみなすべきということでしょうか。[141] charset があったとしても、 BOM もあり、両者が一致していない場合、 XML対応かXML未対応かで動作が変わってしまうのですが、 それでいいのでしょうか。 XML未対応なら一切の文字コード処理をするべきではない気がします。

[110] 処理できない文字符号化の実体に遭遇したら致死的誤りです >>84。

[144] UTF-32 に対応していない XML MIME実体の consumer であっても、 UTF-32 の BOM は認識して適当なエラーを出すべきです >>112。

[145] これは UTF-32 への一切の対応を削除した Webブラウザーや HTML や Encoding Standard の方針とは相反するものです。

[111] 実体の文字符号化において合法でないバイト列に遭遇したら致死的誤りです >>84。

[15] Web での処理は、 encoding sniffing algorithm, Webにおける文字コードも参照。

[16] SRGS の ABNF形の charset sniffing の処理の規定では、 XML 仕様書が参照されています。

MIME charset 引数

[121] text/xml、application/xml、 text/xml-external-parsed-entity、 application/xml-external-parsed-entity、 application/xml-dtd、 および RFC 7303 を参照するその他の MIME型における charset 引数は、 RFC 7303 で定義されており、当該 XML MIME実体の文字コードを表しています。

[122] >>121 以外の XML MIME型の charset 引数は、 異なる定義の引数です。 (あるいは charset 引数が定義されていないこともあります。)[123] RFC 7303 の前の RFC 3023 時代の多くの XML MIME型は、 RFC 3023 の charset 引数の定義を参照しています。 現実的にはそれらも >>121 と同じものとして扱うべきでしょうが、 仕様上厳密には両者の定義は異なります。

[146] 値としては MIME charset が想定されているものと思われますが、 RFC にはまったく言及がありません。

[147] しかし実際の Webブラウザーは MIME charset ではなく Encoding Standard に従い解釈する(べき)ものと思われます。

[124] XML未対応の MIME producer は、 文字符号化が確実に分かっている場合を除き、 XML MIME実体に charset 引数を設定してはなりません >>112。

[125] XML MIME producer は、利用者が XML MIME実体に設定する値を指定する方法を提供するべきです >>112。

[126] 例えば、ファイル名の拡張子から charset を決めるように設定できるような実装方法が考えられます >>112。

BOM

[87] UTF-16 の実体は BOM から始まらなければなりません >>84。

[116] XML MIME実体では BOM のない UTF-8 を使うべきです >>112。

[88] UTF-8 の実体は BOM から始めることができます >>84 が、必須ではありません。

[90] 外部実体の置換文の先頭が U+FEFF でテキスト宣言が無い時には、 UTF-8 であっても BOM からはじめなければなりません >>84。

[118] XML対応の MIME producer は、 Unicode 以外のXML MIME実体の先頭が 0xFE 0xFF, 0xFF 0xFE, 0xEF 0xBB 0xBF のいずれかとなるような場合、 テキスト宣言がなければなりません >>112。

[119] これらは UTF-8 や UTF-16 の BOM と区別できないからです。 なお、 Unicode 以外となっているので、 UTF-8 や UTF-16 以外の Unicode 系文字コード (CESU-8 など) の BOM ならこの要件は適用されないことになります。[120] 特に限定されていないので、 charset 引数があってもこの要件は適用されます。

[89] XML処理器は、 BOM によって UTF-8 と UTF-16 の文書を判別できなければなりません >>84。

[114] UTF-8 と UTF-16 以外の文字コードに関しては、 XML としての BOM に関する規定は特にありません。

encoding 擬似属性

[82] XML宣言・テキスト宣言の encoding 擬似属性 (正式には符号化宣言encoding declaration) は、当該実体の文字コードを指定するものです。

[83] 何らかの文字コードで符号化されたバイト列の中にその文字コードを表す情報が含まれていても一般には意味がありませんが、 利用され得る文字コードの集合は有限なので、 sniffing によって実用上十分有用です。

文脈

[97] XML宣言またはテキスト宣言で、 version 擬似属性の直後に1回だけ指定できます。 テキスト宣言では version 擬似属性が省略可能なので、 その場合対象名の直後となります。 テキスト宣言では直後が pic でなければなりません。XML宣言ではその前に standalone 擬似属性を指定することもできます。

[142] UTF-16BE や UTF-16LE、 UTF-32BE、UTF-32LE の場合、 encoding 擬似属性を指定するべきです >>112。

構文

[92] 要素の属性の構文と似ていますが、特殊な構文として定義されています。

[94] 擬似属性は属性名、=、属性値で構成されます。 属性名は小文字の encoding です。属性値は符号化名で、 " (のみ) か ' (のみ) で前後を括らなければなりません。 文字参照は使えません。 >>84

[93] 本擬似属性の前には S が必要です。後に次の擬似属性が続く場合には、 間の S も必要です。 >>84

  1. S
  2. encoding
  3. =
  4. |
    1. =
      1. "
      2. 符号化名
      3. "
    2. =
      1. '
      2. 符号化名
      3. '

符号化名

[12] XML の XML宣言・文宣言の符号化宣言 (encoding 擬似属性) に指定できる値には、 MIME charset パラメーターの場合と同じ、 IANA 登録簿の名前も含まれます。

[95] ただし、 XML の場合は名前の制限が MIME や IANA 登録簿より厳しくなっています。

[13] 符号化名で使える文字は、ASCII英数字と .、 _、- です。ただし先頭はASCIIアルファベットでなければなりません。 >>84

  1. |
    1. ASCII大文字
    2. ASCII小文字
  2. *
    1. |
      1. ASCII大文字
      2. ASCII小文字
      3. ASCII数字
      4. .
      5. _
      6. -

[103] XML処理器は、符号化名を大文字・小文字不区別として扱うべきです >>84。

なぜか推奨にとどまっています。

[2] 符号化名の意味は、次の通り述べられています >>84。

ただし、なぜかこれらはいずれも「SHOULD」となっています。

[105] XML処理器は、符号化名を IANA登録簿の文字符号化として解釈するか、 未知のものとして扱うかのいずれかとするべきです。 >>84

[107] >>98, >>99, >>100 によりいくつかの charset 名はなぜか IANA登録簿を参照していません。これは厳密に解釈すると IANA登録簿と異なる文字コードを指しているものや、 IANA登録簿にない ISO/IEC 8859 の仕様書を指しているものも含まれています。例えば ISO-2022-JP は IANA登録簿が参照する RFC 1468 の定義と JIS X 0208:1997 に含まれる定義が一致していません。 ところが >>105 の通り処理器に対しては IANA登録簿に従うことを求めており、 ますます意図するところが不明です。

[106] XML処理器は、 IANA登録簿のすべての文字符号化に対応する必要はありません >>84。

[104] これだけ SHOULD のオンパレードかつ曖昧な定義で、 相互運用性を確保するつもりはあるのでしょうか。

[96] 実際には XML処理器で非 IANA 名で x- で始まらないものを使えるものも多いようです。 中には、 シフト符号化表現 なんて値まで使える実装もあるようです。 (これは >>13 に違反していますが。))

DOM

[5] XML構文解析器は、XML文書の文字符号化を決定したら、 これを文書の文字符号化として設定しなければなりません >>4。

[6] 仕様上この正確なタイミングは決められていませんが、 XML の場合は文書の構文解析器の途中で文字符号化が変更されることはありませんから、 必ずスクリプトの実行より前になります。[7] update the session history with the new page より前に実行されなければならないとの規定はありませんから、 他のフレームのスクリプトからは設定前にアクセスできてしまうのかもしれません。

メモ

[148] RFC 4918 - HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV) ( ( 版)) http://tools.ietf.org/html/rfc4918#appendix-F.1

[9] XQuery 3.1: An XML Query Language () https://www.w3.org/TR/2017/REC-xquery-31-20170321/#dt-encoding-declaration

[10] ERB decision: Character sets (Jon Bosak著, ) https://lists.w3.org/Archives/Public/w3c-sgml-wg/1997Jun/0461.html

[11] Determination of Encoding (Re: Invasion of the pseudo-people ...) (Murata Makoto著, ) https://lists.w3.org/Archives/Public/w3c-sgml-wg/1997Jun/0258.html

[14] Re: Comments on XML Part 1 from Japanese experts (Murata Makoto著, ) https://lists.w3.org/Archives/Public/w3c-sgml-wg/1997Jun/0130.html

[17] 使用できる文字エンコーディング, , https://itpfdoc.hitachi.co.jp/manuals/3021/3021360820/ADX20125.HTM