おい、お前らUNICODEを絶滅させて下ちい。

UNICODEそれは世界共通文字コード。これ使えば世界中の人たちがみんな幸せじゃん。と思っていたら

従来の文字コードとUNICODE対応の問題
http://euc.jp/i18n/ucsnote.ja.html
Unicodeの知らざる世界
http://www-6.ibm.com/jp/developerworks/unicode/010810/j_u-secret.html
とかみてみた。

ダメじゃん、全くダメじゃん。
なのに何でUNICODE化が進んでるの、早く絶滅させて!! おながいします!!

放置

他にかわるもんがねーからなぁ
諸問題と戦い続けるしかねーんじゃねーのか？

TRON コードだっけ？
あれで幸せになろうよ。

もしくは次の企画たちあげるか、
次は２バイトなんかじゃ足りねえのはわかってるんだから４バイトで
大決定だろ。

仮称として Global Code とか World Wide Code なんて名前でどうよ？

ipv6にならって、けちけちせずに128ﾋﾞﾄしようYO!

Uni ⇒ Multi

超漢字はUNICODE以上にだめ。

>>1
今ごろ気づいたのかよ

ttp://www.horagai.com/www/moji/2000a.htm#M2
ttp://www.opengroup.or.jp/jvc/cde/ucs-conv.html#ch2_1

いい事考えたYO！
文字を16*16サイズで書いてさ、それのビットパターンをそのまま文字コードにするんだYO
256bitも必要だけど、これで新しい文字やフォント、グリフの問題もオケだね！

ISOで４バイトで話が進んでたところにイキナリ割り込んできた
MSその他アメ公が悪い。

>>10
せめて、32*32くらい欲しい。

>>1
UNICODE・・・だめだめジャン！
今頃知ったＹＯ、最悪。

4バイトにしたらすべての文字を表せるってのも日本人の勝手な妄想らしいぞ
なんだったか忘れたが、文字の組み合わせでひとつの文字を作る奴

リガチャ？

Unicode と UTF-7 と UTF-8 と UTF-16 の関係がわからん。

結局、アメ公の大半は
「うちら不自由してないから関係ないわー」
っていう事なんでしょ？
やるんなら最初から最後まで４バイトで通せよって感じ？
文字によって１バイトだったり２バイトだったり３バイトだったり
すると不自由なんじゃワレ！

ここで早々と結論。
Unicode と関係ない４バイト体系の文字集合を我々の手で策定すべし！

問題はUNICODE対応すれば国際化対応済みとカンチガイしている
西洋人が多いこと。
X-Free86も、、、

>>16
UTF-32に圧縮を書けたものだと思えばいい。
（雨工にとって）頻繁に出現する文字は8ビットや16ビットで表現、
そうでない文字は48ビットや32ビット使う。
なぜUTF-32には期待できないのだろうか・・・

最後の行意味不明
remove なぜ

UNICODE(UTF8)に期待してよろしいか？
http://pc.2ch.net/test/read.cgi/tech/1008913670/34
に
> UTF-32 は３２ビット固定長だが UTF-16 で扱える範囲のみに限定したものだ。

とか書いてあるんだが……UTF-32ってUCS-4のCES部分だけ切り出したヤツじゃないの？
2^31種の文字が全て使えるんだとばかり思ってたんだけど。

>>18
うにコードコンソーシアムがサロゲートとかほざいている限り
UTF-32なんて絵に描いた餅だと思う。

http://pc.2ch.net/test/read.cgi/linux/1003159137/
関連スレ
なんか向こうの方が詳しい人おおそう

>>20
漏れも、なぜ1<<32扱えるようにしなかったのかは疑問。

＞UCS-4のCES部分だけ切り出したヤツじゃないの？
それはISO仕様
UNICODEコンソーシアムはソンナコト考えてない。
サロゲートペアに小うるさい東洋人どもの追加文字をつっこんで澄まそうとしてるだけ。

おい、>>1、
アメ公にオブジェクト指向もUNICODEも家電インターネット製品も
無用の長物ってこと気づかせてやれよ。

>>24
馬鹿野郎。オブジェクト指向は必要じゃボケ。
文句があるなら戦場へ来い。

つーか、Unicode使ってれば国際化できると勘違いしてるのは
Linuxとかでプログラミングしてる片手間プログラマだけだろ？
glibもXFree86もハードコーディングされてるし。

Code Set Independence(CSI)手法を用いて文字を抽象化オブジェクトとしてみなし、
各言語を外部モジュールとしてロードさせてやれば国際化の手間なんて
Unicodeでハードコーディングに比べりゃ遙かに楽になるじゃん。
とりあえずUnicodeは中途半端すぎる。

＞つーか、Unicode使ってれば国際化できると勘違いしてるのは
＞Linuxとかでプログラミングしてる片手間プログラマだけだろ？

WindowsのあのUnicode対応はどうなる。

>>27
Windowsは・・・まもなく滅びるからいい。

>>28
その前にお前が滅びる。

>>1
UNICODE特有の問題と、文字コード一般に言えることがごちゃ混ぜになってる
気がしますが。

とりあえず俺の案
1 文字長は全て1文字全て4バイトに固定。 ASCIIも漢字も全部4バイト。
2 最初の1バイトは言語別コード(英語=0、日本語=1、中国語=2とか)埋め込み。必ず。
3 残りの3バイトを各言語ごとに自由に使う。

この案最高にイイと思うんだけどどうかな??
メリケンどもは上位3バイト全部0にするだけで今のASCII使えばいいし。
我らが日本語は最後の下位2バイトを日本文字で埋めればいい。
何か問題あるかな。

先に自分でつっこんどくけどそれだと無駄が多いってのは無しで。
冗長性は大事だと想うんで。

言語は256以上あるし、異なる言語でも同じ文字はあるし、３バイトに収まらない文字もあるかもしれないし、どの言語にも分類できない文字や記号もあるんだよねぇ。

>>32
言語数は256で足りるのかい？
あと言語の区切りをどうするかが難しいね。

>>33
言語は3000-4000くらいあるよ。
ただし文字をもった言語は 1000 なかったはず。

もはや、一つのコード体系で全ての文字言語を表現しようとするのが間違いだと思うようになってきた。

各言語ごとに文字コードを管理する団体を作って、
最上位ビットが1のとき、残りの31ビットはそれ以降の文字のコードを管理する団体のIDとバージョン
最上位ビットが0のとき、残りの31ビットは文字コード。
プログラムは解釈できない文字コードに出会ったときWWWから対応するモジュールを入手できる、とか、だめっすか？

>>37
間違ってバイナリ食わせたら世界中からダウンロードが始まるわけね…

256で言語数は足りるかってことだけど現行で使われてる各国の主要言語だけでいいんじゃない。
んで言語の区切りはむずいけどASCIIにないヤツだけ。
あと西洋のaに点々とかは数少ないからそれようので1言語割り当て。3バイトあるしたりるっしょ。
それで大体西側諸国のはカバーできるっしょ

>>38
ｵﾓﾛ-ｲ

>>33, 34
言語数の数だけ文字集合があるわけでは無いと思われ。
っていうか「バイト」単位で区切るからいけないんであって、ビット単位で
区切れば 2048 くらいの文字集合をサポートすれば十分なら12ビットくらい
言語コードにとって、残りを中身にすればいいじゃん

で、言いたいのは有限のバイトで表すんだから、
あまりつかわんもんは全部斬り捨て。 もうすっぱり。斬り捨て。
種類が無限に増えるのを有限の固定バイトってのは無理。
だからすっぱり斬り捨て。 <-これ大事

なんかの漢字辞典入れたいとかはもうすっきり斬り捨て。
そいうひとはそれようのコードにしてもらう。
だってそんなん使いたい人は0.0001%位でしょ。
そんなん別の独自コード自分たちで考えるべき。
そういうひとが全部入れろとか言うから話がややこしくなるんで。

その0.0001%に自分が含まれたときのことも考えたほうがいいんでは？
自分の名前が文字コードに入って無いとか（現在でもあるけど）鬱じゃない？

切り捨てなくても32ビットありゃ全部入るよ。
問題はもっと深いところにある．

>>10,12
WINでエロゲム作ってる立場から言うとアンチェリかけてもジャギ目立つので嫌

>>37 それもちょっといいかもね
でもそれじゃ文字列の途中の4バイト見たときどこの言語だかわかんないよ。

お前ら途中の1Byte見たときそこが何バイト目か分かるようにしてください．

んと。今でも3バイト有れば日本語はほぼ100%大丈夫でしょ。
で、人名とかのなんか変な漢字。あれだけどあれ斬り捨てていいよ。
旧字体とかもうイラン。斬り捨てたほうがいい。
横暴? でもそんな字とか人名に許可してたりするから処理が無駄に面倒になるんじゃん
法律で常用漢字以外ダメ、うそ字や旧字体も不可ってことにしちゃえと思う。

俺、完全にUNICODEﾏﾝｾｰなゲイツ信者です。
WinなプログラムはUNICODEしか使いたくない。

1Byte見たらわかるようにか、なら各バイトの最初の2bitを番号にしよ。
00 1byte目
01 2byte目

>>47
ちょっとは面白いかと思ったらなんだそれ？
常用漢字だけだったら11ビットですむよ。お前もUnicodeと一緒に氏ね

ぶっちゃけさ、漢字なんていつまでも後生大事に使ってるから悪いんじゃん？
本当に漢字が必要なのって中国人だけだろ？
日本にはひらがなカタカナっていう素晴らしい文化があるし、
韓国も日常的にはハングル文字だけなんだろ？
(いや、実情しらないんだけど、韓国の映像みてもハングル文字だけで漢字なんて使ってないよね)

中国だって「難しすぎて有害だなコリャ」っていう結論になって
簡体字使ってるんでしょ？漢字なんてやめちゃおうよ。
これからは仮名だけを使って、いかにうまく日本語を表記していくかを
議論するほうが実があると思う。

そのゲイツ様のUNICODEよりもっといいのを考えちゃおうって寸法だ。
現行のダメダメUNICODEよりもっといいコードなら
UNICODEへ二の足を踏んでいる人も移行しやすいんじゃないかな

とりあえず>>10＆>>12の意見がもっとも現実的ってことでよいか？（鬱

TrueType…

>>50
どうかーん
3Byteも用意してるのに切り捨てる理由がわからん

>>50 ????

>>51
カナモジカイ信者ですか？

そうだった、じゃ入れちゃおう。

つーかお前らが何言ってもどこも聞き入れてくんないからもうやめとけよ

仮名だけってのはやだな。
見にくいし文章のリズムが無くなって頭痛くなる。

で、muleでやってるUTF-2000とかいうのはどうなの？

半角カナ。最強、これ。

2chねらーのぷろぐらまさんで何とかしてください おながいします
でもこの意見すごくいいとおもうんだけどなぁ

西洋人はほとんど変更不要だし、
東洋人も今の怪しげなunicode変換テーブルとやらが必要なくて
すぐに変換できるでしょ。
だって今その国で使ってるエンコードを元に作るんだから。

コンピュータの　しんぽ　が　もうすこし　おそければ、
ファミコンの　やりかた　が　もっと　ふきゅうして、
かんじ　なんて　きえさったのに。


駄目だ…音読みの単語があるかぎりはこの目標はなかなか難しいな。
>>57
なにそれ？教えて。

>>60
見にくいのは慣れてないから。
文章のリズムが無くなるっていうのは理解不能。

同音異義語が多いっていう理由で読みにくいのはすべて音読みのせい。
訓読みの単語(大和言葉由来の単語)には同音異義語なんて極めて少数。

マジレス
自分で作る気がないなら少し勉強したほうがいい。
自分で貼ったリンクなり>>9のリンクなり、
Googleで検索するなり
ほら貝でもいいだろ。知識はつけられる．
どれだけ根の深い問題か多少はわかるだろう。
全部壊して32ビットにすれば「多少は」マシなんだろうがね。それが出来ないところが大きい。

俺もPlainTextで日本語と中国語と同時に表示できないUnicodeなんか嫌だ。

>>64 つーわけで漢語のためにカンジは必須という結論でよろしいか？（Ｗ
カナモジカイくらい検索しれよ
ttp://www.netlaputa.ne.jp/~wakabaya/kanamozikai.html
んで、正直な感想がききたい。

日常使われる漢字なんて、どんどん減ってるんだから、ほっときゃいいよ。

>>66
ちゃんとした団体だったのね、正直、検索して引っかかるような物では
ないと思ってた。
根本にある思想は、まさしく俺の考えてたのと同じだわ。
俺の知らない収穫物が山ほどありそう。
でも、はっきり言って、すでに古臭い雰囲気がぷんぷんするね。
俺だったら「権威」による押し付けじゃなくて、草の根活動で
ジワジワと浸透させるんだが……「会費:\5,000.」とか言ってる時点で
妖しいしな。
たしかにカタカナのが最終的にはいいんだけど、現代語をかんがえると
平仮名からはじめるのがいいと思うし。
(今カタカナって外来語を表記するためのものなんだよね。)

で、もし、まず「漢語」ありき。というのであれば、残念ながら
漢字は必須だね。日本語には中国語のアクセントはないのだし
(もし中国語風のアクセントがあるなら、それも表記法に取り入れれば
簡略化は可能だったと思うんだけど…)

でも、本当に「漢語」は必要なのか？という点から見つめなおしたいと思う。
いや、それを言い始めると「日本語」必要なの？英語でいーじゃん論に
達する気もするんだけどね。

あと、アルファベットの生い立ちを考えると、漢字を捨てるのは当然だと
思うのは俺だけなのかな？

>>68 おいらは漢字は書くのが難しく読む人に優しい文字だと思う。（易しいとまでは言わない）

‘pithecanthrope’ と書いてもネイティブでも専門家しか意味を知らないけど
「猿人」とかけば小学生でもなんとなくイメージできるとか。
「髭」って字を知らなくてもなんとなく髪の毛の仲間っぽいとか。

結局どっかの受け売りなんだけどね。
呉知英(Wの本とか

＞でも、本当に「漢語」は必要なのか？
http://plaza22.mbn.or.jp/~gthmhk/kanzi.html
にあったけど
漢語を一生懸命やまとことばに翻訳しても
音節のかぎられた日本語という制約のあるかぎり
同音異義語の弊害からは抜け出せないと思われ。

それを避けるには中国語みたいに発音をたくさん区別するか
ドイツ語みたいに単語を長くするしかない。
文字が単純でも量が多ければ煩雑なのは変わらないと思う。

＞あと、アルファベットの生い立ちを考えると、漢字を捨てるのは当然だと
＞思うのは俺だけなのかな？

その意味ではかな漢字変換のおかげで漢字の寿命は延びたと思う。

> おいらは漢字は書くのが難しく読む人に優しい文字だと思う。（易しいとまでは言わない）

同意、入力速度は遅いが、読む速度は英語とは比べ物にならないくらい速いと思う。
一文字内の情報量が桁違いだし複数くっつけて新しい単語が簡単に作れるしね。

UTF-2000か ちょっと調べてくる

>>69
確かに読みやすい。表意文字だから「文字自体が語りかけてくる」という感覚があるのは認める。
でも、それにしたって「覚える労力」が大きすぎると思う。
公立の学校が週休二日になって授業時間が減っている今、漢字っていうものは
かなり負担になっているはず。

で、ドイツ語みたいにならない為には、「単語の構成要素」みたいなものを
沢山発見してこなきゃ駄目だよね。
英語って「これでもか！」っていうくらい prefix とか suffix があると思うんだけど、(詳しく知らないので半分想像だけど)英語が現在の形になるまでに
各種言語(ラテン語系とか、他のゲルマン語族系の言葉)から、吸収していった
言葉なんじゃないかなと思う。

そう考えると漢語を日本語から「完全に追い出す」のは無謀だとも言える。
でも、今の「日本語」の中の「漢語ルーツ」もしくは「漢字の組み合わせ」の
単語っていうのは、明らかに多すぎる。
ちょっとヤバイ話に片足突っ込むけど、征服者による Native Japanese の迫害の結果なんじゃないかとすら思う。

「日本の文化を壊すつもりか！」とか、お髭真っ白な爺様にでも言われそうだけど、どうしても中国からの借り物というイメージが強くて
どうやって日本らしさを誇っていいのかわからない。

まぁ、既に定着しちゃった造語は、ゆっくりと時間をかけて消していくにしても、これからは正直言って海外の言葉を漢字ベースで翻訳しないで欲しいと思う。
たとえば「固定ディスク装置」なんて言葉、邪魔でしょう？
結局、ハードディスクドライヴっていう言葉と二重に覚えて、頭の中に対応関係をつけておかなきゃいけなくなる。

「カタカナ言葉反対！」なんて言わせないよ。
だって、漢字だって、優れた文化を手に入れるために輸入したんでしょ？
新しい概念だって、最も効率のいい方法で吸収するべき。
そして、もうこれ以上、漢字による負担を増やさないようにするべき。

って何だか言いたい事だけ書いてしまいました。
このスレの本来の趣旨と混ぜ合わせて結論を言うと。
「英語と同じくらい単純な表記が日本語の標準になれば、UNICODE なんかでヒーヒー言う必要なくなるじゃない？」
っていう事です。

かと言って、日本語をひらがな(orローマ字)だけで書くと読みにくくて
しかたないというワナ。

>>73
「慣れてないから」っていう理由が 95%(当社比) を占めてる。
英語とかで想像してみるといい。
中学校で英語習ってた頃は、例え読み方暗記している単語ばかりでも
すごく読みづらかったはず。
でもある程度慣れてくると、知っている単語だと スルッ と頭の中に
溶け込んでくるでしょ？結局はほとんどが「慣れ」の問題なんだよね。

>73　じゃぁ半角ｶﾅオンリーという事でよろしくおながいします

>74
つまり、日本の古典教育＆漢文教育を決定的に
破棄せよ、というわけですな。

>>74
慣れだけじゃない、ひらがなってのはこういう文なんだよ↓
thisisapen.aiamaboy.what'syourname?

大文字と小文字の区別なし、単語間の区切りなし、Iとaiの区別もなし。
読めるわけねぇっての。

必要なもの、便利なものはどんどん取り込むのが日本の文化。
漢字だって中国からの借り物でも何でもない。
取り込んで、日本流にアレンジもするし、更に派生してひらがなやカタカナも作ったんだから．

日本語の文章の中にアルファベット（←英単語のことね）が出てきても
もう何の違和感もないでしょ．

>>78
基本的に切り捨てないからなあ。
なんでも取り入れちゃう。良くも悪くも・・・。

で、今このざま。良くも悪くも・・・。

マジで、
UNICODEの定義領域が少なすぎるだけだろ？
8byteにすりゃ解決じゃん。
記憶領域が一気に８〜４倍必要になるけど。（ｗ
でも、これから一生、文字コードで問題になる事はない。

だから切り捨てる必要なんてないでしょ。
文字のコード化だって、最初から無理に切り捨てようとするから問題が出てくる。
一般人がもう使われなくなったような文字を使う必要はないが、
その文字が必要な人からしたらコンピュータ上にその文字は「存在しない」ことに
なるんだから大問題。

というわけで、俺はUnificationは間違いで検索技術を発展させるべき。な考え

エスペラントが成功していれば事態はもっと変わっていたかも・・・しれなく無いな。

8バイトコードきぼーん。

いや32バイトくらい必要か・・・・

UNICODEが動機で漢字いらねー論になるのは、やっぱ、なんか違う…

>>77
ちょっと >>64 を見てくれ。
なにもかもいまのままでひらがなだけつかえなんてだれもいってないんだよ。
そんなのふべんだなんてわかってるよ。
あたえられたものをそのままたべるんじゃなくてもっとくふうしようよにほんじんだろ？

>>78
> 漢字だって中国からの借り物でも何でもない。
これは中国人聞いたら怒るよ。きっと。
ちなみに大陸で使ってる簡体字を制定した時は平仮名、カタカナ、ハングル文字などが参考として研究されたそうです。
中国の方も自覚されてるんですね。「漢字、覚えきれないよ！」

公用語を英語にすれば問題なし。

小泉政権の支持率が下がってるので、そんな大改革は反対勢力（カタカナカイ）の抵抗にあって無理。

何にしても人に制限を強いるやり方は嫌いだな。

ア メ 公 を 滅 ぼ せ

>> 漢字だって中国からの借り物でも何でもない。
>これは中国人聞いたら怒るよ。きっと。
中国人がどう言おうと関係ない。
ルーツが中国にあるのと「借り物」なんてのは全然別だろ。
もともと中国のものだから日本の文化じゃないってか？
そんなこと言ったら地球人みんなアフリカ人になっちゃうよ。

>中国の方も自覚されてるんですね。「漢字、覚えきれないよ！」
これも関係ないな。
「コンピュータ上では簡体字以外の漢字は存在しない。ヨイナ？」
と言われて中国人は怒らないのか？
Unicode3.1で追加された大量の中国漢字はなんだ？

>>82
エスペラントはロマンス語の一種であり、簡易ラテン語とでもいうべきものであるから、
エスペラントとて決して公平な言語ではない

ではエスペラントよりもっと公平な新言語を作れるかというと、
それも無理だろう。
しょせん、人工語といえども、既存の言語を参照して作るほか無いからだ

世界の言語を統一することは、
世界の文化を統一することになる
世界の文化の多様性が致命的に損なわれる

ムーアの法則によれば３年で４倍の能力に進歩するコンピュータの都合のために
長い歴史をもつ人類の文化を損なうなど馬鹿げている
人類の文化は何千年にもわたって積み上げ、築き上げてきたものだ
コンピュータで扱う都合など、今できないことでも５年、１０年待てば簡単にできるようになるのだ

91の後者は「関係ない」というより「別問題」だな

後者→後半　日本語勉強しなおそう・・・鬱

やっぱCSIの方が汎用性が高くていいと思うのだが・・・

UNICODE + XMLでいいじゃん。
UNICODE以外を扱う時は、UNICODEでXMLを書く。

utf-2000で検索してみた
http://www.google.co.jp/search?q=utf-2000&hl=ja&lr=lang_ja

うわぁぁぁん わかんねー

すべてのテキストファイルに言語識別のためのヘッダを持たせる。
解決。

>>98
日本語の中にハングルを書いたり出来ないじゃないですか。よって却下。

>>99
WAVEのチャンクみたいな感じで分ける。
やっぱり解決。

>>100
チャンクで分けたら引用とかに使えないじゃん。

低脳

漢字を廃止できなければ、日本語を使う人が学者と言語ヲタ(自然言語ヲタの方ね)
だけになるのは時間の問題だな。

このままだと確実に英語に食われる。もし食われなければ競争力低下で
日本滅亡なのだから、そっちの方が幸せかな。

簡易日本語を使う事になるのと、英語を使う事になるのと
アメリカの資本の奴隷になるのと、どれがいい？

>>98
XML?

>>85 と同様、
unicodeの話から、シロウト日本語論になる理由がわからん。

黒岩重吾の「世界でも美しいといわれる日本語」に同意の、日本語マンセーですがなにか?

utf-2000について誰か簡単に解説してくれー
頼む

かくかくしかじか

UNICODE はメリケンの罠だな。
中途半端な UTF-8 だのを背後に隠し持ってやがるからな。
あんなものあれば、DBCS 国以外の人間は誰だって
「アルファベット一文字に２バイトも４バイトも使えって？非効率だな。
アルファベットは一文字１バイトの体系の方を使おう」
って思うに決まってるじゃん。
で、品質管理されない free をモットーとする方々が、ガッチリ依存した
コードを書いてくださると。
極東のプログラマーが言語問題に奔走している間に益々センスと技術に差がついていくね。
「日本人は国際化対応に頑張っているが、自分達でソフトウェアを提供しない」
って、ますます言われる。
100年後、いや50年後、極東に漢字はあるだろうか？
いや、そこに純粋なアジア人はいるのだろうか？

アジアの文化はジャストシステムが守ります

>>103
＞簡易日本語を使う事になるのと、英語を使う事になるのと
＞アメリカの資本の奴隷になるのと、どれがいい？
すべて50年程前から実現していますね :)

