第38回 XML勧告を記述するXMLspecとは何か Page 1

XML 1.0は、1998年にW3Cから勧告として公開された。当然中身は英語で、しかもEBNFと呼ばれる式によって重要な部分が記述してある。この連載では、XML 1.0を深く理解するために、そのXML 1.0勧告の最新版「Extensible Markup Language (XML) 1.0 (Third Edition)」をだれでも分かるように、やさしく読み解きながら解説していくことを目指している。(編集局)

川俣 晶
株式会社ピーデー
2005/10/12

連載最終回の内容

主な内容
--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とはどのようにして使うものであるか、という好例となっている。

編集注:この連載では、XML 1.0勧告であるW3Cの「Extensible Markup Language (XML) 1.0 (Third Edition)」(英語)を参照し、その日本語訳として、日本工業規格 JIS X 4159:2002(Second Edition相当。リンク先は該当規格の原案ですが、最終版とほぼ同等の内容です)と追補1として出版予定の原稿(Third Edition対応)を参照しています。本文中のピンクの地の部分は、XML 1.0勧告の原文を示しています。

文字符号化の自動検出(続き)

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

Note:

In cases above which do not require reading the encoding declaration to determine the encoding, section 4.3.3 still requires that the encoding declaration, if present, be read and that the encoding name be checked to match the actual encoding of the entity. Also, it is possible that new character encodings will be invented that will make it necessary to use the encoding declaration to determine the encoding, in cases where this is not required at present.
備考

これらの場合のうち、符号化を決めるために符号化宣言を読む必要がない場合においても、4.3.3は、符号化宣言(もし存在するなら)を読み込むことを要求しており、符号化の名前が実体の実際の符号化とマッチすることを確かめることを要求している。また、符号化を決めるために符号化宣言を用いる必要が現在はなくても、新しい文字符号化が発明されることによって符号化宣言を用いることが必要になることもあり得る。

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

外部の伝送プロトコル(すなわち、HTTP、MIMEなど)で与えられる情報が存在しない場合、XMLプロセサに渡された実体が、符号化宣言を含むにもかかわらず、宣言で示したもの以外の方式で符号化されているとき、または“印”(しるし)でも符号化宣言でも始まらない実体が、UTF-8以外の符号化を使用したときは、誤りとする。

 次は、未来は未知であり何が起こるか分からない、としている。具体的な事例を示すなら、例えば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(備考)が終わり、本文に戻る。

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).
この程度の自動判別でも、XMLの符号化宣言を読み込み、文字符号化の識別子を十分解析でき、識別子の解析は、類似するおのおのの符号化の1つ1つを区別するために必要になる(例えば、UTF-8を8859から区別するため、もしくは8859の各パートを区別するため、または使用している特定のEBCDICコードページを区別するため)。

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

ISO/IEC 8859-1:1998 Ed. 1 Current stage 90.93 JTC 1/SC 2
Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1 (available in English only)

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

  1/4

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


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


XML & SOA フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

HTML5+UX 記事ランキング

本日月間