第042回_EncodingDecl2

E Autodetection of Character Encodings (Non-Normative)
The XML encoding declaration functions as an internal label on each entity, indicating which character encoding is in use. Before an XML processor can read the internal label, however, it apparently has to know what character encoding is in use -- which is what the internal label is trying to indicate. In the general case, this is a hopeless situation. It is not entirely hopeless in XML, however, because XML limits the general case in two ways: each implementation is assumed to support only a finite set of character encodings, and the XML encoding declaration is restricted in position and content in order to make it feasible to autodetect the character encoding in use in each entity in normal cases. Also, in many cases other sources of information are available in addition to the XML data stream itself. Two cases may be distinguished, depending on whether the XML entity is presented to the processor without, or with, any accompanying (external) information. We consider the first case first.

E 文字符号化方式の自動検知(非規範的)

E.1 Detection Without External Encoding Information
Because each XML entity not accompanied by external encoding information and not in UTF-8 or UTF-16 encoding must begin with an XML encoding declaration, in which the first characters must be '<?xml', any conforming processor can detect, after two to four octets of input, which of the following cases apply. In reading this list, it may help to know that in UCS-4, '<' is "#x0000003C" and '?' is "#x0000003F", and the Byte Order Mark required of UTF-16 data streams is "#xFEFF". The notation ## is used to denote any byte value except that two consecutive ##s cannot be both 00.

With a Byte Order Mark:

00 00 FE FF UCS-4, big-endian machine (1234 order)
FF FE 00 00 UCS-4, little-endian machine (4321 order)
00 00 FF FE UCS-4, unusual octet order (2143)
FE FF 00 00 UCS-4, unusual octet order (3412)
FE FF ## ## UTF-16, big-endian
FF FE ## ## UTF-16, little-endian
EF BB BF UTF-8

E1. 外部の文字符号化方式情報のない検知

ファイル情報から文字符号化方式を判別してファイルをオープンします。ファイル情報を知るために文字符号化方式を指定せずにファイルのバイト文字列を読み込みます。そのバイト列の先頭にBOMが付いている場合はBOMのバイト列からどの文字符号化方式かを判別します。また、BOMが付いていない場合は、"<?xml"の先頭文字"<"を示す文字コードを使って文字符号化方式を判別します。これらは完全ではないとしても、サポートする有限個の文字符号化方式の中では問題がありません。

3バイト目がFEの場合:UCS-4 ビッグエンディアン(1234の順)
3バイト目がFFの場合:UCS-4 普通でないオクテットの並び(2143)

3バイト目が00の場合:UCS-4 普通でないオクテットの並び(3412)
3バイト目が00でない場合:UTF-16 ビッグエンディアン

Without a Byte Order Mark:

00 00 00 3C	UCS-4 or other encoding with a 32-bit code unit and ASCII characters encoded as ASCII values, in respectively big-endian (1234), little-endian (4321) and two unusual byte orders (2143 and 3412).The encoding declaration must be read to determine which of UCS-4 or other supported 32-bit encodings applies.
3C 00 00 00
00 00 3C 00
00 3C 00 00
00 3C 00 3F	UTF-16BE or big-endian ISO-10646-UCS-2 or other encoding with a 16-bit code unit in big-endian order and ASCII characters encoded as ASCII values (the encoding declaration must be read to determine which)
3C 00 3F 00	UTF-16LE or little-endian ISO-10646-UCS-2 or other encoding with a 16-bit code unit in little-endian order and ASCII characters encoded as ASCII values (the encoding declaration must be read to determine which)
3C 3F 78 6D	UTF-8, ISO 646, ASCII, some part of ISO 8859, Shift-JIS, EUC, or any other 7-bit, 8-bit, or mixed-width encoding which ensures that the characters of ASCII have their normal positions, width, and values; the actual encoding declaration must be read to detect which of these applies, but since all of these encodings use the same bit patterns for the relevant ASCII characters, the encoding declaration itself may be read reliably
4C 6F A7 94	EBCDIC (in some flavor; the full encoding declaration must be read to tell which code page is in use)
Other	UTF-8 without an encoding declaration, or else the data stream is mislabeled (lacking a required encoding declaration), corrupt, fragmentary, or enclosed in a wrapper of some kind

バイトオーダーマークが付いていない場合は次のようになる

00 00 00 3C	UCS-4または他の32bitコード単位の文字符号化方式でASCII値で符号化したASCII文字。左のそれぞれはビッグエンディアン(1234)、リトルエンディアン(4321),それと普通ではないバイトの並び(2143と3412)。UCS-4か他の32bit符号化方式を適用するかを決定するためにエンコーディング宣言を読まなければならない。
3C 00 00 00
00 00 3C 00
00 3C 00 00
00 3C 00 3F (<?)	UTF-16BE またはビッグエンディアンのISO-10646-UCS-2 もしくは、16bitコード単位のビッグエンディアンの文字符号化方式でASCII値で符号化したASCII文字 (3つの内のどれであるかはエンコーディング宣言を読まなければならない。)
3C 00 3F 00 (<?)	UTF-16LE またはリトルエンディアンのISO-10646-UCS-2 もしくは、16bitコード単位のリトルエンディアンの文字符号化方式でASCII値で符号化したASCII文字 (3つの内のどれであるかはエンコーディング宣言を読まなければならない。)
3C 3F 78 6D (<?xml)	UTF-8、ISO 646、ASCII、ISO 8859の各パート、Shift-JIS、EUC、 他の7ビットの固定長、8ビット固定長、7-8の可変長の符号化方式でASCII値で符号化したASCII文字 (それらの内のどれであるかはエンコーディング宣言を読まなければならない。)
4C 6F A7 94	EBCDIC (または、その一部。どのコードページを使うかを知るにはエンコーディング宣言を全部読まなければならない。)
Other	エンコーディング宣言なしのUTF-8か、もしくは間違って名前付けされたデータストリーム(必要なエンコーディング宣言が欠落している)か、損傷しているか、文書の断片か、何らかの形式でラップされている。

Note:

This level of autodetection is enough to read the XML encoding declaration and parse the character-encoding identifier, which is still necessary to distinguish the individual members of each family of encodings (e.g. to tell UTF-8 from 8859, and the parts of 8859 from each other, or to distinguish the specific EBCDIC code page in use, and so on).

Because the contents of the encoding declaration are restricted to characters from the ASCII repertoire (however encoded), a processor can reliably read the entire encoding declaration as soon as it has detected which family of encodings is in use. Since in practice, all widely used character encodings fall into one of the categories above, the XML encoding declaration allows reasonably reliable in-band labeling of character encodings, even when external sources of information at the operating-system or transport-protocol level are unreliable. Character encodings such as UTF-7 that make overloaded usage of ASCII-valued bytes may fail to be reliably detected.

Once the processor has detected the character encoding in use, it can act appropriately, whether by invoking a separate input routine for each case, or by calling the proper conversion function on each character of input.

Like any self-labeling system, the XML encoding declaration will not work if any software changes the entity's character set or encoding without updating the encoding declaration. Implementors of character-encoding routines should be careful to ensure the accuracy of the internal and external information used to label the entity.

注意:

自動検知のレベルは、エンコーディング宣言を読み込み、文字符号化方式の識別子を解析すれば十分である。ただし、まだ同系統の文字符号化方式のどれになるか区別する必要はある。(例えば、UTF-8を8859から区別する、8859の各パート同士を区別する、または使用している特定のEBCDICコードページを区別する、等々)

エンコーディング宣言の内容は(符号化されているとしても)ASCIIレパートリーの文字に制限してあるので、どの系統の符号化が使用されているかを検知すれば、プロセッサはエンコーディング宣言全体を確実に読み込むことができる。実際には、広く使荒れている文字符号化方式は上記のカテゴリのどれかに当てはまるので、OSや伝送プロトコルレベルが提供する外部情報が信頼できない場合であっても、エンコーディング宣言は文字符号化方式の(入力ストリームの)内部的な名前を使って合理的で信頼性のある手段となる。ASCIIのコード値のバイト列を上書きして使っている例えば、UTF-7のような文字符号化方式は確実に検出できないことがある。

プロセッサが一度、使われている文字符号化方式を検出すれば、それぞれの場合に応じた別の入力ルーチンを呼び出すか入力のそれぞれの文字に正しい変換関数を呼び出すことで、適切に動作することができる。

自分自身にラベルを付けるシステムならどんなものでも同様であるが、もし、エンコーディング宣言を更新せずにソフトウェアが実体の文字集合や文字符号化方式を変えた場合、エンコーディング宣言は機能しない。文字符号化方式のルーチンの実装者は、実体の名前付けに使用する内部と外部の情報の正確さを確保することに配慮すべきである。

