cxml-stpから。
この際だから、cxmlのDOMに立ちもどって確認する。
http://common-lisp.net/project/cxml/dom.html
をみる。
IDL/Lisp mappingというのはOMGが定めたもので、
http://www.omg.org/docs/formal/00-06-02.pdf
これ。Franzが作成支援したようだ。
さて、cxml-stpが主張しているのは、
** DOMはIDLをつかって規程されている。
** IDL/LISP mappingはOMGで標準化されている。
** だからといってDOM/LISP mappingが標準化されているとはいえないぜ。
** なので、IDL/LISP mappingに従わず、俺流 mappingをするぜ。
ということ。まあ、それはそうだ。
characters/strings instead of runes/rods って何だろ？
調べる。Unicodeに対応していない Lisp処理系にてUnicodeを扱うものな感
じ。
さらに調べる。closure-common packageで定義されているようだ。
--- runes.lisp ---
(deftype rune () '(unsigned-byte 16))
(deftype rod () '(array rune (*)))
(deftype simple-rod () '(simple-array rune (*)))
------------------
Unicodeを扱うためのものであることは間違いなさそうだ。
runeは英語の意味(ルーン文字/呪文)そのまんまから来たんだろうな。rod
は？stringがひもだからそれとの対応としてムチってことかな?
さて、Unicodeとか、UTF-8とかを正確に理解していないような気がする。
私の理解ではUnicodeというのは文字集合の定義とエンコーディング達の定
義を含む総称的な規格であり、その中でもUTF-8というのはPlan9を発祥と
するエンコーディングというものだった。だけどここではUnicodeに対応し
ているものはrune、そうでないものはutf-8という分け方がされている。
むぅ。Unicode 対応ということが何かがわかってないんだな、私は。
文字関係については、確か今夜わかるメールプロトコル、にあったような。
あった、自分なりの補足や調査も交えつつまとめる。
** 文字((graphic) character):
言葉を表記するために社会習慣として用いられる記号。
例: アルファベット、数字、ギリシャ文字、漢字、ひらがな、カタカナ。
** 文字集合(character set):
文字の集合。膨大な文字を計算機で扱いやすくするために、よく使う文字
だけを集めていることが多い。下記の例はcodedが入っていることからわか
るとおり、文字集合の定義だけでなく、次項の文字コードの定義も含んで
いる。ただし、文字集合が何を指すかというのは規格化団体毎に揺れがあ
る。
例:
ISO/IEC 8859-1:1998
Information technology - 8-bit single-byte coded graphic character
sets - Part 1: Latin alphabet No.1
JIS X 0208
7ビット及び8ビットの2バイト情報交換用符号化漢字集合
** 文字コード
文字集合に対して、それと数値を対応づける方式。文字符号化方式
(character encoding scheme)と呼ばれることもある。ただし、文字コード
が何を指すかというのは規格化団体毎に揺れがある。
例：
JIS X 0208は文字集合を規程するとともに、ISO-2022-JP、EUC-JP、
Shift_JISという3つの文字コードを規程している。
さて、ではUnicodeは？
** UnicodeはUnicode Consortiumが企画の策定・維持を行っている規格で
ある。
** The Unicode Standardという文書で規程している。
** The Unicode Standardではそれぞれの文字について、名前とコード
ポイントを定めている。code pointとは数値のことである。
** 現在の最新バージョンは5.1.0である。
** バージョン5.0とISO/IEC 10646は互換である。
** 5.1.0はWebで公開されている。しかしそのPDFは印刷できない。5.0は
書籍としても出版されている。
** The Unicode Standardは、character encoding standardである。
これ以降特にことわりがない限り、The Unicode Standard version 5.1.0
についての話とする。
** 3つのエンコーディング形式を定めている。a 32-bit form (UTF-32)、
a 16-bit form (UTF-16)、 an 8-bit form (UTF-8)。(あれ？ やはり
UTF-8とUnicodeに対する理解は間違っていなかった)
** コードポイントの総数は、1,114,112である。(百万以上)
** コードポイントの始めの65,536をBasic Multilingual Plane (BMP)と呼ぶ。
** コードポイントは、0から0x10FFFFまでの間の値をとる。
** 計算機でテキスト処理をするさいには、そのテキストの要素については
いろいろな表現形式や取り扱いがあるであろう。ここでは、テキスト要素
とはコードポイントであるとする。その意味で、コードポイントのことを
encoded characters(符号化文字)と呼ぶ。
** ここまでがだいたいChapter 1 Introduction。
** 続いてChapter 2 General Structure。
** Chapter 2 のアウトライン。
*** text representationとtext processingの本性について整理する。
*** The Unicode Design Prinsipleを紹介する。
*** the Unicode character encoding model を紹介する。そこでは、
character、code point、encoding forms という概念がそれらの相関ふく
めて導入される。これらによって、UTF-8、UTF-16、UTF-32の説明が可能
となり、これらエンコーディングの利点・欠点もあわせて説明する。
*** the Unicode codespaceを紹介する。
*** writing directionの話題を説明する。
*** equivalent sequencesとnormalizationを説明する。
*** the Unicode Standardに対するcomformanceについてざっくりと説明す
る。(お、ここでUnicode対応とはなんぞやがわかるかも)
** 2.1 Architectual Context
character code standardというのはそれ自体が計算機のテキスト処理のア
プリケーションを成しているわけではなく、有用なアプリケーションをつ
くるための部品である。部品であるがゆえ、様々な用途に使われる。それ
ゆえすべての用途のrequirementsをみたしたものを作るのは不可能であり、
それらをいい感じでみたすようなバランスをとることになる。
*** Basic Text Processes
たいていの計算機では、low-levelのテキスト処理機能をまず用意して、
それをもとに多様なテキスト処理が組み立てられる。このlow-levelの部
分をBasic Text Processesと呼ぶ。
**** Rendering characters visible
**** Breaking lines while rendering
**** Modifying appearance, such as point size, kerning,
underlining, slat and weight
**** Determining units such as "word" and "sentence"
**** Interacting with users in processes such as selecting and
highlighting text
**** Accepting keyboard input and editing stored text through
insertion and deletion
**** Comparing text in operations such as in searching or
determining the sort order of two strings
**** Analyzing text content in operations such as spell-checking,
hyphenation, and parsing morphology
**** Treating text as bulk data for operations such as compressing
and decompressing, truncating, transmitting, and receiving
*** Text Elements, Characters, and Text Process
なにがtext elementであるということは、どういうtext processにおいて？
ということと不可分である。普遍的なというか、text processと独立して
いるようなtext elementsの定義は存在しない。
例えば、英語の"A"と"a"はレンダリングでは別のものだが、語を検索する
ときには同じと扱われる。ドイツ語では、letter combination "ck"は、
ハイフネーションするときは"k-k"として分離して扱うが、sortするとき
は"ck"を一体として扱う。
また、英語でspell-checkするときは、"the quick brown fox,"の"fox"が
テキスト要素になる。
で、Unicodeがcharacter encoding standardとして定めているのは、text
elementsでなく、もっとアトミックなcharacterですよ。それを特定する
code pointsですよ。それらをassigned characterと呼びますよ。
charactersからtext elementsを作る形態は4つある。
**** composite (合成)
**** Collation Unit (照合単位)
**** Syllable (音節(を表わすつづり文字))
**** Word (語)
*** Text Processes and Encoding
the Unicode Standardは特定のbasic text-processing algorithmsに依存
しないように設計している。
** 2.2 Unicode Design Principles
---
Universality: The Unicode Standard provides a single, universal
repertoire.
Efficincy: Unicode text is simple to parase and process.
Characters, not glyphs: THe Unicode Standard encodes characters,
not glyphs.
Semantics: Characters have well-defined semantics.
Plain text: Unicode characters represent plain text.
Logical order: The default for memory representaion is logical
order.
Unification: The Unicode Standard unifies duplicate characters
withiin scripts across languages.
Dynamic composition: Accented forms can be dynamically composed.
Stability: Characters, once assigned, cannot be reassigned and key
properties are immutable.
Convertibility: Accurate convertibility is guaranteed between the
Unicode Standard and other widely accepted standards.
---
今、興味があるものだけ深掘りする。
*** Characters, Not Glyphs
Characters: 書き言葉の最小単位の抽象表現である。ここで書き言葉は意
味論上の価値を持つものに限る。代表的なものとして、letters、
punctuation、signsなどがある。自然言語で使われるlettersをグルーピ
ングしたものはscriptsと呼ぶ。あるletterが異なるscriptsに属すること
もあろう。そして、それが意味論的にも見た目的にも同一だとする。それ
でもUnicodeはそれらを別のcharactersとして扱う。scriptsの分類が優先
ということ。
glyphというのは要は見た目のこと。ただし、単一のletterに関するもの
だけではなく、letterの連続もあることに注意たとえば、英語の筆記体に
て"fox"と単語で書くときと"f""o""x"と個別に書くときではglyphが違う。
fontというのは、Rendering processにおけるUnicode charactersから
glyphsへのマッピングである。
*** Semantics
Unicodeのsemanticsは、characterの名前やcode table上の位置などでは
な定義しない。すなわち暗黙の定義はしない。character propertiesで明
示的に定義する。それらを格納したものをThe Unicode Character
Databaseと呼ぶ。このdatabaseの情報をもとに、parsing、sortingなどの
アルゴリズムを構築する。
Unicode流のアプリケーションプログラミングをする場合、このdatabase
のsemanticsを核におくことになり、i18n対応のためのcode set indepent
modelは不要になる。code set indepent modelでは、byte-streamの
semanticsはcode set毎に異なるという見地から、byte-streamの取り扱う
際には、個別のcode setの個別に定義されたsemanticsを選択的に適用する
機構を有するものである。これがUnicodeでは不要となる。もちろん例えば
UTF-8を単なるcode setの追加と位置付けて、code set independet model
で取り扱うことも可能ではあるが。
*** Unification
scriptsという概念とlanguagesという概念はUnicodeでは別。そして、先
程書いたように、同じletterが別のScriptに属するならば、そのletterの
Semanticsや見た目が同じでも別のcharacterとするが、別のlagnguageで
使用されるletterであってもそれを同じscriptにまとめらるならば統一し
て単一のcharacterにしてしまう、ということ。
** 2.3 Compatibility characters
ここは今の興味には無関係なので割愛。
** 2.4 Code Points and Characters
抽象的であるcharactersという概念は、計算機の内部では、具体的に数と
して表現される。
その数の値域をcodespaceと呼ぶ。その中のひとつの数をcode pointと呼
ぶ。
code pointとencoded characterは一対一対応ではない。例えば、Aの上に
○があるabstract character の eEncoded characterは、次の3通りがある。
code point : 00C5
code point : 212B
code point : 0041 + code point : 030A
最後のものは、letter A のcode pointとletter 上付き○のDynamic
Compositionである。
Unicodeのcode pointの表記の関連は、"U+" + 16進数である。
U+0061 LATIN SMALL LETTER A
U+201DF CJK UNIFIED IDEOGRAPH-201DF
*** Types of Code Points
code pointsはいくつかの観点でカテゴライズできる。
基本的な分類は次のとおり。
---
Graphic:
Letter, mark, number, punctuation, symbol, and spaces
Assigned to abstract character
Format:
Invisible but affects neighboring characters; includes
line/paragraph separators
Assigned to abstract character
Control:
Usage defined by protocols or standards outside the Unicode
Standard
Assigned to abstract character
Private-use:
Usage defined by private agreement outside the Unicode standard
Assigned to abstract character
Surrogate:
Permanently reserved for UTF-16; restricted interchange
Not assigned to abstract character
Noncharacter:
Permanent reserved for internal usage; restricted interchange
Not assigned to abstract character
Reserved:
Reserved for future assignment; restricted interchange
Not assigned to abstract character
---
** 2.5 Encoding Forms
計算機は数というものを数学上の数そのままとしてではなく、fixed-size
units で取り扱う。例えばbyteとか32-bit wordsとか。character
encodingはそういう現実に則して設計する必要がある。
計算機上で整数は特定のcode unitsとして実装される。ここでcode units
は、たいていが、8-bit、16-bit、32-bitである。
そこで、Unicodeのencoding formsでは、それぞれのcode point(整数)を
どのようにa sequence of code unitsとして表現するかを規程している。
The Unicode Standardでは、code units 8-bit, 16-bit, 32-bitに対応し
て、次の3のencoding formsを提供している。
UTF-8, UTF-16, UTF-32
UTFは、Unicode (or UCS) Transformation Formatの略である。
これらはどれも表現力として等価であり、相互変換がロスレスで可能であ
る。
*** Non-overlap
CP932等はoverlapするが、Unicodeはoverlapしない。これは便利。
どういうことかというと、CP932は1byteまたは2byteで表現するのだが、
2byteのleading byteと1byteが衝突することはないが、1byteと2byteの
trailing byteは数として衝突することがある。これは衝突している文字
(1byte)側を検索するときなどやっかいである。
The Unicode encoding formsではこの心配はない。lead、trail、single
だろうがなんだろうが、何かを表現している数にoverlapは存在しない。
*** Conformance
"The Unicode Consortium fully endorses the use of any of the three
Unicode encoding forms as a conformant way of implementing the
Unicode Standard. It is important not to fall int the trap of
trying todistinguish "UTF-8 versus Unicode," for example."
あり？ ということは、cxml-domの記述はおかしくないか？
やはり私のそもそもの理解でただしかったのか？
もう少しUnicodeを読みといてから、考える。
*** Examples.
AΩ語(不思議な文字)
UTF-32 00000041 0000003A9 00008A9E 00010384
UTF-16 0041 03A9 8A9E D800 DF84
UTF-8 41 CE A9 E8 AA 9E F0 90 8E 84
*** UTF-32
もっともシンプル。code pointの数とcode unitの数が一対一対応。
値域は0..0x10FFFF。いわずもがなだが、code pointと同じ。
なので、U+0000..U+10FFFFというcode pointの表記そのままがencodingの
値である。
*** UTF-16
U+0000..U+FFFF (BMP)は、そのまま16-bit code unitひとつで表わす。
U+10000..U+10FFFFは、2つの16-bit code unitsであらわす。このペアを
surrogate pairと呼ぶ。surrogate pairに割り当てる領域は先の単一の
encodingに使われる領域とは隔離されている。これがnon-overlapを実現し
ている。
*** UTF-8
U+0000..&+007F ASCII code points (0x00..0x7F)
それ以外は、Table 3-6をみるのがよさげ。
うーん。とりあえず、ここまで。次回は2.6 Encoding Schemes。
なんかUnicodeのお勉強になっているが、ま、気にしない。
こつこつ。
0 件のコメント:
コメントを投稿