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

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

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

■実体における文字符号化の概要

主な内容 --Page 1-- 実体における文字符号化の概要 実体における文字符号化 --Page 2-- 外部解析対象実体の文字符号化 --Page 3-- Byte Order Markをめぐる根深い問題

　前回は、「4.3 Parsed Entities（4.3 解析対象実体）」から「4.3.2 Well-Formed ParsedEntities（4.3.2 整形式の解析対象実体）」までを読んだ。解析対象実体は、XML勧告で規定される構文に沿って記述される実体である。しかし、そのバリエーションは多岐にわたる。内部実体、外部実体や、一般実体、パラメタ実体のバリエーションもある。また、XML文書のルートとなる文書実体も、一種の解析対象実体と見ることができる。これらを適切に記述し、活用しよう。また、似て非なるXML宣言とテキスト宣言の相違なども解説した。

　さて、まだ「4.3 Parsed Entities（4.3 解析対象実体）」は終わりではない。今回は、「4.3.3 Character Encoding in Entities（4.3.3 実体における文字符号化）」という大物を読んでいこう。これは、文書実体や外部解析対象実体の文字符号化について扱う。つまり、実体をUTF-8で記述したのか、シフトJISで記述したのか、といった相違を正しく判定する方法について記述している。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勧告の原文を示しています。

■実体における文字符号化

　それでは「4.3.3 Character Encoding in Entities（4.3.3 実体における文字符号化）」を読み始めよう。このタイトルでは「実体」という言葉が使われているが、それが示す対象は外部解析対象実体に限らない。ここで出てくる符号化宣言の生成規則[80] EncodingDeclは、実は「2.8 Prolog and Document Type Declaration（2.8 前書きおよび文書型宣言）」に含まれる生成規則[23] XMLDecl（XML宣言）からも参照されている。つまり、「実体における文字符号化」といった場合の実体には、外部解析対象実体のほかに文書実体も含まれるということである。しかし、あらゆる実体を含んではいないことにも注意が必要である。内部実体は、それ単独で存在することはないため、文字符号化の問題に直接かかわることはない。また解析対象「外」実体も、XML勧告によって解釈する対象に含まれないため、ここでは関係がない。

　次に、Character Encoding（文字符号化）という言葉だが、これはシフトJISやUTF-8といった、いわゆる「文字コード」あるいは「エンコーディング」のことを示す。しかし、XML勧告を正しく把握するには、示している対象がややあいまいな「文字コード」「エンコーディング」という言葉では不十分である。ここでは、より厳密に「Coded Character Set（符号化文字集合）」、「Character Encoding Scheme（文字符号化スキーム）」という2つの用語を確認しておこう。

　符号化文字集合とは文字に番号が付けられた文字表であると理解するとよいだろう。それに対して、文字符号化スキームとは個別の文字に対して特定のビット表現を対応付けるものである。符号化文字集合は、使用できる文字の種類を確定する働きを持つ。そして、文字符号化スキームはそれらの文字がどのようなビットの並びで表現されるかを確定する働きを持つ。この2つは両方がそろわないと機能しない。

　例えば、ISO 10646/Unicodeは、符号化文字集合の機能と、文字符号化スキームの機能を併せ持っている。まず、符号化文字集合の機能によって、「あ」という文字は「U+3042」という番号を割り当てられている。しかし、これだけではファイルに書き込んだり、通信回線を通して文字を送ることができない。「あ」という文字を表現するビット列は1つではないためである。そこで、文字符号化スキームの機能を使うことになる。

　文字符号化スキームがUTF-16（リトルエンディアン）であれば「0x42 0x30」というデータによって表現される。それに対して、文字符号化スキームがUTF-8であれば「0xE3 0x81 0x82」というデータによって表現される。これらは異なるビット列であるが、同じ「あ」という文字を表現している。どちらのビット列も、符号化文字集合の「U+3042」という番号に対応するためである。

　さて、ここでCharacter Encoding（文字符号化）という名前で出てくるものは、当然、Character Encoding Scheme（文字符号化スキーム）に対応する。XML勧告では、符号化文字集合は常にISO 10646と連動しており、利用者がこれを変更することはできない。しかし、文字符号化スキームにはいろいろなものを自由に選択して利用する余地が存在している。自由であることは便利だが、いろいろと悩ましい問題も発生する。ここでは、それらの問題にかかわる説明を読んでいくことになる。（次ページへ続く）

1/3

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

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

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