参考文献

かんじふようろん：ぜんぶひらがなでいこう？
http://mentai.2ch.net/test/read.cgi/gengo/1011506718/
【常用漢字表にない漢字の代わりの漢字について】
http://mentai.2ch.net/test/read.cgi/gengo/1004972973/
ほんとうに実在したの？カナモジカイ
http://mentai.2ch.net/test/read.cgi/gengo/1007522874/

[UTF-2000]

中国漢字、日本漢字、異字体、記号、絵文字など、
あらゆる文字に体系的な文字コードを割り当てた、Unicodeのサブ規格。
サロゲートペアなどの複雑な処理を廃し、扱いやすくなっている。
一文字を2000ビットで表現する。

[カナモジカイ]

漢字やめちゃったら韓国みたいになるよ。

http://kanji.zinbun.kyoto-u.ac.jp/~tomo/UTF-2000/
これがUTF2000の公式ページらしいんだが、
もれの腐った脳味噌じゃなにがなんだかさぱーりわからん
読んでわかったのはXEmacs専用??のコードらしい、ってことくらい、

>>113
韓国ではなにか問題が起こっているの？

ぷにこーど、これ最強(名前だけ)

>>115
同音異義語や難解な単語がどんどん減っているとか。

漢字の造語能力に頼れない上にそれにかわる単語の生成規則がないので
研究分野でも困りそう。

UCS-4ならサロゲートに悩まされずに済むよん。UCS-4万歳。

＞1
あなたに指図される筋合いはありません。何の権限があってそのような事を言うのですか？
以上、素朴な疑問。

「お願いします」は指図とは言いません。以上。

>>120
もしかしたら「おながいします!!」は指図なのかもよ!?

LinuxのglibcはUCS-4って聞いたけどあれはどうなってるの？

>>120
コピペにマジレス

>>118
サロゲートは無いけど、合成文字とかあるのは一緒じゃん……。
まぁ、そんなこと言ってたらキリが無いんだけど。

>>74
>「慣れてないから」っていう理由が 95%(当社比) を占めてる。
>英語とかで想像してみるといい。
>中学校で英語習ってた頃は、例え読み方暗記している単語ばかりでも
>すごく読みづらかったはず。
>でもある程度慣れてくると、知っている単語だと スルッ と頭の中に

君には、以後の英語の読み書きを全て大文字て行うことを命じます。
2年ほど経ってまだそんなことを言えているなら、その方向の話を続けてもよろしい。

kanji yamerotte iunara
issonokoto kanamojimo yametara iijan

>>125
しかも、そんなことやったら、現在の日本語のドキュメントが「一部の好事家しか
読めない古代語で書かれた何か」になっちまうし。

文学に限らず、技術文書も全て現在日本語から新日本語に翻訳しなおし。過去
の遺産を捨てるのなら、まだ英語に切り替えた方がマシだな。

>>108
glibc とか XFree86 あたりの実装とか、メーリングリストでの議論を読んでると
暗澹たる気分になるな。

俺はファミコンで鍛えられたから、ひらカナ文字でも全然OKだYO!

>>125
COBOLerを見よ。彼らは嬉々として大文字だけの英単語を「日常でも」使うよ。
ちなみにアルファベット小文字は大文字だけだと不便だから生まれたので、
方向的に逆。ひらがな＆かたかな＆スペースだけで不便なら、
いずれそれなりの新しい表記法が生まれるだろう。

>>127
君、あたりまえの事いいすぎ、君がそういう趣旨の発言をするのは >>68 で
すでに予言済み。
日本語の遺産もそろそろ「原典」と「翻訳版」にわけた方がいいでしょう。
戦前の日本語の文章なんか、そろそろ直感的に理解し辛くなってきてるからね。

>>130
タイムスパンが違う話が混じってるな。

日本語の変遷は百年のオーダー（明治時代の文章ぐらいまでは、読むだけなら
たいていの日本人は可能）、文字コードのほうは十年のオーダー。そんなコロコ
ロ変わるものに合わせて言語の方に手を入れるのは、順序が逆だろ。

>>131
たしかにこのスレは文字コードの話題のスレだが、俺は
文字コードの話で極東の言語が問題になる事をきっかけとして、
日本語の表記法自体が「このままだと国際的に不利になる要因」だという
話をしているのだよ。

＞そんなコロコロ変わるものに合わせて言語の方に手を入れるのは、順序が逆だろ。

コロコロ変わるたびに日本人は奔走するんだよね。

あんまりUNICODEと関係ない話だけど
昔日本語が横書きの時今と逆で右から左へ読んでたときがあった。
いまは左から右の方向だけど。
そのころ方向を変える英断を下した人はえらいと思う。
ありがたやー

かといってころころ言語に手を入れるのは私も反対。

>>133
> そのころ方向を変える英断を下した人はえらいと思う。

言われてみれば同感。
アラビア方面ではRtoLで、そのたびにテキストの描画属性を指定しなきゃならないみたいだし。
日本語もそうだったら結構大変だな。

>>133
つうか日本語は元々は縦書きだから
そのころは横書き文化自体根付いてなかった。

ひげする
しのたまくう
かったかったこんなにかった

>>1は日本語を勉強して下ちい

靴のサイズが合わねぇって話してるときに

「てめえの足がでかすぎるんじゃカカト削れ」

じゃ答えになってねぇんだよボケ！！！１

なにが「国際的に不利になる要因」だ
そんなもん技術屋がどうこう口出しすることじゃねぇだろ。

ダイエットするかどうかは本人の問題だ
服屋にどうこういわれたかねぇや。

なんか話が変な方向にいってるな、元に戻す意味でAGEます。
UNICODE推進してる人ってこれがすでに破綻気味なのしってて推進してるわけでしょ？
それが何でなのかわからない。推進派の人教えてくれ。また未来に禍根を残す気なのか？

>>140
原子力推進してる人たちと同じです。
無理やりシェア拡大すれば無理も通りますから。

>>140
限定範囲内での使用なら Unicode も便利だし。なんか俺、矛盾してるし。

>>140
ラテン文字圏のニーズには完璧に満たされており、
ＯＳやＵＩやネットワークの核となる部分の
主な実装者がほとんどラテン文字圏の人間だから。

向こうの人たちにとってとりあえず数式や記号が扱えれば他の国の文字なんてどうでもいいんだろう。
日本人にとってアラビアやインドの文字があまり興味がないように。

くっそー ひでぇ実状だな。やっぱなんとかしてくれよー＞ぷろぐらむ板の住人さま
どうやったら対抗できるんだろう？？？
欧米諸国にこのままじゃ問題だ、やめてくれよと頼んでもダメ？ 頼み方しらないけど。
実はアジア語圏の勢力締め出し政策なのかなとも思えてきた。

ただ、UNICODE が直面している問題って、UNICODE じゃない code 系でも
向い合わざるを得ない点も多かったりするんだよね。

だからISO2022への回帰なんていうのが、単なるおとぎ話にしかならないわけで。

>>139
＞ダイエットするかどうかは本人の問題だ
＞服屋にどうこういわれたかねぇや。
この理論でいくと、日本語は「太った人」じゃなくて
「そもそも人間じゃない生き物」って事になるよ。

恐竜に人間の服は着れないよね。「服を作った人が恐竜が着る事を想定してないから」
恐竜が人間に進化するのは無理があるけど、人間型恐竜になら進化できるかも
しれないよ、何故そうしないの？というお話。

ま、あなたがギャアギャア騒いだところで「漢字廃止」は非常に緩やかながら進んでるけどね。
ちょっとこの速度じゃ遅すぎるので、もっと早くしなければ。

>>144
＞実はアジア語圏の勢力締め出し政策なのかなとも思えてきた。
私もそう思うときがあります。

>>146
なんでそんなに漢字を廃止させたいんですか？
どういう立場のお方？

＞「漢字廃止」は非常に緩やかながら進んでるけどね。
ｿｰｽは？

>>147
在日だろ。ハングル語マンセーなんだよ。

別に国際的に不利だろうがどうでもいいよ。
識字率99%の国に余計なお世話だ。

漢字が無くなると寂しいよ・・・

確かに子供には負担になるだろうけど、
字を見ただけで一瞬で情景が連想できる
表意文字の感覚は得がたいよ。
アニメやゲームみたいな映像のある分野での
日本人の突出した能力は五文字以上の
漢字を一瞬で見分けられる訓練のせいだという
説もあるよ。

横道にそれてごめん。

>>147
漢字は利点より欠点の方が圧倒的に多いと思ったから。

>>148
新聞読めばわかる

>>149
生粋の日本人だよ！在日中国人のお前に文句言われたくないね！

>>150
お前は一生不便なUNICODEを使ってろ。

ブロードバンドの普及も兼ねて全てビットマップの方向で

>>151
漢字は必要だよね。
「き」とか書いても何の事かわからないけど「木」なら一発だ。

＞新聞読めばわかる
産経取ってますが、わかりません。アカハタ取ればわかるのかな？

146は久々の大型新人の予感（藁

「ソースは？」←「客観的論拠は？」
「新聞読めばわかる」←「新聞がそうなっている。主観的に」
話になりませんな。

