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

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

　次は、US-ASCIIとの互換性の有効性とその限界について記述している。

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.
符号化宣言の内容を ASCIIレパートリーにある文字（どのように符号化される場合であっても）に限定しているので、どの系統の符号化が使用されているかを検出すれば、プロセサは符号化宣言全体を正確に読み込むことができる。現実問題として、広く使用されている文字符号化は前述の系統のいずれかにあてはまるので、オペレーティングシステムまたは伝送プロトコルが与える外部情報を信頼できないときでも、内部ラベルで文字符号化をかなり正確に示すことがXML符号化宣言によって可能となる。ASCIIのコード値を持つバイトを過度に用いる文字符号化（例えばUTF-7）は、確実に検出できないことがある。

　ここで書かれていることは、逆にいえば、安全に符号化方式を判定するためには、符号化宣言に使用される文字の種類は制限されねばならないことを意味する。例えばI18N（Internationalizatoin＝国際化）を至上の価値と信じ、世界のどのような文字を用いても符号化宣言を記述できるように仕様を拡大することは、この部分に限っては誤りとなる。

　次の外部情報が信頼できないという事例は決して珍しくない。例えば、1つのWebサーバ上にシフトJISのファイルと、EUC-JPのファイルと、UTF-8のファイルが混在していることなど珍しくもないし、それらに対して正しいcharsetパラメタ（後で詳しく取り上げる）が常に付いているという前提も取れないだろう。それでも、符号化方式を確定する手段を提供することは、XMLの実用性を高めるための1つの方策ということができる。

　次は、UTF-7はモードを切り替えることで、US-ASCIIに属する同じコードに複数の意味を与える方式である。つまり、符号化方式が不明のまま、ASCIIと互換性があるという前提で判定を行うことは誤判定の可能性がある。しかし、事実上UTF-7は「死んだ」標準であり、これが問題になることはまずないだろう。逆にいえば、このような問題があるからこそ、UTF-7はUTF-8に後を委ねて引退せざるを得なかったともいえる。

　次は、適切に動作する実装が可能であることについて述べられている。

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.
プロセサが文書の符号化を検出しさえすれば、それぞれの場合に対して別の入力ルーチンを呼び出すか、または入力する各文字に対し適切な変換関数を呼び出すことによって、適切に動作することができる。

　これは、XMLプロセッサの入力の実装の方法が2種類あり得ることを間接的に示している。1つは、符号化方式ごとに存在する入力ルーチンを、符号化方式が確定した時点で切り替える方法。もう1つは、バイト列として入力したうえで、バイト列を文字に変換する変換関数を呼び出すことで文字を得る方法で、符号化方式が確定した後、呼び出す変換関数を切り替えていく方法である。これは実装ヒントのような記述であるが、実装方法を決して1種類だけ想定しているわけではないことを示すために書かれたものだろう。

　次は、符号化宣言を変えずに符号化方式を変更してはならないことを記述している。

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.
自分自体にラベル付けをするいかなるシステムでも同様だが、ソフトウェアが、符号化宣言を更新せずに実体の文字集合または符号化を変えれば、XMLの符号化宣言は機能しない。文字符号化ルーチンの実装者は、実体のラベル付けに使用する内部および外部の情報の正確さの保証に注意すべきである。

　例えば、シフトJISで記述されたXML文書をテキストエディタで読み込み、それに一切修正を加えることなくUTF-8で保存したとしよう。すると、このXML文書に含まれる符号化宣言はシフトJISのままであるのに、UTF-8で保存されているという矛盾状態が発生する。このような状態は、例えば文字コードを変換するプロキシサーバによって発生する可能性がある。XML宣言を理解しないプロキシサーバは、本体の符号化方式を変更してしまうかもしれないが、XML宣言を書き換えることはない。それにより、正常な動作は望めなくなる。このような状態は回避しなければならない。

■外部の符号化情報が存在するときの優先順位

　さて、ここからは「F.2 Priorities in the Presence of External Encoding Information」、JIS X 4159では「F.2 外部の符号化情報が存在するときの優先順位」を読んでいこう。XMLの実体がプロセッサに渡されるとき、外部情報を伴うかどうかによって2つの場合に分けたが、ここは情報が存在する場合についての記述である。

