■Ext.Bの符号位置をdecodeして対応する文字オブジェクトを作る方法
→&U-00029C0F;ではなく、 UCS に対しては C0F; みたいな数値参照を用いる
■写像一般
ucs : Unicode 本例示字形に基づく写像（Ext-B は ISO/IEC 10646-2:2001 の例示字形に基づく）
ucs-gb : GB に基づく写像
ucs-jis : JIS に基づく写像（各年版の共通部分）
=ucs-jis-1990 : JIS X 0208:1990 + JIS X 0212:1990 を優先した JIS に基づく写像
=ucs-jis-2000 : JIS X 0213:2000 を優先した JIS に基づく写像
ucs-ks : KS に基づく写像
ucs-cns : CNS 11643 に基づく写像
ucs-big5 : Big5 に基づく写像
以上は、それぞれ対応する => がある。「=foo」は「=>foo かつ <=foo」を意味する。
将来的には、全て =foo スタイルに変わる。また、=ucs-jis-2003が登場する予定。
■変換付き継承
ucs-bmp : ucs の 0 群 0 面
ucs-smp : ucs の 0 群 1 面を 0 から番号付けしたもの (ucs - #x10000 但し #x10000 <= ucs <= #x1FFFF)
ucs-sip : ucs の 0 群 2 面を 0 から番号付けしたもの (ucs - #x20000 但し #x20000 <= ucs <= #x2FFFF)
ucs
+----------------------------+
+---------+-------+------+-------+ |変換付き
| | | | | |継承
ucs-gb ucs-jis ucs-ks ucs-cns ucs-big5 |
| +-------+-------+
+-------+------+ | | |
| | ucs-bmp ucs-smp ucs-sip
=ucs-jis-1990 =ucs-jis-2000
■変換処理詳細
→chise_decode_defined_char はデータベースを引く処理
→chise_decode_builtin_char は組込み文字を作る処理
→ucs は system-char-id を identical 継承したものとして実現されているので、
chise_decode_builtin_char は code_point を system-char-id と見倣す
CHISE_CHAR CHISE_DECODE_CHAR (CHISE_CCS ccs, int code_point, bool defined_only)
{
CHISE_CHAR chao = chise_decode_defined_char (ccs, code_point);
if (defined_only || !CHISE_CHAR_NILP (chao))
return chao;
else
return chise_decode_builtin_char (ccs, code_point);
}
■IDS text fileの詳細
IDSテキストファイルは、それぞれのCCSの符号位置とその字形を表示するための
画像としてのisolated characterを元に、アルバイトがIDSを入力していったもの。
つまりIDSが入力されているものは、その字が存在すると考えてよい。
checkしていないので間違いが含まれている可能性はある。JISは優先してcheckしてある。
対応する属性が定義されていないのは、単においついていないためである。
字形入力に比べて属性定義は専門知識が必要である。
その場合は単にisolated characterとして利用することができる。
属性が無いわけだがその所属する漢字集合を同定することはできる。
本来字が存在するのだから、その字の読み込みをした時点で、
ucsなどのpropertyを勝手につければいいのではないか。
JISとUCS系は違うデータソースが元になっている、入力方法の違い、
字形のゆらぎなどからまったく同一のデータとはなっていない。
JISの入力においてはできるだけ大漢和字典の字形に統一するという
フィルターを一次近似としてかけている。
UCS系の入力方法として使った四角号碼は内部的にCNSのコードを
使用している。字形のゆらぎの判断基準は用意されていなかった。
Unicodeの中には康熈字典のおける部首を漢字そのものとして扱った符号位置と、
部首として扱った符号位置との二つが存在している。つまり二つを違う
スクリプトに属するものとして区別している。
現在データ中にどちらがどの程度採用されているのかはまだわからない。
■CCSの符号位置から文字オブジェクトの作り方
あるUCSの値があるとしてそこから文字オブジェクトを作るにはどうしたらい
いか。CHISEデータベースでは字形のゆらぎをUCSの元になった文字集合毎に管
理しているので、UCSから文字オブジェクトの生成には元になった文字集合の
指定が必要である。
例えば元になった文字集合がJISなのであれば、まずucs-jis/system-char-id
を検索する。ここにマッチすれば、そこで文字オブジェクトが生成される。
次にucs/system-char-idを検索する。しかし実はこのデータベースは空である。
これはどういうことかというと、char idとucsとが同一の値である場合はその
データを入れない。つまりデータが無い場合はucsと同一の値であるとみなすという
データの省略形をいれている。これはデータ量削減を目的としている。
つまり、ucs-jisに無ければucsそのものの値、という処理となる。
(ucs-jisに無かったら次にucs-gbを見る、などといった動作は誤りである。)
しかし文字が定義されているというのも重要な情報であるので、
system-char-id/ucs は定義されているべきではないだろうか。
JISX0208-1990の符号位置をどう変換するか。
まずjapanese-jisx0208-1990を参照し、そこに値が無ければ、
=jis-x0208を参照する。後者が親集合で、それを継承していると考える。
ここで名前付けルールが混乱しているように見えるが、後者に統一しようと
作業中であるためで、最終的には後者に統一される予定。
ucs-bmp, ucs-smp, ucs-sipは文字表示のためだけに入っている。
Xでは16bit単位だけでしかフォント指定ができないから。
この三つは空データベース。ucsも空データベース。
→データ削減のために、system-char-idと同じ値だったら省略するというヒュー
リスティックが入っている。char-definedというpropertyが必要ではないか?
またはto-be-definedというpropertyとか。to-be-checkedというのは考えていた。
define charのデータベースは変化分でとらえているので問題がある…。
→libchise、builtin characterの判定ルーチンをいれようか?
■それぞれの漢字集合の特徴
●JIS
→JISX0208 普通のあれ
→JISX0212 簡単に言うと印刷屋がつくった集合。大漢和字典にのってそうな漢文系の字が多い。
地名、人名とかには使えない字が多い。
→JISX0213 日本の地名をみんな書けるように、住民票をコード化するのが目標だった。
高校までの教科書で使う字も収録している。つまり日本の国字が多い。国語指向。
0212,0213は、2、3000字はオーバーラップしている。
●Unicode
→BMP 普通のあれ
→Ext.A 韓国出典がBMPにはいった。台湾のCNS。漢語大事典。中国の辞書の出典の文字。
朝鮮国字がけっこう入っている。
→Ext.B それまでCNS11643という台湾の集合が、2面と3面の半分くらいまでしか入ってなかった。
残りを全部いれようとしたもの。また0213でUnicodeになかったものも入っている。
そこから始まって、漢語大事典。大漢和を全部いれようとした。いろいろな出典がごった煮。
説文の文字じゃないような文字も入っている。
●Dainkanwa
康煕字典と同じで、つまり漢文をよむための辞書。
■漢字集合の歴史
→シンの始皇帝の文字統一が最初ではないか。小篆をベースにやった。
→漢代が隷書ベースで統一。
→後漢の時代に説文解字。
すごく時代をへて、
→シン代に康煕字典、もうそろそろ近代がみえてくる時代
字体が現代のものになる。これが規範となる。
→日本で大漢和字典。これにインスパイアされて中国でも作られるようになった。
■Ext.B
主にCNSにある文字をUnicodeにいれるために作られた。なのでCNSとの間では
対応がつく。しかし対CNSといっても完全にはマージされていない。漢語大事
典出典の文字が多い。ISO10646-2の規格表に出典のリストがかいてあるのでそ
れを確認すればよい。
→漢字庫 ideograph-hanjik-nantoka
■大漢和
MH- というのは大漢和補巻を表す番号。
大漢和字典の部首と異体字があったら対応する大漢和番号
ページ番号をうったリストがある。
■符号位置からフォントへの変換
文字鏡やGTのフォントには十分な字数があるためこれを利用すればどのような
字も表示可能であるように思えるが、しかしそれぞれの字とフォントの間の対
応関係表は整備されていない。GTについては対応属性が記述されているものも
あるが、ごくわずかである。文字鏡の文字鏡番号については50000以下の値、
つまり大漢和番号に存在する領域については同じであるとすることができると
いうことになっている。つまり大漢和番号が検索できればそこで文字を表示で
きることになる。GT-Kという文字の部品を指定したフォントもあるが、利用方
法はわからない。文字鏡の場合はライセンスが不明解であるが、一般にフリー
に利用するということは不可能である。
→ideograph-gt-pj-1はjis番号と一緒とすることができる。
大漢和番号との対応は、Unicodeは定義してない。jisx0208、0212、0213は大
漢和との対応が書いてある。0221もかいてある? 規格表としてデータがある
場合は、規格表が電子的に存在しているので、属性も入っている。
大漢和番号との対応は、川端さんと師さんのsourceforgeにある。
それとは別に安岡さんもやってる。
それらのデータもマージされているので、大漢和との対応は結構ある。
■使えそうなフォント
●ビットマップフォント
→昔人文研にいたe漢字の勝村さんによる大漢和字典の24x24フォント。
BDF版、Unicodeの日本字形版もある。
→CNS集合の40x40ドットフォント、GNU international fontに入っている。
1〜7面まであるので6万字程度。
●TrueType
→Microsfot Proofing Toolsに入っているTrueType font
1万3千字よりもっと。Ext.Bの一部もはいっている。
中国のGB103?のグリフで入っている。Winodws系では一番でかいのではないか。
●OpenType
→Mac OS X付属のヒラギノフォントはAdobe-Japan-1-5に対応しているため、
Proofingと同じくらい? 0213＋αくらいはいける。
■常用漢字
→常用漢字表、550円。官報を売ってるような政府刊行物発売所で扱っている。
→東京都千代田区神田錦町1-2 東京カンショ
→池袋、芳林堂書店
→渋谷、大盛堂書店
→クサカンムリに方とかいう感じで、すぐに芳が出てきてほしいよなー。
字体が調べられる。本物持ってると人気物になれるとか…。
1945字、常用漢字。
1006字、教育漢字、小学校。
常用漢字表にはその中に、これらの情報も入っている。
→旧字との対応表
→人名字許容字体
→許容通用略字
これらが日常目にする可能性が高い字体であると考えられる。
JISX0213までいくと、だいたいJISにはいっている。
一昨年に国語審議会がだした「生涯漢字表」。
本を見てたりするとであうことがおおい字である。
■漢字集合の対象
1006 教育漢字
1945 常用漢字
6900? JISX0208
? JISX0212
? JISX0213
20000? Unicode
? Unicode Ext.A
? Unicode Ext.B
50000? 大漢和字典
? CBETA
? CNS
? GB
? KS
それぞれの集合に意味があり、統計をとることによりその意味のもつ背景が見えてくるはずである。
また統計作業をとりはじめる最初は対象が少ない方がいいので、
教育漢字、常用漢字、JISX0208集合を順に対象とすることを考える。
■IDS
Unicodeの仕様におけるIDSの扱いは、文字指定をするような意図は含んでいない。
逆に言うとAとアキュートはその二つで合成文字として扱われ、
元々Aとアキュートがついていた文字と同一の文字として扱われる。
しかしIDSによって合成した文字はそのように扱われるという仕様ではない。
つまり"ff0;木木"という文字(列)は"林"という文字と一緒ではなく、
一緒に扱わなくてはいけないという仕様でもない。
じゃあIDSはなんなんだろうという疑問は残るが、とりあえず単にそのような
組み合わせを指定するための記号ということのようだ。
たしかに逆に字形そのものによって字を指定したとしても、それをそのような
属性によって字を定義したと見做せば、Chaonモデルの枠組で利用できて
当然ということだろう。
■IDS text fileの読みこみ
IDS-UCS-Basic.txt 20902 0 0 20393
IDS-UCS-Ext-A.txt 6584 0 0 6500
IDS-UCS-Ext-B-1.txt 8192 0 0 7762
IDS-UCS-Ext-B-2.txt 8192 0 0 7899
IDS-UCS-Ext-B-3.txt 8192 0 0 7998
IDS-UCS-Ext-B-4.txt 8192 0 0 7964
IDS-UCS-Ext-B-5.txt 8192 0 0 8081
IDS-UCS-Ext-B-6.txt 1751 0 0 1730
IDS-JIS-X0208-1990.txt 6398 3460 794 517
IDS-Daikanwa-01.txt 1456 706 212 274
IDS-Daikanwa-02.txt 3244 1930 45 322
IDS-Daikanwa-03.txt 2758 1472 67 143
IDS-Daikanwa-04.txt 4153 1748 801 57
IDS-Daikanwa-05.txt 2916 709 793 48
IDS-Daikanwa-06.txt 3184 995 376 137
IDS-Daikanwa-07.txt 5137 1484 801 258
IDS-Daikanwa-08.txt 5474 1529 608 75
IDS-Daikanwa-09.txt 4761 790 737 127
IDS-Daikanwa-10.txt 5941 1609 486 14
IDS-Daikanwa-11.txt 3581 1066 125 6
IDS-Daikanwa-12.txt 6740 1592 357 18
IDS-Daikanwa-dx.txt 1062 234 88 10
IDS-Daikanwa-ho.txt 35 0 27 1
IDS-CBETA.txt 13363 745 441 341
合計 140400 20069 6758 70675
この順番でファイルを読みこんだ。
すでに出現した文字があった場合は上書きせず元のを残す。
UCS-シリーズにでてくるIDSは、Unicodeの範囲内で表示できる文字が多く、
Meadowで素直に表示されるため都合がよい。
食い違ったものは大体、大漢和番号で指定されているなどの差のようである。
2カラム目がそのファイルに含まれている文字数
3カラム目がそれまでに出現した文字と、まったくIDSが一致した文字の数
4カラム目がそれまでに出現した文字と、IDSが食い違った文字の数
4カラム目が読み込みに成功した字数。IDSが定義されたもの。
最後に合計を示す。
つまりおおよそ14万文字の定義がファイル中にあり、
2万7千文字くらいの文字定義が重複している。
(そのうち7千文字くらいがなんらかの理由で定義が食い違っている。)
無事IDSを定義できた文字数が、7万字ある。
IDSを定義できない文字には、分解できない文字も含まれる。
→IDS textはどのように入力されたか? UCS-BasicとJISとで、
部品レベルでかなり違うが、この違いはどのように解釈すればいいか?
JISは他のファイルから集めてきたものだが、まず一次近似として
morohashi-filterをかけて、諸橋字形に直し、
その後手でデザイン差を考慮し、手で直している。
UCS-BasicよりはJISのほうが優先してcheckしている。
UCS-Basicは入力システム、つまり四角号碼に依存。
元になったデータで一番多かったのがCNSのデータ。
四角号碼の中に部品がCNSの文字オブジェクトで入っているので、
結果的にCNSのデータではいっている。アルバイトの人が入力した。
あとは台湾中央研究院のデータ。新たに入れたのはUnicode字形。
CNSとは台湾の2022ベースの文字規格。1〜7面がある。
BIG5を2022にしたもの。
部品単位でUCSプロパティを見て直せばいいのでは。
デザイン差の問題、骨格が違うこともありうる。
→糸偏、日本:小になってる。中国:3個の点になってる。
→なべぶた、日本:上みたいな垂直線と水平線。中国:横線二本。
中国、台湾は部品レベルで階層的に均一になっているのだが、
JISは常用漢字の範囲、それ以外の範囲とでかなり違う。
部品レベルで見てみるとかなり不揃い。
ucs-jisのフィルターをかけると日本の文字になる。
→Unicodeには部首それ自体を漢字として扱っているものと、
部首そのものを表すコードとが分離して扱われている。
CJK Radicals Supplement http://www.unicode.org/charts/PDF/U2E80.pdf
CJK Unified Ideographs http://www.unicode.org/charts/PDF/U4E00.pdf
つまり、漢字と部品が違うscriptと考えられている。
この二つの間で、字形としてはまったく同一のものが別のコードとして
存在しているのだが、では部品を表すものとしてはどちらのコードを使えばいいのか?
現在は方針は決まっていない。混在している。
他に、GT-Kとして部品だけのフォントデータがある。
GTの世界には部品と漢字の区別はない。
→Unicode規格票
Unicode Standardは本屋で買える。
ISO10646は日本規格協会のWebで買える。
ISOのweb pageを見ると、カタログがあり、星の数で値段が示されている。
日本規格協会で対応するものを見ると値段がわかる。
ISO10646-1は対応するjis0x0221-1が日本語に翻訳されている。JISのほうが安い。
unicodeコンソーシアムに、code chartがPDFでフリーで公開されている。
http://www.unicode.org/charts/
→IDSの規格とはどのようなものか。
例えば、AとAccuteを組み合わせた合成文字は、
それが元々組み合わさっていた文字と、文字レベルで同一のものと考えられている。
しかし、∫木木のようにIDSで指定された文字は林と文字レベルで同一のものと
考えられているわけではない。表示の際に合成されて表示されることがありうるが、
それは文字指定ではなく、林という文字と同一で扱われることはない。
IDSとは、結合文字とは違い、みんな前進文字。
IDSシーケンスは漢字を表してはいない。
ハングル字母みたいに漢字を拡張する仕様とはいえない。
IDSシーケンスには、
CJK Radicals Supplement http://www.unicode.org/charts/PDF/U2E80.pdf
CJK Unified Ideographs http://www.unicode.org/charts/PDF/U4E00.pdf
Kangxi Radicals http://www.unicode.org/charts/PDF/U2F00.pdf
CJK Compatibility Ideographs http://www.unicode.org/charts/PDF/UF900.pdf
こういったものが部品として使われうるという規格になっている。
つまり部品と漢字とどちらを指定したらよいかは、規格のレベルでは区別されていない。
このようなIDSの使い方そのものはcode chartsにはかいていない。
Unicode standardの前のほうにかいてある。
またはテクニカルレポート(TR)として出ている。
IDSの使い方もTRになっているはず。
http://www.unicode.org/reports/
ISO10646とかJISは、工業規格としての書き方をしているが、
Unicode文献は、工業規格的書き方ではない。
世界の文字のことを技術者に説明している文章という感じ。
なので規格としてはきっちり整合していないことがある。
実用上として考えると。
部品はUnifyされていないのだが、漢字のほうはunifyされてる。
つまり部品ではわかれていて、漢字では統合されている場合がある。
部品レベルでの字形をよりこまかく指定しようと思ったら、部品のほうがいい。
→CHISEデータベース的にはどう違う?
部品も漢字としている。
scriptという属性があって、シンボルのリストがあった。
漢字は暗黙のうちにideographというのがついていると。
最初はそれで分類しようとしていたが、現在はそうしていない。
同じ文字コードがそれぞれはいっている。
にくづきはunifyできない。月にunifyするわけにはいかない。
漢字のレベルで違うと思うかどうか。
現在は大漢和字典でにくづきをあらわす番号があったので、それにunifyしている。
まったく一緒で分離されているものは、
from-radicalが定義されていたかも。
radicalとcompornent(parts)は違うものと考えたほうがいいのでは。
造字のときに、形成じゃなて会意のときは、意味部品は漢字である。
音をあらわす部分は、漢字じゃないような。
変形がくわわったときは区別したほうがいいが。
部品にたいするメタデータか?
→デザインでやるか意味でやるか。
肉付き、月とは別の
デザイン的には月にちかくて、肉にちかい部品とか。
→フォントを合成するのにちかいstructure
→意味のstructure
この二つを用意するのが簡単な回答。
しかしこれだと見かけと意味のstructureの対応関係がついてない。
両者のstructureをあわせもった単一のstructureを作り、
その上で、両方のデータを生成できるとかが理想。
見かけと意味の対応関係をかきたい。
メタデータとして、意味ではこう、形ではこう。
現状では、データを頭から最後まで読んで整合性がとれていればよい。
→部品オブジェクトにpropertyをつける?
見かけが似てるものの対応関係。
CBETAのデータで部品がないものは台湾の発音記号をいれたりしてるし。
漢字の起源間で、形が似てるとか。
ひらがな、カタカナも漢字から派生しているから広い意味では漢字といえるし。
→CCSの名前を=なんちゃらとなおしている。
従来方式はaliasになる。
→属性名にたいするディレクトリーサービスが必要ではないか。
ISOの登記簿の番号? 2022のファイナルバイトとか?
JISの規格番号とか? それぞれ文字コードにも属性がある。
それからなんらかの手続きでfindする。coded char setをとりだす。
char-dbにたいして、
char-attribute-dbがある?
属性から名前がひける。
→CBETAとはなに?
団体名。中華仏典電子化協会。
Chinese Butte.. Text Associaction.
CBETAとは、たいしょうしんしょうだいじょうきょう。
大正時代に日本でまとめたおきょうの。。。
そのときに必要になった外字をあつめたもの。
→CBETA番号がある一定数以上ないのはなぜ?
CBETA番号は対応関係が記述されていないものがある。
その場合はそれだけビルトインキャラクターとして扱われることになる。
しかしもちろん、他のプラットフォームから見れば、CBETA番号を直接扱える
環境もあるわけなので、それそのものには意味がある。
とりあえず現在対応関係が無いものは省略してもよいかと思われる。
→Daikanawa番号に抜けがあるのはなぜ?
対応関係が記述されていないものがあるから。
大漢和字典はおおまかに4種類あると考えられる
0 戦前に出た木版版
1 前後に写植ででた、いわゆる初版
2 しゅうてい版
3 しゅうてい第二版。
つまり現在における最新が、3のしゅうてい第二版である。
ideograph-daikanwa/system-char-id が、この3のしゅうてい第二版を指す。
ideograph-daikanwa-2/system-char-id は、2のしゅうてい版を指す。
つまり、なにもついていないideograph-daikanwaが最新である。
大漢和番号には'や"がついている番号がある。その'や"を含めて大漢和番号である。
この'や"を含めた場合の大漢和番号からchar-idへの変換経路は用意されていない。
system-char-id/morohashi-daikanwa
の中身はS式になっている。
1カラム 大漢和番号
2カラム ダッシュの数、つまりだいたいここは0になっている
3カラム 適当につけたvariantsの指定などの値。だいたい0。
9:対応関係がよくわからない 8:対応がかなり遠い
4カラム かつて距離の遠さによって定義しようとしていたことがあり、
それで残っているもの。4カラム目はめったに存在しない。
ダッシュがついた文字の場合は、ついていない文字があるはず。しかし大漢和
番号は後から同じ字であることがわかった場合など、字を削除することがあり、
つまり欠番がありうるので、それは保証されているわけではない。
大漢和番号は最初に4万9千いくつまでついたのだが、その後にでた巻で、
hoの何番という番号もでてきた。それは(ho 99 0)のような番号がついている。
■フォントレンダリングの仕組み
1. まず、変数 default-coded-charset-priority-list で指定した優先順位に
従って、文字オブジェクトを font-CCS と code-point に分解します。こ
れは関数 split-char が行っていることと基本的には同じですが、現状の
X の font の仕組では 16 bit を越える font encoding は使えないので、
charset-dimension が 3 以上だったらスキップします。
2. font-CCS が 1 だったら XDrawString, 2 だったら XDrawString16 で描画
します。
実際には連続して同じ font-CCS を用いる文字列をパックして行います。
■CCS CES
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/23341
http://imcp.maid.ne.jp/computer/sgml/japanese.html
http://www.d2.dion.ne.jp/~imady/kcode/kcodemame.html
符号化文字集合 : Coded Character Set,Codeset , CCS
Character Encoding Scheme , CES
CCSes ( １つ以上の CCS ) + CES．バイト列を文字列に変換する方法およびその逆．
一般にいう ISO-2022-JP は， ASCII, JISX0201(ラテン), JISX0208 の３つの CCS と ISO-2022-JP の CES から 構成されるものを指す．
■木だけでできている漢字?
(put-char-attribute ?木 'ideographic-structure-depth 1)
(put-char-attribute ?林 'ideographic-structure-depth 2)
(put-char-attribute ?森 'ideographic-structure-depth 3)
(put-char-attribute ?\u234CF 'ideographic-structure-depth 3)
(put-char-attribute ?\u236E7 'ideographic-structure-depth 4)
(put-char-attribute ?\u23855 'ideographic-structure-depth 6)
(put-char-attribute ?\u2387D 'ideographic-structure-depth 16)
U-000234CF ? 林木
U-000236E7 ? 木森
U-00023855 ? 森森
U-0002387D ? 林林林林
■【教育漢字】（平成元年改）１００６字 http://www.hakusyu.com/dl/kyoiku.htm
●ぼくらのフォント http://www.hakusyu.com/bokura/index.html
●http://www.hakusyu.com/dl/pandora/dlwin.htm
●WinFonts大図鑑 http://ohkadesign.cool.ne.jp/winfonts/
■形式文法
http://www.genome.ad.jp/Japanese/lect/14-10.html
正規文法
すなわち有限オートマトンや正規表現が有効
文脈自由文法
■ゲーデル賞
http://www.nihon-u.ac.jp/nunews/koho/kh431-03.htm
http://www.uec.ac.jp/uec-80years/toda.html
http://internet.watch.impress.co.jp/www/article/2003/0212/pepper.htm
■IDSテキストファイルの解析
→1カラム目がコードポイントを表し、
2カラム目が文字字体を表してる、ように見えるが、
この2カラム目は字形表示のためだけに使っており、データとしては使うべきでない。
→品質としてはJIS、UCS、Daikanwaの順に良い。CBETAの品質は低い。
おおまかにinstall-ids.elに指定されている順番に品質が高い、はず。
もし1カラム目のコードポイントを検索し、結果として他のコードポイントと
同一であるとわかったとする。
その上で、そのそれぞれのデータが示しているIDSが食い違っていたらどうするか。
その場合は簡単には、上記の品質の順にどれか一つをとりあげるしかないだろう。
なぜ食い違っているのか。2ケースある。
まずIDSの作り方として違う場合。同じ部品で違う扱いがなされている場合。
もう一つは、unifyしている場合。違う部品にunifyされている場合がある。
部品にmap to ucs属性がある場合はそれを使える。
→部品のunifyは簡単ではない。
ニクヅキ、全の上の部品のように、字源を辿ると分かれるものがあり、
そういったものをどう解釈するかは注意が必要。
字源をさかのぼった際の同一性の解釈にはデータが足りてない。
子という字が部品として使われる場合も、字形が変わらないように見えるが、
真中の横線が右上りになるという変形がなされる。
おそろしいことにそれが常にそうなのではなく、二つの部品が識別されている場合もある。
→char-represented-of-daikanwa でdaikanawaにおける対応番号を調べる。
morohashi-daikanwa, ideograph-daikanawaなどを順に調べる。
ideograpic-structure-convert-to-ucs
ideograpic-structure-convert-to-daikanwa
この関数で、IDSをできるだけUCSまたはDaikanwaにunifyした形に変換してくれる。
ids-utilに存在している。
→ids/IDS-UCS-Ext-B-1.txt
U21CB7 →この行だけコードポイントが変。
→部品はGT-Kが網羅的なのでここに集約させるのがいいだろう。
しかし実際に必要な属性が揃っているのかどうかは疑問。