第28回 文字符号化の問題に決着を付ける Page 2
川俣 晶
株式会社ピーデー
2004/12/17
次は、符号化宣言のEBNFによる生成規則である（EBNFの詳細については、第2回「XML勧告読解に必須のEBNF」を参照）。
Encoding Declaration
|
この定義はテキスト宣言の生成規則[77] TextDeclだけでなく、XML宣言の生成規則[23] XMLDeclからも参照されている。それ故に、外部解析対象実体の一部と思うのは間違いで、文書実体にも関係ある重要な生成規則である。
その内容はさほど難しいものではない。生成規則[80] EncodingDeclの方は、空白文字に続いて「encoding="……"」か、あるいは「encoding='……'」を記述できるということである。生成規則[25] Eqの定義により、「=」の前後には空白文字を入れることができる。「……」の部分は生成規則[81] EncNameにより定義が与えられている。これは、1文字目と、2文字目以降の定義が異なっている。1文字目は[A-Za-z]という定義により、大文字（A-Z）または小文字（a-z）のアルファベットを記述できることが分かる。2文字目以降は、([A-Za-z0-9._] | '-')*という定義により、1文字目の文字に加え、数字（0-9）、ピリオド記号（.）、アンダースコア記号（_）、マイナス記号（'-'）も使用できる。ここで、マイナス記号だけ単独で「|」記号で分離されているのは、この記号がEBNFの[……]構文で特別な意味を与えられた記号だからであろう。この記号は、A-Zのように、ある文字から別の文字までのすべての文字を示す機能を記述するために使われるのである。また2文字目以降には、0回以上の繰り返しを示す「*」記号が付いていることも確認しておこう。これにより、文字列の長さはいくらでも長くすることができる。しかし、1文字目の生成規則には「*」「?」といった記号はなく、省略できない。つまり全体として、1文字以上の長さが常にあり、0文字になることはできない。
生成規則[81] EncNameで表現される文字列は、この生成規則さえ守ればどんな文字列を書いてもよいわけではない。それについては、この後で詳しい説明が行われる。
次は、補足説明が続く。
In the document entity, the encoding declaration is part of the XML declaration. The EncName is the name of the encoding used. |
すでに書いたとおり、符号化宣言である生成規則[80] EncodingDeclはXML宣言の一部として記述される。
次の文章は、生成規則[81] EncNameは、文字符号化スキームの名前を記述するために使う、という意味である。
次は、符号化宣言に記述する文字符号化スキームの名前の詳細についての規定である。
In an encoding declaration, the values " |
符号化宣言では、値"UTF-8"、"UTF-16"、"ISO-10646-UCS-2"および"ISO-10646-UCS-4"は、UnicodeおよびJIS X 0221-1の各種符号化のために用い、値"ISO-8859-1", "ISO-8859-2", ... "ISO-8859-n"（ここでnはパート番号とする）は、ISO 8859の対応するパートのために用い、値"ISO-2022-JP"、"Shift_JIS"および"EUC-JP"は、JIS X 0208-1997の各種符号化のために用いることが望ましい。Internet Assigned Numbers Authority [IANA-CHARSETS]に、（charsetsとして）登録された文字符号化については、ここに挙げたもの以外についても、登録された名前で参照することが望ましい。それ以外の符号化は、接頭辞"x-"で始まる名前を使うことが望ましい。XMLプロセサは、文字符号化の名前を大文字・小文字の区別をせずにマッチをとることが望ましい。IANAに登録された名前は、IANAにその名前で登録された符号化を示すと解釈する、または不明であるとして扱うことが望ましい（もちろん、IANAに登録されたすべての符号化の実装をプロセサ に要求するものではない）。 |
冒頭の文章は長いが、さほど意味のあることをいっているわけではない。なぜなら、符号化の名前は次の文章で扱いが明りょうに規定されているためである。この文章は事例を列挙しただけ、という感がある。
ただし、「ISO-2022-JP」「Shift_JIS」「EUC-JP」の部分には意味がないとはいえない。なぜなら、JIS X 0208-1997の各種符号化のために用いることが望ましいと宣言することによって、暗にメーカー独自の機種依存文字の記述に使うのは好ましくないという意図を表現している、と読むこともできるためである。
次の文章はまるで補足文にすぎないかのような書き方だが、こちらの方が本来は主役となるべき文章だろう。インターネット上のさまざまな固有の番号や名前を登録する組織として、Internet Assigned Numbers Authority（IANA）が存在する。IANAは、文字符号化スキームの名前の登録を受け付けており、そのリストがCHARACTER SETSとして公開されている。UTF-8、UTF-16、Shift_JIS、EUC-JP、ISO-2022-JPなどの名前が文字符号化スキームの名前として正当である根拠はここにある。逆に、シフトJISを示すSJISという名前（Javaで初期の時代からシフトJISの名前として使用可能になっている）が、XMLの符号化宣言に記述すると誤りである根拠は、この名前がこのリストに登録されていないことにある。
次の文章はIANAの規定ではなく、根拠はMIME（Multipurpose Internet Mail Extensions）のRFCに求められるべきものではないかと思う。標準的に登録されていない名前は、先頭に「x-」を付けることで使用できるという規定が、RFC 2045などに見られる。
次の文章も、XML勧告独自の規定というよりも、CHARACTER SETSで記述された「However, no distinction is made between use of upper and lower case letters.（しかしながら大文字と小文字の使用に差はない）」という文章や、MIMEのRFCの規定を反映したものといえるだろう。
次はちょっと分かりにくい文章だが、逆に読むと分かる。ここでポイントになるのは、XMLプロセッサはIANAに登録された符号化をすべて実装しなくてよいということである。問題は、IANAに登録されていないか実装されていない符号化の扱いである。もし、IANAに登録されていない名前は「登録されていない」というエラーとし、登録されている名前は「実装されていない」というエラーとする、と決めたとすると困ったことになる。この2つのエラーを区別するために、すべてのXMLプロセッサは、IANAに登録されたすべての名前のリストを含む必要が発生する。しかし、IANAのリストは申請が通れば登録数が増えていくものである。変化し続けるリストを常に参照しなければXMLプロセッサが動作できないとすれば、XMLプロセッサの構造は複雑化してしまう。しかし、この規定により、IANAに登録されているが実装されていない名前は、「不明」とすればよいことになる。もちろん、IANAに登録されて「いない」名前も「不明」にして構わない。つまり、知らない符号化名はすべて「不明」扱いすればよく、XMLプロセッサはすべてのIANA登録名のリストを参照する必要がなくなる。（次ページへ続く）
 |
2/3 |  |
| Index | |
| やさしく読む「XML
1.0勧告」 第28回 文字符号化の問題に決着を付ける |
|
| Page
1 ・実体における文字符号化の問題解決を探る ・サポートすべき符号化の規定 |
|
 |
Page 2 ・符号化宣言のEBNFによる生成規則 ・符号化宣言に記述する文字符号化スキーム名 |
| Page 3 ・エラーとなる符号化のケース ・符号化宣言を含むテキスト宣言の例 |
|
 |
連載 やさしく読む「XML 1.0勧告」 |
- QAフレームワーク：仕様ガイドラインが勧告に昇格 （2005/10/21）
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か （2005/10/12）
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ （2005/9/13）
文字符号化方式（UTF-8、シフトJISなど）を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様（XKMS 2.0）が勧告に昇格 （2005/8/16）
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
 |
|
|
|
|
