アカウント名:
パスワード:
＃U-FA00 と U-3400 と U-20000 の収録基準と使い方は現仕様むちゃくちゃなので、そこのせいで Unicode を批判するのは正しいと思う。
現状では、今昔文字鏡（だったっけ）文字集合を導入してもだいぶ、どころか違いに気がつく人はごく僅かでしょう (西夏文字などを日常的に必要としている研究者じゃない限り)。
もしかしたら将来、日本では TRON コードが使えないことが原因で Linux がすたれて BSD がとってかわるかもしれません (漢字圏では、とは言いません。どうやら、異体字の区別にうるさいのは日本だけっぽいので) し、そうならないかもしれません。
ちなみに、Unicode における異体字の区別は、Variation Selector [unicode.org] というのを使ってできるようになる予定みたいです。
せっかく英語ウェブページがあるんだから、そこには日本語メーリングリストの紹介だけでなく英語メーリングリストの紹介も載せたらいいのに。
というか、日本語化プロジェクトなら日本語でやればいいでしょうが、国際化プロジェクトを日本語でやるのは、なんか間違っている気がします。いや、「国際化とは英語と日本語と、あとせいぜい漢字圏の言語が使えるようになることである」というのなら、それでいいんだけど、citrus プロジェクトはそんなけちくさいプロジェクトじゃないと信じたい。
BSD には citrus プロジェクト [bsdclub.org]というのがあるみたいですが、どんな成果があるのか、とか、なにができるのか、とかが外部からだとよくわからないので、
ちなみに、「はしご高」と「くち高」だって、Unicode で区別されていないのは、JIS で区別されていないのが原因 (のひとつ) です。少なくとも、もし JIS で「はしご高」と「くち高」が区別されていれば、Unicode でも区別されていたはずです。(ちなみに、JIS X 0213 で分離された文字 (異体字) の Unicode での扱いは、ちょっとややこしいことになっているようです。)
異体字を「別の文字」として区別して扱うことが多い人は、Unicode より TRON コードのほうが便利でしょう。「文字コードはなにに対してコードを割り当てるべきなのか」という思想が Unicode と TRON コードでは違うので、役割が違うということです。
でも、variation selector を用いた異体字の区別については、需要があれば、仕様が決まり次第、将来だれかが実装するだろうと思います。(フォント開発がいちばん大変なんじゃないでしょうか)
ちなみに、「はしご高」と「くち高」だって、Unicode で区別されていないのは、
Unicodeを使われると、生徒の名前や住所すら満足に表示できませんからね。
Windows も Macintosh も、すでに内部は Unicode で動いてますよ。
ちなみに、Unicode の漢字統合ですが、JIS も同様な統合 (包摂) の規準を持っています。「Unicode では漢字が化ける」のは、実際のフォントを作る際に、その統合された字形の範囲の中から具体的にどの字形を採用するか、というのが国ごとに違ってくるから。ですので、Unicode を使っていても、日本語のフォントを使っている限りは、従来の Shift_JIS や EUC-JP と同じことができます。つまり、Unicode でできないことは Shift_JIS や EUC-JP でもできません。
もちろん、人名や地名を正確に表現したいときに、Shift_JIS や EUC-JP では到底だめで、Unicode でもまだだめで、TRON コードだと OK、ということは、ありえる話です。
はしご高がUnicodeでは表示できないなどと言ってました。
U+9AD8が高 U+9AD9がはしご高 とコードポイントがわりあてられています。 Unicode V2.0 7-409ページを見てください。
当然のことながらJIS X0208では「高」と「はしご高」は 包摂されているという立場ですから、JIS X0208にマップ したら区別できなくなります。ですから、坂村氏の主張は Unicod
＃slashcode の動きが変だぞ。aelig が入らん。
Unicode の場合、元のコード表で別字になっていたら別字、以外のことは考えてないと見ます。土吉が包摂されていて、はしご高が包摂されていないのは、後者が (IBM/NEC 外字に収録されていたため) CP932 で区別されているから。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
国産技術ならなんでもOKではないけど (スコア:2, 興味深い)
いいじゃねえか、どっかの国がいつぞみたく文句言ってきたら
「われわれはもっとも優れたものを導入しただけだ」
って言い返せば。
実際、日本語を扱うのにこれほど優れたOSはなかろうて。
Windowsじゃ（はしご高）を入力するのも一苦労だし。
Linuxはほとんど使ってないのでなんともいえませんが、日本語環境に関してあまりいい印象は受けてません。
Re:国産技術ならなんでもOKではないけど (スコア:2, すばらしい洞察)
とりあえずlocaleにTRONコードを……それだけでだいぶ違ってくるはず。
Re:国産技術ならなんでもOKではないけど (スコア:1)
＃U-FA00 と U-3400 と U-20000 の収録基準と使い方は現仕様むちゃくちゃなので、そこのせいで Unicode を批判するのは正しいと思う。
現状では、今昔文字鏡（だったっけ）文字集合を導入してもだいぶ、どころか違いに気がつく人はごく僅かでしょう (西夏文字などを日常的に必要としている研究者じゃない限り)。
Re:国産技術ならなんでもOKではないけど (スコア:1)
区別して使われることがあるものはできるだけ区別する（包摂しない）、
という思想が支持されているのでは。
研究用途にせよ、名簿作成にせよ、
区別を必要とする人がいる限り、
道具として広く使われるためには必要、
という考え方をしないといけないのかも知れません。
TRONロケール (スコア:1)
もしかしたら将来、日本では TRON コードが使えないことが原因で Linux がすたれて BSD がとってかわるかもしれません (漢字圏では、とは言いません。どうやら、異体字の区別にうるさいのは日本だけっぽいので) し、そうならないかもしれません。
ちなみに、Unicode における異体字の区別は、Variation Selector [unicode.org] というのを使ってできるようになる予定みたいです。
Re:TRONロケール (スコア:0)
Re:TRONロケール (スコア:1)
せっかく英語ウェブページがあるんだから、そこには日本語メーリングリストの紹介だけでなく英語メーリングリストの紹介も載せたらいいのに。
というか、日本語化プロジェクトなら日本語でやればいいでしょうが、国際化プロジェクトを日本語でやるのは、なんか間違っている気がします。いや、「国際化とは英語と日本語と、あとせいぜい漢字圏の言語が使えるようになることである」というのなら、それでいいんだけど、citrus プロジェクトはそんなけちくさいプロジェクトじゃないと信じたい。
Re:TRONロケール (スコア:1)
ちなみに、
既に NetBSD に成果が取り込まれて [netbsd.org]います。FreeBSD にもそういった動きがあると聞きました。
-- dimbula
Unicode宗教論争したくないけれど、、 (スコア:0)
現行漢字の異体字程度ぐらいならいつものようにadhocなタグ(XML派)かprefixコード(Unicode14面派)の付加でどうにかなると思いますが、そのとき文字の比較とかはライ
Re:Unicode宗教論争したくないけれど、、 (スコア:1)
ちなみに、「はしご高」と「くち高」だって、Unicode で区別されていないのは、JIS で区別されていないのが原因 (のひとつ) です。少なくとも、もし JIS で「はしご高」と「くち高」が区別されていれば、Unicode でも区別されていたはずです。(ちなみに、JIS X 0213 で分離された文字 (異体字) の Unicode での扱いは、ちょっとややこしいことになっているようです。)
異体字を「別の文字」として区別して扱うことが多い人は、Unicode より TRON コードのほうが便利でしょう。「文字コードはなにに対してコードを割り当てるべきなのか」という思想が Unicode と TRON コードでは違うので、役割が違うということです。
でも、variation selector を用いた異体字の区別については、需要があれば、仕様が決まり次第、将来だれかが実装するだろうと思います。(フォント開発がいちばん大変なんじゃないでしょうか)
Re:Unicode宗教論争したくないけれど、、 (スコア:0)
U+9AD8 vs U+9AD9
Re:国産技術ならなんでもOKではないけど (スコア:1)
個人的にはPOSIX的なインターフェースもないと困りそうだけど...
Re:国産技術ならなんでもOKではないけど (スコア:0)
なんとかうちの学校のシステムをWindowsから移行したいと思って
いるのですが、OpenOfficeなどを見ても、日本語を扱うと満足に
表示できず（ポイントの指定が反映されない、全角文字が重なるなど）
まだ完全に移行するにはデスクトップの環境が良くないですね。
インストール時に認識できたディスプレイが次のバージョンで認識
できなくなっていたりということもあって、初心者にはまだ難しい
レベルですし。この点ではWindowsのほうが遥かにフレンドリー。
超漢字にも手を出そうかと考えていますが（やっぱり扱える漢字の
確実さが重要ですから
Re:国産技術ならなんでもOKではないけど (スコア:2, 参考になる)
Windows も Macintosh も、すでに内部は Unicode で動いてますよ。
ちなみに、Unicode の漢字統合ですが、JIS も同様な統合 (包摂) の規準を持っています。「Unicode では漢字が化ける」のは、実際のフォントを作る際に、その統合された字形の範囲の中から具体的にどの字形を採用するか、というのが国ごとに違ってくるから。ですので、Unicode を使っていても、日本語のフォントを使っている限りは、従来の Shift_JIS や EUC-JP と同じことができます。つまり、Unicode でできないことは Shift_JIS や EUC-JP でもできません。
もちろん、人名や地名を正確に表現したいときに、Shift_JIS や EUC-JP では到底だめで、Unicode でもまだだめで、TRON コードだと OK、ということは、ありえる話です。
Re:国産技術ならなんでもOKではないけど (スコア:0)
はしご高がUnicodeでは表示できないなどと言ってました。
Re:国産技術ならなんでもOKではないけど (スコア:0)
単純に日本語としてJISコードに変換したときに「表示できない」
事態は十分考えられます。氏の発言はあながち間違いじゃないかも。
ExtensionA/B (スコア:0)
たしかUnicode3.0が確定する前の話だったと思いますが。
ところで、日本で「文字コードの専門家」ってだ
Re:ExtensionA/B (スコア:0)
U+9AD8が高
U+9AD9がはしご高
とコードポイントがわりあてられています。 Unicode V2.0 7-409ページを見てください。
当然のことながらJIS X0208では「高」と「はしご高」は 包摂されているという立場ですから、JIS X0208にマップ したら区別できなくなります。ですから、坂村氏の主張は Unicod
たしかに (スコア:0)
ここらへんの包摂基準はどこで線引きしているんでしょう？
個人的には、こういうのは全部異体字識別bitを割り振ってもらった方が、異体字テーブルがいらなくて良いように思いますが。（竜と龍とか言う人もいるでしょうが）
とりあえず、第３、第４水準という
Re:たしかに (スコア:1)
＃slashcode の動きが変だぞ。aelig が入らん。
合字 (スコア:1)
Re:合字 (オフトピック) (スコア:1)
Re:たしかに (スコア:1)
Unicode の場合、元のコード表で別字になっていたら別字、以外のことは考えてないと見ます。土吉が包摂されていて、はしご高が包摂されていないのは、後者が (IBM/NEC 外字に収録されていたため) CP932 で区別されているから。
Re:国産技術ならなんでもOKではないけど (スコア:1)
実際、標準の機能で普通の事は出来ちゃうんですけど、普及するための目に見える効果（キラーアプリ）が無いんですよね。
既に使っている人は、標準機能だけで十分だから、新しいソフトってあんまり必要としていない気がします、少なくとも私はそう。
あとは超漢字ウェブコンバーター [chokanji.com]とかの周辺の充実で、他のOSユーザにも、こんな事が出来るOSだよと、露出が増えて行く事を期待しています。
#個人的にも、超漢字で蓄積しているデータの公開に使えるので、超漢字ウェブコンバーターの導入は検討中。