　事実上、1段落と1行しかないので、一気に読んでいこう。

The second possible case occurs when the XML entity is accompanied by encoding information, as in some file systems and some network protocols. When multiple sources of information are available, their relative priority and the preferred method of handling conflict should be specified as part of the higher-level protocol used to deliver XML. In particular, please refer to [IETF RFC 3023] or its successor, which defines the text/xml and application/xml MIME types and provides some useful guidance. In the interests of interoperability, however, the following rule is recommended.
2番目の場合は、XMLの実体のほかに、いくつかのファイルシステムおよびネットワークプロトコルでは、その符号化についての情報が存在する。複数の情報が利用できるとき、それらの相対的な優先度と、それらが矛盾したときの望ましい処理方法とは、XMLの配送に使用するより高水準のプロトコルの一部として規定するのがよい。特に、MIMEタイプtext/xmlと application/xmlを定義しており、いくつかの有用な指示を与えている[IETF RFC 3023]またはその後継RFCを参照されたい。相互運用性のため、次の規則を推奨する。

　ファイルシステムやネットワークプロトコルが、符号化方式の情報を持つことがある。例えば、HTTPではcharsetパラメタによって符号化方式を指定することができる。よくHTML文書には符号化方式を明示するmetaタグを付けろといわれることがあるが、ここでいうmetaタグとは、HTTPのプロトコルの一部として送信すべき情報をHTML文書に埋め込むための手段として使われるものであって、本来はプロトコルの一部である（詳しくは、歴史的に有名な文書である「charsetパラメータの勧め：HTMLにおける文字符号化スキームの明示方法」を参照）。

　ということは、もちろんXML文書を送信する際にも、charsetパラメタは付加することができるし、それは重要な意味を持つことを意味する。つまり、XML文書の符号化宣言とHTTPのcharsetパラメタはどちらも独立して指定可能であり、相矛盾する指定を行うことも可能だということである。

　次は、その矛盾状況に対する言及である。

　矛盾した場合の対処方法は、XML勧告の階層から何かをいえるわけではなく、より高水準の階層で規定すべき問題だということである。とはいえ、一般論からいえば、符号化宣言よりもプロトコルが指定する符号化の指定を優先すべきだろう。なぜなら、通信システムの都合で符号化方式の変換が発生した場合、プロトコルに含まれる符号化方式は正しい情報を含んでいる可能性が高いからである。一方、符号化宣言を扱わないシステムにより変換が行われた場合、符号化宣言は現状に合致しない符号化方式を示している可能性があり得る。

　ちなみに、高水準プロトコルの一部というわけではないが、「RFC 3023 "XML Media Types"」が、charsetパラメタと符号化方式の関係を規定している。次は、そのことを説明している。

　最後の文の「相互運用性のためには」とは以下の定義の意味である。

1.2.1.8 相互運用性のためには（for interoperability）

拘束力は持たない推奨事項について記述する文を示す。ISO 8879へのWebSGML適用附属書以前から存在するSGMLプロセサが、XML文書を処理できる可能性を高めるために、これらの推奨事項を取り入れる。

　つまり、従来のSGMLプロセッサで処理を行う可能性を高めるために推奨されるルールである。内容は以下のとおりである。

  • If an XML entity is in a file, the Byte-Order Mark and encoding declaration are used (if present) to determine the character encoding.
  • XMLの実体がファイルに存在すれば、“印”（しるし）および符号化宣言は、（存在すれば）文字符号化を決定するために使用する。

　JIS X 4159では、項目が1つしか存在しないにもかかわらず「a)」と先頭に付加されているが、文書作成のルールを硬直的に適用して発生する不自然な状況といえるだろう。

　残念ながら、この文章の意味を、SGMLには縁遠い筆者には正しく説明することができない。現在のXML利用者がSGMLプロセッサを使用するチャンスがほとんどあり得ないことから考えれば、無視してもよい規定だろう。（次ページへ続く）

2/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 記事ランキング

本日月間
＠IT