[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。
[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。
[139] XML未対応の MIME consumer は、 charset
引数が無い場合に、既定の文字符号化を仮定するべきではありません >>112。
text/*
で
charset
引数がない場合は US-ASCII
とみなすことになっていました (XML対応か否かによらず)。
(しかし誰もそれに従っていませんでした。)charset
があったとしても、 BOM
もあり、両者が一致していない場合、 XML対応かXML未対応かで動作が変わってしまうのですが、
それでいいのでしょうか。 XML未対応なら一切の文字コード処理をするべきではない気がします。[110] 処理できない文字符号化の実体に遭遇したら致死的誤りです >>84。
[144] UTF-32 に対応していない XML MIME実体の consumer であっても、 UTF-32 の BOM は認識して適当なエラーを出すべきです >>112。
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実体の文字コードを表しています。
charset
引数の定義を参照しています。
現実的にはそれらも >>121 と同じものとして扱うべきでしょうが、
仕様上厳密には両者の定義は異なります。[146] 値としては MIME charset が想定されているものと思われますが、 RFC にはまったく言及がありません。
[124] XML未対応の MIME producer は、 文字符号化が確実に分かっている場合を除き、
XML MIME実体に charset
引数を設定してはなりません
>>112。
[125] XML MIME producer は、利用者が XML MIME実体に設定する値を指定する方法を提供するべきです >>112。
[87] UTF-16
の実体は BOM から始まらなければなりません
>>84。
[116] XML MIME実体では BOM のない UTF-8 を使うべきです >>112。
[90] 外部実体の置換文の先頭が U+FEFF
でテキスト宣言が無い時には、
UTF-8 であっても BOM からはじめなければなりません >>84。
[118] XML対応の MIME producer は、 Unicode 以外のXML MIME実体の先頭が 0xFE 0xFF, 0xFF 0xFE, 0xEF 0xBB 0xBF のいずれかとなるような場合、 テキスト宣言がなければなりません >>112。
[89] XML処理器は、 BOM によって UTF-8
と
UTF-16
の文書を判別できなければなりません >>84。
encoding
擬似属性[82] XML宣言・テキスト宣言の encoding
擬似属性 (正式には符号化宣言)
は、当該実体の文字コードを指定するものです。
[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
[12] XML の XML宣言・文宣言の符号化宣言 (encoding 擬似属性) に指定できる値には、 MIME charset パラメーターの場合と同じ、 IANA 登録簿の名前も含まれます。
[95] ただし、 XML の場合は名前の制限が MIME や IANA 登録簿より厳しくなっています。
[13] 符号化名で使える文字は、ASCII英数字と .
、
_
、-
です。ただし先頭はASCIIアルファベットでなければなりません。
>>84
[103] XML処理器は、符号化名を大文字・小文字不区別として扱うべきです >>84。
[2] 符号化名の意味は、次の通り述べられています >>84。
[105] XML処理器は、符号化名を IANA登録簿の文字符号化として解釈するか、 未知のものとして扱うかのいずれかとするべきです。 >>84
ISO-2022-JP
は IANA登録簿が参照する RFC 1468
の定義と JIS X 0208:1997 に含まれる定義が一致していません。
ところが >>105 の通り処理器に対しては IANA登録簿に従うことを求めており、
ますます意図するところが不明です。[106] XML処理器は、 IANA登録簿のすべての文字符号化に対応する必要はありません >>84。
[96] 実際には XML処理器で非 IANA
名で x-
で始まらないものを使えるものも多いようです。
中には、 シフト符号化表現
なんて値まで使える実装もあるようです。
(これは >>13 に違反していますが。))
[5] XML構文解析器は、XML文書の文字符号化を決定したら、 これを文書の文字符号化として設定しなければなりません >>4。
[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>
UTF-16BE
,UTF-16LE
,CESU-8
などはこの規定に含まれていません >>84。