EUCボクメツ委員会

1 名前：ﾓ･ｸ･ﾍ･ｹ菽ｦｯ [01/10/16 00:18 ID:ZujZqkcr.net] Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。 ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ 意味ないじゃん！ Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。 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] 日本が独自に４バイト固定長あるいは８バイト固定長の国際標準を ぶちあげようとしたら、急に経済制裁とか空爆とかを受けそうだな。 449 名前：login:Penguin mailto:sage [03/04/27 05:07 ID:r9SAhPiw.net] ＞日本が独自に という時点で ＞国際標準 にはなりえん気もするが。 450 名前：login:Penguin mailto:sage [03/04/27 10:26 ID:CIHHY3pY.net] >>445>>446 ISOの国際化規格もXの国際化規格もli18nuxも日本人が中心となって 作った。 Linuxの既存の国際化の仕組みに不満があるなら、li18nuxの樋浦さん あたりに直接文句言えば。 451 名前：login:Penguin mailto:sage [03/04/27 14:04 ID:PuFritwf.net] li18nuxって役に立ってる？ li18nuxの作ったソフトってどこの ディストリビューションも使ってないよね？ 452 名前：login:Penguin [03/04/27 14:17 ID:12AnfH8t.net] 法律で、UCS-4以外を使えば犯罪にしてくれ 453 名前：login:Penguin mailto:sage [03/04/27 15:10 ID:LPP1MV5m.net] >>448 li18nuxは標準化グループです。 今すぐ移行できるレベルの標準はわざわざみんなで考える必要はありません。 ディストリビューション屋さんの得意な既存のソフト組合わせ+少々の改造は、 ディストリビューション屋さんに任せましょう。 454 名前：login:Penguin mailto:sage [03/04/27 15:36 ID:PuFritwf.net] でも、いくつかのsubgroupはクソなので困るんだよね。 455 名前：login:Penguin mailto:sage [03/04/27 16:21 ID:TW4m7+2W.net] >> 450 実装も何気に多い罠 1. locale名の標準化とlocaledefの提供 　ja_JP.ujis -> ja_JP.EUC-JP 2. netscape4.xの不正なmultibyte処理で落ちるバグ対策 　mozillaが使い物になりはじめてた時期であんまり意味なし 3. Xlib-I18N 　Xlocaleのdynamic module化 -> XFree86にmerge済(iconv依存部以外) 　XomCTL(by Sun) -> いまどうなってんの？ CSI xterm -> UTF-8 xterm/luitの出現に敗北 4. GNU toolのmultibyte対応化(by IBM) bash(readline)、grep、sed、gawkなど、現在本家へのmergeが進む 5. その他いろいろ(Big5をISOに〜etc...) あとは前世のNLS分科会での 1. glibc2のmb/wcとlocaledefで日本語が通る為の修正 2. gettext catalogのcontrib などもあるわけだが。 標準化ならthread-safe localeとかnetwork transparent localeとか もっと大風呂敷を広げてくれって感じ。 (Open groupのdistributed localeみたいな) >>451 > いくつかのsubgroupはクソ maja(ryっすか？ 456 名前：login:Penguin [03/04/30 03:11 ID:3+jGzA7G.net] まずは、C言語、C++言語の国際標準を改定させてcharという型名を バイトの代わりにつかうことを禁止させて欲しい。octet とか、byte という型名に変えて欲しい。すべてはまずそこからだ。 Fortran言語も、もしも型名characterが本当に採用している文字表記の 文字１字に対応しているのならよいが、そうでないのなら、octetとか asciiとかbyteというような型名に国際規格を変更して欲しい。 457 名前：login:Penguin mailto:sage [03/04/30 03:35 ID:3ObV2i6L.net] >>453 int8_t〜int64_tとかuint8_t〜uint64_tとかquad_tとかご存知無い？ stdint.hとかC99の仕様を一読してから再度ご来場願いたい 458 名前：login:Penguin [03/04/30 05:40 ID:3+jGzA7G.net] char がC/C++言語として使える限り、あれを文字型と称するかぎり、 コードからcharを文字のデータに使うコーディングが無くなる ことはない。 459 名前：(・∀・)ｙ−~~~　 [03/04/30 06:32 ID:1OhVc4dx.net] homepage3.nifty.com/coco-nut/ 460 名前：login:Penguin mailto:sage [03/04/30 06:42 ID:cbI0AZKf.net] 型なんて飾りです、若い香具師にはそれがそれが判らんのです 最近はJavaあたりの影響か、くだらんこと気にする香具師が増えたのか？ char = iso646ってことで、文字型と呼んどきゃいいじゃん 461 名前：login:Penguin mailto:sage [03/04/30 11:41 ID:tIYWtx7i.net] >>455 規格書、ちゃんと読んだ方がいいんじゃない? charのbit幅について、とかさ。 君がchar = UCS-4な実装するのは誰も止めないぞ。 さらにスレ違い。 462 名前：login:Penguin mailto:sage [03/04/30 22:48 ID:lotq/ow/.net] plain Cで書くのを禁止にすれ。 463 名前：login:Penguin [03/05/04 13:33 ID:E/rgpU1m.net] 結論として、多言語混在の文書を書くには、 UTF-8がベストなのか？ 464 名前：login:Penguin mailto:sage [03/05/04 22:04 ID:LYzzLtSd.net] >>460 > 多言語混在 UTF-8/UnicodeだとHan-Unification問題、fontの問題がありますが何か？ 言語タグで解決するくらいならISO2022で良かった。 465 名前：山崎渉 mailto:（＾＾） [03/05/22 02:03 ID:VfjbtMwi.net] ━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━― 466 名前：login:Penguin mailto:sage [03/05/29 14:48 ID:njol5Zmj.net] 欧米人には utf-8 めちゃくちゃ受けがいいんだよ。 らくちんだもんな。 467 名前：login:Penguin mailto:sage [03/06/01 02:26 ID:fkUOiXAk.net] >>461 ISO 2022マンセーなのは日本人だけ。 >>463 ISO-8859-1→ISO-8859-15よりISO-8859-1→UTF-8の方が都合がいいんだろ。 468 名前：login:Penguin [03/06/01 15:14 ID:xEapgirA.net] 保全age 469 名前：login:Penguin mailto:sage [03/06/02 00:06 ID:RU4bgj1/.net] ISO-8859-1以外だと即変換テーブル必要になるUnicodeはアフォ。 470 名前：login:Penguin mailto:sage [03/06/02 04:55 ID:CmpL8QI9.net] よく知らんが、 サーゲなんとかペアで Han Unification は解決できるの? というか、iso-2022 <-> unicode の変換が一意にできるような標準は できてないの? 471 名前：login:Penguin mailto:sage [03/06/08 00:06 ID:wjasDkQy.net] >>467 > サーゲなんとかペアで Han Unification は解決できるの? サロゲートペアってのは16bitで足りねーから建て増ししたってだけの話。 Han-Unificationってのは同じコードポイントであってもCJ(K)でグリフが違うって話。 よって両者は無関係。 過去のUnicodeと互換性を無くしてまでこれらの文字に新しくコードを 割り当てる英断を期待しろとでも？ > というか、iso-2022 <-> unicode の変換が一意にできるような標準は ISO2022は文字コードではないぞ。 Unicodeは過去の文字コードとの互換性をISO8859-1以外一切無視してるので 計算による変換は不可能。変換テーブルはftpで公開してるが内容についてはかなりアヤシイ。 472 名前：login:Penguin mailto:sage [03/06/08 01:08 ID:ZOaY8FC3.net] 「言語タグ」を使えば理論的には可能じゃない？ まあ、実装する奴がいるとは思えないが(ｗ 473 名前：login:Penguin mailto:sage [03/06/08 18:33 ID:wjasDkQy.net] Unicode 14面に入ってるからいずれ実装せざるを得ないんだろね ＞言語タグ もしくはxmlのlang属性とかpangoとかplain textで直接文字列操作しないのがあたりまえになるか。 474 名前：login:Penguin mailto:sage [03/06/09 04:56 ID:jVTEBnNx.net] >>468 > 過去のUnicodeと互換性を無くしてまでこれらの文字に新しくコードを > 割り当てる英断を期待しろとでも？ 結局 unicode では、漢字圏の多国語同時表示はいつまでたっても 期待できないんですか? emacs の iso-2022-7bit の方がまし? 475 名前：login:Penguin mailto:sage [03/06/09 08:22 ID:8Cy1V2dg.net] 漢字圏の多国語同時表示なんかより、☆とか⌒…とか、記号すらまともに表示できない糞環境をなんとかすれ。 476 名前：login:Penguin mailto:sage [03/06/09 23 ] [ここ壊れてます] 477 名前：:02 ID:/M+iPP4I.net mailto: >>471 いや、出来るよ。固定16bit幅の文字エンコーディングじゃなくなっただけで。 まあ、内部的には21bitあれば、固定幅に出来るけども。 [] [ここ壊れてます] 478 名前：山崎 渉 mailto:（＾＾） [03/07/15 11:28 ID:doz396Fq.net] 　__∧＿∧_ 　|（　　＾＾ ）|　＜寝るぽ（＾＾） 　|＼⌒⌒⌒＼ 　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉 　　 ~￣￣￣￣ 479 名前：ぼるじょあ ◆yBEncckFOU mailto:（＾＾） [03/08/02 05:35 ID:GfRe8vK7.net] 　　　 　∧＿∧　 ∧＿∧ ﾋﾟｭ.ｰ　（　 ・３・） (　　＾＾ ） ＜これからも僕たちを応援して下さいね（＾＾）。 　　＝〔~∪￣￣￣∪￣￣〕 　　＝ ◎――――――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉&ぼるじょあ 480 名前：login:Penguin mailto:sage [03/08/07 06:03 ID:13nJB4vb.net] ja_JP.EUC-JP って、なんか意味あるんですか？ 実は ja_JP.eucJP とは微妙に違うコードセットだったりするん でしょうか？ 全く同じコードセットだとすると、また新しくlocale名の変種が 増えるだけで、ソフトウェア作成の手間が増えて不便になるだけ のような気がするんだけど。 ひょっとして、MIMEのcharset名が全てlocaleのコードセット名と しても使えるようになるんですか？ en_US.ISO_8859-1 とか ja_JP.CSEUCPKDFMTJAPANESE も可能に なるの？ 481 名前：476 [03/08/07 06:05 ID:13nJB4vb.net] 失礼、age忘れました。

---

---

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

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