1-1.

4バイト分を取得する

1-2.

次の一致する文字符号化方式をListに追加する バイト列 : 登録する文字符号化 : word size ――――――――――――――――――――――――――――――――― 00 00 00 3C : ISO-10646-UCS-4、その他の32bit文字符号化方式 : 4byte 00 00 3C 00 : ISO-10646-UCS-4、その他の32bit文字符号化方式 : 4byte 00 00 FE FF : ISO-10646-UCS-4 : 4byte 00 00 FF FE : ISO-10646-UCS-4 : 4byte 00 3C 00 00 : ISO-10646-UCS-4、その他の32bit文字符号化方式 : 4byte 00 3C 00 3F : UTF-16、ISO-10646-UCS-2、その他の16bitコード単位の文字符号化方式 : 2byte 3C 00 00 00 : ISO-10646-UCS-4、その他の32bit文字符号化方式 : 4byte 3C 00 3F 00 : UTF-16、ISO-10646-UCS-2、その他の16bitコード単位の文字符号化方式 : 2byte 3C 3F 78 6D : UTF-8、ISO646-US、ISO-8859-1、ISO-8859-2・・・、Shift_JIS、EUC-JP、7bit固定長/8bit固定長/7-8bit固定長のASCIIの文字符号化方式 : 1byte 4C 6F A7 94 : EBCDIC系のサポートする文字符号化方式 : 1byte FF FE 00 00 : ISO-10646-UCS-4 : 4byte FE FF 00 00 : ISO-10646-UCS-4 : 4byte FE FF ## ## : UTF-16 : 2byte FF FE ## ## : UTF-16 : 2byte EF BB BF : UTF-8 : 1byte※1 その他 : XML宣言/Text宣言をもたないUTF-8、または未知の文字符号化方式 : ????

2-1.	指定エンコーディング宣言まで読み込む
2-2.	指定エンコーディングの識別子がリスト内にあるかチェックする

文字符号化方式	:	EncName
―――――――――――
UTF-8 BOM無	:	UTF-8
UTF-8 BOM付	:	UTF-8
UTF-16 BOM付BE	:	UTF-16
UTF-16 BOM付LE	:	UTF-16

1-1.	4バイト分を取得する
1-2.	次の一致する文字符号化方式をListに追加する バイト列 : 文字符号化方式ファミリ : word size ――――――――――――――――――――――――――――――――― 3C 3F 78 6D : UTF-8 BOM無かつXML/Text宣言を持つ : 1byte EF BB BF : UTF-8 BOM有 : 1byte FE FF ## ## : UTF-16 BOM有BE : 2byte FF FE ## ## : UTF-16 BOM有LE : 2byte その他 : BOM無でXML/Text宣言をもたないUTF-8、または未知の文字符号化方式 : ???? ※未知はサポートしない文字符号化方式を含みます。 ※1.0のXML文書の場合、XML宣言は省略可能です。

3-1.	指定エンコーディング宣言まで読み込む
3-2.	指定エンコーディングの識別子がファミリ内にあるかチェックする

現在の実装では、FileInputStreamとInputStreamReaderの処理はDocumentTokenizerのコンストラクタ内で継承先のBaseFileTokenizerが実行しています。

2つの問題があります。
1つ目は、自動検知機能の処理には、仕様上、致命的なエラーを発生させる場合がありますが、コンストラクタ内で致命的なエラーが発生するとインスタンスは不完全になり、利用してはいけないオブジェクトになることです。

2つ目は、JavaのInputStreamReaderのUTF-8への対応の問題です。残念なことに、InputStreamReaderに文字符号化方式としてUTF-8を指定して、UTF-8にBOM付を指定すると、BOM部分を文字として取得してしまい、これまでの字句解析の実装でWORDトークンとなるため構文解析でエラーになります。

2つの問題に対処するために、無条件字句解析器の引数はBufferedReaderに変更します。BufferedReaderのインスタンスは、自動検知機能で取得した文字符号化方式のオブジェクトから取得し、無条件字句解析器に渡します。

また、UTF-8BOM付の文字符号化方式のオブジェクトでBufferdReaderを取得する場合は、先頭3バイトを読み捨ててから(BOMをスキップした後に)渡します。