toppage memoranda
（ここはbewaad institute@kasumigasekiの過去ログ倉庫です。コメント等は仕様上受付けを停止しておりませんが、こちらではご遠慮いただければ幸いです。何かございましたら、現行サイトにお願いいたします。）
2005-07-30
■ [economy]「真の失業率」推計最新版（2005-06現在）
前回お断りしたとおり未入手故に推計値を用いていた5月分の「15歳以上人口」の値を正しいものに変更（11,000→11,008）し、それに伴い同月の「真の失業率」（8.6%→8.7%）と「真の失業者数」（605→610）も訂正いたしました。また、完全失業率も数字が変更（4.7%→4.6%）されていましたので、あわせて変更しております。
年月 完全 真の 15歳以上 就業者数 完全 真の 失業率 失業率 人口 失業者数 失業者数 1990 2.1% 3.2% 10,089 6,249 134 204 1991 2.1% 2.4% 10,199 6,369 136 155 1992 2.2% 2.2% 10,283 6,436 142 142 1993 2.5% 2.8% 10,370 6,450 166 183 1994 2.9% 3.4% 10,444 6,453 192 228 1995 3.2% 4.0% 10,510 6,457 210 266 1996 3.4% 4.1% 10,571 6,486 225 276 1997 3.4% 3.8% 10,661 6,557 230 262 1998 4.1% 5.1% 10,728 6,514 279 348 1999 4.7% 6.3% 10,783 6,462 317 435 2000 4.7% 7.0% 10,836 6,446 320 485 2001 5.0% 7.9% 10,886 6,412 340 551 2002 5.4% 9.4% 10,927 6,330 359 660 2003 5.3% 10.0% 10,962 6,316 350 700 2004 4.7% 10.0% 10,990 6,329 313 705 2004/Q2 4.8% 9.4% 10,992 6,372 321 663 2004/Q3 4.7% 9.3% 10,988 6,379 314 653 2004/Q4 4.4% 10.1% 10,998 6,326 290 713 2005/Q1 4.7% 11.3% 10,982 6,236 305 792 2005/Q2 4.5% 9.1% 11,002 6,402 299 639 2004/6 4.6% 9.3% 10,982 6,374 309 654 2004/7 4.8% 9.3% 10,984 6,373 318 657 2004/8 4.7% 9.0% 10,985 6,395 314 635 2004/9 4.6% 9.5% 10,994 6,369 309 667 2004/10 4.7% 9.7% 10,997 6,352 311 686 2004/11 4.4% 10.2% 11,003 6,322 290 720 2004/12 4.1% 10.4% 10,995 6,306 270 731 2005/1 4.5% 11.1% 11,004 6,261 296 782 2005/2 4.7% 11.6% 11,003 6,224 308 818 2005/3 4.8% 11.1% 11,003 6,260 313 782 2005/4 4.7% 9.7% 10,994 6,352 310 684 2005/5 4.6% 8.7% 11,008 6,435 307 610 2005/6 4.2% 8.9% 11,003 6,418 280 624 C/(B+C) D/(B+D) A B C D=Ax0.64-B （直近月次ボトム） 5.8% 11.6% -- 6,193 384 818 (03/3,4) (05/2) (03/2) (03/3) (05/2) （注） ・ソースは総務省統計局の「労働力調査」（http://www.stat.go.jp/data/roudou/2.htm）。 ・月次データは原数値を用いている（季節未調整）。 ・「真の」値は、1992年の労働力人口比率0.64（直近ピーク）を15歳以上人口に乗じた数を労働力人口として算出。 ・少子高齢化の進展による労働力人口比率のあり得べき低下は考慮していない。
＃過去の計数は以下のとおりです。
■ [computer]文字コードのロンド
Windows Vistaが漢字フォントとして新JISの表外漢字字体を用いることについて、AKITさんがご自身の名前を例に取り批判され、「正字」のフォントを作ることは構わないが、「正字」に対して新しいコードを付与した上で、両方の字の間の選択を認めるべきであると考える
とのご提案をなされています。
コンピュータにそれなりに長い間触ってきた身として、この問題を考えていただくにあたり、実はこの手の問題は昔から存在していて、別コード付与をしないことにもそれなりの理屈があることを紹介させていただこうと思います。
昔からと申し上げましたが、近年においてもっともこの話題が盛り上がったのは、webmasterの記憶では90年代後半のUnicodeを巡る議論です。日本、中国、台湾、韓国で用いられている漢字について、似て非なるものに同じコードを割り振るとの方針を受けて非常に多くの立論がなされました。
＃ご関心の向きは、「unicode han unification」あたりでぐぐってみてください。
それぞれの立論にはそれぞれなされた理由が部分があるわけですが、その大枠はwebmasterが見るに、次の故・石原潔さんの意見（1998/4/18付の「パソコンと日本語」）に尽きると思います。
異体字を包摂してしまえば、見た目の表記を変えたいときに困ります。しかし、別の文字コードを割り当てられてしまえば、認識や検索のときには困るわけです。
＃「包摂」とは上記のunificationの訳で、異体字に同じ文字コードを割り当てることを意味します。
具体例を見てみましょう。渡邉利和さんがご自身の名前で調べたところでは、「渡邉」「渡辺」「渡邊」をinfoseek以外のサーチエンジンは厳密に区別します（今日現在で試したところ傾向は変わっていないようで、Googleはやはり区別しましたし、infoseekではどれでも同じ結果となりました）。
実は「わたなべ」の「なべ」はこの3種類に尽きるものではなく、例えばイースト社の「人名外字1500V3」には65種類の「なべ」が収録されているとのこと、これらすべてに別のコードが割り当てられたデータベースにおいて「渡辺」さんについての何らかの情報を検索する際、正しい検索語が何かわからなければ65回目でようやくヒットするかもしれませんし、他方で元データが誤っていれば、正しく検索語を選定したが故に必要なデータが見つからないということもあり得ます。
結局、この問題の根本は、コンピュータ（といいますかデジタルデータ）には人間にとってふさわしい程度のいい加減さがないという点に帰着します。人間同士の情報交換においては都合よく「渡邉」と「渡辺」を同じものとして扱ったり違うものとして扱ったりするわけですが、コンピュータにとっては、用いられる状況に依存して同じものだったり違うものだったりといわれても困るわけです。同じものはいつでも同じで、違うものはいつでも違うと。
このあたりはコンピュータの性能向上によって力ずくで解決していくしかないでしょう。例えば先に紹介のhan unification問題は地球上のあらゆる文字を2バイト（65,536文字）でカバーしようとしたところに一因があります。記憶媒体の容量増加や通信速度の向上によりそこまでバイト長に気を遣わなくてもよくなった現在（という理解でいいのかな?）では、CJK統合漢字としてより多くの文字に個別のコードを割り当てることにより、少なくとも異体字がコード上同じものとなってしまう事態はそれなりに解消されています。
それでも先の認識・検索問題は残るわけですが、これも力ずくでやろうとすれば、infoseek的なクエリ側の対応も可能でしょうし、Unicodeにおいても異体字タグだかセレクタだかで（ぐぐっても素人にはよくわかりませんでした・・・）、ある部分で同じ文字であることをアイデンティファイしつつ、それ以外の部分で違う文字であることをアイデンティファイすることが可能であるようです。
こうして技術的には解決策が見つかったとして、最後に残るのは経済的な問題でしょう。Unicodeでの上記のような対応が実装されても、シフトJISやEUCで処理しているレガシー部分をすべてデータ・アプリケーション・OSともに置き換えるのは莫大な費用がかかります。現に、こうした異体字をカバーし、さらに検索まで可能としている「超漢字4」が商品化されていますが、Windowsから皆乗り換えるかと言えばそうではないのが実態です。
いっそのこと政府が極めて横暴で、国内で販売されるソフトには「超漢字」シリーズなみの漢字処理能力を義務づける、といった強権発動をすれば解決する問題ではありますが、そのようなやり方が世に受け入れられるとは想像できません。ことフォント変更はやめろ、という主張に限るのであれば、そうしなければ商売に差し障るとマイクロソフトが認識すれば実現する話ではありますが、以上からお察しいただけるように、それはあくまで小手先の解決でしかないのです。
■ [government]霞が関におけるデフォルトのフォント
同じくWindows Vistaのフォントの話題を取り上げたpaco_qさんのエントリの注2において、ゴシック体をdefaultにしている人は珍しいと思うのですが，僕は高校時代（ワープロ時代）からずっとそうでした。もちろん正式な文章の場合にはさすがに明朝を使います。
とのことですが、霞が関においては実はゴシック体の方がメジャーで、むしろ明朝体をデフォルトにしている人の方が珍しいというのがwebmasterの観測です。理由は簡単、コピーを孫、曾孫、・・・と繰り返すことを想定した場合、ゴシック体は明朝体よりも明らかに劣化しづらいからです。
＃なお、上のエントリ関連で一言触れますと、このpaco_qさんのエントリでデータコンバートにより新旧フォントの共存が可能ではないかとのコメントがありますが、例えば葛飾の「葛」をすべて新フォントに変えてしまうと（地名の）葛城が不正確となり、では後に城が続くものはコンバートしないとすると、今度は人名で新フォントが実は正しいという人の名前は変換されず、とまあいろいろ乗り越えるべき壁があります。
paco_qさんも正式な文書は明朝体とのことで、多くの人にとっても公文書と言えば明朝体のイメージがあるかもしれませんが、それは対外的に発表したり交付したりするものにおいて明朝体が多く使われるからです。わざわざゴシック体と明朝体で使い分けるなんて面倒を何故するのか、という疑問もあるかと思います。その理由は、（あくまでwebmasterの推測ですが）かつては内部文書は手書きで、対外文書は和文タイプ＝明朝体という棲み分けだったのが、内部文書については当初はワープロ専用機、次いでコンピュータの導入により手書き文書がゴシック体のワープロ文書に置き換わっていったということかと存じます。
ところがこの置き換えが進んだ結果、対外文書も担当者が直接卓上で作成し、わざわざ和文タイプの浄書に回すなんてことをしなくなって久しくなります。まだまだお偉いさんの常識は対外文書は明朝体で、というものですから棲み分けは依然としてなされていますが、徐々に対外文書でもゴシック体でプリントされたものが増えてきています（特に官印を捺さないもの）。中長期的には、ますますゴシック体文書が増えていくことでしょう。
＃と若ぶって世代論的に処理したものの、例えば国会議員に資料を届ける際に添付する幹部名のレターなど、webmasterはまだ明朝体で作っているのですが、最近はゴシック体のものも散見したりするわけで・・・。
ご教示ありがとうございます。霞ヶ関ではゴシック体の方が主流とのお話，たしかに（ときどき）ヒヤリングなどに伺って渡される資料はゴシックのことが多いなあと気づきました。ゴシック体が見やすいと個人的には考えていますが，少なくとも大学の世界においてはかなりのマイノリティーだと思われます。
エントリでは主としてワープロ文書を念頭においていましたが、最近ではパワーポイントの使用も徐々に増えてきていて、これについてはゴシック系しか見ません。と考えると、大学でも経営系などはゴシック系が多かったりするのではないでしょうか。
大臣に読んでいただく文書をゴシックに指定した例があったような…？
私のエントリに言及いただきましてありがとうございます。この問題の根本には、漢字に無限の「造字性」があり、それを全てコードに置き換えることは不可能であり、取捨選択が必要であることだと理解しています。異体字を正字とともにコード化するとおっしゃるような認識、検索問題が出てきますが、現に既に多くの異体字、旧字がコード化されており、これら全ての異体字を排除するという「決断」をしないのならば、いずれにしても認識、検索問題は残ります。現状では「超漢字」のようなＯＳを日本人が全員導入するのが現実的でないので、どの異体字をコード化するかは結局はどこかで線引きするしかなく、その基準は社会的な認知、使用頻度によらざるを得ないのだろうと思います。今回「正字」に変更されることになる150の異体字が、これまで社会的に一定程度の通用力を持っていたとするならば、それを残すという選択肢はなかったのか、というのが私の考え方です。
そこは「包摂」という考え方で自縄自縛になってしまったのかなあ、と。あと、X0208が字体を変更していない(MS作業は準拠JISのX0208からX0213-2004への変更)わけで、MSがシステム外字にすべきだよなあ、と。
Refer http://internet.watch.impress.co.jp/www/column/ogata/sp19.htm
「邉」の字を使うものとしては、辺の異体字が２種類も人名用で許容されているのはありがたい（以前、墓石屋が彫り間違えたｗ）です。ワープロで「邉」が打てるようになって、以前は、電話帳でも滅多に見なかった「邉」の字を使う人が異常に増えたのが面白いところです。皆「辺」を使っていたようです。
旧字体使用問題が生じるのは主に人名・地名などの固有名詞です。これらは、せっかく表意文字であるところの「ひらがな」での読み仮名検索や、どうせIMEは複数登録するのですから、そのデータベースを拝借して人名・地名については表記の揺らぎを許容した検索をできるようにするというのもありかなと思います。英語だって、同じ発音でつづりが違うケースがあり、スペルチェックなどもやっているわけです。今の検索サイトなら「もしかして？」の検索拡張もありますので、コスト問題と大上段に構えるほどの問題ではなく単に検索エンジンの手抜きにしか見えません。
構築するに際し、初期投資が大きく、後の使いまわしは比例費が０に近いデータになりますので、表記揺らぎデータベースの構築は営利企業が自発的に行うとは思いにくいので、どこかの社団なりが音頭をとっても良いのかなと思います。
もともと人名漢字が異常に多くなった理由の一つに、手書きの出生届・戸籍などで誤字であろうと提出されたものが正しいという判断で文字数を増やしていた問題もあるのかなと思うことがあります。こちらは、今後の発生を抑える事ができますので、異体字の新規発生問題は今後収束していくのではないかと思ったりします。
というわけで、少なくとも工業規格というスタンダードでは字形の違いは文字コードの違いとし、検索はアプリ側で対応というのをお勧めしたいなと思います。
もちろん、社会的混乱を避けるため、異体字を全て排除するという考え方もわからないではないのですが、固有名詞は由来やら思いいれやらがあふれた世界ですので、難しいんじゃないかなと思います。
労働力人口比率をググルと、0.614（H14)と出てくる。
これだと真の失業率は5％になる。
8.9％というのは、街をみての実感とも合わない。
「文字の海、ビットの舟」
http://www.watch.impress.co.jp/internet/www/column/ogata/
を拾い読みされてから話されたほうが精神衛生上おとくかもとは思います。
他にも http://kappa.allnet.ne.jp/kanou/bookmarks.html#kanji あたりで紹介されているものもお役に立つのではないでしょうか。
http://internet.watch.impress.co.jp/www/column/ogata/news2.htm から引用します。
「それにしても、と私は思う。どうして文字をめぐる論争は、こんなにも感情的になってしまうのだろう？ 私が今思い出しているのは、1997年から翌々年にかけ、日本文藝家協会の人々を中心として展開された反Unicodeキャンペーンのことなのだが、これに対する私の感想は、ここで書かない。それというのも、私自身が熱くなってしまい、あっという間に長文になってしまうからだ」
今までの MS 明朝と違い Windows Vista で搭載されるフォントはあちらの人がかなり絡んでいるはずですが、それは"我々"が結局の所「文字」をg***DELETED for the Security Reasons***...
＞某臆病者さん、小僧さん
自分の姓名に関わる問題だったために過剰に反応してしまったというのは否めないと思います。ご紹介いただいた「文字の海、ビットの舟」などを読んでもう少し勉強してから、自分のところで改めて論じる機会を持ちたいと思います。
一つ追加ですが MacOS X では http://khdd.net/kanou/kangae/2003/gsub.jpg のように字体の変更が可能なのですが(とはいえこれを利用するアプリケーションはいまのところそれほど普及していませんが) Microsoft がこれと同様以上の OpenType 実装をまともにしているかで、心理的負担が軽くなるかどうかが変わるのでしょう。
＞某臆病者さん
そのあたり、省庁（というか大臣）ごとに差がある世界かと思いますが、でも想定問答だとだいたいゴシック体に統一されていますよね。ちょっと違う話としては、総理用の縦書きというのは他ではあまり見ないものではありますが。
＞AKITさん
拙文をご覧いただき恐縮です。おそらくご指摘の世間的認知、使用の程度問題というのは、エントリで市場次第といったこととそれほど差はなく、AKITさんのようなご意見が多く売り上げに響くのであれば、今からでも取りやめということはあり得ると思います。
文字コードとしては、一貫して字数を増やす、漢字で言えば異体字を別字として認識する方向に発展しているわけですが、実装の遅れはそのマイナスに由来する部分もあるわけで、だからこそかねてから議論の多い分野なのだと思います。
＞鍋象さん
サーチエンジンはまだ発展している方で、ローカルでの検索（ワープロやスプレッドシート、ブラウザ、メーラーなど）では単純なコード一致しか拾えないものがほとんどです。アプリ側で対応は自然な方向だとは思いますが（例えば本文で言及した異体字タグなどは、アプリが対応してくれないことにはコードの意味がありませんし）、サーチエンジンほどの機能が各アプリに実装されるのは、やはりコスト問題という気もします。
デスクトップ検索はまだ試していないので、これが十分に軽いのなら、アプリごとではなく検索アプリとして組み合わせ使用でいいということなのかもしれませんが。
＞一国民さん
完全失業率として公表される数字はそのときどきの労働力人口比率をベースとするものですから、例えば6月の4.2%は、当該月の公式労働力人口比率に対応しています。
この試算の趣旨は、失業者のうちそれなりの数が就業意欲を喪失した結果、「完全失業者」ではなく「非労働力人口」にシフトしたのではないかという問題意識から、「非労働力人口」のうち一定数（その考え方としてピーク時の労働力人口比率を用いています）を「完全失業者」としてカウントすれば失業率は見かけより高いのではないかというものです。
なお、完全失業率ベースであっても6%台の地域は散見され（詳細は下記URIにてご覧ください）、また若年失業率の高さは（最近改善傾向にありますが）とみに指摘されていますので、切り取り方によってはまだまだ雇用環境が厳しい部分は多く見られるのではないかと思います。
http://www.stat.go.jp/data/roudou/2004n/ft/index3.htm
＞小僧さん
削除部分がgraphicsということでしたら、石原さんも書いていたことではありますが、究極の文字コードとは画像としての文字認識、実装としてはフォントのベジエ曲線等のデータを直接操作するものなのかもしれません（要求スペックがどのぐらいになるのかはわかりませんが）。
しかしいつも思うのですが、小僧さんって博学ですよね・・・。
削除部分は(ゲフンゲフン)とか...と同様で砂を掛ける表現を自粛したものです。おおや先生がたまに書かれるパターンを拝借したのですが誤解を招く表現だったようで申し訳ありません。
画像としての文字という論点についての記述を本文で削ったので、その未練でバイアスがかかって、そのように読み取ってしまいました（笑）。
検索エンジンでも
http://www.justsystem.co.jp/conceptsearch/
これなんかのように、中で「渡辺＝渡邊」などの統制辞書を持っててちゃんと双方向に一致とみなして検索してくれるのもあります。
日本語を真っ当に検索しようと思ったら、「組み込み＝組込み」とか「受付＝受け付け」とかも一致させなきゃいけないのでそういう辞書がホントは必要なんですよね。あとそれとは別に同義語辞書なんかも。しかしgoogleとかは日本語特化型じゃないので、そういうのはまだまだ先になるでしょう。
>tockriさん
日本語の検索については、ジャストシステムが鍵となるかもしれませんね。あそこはかなり日本語の研究に力を入れてるはずです。
MSと結ぶことはないだろうから、GoogleかYahooと提携するかも。
bewaad さんのページにリンクされている所でずっと詳しい方がいらっしゃるので恥の上塗りを覚悟の上で。お役に立つと信じて投稿しますが、やっつけで間違い多数につきその点に御高配賜わりたく存じます。
同じ文字は何かという問題はかなり複雑なので一旦無視します。
(漢字の異体字の他にも Latin script の ligature とか Arabic script の色々な...)
文字の抽象化をいいかげんに整理してみると、厳密な定義は放っておくとしても
A. 実装されたグリフ図形のデータ達
B. 字形を定義した集合
C. 抽象化された文字の集合 (番号がついている事もあるし、名前がついていることもある)
D. ネット上などで流通する数字列として encode された文字集合 (複数の C. を持つこともある)
が思いつきます。ここで注意しなければならないのは、<strong>これらは同じものではありません</strong>。例えば表示するフォントを変えることで同じ D. のであっても A. の段階で表示されるものは変わってきますし、同じフォントでも縦書から横書に変えると B. の段階で変わる訳ですから。
一方で既存の表を見てみれば分かることは、いいかげんに申し上げると
Shift_JIS とか EUC とかは D.
法務省の人名用漢字表では B. でもあり A. でもある?
今回話題の表外漢字表は A. に近い B.?
JIS の規格 (X0208 とか X0213 とか色々あるが差異は無視) とかは色々な騒動 (83 年の X0208規格改正で鴎外の「鴎」の字形が変わったことなど) と反省を経て規格として定めているのは C. と B. のある程度の基準と D. です。A. は(16 ドット日本語フォントを定義している規格とは違い) sample として定義されたものだけです。とはいえ sample 実装はある程度の正統性を外形として備えてしまうことがしばしばあるのは事実ですし、今回の JIS 0213 改定で表外漢字表の影響下で A. が改変されたことが Meiryo のグリフ変更に繋がっているのだと推測されます。
PDF などで使われる CID は B.
Unicode も B. C. D. ?
一方 ABCD の間には色々な変換表が介在しています
PC9800 などのころは昔のフォントは D. と A. が同一視されていた。
Shift_JIS から EUC の変換表は D. から D.
OpenType の cmap は D. から A.
OpenType layout の GSUB (グリフ置き換え) は A. から A.
OpenType になる前の CID フォントの CMap は D. から B.
B. をある CID フォントに対して適用すると A. が定まる。
かなり単純化を施した後でさえも、文字の抽象化のレベルとその間の変換表の錯綜具合が存在しています。このことが問題を悪戯に複雑にしているのは否めないのですが、同じ文字は何かという問題が表意文字だけではなくアルファベットのような表音文字でも厳然と存在する以上、ある程度はしかたがないことです。
ただしこれらのことを皆が理解した上で規格や表が定まる訳ではなく、歴史的な経緯によりこのレベルが混同されている所はいくつもありますし、無知な人の価値観の表明が bargaining power と結び付いてさらに混乱を招いてしまっているのかなと。
日本語検索についても Web 情報に限定しなければ、NII の Webcat plus のような連想検索は現在でもあります。また究極の文字コードを目指していると言えそうな project は CHISE などがあります。多言語化については Nemacs や mule の頃からの蓄積があるでしょう。大規模な日本語辞書に関しては小学館の日本国語大辞典や諸橋漢和などがありますし、日本語コーパスも色々な物があります。PC 上のシソーラスは市販されていたはずです。ただ英語での Shakespeare や OED と違いそれらが文化セットとして記載されていないのかなぁと。
最後に AKIT さんの二点しんにょうについてですが実際に可能か知らないで述べさせていただきますが、御自分で表示される場合は GSUB の段階で解決するのもありなのかなとは思います。
リンクは略します。
(読みかえしてみると偉そうだなぁ)
＞tockriさん
Googleはカタカナの別表記（ヴェトナムとベトナムなど）はかなり頑張っているように思います。
ただ、最近のMS-officeにありがちですが、アプリ側であまりいろいろしだすと、もっと単純な機能を前提に蓄えたノウハウが変に無効化されたり、余計な挙動でいらいらしたりと、なかなかバランスが難しいですよね。
＞Baatarismさん
これまで組織内での業務フローなどについてソフトウェア工学の応用をあれこれ妄想してきたことと似ているように思いますが、IME関連の技術開発が既存の言語学とは異なるアプローチで思わぬ発券をするのでは、という気はします。
＞小僧さん
素人の勝手な理解としては、文字を人間がいかに使うかの用法によって適したデータセットがあり、つまりは人間は文字を多様に用いているわけですが、それを文字という単一の体系とアイデンティファイするところに認知のずれがあるのかな、という気がします。ネットワーク構造のようにレイヤーに分けて考えたりすると、少しは議論が整理され得るのかな、なんて生易しい話ではないのでしょうけれども。
> bewaad さん
幸か不幸か分かりませんが、そのようなことはないのであります。
文字は身近なものですから言いたいことがあるのは然りとは思いますが、そのレベル(グリフと文字コードの独立性)で最小限整理した上で話をしてもらわないと表外漢字の騒動にしろ、AKIT さんの最初の反応を引き出した新聞記事にせよ、僅かながらも存じ上げている人間からすると困惑せざるを得ない訳です。
> tockri さん
他にも国立国語研究所のひまわり
http://www.kokken.go.jp/lrc/index.php?%B8%C0%B8%EC%A5%C7%A1%BC%A5%BF%A5%D9%A1%BC%A5%B9%A4%C8%A5%BD%A5%D5%A5%C8%A5%A6%A5%A7%A5%A2
などもあります。他の企業でも形態素解析などこのあたりは飯の種になるでしょうからいくらでも prototype はあるでしょう。
あ、ちょっとミスリードでした。「プロ」から見ればどの切り口の話よ、という入り口において、外部ではいろいろな混同があってかみ合わないのかなという趣旨でした。教育論もそうですが、身近であればあるほど自らの経験を一般化しがちであるように思います。
Windows Vistaのフォントは、Adobe-Japan1-6経由でJIS X 0213:2004を実装する予定なので、たとえば「1点しんにょうの辻」はCID=3056に、「2点しんにょうの辻」はCID=8267に収録されて、両方とも使えるはずなんですけど？ うーん、どこで話が食い違ってるのかなぁ…。
>安岡さん
漢字袋の安岡先生まで見てらしているとは、書くんじゃなかった ＿|￣|○
それはともかく、今回の騒動は元ネタの記事を書いた新聞記者が複雑怪奇な文字コードと OpenType の実装について知らずに書いているだけなんじゃないでしょうか。(取材源を秘匿する必要がない場合だけでもいいので、新聞記事であってもせめて internet 上の記事にはプレスリリースの URI を link するなりして self-contained な外形を取るのはそろそろ止めて欲しいと...) 一応個人的に弁解しておくと Windows Vista のフォントの実装がどうなっているか (TrueType ではなく Type2 ならほぼ大丈夫でしょうとは言えたのですが) 具体的に存じ上げていないので、前の comment には実装次第でなんとかなるけどと濁した形で書かせていただいた次第です。
プレスリリースは http://www.microsoft.com/japan/presspass/detail.aspx?newsid=2353
で、また http://www2.xml.gr.jp/log.html?MLID=xmlmoji&N=1636 の情報が正しいとすると、そこそこの解は用意されるようですね。
＞安岡孝一さん、小僧さん
的確なご指摘をいただくことができ、bloggerとして本当にうれしく思います。ありがとうございます。
昔の話をほじくりかえしますが、面白い話を見つけたので http://khdd.net/kanou/kangae/2005/Dec.html から引用します。
----
たった 7 万しかないのか、と思ったとしたらあなたは巨大漢字集合など実際に必要とはしない生活を送っており、実際にそれらを使うため苦労をしたことが無いにちがいない。とにかく 7 万文字を規格に入れてしまったはいいが、それに対処する段になって実装者も利用者も規格制定者までもが漢字の洪水にアップアップしているのが現状なのである。(snip) 最後のほうに出てきた「2, 30 年前の、6000 とか 7000 とかの目が行き届く範囲でやっていた牧歌的な時代とは違う」、という発言 (秋山さんの言葉か他の方だったか忘れたが) を聞いてつくづく思うのだが、漢字文化圏の教養人が使いこなしていた (「使いこなす」の定義は、「形音義の全てがちゃんと解る」こととしよう) 漢字数は昔からその程度で、この値は千年以上変わっていないんじゃないだろうか。
----
ちなみに上に書かれている Adobe-Japan1-6 は 2 万位だったと思いますが、まともに使えるアプリケーションはあんまりないような気がします。(VISTA ではそこそこ使えそうではありますが、使える利用者がどれほどかは...) JIS の第一水準は 3000 弱です。
＞小僧さん
当用漢字なり常用漢字なりもコンセプトとしては同じかと思います。別に日本語特有というわけでなく、longmanが語義を基本語のみで記述しているように、多くの場合においてそれほど多くの漢字なり単語なりというものは使いようもなく、それは人間の情報処理力の制約であるような気がします。