第27回 実体における文字符号化の問題を整理する Page 2

川俣 晶
株式会社ピーデー
2004/11/18

外部解析対象実体の文字符号化

 では読み始めよう。まず、外部解析対象実体についての話題からである。

Each external parsed entity in an XML document MAY use a different encoding for its characters. All XML processors MUST be able to read entities in both the UTF-8 and UTF-16 encodings. The terms "UTF-8" and "UTF-16" in this specification do not apply to character encodings with any other labels, even if the encodings or labels are very similar to UTF-8 or UTF-16.

XML文書内の外部解析対象実体は、それぞれ別の文字符号化を用いてもよい。すべてのXMLプロセサは、UTF-8で符号化した実体、およびUTF-16で符号化した実体を処理できなければならない。この規定での“UTF-8”および“UTF-16”という用語は、その符号化がどれほど“UTF-8”または“UTF-16”に類似していても、ほかのラベルを持つ符号化には適用されない。

 最初の文章は、「XML文書=XML文書ファイル」と理解していると奇異に見えるかもしれない。XML文書が1ファイルで、外部解析対象実体も1ファイルだとすれば、XML文書内に別のファイルが入っているわけがない。しかし、「4 Physical Structures(4 物理構造)」の冒頭で、「XML文書は、1つ以上の記憶単位から構成する」と規定されていたことを思い出してほしい。ファイルとは記憶単位の一種である。つまり、XML文書が複数のファイルから構成されていても、何ら問題はないのである。われわれが安易にXML文書ファイルと呼んでいるものの正しい呼称はおそらく「文書実体ファイル」ということになるだろう。

 さて、話を本筋に戻すと、1つのXML文書を構成する外部解析対象実体は、それぞれ別の文字符号化を使ってもよい、ということを示している。統一する必要はない、ということである。1つがUTF-8で、別の1つがシフトJISであっても構わない、ということである。

 ただ1つ余談を付け加えておくと、現実的な運用においてはできるだけ統一しておいた方が安全であり、さらにUTF-16またはUTF-8を使うことがより確実であるといえる。なぜかといえば、ISO 10646/Unicodeと各文字符号化の間の変換テーブルに不統一があり、情報に互換性が取れないケースがあるためだ。例えば、あるシステムでシフトJISの外部解析対象実体と、UTF-8の外部解析対象実体に同じ文字を書き込んで、別のシステムで処理をしたとき、同じだった文字が異なる文字として処理されてしまう恐れがある、ということである。これは、XMLではなく、ISO 10646/Unicodeの問題点で、XML以外の利用分野でも問題になることである。詳しくはXML日本語プロファイルを参照してほしい。

 さて、話を戻して続けよう。次の文章は「2.2 Characters(2.2 文字)」において、「すべてのXMLプロセサは、Unicode 3.1のUTF-8符号化およびUTF-16符号化を受け付けなければならない」と書かれた内容の繰り返しである。つまり、UTF-8とUTF-16は受け付けなければならない必須のもの(MUST)であるということだ。

 余談だが、上記の「2.2 Characters(2.2 文字)」の文章に続いて、「2つのどちらが用いられているかを明示するためまたはほかの符号化を利用するための機構は、4.3.3 実体における文字符号化に記述する。」と書かれているが、そこに出てくる“4.3.3 実体における文字符号化”がいま読んでいる部分である。

 次の文章の意味は、特に解説しておく必要があるだろう。これは、本来必要のない規定といえるが、注意を喚起するために入れてあると思われる。これは、特に日本の過去の状況と関係があり、おそらくは村田真氏が入れさせたものではないかと思う。なぜ、この規定が日本と関係があるといえるのか。それは、いわゆる「機種依存文字」と関係が深いためである。

 例えば、電子メールの送受信で使われるISO-2022-JPという文字符号化スキームがあるが、実はISO-2022-JPと指定された電子メールの中には、これに違反するものが多数ある。具体的には、機種依存文字である丸付き数字を含む電子メールは違反していることになる。組織によっては丸付き数字の使用を規則で強制しており、送信できれば送信してしまうケースも多いだろう。しかし、ISO-2022-JPが参照している符号化文字集合はUS-ASCII、JIS X 0201、JIS X 0208だけであり、これらに丸付き数字は含まれない。つまり、丸付き数字の送信はISO-2022-JPという規定に違反していることになる。

 そして、話はここで終わらない。単に規定違反があるというだけならともかく、機種依存文字はメーカーごとに異なっている場合がある。そのため、規定違反を承知のうえで扱おうとしても、あるコードがどの文字に対応しているか、1つに確定できない場合が存在するのである。たとえ、完全に同一のビットの並びで構成された電子メールであっても、メーカーAの製品から送信された場合と、メーカーBの製品から送信された場合では、違う文字を入力した可能性があるのである。

 このような問題を回避するためには、「いかに類似していようと」厳密には異なるよく似た文字符号化スキームの名前を使ってはならない、ということになる。XMLは情報の長期保存や組織の枠を超えた交換に使われることが意図されるので、特定メーカー固有の亜種を許容することは存在意義の自己否定となる。それ故に、「過去の慣例上、暗黙的に許される」という解釈を許さないよう、明確にそれができないことを示す必要性があったのだろう。(次ページへ続く)

2/3

 Index
やさしく読む「XML 1.0勧告」 第27回
実体における文字符号化の問題を整理する
  Page 1
・実体における文字符号化の概要
・実体における文字符号化
Page 2
・外部解析対象実体の文字符号化
  Page 3
・Byte Order Markをめぐる根深い問題


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


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

注目のテーマ

HTML5+UX 記事ランキング

本日月間