野嵜ﾀﾝ出張にこないかな(w

146ﾀﾝの発言をまとめてみました。
それでは引き続き議論をお楽しみください。

>>51　>>64　>>68　>>72　>>74
>>86　>>130　>>132　>>146　>>152

>>146
貴殿が日本人を人間と思っていないことだけは解った。

なんと、漢字不要論者がいるのか。
漏れは、どちらかというと旧カナ、旧漢字復活してもらいたい派なのに。。
雅だと思わない？

中国でも、最近は旧漢字が復活してきているよ。
理由はかっこいいから。
確かに簡体字は美的センスに耐えない(W

>>146
そうか！UNICODEは日本人が使うことを想定していないのか。
それなら納得！

雅っつーかオタクっぽい。

>>161
旧かなだと語尾活用の法則と表記が一致して
見かけ上の不規則活用が減るから
文法的な品詞がわかりやすいという利点もあるよ。

書道という世界に誇るべき文化を生んだ漢字の
功績は大きい。

本屋にある小説とか、新聞が全部平仮名カタカナに
なるのか。新しい世代はそれが当然になるからいいのか。

んで今ここにいる連中は「オジイチャンッテ、カンジヨメルンダネ！スゴイ！」
って言われるのか（寂

>>166
COBOLerのように、古臭いって言われるんだよ（鬱

すでにJIS,SJIS,EUCという３つの規格が乱立している状況に、UNICODEが
加わったぐらいどってことないとか思ったりして…。

>>168　(´-`).｡ｏＯ（ わかったふうなこと言ってる暇があったら ）
第3水準を、あんたの「JIS」コードとやらでは、どう表現するんだ (ﾟдﾟ) ｺﾞﾙヮ
小一時間(以下略♥)
http://www.jsa.or.jp/domestic/instac/review/jcsreview.htm

表音文字に比べ、漢字が認識される速度は速いと聞いたことあるよ。
だから交通案内板などに向いているんだってさ。
漢字は、極限まで練り上げた「アイコン」だからな〜

あと、漢字の良いところは、知らない語にぶつかったとき、
表音表記に比べて意味の類推が容易なところだと思うな。

まぁ、いいや。漢字廃止論は、頭のいい奴と頭の悪い奴にしか
理解できない話だからな、常識人間には理解できないのも無理はない。
特に ＊苦労して手に入れた物は価値がなくても大切に思える＊ ものだ。
沈みゆく帝国に(･∀･)ｶﾝﾊﾟｲ

あ、ここで書いておかないと馬鹿が競って書きたがるだろうから
先に書いておく、俺は「頭の悪い奴」の方だよ。
じゃあな、次にお前らに会うのはアメリカ軍占領下の捕虜収容所かな。

よし！俺は146ﾀﾝを応援するぞ！
今までの発言を見てみると、単に全部ひらがなーじゃなくて
新しい日本語のあり方を作りたいんだろ？
がむばってそれを作ってくれ！このスレは君にやる。
明日の日本を救うのはあなたです。

いちお、あげとこ

いちおう日本語は

>>172
つーか漢字覚えるのに苦労した覚えはないが。
漢字が難しくて困ってる人ってそんなにいるの？

>>176
小学生の時分に、毎週漢字テストをやって詰め込まされた気がするが。もっとも
英語なら「漢字」は覚えなくてすむが「単語」は覚える必要があって、やっぱり初
等教育で叩き込まれることに代わりなし。

どっちが楽なのかとか、詳しい話は知りませぬ。ただ日本語を勉強した外国人の
人に聞くと、漢字自体はそれほど難しくなくて、むしろ助詞やら敬語やらの方が大
変だと言ってた（サンプル数３、欧米系２にアラブ系１。あてにならんな）。

俺は漢字を読むのはあまり苦労しないんだが、書くほうは最近ちと辛い。ミーティ
ングなんかでホワイトボードに書いて説明している折、

　そういや、この漢字なんだっけ？
　（なんでこのホワイトボードに IME ついてないんだよっ）

とか思うことが、ままある。普段、コンピュータでしか文章を書いてないからだろう
なぁ。

要は白どもはアジアの怪しげな文字なんか知らん。
うるさいから適当にごまかしちゃえってのが本音だろ。
それでまた訳のわからん中途半端な規格を作って作りっぱなし。
同時に扱わなければならないコードがEUC、SJIS、JIS
に加えてUNICODEが増えるってだけになりそうだね。

>>178
どうでもいいが

欧米＝白人

っつーのは、もはや幻想になりつつある。特に米国の都市部だと、白人人口は
過半数割れしてて、代わってヒスパニック系の割合が急速に増えている。

>>179
で？
国際規格を策定する連中にもヒスパニックが入ってると言いたいのですか？

>>180
国際規格を決める場に、人口比で中国人を参加させたらずいぶんと様相が
変わりそうだな。

ユニコードだめだった。
メモ帳で保存してみたがなぜ0が入るんだ。。。
よってサイズが肥大化するためユニコードはソロモン送りです。

まあ長期的に見ればアメリカの経済支配が人類の滅亡まで続くわけじゃなし。

>>182
一気に話のレベルが下がったな…

とりあえず UCS と UTF で検索して、一通り資料読み直してから出直し。

ちょっとしたWebアプリ書いたことあるけど、JIS/SJIS/EUC/UTF-8、
結局全部対応させなきゃいけないんだよね。
UNICODEの欧米中心だった考え方はよろしくないけど、だからといって
JIS/SJIS/EUCが並立してる現状もよろしくない。

ま、UNICODEがしっかりしたのもにならなかったから、結局４種類＋α
が乱立することになったわけだ。
はっきり言ってやってられんヽ(`Д´)ノ

>>172

ところで、146の理想とする将来の日本像ってなんだ？
漢字が徐々に使われなくなって平仮名カタカナローマ字
だけが使われてるような感じ？
漢字を捨てたベトナムと半島みたいになるのが自然だし有益
というとこか？

>>173
そんなに日本が嫌ならアメリカに帰化しちまえよ。
とりあえず就労ビザとるなら寿司職人が穴らしいぞ。
グリーンカードは大変だろうが。

ﾆﾎﾟﾝｼﾞﾝ全員が、ラテン語、アメリカ語、フランス語、ドイツ語、スペイン語
ポルトガル語、エスペラント、南北朝鮮語、北京語、広東語、タガログ語を
読み書きできます。
なお、向学心のある人はさらに、ヘブライ語、ナヴァホ語、ムー語、
アトランティス語、火星語、日本古語なども読めるようになります。
なお、テレパシーが一般的になるので、、話し言葉は使われません。
以上、300年後の新ﾆﾎﾟｰﾝからお伝えしました。

おれ日本語好きだよ。アルファベットだけの欧米諸国の言語より。
みんな自分の国の言葉なんだから妥協しないでもっといい方法考えようよ。

どうでもいいが、文字コード変換をするAPというのは
結構いい金になった。

っていうひと結構いるでしょ。

>>189
>>41-43
常用漢字だけでいいなんていった奴はどこのバカだ？

>>189
>>47-50
常用漢字だけでいいなんていった奴はどこのバカだ？

やっぱいるって訂正したけど？

お前らローマ字運動でもやっとけ。
http://www.fin.ne.jp/~masa/Mokuzi2.html
http://www.age.ne.jp/x/nrs/
http://www.cityfujisawa.ne.jp/~roomazi/

>>194
訓令式ローマ字嫌いやぁ!!あれじゃローマズィだって。
同様の理由で北斗の拳の激打みたいな奴は大嫌いじゃぁ！
sushi kuine!

31の案賛成。プラスして、下位4ビット程度を、検索で同一視できる文字集合のために空けておいて欲しい。

「Aa」「あぁアァ」とか、簡体字や旧字などをコード的に連続させる。
曖昧比較の実装がすっごく楽になります。
( 直接の互換性は無くなりますが…言語番号0はASCIIを4ビットシフトすれば小文字以外はそのままってのはダメ？

どうせなら、内部コードとして便利なように作ってもいいと思う。

現在の話題と異なるためsage

これどうよ？
http://www.unicode.org/unicode/reports/tr15/p

>>197
ﾌﾟてなんだよ
ttp://www.unicode.org/unicode/reports/tr15/

Iｑｑ　げっとーーーーーーーーー

ＺＱＱもげとーー

なにかわかんないものげとーーーー

ところで、Shift_JISからUnicodeに変換することって
スクリプトで簡単にできるの？

>>202
テーブル引きになるから、変換テーブルさえあれば極めて簡単だよ(鬱)

このテーブルを適当に変換すれ。
ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT

>>185
　　EUC ってどれヨ？
　　　　(´-`).｡ｏＯ（ …と突っ込んでみるテスト♥ ）

面倒くさくても、冗長に EUC-JP とか書かないと
>>184 ﾀﾝに叱られそうです (ﾟдﾟ) ｺﾞﾙヮ
厨房を増やさぬよう、教育的配慮を望みます

>200
それが駄目だというなら、JISも、ISO-2022-JPとやらないと。

JISっつったら句点コード

＞JIS/SJIS/EUC/UTF-8、
この文脈で、JISが区点コードだというあなたは、
日下部レベル＋１ですね : )

>>208
> SJIS/EUC/UTF-8、

いまや全部JISの規格表に書いてあるね

おれのアイデア賛同者いてうれしい あげ！
ところでMSはUNICODE推進してるみたいだけどなんかいいことあるの？？

Microsoftは昔から今動くものを重要視する方針でしょ。
UNIXやMacOSやApollo DomainやXerox Starがあったころも、MS-DOSだもんね。

>>210

文字コードが増えれば増えるほど複雑になる
↓
ソフト需要喚起
↓
アプリで儲かれるＯＳと評判！
↓
ｳﾏｰ

WindowsXPではUTF-16のサロゲートペアにも対応していて、
フォントがあればU+10000〜U+10FFFDの文字も表示出来る。

そんな事より1よ、聞いてくれよ、
昨日、www.unicode.org 行ったんです。www.unicode.org。
そしたらなんかファイルがめちゃくちゃでかくてダウンロード終わんないんです。
で、13MB もある PDF ファイルよく見たら、なんかみんな漢字ばっかりなんです。
もうね、アホかと。馬鹿かと。
お前らな、９万字入りのフォント如きで長々文字表打ち出すために
Unicode 3.1 作ってんじゃねーよ、ボケが。
９万字だよ、９万字。
２バイト固定を信じて作ったアプリもあるのに、よく平気で文字増やせるな。
おめでてーな。
むりやり２万字にＣＪＫまとめながら４万字とか足してるの。もう見てらんない。
お前らな、中華大字典やるからそのコードポイント空けろと。
Unicode ってのはな、漢字は Unify するべきなんだよ。
「桟」の横画が２本か３本かで分けてるのに「浅」は統合されてもおかしくない、
刺すか刺されるか、そんな雰囲気なんだよな。
字を知らなくて単なるデザイン差もわからねーような奴は、すっこんでろ。
で、やっと探してる文字を見つけたかと思ったら、隣のワードと、前のと併せて
１文字なんですよ。
そこでまたぶち切れですよ。
あのな、空き領域でシフトコードなんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、UTF-16 だ。
お前は本当に Extension B の字が読み書きできるのかと問いたい。問い詰めたい。
小１時間問い詰めたい。
お前、surrogate したいだけちゃうんかと。
多漢字通の俺から言わせてもらえば今、多漢字通の間での最新流行はやっぱり、
今昔文字鏡、これだね。
今昔文字鏡 単漢字10万字版。これが通の頼み方。
文字鏡ってのは漢字が多めに入ってる。そん代わりラテン文字が少なめ。これ。
で、それに西夏文字、梵字。これ最強。
しかしこれを使うとフォントに依存するから文字鏡買わないとデータが編集
できないという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前ら初心者は、Mac OS X で JIS X 0213 でも使ってなさいってこった。

こないだ 5番街の B&N 行ったんです、B&N。
そしたらなんか専門書のコーナーに、ハローページをふたまわり
大きくしたような本があったんです。
で、よく見たら Unicode コードブックとか書いてあるんです。
もうね、(以下略)

>>214
(´-`).｡ｏＯ（ 「お前ら初心者」は超感じ、って感じぃ？　ちょーダサくな〜い？ ）

UTF-16のサロゲートペアが使えるようになったからWinのMSフォントにJIS X 0213の文字を追加して欲しい。

>>213
> WindowsXPではUTF-16のサロゲートペアにも対応していて、
> フォントがあればU+10000〜U+10FFFDの文字も表示出来る。

Win2000もMacOSXもできるよ。

UNICODEは世界にひろまりつつあるけど、
オブジェクト指向と同じで駄目駄目ですがな。
中途半端で終わりますです。

>>219
そうかー？
開発者からみたらやっぱり使いやすいと思うんだが。
やっぱりUTF-8っす。

ソフトウェア開発者が使うなら、やっぱりUnicodeでしょう。
現状、国際化されてるアプリケーションの
内部キャラクタセットはやっぱりUTF-16や、UTF-8だよね。

Windowsで言えば、MSLUも出たことだし。
Win9x用も、WinNT用も、もう全部Unicode APIで実装でしょう。

＞Win9x用も、WinNT用も、もう全部Unicode APIで実装でしょう。
いつからWin9XでUNICODEアプリが満足に動くようになりましたか？

>>222
MSLUが出てから。

これですね。
http://www.microsoft.com/globaldev/articles/mslu_announce.asp

>>223
まあWin9x上では、MSLUは結局内部でANSI APIに変換してるだけなんだよね。
だから、Win9xでは、マルチリンガルはできない。
でも、MSLUが出て、Win9xでも、W Functionが使えるようになったってのはいいよね。

>>219
君の発言で確信が持てた。
アンチ OO は難しい漢字大好きな権威主義者だね。

Unicodeは、外国ソフトを作りやすくするための戦略。
いらねぇよ。グローバリゼーションの恩恵を受けてるところなんぞ、
おこめの国以外ない。

＞内部キャラクタセットはやっぱりUTF-16や、UTF-8だよね
とかいってるし。結局Unified出来なかったんだから、Unicode化は
OSとかが対応していればやればいいという感じ。XMLとおなじで
ある程度は標準の役目を果たすんだろうけど。

>>227
ヨーロッパのソフトウェアだってグローバライズされてるよ。
中国だって、GB18030標準になって、WinでUnicodeでアプリケーション
作らなくちゃならなくなったんだぜ。
日本は時代遅れだよね。

>>227
> いらねぇよ。グローバリゼーションの恩恵を受けてるところなんぞ、
> おこめの国以外ない。

やっぱり日本のソフトってだめだめなのか。

>>228
Shift_JISみたいなNativeキャラクタセットよりは、
かなりましだと思うけどね。
結局てっとりばやく国際化できるキャラクタセットが
今のところUnicodeってことなんだろうね。

文字コードなんつーのはOSやVMで吸収すべきもので
アプリ製作者は意識しないでいいものではないかい？

>>232
> 文字コードなんつーのはOSやVMで吸収すべきもので

言ってることが抽象しすぎだよ。どうやって吸収する？
例えば、メールやWeb,Internetなんかはどうするの？
W3Cで国際化するときはUTF-8なんて言ってるけどそういうのも
どう抽象化するの？

>>232
そんなOSないっす。

>>232
>アプリ製作者は意識しないでいいものではないかい？

例えば、ASCIIの0x20をスペースって言いますみたいなところは、
アプリ制作者は意識しないってこと？

>>235
つーことは、
if (c == ' ')
みたいなことはするなってことですな。

>やっぱり日本のソフトってだめだめなのか
先進国では最低水準

もちろん理想論で、現実にそんなOSないのは>>234の言うとおり。
でもJavaや.NETではある程度現実化してるんじゃないかな。
要は抽象化された文字オブジェクトと文字列オブジェクトを用意すればいい。
スペースという文字は使えるけど、それが0x20という実装かは意識しないでいいのでは？ってこと。

>>236
じゃなくて
if (c == 0x20)
はやめれ、っつー話じゃないのか。

>>238
確かに、次の文字のトップが2byte先か3byte先かとかはOSがサポートできるけど、
（現にIBMのICU何かを使えばかなりのことできるしね）
そのデータ自体が今どのキャラクタセットで話しているかは、
やっぱりアプリ制作者が認識していないとだめと思うよ。

>>239
if (c == ' ')
でもだめでしょう。だって、' 'はスペースじゃないかもしれないんだから。
だから、それはif (c.isspace())とか、if (is_space(c))
じゃなくちゃ。

＞240
::CharNext()?

>>242
WinのCharNextを言っているんだったら、
それは使えない。だって、あれは、OSのキャラクタセットか、
もしくはUTF-16しかサポートしていない。

どこぞの国が決めた規格を薀蓄いっても何もはじまらん。
日本には変なPGかレベルの低いPGしかいないとしか
おもわれてないちゃうの。

>>244
この文章だけ読むとデンパっぽいぞ。（脈絡あるから分からんでもないが、
もう少し詳しく書いた方が）

ソフトウェアに置いて日本の出る幕はねぇーっつうことだ。
無いわけではないが、おいしいところはかっさられるっつう
わけだ。悲しいよ。
だから、別にUNICODEはいんだけど。

>>246
俺はそう思わないよ。
ただ、日本の会社が積極的に売っていかないってのが問題あると思うよ。

もちろんいけてる会社もあると思う。ただ、
なんというか、ピラミッドの底辺部分が弱い気がする。

じゃ、まずは製作所と不治痛を解体して、ゴミを業界から一掃するということでいいですか？

>>244
(´-`).｡ｏＯ（ 上流がしっかりしてればいいべ ）

>>218
そうなんですか。
僕Win98からWinXPにうpグレードしたもんですからWin2000については知らなかったんです。
ちなみにWinMeではどうでしょうか?

>>251
> ちなみにWinMeではどうでしょうか?

一般的に限定されてます。TextOutWとかはできるけど、
メッセージ自体Unicodeサポートしてないからなあ。

何でMSフォントはS-JISにある記号(△など)は大きくてS-JISにない記号(横向きの三角など)は小さいのか?(一部例外あり)

>>253
(´-`).｡ｏＯ（ 「S-JISにある」ってどゆ意味？ ）
1. フォントファイル のテーブルがそのグリフにS-JISだけ割り当ててある
2. 第１・第２水準にある

>>254
じゃなくて、MSフォントって言ってるから、
コードページ932に定義されている文字ってことじゃない？

100get(16進で)

>>254
コードページ932に定義されている文字のことでした。
「S-JISにある」は誤りでした。

>>100h
説明的過ぎてつまらん

>>253
たしかに。
U-25B7(WHITE RIGHT-POINTING TRIANGLE)と、
U-25C1(WHITE LEFT-POINTING TRIANGLE)は、
MS*ゴシックとかだと、これじゃあ、
U-25B9(WHITE RIGHT-POINTING SMALL TRIANGLE)と、
U-25C3(WHITE LEFT-POINTING SMALL TRIANGLE)は、
と見た感じ区別つかないよね。。。

つーか、全角数字も"FULL WIDTH"風じゃないので、
サポートは毎日「そこは半角にしてください」「してます」「いえ、(略)」の連続。
けど、悪いのはリコー？

つーか、MSフォントの問題は、Unicodeとはあまり関係ないかも。

なんでWinの機種依存文字は全てUnicodeにあるのに
MACの機種依存文字はUnicodeに無いのがあるのだろうか?
(ローマ数字の13〜15,○大,○小,etc)

>>262
(´-`).｡ｏＯ（ ｺｿｿｰｼｱﾑにおける林檎ﾀﾝの発言力に依存 ）

>>262
Combining characterの形でも（例えば"○大"は5927 20DD）ATSUIは
正しくrenderingするし、Text Encoding Converterのおかげで
Script Manager(Shift_JIS)baseのtext modelとの交換も問題ないからでしょう。
Copy paste時も自動的に変換します。OS9でもOSXでもOK

WinXPでは(Win2000でも出来るかも知れないけど)ファイル名にUnicode文字(CP932外)を使う事が出来る。
例えば"만세.txt"とか"♥.jpg"
しかしあまり使わない方が良いだろう。
何故ならUnicode非対応アプリでは開けないし、lhaやzipで圧縮出来ないからだ。
(lhaやzip形式のファイルをバイナリエディタで見たらファイル名はシフトJISだった)

>>265
それはntfsでは？

フォント作ってる人にとってはUnicode嬉しいのかな???

フォント作る人はどうせ自分の担当ぶんの国の文字しかつくらないだろうから
かわんないでしょ？

漢字文字コード統合したせいで各国の漢字フォントが
コードページ切り替えみたいなことせにゃ
統合できなくなったってのが問題なわけで。

どうせやるならＡもΑとかも統合しろってんだ。

欧州文字は意味を重視してコードを割り振られて、
CJK文字はグリフと音のみに基づいてコードが割り当てられてる

日本語と中国語の漢字とかもちゃんと別々にして欲しかった
所詮白人どもの考えた規格か。

>>270
> 日本語と中国語の漢字とかもちゃんと別々にして欲しかった

Language Tagを使って、言語属性を入れればいい。

それはここから中国語とかそういう目印かい?
そういう目印マークいれるなら今までのISO-2022とかと一緒じゃん?

つまり結論としては、ISO-2022サイコーだと?

ISO-2022は文脈によってascii文字の意味が変わるからサイテー

>>274
そうだよね。
あと、iso-2022だと、違なる言語間での、
sortingとかnormalizationとかtranslationとかも問題になる。
やっぱり、ひとつのテーブルに全部格納するようなキャラクタセットが良い。

>>275
Normalizationが分からないが・・・
UCS2で漢字ソートってできるか？
不可能だと思うが。

UTF8とか小細工するんだったら
最初からMuleの内部コードみたいに
おとなしく32ﾋﾞｯﾄにしとけばよかったかもナー

当初のＩＳＯ案がつぶされたのが今更ながらに悔やまれ。

>当初のＩＳＯ案がつぶされたのが今更ながらに悔やまれ。
これ、噂は時々聞くのだけど、具体的にはどんな案だったの?

>>276
> UCS2で漢字ソートってできるか？

漢字ソートって何？
辞書ソート、電話帳ソートとかキャラクタセットに基づいたソート以外にもいろいろある。

どっちにしても、i18nするって言った場合、iso-2022はUnicodeよりも現実的じゃないと思うな。
localeがわかんなくちゃキャラクタセットが決められないんだから。
サーバなんかをi18n化にするなんてときでもそう。
クライアントのlocaleがわかりません。そのときクライアントにはiso-2022の何で返せばいい？
なんてありうる。

>>277
UTF-32

>>279
その辞書ソートって奴できないでしょ

>>282
Unicode collation algorithmを読みましょう。
www.unicode.org/unicode/reports/tr10/

>>283
単純なコード比較じゃなくて、専用のテーブルを参照して比較しろってこと？

>>278
ISO-2022の各コードセットを面に突っ込むという
案だったような
違っってたらフォローよろしく

>>284
javaなんかにもUnicodeのためのcollationのクラスがあるよ。
で、localeを入れると、そのlocaleにしたがってソーティングができる。

iso-2022は結局、ESCシーケンスを使えば、
複数のキャラクタセットを共存できるということで、それ以外はないんだよね。
だから、異なる面の、この文字とこの文字を比較したらどうなるとか、
他のキャラクタセットとの変換のとき、どの面のどの文字を返せばいいかとか決まってない。
（まあ日本語のときはiso-2022-jpってのはわかるんだけど、localeが異なるときね）
決まっているのはEncodingをどうするかってことだけだよね。

つーか、日本人くらいだよ、
iso-2022こだわってるの。（それもメールくらいか）

中国はGB18030で、でっかいキャラクタセットが標準になっちゃったしね。
やっぱりiso-2022みたいな切り替えるってのは時代遅れでしょう。

iso-2022はそれなりに良い点もあると思う。
UNICODEは新しく規格を決めたくせに不満な点が多すぎる。


ところで途中で切り替えんのはいまいちだからUNICODEにしようとかいう話じゃなかったのかな。
それなのにUNICODEで途中でコードの切り替えが必要なんて全く本末転倒もいいところだとおもう。

オレはhtmlもiso-2022にしてるがなあ。
EUCやSJISだとときどき判定に失敗するんで。

>>290
ISO-2022-JP だべ？そんな限定的な話されても…

>>290
ISO-2022を名乗るならせめてISO-2022-JP-2にしとけ

>>289
> iso-2022はそれなりに良い点もあると思う。

全然ないよ。単にUnifyされていないだけ。それ以外はやっぱりUnicodeに劣る。
結局iso-2022は単なる複数キャラクタセットのencodingなんだよね。それ以外のなんでもない。
だから、言語をミックスしてソーティングとかトランスレーションとか考えるとやっぱり問題ありあり。
だから、メールみたいな使い方しかできない。だから、Unicodeに比べてOSに適用しずらい。

> それなのにUNICODEで途中でコードの切り替えが必要なんて全く本末転倒もいいところだとおもう。

なんのことを言ってる？コードの切り替えなんてUnicodeにはないぞ。

>>291
そうそう。iso-2022-krなんて全然韓国とかで使われてないし。
日本人くらいだよ、iso-2022にこだわってるの。

>なんのことを言ってる？コードの切り替えなんてUnicodeにはないぞ。
UCSxじゃなくてUTF-xの事だと思われ

>>293
UNICODEは
文字コード切り替えはないがちゃんとロケール切り替えしないと
表示するグリフ（個々の字形）が決まらない。
実装系作る手間からいったら一緒。

それにソーティングはそもそもロケールに従属する概念では？
複数ロケールをまたいだソーティングってナニ？

英語のＡと平仮名の「あ」と ℵアレフ のソート順なんて
一意に決められるわけないじゃん。
まあ無理矢理決めてもいいけどそれでソートできてナニカ嬉しいわけ？

とにかく複数ロケール間の文字コードのユニフィケーションが
UNOCODEの諸悪の根元。
そこまでしても１６ビットには結局収まらなかったわけだし
最初から３２ビットでロケール毎に分割統治しとけばよかったのに。

>>295
> UNICODEは
> 文字コード切り替えはないがちゃんとロケール切り替えしないと
> 表示するグリフ（個々の字形）が決まらない。
> 実装系作る手間からいったら一緒。

いわゆるアメリカ＋西ヨーロッパでは文字コードだけでOKってとこがミソでしょ？
つまり、もうCJKのことなんてもう気にしなくていいよ、というための錦の御旗。

>>296
(´-`).｡ｏＯ（ ISO-8859-15 は ISO-8859-1 と混在できるの？ ）

>>295
> 文字コード切り替えはないがちゃんとロケール切り替えしないと
> 表示するグリフ（個々の字形）が決まらない。

Unifyされた文字はそうだね。だが、それはコードの切り替えじゃないよ。

>>295
> 英語のＡと平仮名の「あ」と ?アレフ のソート順なんて
> 一意に決められるわけないじゃん。

決めなくちゃだめだよ。多言語化ってのはそういうこと。

> まあ無理矢理決めてもいいけどそれでソートできてナニカ嬉しいわけ？

多言語化ってのはencodingだけじゃないってことだよ。
みんなiso-2022のUnifyされていない部分しか話さないけど、ソーティングもしっかり決まってなくちゃならない。
文字列が等しいかとか、大きい小さいかってのはどんなアプリケーションでも使うからね。
それぞれのキャラクタにcollation valueが決まってなくちゃいけない。
で、さらに、それが選択された言語で変わる必要がある。

さらにトランスレーションだって問題ある。
iso-2022-krとiso-2022-jpに含まれている同じ文字は、
他のOSとやりとりしたときや、比較の時にいったいどっちにころぶのか。

結局iso-2022はOSのキャラクタセットとして使うには使えないってことなんだよね。
encodingとして決めただけ。

>>296
> つまり、もうCJKのことなんてもう気にしなくていいよ、というための錦の御旗。

s/CJK/non-CJK/すれば、iso-2022もそうかも。

結局、
Unicodeも問題ありありだが、
iso-2022なんてさらに使えないじゃんかってことです。

>>295
> UNICODEは
> 文字コード切り替えはないがちゃんとロケール切り替えしないと
> 表示するグリフ（個々の字形）が決まらない。
> 実装系作る手間からいったら一緒。

実装系作る手間はいっしょじゃないぞ。

つーかOSのキャラクタセットとしてiso-2022を実装するなんてできないよ。
決まってないこと多すぎ。

(´-`).｡ｏＯ(CCSとCESの違いを理解している人はどれくらいいるんだろう…)

>>302
そんなの普通理解していると思う。

まあ、たーまにわかってなさそーな人もいるけど、
そーいう人はそもそも
違いを理解していないというより、そんな言葉聞いたこともないって
雰囲気だし(w

ところでXFreeでモメてた件って結局どうなったのage?

agaってないよ。。。

>>303
(´-`).｡ｏＯ(298と301が分かってないだけか…)

>>306
298ですが、俺のことを言ってたのか。

CCSとCESの違いが分かってるかって？
例えば,ISO-2022-JP, Shift_JISなどはCESだよね。
それらのCESにはASCII,JISX0201,JISX0208などのCCSが含まれている。
っていう理解だよ。

>>306だけじゃ、君の言いたいことがわからん。もうちょっと君の意見を言ってくれよ。

(´-`).｡ｏＯ(「OSのキャラクタセット」って何を指しているんだろう…)

unicode策定した日本人は売国奴と言ってみるテスト

(´-`).｡ｏＯ(「OS native」という用語を理解している人はどれくらいいるんだろう…)
(´-`).｡ｏＯ(>>308が分かってないだけか…)

http://www.debian.or.jp/~kubota/unicode-symbols.html
参考になるかもね age

なんか最近３２ビットが良いような気がしてきた。
ISO-2022をまるごと入れたようなもんだけど。
絵や動画、音楽のでかさに比べたらテキストなんて
カスみたいなもんだしな。

>>312
UTF-32 ?

UCS-4

みんなでUnicode化を阻止しよう! 倒せUnicode! 撲滅させろUnicode!

>>312
オムロンあたりの人たちが作っていたm17n web browser(Arenaだっけ?)が、
内部コードが32bit固定長で、当時のweb pageの統計情報を取って、
32bitにしても扱う量は十数パーセントくらいしか増えないよん、と書いてあった。

32bit化大賛成です。

>>315
(´-`).｡ｏＯ（ 「これは Unicode では無い！ XKP ダ」とか言うﾉｶｰ ）

XKPってなに?

50Mのテキストファイル編集するのにメモリが300Mとか必要になるんじゃねーか？＞32bit化

超漢字はどういう文字コードを使っていますか。

なんか計算おかしいような気もするが。。
全部メモリにロードするならメモリ喰いそうだけどそんなことしないべ

300MBぐらいいいんじゃネーノ? 今の時代。

行き先が地獄とわかっている道、
ちょっと道は長いかも知れないけど天国に続くかも知れない道
どっちを選びますか?

>>324
　　(´-`).｡ｏＯ（ 叩けよ、狭き門 ）
　　　　　　　狭き門　(;´Д｀)…ﾊｧﾊｧ

>>325
お前病気だよ

UTF-65536って何よ?

　　　　　　　　　　♪
　　　　　　　♪
　♪　 　 ∧,,∧　　　　　♪
　　　　 ミ ﾟДﾟ彡⊃　UNICODE くさってるー
　　　ヽ⊂　　 ﾐ　　　　UNICODE はいしせよー
　　　 ⊂,,, 　 ﾐ
　　　 　　 し″...

異体字を同一文字コードに入れて、文字の違いは深さで表現すれば
斉藤さんも斎藤さんも齋藤さんも一気に検索できるのになぁ。現状
あと無理にマルチリンガルな文字コード作るよりプレーンテキスト自体を
xmlにしちゃって文字コードをタグで吸収しちゃえばいいと思った。
足りない文字があったらビットマップを張り込んじゃうとか。んでOSで
完全にxmlプレーンテキストをただのテキストファイルであるように
扱う。

>>329
そんなんで解決したら苦労しません。

1文字32bitなら何ビットかは異体字区別専用に割けるんじゃない？
検索時はそれ以外のビットだけをマッチさせればいいっしょ。

一つ言いたい。
日本語のJIS1級だけでも４万字もあるのに、なんでUNICODEは16bitなんだ。
糞だ。死ねだ。ゴミだ。うんこだ。カスだ。
頼むから32bitにして欲しかった。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以上

そして
以下同文
そのうち消えるだろうよ

ぞろ目get

>>329
>異体字を同一文字コードに入れて、文字の違いは深さで表現すれば
>斉藤さんも斎藤さんも齋藤さんも一気に検索できるのになぁ。

「斎」と「齋」は異体字だが「斉」は別字だ。

ㄨㄧㄦ

＞ なんでUNICODEは16bitなんだ。
事実と違う!

＞ 足りない文字があったらビットマップを張り込んじゃうとか。
ベクトルにしろ (ﾟдﾟ) ｺﾞﾙヮ

どいつもこいつも！　どいつもこいつも！

JavaもWindowsも（誤解を恐れずに言えば）XMLもみんな Unicodeだ。
アメリカ人が、ソフトウェアの主導権を握っているという事実が変わ
らない限り Unicode がそのうち消えるということは、ありえないよ。

JIS1級ってなんだ？

UnicodeよりSJISを絶滅させたいよ。

SJISは既に地位が確立してるからなぁー
地位確立する前の今の内に糞コードのUnicodeを絶滅させるのが良策と思う。

つーか何故絶滅させるのかは置いといて、どうやって絶滅させる気？（ﾌﾟｯ

早くWinでもUnicodeの合成文字(U+300など)をサポートして欲しい。

芸と藝だってもとは別字

「俁（4FC1）」の簡体字「俣」が、国字の「俣」と同じに
処理されるのも気になるやね。

unicode擁護派ﾊｹｰﾝ

そういうことを考え出すときりがないから
とにかく形が同じならUnifyするという方針なの。
CJKだけな。

Unicodeは漢字の僅かな字体差は包摂してるのに
英大文字のKと絶対温度記号(ケルビン)、
希臘大文字のオメガと電気抵抗の単位オームなどを分けてる。

>>340
> 地位確立する前の今の内に糞コードのUnicodeを絶滅させるのが良策と思う。

つーか、WinもMacもUnicodeベースだよ。
W3Cでも、国際化するならUnicodeだし。十分地位は確立してるよ。
他により良い国際化Charsetってないしねー。

Shift_JISみたいなNative Charsetはやっぱりみんな嫌うよねー。

>>320
そもそも、50Mのテキストを編集するなんてことはあまりないだろ。

>>348
他に良い国際化Charaset?

TRON、UTF-2000、GCSはダメなの？

>>349
つーか、
MSのワードとかのファイルは、
ほとんどUnicode(UTF-8)じゃんね。
たぶん最近のメジャーなソフトのファイルフォーマットの
大半はUnicodeだぞ。

とりあえず、こんな糞なコードはそのうち間違いなく取って代わられるんだから
早めに置き換えるほうが良いぞ。

＞351
ちがうだろ

何でも一つにまとめようとすると
おかしなことになる良い例ですな。

現行の UNICODE をぶっ潰すには、
UNICODE よりまともなヤツを決めて、積極的に使うしか解決方法はないでしょ？

他にまともなコードがあるのか？ないのか？
ないなら誰が決めるのか？(すごく金がかかるだろ？誰が金を出すんだ？)
どうやって普及させるのか？(趣味プログラマが積極的に自分のアプリに組み込むようにしないと後から普及させるのは難しいだろう)

ここで細かいことをウダウダ言っててもはじまらないよ。

WinXP,Win2000ではサロゲートをサポートしてるのに
それに付属のメモ帳やOfficeXPはUTF-16やUTF-8だけでUCS-4に対応してない

ワードパッドがサポートしてたよーな。＞サロゲートペア

まずは２ちゃんからっつーことで、標準化に向けてライブラリでも整備しないか
TRONは糞だから、手っ取り早くUTF-2000あたりで。

結局なんだかんだいってUNICODEの波には逆らえないような気がするんだけど…

# オレは認めてない。が、日本人だけでなにができる?
# 欧米人が使い始めたらもうオシマイだと思う。

まだ他のコード体系に見込みがあると本気で思ってる人いる?
それともここはただの嘆くスレ?

2ちゃんねらのｽﾊﾟｰﾊｶｰが考案&普及させてくれるに違いないと期待してる

まぁ上のは冗談として、いいコード策定すれば日本人が世界に名前を残すチャンスでも有ると思うんだけどな
誰か音頭取って新開発してくれないかな、、UNIXコミュニティの人々はunicodeについてどうなんだろ。
unicodeまんせーまんせーなのかな? そのUTF-2000ってのにまんせーまんせーなのかな
すでにこのunicodeは破綻してるんだからこれより少しでもマシならみんな飛びつくと思うんだよ、おれは。

>>359
> それともここはただの嘆くスレ?

お前もな

>>361
> UNIXコミュニティの人々はunicodeについてどうなんだろ。
I hate UNICODE :-)

っつーシグネチャは見かける。でも、代わりが ISO2022 系とか言われると萎え。

俺は「何でも良いから統一してくれ、優れたモノが複数あるより、妥当なものが
一つの方が楽だ」というトコロ。OS にしても Win32 はイロイロイロイロ腐ってる
と思うけど、NEWS-OS と AIX 両方に対応するプログラム開発するよりは楽だっ
つーか。

>ただの嘆くスレ
それと無邪気にUnicodeって便利ジャン？と思っている人間に知識を与えて鬱にするスレ

>>356
> WinXP,Win2000ではサロゲートをサポートしてるのに
> それに付属のメモ帳やOfficeXPはUTF-16やUTF-8だけでUCS-4に対応してない

なにが言いたいんだろう？？？サロゲートだって割り当てられてないとこもあるのに。
Winだと、サロゲートはNotepadも、OfficeXPも対応してるよ。TextOutW()もちゃんと動くし。

Win2000,XPは、GB18030対応してないけど、サロゲート対応してる。
中国政府よ、それで良いのか？

10bit-1024エントリが言語地域を示す。大抵足りるだろう。
22bit-64*65536が言語の文字コード。大抵足りるだろう。

極めてシンプル。

>>366
「大抵足りるだろう」ってUnicodeができたわけですな。

>>367
Unicodeは(0,0,0)が言語ごちゃまぜで
言語タグがないと何がなんだかわからん。
その点は上のは最初から区別する。

似てても全然同じじゃないぞ。UCS2,UTF8はゴミだから捨てる。(w
まぁ、文字コードなんてどうでもいいことなんだがな。

>365
下8bitは異字体情報にしてくれませんかね？

異字体情報なら3〜4bitで十分
8bitなんて必要ないだろ
上位10bitが文字セットを示してるんだから

>>369、>>370
どーでもいいが「異字体」じゃなくて「異体字」だぞ。
コード系をうんぬんするなら、間違えんでくれ。
説得力なくなるから。sage

そこで熊さんが言うには「痛い字はどうましょう？」
お後がよろしいようで。ﾍﾞﾝﾍﾞﾝ ﾍﾞﾝﾍﾞﾝ

八つぁん「痛い痔はいやずら！」

>>365
Unicodeの全ての文字を1字あたり4バイトであらわす形式に対応してないという事です。
UCS-4でなくUTF-32と表記するべきだったかな?

>>374
＞Unicodeの全ての文字を1字あたり4バイトであらわす形式に対応してないという事です。

それは今のところ単に定義されていない文字までサポートする必要がないだけだと思うよ。
UTF-16 -> UTF-32の変換って別に簡単じゃん。。。。

UTF-16では約100万のコードポイントが扱えるが
これで足りなくなる日は来るでしょうか?

ぷにコード誰か作ってくだせえ

ぷにコード萌え。

ぷっCS-4、これ最強。

もう折角だから128bit per charの文字コードでいいよ
絶対に足りなくはならないだろ

>380
>>5でガイシュツ

だから前から言ってるように、文字コードなんか使わないで全部bitmapにするんだよ！
嫁ねえとか言うバカには解像度128*128bitずつ割り当ててやる UBF-128で完璧なんだよ。

ビットマップ文字のハッシュで128bit これ最強。
万が一かぶっちゃったらご愛嬌。

それ、改行とタブはどう表現するんだYO

やっぱり現実的なところで4バイトが妥当と思うな

ネットワークは iso-2022。

内部コードは 32bit固定。
11xxxxxx 10yyyyyy 1aaaaaaa 0bbbbbbb

これなら２回のバイトアクセスで文字の位置がわかる。

x - だいたいの地域
y - コード種類
a,b - JISコードとか

面倒なら x,y は iso-2022 の図形文字集合とかを変形して使ってくれ。

全部URIであらわせばいいじゃん。一文字一文字。

URIってなに？>387

>>385
4バイトが現実的かよ！

ジョジョに出てくる擬音です>388

のーみそと直結するようになれば、文字自体いらねーな。

最近 Python-ml-jpであばれてるUnicode厨の実例
ttp://www.python.jp/pipermail/python-ml-jp/2002-March/001135.html
Unicode/UTF-8以外の既存文字集合を不要つったり、自分の意見を日本代表
みたいな顔して海外のメーリングリストに送ったりで、完全にデムパ状態｡

Unicodeの発想自体は間違ってないと思うが、細部がぐちゃぐちゃ、
場当たり的でもう見てらんない。例えば、スペースや横線の種類多すぎ
だったり、改行問題に新たな頭痛の種を持ち込んだり、Han Unification
で解決しようとしたことを今度は「互換漢字」でやろうとしておよそ理解
不能な体系になったり、書体の区別はしない筈なのに「SANS-SERIF
なんちゃら」とかいうのがあったり、etc...。
知れば知るほど鬱になる、それがUnicode。

現行のBMPを廃止して、別の面に New BMP を作って欲しい。
変な制御文字みたいのを作るのはもう止めれ。

>>392
すごい自己厨だね、この人。

http://www.python.jp/pipermail/python-ml-jp/2002-March/001207.html
でばっさり切られてるけど。

間をとって3バイトだな

27bitくらいかな

もう0bitでいいよ！うえーん

>>393
場当たり的、だよねぇ。やっぱねぇ。
さいきん、また、「電気の 「電」 の字を間違えて定義してしまい、
電気なんつーのは C でも J でも K でも頻繁に使う単語だから、
こりゃ洒落にならんので」みたいな errata が出たべ？

優良すれあげ
unicodeまんせーやろうにぜひ読んでもらいたい

福田恆存の「私の日本語教室」文春文庫読んでたら、
国語審議会の「現代仮名遣い」も
始め簡単だと思って始めたら意外と難しくて
後から基準変えて泥沼って話が、当事者の言葉を引いて出てたよん。

けど、Unicodeももう遅いよね...

問題点がいろいろあるのはわかっているが、
それでも新規システムに Unicode を使ってしまうのは私が
至らないせいでしょうか?

ASCII で済む人々が恨めしい。

8bit国コード+16bit文字コードで、
文字コードは各国の機関で制定してもらうってすれば良かったのに。

>>402
すぐに国コードが8bitに収まらなくなるに1000ｳﾆｺｰﾄﾞ

>>398
> 電気の 「電」 の字を間違えて定義してしまい、
もうね、アレかと。ナニかと。
（腐ってる、というのも必然的なものだったわけですか）
>>389
4バイトってそんなに非現実的なんですか？

>>398
> こりゃ洒落にならんので」

「電」だけに(え!?)、Unicode Policyを変えます、とさ

http://www.unicode.org/versions/corrigendum3.html の最後の二段落
http://www.unicode.org/unicode/standard/policies.html

// Policy信じて行った実装とデータ化は?

それが悪の総本山だな
数々の問題点についてのページが見あたらない、、

むりやり拡張して100万文字とか言われてもな。使う人のこと考えてんのかね、毛唐は

>>406
100万文字の為に「拡張」している時点で何も（最初から、何も。必要な文字数さえも）考えていないことは明らかであります。

>>14
（埋もれてるのでリンク張っておこうと思って……）

>>404
今時の画像処理でさえ１ピクセル３２ビットだよ
何にこだわって３２ビットがダメなのかわからん

>>408
そうでした。

4バイトが非現実的って言うのはもしかすると>>14のことを言っているのかな？
（違うような気がするけど）
そういうのも「例外なく統一的に、同様に扱えるように」しないと、実装の段階で捨てられる可能性もあるからね。

やつらがこのログ読んだら泣き出すだろうな
(どうせ東アジア人の言うことなんぞ読まないと思うが)

>>410
ていうか、
そもそも読めるヤシが僅少であるような気がする…

>>411
ていうか、
たとえ読んだとしてもそこでお終いだろう。
メリケンはASCIIでも別に困らない訳だし。
# ドイツとかだとウムラウトとかあるが……。

>>412
チェコとか
ポーランドとかノルウェーとか
アイスランドとかフランスとかイタリアとか
スペインとかハンガリーとかトルコとかベトナムとか…
ラ テ ン 文 字 だ け で も キ リ ル が な い の に な ぁ …

∧_∧
( ﾟдﾟ) 保全age

そして、errata とともに Unicode 3.2 が発表され。
てか、 3.1 と 3.2 って違いがあるんすか？　どうよ？
http://www.unicode.org/unicode/reports/tr28/#errata
http://www.unicode.org/unicode/uni2errata/UnicodeErrata.html

Unicode3.2か・・・たしかひらがなの小さい「か」とか小さい「け」とかが追加されてた記憶が。

>>416
　ヵヶキク
　　　　　⊆ ((´-`)　　　.｡ｏＯ（ サンペーです ）
　　　　　　　(´-`)) ⊇

ちいさいひらがなの「か」と「け」ってどういう場面で使うの?

http://www.google.com/search?q=ヵ
http://www.google.com/search?q=ヶ

ひらがな、、

>>419
「ヵ」を見たら、「何ヶ国」とかのかわりに「何ヵ国」と
やっているようなケースが多かった。

(；´д｀).｡oO(なんで報道と報道向けソースが多いん？）

これだ。ひらがなのちいさい「か」と「け」
http://www.unicode.org/charts/PDF/U32-3040.pdf

たぶんカタカナはあるのにひらがながないと変換できなくて困るとかそういう問題でない？

>>422
確かにAOTKXひらがな入力で「ヴ」を入力すると「う゛」になるからうざいな。

unicode作ってるやつは真性のアホですか。グループに日本人いるんですか?

さいごの 「ち」みたいなのはなんですか。
HIRAGANA DIGRAPH YORI
ってなってるけど、みたことねぇっつぅの。
あんなのいれるんなら、「冷麺あり□」<=「ます」ね
とかもいれることになるんじゃねぇのかよ、糞アメリカ人が

>>424
日本人はいる。ただ、声の大きさが足りてるかは、ちょっと。

（日本からもガンガン意見出さないとダメだと思うんだが）

>>425
「HIRAGANA DIGRAPH YORI 」ってねぇ、
縦書きで合体しちゃった「よ」と「り」だと思われ。
(てか、こういうのも digraph と言っていいんかさぁ?)

近世〜明治初期のテキストにはよく出てくるようです。
ご近所の博物館とかで漁ってみるとよろしいかと。
ていうか、昔の字か…

マスには　(´-`).｡ｏＯ（ はげど〜♥ ）
「酔鯨」ありマス　とかネ　　☆彡

>>425
マス はこちら
http://www.unicode.org/charts/PDF/U32-3000.pdf
303C MASU MARK

うぎゃ、あるのかYO! 見境なくなんでもありなんだな、、

ﾅｲﾅﾗ ﾅｲﾃﾞ､ｱﾙﾅﾗ ｱﾙﾃﾞ ﾓﾝｸ ｲﾜﾚﾃ ﾓｳ ｳﾝｻﾞﾘ ﾀﾞｱ

>>429 その手のヤクモノはキリがないよな。

ところで、
漢字のユニフィケーションにも一応利点はあるわけさ。

互換性問題を考えなけば
いまのＵＮＩＣＯＤＥ統合漢字で別の字になってる異体字を整理して
国コードと異体字サブコードをくっつけた状態が
理想だと思うんだけどどうよ。

国コードと異体字コードを無視すれば全斗煥も毛沢東も検索できるし
斎藤さんと斉藤さんのあいまい検索も簡単。
フォントやなんかの住みわけもちゃんとできるし
いいと思うんだけどな。

>>431
だから「斎」と「斉」は別の字だっつーの。
異体字とかそういう問題じゃない。

意見自体には大体同意。

>>432
（；´д｀）.｡oO（　ハゲドー　）

痛い字は「斎」「齋」だもんナー。
「斉」「齊」は互いに異体字ダモンナー。
「斎」と「斉」は互いに別字ダモンナー。
（以下略）

まぁいまさら作り直すわけにはいかないからねぇ。
Unicode Collation Algorithm を極めるしか。

>>433
> （；´д｀）.｡oO（　ハゲドー　）

何でこれが禿同の顔なのか…「齋」より問題に感じた…

仕様書を全部PDFで公開して欲しいの…

>>433
「斎」と「斉」の他に「一」と「壱」,「二」と「弐」を異体字だと思ってる人も沢山いるみたい。
スレ違いなのでsage

3.1流Win32プログラマとしては、全部Unicodeで組めると
DirectXとか使うときに変換しなくていいから楽です。

「ヶ」はカタカナでは無く、「箇」の略なんだそうです。
「一箇所」「一ヶ所」「二箇月」「二ヶ月」云々……。

「ヵ」なんていつの間に出来たんだろう？

>>438
そう、そこが問題なのヨ。
新聞記者向けガイドブックとかで使用が「ヵ」の使用が
推奨されているのかな？

ヨとかつかうなＹＯ
気持ち悪い。

YOはいいのか世?

その小さい「け」のことは知ってたけど、
口でしゃべるとき発音が「か」だから
アホが勘違いしてちいさい「か」だと思いこんで
使ってるってのがおれの予想

だから既出が「がいしゅつ」になる日も近いね

希望が「きぼん」になったり、習字で「ﾊﾝｶｸ」書いたりすんの?

「間違った言葉遣いもたくさんの人が使えば認知される」

「行き当たりばったりの糞コード(unicode)もたくさんの人が使えばそれが主流になる」

これって似てるね

赤信号みんなで渡ればこわくない

悪貨は良貨を駆逐する
　　Thomas Gresham （1519〜1579）
　　http://www.infoplease.com/ce6/people/A0821820.html

>>446
それ、意味が違う。良貨が駆逐されるのは
> the good money is withdrawn from circulation by hoarders
（良貨は人々が手元にとどめ置くので、貨幣の循環から引き出されてしまう）
からであって、悪貨を積極的に使うからではない。

UNICODE が普及するのは「普及してるから使う」「使われてる OS やライブラリ
が増えてるから、ますます普及する」という拡大再生産の循環に入っているから
だし、そもそも公共財的な性質を持つ文字コードと排他性が働く貨幣の所有を
同列に扱うのは無理。

なにげに教養あふれる人が集うスレであった。

>>448
エイプリルフールですね（教養あふれるってあたりが）

>>447
○悪貨は良貨を駆逐する
(1)「グレシャムの法則」参照。
(2)転じて、悪人のはびこる世の中では、善人は不遇である。

何でJIS X0213面区点1-11-69(「∧」みたいな記号)と
1-11-70(「V」みたいな記号)って
UnicodeではU+02E9 U+02E5,U+02E5 U+02E9のように表すのだろうか?

プログラマとしてはエンディアンの問題も厄介。
多バイト文字だと、リトルかビッグかを考える必要がある。
Unicodeでは両方が認められていて、
最初の２バイトで判断できることになっているが、
文字列の最初に判定ワードがある保障は何もない。

>>452
1パス目でサンプリングして判定すればいいじゃん。

ひっくり返った値が有効なコードのみで構成されているとすると判別できないねえ。

有効な文字のみで構成って言っても、
テキストには出現コードの偏りというものが存在するから、
統計を取って照合すれば？

今のSJIS/EUC/JIS判定だって似たようなことしてるんだし。

せっかく新しいの作ったのにただ文字が増えただけかよって思ってしまうが

>>453
「BOM使わんヤシは頃ス」でも　　　(´−`).。ｏＯ（ OKヨ ）

>>456
マイナーバージョンアップでは大幅な改訂はやらんでしょ。4.0を待ち。

つか、全く期待できないんだけどね
4.0で廃止しました。にならないかな。

>>459
そんなこと逝ってると、またXKPがプリ返してくるｙｐ！
具体的に代替案が無いなら、とりあえず Unicode を age とけ。

それが嫌だからちゃんとしてほしいのに>>455
いつまでもブラウザの自動判別レベルでいいのかや？

>>461
だからBOMを付けれと、小(略)

全文書XMLにして、XML宣言のアタマ'<!'でみわけるとか。

>>455
いつまで斯様なローテクにたよらねばならないんでしょうか（；´д｀）

BOMって必須？それとも任意？
任意なら意味ないなあ。

爆弾ってなんですか??

>>465
そりゃBOMBやがな！！



と。

わかった。これね。
http://www.atmarkit.co.jp/aig/01xml/bom.html

>>467
もとネタも見ておこうゼ！
これ↓の 2.7 節と
http://www.unicode.org/unicode/uni2book/ch02.pdf
これ↓の 13.6 節ね。
http://www.unicode.org/unicode/uni2book/ch13.pdf

用語集のページは、このとおり。
http://www.unicode.org/glossary/#byte_order_mark

優良すれさがりすぎだよ age
業務でunicodeまわり担当した人感想をどうぞ!

ん
UNICODEで書いたSSIのHTML、BOMがそのまんま表示されてデザインくるたよ。

>>469
「ROMが足りねえよ！」で
製品化が　あぼ〜ん。

例のうんこ変換テーブルがやっぱでかい?

いてまえ！

多バイトのデータを生で外出ししてる時点でアウト。

UnicodeならUTF-8とかにエンコしてバイトオーダの問題が出ないようにする。
これ最強。BOM逝ってﾖｼ

>>474
それ意外と賛成

Windows2000のメモ帳はUTF-8で保存してもBOM付けますが。
えーと、EF BB BF だったかな、たしか。

>>476
　ヽ(；´д｀).｡ｏＯ（ 強制的に EF BB BF かぁ。 はっふーン　)

ついでに
unicode.org のグロッサリを見ると
　The Unicode character U+FEFF ZERO WIDTH NO-BREAK SPACE
　when used to indicate the byte order of a text. (See Section 2.7,
　Special Character and Noncharacter Values , and Section 13.6, Specials .)
　(http://www.unicode.org/glossary/#byte_order_mark)
と書いてある。

Section 13.6 の Table 13-2 に、いろんなエンコーディングによる
インスタンスが纏められているヨ。

Windowsが日本市場を制圧するためには役所にも導入されなければならず、
役所では人名で特殊な文字も使わなければ「使えない」と思うのですけど、
そこらへんはどうなっていますか？

あと、24bitじゃ足りないんでしょうか？実質的に。

人名出ないと困るだろうねぇ

うちの近所の区役所では、住民票を電子化するときにＪＩＳ第二水準までの
漢字に置き換えさせていただきます、ってことだった。人の名前を勝手に置き換えるなよ...

木ハ
｜ロ

な松の人もいるわけだが、そういうのも木ハムに統一されたのかな。

でも年寄りは別として、「人名に使える漢字」には制約があって一覧表もあるみたいだし、
とりあえずは人名漢字をカバーしとけばいいという考えじゃない？

我々日本人プログラマができる草の根運動は、
文字列を int 幅で扱うことですか？

人名なんてきりがないよ。
おとしよりにはいまだに変体仮名の名前の人がいるけど、
ああいうのはどうするんだろうね。

>>481
int幅って32bitですか？
どうしてもint=16bitが頭から離れないんだけど。

>>483
ＰＣによって違うんじゃなかったっけ。
32Bitパソならintも32bit幅、みたいな。
ウロ覚えでスンマセン。

>>484
そうそう。だから481の人がどっちのつもりで言ってんのかわかんないんだけど。
Javaなら幅が明確に決められてるからいいんだけどね。
Javaのintは32bit。Javaだとcharも16bitだな。

われわれにできること

1.UNICODE関係の仕事がきたらキッパリ拒否+逆襲
2.とりあえずunicode.orgをぶっ潰す
3.新しいコーディング方法を考えて勝手にそれを広める
4.転んでも泣かない

好きなの選んでヨシ!

内部処理としてはUCS2モドキ、転送用としてはUTF8を使うけど
charsetについては独自に決めてくしかないねえ。

>>482
Unicode.orgが刺客を送ったそうです。

>>478
24bitて. Word境界どうすんねん?

>>488
Word境界ってなんですか？と聞いてみる。

とにかくUnicode使うんなら、
さっさと対策講じて、さっさと移行してくれんかな。
Unicodeを要求するApiとか、紛らわしいんだよ。

…つーか完全に移行しても、
２バイト文字を使うのなんて、紛らわしくない訳がないな。

ところでCPUの進歩で、char型文字列を使う必要はなくなりますかね。
全部string型で管理できたら、ヘタレな俺は大変助かるんですが。

String型を使えるようになってパフォーマンスが向上するならあるんじゃない？
パフォーマンスが落ちるなら、ないでしょ。

>>490
Javaに移行すれ。
とネタ振ってみる。

age

>>491
ありあまるCPUパワーまかせで解決。

中日韓の文字はむりやりunifyしたくせに
欧米の文字をunifyしないところに設計者の差別意識が
良くあらわれているとAssistの社長が言ってたよ。

ΑとАとＡをunifyしない理由は何？

なにをいまさら

こんなに文字数が多いなんて想定してなかったから。
最初の設計者が良く良く考えてはなかったのね。

>>495 >>497
ヨーロッパの字母を「unify」しない理由は、たんに
そもそもそういうつもりで unify って言っているのではないから。

彼らの unification は、ひとつのコード体系の中に、どの言語用の文字も
簡単に (彼らの幼稚な決め方によって) 入れられるという、無知から生まれた
naive な発想にすぎない。

もっとも、大切な言語と思われている言語のための文字から順に
表に納められていること自体が誤りです。最初の 128 文字くらいで、すでに
USA 中心のコンピュータ利用機会を追認していることが罪悪です。

やはり、CJK の字母の多さには、あとから気づいて慌てていました。
あきらかに CJK 相当のコード空間がたかだか 1/3 に節約できるだけなのに、三者を
「むりやり unify」することを始めてしまった挙げ句、根本的な解決を怠ったために、
サロゲートペアを導入せざるを得なくなったり、「電」なんていう大切な字母を
間違えたりするという体たらく。

あんな ad hoc な対応のしかたでは、そのうちホツマ文字も採用されてしまうよ。
あなおそろし。

そもそも、他のコード集合から移行して UNICODE を採用すべきシステムにおける
移行に伴うスループットの低下について、定量的に算出することが可能であり
かつ容易に導入できるような見積りの手段をコンソーシアムが提供できない事実が、
コンソーシアムにおける低レベルのモラールを窺わせます。

ホツマ文字で検索してたらおもしろいの見つけた。
http://www2.tron.org/set.html
TRON関係のページらしいけど。漢字は無理矢理統合したくせにこれ採用されたら笑えるな。

unicodeは未来のコードとか言いつつアジアンを差別する香りがプンプンするので大嫌い
fuckin' unicode!
なるべく使うのやめようぜ、住人のみんな

だからかわりに何を使えってんだよ。
sjisか?

>>498
最後の段落なんかﾜﾗﾀ
何処かで読んだような気が持ってまわったイヤらしい

unicodeが駄目なのは解ったのですけど、
なぜ日本人も推進してしまったのでしょうか？

OSがMSに握られてるから？でもたしかジャストシステムも絡んでましたよね。
他にないから？

ホツマ文字ﾜﾗﾀ。
まあでも需要はありそうだよな。携帯厨向けに絵文字に採用するとか。

他にないならTRONコードでいいじゃないか！という気が
激しくしてきました。

今からでもいいからCJK分離しましょうUnicode

>>503-504
いや、だから、むしろ
TRONコードっていうわけにもいかないんだっつーの。
つーわけで、>499 の 前半を読んでみてよ。

Unicodeは否決、んでアジアンが中心になって新しいコード体系を作れちゅうことやね。
でも米国中心なギョーカイがそれ採用するのか？
それ以前に、新しいコード体系ができるまで何を使うんだ？
現状でぁマルチリンガルな文書を書きたくても複数のコード体系を混在できないぞ。

話がぐるんぐるん回ってる気が激しくします。まあそうなんだけど。
もっと建設的に行きましょうよ。

まず、やっぱり、一生使わない漢字だとしても蔑ろにされるのは嫌。
技術者のエゴだと思うよ。「それは仕様です」に代表される。

コード体形は何でもいいけどさあ、とりあえず char を 4bytes
にしなきゃ何も始まらないだろう。

>>506 可変長がいまいちだけど、TRONコードが現実これが最高の理想だと思います。
32bytesにパディングしちゃえばいいし。
http://www2.tron.org/troncode.html

よし、漏れはここに誓う､これから書く unix のコードは
文字を int で扱うっす。標準ライブラリも書き直していくっす。

#unicodeのスレがふたつあって不便。

>一生使わない漢字だとしても蔑ろにされるのは嫌。

文字コードは、字形を表現するという役割だけではなく、
処理速度や記録効率なども求められると思われ。

さらに、国際的に使ってもらおうと思うなら外国人が納得する様な、
(たとえば一部をASCII互換にするとか)仕様でないとダメだと思われ。

>一生使わない漢字だとしても蔑ろにされるのは嫌。
そんなにこだわるなら、
文字コードなんて融通の効かないもんつかわんでPostScriptでも使えば?
検索ならパターンマッチングを使えば、遅くてもできない事はないだろうし。

こうしてまた振り出しに戻るのであった。

>>509 薄っぺらい反論するなあ。

ISO10646の原案はきれいだったんだけどなあ…
Unicodeが乱入してくるまでは。

革新Unicode派―OSや言語で環境整いつつあるからいいじゃん。出せない漢字があるのも仕様っすよ。
保守ShiftJis派―（実はよくわからない）
理想TRONコード派―トンパ文字もゼントラーディー文字もゼビウス文字も使いたいたいよねえ。
穏健ISO派―unicodeにのっとられ。

>もっと建設的に行きましょうよ。
無理。ここはUnicodeを叩くスレなんだし。
Unicode以外のものを支持・推進するにしては力不足。

>>514 じゃあこのスレは「愚痴」るだけのスレなのか。
そうだよな、愚痴るぐらいしか出来ないよな。
Mr. Gatesの野グソ写真でも落ちてないかな。

ウイルス集めてるんで誰か下さい

おれはunicode野郎は市ね派。
ShiftJIS派じゃないけど、どうせやるならもっと「きれい」なコーディングが欲しい派。

ちょっと思いついたんだけど、unicodeなら日本語も中国語も混ぜて使えるとかいってるけど、
--- 中国語の草は「草」と書きます。日本語では「草」と書きます。 ---
ってな文章だった場合、草が統一されてたらどうやって表現すればいいのさ?

>513
とりあえずTRONコードに期待。
フォントがデカイけど。だからって超漢字は欲しくないし。

>517
ぜんぜん解ってないのにくちばし突っ込むな。

>>518
「フォントがデカイ」って、どーゆー意味？
（ ﾟдﾟ）σ）Д`）

>>520
(TRON)フォントのファイルサイズっつ意味。
あれだけ文字が多いと、相当にデカイだろうなぁ・・と。

Gryphと文字セットは切り離して考えよう

>522
ｽﾏｿ

>>519 なら解説してみろよ、草のコードが一緒ならどうすんだよ?
2文字目の草と3文字目の草をどうやって内部で区別するんだよ?

>>1のリンク先より引用
たとえば、中国語 (繁体字) で「草」を表すのに使用されるグリフでは、草を表す部首の草冠が4画ですが、中国語 (簡体字)、日本語、および韓国語のグリフでは3画です。しかし、書記体系とは無関係に、「草」の字に対応するUnicodeポイントは1つ (U+8349) しかありません。

言語切り替えキャラクタとか無かった？

LANGUAGE TAG を使うのさ・・・

>>524 だから区別してないから問題になってんだよ。キミ見当違い君。

とはいえ、Unicode以前は日本語と独逸語とハングル混ぜるような芸は不可能だったわけで。
ま、20年もすればもうちょっとマシなコードができるだろ。その頃は32bitどころか128bit使っても
文句でねぇだろうし。
つーことで俺はUCS-2でいいわ、いまんとこ。

>>528
ヲイヲイ
iso-2022があったろうが。切替え方がよ。

んじゃーISO-2022とかと一緒じゃんか?

っていうか、奴ら問題の本質解ってなさすぎ。
奴ら向きに説明するなら、小文字のaと小文字のdを同列に扱おうって話だ。
と言うべきだ。
「おれら異文化圏からいえば、aとdの違いは単に上が長いかどうかだけ。
だったら一緒に扱っても問題ないな。コードの節約になるし。
あと、αとａは似てるから一緒ね。βとＢも似ているから一緒。ハイ決定！」
という事と同じだと言ってやればいいのさ。

>>531
激しくがいしゅつ

がいしゅつでも、誰もそれを標準化委員会で言っていない

>>529
iso-2022ったって、CJKとLatin1くらいでしょ？
他はなにも決めてないぞ。
いまやメールだって日本人以外は、ISO-2022なんて使わないよ。

>>531
> っていうか、奴ら問題の本質解ってなさすぎ。

つーか、それはまさに人のことをたなにあげてますな。
日本人だって、Shift_JIS作るときにすでに妥協してるじゃん。

> 「おれら異文化圏からいえば、aとdの違いは単に上が長いかどうかだけ。
> だったら一緒に扱っても問題ないな。コードの節約になるし。
> あと、αとａは似てるから一緒ね。βとＢも似ているから一緒。ハイ決定！」

同じ感覚でShift_JISも作られたんだからね。

shift_jisのころは、そもそも記憶資源＆処理能力の所為で16bitにせざるを得なかっただろ

>>534
SJIS で unification されてるのか？　それは

　はつみみです (C) void

だけど。

>>528
正味なハナシ、MIME 使えば全部 EUC 系ですらオッケーちゃうんかい？
てか、ISO-2022 で済むンちゃうんか！
てか、Deutsch のアルファベートと日本語だけなら JIS X 0208:1978 だけで
済むんですけど、何か？

>>536
> はつみみです (C) void

いやあ、こちらこそ、おはつまみむめも。
俺が言いたかったのは、例えば、もりおうがいの「おう」の字とか、
Shift_JISでそんなのは許せるのかってこと。

>>537
またそうやって、アジアだけで済まそうとしてる。eucでIndicどうすんの？

>>538
「Deutsch のアルファベートと日本語」って「アジアだけ」じゃないんだよ。
「日本語と独逸語とハングル」も「アジアだけ」じゃないんだけど、わかるかな?

てか、534 のことは放っておきなよ。

>>537
まいむでどうやって言語混ぜるんデすカ？

世の中いろんな形式の文書があって、
どうせそれぞれ変換なりして対応することになるんだから、
あらゆるコードを混在させられる内部表現としての文字コードがほしいよな

>>541
UCS-4

>>542
CJKの潜在的な問題は解決してないでしょ？

>>543
なんで？ Basic multilingual planeだけはUnicodeに汚染されてるけど、
あとはcanonicalなまま(言語ごとにplaneが違う)でしょ？

abc'efghi'k'mnop'rstuvwxyz
AB''E'GHIJKLM'OP''ST'V'X'Z

[']は他の似ている文字の拡張、および、代用するという事とする。
拡張文字の前にはESCシーケンスを入れてこれを補う。

おおっと。
mnuも最適化できるな。
nに統一する。
mを表す場合は、ESCを入れ、nnとする。
uを表す場合は、ESCを入れ、180°回転コードを入れる。

おおっと。
vw、VXも最適化できるな。
vに統一する。
wを表す場合は、v[ESC]vvとする。
Xを表す場合は、X[ESC][上下合成コード]v[180°回転コード]v


ん？
似ているんだから良いだろ？なんか文句あんの？
最適化だよ。こうしないと入らないんだからしょうがないだろ？
細かいこと気にするなよ。Ｈａｈａｈａｈａｈａ！

はぁ？いつも使う語が標準セットに含まれてない？
Eはちゃんと含まれているではないか。
我々の統計では、Eが最も使用頻度が高く、Xの頻度は低いと出ている。

まぁ、偶に使う文字など標準に無くてもそれほど問題ないと考えている。
我々は、ちゃんと＊使える＊ように設計したはずだよ。Hahahahaha!!

>>545-547
んじゃ漢字も
終=[esc](左)糸[esc](右)冬
努=[esc](左上)女[esc](右上)又[esc](下)力
とか出来るな。

>>540
ゴメソ！

>>549
ドットで書く…

ハングルもハングルも

結局すべては.(period)に帰納しますか？

>549
ESC必要ないんじゃ? って言うか、普通に使われてるし。

((( ;ﾟДﾟ))) ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

555get

Unicodeも今と昔で、方針が変わっていたりして。
漢字統合は16bitになんとか納めようと頑張っていた頃に考えられてた事で、
16bitに収まり切らなくなってからは、依存の体系をそのまま収録するような
方向になってきてる気がする。

CKJ統合漢字は、古の見られたくない過去として葬って、
新たに各国の文字集合を追加するってのはムリかねぇ。

>>556
方針が変わったところで、
>CKJ統合漢字は、古の見られたくない過去として葬って
これが絶対にされそうにないから愚痴るのではないのか？

>>CJK統合漢字は、古の見られたくない過去として葬って
>これが絶対にされそうにないから愚痴るのではないのか？

Unicodeコンソーシアムの方には打診してないの?
ユニファイへの苦情を激しく申し立てれば、今なら通りそうな気もするけど。

打診をする前に、登録して欲しい文字セットを用意しないとならないかも。
JIS2000あたりかな?

Windows方面は、サロゲート付き16bitという、マルチバイトな
WideCharでいくらしいが、なんだかなぁ……

>>549
Ideographic Description Character とかいうのがあったような。

むかーし昔のタイプライタには数字の 1 がありませんでした。
アルファベットの I で代用していたのです。

「似てるんだからいいじゃん」というおおらかなアメリカ的精神は
Unicodeにもしっかり活かされています。

>>559
> Windows方面は、サロゲート付き16bitという、マルチバイトな
> WideCharでいくらしいが、なんだかなぁ……

いや、Winでは、Unicodeぬきにして、そもそも、
ネイティブキャラクタセットの１文字の最大長が
２バイトってのがもっと痛い。

>>561
I(大文字アイ)じゃなくてl(小文字エル)じゃなかったっけ？

つーか、
Unicodeの問題って、そんなにグチになるほど、
2chユーザは困ってないんでねーの？

まあ、
通常、Unicodeより、SJISの方がこまるよね。
やっぱり。

>>564
winの実装で環境が整ってるからだろ。

今後問題が出てくる可能性を考えると、
おちおち使ってられないってことじゃないのか

>>566
> winの実装で環境が整ってるからだろ。

つーことは、いまのUnicodeで十分ってことですか。

>>567
まあ、それにしたって、俺も、Shift_JISよりは、ぜんぜんましと思うんだが。

ユーザとしては、
Shift_JISで補助漢字出ないほうがいたいだろ。
グリフが違うの出したいって要求より、
補助漢字出したいって要求のほうが断然多いと思うんだが。

我がUNICODEは永久に不滅です。

>つーことは、いまのUnicodeで十分ってことですか。
十分だと感じている人もいれば、そうでない人もいる。

誰もが十分と思うようなコードは永遠に出現しないと思われ。

結局どんなコード作ってもどこからしか不満はでてくるのだろうから
いちばん実装が進んでいるUnicodeでいいじゃん。
BMP面より後ろは、まだまだ余裕があるんだし。足りない文字は追加しる!

ただUnicode 3.2になって依存のコードとの
公式変換表が無くなってしまったのにはビックリ。
そんな表を作っても結局、実装次第だから変換の一意性はあきらめてしまったのだろうか。
まぁ、Unicodeだけを使うならあまり問題にはならないのかもしれないけど。

> 公式変換表が無くなってしまった

アチャー、それじゃあ実装ごとに独自の変換表を持ってねってこと？
今現在すでに混乱してるのに、拍車がかかる・・・

> まぁ、Unicodeだけを使うならあまり問題にはならないのかもしれないけど

通常アプリは変換テーブルを持てばなんとかなるだろうけど
DBが困ったことになりそう
メジャーなDBってUnicode対応してないような。

>>570
＞BMP面より後ろは、まだまだ余裕があるんだし。足りない文字は追加しる!

それどころか、群がグングン増えていく (当社比)
で、いいじゃん！

> 公式変換表が無くなってしまった
なにー！
自分で変換表作らなきゃならないのか！？まじ！？

君らヒマだねえ。
こんなところでグチってても何もならないよ。
UNICODEがひっくり返ることなんてないんだから。

>>574
>>452 から読め

一つ訂正、変換表がobsoleteされたのはUnicode 3.1.1 からだったみたい。

>アチャー、それじゃあ実装ごとに独自の変換表を持ってねってこと？

結果的にはそういう事になっちゃうんだけど、

経過を説明すると、既に各ベンダーが少しづつ異なった変換を実装していて、
正式な変換表とはどれもあわない。そんならヤメちまえって事になったらしい(ｫｨｫｨ


>メジャーなDBってUnicode対応してないような。

PostgreSQLはUnicodeを扱う為の機構があるよ。
Oracleでも使えるっぽいけど、これは使ったこと無いから知らない。


>自分で変換表作らなきゃならないのか！？まじ！？

自分で作るのはやめれ!。よけいに混乱してしまう〜。

obsoleteされたので良ければ、まだgetする事はできる。
http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/

↓は実際の各社の実装を調査した例。
http://www.autumn.org/etc/unidif.html
http://www.asahi-net.or.jp/~hc3j-tkg/unicode/

どれ使うのもUnicode 3.1.1以降に準拠するなら自由だけど、
とりあえず自分の使ってる環境に合わせておくのが幸せそうかなぁ。

そのうちUnicode変換ソフトにはベンダ指定のオプションできたりしてね :(

↓ベンダ別変換表あった
http://www.unicode.org/Public/MAPPINGS/VENDORS/

ごちゃごちゃ言ってもしょうがない問題ってのはあるんだよ。
こんなのが技術問題だと思ってる厨なのかな?

2ちゃんねるってのはそういうことを
ごちゃごちゃ、うじうじ言うためにあるもんだと思ってたよ。

>>578は十年後にごちゃごちゃ言い始めるに一票

>>580
その前に、業界からリタイアしてるだろ（ｗ

（俺も十年後は分からんが）

>その前に、業界からリタイアしてるだろ（ｗ
そんな無責任な事だからどんどん問題が複雑化していくんだよ。

おい、お前ら全滅して下ちい。

>>579
ふふふ、そんなもんだろうよ。
青臭い事をうじうじ言ってるのはさぞ楽しかろう。

気になったんだけどもさあ、
左右反転とか回転とか結合とかで文字を表すのって、
結局はもとにするグリフとの差分や字母グリフの結合で文字を表現してるんだよな。
てことは統合漢字てのはグリフを表現してるわけ？
ガイシュツだったらスマソ。

>>582
業界からリタイアするのは、責任感云々の問題ではないのよ…。
身体を壊すとか精神を病むとか。

（気力でどうにかなるぐらいなら、まだマシ）

>>587
別にリタイアする事に対して言ってるわけじゃないだろ。
現在の文字コードに対する姿勢について言ってるんだろうさ。

↑>>586だった(鬱

精神論はどうでも良いから、文字コードの話しよう Yo!

>>585
統合漢字と合成文字は違うぞ。
なんか勘違いしてない?

>>589
ふふふ、楽しそうだな。

>>576
> そんならヤメちまえって事になったらしい(ｫｨｫｨ

ﾜﾗﾀ!
これでUnicodeの当初の目的の内幾つを諦めることになったのか…

>>574
> こんなところでグチってても何もならないよ。

と言いつつもここで初めて知った事実に
>>574は目を輝かせ今日も眠りにつくのであった。

>>590
>>545-549 あたりの話って合成文字だよね。
これが統合漢字への批判として出ているわけだよね。

asd

>>586
責任感が強い→精神を病む→リタイア

漢字のunifyはコンピュータの外側でやってくだちぃ。

仕事のしすぎで失明してリタイアした奴知ってる。
スクロールする画面を見続けていると網膜を損傷しやすいんだそうだ。
特に強度近視の人はヤヴァいらしい。

>>596
あー、そうともさ、そうともさ。
unify は政治と軍事で行われるのさ。　(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

ってーか、いまのUNICODEじゃ、名前を電子化できない奴が五万と居ると思うがどうよ？
この問題は深刻だぞ。
法律文書から何から総てで困ることになる。

『Win→おもちゃ→糞』？？？

戸籍情報については
記録のためのガイドラインというか実装標準を決めて欲しい気がする

>>599
そんなのの要望に全部こたえるのは無理。
どうせ今だってできないんだし。
XKPでも使ってろ。

>>601
んだんだ。は外道。
外字のハナシは XKPスレでも立てておやりなさいな。>599
(；´д｀).｡ｏＯ（ 599 ﾃﾞｽｶ。　・・・・・　　−・　　−・ ）

600まで来ても不毛なやり取りが続いている。ので、
まずは問題をはっきりさせよう。

まず、文字コードを4Bytesで表すことについてはどうか？
また可変長とするべきか固定長ではどうか？

固定長24bitもしくは32bitでいいやん

>>599
人類50億のうち5万人だけなら無視してもいいんじゃねーの？

>>604
24bitにした場合、残りの8bitは透明度か何かですか？

>>605
はぁ？
メモリに読み込むときは4byteに拡張したっていいし、
24bitレジスタを持ってるCPUなら24bitネイティブでもかまわないだろ
スーファミとか24bitレジスタもってたとおもうし

>>601
(　´,_ゝ`)ﾌﾟ

>>602
おいおい、外字なんて言う糞仕様を無くすためのUNICODEだろ。


32bit固定長、4バイトで世界中の文字列を同じテキストに総て羅列できると思われ。
2・4億もあれば大丈夫だろ。
最大の問題は、文字列処理のオーバーヘッド、記憶領域が従来の２倍。
英語圏だと４倍になること。

多分、アメリカ人が作ると000000がイパーイのテキストになると思われる。
まぁ、ASCIIだけを残して、あとをぜーんぶUNICODEで、って手もあると思うけどね。

>>607 >>316を参照。十数パーセントくらいしか増えない。そうだ。

>>608 意味不明

現在のASCIIコードを
00000000〜0000007fにそのままマッピングすれば0だらけと言うことだと思われ

>>608
圧縮すればディスクのサイズについては問題なく使えそう
公式のラッパー抱き合わせで配布して、UNICODE以前とあまり変化を感じさせないようにするっつーのはどうでしょうか

>>608 >>610 Unicodeはもともとそうだ。なあ不勉強君たちよ。

A領域の最初の256文字(U+0000〜U+00FF)はISO 8859-1 (Latin-1)と互換になっています。
すなわち、最初の128文字(U+0000〜U+007F)はASCIIと互換になっています。

>>612
勉強不足なんていわんでもなぁ、、、
それくらい承知してるよ。
>>609が意味不明とか言ってるから解説してやっただけだよ

不毛も何も、こんな議論最初っから意味無しなんだってよ。
分かれや、ボケども。

メモリ上で処理するときはUCS-4、ファイルに書き出したりネットワークに流すときはUTF-8。文句ある？

>>607
＞おいおい、外字なんて言う糞仕様を無くすためのUNICODEだろ。

だーかーらー「外字のハナシは XKPスレでも立てておやりなさいな。>599 」
と言ったのよ。UNICODE スレでは外字のことは考えないでおきましょう、と。

>>615 この期に及んで二種類使い分けるのか。あとUCS-4ってちゃんと制定されてるんでしょうか。

>>616 外字が本体よりも多くなっちゃうね。なんのためのUnicodeなんだか。

>>617
2種類ってなんですか？
UCS4とUTF8を混同してませんか？

>>618 おっと失敬､ビットシフトしただけなのね。

>>607
>32bit固定長、4バイトで世界中の文字列を同じテキストに総て羅列できると思われ。
そりゃ、並べるだけの空間が空いてるってだけの話だろ。
空間があいてたって、出所不明な文字をホイホイ収録する訳にはいかないんだよ。
そもそも、Unicodeはグリフをエンコードするんじゃないく文字をエンコードするんだ。

そもそも、Unicode = 外字を無くすため なんて発想は何なんだよ。
UnicodeにもPrivate Use Areaってのがあるのを知ってるか?

>>620 Unicodeはそもそも並べるだけの空間が無かったから破綻したと思われ。

TRONコードを見習え。よ。

>>621
Unicodeはまだ21億4740万文字ほどの空間が空いていますが、何か?

なんで、あんな坂村の独りよがりのものに、何をそんなに期待するんだ?
TRONコードだってUnicodeを内包してるし、その他にも突っ込みどころあるぞ。
http://www.kt.rim.or.jp/~tyamamot/charcode/ONTRON.PDF
http://www.horagai.com/www/moji/tron.htm

>>622 へー、それって取りも直さずUCS-2(Unicode)じゃ駄目でした。
CJK統合漢字、統合してスミマセン。ってことじゃん。

別にTRONコードが最高ってわけじゃないけど、
「外字は作らない」って気概がいいね。
Private Use Areaなんてバカじゃないの。

超漢字とTRONコードは別物ね。

>>621
だーかーらー

>>572 にて、
＞それどころか、群がグングン増えていく (当社比)
＞で、いいじゃん！
って言ったのに。　（;´Д⊂ ｳｴｰﾝ

>>624 それはUnicodeじゃないじゃん。
Javaのcharが2bytesなのは、どう責任とってくれよう。

>>625
UTF-8使えばいいじゃん。
UTF-16でサロゲートペアをサポートしてないとかいうのはSunに文句言え。

>>623
そんな、本当に使ってる奴がいるのかどうかも怪しい様な
字ばっかり集めていい気になってるんじゃねぇ。

Unicodeは歴史資料館じゃねぇんだ。漢字の学術研究は他でやれ。

Private Use Area は他の文字コード体系との変換のため *だけ* にあると思われ。

>>628　http://www.unicode.org/unicode/standard/principles.html
The Unicode Standard also reserves code points for private use.
Vendors or end users can assign these internally for their own characters and symbols, or use them with specialized fonts.
There are 6,400 private use code points on the BMP and another 131,068 supplementary private use code points, should 6,400 be insufficient for particular applications.
となっていますが、何か?

>>627 キミはJIS第一水準の漢字しか使ってなさそうだな。了見の狭い奴め。

あんまり使わないから切り捨てる、というのは使えないプログラマの典型だな。
言い訳は「仕様です」かよ。おめでてーな。

シフトJISが古くて使いがってが悪いように、
すでにUnicodeも遺産なのだ。よ。っと。

UNICODEが遺産ならなにかそれに変わる物は？
それとも、文字コードなんてすでに現代では滅んだんですか？

>>630
今時TRONコードとか言ってる方が、よっぽどおめでたいと思われ。

歴史からも解るように、失敗だとわかっていて、
でも突き進むのは間抜けだな。歴史は繰り返すか。
悲しかったよ。いや、プログラマになったことがじゃない。
歴史を学んだことが､だ。

激しく板違いだが、
以前小学生の「なぜ歴史を学ぶのか？」って質問に当時の文部大臣が「戦争を繰り返さないため」なんつーおめでたい答えを返してたな（ｗ

>>634 ぢゃないのか？

>>633
勝手に悲しんでろ。
それじゃなきゃ、おめーが歴史を変えてみろ。

>>635
戦争を行う指導者たちだって歴史くらいは学んださ。

>>631
遺産との共生。　(･∀･)ｨ�`! 　これ、最強。

>>630
まぁな。とりあえず第四水準まで突っ込むのが急務だから、
Unicode でも何でも使うわな。
てか、JIS X 0212 の分も 「シフトJIS」するのか、と。
何を何処にシフトするのか、と、小一(略)

0212といえば、EUCとShift_JISが埋まって自動判別できない罠、はどうなったんだろう。

>>612
そうじゃなくって、
ASCII
UNICODE(4byte)
と２つの標準を使う。
英語圏は今まで通りASCIIで行って、外国語圏の人はUNICODEを使えばいい。
で、そのうち処理性能や記憶領域が馬鹿でかくなるから、ゆっくりとASCIIを
使わなくしていけばいい。これは無期限で。

>>609
圧縮すればって事？
モデムとかZIPとかで。

俺が言ったのはプレーンテキストで扱った場合、のデータ量だよ。

せっかくのネタに>>636みたいなしょうもない突っ込みを入れられてしまった
>>633よ哀れ。

解ってくれるのは >>642 だけだ。

>>640
いや、だから、
「UNICODE(4byte) 」っていうのは
どんな CES なんだ？

>>644
640じゃないけど、なんとなくUTF-32っぽい。

TRONコードとか持ち出すバカもいるし。

>>646
何でバカなんだ？有効な解の1つでは有ると思うが。
主流にはなれんだろうけどな。

画像ファイルみたく交換形式はﾃﾞﾌｫで圧縮かければ？

>>648
全文検索が重くなるから脚下。

>>629
> Vendors or end users can assign these internally for their own
> characters and symbols, or use them with specialized fonts.

「specialized fonts」ってことは、
CJKでunifyされた漢字の「日本版」を入れたりするのか? (w

utf-8-JP, utf-8-KR, utf-8-TW, utf-8-CNとかprivateに作るわけなのか?

ｲﾐﾈｰ

>>637 だが現実を見なかった。

>>641 いや、プレーンテキストの場合は単純に2倍に増える。
しかし世の中プレーンテキストよりもバイナリのほうが多いわけで、
そういう意味で､だ。

>>646 コード体形なんか文字ひとつにひとつのコードを
割り当てる作業なんだから、小学生でもできるから、
優劣なんて無いのさ。でもそれにしてもUnicodeはひどすぎるし、
それを盲目的に実用的だ、と考えてる奴は無責任だ。

使うだけの奴には責任がない

>>それを盲目的に実用的だ、と考えてる奴は無責任だ。
盲目的に批判する奴も無責任だね(ｗ

>>653
> しかし世の中プレーンテキストよりもバイナリのほうが多いわけで、

そうなのか？ テキストは基本的にあプレーンテキストだと思うが。
もちろん text/plain の意味ではなく可読文字という意味でだ。
application/pdf や application/msword や application/x-js-taro の話か？

xMLはsvgzなどの例外を除いては可読文字だしな。

＞633
Shift_JISへ戻れだと。道は一本きりではないか。

>>655 Unicodeが駄目だってことは目が見えなくたって解るよ。

>>656 1MBのテキストファイルなんて普段あまり見かけない。
それが2MBになったところで、HDDが数十G単位の昨今では､べつになんとも。

ディスク領域よりネットワーク帯域のほうが・・・。

1MBテキストを読むのは56kbpsの速度でも追いつかないと思うがどうよ？

しかしそれを2chとかが採用したら鯖がもたんのでは・・・

gzip圧縮があるじゃないか

>>657 「何が見える？」「サロゲートペア」「おまえの目は節穴だ」

>>662 そうそう、圧縮すれば文字コードが16Bytesだったとしても、
1割も増えんよ。モデムでも圧縮してるし。ね。

モデム圧縮って・・・
ISDN/光じゃハードで圧縮行わないし・・・
ADSLは圧縮するの？

>>664
たぶん圧縮してないかと。

テキストの場合：どうせデータ量大きくないから圧縮しない
ビデオクリップの場合：圧縮する意味がないから圧縮しない

圧縮ってMNP5とかV42bisとかだよね

>>647
特定のOSのための内部コードを
VAX とか ACOS とか (富士通の) GS とかでも使えと？
FENICS を挟んだ SAN にも流せと？
ﾜｹﾜｶﾗﾝ

>>666
なーんかさ、思いっきりレトロスペクティブなことを書いちゃったりする人
(うっかりさん) とか、出鱈目を言っちゃう人 (ぽこぽこちゃん) が
多いように思うポ。
たとえば >>663 とか、漏れね。
漏れは (ハードウェアがって言うのを忘れて) B-Plus とか ZMODEM を
思いだしちった。

ごめーん、ADSLのモデムはハードウェア圧縮してないんだね。
すればいいのに。

>>669
最近では圧縮程度はソフトでやってもちっとも負荷にならないし
実際ソフトで圧縮済みのコンテンツ多いからオーバーヘッドばっかりという罠。
jpegとか２ｃｈとか。

>>669
HTTPみたいにapplication layerでやれば、peer to peerで圧縮じゃん?

>>671
アプリケーションレイヤで圧縮する独自プロトコル使えってこと？ (んなわけない)

>>671 いや、やっぱり出入り口のハードウェアでやったほうが良いと思われ。
だって楽なんだもん。

というわけで2Bytesに固執する必要は無くなり、
CJK統合漢字は愚かの至りで、スレ名どおりUnicodeは絶滅すべき。

さあみんなで代替コードを研究しようではないか。
で、まず最初に、UCS-4ってどうよ？全部制定されてんの？

ECUこそ絶滅させてもらいたいものだ。
UNIX界すべてをShift-JIS化してほしい。

>>673
UCS-4⊄Unicodeですか?

>>675
Unicode⊂UCSだ。↓でも見て勉強すれ。
ttp://www.d2.dion.ne.jp/~imady/kcode/kcode_ucs.html

とりあえず内部形式はUCS-4、入出力はUTF-8でも使っとき。
非UnicodeなUCS領域ってどのくらい定義されてるの？

>>676 もはやUnicode=UCSです。(by UTF-32)
http://www.unicode.org/unicode/reports/tr19/tr19-9.html

>>677 少しづつだけど文字が入り始めてます。10000以降を見てね。
http://www.unicode.org/charts/PDF/

場当たり的に文字群追加してって Extension B とかやるのやめてほしい。
何をもって「拡張」なのか。ただ見落としてただけという噂が。

>>677 どっからを入出力とするよ？

10000以降の領域を使って国別とかに整理し直されることはないの？
現状のコードマップには不満はないの？
主にサロゲートペアとかの問題？

ファイルまたはネットワークへの「入出力」。

あーやっぱとTRONコードがいいわ。
いまざっと読んだところ。というかほかに無いだろう。
Unicodeも包括してるし。

2F901の「海」と6D77の「海」はどう違うんだろう・・・。
さんずいの形状か？？

>主にサロゲートペアとかの問題？
サロゲートペアはUTF-16の時だけの問題なので、
元々全領域を指定できるUTF-8とかUTF-32を使えば問題ない。

UTF-8の問題点は、英語圏以外ではバイト効率がやや悪くなる事。
UTF-32の問題点は、英語圏でのバイト効率が悪くなる事。
UTF-16の問題点は、サロゲートペアを使っても0x0010ffffまでが精々な事。

>10000以降の領域を使って国別とかに整理し直されることはないの？

もう16ビット(UCS-2)に押し込む事をあきらめたんだから、
10000以降の領域は考えを改めて欲しいよねぇ。

>>685
バイト効率が悪くなるって、8ビットや16ビットと比較した場合だろ。
もともと32ビットのUCS-4を基準にして見れば問題なし。

iso-2022の問題点は、多言語といってもCJKぐらいなのと、日本以外では殆ど使ってないのと、ESCの煩雑さ。
TRONコードの問題点は、文字の追加が坂村ちゃんの気分次第なのと、実装の少なさ。漢字圏以外の文字に関してはUnicodeに頼り切りってのもあるなぁ。

どうせ日本で色々考えても、国際的に使われる訳が無いんだから、Unicodeに必要な漢字を追加させろよ。
TRONコードになんか拘っても、ネット環境が改善される見込み無し。

同感。ＯＳがUnicodeじゃ意味なし。

ところでＯＳＸのコードって何？

>>688
(ﾟДﾟ)ﾊｱ?

TRONコードは枠だけつくって内部定義はこれからやっていこうね。
って話だろ？
さらっと読んだ限りでは。
まぁ、国が金出すなりなんなりやって、さっさと決めちゃうべきだとは思うけどね。
ボランティアとか言ってたら7〜10年はかかるよ。きっと。

>さらっと読んだ限りでは。
どこを、ざっと読んだの？（ｗ

TRONコードの内部定義は、ほれここ。
http://www2.tron.org/troncode.html

TRONに国費投入すんのか！！？（−д−；
いっそ凍結でいいと思うがどうよ。

TRONって、昔変なキーボードとか作ってた連中だよね？
一般人には「８ビット時代の遺物」ってイメージが。

>>691 他にすでに17万文字を割り当ててるコード体系はないだろう。

>>639 JISコードをTRONコードに置き換えてもらいたいものだな。

>>694 イメージで技術を語るな。

学者は生産しないと思われ。

>>696
君はI-TRON以上に普及したOSを生産したのかね？

実際に生産したのは学者じゃなくて会員企業だろ。
立派な枠組みを作ってもカタチにできなきゃただのゴクツブシだよ。
今や「ゲイツ様に実装していただかない限りTRONコードの普及はない」と思われ。
あー、寒気がするわ。

>>698 そうだ。問題はそれだ。良くも悪くも Windows に乗らないと普及しない。

いや、コードなんてどうでもいいけど、
いまだってWIndows標準はUnicodeもしくはシフトJISだけど
EUCとかJISも使えてるし、

問題は文字幅をどうやって4bytesにするかだ。

これからは 1byte = 32bit と定義しよう。
これですべて快傑。

>>700 いあ、何も怪傑してないぞ。おもむろに。

>>386 が結構よさそうだが、どうよ。約６７００万が確保できる。
ASCII コード(0-127)は今まで通り１バイトで記述できる。

例えば、
xxxxxxyyyy = iso-2022 の登録番号とか
yy = 予約（とりあえずゼロ）
aaaaaaa:bbbbbbb = コード番号

フォント作成が面倒なら、これにフォントフェイスマッピングを作って、
表示だけunifyしてください。必要な人が表示できれば問題ない。

せめて「言語」「スクリプト」の区別をしたいが、大変だろうからせめて言語だけでも区別できる方が吉。

以下は自己主張なので無視ってください。

規格を作る人は、人は見た目にこだわることを意識して欲しい。
理想論で言えば文字の意味で区別、だけど、それでは世の中通用しない。
日本語だけで言えば、文字セットはグリフも定義すべき。
#意図的＆間違いで登録した戸籍の造語等はどうでも良いけど。

つまり、厳密に定義しておいて、足りない場合は諦めて別の字を使え、
そういうことを意識的にしておいた方が良いのではないか、ということ。

>ところでＯＳＸのコードって何？
Unicodeです。
http://www.apple.co.jp/macosx/upgrade/specs.html

>>699
EUCって、どのEUCだよ？
JISって、どの文字セットだよ？
ていうか、CCS なのか、それとも CES なのか？

WindowsなんだからJISというよりもCP932なんじゃ。
>>699 はeuc-jpとiso-2022-jpの事を言っている様な気がする。

>>705
　 ∧_∧ 　　　なるほど！　
　(　・∀・)　ﾆﾔﾆﾔ

現状のUCSの文字のマッピングって、「US-ASCIIしか含まれないUTF-8文字列」を
「US-ASCIIとして解釈するソフトウェア」に通しても問題ないようにしてあるん
だよね。

でも実際には「US-ASCII領域外の文字が含まれるUTF-8文字列」が渡されることも
あるわけだから、きちんとUTF-8として解釈することが求められてる。
UTF-8文字列を無理矢理US-ASCIIとして解釈できることの意義は薄いと思うがどうよ？

だったら互換性のために￥をバックスラッシュの異体字にしたりしないで、
通貨記号をバラバラの位置に配置したりしないで、きちんとまとめちゃえ、
って話にならない？

>>707
「US-ASCII領域外の文字が含まれるUTF-8文字列」が渡されても、
特別な文字と解釈せず無加工で8bitを通すなら誤動作しないってソフトなら、
多いって事でしょう。
「UTF-8文字列のUS-ASCII領域の文字」は特別な文字と解釈される事が多いので、
UTF-8文字列を無理矢理US-ASCIIとして解釈できることの意義が強いって事だな。

例はhtmlfileだ。対応してないブラウザでも見る可能性が高い。
US-ASCIIとして解釈できないと、文字が化けるくらいで済まず、誤動作するぞ。

>>684
旁の下側が、2F901は「毋」、6D77は「母」。
PDFファイル中の「≡」は異体字と繋がっているようだね。

ああそうか。てことは日本語の「海」は2F901ってことね。
でもさんずいの形状が違うか。

>>707
￥ってバックスラッシュの異体字け？
バックスラッシュ：005C
￥（半角）：00A5
￥（全角）：FFE5

通貨記号・・・いちおう 20A0-20CF Currency Symbols ってのがあるんだけどなぁ。最初考えなしに配置された記号はそのままになってるなぁ。直せばいいのに。

ってーか、TRONコードが使えるCコンパイラが必要だろ。
Windowsはあまり関係ないよ。
自前の変換エンジン持てば良いんだし。
ッてーか、ここにいる連中プログラマか？
4byte化しても、容量増えねーとかパフォーマンス変わらねーとかマジレスしてるし、おめでてーな。
1･2byte charで扱うってのか？マジでおめでてーな。

> ってーか、TRONコードが使えるCコンパイラが必要だろ。

そんなんperlで適当にプリプロセスすりゃいいじゃん。

ってーか、お前プログラマか？

>>711
Cソースなど、円記号をバックスラッシュの意味で使うことがあるので、
￥と書いてあってもバックスラッシュのコードをあてなければいけないことは
よくある。という理由から半角￥記号をバックスラッシュの異体字として、
さらに半角￥記号と全角￥記号が用意されてる。
だからフォントによっては￥記号が３つある。

「異体字」という表現がマズかったかな？

それって、コンパイラが吸収するべき違いな気がする。
Unicodeを食わせられるコンパイラなら、バックスラッシュと同じと見なす文字をシソーラス検索すれば良いのに、変なコード変換と変なフォントを用意して、問題を複雑にしてるだけ。

>>715
違いをコンパイラが吸収するなら、バックスラッシュを使ってるソースと
￥記号を使ってるソースが混在するんだよね。

日本語キーボードにバックスラッシュキーをつけて、他コード体系からの
コンバートの場合にはシソーラス検索＆ダイアログ表示で区別を徹底させるとか。
＃￥記号使ってもコンパイルエラーにはならんので結果として大変なことになるか・・・。

この問題を解決するためには、
まず「円記号をバックスラッシュの意味で使う」という悪習をなくすべきでしょう。
そのためにはまず、日本語キーボードにバックスラッシュキーをつけて、
文字コード変換を行うソフトウェアは自動判別とダイアログで対応する。
たとえばダイアログ対応する必要のありそうなのは、「￥￥」など。
この場合バックスラッシュを表示したいのか￥記号を表示したいのかが
不明である。
ダイアログ対応が必要となることが最大のネックかもしれない。

個人的にはハイフンとマイナスも区別してほしいところ。
こっちはテンキーのほうをマイナスとみなすとか。

>>712
TRON と一緒に使うためのCコンパイラ、見たことも想像したこともないんか？
Windows については「自前の変換エンジン持てば良いんだし」って、
CCS と CES のどっちについて言ってるつもり？
おめでテーナ。

　 ∧_∧ 　　
　(　・∀・)　ﾆﾔﾆﾔ

オイオイ、ちょっと見てなかったが、未だにTRONがどうしたとか言ってるのか？
いいかげんにしろ、クズども。

アフォが略語出していい気になってる様だな。
CES Character Encoding Scheme 符号化方法
CCS Coded Character Set 符号化文字集合

>>720
しかも、ほざいている奴の大半はプログラム組んだこともないエンドユーザという罠。
良くてVBレベルという罠。

どうせ、ASOIIとかそういう雑誌読んで、片言の知識でガタガタ言ってるだけだろ。
案外、ただのシステムアドミンだったりとさ。NTの。(ｗ

>>721
VBを「良くて」って言っちゃう罠に虜。
ﾊﾞﾘｱﾝﾄ型 (;´Д｀)ﾊｧﾊ

\（円記号）は半角ですか全角ですか？
全角ならIMEにまかせれば。と素人考え。

>>713=アホ

>>723
ﾊﾝｶｸです。とマジレスしてみる。

>>723
しかも会計計算用C programの実装ドキュメントです。

Unicodeの場合半角全角は区別するんでしょうか。
っていうかあるんでしょうか。
フォントはビットマップだからかんけいないのかなあ。
でもUnixもあるしぃ。

>>727
FULLWIDTH シリーズがあるので半角と全角の区別はあるでしょう。
たしか他の文字コード体系との変換用に、どの文字が半角でどの文字が全角かと
いうリストのようなものがあったように記憶しています。

その文字が全角か？半角か？は言語依存な罠。(w
たとえば、JIS補助漢字に入ってる欧文の飾り付きのアルファベットは全角だが、ヨーロッパでは普通のASCIIコードの文字と同じ幅。
素直に、JIS X 0201の文字を半角文字として、全て例外にすれば良かったのにねえ。

>>729
そういえばそうだったですね。
ロシア文字とかギリシア文字などもそうですね。
この問題に対処するため、East Asian Width というプロパティが用意されました。
UTR #11 です。

そもそも、何だよ半角全角って。
互換性目的以外に存在する意味無いじゃん

ですので、Unicodeの代替試案を決めてみます。

まずは32bit固定長です。と言いつつ、将来10億文字を操る
少数民族もしくは地底人が現れたときのために拡張用に2bit
取っておいて、実質 30bit = 1,073,741,824 にしたいと思います。

次の方どうぞ｡

730≠728です。ちょっと待ってください。

UTR#11
http://www.unicode.org/unicode/reports/tr11/
と
East Asian Width Properties
http://www.unicode.org/Public/UNIDATA/EastAsianWidth.txt
というのは、それぞれのコードポイントに対して半角か全角かを示すものであって、
同じコードポイントの文字を全角にしたり半角にしたりできるものではないでしょう。

ロシア文字などはUnicodeに変換すると半角になってしまいますので、
Unicodeに全角ロシア文字などが追加される必要があるということだと思います。
＃もしかしたらもうあるのかもしれないけど...

次の方です。
32bitのコードを作って、先頭の8bitをベンダーコード、後ろの24ビットを
文字コードにします。

少なくとも ASCII とは互換性を取ります。ので、

0x00000000 から 0x000000ef までは ASCII です。

次の方どうぞ。

ベンダーコードってなんですか？

次の方どうぞ。

後ろ24ビットの文字コードを作った会社を示す一意なID。

ふつー会社単位じゃなくて、言語、国単位でしょう。

次の方どうぞ。

関西弁と関東弁では使う文字が違うのですが何か?

>>739 その例を示してください。

国コード　　　　　　予約　文字コード
−−−−−−−　−　　−−−−−−−−−−−−−−−−−−−−−−−−
0　　　　　　　　　6　　7　　8　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　31

>>741 国と言語が一致しない場合もありますよ。よく考えましょう。2点

国コードや言語コードを文字コードに埋め込むのは無茶だろ。
国コードに8bit、言語コードに13bit、計21bitは使わないと、問題でるぞ。

結局国・文字セットごとに分類出来ないと〜って不満が出てくるわけだから、
いっそのこと贅沢に１キャラクタ＝64bitにして、
先頭32bitでその文字の属性続く32bitで文字を表現。
全部ビッグエンディアンで統一

これが一番現実的じゃないの？

>>744 それはやりすぎのような気がするけど、
世間は許してくれるだろうか。

国コード８ビットで足りるかな。余裕もって１０ビットくらいはほしい気がする。

そもそも国コードなんでいるのかしら。言語コードだけで十分だと思うけど。

文字のない言語はどうやってサポートするのですか？

国は言語より消滅するのが速いしな

>>744
おまえ、現実的って言葉の意味知ってる？

言語学板にでもスレを立てて問題を大きくしてみようか

>>751
言語学ってそういう学問じゃないと思われ

>>750 おまえって言うな

>>753 話し外れるが、あのコテハン野郎の書き込みを追えば、
文句ばかりの不毛な奴だとありさんでも解るな。
ストレス解消をこのスレでされるのはいい迷惑だ｡

>>748 文字のない言語は文字コードも要らないだろう。

>>748
(;´д｀).｡oO(　IPAだろう？　)

何度かこのスレで繰り返し出てますが、下位何ビットかは異体字情報にしてください…

将来新たな言語(文字)が生まれる可能性を踏まえて
128bit。
これ最強。
ただし誰も使いたがらないという諸刃の剣。

>>758
符号化の話、それとも文字セットの話？

2ch文字セット に 2ch文字コード

符号化方法だけ決められて、文字セットは何も決められないっぽ。

もういっそのこと1bitにしてしまえよ

>>757 それすなわち異体字は別コードに割り当てるってことじゃないかしら。

001111100011111000110011011100110110001100100000101000001010
10001110100000001000001011110001100000101100
01011000001010101101100000101011111010000010
1011001110000010101000101000000101000010

>>763 それだけじゃなくて
異体字ビットをマスクするだけで異体字あいまい検索できるってことでそ。

>>765
それは関数でも作って対応してください。
その方が有用ですから。
きーぷいっとしんぷりゃー。すぬーぴっと。でおながいします。

すぬーぴっとがわからんけど766に同意
異体字ってそんなにたくさんあるの?

>>767
最寄りのサイトウさんへお問い合わせください。

>>765 IMEにおまかせ。

snoop it

妛！とか叫んでみる。

妾！とか叫んでみる。

>>771
有名な幽霊文字だね。

彁暃妛碵駲恷

「妛」と言えば、
http://www.infonia.ne.jp/~nature/kanji/sasahara.html
http://member.nifty.ne.jp/shikeda/kkd4-3.htm

妄！とか叫んでみる。

777get

>>767
"Keep It Simple, Stupid シンプルなままにしておけよ、このマヌケ"

ちゅうしゅつ
http://www.linux.or.jp/JF/JFdocs/history.txt

JAPANESE RECYCLE MARK FOR PLASTIC
≈ ???? SQUARED RECYCLE MARK 30D7 プ 30E9 ラ

JAPANESE RECYCLE MARK FOR PAPER
≈ ???? SQUARED RECYCLE MARK 7D19 紙

>>778
漏れは 767 じゃないけど、
すくなくとも差炉ゲート云々とか UTF-8 とかよりは
ずっとシンプルだと思うな。

# 文字によっては異字体はもっと多かったような。

>>すくなくとも差炉ゲート云々とか UTF-8 とかよりは
それは別に異字体を解決する手段じゃないじゃん。

>>781
＞異字体を解決する手段

そんなことはわかっとります。
異字体情報埋め込んだ文字セット＋円コードの方が、
日本人からみて unicode とか utf-8 ＋ 異字体判別関数
なんかよりずっとマシだという事。
マスクとればいいだけなら面倒な比較関数つくるよりずっと simple でしょうが。
計算量もｏ(1)で済むし。外字の量もずっと減るだろうし。
utf-8 なんぞを推進する理由が既存の ascii only ソフトの問題なら、
別に今までの文字コードでもかまわんと思うが。

訂正
誤>計算量もｏ(1)で済むし
正>計算量もｏ(n)で済むし

ここで n は文字列の長さ。

>>782
始めからそう出来ていたらよかったのかも。
でも、文字セットを作るのは、半端な作業量じゃないし。

JIS X 0201、0208、0212、0213 使ってるのと比べるなら
UCS-4でUTF-8+関数でも手間的には変わらないとおもう。

そんな事より聞いてくれよ>>1よ。
このあいだ、Unicode撲滅スレいったんです。撲滅スレ。
そしたらなんか、全然撲滅してないんです。
で、よく見たら文字コードの事を分かっていない房ばっかりなんです。
もうね、アホかと。馬鹿かと。
おまえらな、撲滅しょうってんならUnicodeの事ぐらい知ってろってーのボケが。
なんか独自の符号化方法考えてご満悦の奴もいるし。誰がそんなの使うんだよ。おめでてーな。
よーしパパ余裕をみて128bitにしちゃうぞー、とか言ってるの。もう見てらんない。
お前らな、文字セット抜きに浮かれているなと。
撲滅スレってのはな。もっと殺伐としてるべきなんだよ。
追いつめられた房がいつコピペ荒らしを始めてもおかしくない、
干すか干されるか、そんな雰囲気がいいんじゃねーか。
分ってない無い奴はすっこんでろ。
で、Unicodeの対抗案としてTRONコードとか言ってるんです。
そこでまたブチ切れですよ。
あのな、TRONコードなんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、TRONコード、だ。
お前は本当にTRONコードを使いたいかと問いたい。問い詰めたい。
子１時間問い詰めたい。
お前、TRONコードって言いたいだけちゃうんかと。
I18N通の俺から言わせてもらえば今、I18N通の間での最新流行はやっぱり、
UTF-8、これだね。
UTF-8ハードエンコード。これが通のコーディング。
UTF-8ってのは漢字圏ではオクテット数が多め。そん代わりASCIIとの互換性が高い。これ。
で、それにUCS-4。これ最強。
しかしこれを頼むとXlibシンパの人間からマークされるという危険も伴う、諸刃の件。
素人にはお薦め出来ない。
まあまあお前らド素人は、SJISでも使ってなさいってこった。

異体字情報を下位ビットにするって意見には、異体字が１対多の構造のみって前提のようだな。
実際の運用である多対多では、無意味だろう。
有名なのとして、濾の略字代わりとして、「シ戸」を使ってる。
本来は「瀘」の略字なのに、使用例はその代用字としての方が多い。
検索時には結局、シソーラス検索せざるえない。
問題が複雑になるだけだろう。

>>786
つーか略字は手書きの便宜のためのものじゃん
文字セットでそこまで含めるべきなのかちょっと疑問。

手書きの違いは文字セットに含めなくて良いなら、人名異字体はほとんど要らないな。

「破たん」とか「ら致」とか「押なつ」とか最近は報道機関が小学生みたいな
書き方してるから、シ戸とシ慮の区別みたいな問題だけじゃないと思うぞ。

家紋も入れてください。

>>788
登記簿があるからダメです。(ｗ

UNICODE逝って良し！
誰が日本の主権を手放すかボケが！

>>791
てか、すでに日本には制空権がないと思われ。
　｡･ﾟ･(ﾉД`)･ﾟ･｡ｳﾜｰﾝ

>>792
うぜーよ。

既に制宇宙権はねぇんだよ。制空権ごときあったって無駄無駄。

ＩＣＢＭは最後の武器だ

>>787
「シ戸」は教科書用例があって0213にも入ってるよ。

>>793
脇道だが国際競争力の話として関連あるから、認識間違いを改めよう。
制宇宙権は実質あるのだ。
たとえば静止人工衛星打ち上げ能力を所有していないと、静止衛星軌道の割り当てがほとんど得られない。
有限な宇宙資源が、今現在の能力で割り当てられてしまうのだ。
金だけ技術だけじゃなく、現実への実行力を持って無いと、国際政治上無視されて、長期的不利益をこうむるのだよ。

>>796
産業とかの問題ならそうかもね。でも、軍事力の話よ。

まぁ、遅かれ早かれ、火星や月の支配権をどうするかって話になってくるしな。
h2打ち上げとかは結構重要だな。

結局どうするんだろ？
月や火星に地球上では稀少な資源が埋蔵されていることが発見されたとして、
その権利はどうするのか？
とか詰めの議論はされて無いっぽいね。
いざとなったら「はじめに行ったのは俺たちだ。それにオマエラじゃ採掘する
技術も輸送する技術もないしな。お話になんないな。まぁ、金出せば現実的な
値段で貸してやらないこともないぞ。（まぁ、貿易摩擦でやばくなったときに
も常にこんな大らかな態度でいられる保証はないけどな。）」とかってならない？

アメリカ合衆国の成り立ちを考えるべし。

国コードとかてIPみたいだな。。。
一つにまとめるのならIPv6ぐらいおおらかにいかないと。

そこまでやるなら「慶應」の中を「K」「O」と書いた略字も入れれ。

>>798
宇宙連邦政府かよ!!

って横道離れ過ぎだからsage

>>800
今昔文字鏡には収録されてたんじゃなかったっけ？

ト゜とか例示しておきながら登録してないな。
ってカタカナ領域もう空きがないじゃん。
鼻濁音を示すカ゜とかもほしいのに。

>>803
そういうのは
309A COMBINING KATAKANA-HIRAGANA SEMI-VOICED SOUND MARK
で文字を合成させることになってるの、きっと。 309C との違いに注意。

>>799
(´ヘ｀;)ﾊｧ?　逆なのでは？
The alpha-2 code elements from ISO 3166-1 are used in the Internet
as the country code top-level domain identifiers (ccTLDs).
http://www.din.de/gremien/nas/nabd/iso3166ma/internet.html

>>803
ていうか、アイヌ語の来し方・行く末については、もうちっと
ﾏﾀｰﾘ話し合いましょうや。

>>800
なんか、そういう造字（？）をあつめたサイトがあったげな。
どこだったっけ？

カ゜は音声合成ソフトなんかでも記述用に使うし。
「がんばれ」の「が」と「私が」の「が」は音が違うでしょ。

古典芸能では「の゜」とかも発音してるよな。

>の゜
どんな音だよ

鼻濁音じゃないのか？

ま゛

ainu-Taimuzu dai 8 go^ ne yakka oro ta asir 20 noka (mozi) a=nuye wa an hine, a=eywanke asir katatana noka (mozi) ene oka hi:
セ°[ce]/　ツ°[tu]/　ト°[tu]/　ク [k]/　シ [s]/　ス [s]/　ト [t]/　ヌ [n]/　ハ [(a)h]/　ヒ [(i)h]/ フ [(u)h]/　ヘ [(e)h]/　ホ [(o)h]/　プ [p]/　ム [m]/　ラ [(a)r]/　リ [(i)r]/　ル [(u)r]/　レ [(e)r]/　ロ [(o)r]/
Inta^netto (Internet) ka ta nerok noka (mozi) ko^do oka ruwe ne.
http://jcs.aa.tufs.ac.jp/jcs/pubrev/codetbl21.pdf
(http://www5d.biglobe.ne.jp/~hel/jp/JOKO/AT14.htm)


JIS X0213:2000 sekor a=ye JIS kikaku or ta aynu itak a=nuye hi ta a=eywanke asir 20 katakana mozi ko^do oka ruwe ne.
ne katakana mozi anak yuniko^do (unicode) 3.3 sekor a=ye kokusai-kikaku or a=omare wa, asir yuniko^do a=kar.
(http://sapporo.cool.ne.jp/kumanesir/AT20.htm)


http://www.unicode.org/unicode/onlinedat/languages-scripts.html
ここ(Languages and Scripts)には、
「アイヌ語 (日本で使われる) は、カタカナかラテン文字で書け　(ﾟдﾟ) ｺﾞﾙヮ」
みたいなことが書いてある。

デファクトスタンダードってのは力ずくで標準を決めちゃうの。これ最強。
でもUnicodeはみんなで話し合って一応納得いくように、
という弱気だから正論には弱くって、どんどん最終防衛戦を下げて行ってるの。
MSやIBMあたりが、勝手に使い勝手が良くてマイナー言語/用法を切り捨てた
文字コードを作ってくれたら、正直楽かもしれないと思う今日この頃。

>>811
強気だろうと弱気だろうと、そんなのは関係ない。
デファクトといって五里押しできるのは市場が拡大している開拓時代だけ。
成熟期には無理。独禁法があるからね。
時代背景も踏まえずに適当なこと言うなよ。
１０年前のソフト市場なんて大したこと無かったんだから。もっぱら、
「大もうけするならハードウェア、かハードとセットの抱き合わせソフト」
って時代だったんだし。今ほどパッケージソフトで儲かる時代じゃなかったんだよ。

力づくでというより、独自規格を採用したＯＳが普及することで知らない間に
スタンダードになってるってのが正しい。いわば「サブマリンスタンダード」。

DiskBASIC は JIS コードだったのに DOS-BASIC は シフトJIS だったよな。

日本の携帯電話はSJISモドキなのでSJISがスタンダードとなります。

ｺﾄﾞﾓも採用するとかいうWAP2.0はどうなってんの？
XHTML-MP 使ってもShift_JIS以外だめ？

>今ほどパッケージソフトで儲かる時代じゃなかったんだよ。
そうやって、あぐらをかいていたからMSに根こそぎもっていかれちゃったんだよね。

>>816
いや、一太郎、Lotus-1-2-3などパッケージで頑張っていたところもあったけど、
やっぱOS押さえているところが強いじゃん? って状況、まだ。

だって、OS version upした時に、起動できなくしちゃうんだもんね…

JustSystemはそれにムカついてすべてをActiveXコンポーネントにしたという（ワラ

そうそう。そういうアンフェアなことをしてシェアをのばしてきた。
昔一太郎＆1-2-3モデルとWord＆Excelモデルがあったよな。
漏れは一太郎＆Excelがﾃﾞﾌｫなのに。
それだって一太郎モデルにはMS-Officeを入れさせないという圧力があったから。

ＯＳ持ってるとこは強いけど、それを利用したらフェアじゃない。

>>811
＞デファクトスタンダードってのは力ずくで標準を決めちゃうの。これ最強。

世界中の文字をスパッと符号化できる人なんかいない。
というのがこの問題の核であって、
標準化の一般論を語ってみても意味がないという罠。

じゃあ勝手にワナワナ言ってりゃいいさ。
俺は断じて長い物に巻かれるからな！ざまあみろ！
お前等は敗北主義者だ。

Javaって main()を使えるの?

>>822
public static void main(String[] args)
は使えるが。ネタか?

誤爆？

>>ＯＳ持ってるとこは強いけど、それを利用したらフェアじゃない。

PC向けに使えるOSを供給してた会社なんて当時MS以外にねーじゃん。
PC市場を軽視してたからだね。だからあぐらかいてるって言ってるんだよ。

>>825=経営のけの字も知らない馬鹿＆政治のせの字も知らない馬鹿

>>825
それまで他社がPC市場を軽視していたわけでも何でもなく、
そのころ(MS-DOS2.1当時)のPC用のOSはOSというよりシステムシェルとでも言うべきもので、
一般にはエンドユーザに販売する性質のものとは見なされていなかった。
それよりもアプリケーションの充実のほうが急務だった。

その一方、MS-DOS2.1までパッケージへの同梱を黙認することでエンドユーザに
普及したとたん、ライセンスを課すようになった。

>それまで他社がPC市場を軽視していたわけでも何でもなく、
じゃあ、どうしてWindows3.1が出た頃に入ってこなかったんよ。

>その一方、MS-DOS2.1までパッケージへの同梱を黙認することでエンドユーザに
>普及したとたん、ライセンスを課すようになった。

別に問題ないでしょ。2.1が使えなくなる訳じゃないし。

>>828
> じゃあ、どうしてWindows3.1が出た頃に入ってこなかったんよ。
そのころには既にPC用OS市場ではMS-DOSは独占状態にあった。
実際、OS/2などの他社OSもあったが、
MS-DOSで築かれた独占は崩せなかった。

> 別に問題ないでしょ。2.1が使えなくなる訳じゃないし。
一旦独占状態にはいってユーザを囲い込んだ後でのMSの方針は
DR-DOSの件でもわかる通り、非常に攻撃的だった。

>エンドユーザに販売する性質のものとは見なされていなかった。
やっぱこの辺の先見性の無さが問題なのでは?

>>830
OSをソフトとしてエンドユーザに販売するものではなかった時代
という意味だと思うよ。
ソフトはハードのオマケだった時代。
しかも、漢字ROMとゆーものが跋扈していた時代。

致命的なバグでもないのにヴァージョンアップで仕様を非互換に変更して、
しかもドキュメントはろくにしない。その上、隠し機能があって、自社だけ
有利にするというのは、 OS メーカーとしていかがのものか。

# DOSのころは、文字を表示させるのにも公開されたファンクションコール
# じゃ遅いから、マジのときはメモリに直書き、そうじゃなきゃ未公開の
# ヤツを使ってたよねぇ。

>>811
> でもUnicodeはみんなで話し合って一応納得いくように、
> という弱気だから正論には弱くって、どんどん最終防衛戦を下げて行ってるの。

最終防衛戦を下げて行ってないじゃん。
つーか、みんなで話し合ってる、W3CとかRFCとかでも、
そんなことは起こってないぞ。

どうでもいいスレになっっっってきたな

>>833
utf-16 とか、utf-8 とか全部妥協の産物でしょう。
最終防衛線が 16bit のキャラクタセットで符号化番号一致
だったらまだ楽な文字コードだったのにね。日本人的にはもう使う価値無いよ。

もしかすると、味を占めたアメリカあたりが、
UCS-4 をまた糞コードにするんじゃないかと思うとぞっとするね。
# 大衆文化ってのは案外楽に変えられるもんだからな。
# 文化の主導権を競争相手に握られたら負けだね。（既に負けてるけど）

>>835

＞最終防衛線が 16bit のキャラクタセットで
Unicodeの「キャラクタ」は今でも「定義上」16bit。

＞日本人的にはもう使う価値無いよ。
で、何を使うと？

＞もしかすると、味を占めたアメリカあたりが、
＞UCS-4 をまた糞コードにするんじゃないかと思うとぞっとするね。
UCS-4は、すでにUTF-32と同じ。

＞＞最終防衛線が 16bit のキャラクタセットで
＞Unicodeの「キャラクタ」は今でも「定義上」16bit。
だから何？

＞＞日本人的にはもう使う価値無いよ。
＞で、何を使うと？
外部とのやりとりならまだ shift_jis or euc-jp or iso-2022 で十分。

>>836
UCS-4 は CCS,
UTF-32 は CES なんじゃネーの？
違うかな？

>>838
そだよ。

でも、こゆこと。↓
Until the formal balloting is concluded, the term UTF-32 can be used to refer to the subset of UCS-4 characters that are in the range of valid Unicode code points.
After it passes, UTF-32 will then simply be an alias for UCS-4 (with the extra requirement that Unicode semantics are observed).

>>837
＞外部とのやりとりならまだ shift_jis or euc-jp or iso-2022 で十分。
「まだ」を言い換えれば、
「Unicodeが普及途上にある現状では」ってことだろ。
「『もう』使う必要がない」という主張（>>835）の論拠にはならない。

>「『もう』使う必要がない」という主張（>>835）の論拠にはならない。

はぁ？使う価値が無いと言ったんだけど。
嫌でもほぼ強制的に使わされるだろう。

>>841
落ち着け。意味判らんぞ。

>>842
漏れは >>835 で
>もう使う価値無いよ
とは書いたが、
>「『もう』使う必要がない」
なんてのは書いてない。

価値と必要は別。
嫌でも使わないとだめなら、少なくとも漏れにとっては
それは必要はあるけど価値はないっつーこと。いじょ。

あーまた揚げ足取りがでるかもしれないのでもう一言。
価値という言葉がわるかったかもしれないので、
魅力あたりに置き換えて読んでくれ。面倒なので終わり。

まあ、普通の人は国内の文字セットさえ、問題無く使えれば、必要充分だわな。
Unicodeは過剰な文字セットでしかない。余計なリソースを要求される分は魅力が無い。
でも、今時国内専用プログラムだけって訳には行かんよ。
とりあえずだろうが仕方なくだろうが、他に代替文字コードが無い以上、結局使うだろ。

外国で作られたソフトをいちいち日本語通る様にするのって面倒じゃん。
Unicode対応で作られていれば、改造しなくても日本語通せそうなのは魅力。

>>846
そう簡単にいくといいけどな。

無理だな。
メリケンは余計なことが好きだから勝手に上位のビットをマスクしたりするだろう

>>847
禁則処理とかは無理だと思うけどね。

>>848
Encording方法は規格化されてるんだし、
わざわざそれを曲げるような事はしないと思うけどな〜。
ライブラリの機能をわざわざ殺すかな?

禁則処理は・・・Unicode Line Breaking Algorithmってのがあったはず。あれを実装すれば・・・でもやらんだろうなぁ。

>>845
おいおい、JIS X 0212 補助漢字 は、どーすんのよ？

>>851
Unicode 3.2では JIS X 0208、JIS X 0212、JIS X 0221、JIS X 0213を併合したものになっているので補助漢字も使えますよん。
http://www.unicode.org/unicode/faq/han_cjk.html#0

暇人の挙げ足取りはどうでもいいYO。
そう、結局使っていくんだから。

英語のソフトを使ってると
「ああ、Unicode化しといてくれればなぁ」
とか思うときがある。
まあ、Unicode化しても、日本人としてまともに使えるかは
また別問題だろうけどさ。

結局絶滅不可能ってことで終了しろよ。

>>855
終了しないと不都合なことでもあるんかいな。

>>856
ということにしたい人発見!

unicode使う日本人はガイキチ

>>858
坂村健先生、お久しぶりです。

>>859
病院行った方が良いぞ。

>>860
村井先生、だいぶ恰幅がおよろしく…

unicode 良いじゃないですか。
その前にJEFコード及びEBCDICを消滅させてくれ。

その前に>>862を・・・

UTF-16LEを使う意味って何よ？

>864
日本語コードをUTF-8より少ないバイト数で表現できる＆インテルへの配慮。

UTF-8と同様の8bit単位で読み書きするルーチンを用意しておけば
UTF-16LEなんか使わなくていいような気がするんだけど、
8bit単位で読み書きしたくない理由、
またはファイルコードがLEでなきゃいけない理由ってある？

おい！お前ら。
日本語のコードの種類を教えてください。おながいします。

>>867
>>1

>>866
> UTF-8と同様の8bit単位で読み書きするルーチンを用意しておけば

そんなの使いたくないから、UTF-16LEがあるんでないの？
つーか、UTF-8と同様のってなんだ？

>>866
BEよりLEのほうが自然

>>870
どう自然なの？
みんな頭の中でひっくり返して考えているんじゃないの？
ダンプ読むときとか。

UTF-16LEならlittle endianのunsigned shortとして扱えるから便利。

intel以外ではlittle endianが不便

UTF-16BEならbig endianのunsigned shortとして扱えるから便利。

intelではbig endianが不便

文字数を数えるのにパーズしなきゃなんないなんて最低

wintelマシン使ってない俺にとってはLEなんてクズの思想にしか思えない

big endianのマシンは int>char キャストの負荷が高いから糞だ

激しくスレ違いの予感

>>878
メモリ上なら３バイト目
レジスタ上なら最下位バイト

どう負荷が上がるのか分らん(;´Д`)

>>879
ad hocな仕様を頭に入れて考える負荷じゃないの？

ad hoc 略して アホ。

>>879
バスエラーって知らんの？

>>880
プログラマの動作クロック数が低いってこと？

>>882
任意のアドレスから１バイト読めないプロセッサって
Alphaぐらいなんじゃないの？

>>884
DECｱﾎﾞｰｿ
(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

> 任意のアドレスから１バイト読めない

ああ・・・そういうことか・・・(;´Д`)
ワード境界跨るわけないのに何でだろうかと思ったが
そういうのもあるのか・・・

>>883
厳密にはプログラマのクロック数と実行速度の比が大きくなる仕様だな。
レジスタ馬鹿食いのプログラムだ。

1000までネタスレかよ
おめでてーな

>>882
big endianだけbus errorが起きるのか?

とりあえず書いておくと普通漏れらは普段インデックスが左から右に大きくなるようにメモリをイメージしてるわけ。（これをLTRと呼ぶことにする）
バイナリエディタとか、どれをとってもそうでしょ？
ところが数字の表現はRTL,つまり右から左へ増加する、これが諸悪の根源。
数字もLTRで表現すればLEで書くのが最も自然になる。

数字LTRでDWORD(4BYTE)を書いたとき、LEの場合、全てが左から右に向かって増加する方向に書けるので最も自然

0bit目
↓　　↓7bit目　　　　　　　　　　↓31bit目
11111111 11111111 11111111 11111111
↑0BYTE目↑1BYTE目↑2BYTE目↑3BYTE目
↑0WORD目　　　　 ↑1WORD目
↑0DWORD目　　　　　　　　　　　　　↑1DWORD目

数字RTLでLEの場合、ビット順に反転が生じて不自然
7bit目　↓15bit目
↓　　↓0bit目　↓8bit目
11111111 11111111 11111111 11111111
↑　　　 ↑1BYTE目
0BYTE目
↑0WORD目　　　　↑1WORD目
↑0DWORD目　　　　　　　　　　　　 ↑1DWORD目

数字RTLでBEのとき
　　　　　　　　　　　　　　7bit目
↓31bit目　　　　　　　　　↓　　　↓0bit目
11111111 11111111 11111111 11111111
↑3BYTE目↑2BYTE目↑1BYTE目↑0BYTE目
↑1WORD目　　　　 ↑0WORD目
↑0DWORD目　　　　　　　　　　　　 ↑1DWORD目

bit/BYTE/WORDは左から右に減少する順なのに、DWORDは増加順になる。
同じビット列をWORDデータとしてみた場合はWORDが増加順に、
BYTEデータとしてみた場合はBYTEが増加順になる。
激しく不自然。

ところで、ここまで書いててふと思ったんだけど、
漏れは最下位bit=0bit目とイメージしてるんだけど、
BE派の人たちってもしかして最上位ビット=0ビット目、って言うイメージになる？

激しくずれちっち（´Д｀；）

>0bit目
>↓　　↓7bit目　　　　　　　　　　↓31bit目
>11111111 11111111 11111111 11111111
>↑0BYTE目↑1BYTE目↑2BYTE目↑3BYTE目
>↑0WORD目　　　　 ↑1WORD目
>↑0DWORD目　　　　　　　　　　　　　↑1DWORD目

Little Endianの場合って思いっきり変態的に、下のようなイメージじゃないか？
7bit目
↓　　↓0bit目　　　　　　↓31bit目
　　　　　　　　　　　　　　　　　↓24bit目
11111111 11111111 11111111 11111111
↑0BYTE目↑1BYTE目↑2BYTE目↑3BYTE目
↑0WORD目　　　　 ↑1WORD目
↑0DWORD目　　　　　　　　　　　　　↑1DWORD目

エディタにコピペで

ネットワークが不可欠な時代なんだから、
PNG にならって Network Byte Order で統一ということで。

ビット列がぜんぶ１なんでわかりにくいんだけど、
たとえば 0x1234 は LE では 0x12 0x34
0001 0010 0011 0100
で、BE では 0x34 0x12
0011 0100 0001 0010
でしょ？　（たしかZ80はBEだったな...）

Network Byte Order は MSB が先だから、
0001 0010 0011 0100
でしょ？

>>892
そうだよ現在の数字の書き方では、BEとどっこいどっこいの変態記述。
んで漏れは890で、現在とは逆方向に書くことを提案（？）してる。
こちらだと激しく自然な記述が出来る。

>>894
LE と BE が逆です。

もしかしたら、ダンプ（というか、メモリイメージ）なども
下から上にアドレスが増加していく方が自然なのかもね。

>>897
数直線で表せると良いのだが・・・。
２次元でも３次元でもちゃんと表せるし。

> > UTF-8と同様の8bit単位で読み書きするルーチンを用意しておけば
>
> そんなの使いたくないから、UTF-16LEがあるんでないの？

でもUTF-16LEがあるせいで、
BEかLEかを判別して変換する処理が必要になるわけで、
結局実装コストが増すことにならんかい？

変な平等主義っつーか、
wintelの「面子」にこだわった結果出てきたのが
UTF-16LEだという気がするのは俺だけ？

>>899
書き出すときのことを考えれば楽だけどね。

IA-32であればLEが有利なのでは？

>>899
＞でもUTF-16LEがあるせいで、
＞BEかLEかを判別して変換する処理が必要になるわけで、
＞結局実装コストが増すことにならんかい？

規格を管理するコストも増しますし。あーやだやだ

UTF-8にBOMを付けるとかいう勘違い野郎も出て来るし。

>>903
Windowsのメモ帳でUTF-8保存するとBOMが付く罠

メモ帳がヴォケの筆頭か。

メモ帳でプログラムのソースコードを書いているﾔｼが筆頭であり最強。

BOMがついてるとまず文字化けしないという副作用的利点があるとかいって
積極的にBOMをつけるヴァカもいるぞ。

UTF-8にBOM(EF BB BF)を付けるとS-JISと区別出来るようになると思ったけど、
EF BB BFはS-JISで1面94区29点の文字(JISX0213で髟の下に會)と半角仮名のｿ
と解釈出来てしまうから駄目だな。

>>903
http://www.fifatickets.com のpageに付いてましたね。

無印のUTF-8は「EF BB BF」（BOMではなくシグネチャと呼ぶ）付きで、
シグネチャのないのはUTF-8Nってことになったんじゃねーの？
と思って資料探してみたけど、
公式のドキュメントで「UTF-8N」が出てくるものは発見できず。
知ってたらご指摘きぼんぬ。＞UTF-8の偉い人

解説の類ならいろいろある。↓とか。
ttp://www-6.ibm.com/jp/developerworks/unicode/unicode.html

>解説の類ならいろいろある。↓とか。
>ttp://www-6.ibm.com/jp/developerworks/unicode/unicode.html

資料古いな。1999年9月の資料だし。
これに限らず、割と古い資料が多いので注意した方がいいかも。

>注: イタリック体の名前はまだ登録されていませんが、参照に役立ちます。

もしかしてボツになったんじゃないの? >UTF-8N

UTFとBOMにかんする公式FAQはこちら。
http://www.unicode.org/unicode/faq/utf_bom.html

・そもそもUTF-8は、バイトオーダーが固定なのでBOMは必要ない。
・IANAの定義には、UTF-8はあってもUTF-8Nは無い。
・Unicode コンソーシアムでは、
　『UTF-8にBOMが含まれても問題無いが、バイトオーダーの変化には影響を与えない。』
　としている。
　http://www.unicode.org/unicode/faq/utf_bom.html#29
・俗世間では、BOMの無いUTF-8はUTF-8Nと呼ばれている。
　(公式にUTF-8Nは定義されない)

ってとこなんじゃネーノ?

このスレまだあったんだーね。
僕の闘いの歴史です。

BOMをエンコーディングによって付けるか付けないかが各エンコーダでマチマチだと、
読んで保存しただけでファイルサイズが増えたり減ったりする罠

>>914
さらに、ファイルの比較では別物とみなされる罠

>>914-915
だからBOMつけるなよ。

>>916
俺らに言われても。メモ帳はBOM付けやがるし。

ボむっ

O次郎ですか？

>>917
メモ帳使うなよ。

>>913
ん？　>>146ってことは漢字廃止論者か？
わたくしの名著『漢字と日本人』を読んで出直してきなさい。

高島ってTRONを持ち上げてたアフォだろ？

TRON
＼○／
　｜
／　＼　　９．８点

根本的な疑問なんだが。
文字コードを統一する必要ってあるか？
一つの文書に多国語で文章書く事ってそんなに有るか？
「文字コード識別+切り替え」じゃ、なんでいかんのよ。
つーか、全世界の文字を一つのコードに集約するのは
どう考えても現実的じゃないだろ。無駄も多いし。
誰か説明してくれ。

>>924
各種アプリケーションのi18nやl10n等、
不毛な作業プロジェクトが大量に発生しているから。

>>925
さっそくありがとう。
だけどよ。それはコードを統一すれば解決する問題なのか？
可変長のコードを扱うようにプログラムを改造するより、
確実に識別出来るコードを作った方が
比較的手間はかからないんじゃないだろうか？

>>926
ISO2022 をフル実装しろと言ってる？　それは議論され尽くしてるような。

>>926
くだらなすぎ。無意味なカキコキ (´-`).｡ｏＯ（ サンペーです ） せずに
勉強汁！

ISO 2022 使うなら、(使うのか？)
「確実に識別」とか言うのはナンセンスだし、
既存のコードを使うには可変長にしなきゃ不可能だろ　(ﾟдﾟ)ｺﾞﾙｧ!!

貴様は逆に UTF-16 使えと言いたいのか　(´・ω・`)ｼｮﾎﾞｰﾝ

文字コード次にロケールが控えてるんだが
最初で躓いてるからねえ

>>929
ロケールもアレだが、
スクリプトも切り替えたいよな。

カタカナ・ひらがなって
ケースの上下みたいなもんだと思うんだがね。

>>926 どうせ可変長コードを使う部分はライブラリの中だからいいんだYO!
ライブラリがあるのに、自前でクソな処理ルーチンを書いてしまうのはアフォの証拠です。

>>926 可変長が嫌ならUTF-32でも使ってろYO!

確実に識別て何？よくわからん

>>933
「確実に識別」を妥当に解釈するなら、「判定ミスを起こさない」ということです。

iso-2022かUCS4(with UTF8)でも使いたいってことか。

>>926
「可変長」ってサロゲートペアのことを言ってるのか？
あんなのは比較的単純な話。
ステートフルであることが問題になるのは、
インド系の結合音節文字とか、
ラテンアルファベットだけでも相当複雑な結合文字の処理だろ。

話の筋と関係ないけど、たまに iso-2022 は grep ができないとか逝ってるやつが居るが、
真面目に iso-2022 で grep しようとするやつなんて居るのかな。
普通内部でコード変換すると思うんだが・・・

unicode で言語タグとか出てきたら結局コンテキスト
見ないとダメなのは似たような問題だな。

lgrepではできるよ。

>>937
言語タグは無視できる、という点が違うけどな。

あれだな、ISO-2022-JP でもエスケープシーケンス無視して grep してしまえば
特に問題なさそうな気もする（ｗ

いっそのこと、ch & 0x7f するか(w

UTF-8

>>941
よし! UTF-7だ!

UTF-6

UTF-1024

組み込み用の64Kbyteのメモリに変換テーブル入れられんかな…。

unicode→SJIS 日本語だけでいいんやけど…。

>>947
UCS-2→SJIS変換テーブルとプログラム作ったけど、不要な部分削って
表引きさせても、50Kぐらい消費する。ヘボくてよければソース出すよ。
SJIS→UCS-2なら、もっと小さくなるのだけどね。

>>948
その変換テーブルはunicode.orgの物？
それともWindows互換？

サイズに関してはそんなに変わらんと思われ。

>>949
Windows用。スマソ。