アカウント名:
パスワード:
そのへんの『ブンカ』が理解できると称するやからは、日本語をシステムにのっける上で何が問題になるのかすら理解できなかったんだから、おあいこでしょ。
ここ [forus.or.jp]で公開されていますね. gkrellm等で愛用しています.
つめれば12byteはさすがにいらないとは思いますが、 内部処理上では、基本コード＋異体字用コード＋オプションで、 4×3=12ってのはありそうな話ですね。 Unicode でも、サロゲート、コード本体、異体字タグ前後、 異体字コードとか駆使することになると、可変長で最大 そのくらいいきそうです。
大半の文字はそういった異体字は不要なわけで、変に全部を とりこもうとするコード体系を使うよりも、XMLでもなんでも 良いですが「タグづけ」を行ってアプリケーションレベルで 処理してしまうほうのが得策でしょう。 OSレベル(すなわち一般のインターフェースも含む)でそこまで しようとすると、現在のマシンパワーでも辛いと思います。 ただでさえ「英語版」に比べてやたらパフォーマンスの悪い 「日本語版」 Windows がもっと重くなるのは勘弁。
現状で「あらゆる漢字を扱えること」という要求に対して、 印刷まで含めた解を求めるなら、素直に、計算機屋さん発想 (合理的なコード体系を!)ではなく、印刷屋さん発想(俺は あらゆるグリフを作る!)な PDF 技術の延長で処理するのが 無難でしょう。フォント(グリフセット)を定義して、準備 してしまえば、事実上無限に文字を増やすことができますし、 フォントの埋め込みもその仕様に入っていますから、編集を 考えない限りは(全部うめこめば可能)、相当の環境において 普遍的に扱うことができるわけで。
TRONはあらゆる文字って点では印刷屋さん的なんだけど、 それを一つにおしこめようとしてる時点で、古い計算機屋 さんなので却下です。
文字の統廃合をするにせよ、全部もりこむ方針でいくにせよ、 とりあえず収集して、「住民基本台帳用追加コード」として まとめてしまって、それのフォント作成＆オープン化を行って しまえば、現行のシステムで普通に扱えるようになるわけで、 まずはそのあたりからやってほしいところです＞総務省。 TRON でも Unicode でも、収納されるの待ってたら日が くれちゃうよ。Adobe あたりとつるんでざくざく作って しまうヨロシ。
こういうものが出来るとは思えません。ある漢字がある日二つの異体字に分かれたとして、元々その漢字で蓄積されていた情報が本来はどちらの文字を想定したものであったのか、を識別するのは機械的に出来る話ではありません。人手介入の工数が発散するだけでしょう。
元々の情報には、異体字のどちらであったかという情報を識別する手段がなかったため Unify されて特定のコードポイントが指定してあったわけです。これはこれでそのままでいいのかという問題もあります (例えば、現行の JIS で高橋さん、の名簿があったとき、はしご高を新規に文字として取り込んだらその名簿の方も直せ、と主張する人は一杯いますよね)。また、更に文字をどんどん追加していくことを考えるなら、各文字ごとに更新の何らかのタグも必要です (これがないと、特定の時点で特定の異体字との間の区別がなかったからこの字にしていたという情報が失われる)。また、ある文字に対して書き手が認識できる異体字の種類には制限が出てきますから、それを情報として残していく手段もいる。
どちらにせよ、単に文字を登録できればいいと言う話ではないと思いますね。
同意。但し、私は昔から情報交換用のコードと情報蓄積用のコードは別物だと考えていて、後者については上記の情報を文字情報に含めるべきである、と考えています (上記は元々各文字の属性に起因する情報ですし、編集の際に失われないことを考慮するならその方がいい)。また、この種の情報を B/Right のようにまとまったテキスト (段落など) の情報として情報を残そうとするのは筋違いだと思う (なぜならば、これはその文書を編集した際の情報であり、まとまったテキストに付随する属性ではない)。
＃個人的には、今となっては TRON コードは発想の古さが耐え難い。
>「文字コードと登録された文字実体への参照、の二本立て」
否定はしないです。また、その考え方で作られたシステムが現状のものよりましになる可能性があることも同意。でも、これが解決という気がしないんだなぁ。たぶん、文字コードを議論している方が暗黙のうちに仮定している、「一つの文字には、まず文字という概念があり、それにたいして異体字という表現が複数ある」と割り切れないためかもしれません。
コード領域は無限ではありませんが、どんな文字でも受け入れているように見えますが [tron.org]。
ま、とりあえず0～2についてはこのへん [tron.org]とかこのへん [tron.org]などを読んでみて下さい。
3,4については、こういうの [chokanji.com]とかこういうの [chokanji.com]が既に製品化されているので、あと一歩ってとこですかね。でも、OS非依存になってしまったら、肝心のクライアント [chokanji.com]が売れなくなってしまうので、商売としてはつらいものがあるでしょう（ｗ
確かに今の漢字コード論議って字面しか考えていない所があるから, 例えば森鴎外と森鷗外が別人になっちゃうんですよね.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
あらゆる漢字を扱えること (スコア:1, 興味深い)
知り合いの印刷屋から聞いた話ですけど，例えば銀行からの
ダイレクトメールの場合，顧客に失礼がないように顧客の名前を
「忠実に」漢字で印刷しなければならないそうです。ちょっと
前まで戸籍登録の際に使用できる漢字には制限がなかったそうで，
そのために誤字までもが正式な名前に使用される漢字として
登録されてしまったらしく，「渡邊」の邊だけでも12とおりの
漢字が存在するそうです。
その結果，日本人の名前を「忠実に」漢字で印刷するためには
1 文字で 12 Byte を要するにまでなってしまったとか…。
ウソかホントなのかはわからないのでAC
日本には (スコア:1, 参考になる)
「朝日新聞」の一面右上の「朝日新聞」の文字なんかその典型。
自分の独自性、個性をこういうところで主張する。
秋葉原にもあるワシントンホテルチェーンのレストラン「銀座」の文字とか。
あれは、最初のオーナーが書くとき間違えた、とかいう話もあるけど、その「間違い」も個性といえば個性。
どの国にも似たようなものってあると思うがな。
Re:日本には (スコア:1)
昔は紙に印刷された文字を*切り貼り*して字を作ってたそうな。
山
女
この字を作字したときに"山"と"女"の間に紙のつなぎ目の横線が入り、
山
ー
女
という字が作成されたそうです。
滋賀県多賀町河内の「あけんばら」って地名に使われている幽霊漢字の話。
#もじは生物だから
文字も文章も活字も (スコア:0)
日本の文化なんか全く無視されたところから現在の「日本語システム」ができあがってしまった、というのが最大の不幸ではないかと思いますが。もっとも、コンピュータやってる連中だと、ここいらの「文化」がもともと理解できないくらいの教養しかなかった人も多かったから、これはしょうがないものか。
Re:文字も文章も活字も (スコア:1)
そのへんの『ブンカ』が理解できると称するやからは、日本語をシステムにのっける上で何が問題になるのかすら理解できなかったんだから、おあいこでしょ。
Re:１２バイト (スコア:1)
> 1 文字で 12 Byte を要するにまでなってしまったとか…。
> ウソかホントなのかはわからないのでAC
実は、ビットマップだったり…。(^^;
Tak.Miyoshi
Re:１２バイト (スコア:1)
ビットマップフォントという線はないと思います。
Re:１２バイト (スコア:1)
8x8ドットの漢字フォントなんてものあります。
実際見たことはないのでどの程度識別が可能かは知りませんが
存在するからには結構使えるモノだったのかと。
# 1byte=32ビットだったりして…
Re:１２バイト (スコア:1)
ニュートンやらパームのJ-OSやら何やらと、あちこちで流用されてるんで、結構使えますな。
(_ _)ZZZZzzzzz...... I'm sleepy
elisa8x8 (スコア:1)
ここ [forus.or.jp]で公開されていますね. gkrellm等で愛用しています.
Re:あらゆる漢字を扱えること (スコア:1, 興味深い)
つめれば12byteはさすがにいらないとは思いますが、 内部処理上では、基本コード＋異体字用コード＋オプションで、 4×3=12ってのはありそうな話ですね。 Unicode でも、サロゲート、コード本体、異体字タグ前後、 異体字コードとか駆使することになると、可変長で最大 そのくらいいきそうです。
大半の文字はそういった異体字は不要なわけで、変に全部を とりこもうとするコード体系を使うよりも、XMLでもなんでも 良いですが「タグづけ」を行ってアプリケーションレベルで 処理してしまうほうのが得策でしょう。 OSレベル(すなわち一般のインターフェースも含む)でそこまで しようとすると、現在のマシンパワーでも辛いと思います。 ただでさえ「英語版」に比べてやたらパフォーマンスの悪い 「日本語版」 Windows がもっと重くなるのは勘弁。
現状で「あらゆる漢字を扱えること」という要求に対して、 印刷まで含めた解を求めるなら、素直に、計算機屋さん発想 (合理的なコード体系を!)ではなく、印刷屋さん発想(俺は あらゆるグリフを作る!)な PDF 技術の延長で処理するのが 無難でしょう。フォント(グリフセット)を定義して、準備 してしまえば、事実上無限に文字を増やすことができますし、 フォントの埋め込みもその仕様に入っていますから、編集を 考えない限りは(全部うめこめば可能)、相当の環境において 普遍的に扱うことができるわけで。
TRONはあらゆる文字って点では印刷屋さん的なんだけど、 それを一つにおしこめようとしてる時点で、古い計算機屋 さんなので却下です。
文字の統廃合をするにせよ、全部もりこむ方針でいくにせよ、 とりあえず収集して、「住民基本台帳用追加コード」として まとめてしまって、それのフォント作成＆オープン化を行って しまえば、現行のシステムで普通に扱えるようになるわけで、 まずはそのあたりからやってほしいところです＞総務省。 TRON でも Unicode でも、収納されるの待ってたら日が くれちゃうよ。Adobe あたりとつるんでざくざく作って しまうヨロシ。
Re:あらゆる漢字を扱えること (スコア:1)
文書(データ)としては「考えない限り」とおっしゃっている「編集」は必須だと思っちゃうし、検索のためのインデックス処理をどうやるのかもわからんし(古い計算機屋的考えなんだろうなぁ)
このあたりは「扱う」の範囲がわかってないのでなんともいいがたいのかもしれませんが。
編集用データ構造(これはTRONやUNICODEの規格内)と表示用データ構造(これはおっしゃるとおりゴリゴリ拡張とか)と分けてみるとかかなぁ。
本当かい♪本当かい♪
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で動くとしても。
＃でも、私の言うサーバはあくまでも文字情報のサーバであって、
＃いわゆるデータベースでは無かったのだけれど。
Re:あらゆる漢字を扱えること (スコア:1)
確かに今の漢字コード論議って字面しか考えていない所があるから, 例えば森鴎外と森鷗外が別人になっちゃうんですよね.
Re:あらゆる漢字を扱えること (スコア:1)
SJISに存在しない文字(JEF文字)は4バイト文字で表現してますよ。
渡辺、斉藤、吉田、何でもこいってｋａｎｊｉ
#はしご高とかのIBM選定文字は、SJISに存在しないとみなされて
#4バイト文字の領域を勝手に使われるので、激しくイヤです。
それ以前に読めなきゃ、、、 (スコア:0)
特に関東地方在住の方、その辺の違いが知りたいです。
俺が東京のデパートに逝った時、行き成り｢佐賀県からお越しの中島(ナカジマ)様、、、｣という可愛らしい女性のアナウンスがかかってきて一瞬誰かと疑ったよ。
まあ、佐賀県だから俺しか居なかった訳だけど、、、(w
あっ、因みに俺は佐賀県出身です。
俺
Re:それ以前に読めなきゃ、、、 (スコア:0)
濁ることが不自然ではないから。
Re:それ以前に読めなきゃ、、、 (スコア:0)
ただ、ヨーロッパの場合、ラテンアルファベットが元来は表音文字であることと、国というか地域ごとに正書法が成立する年代がずれているために、発音が乖離すると
Re:それ以前に読めなきゃ、、、 (スコア:0)
紛らわしい・・・。
Re:それ以前に読めなきゃ、、、 (スコア:0)
> 「香港」は現地音（広東語）で何と発音されていようと標準語で
> は【シアンカーン】と読まれてしまいます。
中国に標準語なんぞないような。。。
みんな好き勝手に言っとる感じ。
それでもそれなりに通じてるところはすごいけど。
Re:それ以前に読めなきゃ、、、 (スコア:0)
Re:それ以前に読めなきゃ、、、 (スコア:0)
北京語。
Re:それ以前に読めなきゃ、、、 (スコア:0)
追加 (スコア:0)
ミッチェルとかミッシェルとか……
Re:追加 (スコア:1)
# ミケはきっと違う。
Re:それ以前にわからなきゃ、、、 (スコア:0)
何であなたは自分の方が自然だと思うのでしょうか。
清濁くらいで気にするな (スコア:0)
私は気にしないで両方使ってます。
漢字も異字体があって、それも両方使ってます。
私は公式に名乗るときには田舎の発音で、戸籍に載っている方のややこしい漢字を使います。
その地方ではそこでの発音が正式なのですから、
自分の地方と違うからといって文句を言ってもしょうがないと思います。
あとで、「実はこう読むんですよ」と言うくらいで良いのでは
Re:清濁くらいで気にするな (スコア:0)
Re:それ以前に読めなきゃ、、、 (スコア:0)
# 逮捕されたくないので AC
Re:あらゆる漢字を扱えること (スコア:1)
本筋とは関係ないつっこみです。
戸籍登録の際に登録されるのは氏名ですが、このうち、氏に関しての
文字制限は、いまだに戸籍法に記載がありません [houko.com]。
名前のほうの文字制限は、子の名に関してのみ、「常用平易な字」と、
第50条で制限されております。
この「常用平易な字」の規定は、戸籍法施行規則 [so-net.ne.jp]第６０条にて
定められています。
では、過去に制限が無かったかというとそうではなく、この省令が
昭和22年12月29日に施行されているところから分かるとおり、戦後すぐに
制限が加えられています。
# といっても、常用平易な字の範囲が、昭和54年のものになるように
# 書き換えられているから、元がどうだったか示せませんが…当用漢字と
# 記されてたはずですが、適切なリソースが見つかりませなんだ。失礼。
で、主張したいのは、子供の名づけ以外のシーンでは、制限が
無いって話です。
それ以外は、戸籍を受理する側が、常識の範囲内かどうかなどを
はかっているのではないかと考えるのですが、こちらは憶測の粋を
出ないです。
Re:あらゆる漢字を扱えること (スコア:1)
Re:あらゆる漢字を扱えること (スコア:0)
Re:あらゆる漢字を扱えること (スコア:0)
原因はオブジェクト指向への浸りすぎ (違