アカウント名:
パスワード:
つめれば12byteはさすがにいらないとは思いますが、 内部処理上では、基本コード＋異体字用コード＋オプションで、 4×3=12ってのはありそうな話ですね。 Unicode でも、サロゲート、コード本体、異体字タグ前後、 異体字コードとか駆使することになると、可変長で最大 そのくらいいきそうです。
大半の文字はそういった異体字は不要なわけで、変に全部を とりこもうとするコード体系を使うよりも、XMLでもなんでも 良いですが「タグづけ」を行ってアプリケーションレベルで 処理してしまうほうのが得策でしょう。 OSレベル(すなわち一般
こういうものが出来るとは思えません。ある漢字がある日二つの異体字に分かれたとして、元々その漢字で蓄積されていた情報が本来はどちらの文字を想定したものであったのか、を識別するのは機械的に出来る話ではありません。人手介入の工数が発散するだけでしょう。
元々の情報には、異体字のどちらであったかという情報を識別する手段がなかったため Unify されて特定のコードポイントが指定してあったわけです。これはこれでそのままでいいのかという問題もあります (例えば、現行の JIS で高橋さん、の名簿があったとき、はしご高を新規に文字として取り込んだらその名簿の方も直せ、と主張する人は一杯いますよね)。また、更に文字をどんどん追加していくことを考えるなら、各文字ごとに更新の何らかのタグも必要です (これがないと、特定の時点で特定の異体字との間の区別がなかったからこの字にしていたという情報が失われる)。また、ある文字に対して書き手が認識できる異体字の種類には制限が出てきますから、それを情報として残していく手段もいる。
どちらにせよ、単に文字を登録できればいいと言う話ではないと思いますね。
同意。但し、私は昔から情報交換用のコードと情報蓄積用のコードは別物だと考えていて、後者については上記の情報を文字情報に含めるべきである、と考えています (上記は元々各文字の属性に起因する情報ですし、編集の際に失われないことを考慮するならその方がいい)。また、この種の情報を B/Right のようにまとまったテキスト (段落など) の情報として情報を残そうとするのは筋違いだと思う (なぜならば、これはその文書を編集した際の情報であり、まとまったテキストに付随する属性ではない)。
＃個人的には、今となっては TRON コードは発想の古さが耐え難い。
>「文字コードと登録された文字実体への参照、の二本立て」
否定はしないです。また、その考え方で作られたシステムが現状のものよりましになる可能性があることも同意。でも、これが解決という気がしないんだなぁ。たぶん、文字コードを議論している方が暗黙のうちに仮定している、「一つの文字には、まず文字という概念があり、それにたいして異体字という表現が複数ある」と割り切れないためかもしれません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
あらゆる漢字を扱えること (スコア:1, 興味深い)
知り合いの印刷屋から聞いた話ですけど，例えば銀行からの
ダイレクトメールの場合，顧客に失礼がないように顧客の名前を
「忠実に」漢字で印刷しなければならないそうです。ちょっと
前まで戸籍登録の際に使用できる漢字には制限がなかったそうで，
そのために誤字までもが正式な名前に使用される漢字
Re:あらゆる漢字を扱えること (スコア:1, 興味深い)
つめれば12byteはさすがにいらないとは思いますが、 内部処理上では、基本コード＋異体字用コード＋オプションで、 4×3=12ってのはありそうな話ですね。 Unicode でも、サロゲート、コード本体、異体字タグ前後、 異体字コードとか駆使することになると、可変長で最大 そのくらいいきそうです。
大半の文字はそういった異体字は不要なわけで、変に全部を とりこもうとするコード体系を使うよりも、XMLでもなんでも 良いですが「タグづけ」を行ってアプリケーションレベルで 処理してしまうほうのが得策でしょう。 OSレベル(すなわち一般
Re:あらゆる漢字を扱えること (スコア:1)
文書(データ)としては「考えない限り」とおっしゃっている「編集」は必須だと思っちゃうし、検索のためのインデックス処理をどうやるのかもわからんし(古い計算機屋的考えなん
本当かい♪本当かい♪
Re:あらゆる漢字を扱えること (スコア:2, 興味深い)
「編集」の場合、何が難しいんでしょうか？
＃遅くなってUIとして受け入れがたいという主張なら理解しますが。
Unicodeみたいに「グリフIDやその実体参照表現と違って、サイズが
固定の文字セットだからコンピュータで効率よく扱うことができる」
という幻想を与えておきながら、2, 3年に一度改定されるのに
振り回され続けたいですか？
注： Unicodeコンソーシアムは1991設立で、最新はUnicode 3.2です。
＃個人的には文字コードなんて基本的なものは、10年に一度の改定でも、
＃十分迷惑だと思います。
それよりは、いっそのこと文字のレパートリーが、日々増
Re:あらゆる漢字を扱えること (スコア:1)
>仮定したシステムを頑張って作ってしまった方が簡単なんじゃなかろうか
>と妄想しています。
こういうものが出来るとは思えません。ある漢字がある日二つの異体字に分かれたとして、元々その漢字で蓄積されていた情報が本来はどちらの文字を想定したものであったのか、を識別するのは機械的に出来る話ではありません。人手介入の工数が発散するだけでしょう。
Re:あらゆる漢字を扱えること (スコア:1)
安岡先生の漢字袋 [kyoto-u.ac.jp]は、その簡易な型だと思います。
＃色んな意味でリソースが必要なのは認めます。
異体字の話ですが、ごく最近に異体字に分かれたものであれば、その
理由は調査できるはずです。というか、それを明らかにするためにも、
登録という手続きは必要です。
ところで、なぜ古いものを二つに分類する必要があるのでしょうか？
単に古い文字Aに対して、新しくその表現形としてグリフBとグリフCが
追加された場合ですよね？古いものはそのままAを使い、新しい物は、
必要に応じてABCを使い分けるということで構わないのではないでしょうか。
例えば、中国・日本の古典で使われた漢字が、中国と日本で異なる
簡略化の結果、グリフが増えた場合と同じだと思いますが。
Unicodeでは、その三つで別のコードが振られていると思います。
＃このパターンで異体字が増えた漢字はたくさんありますよね？
Re:あらゆる漢字を扱えること (スコア:1)
>単に古い文字Aに対して、新しくその表現形としてグリフBとグリフCが
>追加された場合ですよね？古いものはそのままAを使い、新しい物は、
>必要に応じてABCを使い分けるということで構わないのではないでしょうか。
元々の情報には、異体字のどちらであったかという情報を識別する手段がなかったため Unify されて特定のコードポイントが指定してあったわけです。これはこれでそのままでいいのかという問題もあります (例えば、現行の JIS で高橋さん、の名簿があったとき、はしご高を新規に文字として取り込んだらその名簿の方も直せ、と主張する人は一杯いますよね)。また、更に文字をどんどん追加していくことを考えるなら、各文字ごとに更新の何らかのタグも必要です (これがないと、特定の時点で特定の異体字との間の区別がなかったからこの字にしていたという情報が失われる)。また、ある文字に対して書き手が認識できる異体字の種類には制限が出てきますから、それを情報として残していく手段もいる。
どちらにせよ、単に文字を登録できればいいと言う話ではないと思いますね。
Re:あらゆる漢字を扱えること (スコア:1)
はい、了解。
＃これは、どうしょうもないですよね。仕組みでは救えない。
> また、更に文字をどんどん追加していくことを考えるなら、各文字ごとに更新の何らかのタグも必要です
そういう情報は必要でしょう。
ただ、それを文字コードに含めるおつもりでしょうか？
＃異体字情報を記述する制御コードに関する規格？
厳密な区別や高度な検索が必要な場合に使う、オプション規格ならば賛成です。
＃たぶん、漢字に特化した規格になるでしょうから、規格の必須な
＃規定にしても、どうせ外人さんは実装しないんじゃないかと。
>どちらにせよ、単に文字を登録できればいいと言う話ではないと思いますね。
何を登録するかの話に発展しているのだと考えています。
ところで、確認したいのですが、
「文字コードと登録された文字実体への参照、の二本立て」
という方式自体は同意可能ですか、積極賛成でないにしろ？
＃登録内容として本字の文字コード、異体字記述、グリフがあって、
＃その登録内容をオンラインで参照できれば、原理的には処理可能か？
Re:あらゆる漢字を扱えること (スコア:1)
同意。但し、私は昔から情報交換用のコードと情報蓄積用のコードは別物だと考えていて、後者については上記の情報を文字情報に含めるべきである、と考えています (上記は元々各文字の属性に起因する情報ですし、編集の際に失われないことを考慮するならその方がいい)。また、この種の情報を B/Right のようにまとまったテキスト (段落など) の情報として情報を残そうとするのは筋違いだと思う (なぜならば、これはその文書を編集した際の情報であり、まとまったテキストに付随する属性ではない)。
＃個人的には、今となっては TRON コードは発想の古さが耐え難い。
>「文字コードと登録された文字実体への参照、の二本立て」
否定はしないです。また、その考え方で作られたシステムが現状のものよりましになる可能性があることも同意。でも、これが解決という気がしないんだなぁ。たぶん、文字コードを議論している方が暗黙のうちに仮定している、「一つの文字には、まず文字という概念があり、それにたいして異体字という表現が複数ある」と割り切れないためかもしれません。
Re:あらゆる漢字を扱えること (スコア:1)
> 後者については上記の情報を文字情報に含めるべきである、と考えています
興味深いです。
ただ、人間の頭の中まで自動更新はできないので、運用は大変かも。
新しい文字ができると、ユーザはその新しい文字の意味を知った上で、
異体字を選ばないといけないわけです。かな漢字変換のサブシステム
として異体字入力を作って、そこに出る候補は随時更新し、必要で
あれば、その文字に関する情報を表示するという手しかないのでしょうか。
＃辞書なんてどうするんだろう。
テキストに含めないと言うのは、当然そうあるべきだとおもいます。
> でも、これが解決という気がしないんだなぁ。
それは、おっしゃる通り。でも、最初から完璧な枠組みを作るのが、
難しい程度には、文字の文化に差や流動性があるから、少しずつ進め
た方がよいだろうし、失敗しないためには、多重化しておいた方が
無難かなぁと思うわけです。
> 「一つの文字には、まず文字という概念があり、それにたいして
> 異体字という表現が複数ある」と割り切れないためかもしれません。
私もそれは嘘だと思います。例えば、「沈澱」を「沈殿」と書いて
よいそうです。
＃というか、教育の場で後者を教えている。
これって、「澱」と「殿」がUnifyされて「殿」という文字に「おり」
という意味が付与されたのでしょうか。それとも「澱」の異体字として
「殿」が利用可能になったと考えるのでしょうか。
件の言明が正しいのであれば、そのどちらかだと思うのですが。
＃おそらく、一般的にはどちらも賛同は得られないでしょう。
＃私は、Unifyは話が面倒になるので、後者であって欲しいと思います。
＃あくまで、どちらを選ぶかと言われればですが。
意味と形と音と言語における用法に関して、明解な基準がないから、
コンピュータに乗りにくいのですよね。また、同じ漢字を使う
日本、中国、韓国で、それらに対する考え方が異なるのも頭痛いです。
＃まず、日本の国語審議会自身が日本語をゆがめていたのを認めて
＃もらわんと。