Tweet

■連載最終回の内容

主な内容 --Page 1-- 連載最終回の内容 文字符号化の自動検出（続き） --Page 2-- 外部の符号化情報が存在するときの優先順位 --Page 3-- 2つの名簿 --Page 4-- 実はとても重要度が高い備考 最後に

　前回は「E Deterministic Content Models (Non-Normative)」と、「F Autodetection of Character Encodings (Non-Normative)」の途中までを読んだ。JIS X 4159では「附属書E（参考）決定的内容モデル」と「附属書F（参考）文字符号化の自動検出」に当たる。今回は、その話題の続きを読む。「F.2 Priorities in the Presence of External Encoding Information（F.2 外部の符号化情報が存在するときの優先順位）」は、文書内部に書かれるべき符号化宣言のほかに、文書外に符号化方式を示す情報があった場合に、どちらを採用するかの優先順位について記述している。

　さらに今回は2つのトピックも読んでいく。1つはXML勧告を作成し、メンテナンスを行う作業グループの名簿についてである。もう1つは、「I Production Notes（I 文書作成に関する備考）」であり、XML勧告を作成するために使用された技術についての備考である。わずか1段落の短い文章であるが、実は非常に大きな価値がある。何しろ、XML勧告を出版するために現実に使用されたDTDやスタイルシートが丸ごと公開されているのである。現場レベルの泥臭いリアリティに立脚して、XMLとはどのようにして使うものであるか、という好例となっている。

■文字符号化の自動検出（続き）

　では、前回の続きを読んでいこう。「F Autodetection of Character Encodings (Non-Normative)」、JIS X 4159では「附属書F（参考）文字符号化の自動検出」となる部分のNote（備考）以降である。

　冒頭の文章は、「4.3.3 Character Encoding in Entities（4.3.3 実体における文字符号化）」に含まれる以下の文章を指し示しているのだろう。

　次は、未来は未知であり何が起こるか分からない、としている。具体的な事例を示すなら、例えばUTF-8のByte Order MarkであるEF BB BFというバイト列は、第3水準、第4水準を規定するJIS X 0213:2000に含まれる「付属書1（参考）Shift_JISX0213符号化表現」（いわゆるシフトJISの0213版）とバッティングする。もし、EF BB BFというバイト列をこれに従って解釈すると、EF BBは下記の文字、BFは半角の“ｿ”となる。

X0213:2000 p198より引用

　つまり、従来のシフトJISでは、EF BB BFというバイト列に該当する文字が存在しないために、シフトJISとUTF-8を確実に自動識別するために、UTF-8文書の先頭にByte Order Markを付けるという選択は安全であった。しかし、Shift_JISX0213符号化を用いた場合、このバイト列では確実な判定ができないことを意味する。つまり機能性が劣化している。

　これはJIS X 0213（第3水準、第4水準）が強い批判を浴び、難産となった理由。そして、結果として生まれ出たものの、シフトJIS表現に関しては「参考」という表記で分かるとおり「規定」に含まれることがなかった理由の1つ（すべてではない）といえるのではないだろうか。念のためにいえば、悪いのはJIS X 0213（第3水準、第4水準）ではなく、このような明らかに予想される問題点を回避する手間をかけないという怠惰な態度にある。そう、JIS X 0213に対する批判とは、突き詰めていけば、文字の問題でもなく、技術の問題でもなく、怠惰さの問題に行き着くのではないかと思う。

　ちなみに、このような難解な文字と半角の“ｿ”を連続して先頭に書くことなどあり得ず、Shift_JISX0213符号化表現を使ってもトラブルなど起きるはずがない……、という主張はおそらく誤りである。なぜなら、起こるはずがないと考えられた組み合わせが実際に発生した事例がいくらでも存在するからだ。容易にあいまいさを取り除くことができるケースで、「いくら何でもあり得ないだろう」と考えてあいまいさを残すことは、トラブルを自ら差し招く行為であると考えた方がよいだろう。ちなみに、トラブルを招いた者と、実際にトラブルに遭遇する者が同じとは限らない。トラブルを招いた者は、トラブルに遭遇する者の痛みを理解せず、繰り返しトラブルを招き続けるケースもあるので、要注意である。その点で、このXML勧告の記述は、そのようなあいまいさが生じるケースに備えて符号化宣言のチェックを強制しており、より好ましい規定を行っているといえる（ただし、規定を行っているのは、「4.3.3 Character Encoding in Entities（4.3.3 実体における文字符号化）」であり、いま読んでいる部分は規定ではなく参考である）。

　もう1つ注意を払う価値があることがある。正しいXML文書は、先頭が「この難解な文字と半角の“ｿ”」となることはない。従って、正しいXML文書を扱っている限り、EF BB BFというバイト列で始まる文書はShift_JISX0213符号化表現ではあり得ない。しかし、入力されるすべての文書が正しいXML文書であると考えるのは、過酷な現場で稼働するシステムを設計する態度としては正しいものではない。もし、Shift_JISX0213符号化表現で記述され、先頭がEF BB BFというバイト列というXML文書ではないファイルを入力したとしよう。しかし、この附属書Fの仕様を実装したXMLプロセッサは、これをUTF-8と誤判定する。そして、XML文書としての解析に失敗し、XMLプロセッサは誤りを報告するかもしれない。そこまではよい。そのファイルがXML文書として誤りであるというのは正しい判断である。しかし、もし誤りを報告する際に、誤りを検出した行を付けたとしたらどうだろうか。ファイルはShift_JISX0213符号化表現であるのに、XMLプロセッサはこのファイルをUTF-8だと認識して扱っていることになる。その結果、報告に付けられた行は文字化けすることになる。文字化けしたエラー報告は、しばしば問題の解決を遅らせることがあり、好ましいものではない。このような問題を回避できる状況で回避することは、望ましい選択であるが、Shift_JISX0213符号化表現はそれを回避しようとしていない。

　さて、話を先に進めよう。Note（備考）が終わり、本文に戻る。

　ここで書かれていることは、自動判別の目的が「符号化方式の確定」ではないことを示している。符号化方式を確定するために「必要な情報を得る」目的に限れば、自動判別でも十分に役立つということを述べているのである。つまり、自動判別でまずラフな当たりを付け、当たりを使って符号化宣言を解析し、符号化方式を確定することができるということである。ちなみに、8859とは、ISO/IEC 8859で始まる名前を持つ一連のシリーズを意味する。バリエーションとして、ISO/IEC 8859-1、ISO/IEC 8859-2、……などがある。例えば、ISO/IEC 8859-1は以下に当たる。

　これらは、ラテンアルファベットのための符号化文字集合の規格なのだが、必要とされる文字の種類の違いによって、さまざまなバリエーションがある。それらのどれを使用しているかは、自動判定では容易に分からない。容易かつ確実に区別するには符号化宣言が必要である。（次ページへ続く）

1/4

Index
やさしく読む「XML 1.0勧告」 第38回 XML勧告を記述するXMLspecとは何か
	Page 1 ・連載最終回の内容 ・文字符号化の自動検出（続き）
	Page 2 ・外部の符号化情報が存在するときの優先順位
	Page 3 ・2つの名簿
	Page 4 ・実はとても重要度が高い備考 ・最後に

連載　やさしく読む「XML 1.0勧告」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）