EUCボクメツ委員会

1 名前：ﾓ･ｸ･ﾍ･ｹ菽ｦｯ [01/10/16 00:18 ID:ZujZqkcr.net] Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。 ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ 意味ないじゃん！ Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。 348 名前：login:Penguin mailto:sage [02/08/09 02:10 ID:K7okXid5.net] sage忘れているし。 で、>>341はどうなんだい? 349 名前：login:toor mailto:sage [02/08/09 02:24 ID:EN04GVuN.net] >>342 www.geocities.co.jp/SiliconValley-PaloAlto/8090/ これ読んで出直せ。 350 名前：↑おまえの名前キモい。 mailto:sage [02/08/09 08:35 ID:VJ0HrLof.net] >>342 禿同。 あんな互換性も糞も無いような物はさっさと滅べ。 そしてこれからはICUを使えといいたい。 ついでにg++のwstring周りのヘボさをVC、BCB程度には何とかしろともいいたい。 コメント如きの解析に失敗して下らんエラー吐いてんじゃねーよ。コメントだよ。コメント。 コメントなんざ開始記号に当たったらゴール記号まですっ飛ばせ。ヴォケが。 無駄な時間使わせやがって。コメントまで一々読んでんじゃねーよ。 つーか、STL周りもヘボすぎ、いっそのことSTLportを標準で採用しる。 351 名前：login:Penguin mailto:sage [02/08/09 12:16 ID:K7okXid5.net] >>347 ワイドキャラクタうんぬん以前にSTL自体の互換性がダメダメじゃん。その 発想で逝くならSTL自体使い物にならないからさっさと滅べになるぞ。 Unicode固定ならICUでいいと思うけどね。 352 名前：login:Penguin mailto:sage [02/08/09 21:07 ID:8e06bABa.net] あっちこっちで独自に突っ走られたおかげで、 それらに依存したプログラムが生産されてしまうのは悲しい。 gccの L"" の実装のアホさ加減はどうにかならないのかなあ。 353 名前：login:Penguin mailto:sage [02/08/09 21:13 ID:rdAeGCpP.net] おまえがどうにかしろ >>239 354 名前：login:Penguin mailto:sage [02/08/09 21:26 ID:K7okXid5.net] >>349 もう一度聞くが、>>341はどうなんだ? 君の逝っているのは互換性のダメダメな独自に突っ走ったワイドキャラクタの 一種だろ。違うか? 355 名前：login:Penguin mailto:sage [02/10/14 12:33 ID:JLQPtdaZ.net] 保守 356 名前：login:Penguin [02/10/29 20:40 ID:SYhTKn3M.net] 保守その２ 357 名前：login:Penguin mailto:sage [02/10/29 21:57 ID:a4KVTkgD.net] >>353 は Interface 12月号を買いますた 358 名前：login:Penguin mailto:　 [02/11/10 14:02 ID:KHhL1iGr.net] 　 359 名前：login:Penguin [02/11/17 02:01 ID:roKdiGN4.net] 日本政府も、OSのオープンソース化を図るならば、なるべく最初から 透明な４オクテットコードによる実装を実現して欲しい。 ついでに官製のフリーなフォントも充実させて欲しい。 360 名前：login:Penguin mailto:sage [02/11/18 03:47 ID:Gf2/ARBr.net] フォント欲しいね。 adobe が acroread 用のフォントを自由に使わせてくれるといいんだが…。 361 名前：login:Penguin mailto:sage [02/11/19 04:00 ID:Bmojh6sR.net] >>310 そいつの名前はMULTICODEで決まりですか？ 362 名前：login:Penguin mailto:sage [02/11/20 03:36 ID:ycIE/NKT.net] 1文字4オクテットにしよーが一文字で英語の一単語と同等の 情報量を持つ漢字を扱うには根本的に無理がある ここはやはり"肛門"は"月エ門"、"姦"は"女女女"のそれぞれ合成文字として 扱う漢字文化マンセーなCESキヴォンヌ。 しかし"多"は"タタ"なのか"夕夕"なのかでJISが大揉めになるやもしれん罠。 それに合成文字はフォントが鬼門かのう。 英語圏の人間が grep "tel" -> telephone television telnet... とか、接頭語等で類語を検索するように、漢字圏の人間が grep -bushu "雨" -> 雪 雷 雹 ... とできるようになる日がいつになったら来るのやら。 # ってテーブル用意すりゃ今でもできるけどさ。 363 名前：login:Penguin [02/11/20 10:29 ID:YEjhkZZC.net] >>359 言うの勝手だが実装する奴の身にもなれやボケ。 まぁ、そんなことをしたら美しい日本語フォントが消滅するわけだが。 それ、日本語知らない外国人の発想だよ。 364 名前：login:Penguin mailto:sage [02/11/20 12:34 ID:Lrodec+Q.net] > まぁ、そんなことをしたら美しい日本語フォントが消滅するわけだが。 まぁ、>>360のようなフォント(グリフ)のエンコードと文字符号化方式が区別できんアフォにも消滅してほしいわけだが。 365 名前：login:Penguin mailto:sage [02/11/20 12:49 ID:YEjhkZZC.net] >>361 そんなことするなら初めから1:1対応させた方が幸せになれるわけで。 366 名前：login:Penguin mailto:sage [02/11/20 13:52 ID:60UMuHNB.net] >フォント(グリフ)のエンコードと文字符号化方式が区別できんアフォ 合成文字だとフォントが問題になるって話なのにどこを縦に読めば こういうレスをつけられるのか 脊髄反射もええかげんにせえやヴォケが 367 名前：login:Penguin mailto:sage [02/11/20 20:10 ID:xJzR2YEl.net] 半角ひらがなもあったな 実際は半角かなと同じなんだが… 368 名前：login:Penguin [02/11/20 21:13 ID:2ILmZHLU.net] >>363 だから合成文字の符号化と、合成後のグリフ(フォント)は別ってことでしょ。 "雨"と"田"の合成文字を表すのに"雨"と"田"のグリフを合成するんじゃなくて、 "雷"のグリフを持つ。 ただ文字符号として"雨"と"田"の合成ということがわかる符号化だから grep 雨で"雷"がひっかかるってこと。 俺はもうUCS-4でいいやって思ってるからこんなのいやだけど。 369 名前： mailto:sage [02/11/20 21:16 ID:wwp5/aza.net] >>359 嬲る 男女男 370 名前：login:Penguin mailto:sage [02/11/20 21:29 ID:ACdoqChd.net] >>365 文章から部首で検索したい状況ってのが思いつかんが。 それよりはまだ類字・略字テーブル付きの正規表現で検索できたほうが使えそうだ。 371 名前：login:Penguin mailto:sage [02/11/20 22:12 ID:dTPov+yh.net] >>365 例で言えば"雷"みたな個別の文字のグリフは持っていられないのでは 一部を持ってもいいけど、全ての組み合せは持てないでしょ グリフが既に有る組み合せはそのグリフを使ってそれ以外は動的生成とか？ あんまし格好良いとは思えない どっかのソフト会社が研究用にDnDで部首からグリフを生成するような ソフトを出したという話を聞いたことがあったな、そういや バランスの良いグリフを生成するのはノウハウの塊なんだとか それでも一つ一つ人間がデザインしたのに比べれば、やっぱり美しくないだろうし 372 名前：login:Penguin mailto:sage [02/11/21 20:46 ID:zqZBnzTZ.net] >>368 > 例で言えば"雷"みたな個別の文字のグリフは持っていられないのでは > 一部を持ってもいいけど、全ての組み合せは持てないでしょ 持てるでしょ？符号化は文字集合の枠を逸脱しないと思うんですが。 部首でバラす符号化がJISX0208とか既存の文字集合に準拠してれば 既存のフォント(-*-jisx0208.1990-0など)はそのまま使えるよね。 つまり「男女男 = 嬲」はJISにある文字だからOKだけど「女男女」は存在しない 文字、だからエンコーディングエラー。豆腐でも表示しときゃ良いんじゃない？ まあ、現実には部首集合とそのグリフをどうするのかの問題はあるけど。 JIX0214？(w 373 名前：login:Penguin [02/11/22 01:55 ID:N/6qdEgd.net] 本当にワイドキャラクタがopaqueでしかありえないなら、 いわゆる国際化は出来ても、国際化の最終段階としての地域化で 非常に大きなハンディキャップを背負うことになる。 例えば句読点を特別扱いしたいという時、ISO C的に正しい アプリケーションは、現在のlocaleを見て、いったんマルチバイトに 戻してから処理しなければならない。それを避けようと思えば、 際限無くマルチバイトctypeを増やさなくてはならない。 句読点レベルならさすがにマルチバイトに戻してもいいかも知れないが、 BiDiや結合文字のサポートがctypeレベルですら行われていないのは酷い。 その点ではUCSで統一した方がはるかにまし。 やはり、ワイドキャラクタはopaqueであるべきだ、という考え自体が 諸悪の根源だと思う。libcが提供する情報しか扱えないのでは、外部の ライブラリのレベルで機能を追加することもままならない。 ワイドキャラクタの中が分かれば、実装ごとに提供する情報に差があっても、 アプリケーションの側が足りない部分「だけ」を実装すればいい。 UCSみたいなやり方が嫌なら、個々のロケールごと、つまり言語ごと、 エンコーディングごと、包接基準ごとにワイドキャラクタの仕様を決める という方法もあって、それなら変な文化問題も互換問題も無くなる。 374 名前：login:Penguin mailto:sage [02/11/22 05:04 ID:W3DPkTzr.net] >>370 > 例えば句読点を特別扱いしたいという時、ISO C的に正しい (中略) > 際限無くマルチバイトctypeを増やさなくてはならない。 iswctypeのロケール依存class(たとえばja_JPなら"jhira"、"jkata"他)の話をしているのでつか？ "udc"(user defined class)とかもあるわけで、localedefで自由にいじれるとおもうんでつが。 # 実装されてないlibcが多いだろーけど。 locale databaseいじるの嫌ってんでもwcschrもwcsstrなんかもあるわけで、 いちいちmultibyteに戻さんでも、句読点をwchar_tに変換すりゃいいじゃんとか思うけど... それとも単に typedef unsigned long int wctype_t (glibc) typedef long wctype_t(FreeBSD) な実装じゃwctype classは際限なく増やせねーって話？ > 句読点レベルならさすがにマルチバイトに戻してもいいかも知れないが、 その「句読点レベル」でない処理ってーのを、もっと詳しく説明キボンヌ。 # そういやUI-OSF日本語環境実装規約にはwctransに # 全角半角変換とか平仮名カタカナ変換って定義されてないのねぇ。 > BiDiや結合文字のサポートがctypeレベルですら行われていないのは酷い。 BIDI、結合文字はlibcが扱う範囲を越えてると思いまつ。 Xとかcursesの扱うレイヤでは？ libcにはwcswidth程度の実装があれば必要十分なんでは。 何でもlibcさんのせいにしたらlibcさんが可哀想ですぅ。 > 実装ごとに提供する情報に差があっても、 setlocale(LC_ALL, NULL)とかnl_langinfo(CODESET)とかの戻り値は各プラットフォームによってメタメタですな。 でもそんぐらいのような気がするんですけど、他なんかあります？ 375 名前：login:Penguin mailto:sage [02/11/22 09:07 ID:qpegcL4W.net] 結局現状維持でかなりの人間が不便を感じない罠。 その辺の市役所がアフガニスタン語が表示されなくて困ることもなし。 376 名前：login:Penguin [02/11/23 01:28 ID:thlNcqVy.net] >>371 >いちいちmultibyteに戻さんでも、句読点をwchar_tに変換すりゃいいじゃんとか思うけど... 確かにその手はあるなあ。 >その「句読点レベル」でない処理ってーのを、もっと詳しく説明キボンヌ。 句読点を処理したい、というレベルになると、もう相当高度な自然言語処理 だから、BiDiみたいにもっと基本的な処理は一般性のある形で処理できて ほしい、という意味で書いた。 >BIDI、結合文字はlibcが扱う範囲を越えてると思いまつ。 >Xとかcursesの扱うレイヤでは？ >libcにはwcswidth程度の実装があれば必要十分なんでは。 >何でもlibcさんのせいにしたらlibcさんが可哀想ですぅ。 Xやcursesのために、どの文字が結合文字になるか、という程度の情報は is???()でlibcから取れるようにしておくべきだと思うけどなあ。 もちろんそれだけでは何も出来ないから、X,cursesもロケール個別の 処理をやらなくてはならないが。で、そうやって各層で国際化を 積み重ねて行くためには、どこかで情報を共有できないと困る。 そのためにはワイドキャラクタの中を晒してしまうのが一番 手っ取り早いと思うわけ。 377 名前：login:Penguin [02/11/23 02:03 ID:LOD4l8AE.net] 結論：日本語はすべてローマ字で表記せよ！ 378 名前：login:Penguin [02/11/23 02:23 ID:8aEtw4PB.net] >>359 本題とはずれるが、やはり日本語のベクターフォントは容量食うので 合成しようって話はあるよね。 # あくまでフォントの話 379 名前：login:Penguin mailto:sage [02/11/23 04:04 ID:taFbs00T.net] >>373 > Xやcursesのために、どの文字が結合文字になるか、という程度の情報は > is???()でlibcから取れるようにしておくべきだと思うけどなあ。 リガチャに関してのみならば、wcwidth/wcswidthはwchar_tのカラム数を算出する関数なので、 こいつの実装のためにどのwchar_tがリガチャかの情報はlibcが持ってる必要があると思います。 んでlibcの内部でその情報を使うだけではなく、is???でも情報が取れるべきってー要望は >>371で書いた通りwctype classはロケール固有に自由にclassを定義しても良いはずなんで #include <locale.h> #include <wctype.h> wctype_t tp; int ret; char *s = リガチャな文字 setlcoale(LC_CTYPE, ""); tp = wctype("ligature"); /* ← class名はテキトーっす */ if (!tp) return; /* リガチャclassは現在のロケールでは使えません */ ret = iswctype(tp, *s); てなコードで可能にするように実装すれば良い話なんでは？ # wchar_tの情報を知るのにUCS4であると仮定するのも、iswctype()にいちいち聞くのも # どっちもどっちで大差は無いと漏れは思います。 んでBIDIに関してはアラビア語とか左右混在する言語はよー知らんのでパス。 こっちは今のlocaleでは機能は足りてないかも。 380 名前：376 mailto:sage [02/11/23 04:10 ID:taFbs00T.net] ○ret = iswctype(tp, *s); ×ret = iswctype((wint_t)*s, tp); 逝ってきます.... 381 名前：376 mailto:sage [02/11/23 04:11 ID:taFbs00T.net] ×ret = iswctype(tp, *s); ○ret = iswctype((wint_t)*s, tp); さらにもう一発逝ってきます.... 382 名前：376 mailto:sage [02/11/23 04:20 ID:taFbs00T.net] でもリガチャを表すクラス名がロケールによってバラバラだと流石にキツイなぁ そのへんはisligatureは用意するとか、class名は登録制にして char ** wctypeSupportedClassNameList()とかも必要なんすかねぇ... 383 名前：376 mailto:sage [02/11/23 04:28 ID:s8Fyt+ei.net] ×char *s = リガチャな文字 ○wchar_t *s; /* <- リガチャなwide文字列 */ だめぽ。 384 名前：login:Penguin mailto:sage [02/11/23 09:33 ID:Jj9OvgEA.net] 現状維持。これでよし。 385 名前：login:Penguin mailto:sage [02/11/23 13:26 ID:thlNcqVy.net] > んでlibcの内部でその情報を使うだけではなく、is???でも情報が取れるべきってー要望は > >>371で書いた通りwctype classはロケール固有に自由にclassを定義しても良いはずなんで それが実装されていないlibcでも上のレイヤでカバーできるように するためには、やっぱりwchar_tの中が見えた方が良くないか？ 386 名前：login:Penguin [02/11/24 01:59 ID:AQbo0hie.net] どうして、ワイドキャラクターとかで、ぐちゃぐちゃとクラスだの ロケールだのと面倒な、ASCII文字の場合と違うソースのかき方になる ような変なことをしなければならないのかと思うよ。 387 名前：login:Penguin mailto:sage [02/11/24 02:27 ID:lWARrYsy.net] 軍備強化して世界征服しましょう。で好きなように文字コードを決めましょう。 388 名前：login:Penguin mailto:sage [02/11/24 02:37 ID:SVTsCyE/.net] 高度な話をしているところスレ汚しなんですが 文字幅って表示をヌキにして(単純にlibcレベルで)判定できるものなのかな... たとえば「★」や「”」が全角幅のフォントと半角幅のフォントがあって (efontなんか半角だったな...) これをwcwidthで判定すると(wcwidthはフォント情報なんて知らないから) どっちも同じ幅を返す しかしたとえば XwcTextEscapement なんかで幅をもってくると 差がでてくる そんな場合はどっちを信用したらいいか やっぱり表示に用いられる条件ヌキにして文字幅情報の判定は困難かと (そのヒントだけならなんとか...?) なんか勘違いしていたらスマソ 389 名前：login:Penguin [02/11/24 02:49 ID:5DSLS8t6.net] XTerm と全角文字 slashdot.jp/journal.pl?op=display&uid=64&id=77518 390 名前：login:Penguin mailto: sage [02/11/24 02:55 ID:21x7eWWm.net] そもそも何のために文字幅情報を得たいのか、 それが問題じゃねーかな。 391 名前：login:Penguin mailto:sage [02/11/24 04:30 ID:YgGFtLsl.net] >>383 結局ロケールってば、要は抽象化プログラミングなんすよ。 そーゆーのが得意なjava風に書けば(稚拙ですが) interface ctypeLocale { 　　public int mbtowc(...); 　　... class eucJP implements ctypeLocale { 　　public int mbtowc(...) { 　　　　/* CES -> 内部表現(2byte->16bit変換とか、CCS or UCS4に変換とか、特に決まってない) */ 　　　　... class ctypeLocaleFactory { 　　public static ctypeLocaleImpl setlocale(String locale) { 　　　　if (locale.equals("ja_JP.eucJP") 　　　　　　return new eucJP(); 　　　　... [使い方] ctypeLocale ctype = localeFactory.setlocale("ja_JP.eucJP"); ctype.mbtowc(...); みたいな感じかな？ # 本当はmb/wcとwctype/wctransとか、言語・地域・CES・CCSごととか、細かく # 別オブジェクトにする必要あるだろーけど、いーかげんに書けばこんな感じでしょう。 ごく普通のプログラミング手法だと思うけどな。 392 名前：login:Penguin mailto:sage [02/11/24 04:34 ID:YgGFtLsl.net] mbrtowc/wcrtomb,wctype/wctrans,strftime etc...はあくまでinterfaceであって、 中身は (言語)-(地域)-(文字符号化方式)に応じて手前らお好き勝手に実装せい、 んでsetlocale()で多態せよ、アンドこういう抽象化のお約束として内部は隠蔽したから、 内部情報を聞きたいときはis???とかでお伺いを立てろと。んで、wchar_tってのは class wchar_t { protected int value; } と、外から中身を覗いちゃダメなものと規定しましたよと。 なんですが、>>383みたいに直接wchar_tの中身を覗かせろって意見が多かったり、 #define __STDC_ISO_10646__がつっこまれたりしたんは、 結局のところ、interfaceの設計が悪いんだよなーと漏れは思うっす。 # そういや塩兄はいっそいまのlocale frameworkはobsolateにしちまえとかいってたような気が。 結局、opaque死守派は、private/protected fieldを覗く行儀の悪さに対する嫌悪感と、 将来的に拡張をしようとしたときにバイナリの再コンパイルが必要になる (#define __STDC_ISO_10646__ yyyymmLだからね)ところが嫌なんだろうと想像してみる。 >>385 XwcTextEscapementって文字の送り幅をpixelで取得する関数ですよね？ libcの提供するwcwidthはもっとprimitiveなもんで、カーソルを移動する個数を計算するだけで、 半角なら1、全角なら2ってーのを返すだけでつ。 # 文字集合でHalf-width、Fullwidthとか決まってればの話。 単純化して書くと return isprint(c) ? _isZenkaku(c) ? 2 : 1 : 0; 程度のもんです。 393 名前：385 mailto:sage [02/11/24 12:35 ID:toan50Vo.net] >>389 固定幅文字用のフォントをみても、同じ文字がフォントによって 全角/半角と変わったりする場面があるんで、表示と切り離して 文字幅を考えることができるのかなと... もっとも、表示をきちんと(ずれないように)行う、という意味では Xwc(mb)TextEscapementなんかつかってまじめにピクセル位置を 求めるのが正攻法っぽいけど。 ただ、ISO10646のフォントでXwcTextEscapementがちゃんと動かない 場面があった(それはうちの環境の問題だな...)と、 じゃぁということでwcwidthを使ってみると、EUC-JPやSJISと 文字幅がちがうものがあったりということがあったんで ...失礼しました 394 名前：370(==373,382) [02/11/26 03:23 ID:Lk149imn.net] > なんですが、>>383みたいに直接wchar_tの中身を覗かせろって意見が多かったり、 > #define __STDC_ISO_10646__がつっこまれたりしたんは、 > 結局のところ、interfaceの設計が悪いんだよなーと漏れは思うっす。 interface云々じゃなく、libcによる一元的なi18nという思想自体が 間違っていたんだと思う。むしろ各レイヤが協力しあって、自分が 出来る範囲で国際化を実装するのが本来の姿。 例えば、mbstowcsは純粋にlibcだけで出来ることだから、そう実装すべき だけど、例えば入力システムは可能ならアプリケーションが自力で 実装して、それがダメならtoolkit->X、あるいはreadline/curses->端末 という風にfallbackしていくのが理想。文字幅なら、デバイスに応じて 取れないと意味が無いし、高品質な出力が欲しければコンテキストにも 依存した形で取れて欲しい。もちろん、単純な用途で精巧な実装が不必要 な時は、コンテキスト非依存で簡単に取れて欲しいし、端末の文字や ascii artのようにどこに持って行っても同じ幅でないとならない場合の ために、固定幅という選択肢も必要。 もちろん、各レイヤの国際化の実装が喧嘩しないようになっていなくては ならず、例えばXIMが効いているとEmacsで直接入力ができない、とかいう のは恥ずかしい。 ところが今のwchar_tの仕組みは、libcが情報を全部抱え込んでいて、 アプリケーションはISO Cの枠組ではlibcから取れる以上の情報を 取れない。仕方無いから、nl_langinfoみたいな裏口から何とか情報を 取って対応することになるけど、明らかにこれはおかしい。結局、 ロケールには頼らないで、全部Unicodeにして、最後まで独自実装で やってしまうのが正解、ということになる。 つまり、libcは自分でできることはやるけど、それ以上のことをXなり cursesなりアプリケーションなりが実装することを妨げないように、 情報を外に出すべきだ、と言いたかったわけ。その手段はUnicodeだけでは ないはず。 395 名前：login:Penguin mailto:sage [02/11/26 11:34 ID:/BqcUjeR.net] SJIS の化け物みたいな GB18030 っていいね。 あの思い切った姿勢が大好き。 396 名前：マカース受信中 mailto:sage [02/11/26 13:14 ID:6Jv4mTS/.net] ライブラリ群の協調の為にwchar_t = UCS4として生触りしたいのであれば #define __STDC_ISO_10646__で既存のwchar_t, wcslen, wcscmp, wcswidthを乗っ取るなんて ギャングな方法でなく、ucs4_tによって内部表現がUCS4であることの保証、 そしてucs4len, ucs4cmp, ucs4widthを実装して、な方法が正しい方法でしょう。 むしろ変換なんてセコイこと言わずに、multibyteは全てutf8と仮定して utf8len, utf8cmp, utf8widthを実装して、既存のctypeは全廃したほうがlibcもすっきりしますね。 では、ロードマップとしては5年後までに既存のctypeを全廃ということで。 …ネタはさておき。 ああ、でもちょっとマジレスする時間が無かったり。 ちゃんとした反論はもうちょっと待ってね>>391 軽く>>389を補足しておけば、 libcの持つ情報の提供という点では、UCS4 hardwire vs is???/nl_langinfoの戦いは 例えはロケールDBがOracleだったとしたら(w SQLを叩くか(直値)、ストアドプロシージャを使うか(手続)とか程度の 不毛な議論にしかならないと思います。 DBの中身が同じであれば結果に差異はでないはず。 ただし、文字とは何か？を考えるとUCS4 hardwireでは失うものは多いと。 樋浦さんの言葉を借りれば「Unicodeの表現能力の限界」っすね。 397 名前：login:Penguin mailto:sage [02/11/26 13:42 ID:9t3zkyFp.net] Cにtemplateを導入してstring.hをテンプレート化。 で、strlen<ucs4>() これ、最強。 ……素直にC++使っとけ。 398 名前：login:Penguin mailto:sage [02/11/26 21:58 ID:Lk149imn.net] そんなTCHARみたいな・・・ 399 名前：login:Penguin [02/11/27 03:21 ID:HhmqaFh8.net] 383のいわんとすることは、プログラミングスタイルが 文字コードによらずにかけるべきだというものだ。 英語のサンプルプログラムを書いた本があったときに、 それを日本語翻訳して、サンプルプログラムの中の文字列とかコメントを 日本語に直せば（文字数が変るのは別として）、それで正しいプログラム になるというようなもの。（英語と日本語の文法の違いは考慮しない。） たとえば program main() { #include <stdio.h> char * s= "Hello World.\n"; printf("%s",s); } とかかれたプログラムがあったとするとき、 program main() { #include <stdio.h> char *s="もうかりまっか！\n"; 　printf("%s",s); } とかくだけで、よいというもの。string 函数なども、全部同じ書き方。 もちろんソースは４バイト固定長の文字によりかかれているものとする。 400 名前：login:Penguin [02/11/27 03:21 ID:HhmqaFh8.net] ＃ 文字を処理する場合に、全角だとか半角だとか、幅が１だとか２だとか、 内部表現が１バイトだとか２バイトだとか３バイトだとか４バイトだとか そういうことをぐちゃぐちゃとまぜこぜにしているから、頭が混乱するのだ。 文字「A」はもじ「A」であって、字形とか内部表現の文字数とか、表現 コードの種類とか、いろいろなことを気にしてプログラムを書いたら、 気が散っていけない。どうしても必要な時にはフォントの幅とか字体とか 内部表現のコード系を考慮してもよいかもしれないが、たとえば、日本語を 英語に翻訳するプログラムを書いているときに、幅が１か２かは関係ない。 １文字は1文字として、それが全角半角は関係なし、幅が１か２は関係ない。 そもそも、英語の活字も単語の中で幅が異なるのが正しいのだし、毛筆体なら とかでもそうなる、しかし一端、文字の列であると認識して処理する場合に、 幅とか字体とか字形は無関係にプログラムが（望めば）かけねばならない。 　エディターに表示するために、であれば、そのときには、字形やフォントの 情報にアクセスしにいって、それらを考慮したプログラムにしてもよいだろう。 401 名前：login:Penguin mailto:sage [02/11/27 22:02 ID:N9f6Y7xH.net] 国際化の話になってくる気はするが、上から下か左から右か右から左か、なんてことを考えることになるのぅ。 字体字形も「幅」なるものもコンテキストによって変わるし、場合によっては「高さ」かもしれない。 行なんてモノが意味が無くなるかもしれない。 論理構造でプログラムを組んで、見た目側を独立させようなんてのは、所詮は夢物語の理想論な気がする。 HTML ですら fixed でない layout を理解できない奴らがふつーな世界なのに。 402 名前：login:Penguin [02/11/27 22:14 ID:DCJVBuF/.net] Ｌｉｎｕｘはやはりユニコードつらいよね。。。 403 名前：login:Penguin mailto:sage [02/11/28 03:34 ID:ZTs0Sb/2.net] そうか？ Win や Mac が SJIS にひきずられてるのと同程度に EUC にひきずられてるぐらいだと思うが(根本的には ASCII だが)。 404 名前：login:Penguin mailto:sage [02/11/28 19:53 ID:k3y9tCkp.net] >>394 あとついでにwchar_t == UCS4派の方々の為に 演算子オーバロードを導入して ucs4_t zensp = '\u3000'; wchar_t wc; wc = zensp をきぼー(変換不可の文字の場合はraise exception)。 これでwchar_tが特定のCCSに縛られることによる 非互換性 or 情報欠落 or 誤変換 or *政治*は発生しない。 …素直にC++(以下略 405 名前：login:Penguin mailto:sage [02/11/28 20:32 ID:k3y9tCkp.net] さて、ネタはさておき。 >>396はよくわかんないです。 サンプルコードそのままで動きそうなんですが。 i18nの見地ではcatgets()/gettext()使えとしかコメントが… # 「出ますディレクトリ」問題？引数順つきフォーマットの話？ ソースは4オクテット固定文字でなくてもいい罠。 現にjavaではwinならSJIS、unixならeucJPで書いてもbyte compile時に native2asciiがソースを7bit-ASCII(含まれない文字は\u3000といった Unicode2.0のコードポイントで表現)するよう変換するけど？ ソースがSJISだとcharがSJISでcompileされてLC_CTYPEと相性が悪いってーのは char *s = "あ"; と書いてこれが「あ」に見えるのはエディタが悪い(w。コンパイラにしてみれば char s[] = {0x82, 0xA0, 0x10}; でしかないからねぇ。やっぱりLC_CTYPE使うプログラムはmessage catalogを使えと。 んでwchar_tのL'あ'は確かにCSIだとアレなんだよな。 下手するとcompiling-time localeに縛られちゃうし。 というか、L'あ'の'あ'はソースがSJISだったらL'0x82A0'で良いんだろう。 # でマクロなりでmbrtowcを呼べばいいんだろう。 それ以上の働き(LC_CTYPE=ja_JP.eucJPのときにはeucJPとして振舞うこと)を 期待するのは正しくないんだと思う。 (このへん非常に自身なっすいんぐ) そもそもL'あ'なんてロケールko_KR.eucKRの時に意味を為さないもん。 406 名前：login:Penguin mailto:sage [02/11/29 12:40 ID:raYwjZ0J.net] >char s[] = {0x82, 0xA0, 0x10}; なぜ \0 で終端しない? >そもそもL'あ'なんてロケールko_KR.eucKRの時に意味を為さないもん。 xfd -fn '-*-ksc5601.1987-0' してみろよ? 407 名前：login:Penguin mailto:sage [02/11/29 14:22 ID:MQGqKzTm.net] > なぜ \0 で終端しない? 入力ミスでつ、失礼。 > xfd -fn '-*-ksc5601.1987-0' してみろよ? おお、KSC5601とかGB2312、BIG5あたりにも平仮名ってあったのね、Thx. じゃー s/ko_KR.eucKR/ru_RU.KOI8-R/とでもしとおきまつ。 408 名前：login:Penguin [02/12/01 05:03 ID:wdAcIpdA.net] % 409 名前：login:Penguin [02/12/15 02:05 ID:Ra09IIC2.net] 血液型の存在意義ってあるんでしょうか？ 410 名前：login:Penguin [02/12/15 04:06 ID:JcBJBO9o.net] overload? pcが燃えたりしない？ 411 名前：login:Penguin [02/12/15 04:35 ID:95NNaRk1.net] ところで、何で ShiftJIS は M$ が作ったことになってるの？ 412 名前：login:Penguin mailto:sage [02/12/15 21:24 ID:7gUpNzER.net] >>408 ASCIIがMS-BASIC, MS-DOSのために考えたから。 413 名前：login:Penguin [02/12/16 01:54 ID:bS9goAzK.net] 文字（漢字なども含めて）をアトミックな情報と考えずに、 バイトの列と捉えること自体が、既に既存のASCII的 英米中心主義に足をとられている証拠だ。文字の実現が 何バイトであるかを知らずとも、char が文字１つを あらわし、文字は何か特別な処理（函数を呼び出すなど）を しないかぎり、内部構造を見られないものとして、プログラムが かけなければ、いつまでたっても、ぐちゃぐちゃのいきあたり ばったりでわけのわかりにくいソースコードの地獄から抜け出られないよ。 実数（単精度でも倍精度）でも、通常は、内部の二進表現がどうであるか を気にしなくてもプログラムがかけるように、文字も内部で同表現されて いるかによらずにソースプログラムがかけるようなインフラの土台を 作るべきなんだ。 　そのためにも、一番適当なのは、いまや３２ビット固定幅の文字であり、 従来のシステムからの移行の便宜を考えるならば、コンパイラには、 ソースがどういう従来の文字コード体系でテクストとしてかかれているかを オプションとして引数に渡し、でてくるオブジェクトは、すべて３２ビット 固定幅の文字コードを前提とした出力とするのがよい。 　とにかく、英米以外の国々は、行き当たりばったりの変な文字コードと その処理の複雑さや函数の仕組みなどにより、ASCIIオンリーでプログラミング ができる場合に比べて過大ともいえる苦労を強いられてきた。バグも多くなる。 開発コストも高い。　いまや多少の性能、容量のオーバーヘッドを犠牲にして でも、ソフトが自然に、まるでASCIIのみしかない場合のように書けて、 32ビットに収まるほぼ全世界の文字をひとつのソースで、ロケールなど気にせずに 処理できる、そういう理想郷が必要だ。 　面倒で不便なその場当たりなコードのために英米に比べて日本などの国々は 著しい文化的不利益を被ってきたし、このままだと被りつづけることになる。 今こそ、この状況を跳ね返して、英米中心主義のコード体系、計算機言語や ライブラリーにNOといおう。 　 414 名前：login:Penguin mailto:sage [02/12/16 01:58 ID:CE1D5wUJ.net] そうなるためには僕達は具体的に何をすればいいですか？ 415 名前：login:Penguin [02/12/16 02:44 ID:kZumFsPJ.net] >>409 MS-DOS が出る以前に ShiftJIS を見たのは幻だったのか… 416 名前：login:Penguin mailto:sage [02/12/16 06:44 ID:4qHLRA5W.net] >>410 せめて、「包接基準」程度の言葉を覚えてから書こうね。 417 名前：login:Penguin mailto:sage [02/12/16 07:26 ID:FwnNqLr5.net] >「包接基準」 この字でええんかと小一時間 418 名前：login:Penguin mailto:sage [02/12/16 18:51 ID:klsjmqv9.net] ttp://www.nara-edu.ac.jp/~inoue/sizen/kaeru/housetu.htm 419 名前：login:Penguin [02/12/18 04:11 ID:pxr5ilKA.net] いまや我等は従来の英米中心主義を廃すへし。 420 名前：login:Penguin mailto:sage [02/12/18 04:17 ID:9zCa8KtI.net] >「包茎基準」 萎えた状態で 3mm でも皮被ってたら包茎ですか？ カリ首が見えないとダメですか？ 421 名前：login:Penguin mailto:sage [02/12/21 01:50 ID:EFgh3ncW.net] >>413 >>410 > 32ビットに収まるほぼ全世界の文字をひとつのソースで、 > ロケールなど気にせずに処理できる、そういう理想郷が必要だ。 まあ、ロケールが文字コードだけの問題と思っているようじゃ... 422 名前：IP記録実験 mailto:IP記録実験 [03/01/08 22:08 ID:+M/1sqI1.net] IP記録実験 qb.2ch.net/test/read.cgi/accuse/1042013605/ 1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:??? そんなわけで、qbサーバでIPの記録実験をはじめましたー。 27 名前：心得をよく読みましょう 投稿日：03/01/08 17:20 ID:yL/kYdMc SETTING.TXT管轄でないということは全鯖導入を視野に、か？ 38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l >>27 鋭いです。 73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l ＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？ ・今までより、サーバが重くなる。 ・裁判所や警察からの照会があった場合にはIPを提出することがある。 423 名前：login:Penguin mailto:sage [03/01/09 01:25 ID:0uJfVOg+.net] >>348悪ざない。バカだと。 424 名前：login:Penguin mailto:sage [03/01/09 01:36 ID:0uJfVOg+.net] 記念カプリコ 425 名前：IP記録実験 mailto:IP記録実験 [03/01/09 02:01 ID:Eya/RVup.net] IP記録実験 qb.2ch.net/test/read.cgi/accuse/1042013605/ 1 名前：ひろゆき ◆3SHRUNYAXA ＠どうやら管理人 ★ 投稿日：03/01/08 17:13 ID:??? そんなわけで、qbサーバでIPの記録実験をはじめましたー。 27 名前：心得をよく読みましょう 投稿日：03/01/08 17:20 ID:yL/kYdMc SETTING.TXT管轄でないということは全鯖導入を視野に、か？ 38 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:22 ID:rLfxQ17l >>27 鋭いです。 73 名前：ひろゆき ◆3SHRUNYAXA 投稿日：03/01/08 17:27 ID:rLfxQ17l ＞ところで、IPが抜かれて何か今までと変わることってあるのでしょうか？ ・今までより、サーバが重くなる。 ・裁判所や警察からの照会があった場合にはIPを提出することがある。 426 名前：login:Penguin mailto:sage [03/01/09 02:09 ID:I0ACnG/A.net] (・´з`・) ＜ひろゆきは1000狙ってるよ 427 名前：login:Penguin mailto:sage [03/01/09 02:48 ID:h7UDho/F.net] >>1さん IPを記録しないでくださいお願いします 428 名前：login:Penguin mailto:sage [03/01/09 03:31 ID:mK/aEqnH.net] 多分一ヶ月くらいで新しい掲示板が出来るんだろうな 429 名前：山崎渉 mailto:（＾＾）sage [03/01/15 11:30 ID:+BGYmUVc.net] （＾＾） 430 名前：login:Penguin mailto:sage [03/02/18 02:10 ID:pSq8jkiV.net] 保守 431 名前：login:Penguin [03/02/24 13:15 ID:xcdIcF3X.net] >>1 馬鹿ですか？8ビットコードをSJIS無くしてEUC統一ならともかく。 432 名前：login:Penguin [03/02/24 14:27 ID:mKA/Y3vi.net] >428 今更EUCに8ビットコードを統一なんて非現実的な事をいうほどは馬鹿じゃない。 433 名前：login:Penguin mailto:sage [03/02/24 18:43 ID:JRC7EHKD.net] でも、16bitに統一だ〜とか非現実的なことを今でもいっているバカは欧米方面に 数多く存在する模様。 434 名前：login:Penguin [03/02/25 14:08 ID:v6xxx70E.net] >>1 > Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。 > ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ > せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ > 意味ないじゃん！ > Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO > Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。 何を言うかっ! お主が真のJava使いならShift_JISを選ぶべきではない！ UTF-8にするはずじゃ！ XMLもUTF-8が標準なのじゃぞ！ 435 名前：おしえてくれいー [03/03/01 00:31 ID:rr6x418h.net] ぼくもUTF-8がいいとおもう SJISは2バイト目のコードがMSB立っていないのでやだ。 436 名前：login:Penguin [03/03/01 01:36 ID:7knwdp6R.net] 元々、EUCってAT&Tとかが決めた国際標準じゃなかった？ 437 名前：名無しさん＠Ｅｍａｃｓ mailto:sage [03/03/03 12:45 ID:5UTxkYrg.net] まだこのスレあったのかよ 438 名前：login:Penguin [03/03/27 05:06 ID:Ys6voNX5.net] ユー、ワカッテナイネ． ジャップ ガ ナニヲ イッテモ ミーニングレス ネ． アメリカン ガ エンコーディング ヲ キメルノダ． スベテノ ソフトウェア ハ アメリカ デ ツクラレル． ジャップ ハ ソレヲ カウ ダケ． ソノカワリ ノースコリア ヲ コウゲキシテ アゲヨウ． 439 名前：login:Penguin mailto:sage [03/03/27 05:24 ID:jeN9lawM.net] Shift JISは2バイト目がASCIIと重なる場合があるから嫌い。 440 名前：login:Penguin mailto:sage [03/03/27 23:54 ID:BCTYm40e.net] まぁ、本来ならば「文字」をキャラクタ(バイト)単位で 判定してはいけないわけだが... (たとえば文字"A"をさがすのに頭から1バイトずつ順にさがすなど) だからSJISが2バイトめがMSBたっていないからEUCより面倒とかは 「正しい」組み方をしている限りはない。 (プログラムが文字のエンコーディング方法を知っている必要はないので) そうはいっても古いコードはまだ多く残っているから。 それに、ちゃんと書くのはけっこうめんどい 441 名前：login:Penguin [03/03/28 00:54 ID:a3LtJSU8.net] はやくさっさと、１文字８バイトの桃源郷を作るんだ。 442 名前：login:Penguin mailto:sage [03/03/28 01:56 ID:bqsGCLHk.net] >>437 "内部コードが"CSIなのってSolarisくらいじゃない? printf()とかさ 443 名前：山崎渉 mailto:（＾＾） [03/04/17 12:11 ID:PWISM87M.net] （＾＾） 444 名前：山崎渉 mailto:（＾＾）sage [03/04/20 06:09 ID:X64WTq1+.net] 　　 ∧＿∧ 　　（　　＾＾ ）＜ ぬるぽ（＾＾） 445 名前：名無しさん＠Ｅｍａｃｓ [03/04/27 01:19 ID:6zN1r8md.net] お前ら、新しいエサですよ。 Unicode 4.0 Released! www.unicode.org/versions/Unicode4.0.0/ 446 名前：login:Penguin mailto:sage [03/04/27 01:25 ID:qRyDd44s.net] (ﾟдﾟ)ﾊｧｰﾝ 447 名前：（　´Д｀）/＜ 先生！！こんなのが有りますた。 mailto:ｓａｇｅ [03/04/27 01:31 ID:dA76kPz1.net] www.yamazaki.90.kg/hankaku/hankaku07.html www.yamazaki.90.kg/zenkaku/index.html www.yamazaki.90.kg/hankaku/hankaku08.html yamazaki.90.kg/hankaku/hankaku10.html www.yamazaki.90.kg/hankaku/hankaku01.html yamazaki.90.kg/hankaku/hankaku03.html www.yamazaki.90.kg/hankaku/hankaku02.html yamazaki.90.kg/hankaku/hankaku09.html www.yamazaki.90.kg/hankaku/hankaku06.html yamazaki.90.kg/hankaku/hankaku04.html www.yamazaki.90.kg/zenkaku/index.html www.yamazaki.90.kg/hankaku/hankaku05.html 448 名前：login:Penguin [03/04/27 04:22 ID:AM2rRROs.net] 日本が独自に４バイト固定長あるいは８バイト固定長の国際標準を ぶちあげようとしたら、急に経済制裁とか空爆とかを受けそうだな。

---

---

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

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