| Subject: Unicode 版への変換作業について（２） Date: Mon, 28 Jan 2002 10:55:48 +0900 富田さんへ 志田です。 お返事どうもありがとうございました。 にわかじこみの知識とひらきなおりの心意気ばかりなもので、どうぞご容赦ください。 >UCSへの対応の問題は、世話役の中でもまったくと言っていいほど話したこと >がありません。 この件にかんしては、興味はあるけれどもじっさいに積極的に手をだすには気がひける……というのが、個人レベルでも、組織レベルでも、いつわらざる心境なのだろうと思います。そういう、みんながしりごみせざるをえないテーマだからこそ、あえて発言したりアクションをおこなうことにしました。 １．青空文庫→JIS X 0213→Unicode 青空文庫なくして JIS X 0213 の制定はありえず、また、JIS X 0213による文字集合の定義がなければ、Mac OS X でも Win 2000 でも、Unicodeとして反映することはできなかった……この認識で、まちがっていないと思います。現在わたしが目にしているUnicode は、青空文庫にたずさわったかたがたの成果であることに、まずは感服・感動しています。 ２．UCS と Unicode について 登録商標でもあり企業色のつよい「Unicode」という表現よりは、それを国際的な標準規格として追認した「UCS」や「UTF」というよびかたのほうが好まれるのかもしれません。そのことを認識したうえでUnicode という表現をつかいたいと思います。文字パレットや保存形式で現実にまのあたりにするのが「Unicode」という表記だからです。「なんだかくわしくわからないけれども次世代のパソコンの標準な文字コードになるみたい」というのがわたしの出発点の認識レベルだからです。 ３．とうめんの活動は 0208 おもに LUNA CATさんが「明日の本棚」を整備してゆくのを、感激・興奮しながら拝見したものでした。ただ、しばらくすると活動が停滞気味になり、はがゆく思ったのが今回のアクションのきっかけになっています。「Kandata・Habianを利用したJIS X 0213 表現は非常に画期的、だが、あくまで暫時的なこころみ」であることに気がつかれたので、積極的な変換作業をさしひかえたのだと受け取りました。 Unicodeもまた魅力的ですが、「つかいたくてもつかえない」のがスタンダードOSでの実情です。時間がたてば Unicode も普及するかもしれない。けれども、そのあいだ、軌道修正だってあるんじゃないの？ っていう疑いも捨てきれない。 したがって、青空文庫本体の活動は、とうめんは 0208 でいいのだと思います。入力・校正・制作……もんだいなくテキストを交換できることが活動の必須条件だからです。 ４．0208→Unicode に限定したプロジェクト 前述の理由から、「新規入力を Unicodeで受けつける」には課題が多すぎるし、「Unicode から 0208」への変換もまた、未知の領域といわざるをえません。 そこで考えたのが、0208から Unicode に限定した変換プロジェクトです。 >UCSへの対応の検討までは、なかなか手が回りそうもありません。 青空文庫ほんたいでは、かかえている課題がたくさんあって、あたらしいプロジェクトを並立して起動させるのはむずかしそうです。青空文庫からローカルな形式へ変換している青空派生ファミリーという位置づけでやらせていただいたほうが、規制緩和もやりやすいだろうかと考えています。 ５．あしなみはまだ…… Mac にかぎっても、OS X と X10.1では文字集合にちがいがあるらしいし、ましてや Winでは、補助漢字あり……と、おせじにも Unicodeのあしなみはそろったとはいえない。したがって、わたしの提供できるサービスは「2002年1月現在の Mac OS X10.1プレゼンツ」ということにならざるをえないし、それでいいんじゃないかとひらきなおっています。できるものは責任をもってやらせてもらう、不完全なものはつぎのひとに確実にバトンタッチする……、その点を理解して利用してもらえればいいのではないかと思います。 ６．「面区点番号」表記の有無について 面区点番号があれば、変換のさいに非常に心強いです。類似している文字でも番号をたよりに確認ができます（極論では面区点番号表記「のみ」でも変換は可能です）。だからといって、登録済みのテキストにさかのぼって番号を付記する必要までは感じません。むしろ、底本が手元になくても確実に変換するためには「エキスパンドブック」なり（笑）、外字画像のはりこんである「HTML形式」で照合する必要性を感じました。画像は、本文内にある必要はなく、逆にあとづけになってるほうが効率がいいです（この点は「ファイルは変換の効率のためだけにあるわけではない」と思うので、anything goes です）。 ７．自動変換について Mac OS X では、Perl もあるし、Ruby という選択もあるでしょう。sed Macも考えられますがいずれも不勉強です。Unicode がそれらに対応しているのか確認のてだてすらわかりません。テキスト内の注記の表現にしても、すべてがまったく同一形式というようでもないみたいですし。目視確認しないとどうにも心細くていられないたちで……。というわけで、せいぜいいまの段階では、エディターでの変換や置きかえぐらいです。 ８．「78互換包摂29字、包摂適用除外の104字、加えて0213の改訂で加えられてしまうかも知れない10字」とかについて 以下は、「Unicode 版への変換作業」の「包括規準の適用除外とかについて」に記載したことのくり返しになります。 「底本にそった入力と変換を“大”前提」とします。これがたてまえです。そして、「入力者や校正者の注記を“唯一”のよりどころ」に変換します。ここがポイントです。また「底本へさかのぼっての確認や修正はおこないません」ということを宣言します。これで、変換対象が肥大化するのをセーブできると思います。「必要だという作業は、必要だと主張なさるかたがおやりください」方式です。 前述のたてまえのみだと、「森鴎外」の「鴎」には注記がないので変換対象にはなりません。けれどもUnicode 版なんだから「區鳥」にしたいというのが「ほんね」。そこで、「人名などの固有名詞は本人にとって正式である字形を極力採用したいという」個人的人権の尊重主義をもちだして、例外的に変換したいと思います。 ９．８についての補足 したがって、とことん底本主義者のかたにとっては「そんなもの認められない」ということに残念ながらなってしまうでしょう。けれども、わたしじしんは、そこまでの完璧性をいまの段階ではのぞみません。このたびの企画では「78互換包摂29字、包摂適用除外の104字を底本へさかのぼって確認する作業を放棄」します。 そういう独断が前提になるとすると、やはり青空文庫とは別世帯のほうがいいのかなと考えています。「作業目標として“包摂・包摂適用除外の確認の放棄”、したがって作業の意義はきわめて浅い」（半分冗談、半分本気です）。「0208／0213の包摂規準とUCS の Unificationルールの溝」という件も、その差異に価値観をいだくかたもいらっしゃれば、そうでないひともいる。その差異をいかに扱うか“議論”することに価値をいだくかたもいれば、そうでないひともいる。「問題の先送りだ」と批判されるかもしれませんが、まずはできることをおこなうというのがわたしのモチベーションです。大きな課題は、Unicode を使う環境がもっとゆたかになって、それを関心もってつかいたいと思うひとがたくさんあらわれてからのほうが、効率が高いはずと考えます。 １０．「ない字」問題への対処 第５・第６水準候補の漢字がどの作品に使われているのか、すでに青空文庫では承知なさっていらっしゃるのかもしれませんが、この企画でも、一見してそれがわかるようにインデックスを用意できるでしょう。 また、「Unicode における漢字や記号表現の差異確認」を焦点のひとつにしています。おそらく文字の互換性はひとすじなわではいかない。あゆみよりもすれば、意図的な差異化もあるのではないでしょうか。その点で内田さんのすすめてらっしゃるフォントの作成は意義深いことだと思います。 Unicodeのさきゆきはわかりません。たぶんないとは思いたいですが、Unicode形式同士に互換性がないじたいにおちいるとか（笑）。ただし、Unicodeが成長するにあたって、JIS X 0213 制定が果たした役目は大きかったでしょうし、周囲に「超漢字」や「文字鏡」、中国圏では「方正」などが牽引役・牽制役として存在していたのが健全化に有効だったのだと思います。 不完全な神輿（みこし）であることを承知のうえで、かつげるものならかついでみようか……といった心境です。下でかついでいるさいちゅうに、神輿の増築もおりにふれてやってくれるのだろうと思います。きっと。 ですから、いまの段階では、わたしはひとりしばいでもいいとおもいますし、ひとりでも可能なレベルに活動内容を制限しておきたいと思っています。そのほうが、リスクの分散・いたみの分散になるだろうと。 お答えになっていますでしょうか。 みとおしが楽観的すぎるかもしれません。 もしかしたら、この活動が起爆剤になるのでは、という予感もぬぐいきれません。 2002.1.28 Mon 志田 火路司 |