アカウント名:
パスワード:
つめれば12byteはさすがにいらないとは思いますが、 内部処理上では、基本コード＋異体字用コード＋オプションで、 4×3=12ってのはありそうな話ですね。 Unicode でも、サロゲート、コード本体、異体字タグ前後、 異体字コードとか駆使することになると、可変長で最大 そのくらいいきそうです。
大半の文字はそういった異体字は不要なわけで、変に全部を とりこもうとするコード体系を使うよりも、XMLでもなんでも 良いですが「タグづけ」を行ってアプリケーションレベルで 処理してしまうほうのが得策でしょう。 OSレベル(すなわち一般
こういうものが出来るとは思えません。ある漢字がある日二つの異体字に分かれたとして、元々その漢字で蓄積されていた情報が本来はどちらの文字を想定したものであったのか、を識別するのは機械的に出来る話ではありません。人手介入の工数が発散するだけでしょう。
元々の情報には、異体字のどちらであったかという情報を識別する手段がなかったため Unify されて特定のコードポイントが指定してあったわけです。これはこれでそのままでいいのかという問題もあります (例えば、現行の JIS で高橋さん、の名簿があったとき、はしご高を新規に文字として取り込んだらその名簿の方も直せ、と主張する人は一杯いますよね)。また、更に文字をどんどん追加していくことを考えるなら、各文字ごとに更新の何らかのタグも必要です (これがないと、特定の時点で特定の異体字との間の区別がなかったからこの字にしていたという情報が失われる)。また、ある文字に対して書き手が認識できる異体字の種類には制限が出てきますから、それを情報として残していく手段もいる。
どちらにせよ、単に文字を登録できればいいと言う話ではないと思いますね。
同意。但し、私は昔から情報交換用のコードと情報蓄積用のコードは別物だと考えていて、後者については上記の情報を文字情報に含めるべきである、と考えています (上記は元々各文字の属性に起因する情報ですし、編集の際に失われないことを考慮するならその方がいい)。また、この種の情報を B/Right のようにまとまったテキスト (段落など) の情報として情報を残そうとするのは筋違いだと思う (なぜならば、これはその文書を編集した際の情報であり、まとまったテキストに付随する属性ではない)。
＃個人的には、今となっては TRON コードは発想の古さが耐え難い。
>「文字コードと登録された文字実体への参照、の二本立て」
否定はしないです。また、その考え方で作られたシステムが現状のものよりましになる可能性があることも同意。でも、これが解決という気がしないんだなぁ。たぶん、文字コードを議論している方が暗黙のうちに仮定している、「一つの文字には、まず文字という概念があり、それにたいして異体字という表現が複数ある」と割り切れないためかもしれません。
コード領域は無限ではありませんが、どんな文字でも受け入れているように見えますが [tron.org]。
ま、とりあえず0～2についてはこのへん [tron.org]とかこのへん [tron.org]などを読んでみて下さい。
3,4については、こういうの [chokanji.com]とかこういうの [chokanji.com]が既に製品化されているので、あと一歩ってとこですかね。でも、OS非依存になってしまったら、肝心のクライアント [chokanji.com]が売れなくなってしまうので、商売としてはつらいものがあるでしょう（ｗ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
あらゆる漢字を扱えること (スコア: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年に一度の改定でも、
＃十分迷惑だと思います。
それよりは、いっそのこと文字のレパートリーが、日々増えていくことを
仮定したシステムを頑張って作ってしまった方が簡単なんじゃなかろうか
と妄想しています。
確かにレパートリーがガンガン増えたら、システム自体は何年かに
一度作り直す必要があるでしょう。でも、全体の枠組を見直す頻度は、
ぐっと下がるはずです。
＃どっちが技術屋として嬉しいですか？
また、グリフの考え方では、基本的に文字を無限集合ととらえていて、
「何が文字か」、「これはこの文字と同じ文字ではないか」といった、
判断を行うことはありません。だから、登録さえすれば会社のロゴだって、
グリフとして登録可能です。「俺の名前は文字コードで表せない」と
言っていた人達も安心できるというもの。
＃しかし、登録機関って今動いているんでしょうか？＞SC34の小町さん。
＃って、ここで呼んでも出て来ないか。
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は話が面倒になるので、後者であって欲しいと思います。
＃あくまで、どちらを選ぶかと言われればですが。
意味と形と音と言語における用法に関して、明解な基準がないから、
コンピュータに乗りにくいのですよね。また、同じ漢字を使う
日本、中国、韓国で、それらに対する考え方が異なるのも頭痛いです。
＃まず、日本の国語審議会自身が日本語をゆがめていたのを認めて
＃もらわんと。
Re:あらゆる漢字を扱えること (スコア:1)
編集は、結局その文字を使うならなんらかのコードは与えなくちゃ他から簡単には使えないだろうな、と。
ただ、それでも既存の表現との関連(異体字なわけで、読みとか意味は同じ?)はなければいけないんじゃないかな？と考えたり、と。
アプリというよりはシステムと運用も絡んできちゃいそうで、なんか考えがまとまらないというのが正直なところです。
別にUNICODEで十分なんていいませんし、フォントを作るというのはどちらかというと賛成なんですが、
結局他でも使えるようにしようと思うと結局UNICODEと同じような羽目になりそうだなぁ、とも。
ただ本当に個別に埋め込むだけでは非効率的過ぎると思うし。
「よみがな」をインデックスにして、誰かが創ったかどうかを確認してあったら流用とかかなぁ?
うーん、結局力任せなら確かに、他からの流用は完全無視して、ともかく必要な文字を全部作り上げると。後で統合とかか。統合でもめそうだけど。
スマートにやろうというのは確かに計算機屋な発想だな、と再確認ｗ
本当かい♪本当かい♪
Re:あらゆる漢字を扱えること (スコア:1)
でも、その内部コードへの漢字を割り当てを考えたら、頭痛くなりません？
そんなこと考えるより、文字の定義(名前または文字コード)をもつ
共用体へのポインタとして扱った方が簡単だったりしませんか？
＃特定のシステムまたはアプリケーションの中では。
＃交換時には、文字コードと実体参照形式に戻す。
> ただ、それでも既存の表現との関連(異体字なわけで、読みとか
>意味は同じ?)はなければいけないんじゃないかな？と考えたり、と。
でも、これって普通の文字コードでも必要ですよね。JIS X 0208だって、
第2水準だと読みですら並んでないですし。
＃あぁ、ちなみに私は文字コード自体には反対しないです。
＃でも、皆が考えているように文字コードおよび文字セット在りきでは、
＃救えない要求があると思ってるだけです。
> 「よみがな」をインデックスにして、誰かが創ったかどうかを
> 確認してあったら流用とかかなぁ?
JISには、誤って採録された嘘字(使用例も読みもない文字)すらあります。
＃それに「よみがな」は日本でしか通用しない。
> スマートにやろうというのは確かに計算機屋な発想だな、と再確認ｗ
相手となる言語や文字がスマートじゃないわけですから。
＃暗号の堅牢性の検証実験みたいに「ブルートフォースをいかに
＃スマートな手法でふるうか」という話ではないでしょうか。
Re:あらゆる漢字を扱えること (スコア:1)
＞そんなこと考えるより、文字の定義(名前または文字コード)をもつ
＞共用体へのポインタとして扱った方が簡単だったりしませんか？
ええ、でも、文字の定義を与える時点で、なんらかのルールとの整合を持たせるわけですから、
文字コードを振るのと本質的には変わらない、つまり、今までの問題と同じ面をもつような。
＞でも、これって普通の文字コードでも必要ですよね。JIS X 0208だって、
＞第2水準だと読みですら並んでないですし。
ええ、既存の文字コードのルールも完璧なものではないと思ってます。
結局、その文字コード・定義?の与え方(ルール、方針ですかね)はまだまだ研究の余地があるよなぁ、と。
で、AC氏のは、究極そういうルールを決めるのが大変(終わりが見えない)なら、うっちゃって、まずは目的優先で管理せずにがんがん創っちゃえ、ってことかなぁ、と。
文字の名前を便宜的に与えるなら「どこそこのなにがしの名前何文字目の文字」みたいなｗ
＃創ったときの部品を目印に後から検索して、以前に創ったことあるかどうか位はチェックできるかな?
本当かい♪本当かい♪
Re:あらゆる漢字を扱えること (スコア:1)
> 文字コードを振るのと本質的には変わらない、つまり、今までの問題と同じ面をもつような。
実は、そのルールはあります。
文字コードは一意に決定できないといけないですが、グリフの識別子は、
極端な話をすると一意じゃなくても構いません。
＃正しくグリフを指示できればよいだけで。
例えば、グリフ識別子管理者名+IDみたいな形になっていれば、
別の管理者が同じ文字に対して別のIDを振っても問題は少ないし、
さらに極端に言えば、この識別子はURIなんかでも構いません。
＃URIが差す先の定義の形式はもちろん標準化の必要があります。
この重複をチェックして、名寄せを行って文字セットを定めるのは、
文字コードを制定者の仕事だと思います。
で、件のAC氏は、その管理者としてAdobeを、定義の形式として(?)CIDに
してしまえと言っているのではないかと。
＃手をつける最初の段階としては、悪くないかもしれないです。
ちなみに、私が言ってるのは、実はISO/IEC規格の説明なのです。
が、古い記憶で書いているので、間違いもあるかと思います。
興味があったら、
グリフ登録関連文献のサーチ結果 [google.co.jp]を拾い読みして下さい。
＃AdobeのCIDなんてのも、これを受けてできたものなのですよ。
だから、それがTRONでしょ？ (スコア:1)
コード領域は無限ではありませんが、どんな文字でも受け入れているように見えますが [tron.org]。
Re:だから、それがTRONでしょ？ (スコア:1)
Re:だから、それがTRONでしょ？ (スコア:1)
しかし、残念ながら私はTRONコードには無知なので、私が文字コードに
対してもっている要求のどれだけが満たされているか教えていただけ
ないでしょうか。
(0) これまでの文字コードと混在できる。
(1) 文字をその名前(識別子)で参照する。
(2) 文字は字形や配置情報をその属性にもつ。
(3) 文字の情報はサーバで提供する。
(4) 対応しているAPならば、OSに依存せずに利用できる。
これらはXML(SGML)の実体参照を文字の識別子として使えば、
原理的にはクリアできるだろうと思っている項目です。
もちろん、文字への参照をすべてこれで行うのは効率が悪いので、
既存のなんらかの文字コードの仕組みをキャッシュとして用いる
のでしょうけど。
＃要するにブラウザなどが知らない実体参照に出くわした場合にだけ、
＃文字サーバにアクセスするわけです。
＃まぁ、妄想してるだけで実装や普及活動はできないでしょうけどね。
Re:だから、それがTRONでしょ？ (スコア:1)
ま、とりあえず0～2についてはこのへん [tron.org]とかこのへん [tron.org]などを読んでみて下さい。
3,4については、こういうの [chokanji.com]とかこういうの [chokanji.com]が既に製品化されているので、あと一歩ってとこですかね。でも、OS非依存になってしまったら、肝心のクライアント [chokanji.com]が売れなくなってしまうので、商売としてはつらいものがあるでしょう（ｗ
Re:だから、それがTRONでしょ？ (スコア:1)
普及のためには、TRONコードを扱うWindows用ライブラリとWindows用
ウェブブラウザぐらいは必要なのではないでしょか。
データベースサーバはTRONで動くとしても。
＃でも、私の言うサーバはあくまでも文字情報のサーバであって、
＃いわゆるデータベースでは無かったのだけれど。