第35回 要素や属性の名前に使用できる文字の規定 Page 2
川俣 晶
株式会社ピーデー
2005/7/6
次は、このリストがいかにして作成されたかという根拠について説明されている。
The character classes defined here can be derived from the Unicode 2.0 character database as follows: |
ここで定義する文字クラスは、Unicode 2.0の文字データベースから、次のとおりに得ることができる: |
この文章は、リストの根拠を示すとともに、なぜXML勧告が文字のリストを含む必要があるのかという理由も示している。つまり、このリストは、Unicode 2.0に含まれる何らかの定義をそのまま利用しているわけではなく、以下のようなルールによって再構成されていることを示している。すなわち、Unicode 2.0を参照仕様として示すだけでは不十分なのである。
ここで、ルールさえ明確に示せば十分ではないか、という疑問はあり得るだろう。Unicode 2.0の文字データベースと以下のルールだけ示せば、必ず同じ文字リストが得られるのだから、それを重複して掲載することは無駄であるばかりか、ちょっとした表記の解釈の違いから問題を引き起こしかねない可能性もある(前回「XML勧告を理解するために必要な外部の文書」参照)。しかし、文字クラスのリストに関しては、別の懸念があり得る。つまり、自然言語(英語や日本語)で書かれたルールは、自然言語であるという理由からあいまいさが入り込む可能性があり、常に同じ文字リストを得られない可能性があり得るのである。しかも、文字クラスのリストを得る作業は決して楽なものではない。手間もかかるし、ミスが入り込む余地もある。それらを総合的に配慮すれば、たとえ重複する定義を行う懸念があるにせよ、ここに文字クラスのリストをすべて掲載する価値があるのではないだろうか。
さて、具体的にUnicode 2.0の文字データベースとは何だろうか。おそらく『Unicode 2.0の書籍』に付属のCD-ROMに含まれる\DOS\UNIDATA(\MAC\UNIDATAと\UNIX\UNIDATAも同じと思われる)ディレクトリに格納されたドキュメントを示していると考えていたのだが、あらためて調べてみるとどうも違うらしい。というのは、これと同じUnicode 2.0の文字データベースが、Unicodeコンソーシアムのhttp://www.unicode.org/Public/2.0-Update/にあるのだが、マイナーバージョンアップされているようで、CD-ROM収録のデータベースと内容が一致していないのである。では、XML勧告は、どのバージョンを具体的に参照しているのかというと、これは明確に示されていない。いくつかの文字をチェックしてみたが、書籍収録版ではなく、Unicodeコンソーシアムのサイトにある最終版(2.0.14)と一致した。すべてが一致しているかどうかは分からないが、おそらくは最終版に一致していると思ってよいのではないかと思う。
Unicode 2.0の文字データベースはテキストファイルなので、参照するのは容易である(その意味を理解するには解説文を読まねばならないが)。
大体のイメージをつかんでいただくために、いくつかの行を抜き出して紹介しておこう。なお、最初の16進数は文字番号、その後の文字列が名前、その後に続く略語などのうち、読み取るのに必要な情報はこの後に説明を行う。
0030;DIGIT ZERO;Nd;0;EN;;0;0;0;N;;;;; 0041;LATIN CAPITAL LETTER A;Lu;0;L;;;;;N;;;;0061; 00A5;YEN SIGN;Sc;0;ET;;;;;N;;;;; 30AB;KATAKANA LETTER KA;Lo;0;L;;;;;N;;;;; FF76;HALFWIDTH KATAKANA LETTER KA;Lo;0;L; |
では、個々のルールを見ていこう。「JIS X 4159」では個々の項目にアルファベット小文字の項番が付いているが、これはJISの書式のルールによるもので、本来は存在しないものである。
まずは最初のルールから。
|
|
Ll、Lu、Lo、Lt、Nlという意味不明の略語が出てきたが、これはUnicodeの文字データベースで使用される用語である。略語の一覧をUnicodeの文字データベースのreadmeファイルの一覧から以下に引用する(なお、補足的に付加したカッコ内の日本語表記は、『Unicode標準入門』 p116 表5-2 UnicodeData.txtの一般カテゴリの値の表記に合わせた)。
Normative Mn = Mark, Non-Spacing(結合文字―幅なし) Mc = Mark, Spacing Combining(結合文字―幅あり) Me = Mark, Enclosing(結合文字―囲み) Nd = Number, Decimal Digit(数―10進数字) Nl = Number, Letter(数―字) No = Number, Other(数―そのほか) Zs = Separator, Space(分離子―空白) Zl = Separator, Line(分離子―行) Zp = Separator, Paragraph(分離子―段落) Cc = Other, Control(そのほか―制御) Cf = Other, Format(そのほか―書式) Cs = Other, Surrogate(そのほか―サロゲート) Co = Other, Private Use(そのほか―私用) Cn = Other, Not Assigned(そのほか―未割り当て) Informative Lu = Letter, Uppercase(字―大文字) Ll = Letter, Lowercase(字―小文字) Lt = Letter, Titlecase(字―タイトル文字) Lm = Letter, Modifier(字―修飾) Lo = Letter, Other(字―そのほか) Pc = Punctuation, Connector(句読点―接続) Pd = Punctuation, Dash(句読点―ダッシュ) Ps = Punctuation, Open(句読点―開き) Pe = Punctuation, Close(句読点―閉じ) Po = Punctuation, Other(句読点―そのほか) Sm = Symbol, Math(記号―数学) Sc = Symbol, Currency(記号―通貨) Sk = Symbol, Modifier(記号―修飾) So = Symbol, Other(記号―そのほか)
NormativeとInformativeの意味は前回「XML勧告を理解するために必要な外部の文書」で説明したが、それぞれ規定と参考という意味である。しかし、Informativeの分類も、XML勧告の規定を定めるためには必要とされていることに注意が必要である。
なお、name start characters(名前開始文字)とは、要素や属性の名前の最初の1文字として使用される文字を意味する。
|
|
名前開始文字以外の名前文字とは、要素や属性の名前の2文字目以降の文字を意味する。Mc、Me、Mn、Lm、Ndの意味は上記の表のとおりである。ここで注意が必要なのは、この文章は名前開始文字の名前文字に加え、2文字目以降はこれらの文字も認めるといっていることである。決して2文字目以降は1文字目で許可した文字を使えないという意味ではない。つまり、2文字目以降に使用できる文字は、Ll、Lu、Lo、Lt、Nl、Mc、Me、Mn、Lm、Ndということになる。
|
|
互換用領域とは、仕様の整合性から本来は入れたくなかったが、互換のためにやむを得ず収録した文字を意味する。この中には、機種依存文字としての漢字や、半角カタカナ、全角アルファベットなども含まれる。つまり、これらの文字は要素や属性の名前としては使用できない。データベースのフィールド名に半角カタカナや全角アルファベットを使用していて、それをそのままXMLの要素名などに使おうとしてエラーになる、というのはXMLのFAQであるが、その理由はここにある。カタカナは全角、アルファベットは半角を用い、幅を変えたいときにはフォントを用いて行うというのが、「建前上」の正しい文字の扱いである。ちなみに、この記述はUnicode 2.0に対しては正しいが、その後のUnicodeでは、当初互換文字として収録した漢字を正規に認知するケースがあり、#xF900より大きく#xFFFEより小さい文字のすべてが互換文字とは限らない状況になっているそうである。
|
|
データベース内の5番目のフィールドとは、もちろん上記のUnicodeデータベースのテキストファイルに書き込まれた各行の内容のうち、5番目に記述された情報を意味する。
|
|
このあたりは、日本では一般的な文字ではないので、なぜ類似すると見なしてよいか筆者には説明できない。ちなみに、Unicodeデータベースでは以下に該当する。
02BB;MODIFIER LETTER TURNED COMMA;Lm;0;L;;;;;N;;;;; 02BC;MODIFIER LETTER APOSTROPHE;Lm;0;L;;;;;N;;;;; 02BD;MODIFIER LETTER REVERSED COMMA;Lm;0;L;;;;;N;;;;; 02BE;MODIFIER LETTER RIGHT HALF RING;Lm;0;L;;;;;N;;;;; 02BF;MODIFIER LETTER LEFT HALF RING;Lm;0;L;;;;;N;;;;; 02C0;MODIFIER LETTER GLOTTAL STOP;Lm;0;L;;;;;N;;;;; 02C1;MODIFIER LETTER REVERSED GLOTTAL STOP;Lm;0;L;;;;;N;;;;; 0559;ARMENIAN MODIFIER LETTER LEFT HALF RING;Lm;0;L;;;;;N;;;;; 06E5;ARABIC SMALL WAW;Lm;0;R;;;;;N;;;;; 06E6;ARABIC SMALL YEH;Lm;0;R;;;;;N;;;;; |
|
|
Unicode 2.0の5.14とは、「5.14 Identifiers」を意味し、識別子の記述方法について述べている。合成文字の特別な構文で使用されるので、特に除外しているというように読めるが、残念ながらUnicodeのエキスパートではない筆者には完全に解説することができない。ちなみに、Unicodeデータベースでは以下に該当する。
20DD;COMBINING ENCLOSING CIRCLE;Me;0;L;;;;;N;ENCLOSING CIRCLE;;;; 20DE;COMBINING ENCLOSING SQUARE;Me;0;L;;;;;N;ENCLOSING SQUARE;;;; 20DF;COMBINING ENCLOSING DIAMOND;Me;0;L;;;;;N;ENCLOSING DIAMOND;;;; 20E0;COMBINING ENCLOSING CIRCLE BACKSLASH;Me;0;L;;;;;N;ENCLOSING CIRCLE SLASH;;;; |
|
|
プロパティリストとは、Unicodeデータベースを構成する別のファイルとして存在するデータを意味する。上記サイトの「PropList-2.0.14.txt」の「Property dump for: 0x20000040 (Extender)」という項目に「00B7」の値が書かれているが、このファイルでは根拠は示されていない。ちなみに、Unicodeデータベースでは以下に該当する。
00B7;MIDDLE DOT;Po;0;ON;;;;;N;;;;; |
|
|
正準形とはつまり正規化して同じものとして扱う形であるが、それを配慮して名前文字に追加するということである。ちなみに、Unicodeデータベースでは以下に該当する。
00B7;MIDDLE DOT;Po;0;ON;;;;;N;;;;; 0387;GREEK ANO TELEIA;Po;0;L;00B7;;;;N;;;;; |
|
|
これは、Unicodeの文字分類からの明らかな逸脱である。しかし、おそらくはSGMLとの互換性のために許す必要がある文字なのではないかと推測する。ちなみに、':'は名前空間併用時には、名前文字ではなく、接頭辞と局所名を区切る記号になるのはいうまでもない。
|
|
これも、Unicodeの文字分類から逸脱するXMLの特殊ルールである。
以上で、「B Character Classes(附属書B(規定)文字クラス)」を読み終えた。実は今回の内容を書くに当たって、筆者もいろいろと勉強を行った。やや古い書籍となる洋書の『Unicode 2.0』や、日本語訳の『Unicode入門』が手元にあったことで、今回の原稿はやっと成立したという印象である。なぜ追加の勉強を必要としたのかといえば、通常の利用方法ではリストだけ見れば十分であり、その根拠まで厳密に読む必要が存在しないためである。しかし、この連載の趣旨からすれば、書かれた説明はひととおり解説を要する。解説を行うために必要な技術情報がどこにあるかはすでに知識として把握していたので、それらを調べて解説を書き下ろした。なお、筆者は(一部に誤解している方々いるかもしれないが)Unicodeの批判者、あるいは応援者であったことはあるが、Unicodeに関するプロというわけではないので、間違いがあれば編集部までご一報いただきたい。
◇
さて、次回はAppendicesの続き、「C XML and SGML(Non-Normative)(附属書C(参考)XMLおよびSGML)」以降を読んでいこう。XML and SGMLは、XMLとSGMLの関係を説明している短い文章である。次の、「D Expansion of Entity and Character References(Non-Normative)(附属書D(参考)実体参照および文字参照の展開)」は、実体と文字参照の展開に関する説明を記したものである。どちらも、「参考」であって「規定」ではないが、より分かりやすくするために補足された文章なので、読む価値がある。(次ページへ続く)
2/3 |
Index | |
やさしく読む「XML
1.0勧告」 第35回 要素や属性の名前に使用できる文字の規定 |
|
Page
1 ・文字クラスについて ・名前とトークン再び ・文字クラス(Character Classes) |
|
Page 2 ・文字クラスのルール |
|
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」の詳細も紹介する
|
|