(大漢和 12巻 569頁 45098番)
前寺正彦（ロータス株式会社
米国MA州ウェストフォード研究所）
E-mail:SGQ00310(#AtMark#)nifty.ne.jp
2001年前半に、新しい Unicode のバージョンである
Unicode 3.1 がリリースされた。
私も含め、漢字圏の一員である日本人として、
漢字数の拡充に関心がいくところである。さて、その漢字数であるが、
中日韓統合漢字拡張Ｂ(CJK Unified Ideograph Extension B)の約４万字が加わり、
既存の漢字とあわせて、総計で約７万字の漢字が定義され、大幅に拡充された。
そこで、文字鏡ユーザーにとっては、データの蓄積方法が大きな関心事である。
文字鏡データを主体に蓄積すべきか、 Unicode
テキストデータを主体に蓄積すべきか、悩むところである。
結論を先にいうと、私は、迷いもなく、
文字鏡データを主体にデータを蓄積すべきであると主張することができる。
その理由を、以下の章で順を追って、説明したいと思う。
まず、Unicode
で漢字が約７万字ほど定義されたからといっても、
それらは定義されただけで、Windowsなどの基本ソフトで使えるような、
すべての漢字が収録されたフォントは、一般的に配布されていないのが実情である。
一部、中国ですべての漢字を収録した Unicodeフォントが配布されているという噂もあるが、
仮にそれが事実であっても、日本人の好みにあうようなデザインである保証はない。
また、フォントの問題が解決されても、一太郎のような応用ソフトが対応して、
Unicode
の全漢字が表現力のある文章の一部として使えるようになるまでには、
まだまだ時間がかかる。
一方、文字鏡の場合は、最初に実在するフォントが提供され、それらは、
すでに一太郎やＭＳワードのようなワープロソフトで実際に使われており、
しかも、出版物の一部として使用されているという実績がある。
もちろん、これらの事実は、単純に現状での長短を述べているだけであって、
将来のデータ蓄積に関してどちらが有利であるかの説明はまったくされていない。
ここで、将来という時間軸では解決できない「包摂規準の問題」を次章で説明する。
まず、「包摂規準」という言葉がでると、
またこの話かとうんざりする読者も多いと思う。
これについては、先日JIS 規格になった JIS X 0213
のリリース前後でも、
インターネット上の数多くのサイトで議論になったのは記憶に新しいところである。
また、Unicode の包摂規準については数多くの専門家が、
一貫性や正確性に関しての疑問を述べている。
現在、これらのテーマについて議論しているサイトは、 Web
上の検索サイトで、適当なキーワードを用いて検索すれば、
容易に見つけることが可能である。
しかし、私自身は漢字学者でもなく、 Unicode
内の漢字について一文字ずつ調べている専門家でもない。
Unicode
の包摂規準について一貫性や正確性の真偽を語るすべは持ちえない。
でも、Unicode の原点にかえり、 Unicode Standard Book
の一文を引用することは可能である。
ユニコード標準は、 意味のある値をもつ書き言葉の最小の構成要素である 文字(characters)と、 表示時に文字がもちえる形状を表現する グリフ(glyphs)との間に区切りの線を引いている。
上記の翻訳文をみればわかるように、 Unicode は「文字」と「グリフ」の違いを次のように定義している。
意味のある値をもつ書き言葉の最小の構成要素である
表示時に文字がもちえる形状を表現する
あくまでも原文に忠実な訳を心がけたので、わかりづらい表現があるかもしれないが、 アルファベットを例にすると次のような具体例が出せる。
「Ｓ」と「ｓ」は文字として区別する必要がある
イタリック体やボールド体はグリフでは区別するが文字としては区別しない
次に、これを漢字に適応すると、次のような具体例が出せる。
「口」と「囗」は文字として区別する必要がある
異体字や明朝体、毛筆体はグリフでは区別するが文字としては区別しない
上記の具体例をみて、Unicode
における文字とグリフの違いを、
アルファベットや漢字やその他の文化圏の文字に適応したときに、
それらの文字の間で、一貫性を保ち得るかに対する疑問もあるかもしれない。
しかし、Unicode
のような多言語間で産業標準を目指す規格を、
上記の曖昧さだけで、単純に批判することはできない。
ただし、漢字に限定すれば、
異体字の区別は明らかに Unicode
の収録規準からは除外されており、
それらが別字として二つのコードポイントを与えられるか、
同じ文字としてひとつのコードポイントしか持ち得ないかは、
Unicode
が定める「意味のある値をもつ書き言葉の最小の構成要素である」
であるか否かに依存するのである。
それに対して、文字鏡研究会は、収録規準として、
「幾何学的字形差」と「出展」という二つの条件を採用し、
新規文字を収録するという立場をとっている。
だから、「出展」さえあれば、「幾何学的字形差」のある
異体字には、それぞれ別の文字鏡番号が与えられるのである。
もちろん、３画草冠と４画草冠のように、
申請者の誤用により、創作異体字が発生する危険性もあるが、
少なくとも、文字鏡研究会は、
申請者の誤用でしか「出展」のない文字は収録対象外とし、
無意味な創作異体字で、不必要に文字鏡番号を増やすことはしていない。
読者は上記の収録姿勢の違いを、はっきりと認識しておく必要がある。
データの蓄積方法として、どちらが長期間にわたり、
読者の意図する正確な字形情報を保つために適しているかを判断する必要がある。
しかし、文字鏡はあくまでもフォントであり、文字コードではないので、
読者のなかには、保存の仕方に不安を持つかたも多いと思う。
せっかく、一太郎でデータを作成しても、テキストファイルで保存するときに、
フォント情報が落ちてしまえば、
字形情報を同時に欠落してしまうのではないかという危惧がある。
それを解決するのが、次章の「リッチテキストの時代」である。
ここで、私は、XML や HTML
という用語を使わずに、
あえて、リッチテキストという用語を使用した。
リチッテキストにはいろいろな意味合いが含まれるが、
私は、plain textに対する存在としての rich
textというつもりで使っている。
プレインテキストとは、
いわゆる読者が通常の文脈でつかうテキストファイルであり、
改行やタブなどの極めて限られたフォーマット用の文字以外は、
すべて、字形をもった文字で構成されている。
それに対して、リッチテキストは、特殊なエスケープ文字を持ち、
それに続く文字列はエスケープ終端文字がくるまでは、
表示以外の文書整形や参照情報に使用される。
しかも、ワープロソフトで出力されるバイナリデータと違い、
リッチテキストの構成文字は、
すべて字形をもったプレインテキストと区別がつかない。
文字鏡を使用するのに一番適したデータ形式がこのリッチテキストであろう。
そのなかでも、文字鏡番号によるデータ蓄積が、
一番、リッチテキストのメリットを生かすことができる。
文字鏡番号を使用した具体例を以下にあげる。
| 文字鏡 | ISO/IEC: | 9AA8 | ||
|---|---|---|---|---|
|
|
|
|
|
|
| M:08-E788 | G:0-8D66 | T:1-9CEA | J:0-8D9C | K:0-9789 |
| 音: | コツ/E | |||
| 訓: | ほね/E | |||
| 名: | ||||
| 英語: | bone | |||
| 中国音: | 韓音: | kor | ||
| 部首: | ほね | 総画数: | 10 | |
| 属性: | 基本字 | 部首内画数: | -- | |
| 文字番号: | 45098 (大漢和 12巻 569頁 45098番) | 学習学年: | E6-- | |
| 情報: | ||||
備考: Unicode文字 U+9AA8
は、文字鏡では、&M45098;, &M57630;, &M79860;
の３つの番号を持つ文字に分かれる。
もし、読者の環境に文字鏡フォントが正しくインストールされていれば、
「辷」 「秀」
「講」
が、「辷」「秀」「講」ではなく、 「
」
「
」
「
」
と表示されるはずである。
備考: Unicode文字 U+9AA8
は、文字鏡では、&M45098;, &M57630;, &M79860;
の３つの番号に分かれる。
もし、読者の環境に文字鏡フォントが正しくインストールされていれば、
「<FONT face="Mojikyo M108">辷</FONT>」 「<FONT
face="Mojikyo M111">秀</FONT>」 「<FONT
face="Mojikyo M115">講</FONT>」 が、「辷」「秀」「講」ではなく、
「<IMG alt="(#AtMark#)M45098;"
src="http://www.mojikyo.gr.jp/gif/045/045098.gif">」 「<IMG
alt="(#AtMark#)M57630;"
src="http://www.mojikyo.gr.jp/gif/057/057630.gif">」 「<IMG
alt="(#AtMark#)M79860;"
src="http://www.mojikyo.gr.jp/gif/079/079860.gif">」
と表示されるはずである。
上記の例では、文字鏡番号をあわわす表現形式として、次の４つを使用している。
(#AtMark#)45098;
&M45098;
http://www.mojikyo.gr.jp/gif/045/045098.gif
<FONT face="Mojikyo M108">辷</FONT>
暗算で簡単に変換できるものもあれば、複雑な計算を要するものもある。
しかし、心配するには及ばない。
変換用のテキスト処理ツールを、文書作成時に、最初に用意しておけば、
あとは、コンピュータ上でそれを使用して効率的に文書作成をするだけである。
文字鏡番号でデータに蓄積しておけば、文字コードによる包摂や、
文字コード間の変換による情報の欠落に悩まされず、
適切なテキスト処理ツールを使うことで、いつでも、好みの形式で、
正確な情報を相手に伝えることが可能になる。
このようなテキスト処理ツールは、すでに、十分な数だけ種類があり、
そして、それらは、中日韓統合漢字拡張Ｂを含んだ Unicode
フォントを作成するより、
はるかに安価なボランティアベースで増えつづけ、
読者が入手することが可能なのである。
このインターネットの時代では、ホームページ上にいくだけで、
文字鏡番号変換のサービスを提供するページも登場してくるであろう。
2001年7月30日著