EUCボクメツ委員会

1 名前：ﾓ･ｸ･ﾍ･ｹ菽ｦｯ [01/10/16 00:18 ID:ZujZqkcr.net] Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。 ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ 意味ないじゃん！ Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。 313 名前：全てOKだよ。互換性問題以外は。 [] [ここ壊れてます] 314 名前：login:Penguin [02/07/02 02:05 ID:zRK+hHNj.net] 賛成。１文字を４バイト（４オクテット）にすればよい。 C言語の文字を表す型名char をバイトサイズのデータ型と混同して プログラミングで使うというスタイルが実に良くない。 既存のCで書かれたソースをすべてchar を byte という型名で置き換え、 Charという型名でもって、４オクテット文字をあらわす型名とし、 従来のアスキーコードは右端のバイトに埋め込み、Charが符号無しか 符号付であるかによって左の３バイトはオールゼロにするか、 あるいは右端のアスキーコードの符号付延長とする。 GCCを改造して、文字は４オクテットとして、データ―タイプbyteを 導入する。たとえばCのソース中に 'a' と文字が書かれていたら、 それは４バイトのデータになるし、"ABCD"と文字列がかかれていたら それは全部で２０バイトになるという具合だ。 デバイスドライバーや通信プログラムには、従来の コードとの変換フィルターを作ったりする必要があるかもしれない。 内部コードのみ４バイトとして、通信コードにはJISを用いたり、 必要に応じて圧縮をするべきかもしれない。。。。 ともかく、文字が４バイトの固定長であって、（出来れば符号無しか 符号付かをも含めて統一すべきだ）くれれば、ものごとは 実に単純明快になる。 315 名前：login:Penguin mailto:sage [02/07/02 04:50 ID:yx04ZA8s.net] 超漢字でつかってる文字集合って4byteで表せるの？ 316 名前：login:Penguin [02/07/02 05:34 ID:W8RRbPwE.net] >>311 １文字４バイトで、"ABCD"がなぜに２０バイト？ １６バイト？　それとも俺って何かぬかしてる・・・？ 文字列終端のNULLも４バイトってこと？ 317 名前：login:Penguin mailto:sage [02/07/02 10:11 ID:J9ewXkSU.net] >>313 そだろ。 なにか問題でも？高々4倍だろ。しかも、中はスカスカだから、 圧縮率高いし。 318 名前：login:Penguin mailto:sage [02/07/03 23:19 ID:4sQNVHL5.net] レス間隔が広いな（わ Unicodeだのいう前に「シフトJIS」統一してくれ…。 せめて名前の峻別だけでも…頼むよ。 319 名前：login:Penguin mailto:sage [02/07/04 02:20 ID:oPs3IW0a.net] CP932でいいじゃん。 320 名前：　　　 [02/07/17 00:41 ID:TeaEgqOV.net] ４バイト文字コードのオープンソース、あるいはGPLのライセンスによる OSとコンパイラが完成して広まれば、それが各国の言語で共通に使える プラットホームとなりうる。相違点は、入力フロントエンドとか、 ワープロの文則、禁則の処理の仕様とか、かな？ ＃ もしも３バイトで全世界の文字が十分に利用可能であるならば、 上の１バイトは書体をあらわす指定にすることもできるかもしれないな。 （ただ、そういうことをあまやらないほうがいいという考え方もあるな） 321 名前：login:Penguin mailto:sage [02/07/17 00:45 ID:TK6Nax3r.net] >>317 できたら教えて。 322 名前：login:Penguin mailto:sage [02/07/17 03:31 ID:tpoiTIS/.net] トンパ文字は3バイトで収まりきるのか？ 323 名前：login:Penguin [02/07/17 14:34 ID:ru8f1smn.net] >>319 超漢字で使えるやつ？ 324 名前：login:Penguin mailto:sage [02/07/17 23:45 ID:kNSTOrUx.net] >>319 日本玄米茶？ 「コシヒカリっ！」 325 名前：login:Penguin mailto:sage [02/07/19 02:49 ID:PgHw/Khc.net] なんで半角カナはあるのに半角ひらがながないんですか？ 326 名前：login:Penguin mailto:sage [02/07/20 00:52 ID:b3Zy3R0n.net] >>322 なんでだと思いますか？ 327 名前：login:Penguin [02/07/21 09:46 ID:9P133XK7.net] >>315 いちおう、JISの1997年版で各社の違いが比較され、 JIS版のShift-JISが定義されますが？ 328 名前：login:Penguin mailto:sage [02/07/21 12:27 ID:h3ICbItJ.net] はるかな未来： 文字コードは 64bit 16bit 種類のベンダーが勝手に決めるコード体系に 32bit 種類の文字／グリフと 16bit 種類のフォント表現 ベンダーの管理するサーバが常時稼動 文書記述したいときは IME にどの語にどの読みとどのベンダーのどのグリフ列を与えるかの辞書を使い 文書を視認したいときはローカルなフォントでなくサーバからその都度フォントを引っ張ってキャッシュ コード内の各グリフ、各コード間の各グリフで「同じ」か「違う」かを変換するサーバを用意 しかしハイフン様の文字、「か゜」と「が」、AとＡとАとΑを同じとするかどうかのポリシーは ベンダーが勝手に決めてその多数決、ユーザー有志も常に多数決に投票可 マッチングのたんびに多数決の結果がどうなってるかサーバに問い合わせ ｱﾋｬﾋｬﾋｬ 329 名前：login:Penguin mailto:sage [02/07/21 20:00 ID:TcSW6VAc.net] >>325 多数決より、 option で指定できた方が良いな… 異体字の同一視とかも、その都度指定したい。 330 名前：login:Penguin mailto:sage [02/07/22 03:01 ID:Wv+UJQXs.net] >>322 X68000にはあったはず。 1/4角文字とかも。 331 名前：login:Penguin mailto:sage [02/07/22 21:51 ID:ZW0bDY+f.net] >>322 MSX にもあったぞ 332 名前：login:Penguin mailto:sage [02/07/24 01:18 ID:6Xasd6b0.net] >>315 JIS X 0208:1997附属書1ですね。 せめて「増補改訂 JIS漢字字典」に収録の縮刷版でいいからJIS X0208と JIS X0213を読んでから書き込んでくれ…頼むよ。 333 名前：　　　 [02/07/26 15:10 ID:hqzfU9HA.net] 確かに、プロ―ドバンドで動画がやりとりできる時代には、 たとえ漢字全体の字の形状データ―といえども、 それほどたいしたデータ―量ではないな。 DNSのシステムのように、各国にその国のコードの体系と字形を 収めたルートサーバーがいくつかあって、階層的にキャッシュ がされていて、最終的にはローカルマシン、あるいはその直上 にはその会社のフォントキャッシュサーバーへアクセスに いけばよいということになるかな。文字が64ビットコードであるか 32ビットコードであるかはともかくとして、昔の磁気テープの ANSIラベルのように、ファイルにはそれに付属したラベルが あって、そこにどのコード体系（いつの時点、バージョンであるかも ふくめて）で記述されているかを512オクテット程度の量で指定 したものを、外部公開用のファイルの基本のやり方とすると、 １０年２０年後に、古文章を開くときに、どの文字コードで読めば よいかということを試行錯誤しなくてよいはずだ。 334 名前：login:Penguin mailto:sage [02/07/27 09:31 ID:aH8wXR91.net] >>330 古文書だと、 server の維持が大変そう… 減多に使われないけど、無くなったら誰も其の言語の file を読めなくなっちゃう… 廃れて行く言語って、結構有るみたいだし… 大きさを気にしないなら、全部画像にしちゃった方が良いんじゃないかな。 font が無くても、見る事だけは出来るから。 335 名前：login:Penguin [02/08/06 08:27 ID:mZ95nMRZ.net] ruby-talk(Rubyの英語ML)で面白い奴ハケン www.ruby-talk.com/blade/45931 www.ruby-talk.com/blade/45933 以下同スレで発言多数 RubyのUNICODE対応に関するスレッドの中で、 Rubyを離れて日本人のUNICODE嫌いについて文句を言っている I18Nにはそれなりに詳しくて経験あるようだが、 妙に鋭い所とアメ人特有の無神経さが同居しているような気がする このスレのエラい人にこの人の意見に対する見解キボーン 336 名前：login:Penguin [02/08/06 16:58 ID:wkw+ALMi.net] 横槍すまソ 私的には、UNICODEはでっかいEUCとして使う利便性だけ得られるかと 実装はUNICODEのアホンダラ!!!!! 337 名前：login:Penguin [02/08/06 23:39 ID:5RFCcanm.net] そしてEBCDIC+JISへの回帰 っていうか、[GI] [GO] マンセー 338 名前：login:Penguin [02/08/07 20:46 ID:q4PusX4L.net] >> 332 UNICODEって、Ver 1とVer 3の間に互換性がなかったような… 339 名前：login:Penguin mailto:sage [02/08/07 21:12 ID:1ua9JQMr.net] そう言えば「電」はどうなった? 340 名前：login:Penguin [02/08/08 20:45 ID:h5Ite4hL.net] とにかくだれかが、１文字＝３２ビット、もしくは６４ビットとして 内部処理されるLinuxOSカーネルとGnu-Cコンパイラを作って、それのブート イメージあるいはブートストラップCDイメージを作ってくれれば、案外する するっと文字コードは固定長３２ビット・６４ビットに技術が突然シフトして 移行するかもね。きわめて自然だし、へんなUNICODEのようなアメリカ帝国主義 的な要素がないから。あとはGPLだし。 341 名前：login:Penguin mailto:sage [02/08/08 21:05 ID:vwpNtz+m.net] >>337 ワイドキャラクタって知ってる?このスレの上のほうでも出てきているんだけど。 342 名前：login:Penguin mailto:sage [02/08/09 00:28 ID:8e06bABa.net] >>338 使い物にならないことは知ってる。 343 名前：login:Penguin mailto:sage [02/08/09 00:45 ID:K7okXid5.net] >>339 (ﾟДﾟ)ﾊｧ? ワイドキャラクタとは一文字の大きさが固定の文字列のことだぞ。 例えば、gtk-1.2.x & GNOME-1.xはシステム標準のワイドキャラクタを使って 国際化されているし、QT-2.x, 3.x & KDE-2.x, 3.xはQStringという独自のワイド キャラクタ文字列を全面的に採用して国際化している。 どの辺が使い物にならないか言ってみそ。 344 名前：login:Penguin mailto:sage [02/08/09 00:50 ID:K7okXid5.net] 別な言い方をすると、 >>337とDIS10646.1あたりをワイドキャラクタの文字コ−ドに採用したのと どう違うの?さらに言えば、UCS-4/UTF-32なワイドキャラクタを採用している 現行のglibc-2.xと>>337はどう違うんだ? 345 名前：login:Penguin mailto:sage [02/08/09 01:15 ID:8e06bABa.net] > どの辺が使い物にならないか言ってみそ。 それぞれが独自にやりすぎちゃって互換性もクソもない。 346 名前：login:Penguin mailto:sage [02/08/09 01:28 ID:K7okXid5.net] >>342 （　ﾟдﾟ）ﾎﾟｶｰﾝ（　ﾟдﾟ）ﾎﾟｶｰﾝ（　ﾟдﾟ）ﾎﾟｶｰﾝ もう一度書こう。 ワイドキャラクタとは一文字の大きさが固定の文字のことだぞ。 ワイドキャラクタ関係の関数はISO Cで標準化されているし、そもそも本来はワイド キャラクタの文字コ−ドに依存しないように書かなくてはならない。さらに、C99で 新しく定義したマクロにより、ワイドキャラクタの表現をISO10646として扱っても よいことになった。 真っ当に国際化されているUNIXのどのシステムでどう独自にやっていてその結果 どう問題が生じたか具体的に言え。 347 名前：login:Penguin [02/08/09 01:47 ID:K7okXid5.net] ちなみに、独自のワイドキャラクタというところが、QTの変なところであり、ある 意味まともなところ。 UNICODE固定でやるならヘタにシステム標準のワイドキャラクタをいじったりせず、 独自に突っ走ってくれたほうがよかったりする。まあ、QTは閉じた体系でQT内で全部 行うライブラリだから、独自のワイドキャラクタでも問題ないんだが。 ただ、システム側でちゃんと国際化しISO Cの国際化フレームワークに基づいたワイド キャラクタシステムが提供され、それを使って国際化するのが真っ当な道。ISO Cの 国際化フレームワークに従いISO Cで定義された標準Cライブラリを使って正しく国際化 するなら、ワイドキャラクタの扱いで問題が生じることはないし、互換性の問題もない。 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といおう。

---

---

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

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