EUCボクメツ委員会

1 名前：ﾓ･ｸ･ﾍ･ｹ菽ｦｯ [01/10/16 00:18 ID:ZujZqkcr.net] Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。 ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ 意味ないじゃん！ Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。 29 名前：login:Penguin [01/10/16 07:51 ID:XM6EXXtB.net] >>27 EUCとJISに欠陥があるからって言ってた気がする。 30 名前：login:Penguin [01/10/16 08:02 ID:0RDEkWSQ.net] つーかEUCにしろSHIFT_JISにしろ、計算機資源の乏しかった ころの規格だろ。 富豪的コンピューティングでTRONでいいじゃん。 UNICODEもステだな。 31 名前：login:Penguin [01/10/16 09:15 ID:10niM3hA.net] っていうか、なぜEUCにこだわる人ってなぜそんなものにこだわる？ 理想を求めるならTRON-CODE 今現に多く使われているという現状を追認するならS-JIS EUCにはどっちの利点も無い。 32 名前：うひひ [01/10/16 09:21 ID:so9BFYxc.net] むずかしいことイイからよ shift_jisバリバリのLinuxあっても良いんじゃねーか？ shift_jisのUnix使ってると連携わりーんだよな実際。 33 名前：login:Penguin mailto:sage [01/10/16 09:37 ID:Gyb/MKxi.net] >>31 人生に妥協は必要だよ。 34 名前：login:Penguin [01/10/16 09:43 ID:devEzPX4.net] >>31 > っていうか、なぜEUCにこだわる人ってなぜそんなものにこだわる？ m17nに有利だからだろ。 35 名前：login:Penguin [01/10/16 11:47 ID:W81ZfPKp.net] >>29 ﾊｧ? 逆だろ。 まず ISO-2022-JP があって、モード付きのエンコーディングだと プログラムが書きにくいから ShiftJIS が作られた。 でも ShiftJIS は半角カナを 1 バイトの領域に入れてしまったために 一部の記号と日本語のコードがダブってしまって、それを例外として 処理する必要があった。 その辺を教訓として EUC-JP が作られたから、日本語と英数字の 領域は完全に分離されていて最も扱いやすく、I18N に有利である。 36 名前：続き [01/10/16 12:51 ID:7rh/WYyT.net] 結果、半角カナは2バイトで、外字は3バイトである。 文字コードの何たるかを考えた事もない ヘタレプログラマにはただただうっと惜しいだけであった。 37 名前：login:Penguin [01/10/16 12:50 ID:uARHilua.net] >>35 なんか違うぞ ISO-2022-JP はそれまで慣習として通信で使われてた7bitJISコード (ISO-2022にそこそこ準拠)を、fj.* と Internet Mail で使うものとして、 制限つけてRFCとして書き起こしたものだ。名前に反して実は ISO-2022 に 正確には準拠してないのは有名だ。7bit JIS としてなら歴史はあるが、 まとまったのは一番新しい。 まあ、たぶん言いたいことは「ISO-2022 が先にある」ってことなのだろう。 それなら正しい。 ShiftJIS は、Microsoft社が MS-DOSに日本語を導入するにあたって、 半角カナを残しつつ漢字コードをわりこませるためにASCII社に作らせた もんだ。変態的な変換で気持ち悪いことと、当時既にあった国際規格の ISO-2022を全部無視したこと以外はそんなに悪いコードじゃない。 いってる通り、不幸の文字があるので、ASCII処理前提でかかれていた コードは全部書き直しの憂き目にあったのはそのとおり。 んで、EUC-JP は別にそのあたりを教訓にしたのではなくて、 UNIX の国際化を行うにあたって、普通に 8bit 版 ISO-2022 の使い方を日本語用に確定しただけのものだ。これは当時国内でUNIXを 作ってたメーカが、既に同等の手法で自社UNIXを国際化してたのが 細部が異なってたのを統一する形でつくられた。 ISO-2022 のままだと、ステートが爆発するので扱いにくいのは事実。 でも、SJIS と EUC-JP では、正しくまじめに国際化するのなら、質的 には有利/不利の差は存在しない。 ただ、世の中には、「ascii依存」なソースがあまりに多い。で、EUC-JP の 場合、コードが重ならない関係で、8bitスルーにさえなれば、日本語が 壊れず通ってしまう。こういった「手抜き国際化」は EUC-JP のが やりやすいのは確か。 ちなみにこの条件は UTF-8 も同じだ。だから、最近のあちらさんの アプリケーションはこれで処理したがってる。ソースをあんまり 修正しなくて良いってことね。 UTF-8 は、互換性は目をつぶるとしても、日本語だけを扱うとしたら パフォーマンスが悪くなるのと、通信量が膨れ上がるのが欠陥 (漢字は6byteになる)。まあ、マシンパワーの向上が全て解決すると いわれればそこまでやね。 38 名前：21 [01/10/16 14:42 ID:aWaNxseP.net] >>23 ＞同じ文字とは何か？定義してないから、 ＞databaseやgrepで困ると思われ これは運用の問題だろ？ 斎藤と斉藤と齋藤を区別したいときもあれば同じに扱いたい時もある。 なら別々にして必要に応じて変換ライブラリーみたいなの使えばいいと思うぞ。 しかし37読むとEUC-JPかUTFがいいような気がする 39 名前：login:Penguin mailto:sage [01/10/16 15:21 ID:pLM2+efM.net] 不治痛だろ？ 40 名前：37 [01/10/16 15:33 ID:uARHilua.net] 結局のところ、マルチバイトキャラクタな状態ってのは、 文字の区切りがよくわからんところが最大の問題で、SJIS で \ を 誤認してしまうのもこれによる。EUCも、結局頭からおいかけないと、 文字の区切りはやっぱりわからん。 てっとりばやくこれを処理するには、ワイドキャラクタ化してから処理 してしまえばよいことになる。この場合、EUCだろうがSJISだろうが関係なくなる ただ、これをするにはアプリケーションを全部 wchar 用に書き直す必要が あって、めんどくさがられてる。その点、UTFは、EUCとかと違って、文字の 区切りが一発でわかるようなエンコーディングなんだな。 今見てる場所から、「前の文字」「次の文字」がわかるようになっている。 基本は char のままで、文字処理するとこだけ細工いれればよいので好まれるわけ。 ちなみにこれには罠があって、Unicode がホントに Unicode なら 問題なかったんだけど、Unicode　って Unicodeだけでマルチバイト文字 になるので (UCS2/UTF-8 で複数のコードで1文字になる複合文字がある) そういった文字を扱おうとすると一瞬で破綻してマルチバイト時代に逆戻り。 まあ、欧米の人はこれでこまらんのだ。そんな複合文字なんてつかわんから。 日本人は無縁じゃないぞ。濁音は、処理次第では2つのコードに分離するのだ… 41 名前：login:Penguin mailto:日本人 [01/10/16 17:54 ID:dew/Ir09.net] マルチバイト文字なんか使ううちらが悪い。 外人から見れば英語最高！で国際化なんかやってらんないよ 外人に感謝しよう 42 名前：名無しさん＠お腹へった。 [01/10/16 18:09 ID:h02cohTC.net] SJISを完全に捨てているVineは糞。 って今はどうなの? PJEの頃は少しましだった気がするが.. 43 名前：login:Penguin mailto:sage [01/10/16 18:48 ID:Gyb/MKxi.net] >>41は微妙にスレ違いだな・・・ >>42 完全に捨てているというtと、具体的には？ 44 名前：>>41 [01/10/16 19:21 ID:OnoFABDw.net] >>41 誇りを持て 45 名前：login:Penguin [01/10/16 19:38 ID:q4n1GyJy.net] 情報交換符合と内部表現、 文字セットとエンコーディング、 コードとグリフ、 区別してしゃべってくれ。 46 名前：login:Penguin mailto:sage [01/10/16 20:35 ID:VUO+BV9r.net] >>37 が微妙に無知だと思うのは俺だけ？ 47 名前：login:Penguin mailto:sage [01/10/16 21:25 ID:0bJyD8nh.net] >>46 ただの「言ってみるテスト」か? そう思うなら、違ってるところを指摘しろよ。 48 名前：login:Penguin [01/10/16 22:28 ID:kO566Fcx.net] >マルチバイト文字なんか使ううちらが悪い。 >外人から見れば英語最高！で国際化なんかやってらんないよ 漏れもそう思う。で、外人に日本語を入力してもバグの出ない ソフトを書かせるためにはクラスライブラリでワイド、UCS4を 積極的に使用するのがおすすめ。 ソフトはクラスの定義と入出力関数だけ変更して、 処理ロジックはそのままで手を触れない。 これ日本語や中国語を知らん外人が楽なので現実的な解。 49 名前：login:Penguin [01/10/16 22:43 ID:x0duUuO3.net] 1byte=32bitにすれば、全世界で幸せになれるよなー 50 名前：login:Penguin mailto:sage [01/10/16 22:43 ID:D0nvonPu.net] 外人が楽できるように外人に合わせるノカー。 みんなガンバレヨ！ 51 名前：login:Penguin [01/10/17 00:02 ID:FRYHV9JH.net] IPv6みたいに当分大丈夫だと思われる広大な領域を取った文字コードが 出てきてもいいと思う。 Unicodeみたいに word単位なんぞケチくさいことは言わずに、 qword ぐらい固定長で占有。これで宇宙人と出くわしても大丈夫。 すべてのプログラマに痛みがともなうが、構造改革なので許せ。 52 名前：login:Penguin [01/10/17 00:26 ID:cC5QpbAl.net] >>51 それってUTF-32か? 普通の目的には4バイトじゃなくても サロゲート無視のUTF-16(とは呼べんが)でもよさそげな気もする。 個人的にはUTF-8でいいかなと思うけど、 ISO-2022-JPもShift_JISもEUC-JPももうこれだけ広まったらまとめるなんて無理だ と思うので我慢する、と。 53 名前：login:Penguin [01/10/17 00:30 ID:YQKlNfNV.net] >>38 TRONコードは、誰かが新しい文字が必要だと思い、申請したら、 例え点を一個追加するだけでも、それは追加される。だから、 > なら別々にして必要に応じて変換ライブラリーみたいなの使えばいいと思うぞ。 は、日々変化する。それは「いい」か？ 文字の同定の基準が存在し、かつ無闇に文字集合が変動しない、 という取り決めがなかったら、大変だぞ。 > これは運用の問題だろ？ > 斎藤と斉藤と齋藤を区別したいときもあれば同じに扱いたい時もある。 文字集合が固定されている環境でのみ、その要求は満たされる。 新しい「齊」や「藤」が次々に生まれる環境では、それらを「同じに扱」うことは、 原理的には可能だが、現実問題としては難しい。 > しかし37読むとEUC-JPかUTFがいいような気がする だと思う。まあ、TRONコードも印刷用途だけならまだましだけど。 54 名前：49 [01/10/17 01:13 ID:BOPoQ/5Y.net] >>51 いや、複数byte列が必要な時点で終ってる。 結局、英語圏の人間は「ASCIIで十分じゃん」ということになる。 例えば、プログラミング言語を作るにしたって、わざわざ マルチバイトのハンドリングをして「hogecode対応！」なぞと するより、単一byteを相手にした方が楽に決まってる。 だから、単一byteのビット数を上げるしか道はないんだ！！！ 55 名前：login:Penguin mailto:sage [01/10/17 02:20 ID:ZtT6Vz1v.net] >だから、単一byteのビット数を上げるしか道はないんだ！！！ bit増やしても、自分の国で使われることしか考えない奴は 減らないので一緒。 昔よくいたよね下位7bitでマスクかけちゃう奴。 56 名前：login:Penguin [01/10/17 10:51 ID:mpfavLge.net] そんな事より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 でも使ってなさいってこった。 57 名前：37 [01/10/17 11:08 ID:6wv4UuNs.net] >>46 何も資料参照せずに書いたにしてはそれなりにできたと思てるがどうよ? 完璧な情報を集めて考えたければ2chに頼るのが間違いだろうて。 あ、次何も見ずに書くときに参考にするから、すこっと抜けてそーな事項を 列挙しといてくれるとうれしい。 >>56 なにげに通やね(笑) 58 名前：logon mailto:sage [01/10/17 11:25 ID:G2XZ5+M2.net] >>56 ﾖｼｷﾞｭｳﾈﾀﾜﾗﾀ! 59 名前：名無しさん＠Ｅｍａｃｓ [01/10/17 15:37 ID:rj14CtXF.net] emacs で iso-2022-7bit 使って多国語やってますが, これって 国際標準じゃないですよね. iso-2022 で多言語やらないでわざわざ Unicode 作ったのは, escape 入れなくても一文字見たら何だか わかるようにするため? 60 名前：login:Penguin [01/10/17 15:41 ID:XqIjgTGZ.net] >>59 ISO 2022 のフル実装は無理というアメリカ人の妄想のため。 61 名前：login:Penguin [01/10/17 16:42 ID:3ILRMCNZ.net] >>48 支那人も外人なんだけど 62 名前：logon mailto:sage [01/10/17 17:22 ID:5T5C0ttM.net] つか、EUCよかS-JISのが腐ってるだろ。 なんだよ、半角かなって。腐ってるじゃねーか。 WinがJISなりUnicodeなりに文字コードをかえればすむこと。 63 名前：logon mailto:sage [01/10/17 17:31 ID:5T5C0ttM.net] あ、ちなみにEUCとJISは1ビット違うだけなので上の発言には含めてないだけね。 M$ってEUCしそうにないし。 64 名前：login:Penguin [01/10/17 18:29 ID:XqIjgTGZ.net] >>62 ハァ？ 文字集合とエンコーディングを区別しろ。アホか。 65 名前：login:Penguin mailto:sage [01/10/17 19:21 ID:YthITvX3.net] > iso-2022 で多言語やらないでわざわざ > Unicode 作ったのは, escape 入れなくても一文字見たら何だか > わかるようにするため? それだけだったら、DIS10646.1 (DIS ってのは、ISO のドラフト仕様ね) で良 かったわけだろ。 DIS10646.1 (こいつは、文字集合としては mule の考え方に近い) が潰されて、 Unicode ベースの ISO10646.1 になったのは、16bitに納まらないと都合が悪 いと考えた Unicode コンソーシアムと、それに押し切られたボンクラのせい だよ。 66 名前：Anonoymous mailto:sage [01/10/17 19:46 ID:YAa2k7T0.net] >>56 ネタに乗せてかなりコアなことを、かなりうならせられるのう TORONコードをxfsなどで配信できたら良いと思うのだが 実際、古文書を解析している方々は超漢字を愛用しているそうな（w 67 名前：名無しさん＠Ｅｍａｃｓ mailto:sage [01/10/17 21:48 ID:YBwfYzjL.net] すべての文書を画像の形式でやりとりするようになれば、 文字コードなどというものは必要なくなる。 ファイル名やコマンドの認識もすべて画像 vs 画像のマッチングにするのだ。 とうぜんソースコードは全部手書きね。 68 名前：login:Penguin [01/10/17 23:48 ID:bGZ6eUEA.net] 　　 ＠ノハ＠ 三○ ｱﾀﾀ! 　　 （　‘д‘) 三○＜なんでもいいから統一しろ！ >>67以外で 　　　　　　　　三○ 69 名前：login:Penguin mailto:sage [01/10/17 23:55 ID:+4YHdf3b.net] >>68 いや、67 はいいセン行ってる。 TRON がおバカなのは文字じゃないモノまで文字として扱ってる所。 70 名前：login:Penguin [01/10/18 01:18 ID:jQdiwMFy.net] >>67 絵がヘタな私は、永久にファイルのコピーもできそうにありません... 71 名前：login:Penguin mailto:sage [01/10/18 02:59 ID:d914pY0P.net] >>67 面白いね!! で、仮名漢字変換やｿｰﾄはどうするの? 72 名前：login:Penguin [01/10/18 05:24 ID:qKFuLJNE.net] ひそかにいいかなと思ってるのは CID だな。 adobe が統一管理してるから混乱ないし、異体字検索問題も対応できる。 新しいコードの追加もそれなりにできる。 コード表とグリフも adobe が提供してくれるしな。合字問題とかどうなってるか知らんが、きっと adobe サマが解決しとるだろう。 内部コードとしてはちょっと複雑すぎる気がするが。 73 名前：login:Penguin [01/10/18 05:41 ID:IKIIFWmq.net] >>56 > お前、surrogate したいだけちゃうんかと。 ｺﾚ ﾜﾗﾀ. 74 名前：login:Penguin mailto:sage [01/10/18 07:13 ID:2ftNibmN.net] 手っ取り早く済ます仕事には今も EUC 使っちまうよ。 75 名前：59 [01/10/18 16:15 ID:zQ3uDx9i.net] 結局 iso-2022 で多国語というのはすたれゆく運命ですか? 僕は Unicode よりイイと思ってるんだけど. 76 名前：login:Penguin [01/10/18 16:33 ID:YWCxX3Ha.net] mb/WCの区別をしなくてよくなるのならUnicodeがイイ！に決まってるが、 それは幻想だったことが決定してるので2022でよい(よかった)。 77 名前：login:Penguin [01/10/18 17:17 ID:gPhXvV4t.net] >>75 内部コードとしては一定以上高度な多言語処理ではどっちも使わん でしょ。Emacs もオリジナルだし。 プログラマの苦労は結局かわらんので、76のいってる通り 2022でよい(よかった)ではあるんだけど、サポートの現状を考 えると、今や、Unicode が圧倒的に有利かな。Unicodeの文章が とりあえず読み書きできる環境を持つ人はもうざらだから。 専門用途ではオリジナルコードも十分ありと思われ。というか、 実際、現在のDTPでは、最終的には adobe のコードが物を言うし。 78 名前：login:Penguin [01/10/18 21:01 ID:o4Mc8Bmx.net] 現実の話、UTFとかワイドキャラクターの導入って あくまでもクラスライブラリとか ウインドウシステムのインターフェースとか ファイルシステムのファイル名の内部形式とか そこら辺の話に終始してる。 ディスク上のテキストに関しては移行できる と考えている人はあんまりいない。 ISO-2022が妥当だろう。 79 名前：login:Penguin [01/10/18 21:14 ID:YWCxX3Ha.net] UTFってUTF-16のこと？UTF-8を内部形式で使う奴はおらんだろう。 >ディスク上のテキストに関しては移行できる >と考えている人はあんまりいない。 XML文書は?普通UTF-8で書くと思うのだが。 >ISO-2022が妥当だろう。ISO-2022系の多言語非対応のエンコーディング(EUC-JP他)、 という意味ならまぁそうかも。 80 名前：79 mailto:sage [01/10/18 21:16 ID:YWCxX3Ha.net] >>79 改行抜けた。mozillaたんしっかりしてくれハァハァ… >ISO-2022が妥当だろう。 ISO-2022系の多言語非対応のエンコーディング(EUC-JP他)、 という意味ならまぁそうかも。 81 名前：login:Penguin [01/10/18 21:31 ID:o4Mc8Bmx.net] >UTFってUTF-16のこと？UTF-8を内部形式で使う奴はおらんだろう。 Ruby 82 名前：79 mailto:sage [01/10/18 21:33 ID:YWCxX3Ha.net] うお、rubyか。じゃ結構普通のことなのかな？ すみません。 83 名前：_ [01/10/18 23:03 ID:Hq3ecu1b.net] >>79 次期 GTK+ の GTK+2 も内部は基本的に UTF-8 ですな。 84 名前：login:Penguin mailto:sage [01/10/19 00:31 ID:Kw5tPojH.net] そりゃ、(EUC-JPと同じく)UTF-8は、ASCIIで済む人はASCIIと変わらんdata量で、 過去のcode資産も活用できるから、移行し易いだろ。ISO 8859-1ででもそうだし。 Unique "wchar_t"は幻想だったという事で。 85 名前：名無しさん＠Ｅｍａｃｓ mailto:sage [01/10/19 02:06 ID:fpLOIwDH.net] 名スレ化あげ 86 名前：login:Penguin [01/10/19 02:33 ID:QKiQs1/Q.net] >>84 でもRubyは国産なのに意外。なんでUCSじゃないのでしょうか？ 質問age 87 名前：login:Penguin mailto:sage [01/10/19 03:23 ID:Kw5tPojH.net] >>86 処理系内部で使うprintf(3)からRuby用にかき直すんかい? 2byte目に'%'や'\'のあるcoding system(e.g. Shift_JIS)用は書き直しだぞ。 88 名前：86 [01/10/19 04:51 ID:QKiQs1/Q.net] >>87 ごめん、ちょっと意味がわからない。 （なんでprintfが使えることが重要なのか？という点が） もし暇なら説明をお願いしたいです。 89 名前：login:Penguin [01/10/19 11:39 ID:wq307Z9h.net] 87じゃないけど… 基本としては、「アプリケーションはなるべくシステムのlibcを使うべき」 ってことだろね。きちんと整備されてるＯＳなら、libcを使うのが パフォーマンス的にも、開発効率上も有利。それが標準の存在意義。 それから「アプリケーションの互換性重要」ってのが背景にある。 printfとかに代表される標準Cライブラリの昔からあるものってのは、 ASCII以外は設計の想定外。だから、SJISとかUCSのような、ASCIIと干渉する エンコーディングをそれで扱おうとするとまず間違いなく誤動作する。 本来これを避けるための Wide Character なんだけど、残念ながら、 この部分は実装依存度がやたら高い。無いOSも多いし、内部構造もOS毎に ばらばらだ。もちろん過去のコードはもちろんこんなもの使ってないわけで、 使うとしたらかなり書き直しに陥るはめになる。 そうなると、選択肢としては、なんとか char のまま、普通の libc で 扱えるようにしちゃおうって考えが浮上してくるわけだ (技術的には逃げなので退化) 必要要件は 　1. ASCII に干渉しないマルチバイト(char の配列)きぼんぬ 　2. 文字区切りが確実容易なほうがイイ！ 3. 何か標準に沿ってるほうがイイ！ こんなところで、それを満たす UTF-8 になるのは自然な流れだろう。 やっぱでかいのは互換要因のほうかな。完全に1から書くのなら、 UCSだろうがオリジナルだろうが好きなのを採用すればよろし。 90 名前：77 [01/10/19 13:05 ID:wq307Z9h.net] >>78 79もいってるけど、「非多言語対応」なら、ISO-2022系が 妥当だろう。実際そっちのが多いと思うし。 話の流れは「多言語用」だよね。ISO-2022-JP-2 とかを扱える環境(emacsとか) をそろえてる人は、UTF-8 扱える環境をもってる人より少ないよねって のがオレの指摘。 今はWinいれたらそれだけでとりあえず日常用途で使う範囲なら、読むのも 書くのもできるからね > UTF-8 91 名前：login:Penguin mailto:sage [01/10/19 13:10 ID:LpodI9Q2.net] >>45 > 情報交換符合と内部表現、 > 文字セットとエンコーディング、 > コードとグリフ、 これらの区別が説明されているサイトはありますか？ 出来れば日本語ｄ 92 名前：login:Penguin [01/10/19 18:32 ID:mx7DeiuF.net] 欧米の人たちが ASCII や ISO-8859-x で足りてるなんてのは わりと誤解で、文字をもっと増やしたいと思っている人が多いです。 XFree86 で強硬に Unicode を推進している人たちはそんな感じ。 JIS X 0208 の記号とかを使った英語のプレゼン資料とか見せると 羨ましがられるよ。 93 名前：login:Penguin [01/10/19 18:42 ID:mx7DeiuF.net] >>15 Solaris や NetBSD は SJIS ろけーるもあったかと。 Solaris だと ja_JP.utf8 とかもできるんじゃなかったかな。 Linux (つーか glibc) は内部 Unicode なんだっけ? 94 名前：login:Penguin [01/10/19 18:56 ID:+gP9D3Wa.net] >>93 linuxでもできる。KondaraではUTF-8なロケール使って、 X上でximを切り替えてCJK混在な文書とかも作れたはず。 Debian sid でもutf-8なロケール作ってやればできるでしょ？ まあアプリ全てがちゃんと動くわけではないが。 (ATOK X のメニューが化けて鬱だった記憶が） ほかのディストリとかは知らない。 95 名前：login:Penguin [01/10/19 19:03 ID:Y1kLvlVv.net] >>91 そんなに難しい話じゃないよ。 「文字」の定義が甘いのをとりあえず横に置いとけば。 文字セット：「この文字を扱う」という範囲。各文字を識別する ID つき エンコーディング：上の文字セットをコンピュータで表現するための数値化の方法 情報交換符合：通信、ファイルなど、外部とやりとりするための文字セット+エンコーディング 内部表現：OS やアプリケーションでの文字の内部表現 コード：数字。文字コードね。 グリフ：形。目に見えるものね。 この手のお話だと、必ずこのあたりがごっちゃになった議論になってわけわかになるので、釘さしてみただけ。 96 名前：login:Penguin [01/10/19 20:53 ID:PkKT5Zqx.net] >printfとかに代表される標準Cライブラリの昔からあるものってのは、 >ASCII以外は設計の想定外。だから、SJISとかUCSのような、ASCIIと干渉する >エンコーディングをそれで扱おうとするとまず間違いなく誤動作する。 >本来これを避けるための Wide Character なんだけど、残念ながら、 >この部分は実装依存度がやたら高い。無いOSも多いし、内部構造もOS毎に だから俺はCやめざろう得なかった。 Standard C++ならば標準ライブラリは全部マクロなんで 自動的に展開されて解決。 C++を嫌うならばKylixがある。 KylixはCのようなポインター操作もできるし、 GUIなしのデーモンプロセスも書ける。 ヘッダーさえなんとかすればドライバも書ける可能性あり。 Cユーザーにとって、字面以外は抵抗なしに受け入れられる。 >ばらばらだ。もちろん過去のコードはもちろんこんなもの使ってないわけで、 >使うとしたらかなり書き直しに陥るはめになる。 過去の資産に関しては同意。 97 名前：login:Penguin [01/10/19 20:58 ID:QKiQs1/Q.net] へ？？ >Standard C++ならば標準ライブラリは全部マクロなんで >自動的に展開されて解決。 ここだけでいいから、なにが解決されるのか具体的に書いて。 98 名前：login:Penguin [01/10/19 21:09 ID:PkKT5Zqx.net] C++のstringというのはbasic_string<char>という テンプレートマクロ。 ワイドはbasic_string<wchar_t>とするだけ。 そうすると、stringと同一の機能をwstirngが受け継ぐ。 printf("%s%d\n", s, d)は cout << s << d << endl; wcout << ws << d << endl; 型の定義だけでほとんどを解決し、ロジックはいじらない。 うまくいくと変数の宣言文を触れるだけで全部解決。 99 名前：login:Penguin [01/10/19 21:14 ID:QKiQs1/Q.net] >>98 ああそういう意味か。了解。 でも、話の流れは、wchar_tじゃぁ駄目って事だったんじゃ…。 #個人的にはふつ〜のアプリはWC使って書くのが好きですが。 100 名前：98 [01/10/19 22:30 ID:dckKBkBJ.net] >Unique "wchar_t"は幻想だったという事で。 wchar_tイコールUCS2でないよ。 MSの2バイトwchar_tは幻想だが。 www-6.ibm.com/jp/developerworks/unicode/000616/j_uniwchar.html C 規格では、wchar_t に対して厳密にどれというタイプを指定していません。 101 名前：login:Penguin [01/10/19 22:58 ID:Kw5tPojH.net] >>100 > >Unique "wchar_t"は幻想だったという事で。 Uniqueというのは、 > wchar_tイコールUCS2でないよ。 > MSの2バイトwchar_tは幻想だが。 などから一つを選択してそれのみでやっていく事を目指す、というつもりで、書きました。 > www-6.ibm.com/jp/developerworks/unicode/000616/j_uniwchar.html > C 規格では、wchar_t に対して厳密にどれというタイプを指定していません。 はもちろん知っています。 ただ、上のようにUniqueになろうと"UNI"codeは目指したと思います。少なくとも当初は。 102 名前：login:Penguin [01/10/19 23:03 ID:dckKBkBJ.net] 4バイトでUniqueになればいいじゃないか。 103 名前：login:Penguin [01/10/20 06:16 ID:g2GqcdkH.net] どうやら、このスレには、ちゃんと理解しているのが３人しかおらず、 それ以外はコード表（どれか１つでも）も見たことがない奴らだけの ようだ まだ、青木光恵の旦那の方が３８倍ましって感じ 104 名前：ななしさん＠おなかいっぱい mailto:sage [01/10/20 07:28 ID:a3ky6FMM.net] >>103 「ちゃんと理解している」のが3人もいれば2ch的には充分のような気も。 あと、そーいうことをいう人には、どのポストに正しいことが書いてあるの か指摘してもらえると嬉しいかな、とか。 105 名前：login:Penguin [01/10/20 11:51 ID:mRQL8QGY.net] >>56 やっぱり謎の中国人に「アイヤー、漢字特盛りにしちゃうアルヨー」 と言わせてほしかったな。 106 名前：login:Penguin [01/10/20 13:09 ID:2B2NfqxB.net] >>102 それについては、>>65の言う通りで、>>56が詳しい(w 「もうUnicode捨てたいんと違うんか？」と小１時間問い詰めたい。 euc.jp/i18n/ucsnote.ja.html Unicodeの安易さが持ち込んだ問題で、10646が腐るのは困る。 <!-->>102はHan Unificationの問題「だけ」を言っているのかな？--> 107 名前：login:Penguin [01/10/20 16:11 ID:8ZJLlTqR.net] このスレッド面倒だから読んでいない。 重複する内容だったら失礼。 シフトジスになぜしないかというとシフトジスには欠点があるから。 その代表的なものは0x5c問題。 0x5cはダブルコーテーションという記号だがシフトジスの漢字はこれを含む 漢字もある。 アスキーコード0x5cが文字列に入っているとシフトジスはおかしくなる。 プログラムでこの問題を回避する処理を入れないといけないがそれは大変だ。 実際、WINDOWS版のソフトでこの問題を回避できていないソフトは多い。 EUCだと、8ビット目を殺さないようにするだけで無変更でコンパイラなどが 日本語をソースに入れても問題なく使える。 それによってgccなどは英語版そのものを使ってもEUCなら日本語を入れたソース をコンパイルできる。 しかしシフトジスだと0x5c問題にかかるので改造しないと使えない。 改造しても行の先頭から順番に読んでいかないと半角か全角か判断できないと いうシフトジスの大きな欠点のため速度が遅くなるという欠点が出る。 仮にシフトジスに変えてしまうとほとんどのLinuxソフトが日本語使えなくなる。 108 名前：かといってシフトジス対応という膨大な作業を誰がするというのだろう。 シフトジス対応すると本家と英語版とソースが分岐するので古いバージョンを 使わざる得ないとか不都合がたくさんでる。 結果的にシフトジス標準は不可能だ。こんなことはプログラマーならわかると思うが 1 はユーザー専門なんだろう。 [] [ここ壊れてます] 109 名前：login:Penguin [01/10/20 17:52 ID:cvBqh8vR.net] このスレ案外詳しいよ. スレッド名に反して役に立った. 110 名前：login:Penguin [01/10/20 17:53 ID:n/co2nXu.net] 文字の割り当ての正当さなんぞ気にしていたら あと何百年かかるかわからんだろ。 「てめーら勝手にしろ」でコード領域広く取って 各地域24ビットぐらい割り当てちまえばよい。 で日本では従来のJISを突っ込んで終わり。 グリフだのなんだのとわめいていたら、孫の代まで に完成しねえぞ。 111 名前：login:Penguin [01/10/20 19:04 ID:2B2NfqxB.net] >>109 それで解決するのは、Han Unificaionだけで、 euc.jp/i18n/ucsnote.ja.htmlの問題はどんどん拡大する。 # 各国内での互換性を維持できたわけだし、>>109はそれでもいいと言っているのだろうが。 しかし、以下は妥当な文字非統合だろうか？(上のURLから一部だけ抜き出した) U+002D HYPHEN-MINUS (ASCIIのマイナス) U+00AD SOFT HYPHEN 語中の折り返し可能個所、表示されないかもしれない U+2011 NON-BREAKING HYPHEN (右端でも折り返されないハイフン) U+2010 HYPHEN 複合語などの一般的なハイフン U+2212 MINUS SIGN マイナス : 互換性を求めて既存のを無制限に突っ込んだ挙げ句がこれ… 112 名前：login:Penguin [01/10/20 19:11 ID:DsyBUQBQ.net] >>110 それでもいい。 それは子孫の時代に解決する問題。 現状では再コンパイル一発で将来の文字コードに 対応できるインフラの整備が大事だと思う。 113 名前：login:Penguin [01/10/20 19:48 ID:XktlMTUg.net] >>107 >このスレッド面倒だから読んでいない。 >重複する内容だったら失礼。 こういっちゃなんだが、すでに、ビット並びの字面(とでもいうのか?)の話はし てないです。 ワイドキャラクタを使用しない、m17nな独自内部コードとしては、開発効率の観点 からビットの字面が大事(UTF-8を使わざるをえない)なんていう話はでたけど話 のレイヤがかなり違う。 >シフトジス対応すると本家と英語版とソースが分岐するので古いバージョンを >使わざる得ないとか不都合がたくさんでる。 localeとはなにか？と、mbstowcs関数をはじめとした、ワイドキャラクタを 利用したプログラムの書き方でも覚えてくれ。 すると、分岐せずに(=localizeせずにinternationalizeすることで)Shift_JIS に移行できなくはないことがわかる。ソースコードは改変する必要はあるかも しれんし（本家に統合は可能だろう）、OSのlocaleまわりもいじらないとい かんかもしれないが。 蛇足だが、 何度か言われているが、character set と encoding を区別してくれ。 ISO 2022 とはなにかを理解してくれ。暇があれば UCS, UTF とはなにか を学んでくれ。書籍もいくつかでてるが、まずは euc.jp/ を読む とよい。 理解した上の発言ならすまん。 114 名前：login:Penguin [01/10/20 21:03 ID:7W8DCi3g.net] >>110 文字コードと文字集合を世界で統一しようという アイデア自体には大賛成だが、ここまで致命的な問題点を 見せられると困るな。 日本だけを見てもこの状況だから、他の諸外国でも いろんな問題があるんだろうな。 ほんと孫の代になるまで解決しそうにないな。 漏れが現役の間は EUC-JP で頑張るしかないかな。 115 名前：login:Penguin mailto:sage [01/10/21 01:58 ID:3nI2LT/o.net] Flashの日本語が読めないのは誰のせい… 116 名前：login:Penguin [01/10/22 00:36 ID:vff311A1.net] 結局, 中国語と日本語を両方ともまともに使う人から見て, Unicode の CJK Unified は満足できるものなんでしょうか? 結局どっちかをメインとして使わないと文面の字面がキモくなる ような気がするんですが. それなら Emacs で ISO 2022 で違う font を使って表示した方が ましのような. 117 名前：login:Penguin [01/10/22 07:46 ID:EJ6V2X5S.net] 16bitに無理矢理収めたくてUnifyしたのに、 >>56にあるように9万(>2^16)字になっちゃったんです。意味ないんですぅ Unifyの意味ないのに、UnifyされたのがISO 10646.1(>>65)になっちゃったんですぅ しかも>>110にあるように漢字以外のUnifyの基準が使いものにならないですぅ Unicodeは文字コードの世界に新しく増えた負の遺産なんですぅ //最近のtechnical reportは面白いのあるけど。 118 名前：login:Penguin [01/10/22 08:00 ID:RZQUGhKz.net] Emacsの内部コードって何つかってんの? 119 名前：login:Penguin [01/10/22 09:01 ID:7trpRy3z.net] HTMLってSJISは論外としてEUCとJISのどっちで書くのがいいの？ 120 名前：login:Penguin mailto:sage [01/10/22 09:08 ID:Pupx5KWC.net] >>118 あんまり考えずに全文検索とかするためにはバッティングしない EUCの方が楽なんじゃない？ 121 名前：login:Penguin mailto:sage [01/10/22 13:05 ID:U0CK64Pe.net] iso-2022-jpでしょ。>>118 122 名前：login:Penguin mailto:sage [01/10/22 13:28 ID:w9iNU5fE.net] ネスケの 4.x だと たまに ISO-2022-JP を認識できないことがある。 ネスケのバグ? 123 名前：login:Penguin mailto:sage [01/10/22 15:33 ID:cV0J5a3p.net] charset= が間違ってるとかじゃなくて？ 124 名前：login:Penguin [01/10/22 15:54 ID:dRSBo2ui.net] >>120 根拠は? 125 名前：login:Penguin [01/10/22 17:12 ID:uLX7lQZs.net] surrogate して使う文字は utf-8 で encoding すると普通の 漢字より byte 数を食いますか? あまりかわらないんだったらそっちにいろいろ文字入れれば Han Unification も救いようがあると思うんですけど. 126 名前：login:Penguin [01/10/22 18:36 ID:WlYpkgCt.net] >>118 ちゃんとコード指定するならSJISでも全く問題ないよ。 俺は各種処理が楽なので、今のところ EUC-JP 使ってる。 127 名前：login:Penguin [01/10/22 18:52 ID:+lMZ2zFA.net] >>125 ちょっと問題あるかもね。 charset=Shift_JIS は文字セットが曖昧だから:) とはいえ、Windows-31J とか書いても理解してくれるブラウザは… >>123 漢字コードの自動判別がしやすいからでしょ。 そもそも charset 書かないのがよろしくないんだけどさ。 128 名前：login:Penguin [01/10/22 21:30 ID:WlYpkgCt.net] >>115 RTF とか HTML とか XML とかマークアップ言語使って ラッピングして使うってのがもう実用的につかわれてるよん。 さらばプレーンテキスト。一回 Outlook とか使ってみそ。よくできてるから。 あ、プレーンテキスト用の「言語タグ」ってのも一応表にはのっかってる けど使うなって書かれてます。わはは。 Solairs の UTF版　Motif の実装も似たようなことしてるはず だけど使ったことないから詳細不明。あと、GTK で pango が UTF-8 ベースなんだけど、こいつもオリジナルのマークアップかけることで、 ちゃんと「多言語」処理できるようになってるね。 もう世の中の流れ的には、少なくとも新しいものを実装する上では、 困ったところをうだうだ言うフェーズは終わってるといえるかもね。 129 名前：login:Penguin [01/10/23 12:54 ID:CcIiXv/t.net] >>124 RFC 2044 からいんにょー: UCS-4 range (hex.) UTF-8 octet sequence (binary) 0000 0000-0000 007F 0xxxxxxx 0000 0080-0000 07FF 110xxxxx 10xxxxxx 0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx 0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx つまり、BMP 内だったら最高でも 3 オクテット、 surrogate pair が必要な文字(U+10000〜U+10ffff)は 4 オクテット。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef