EUCボクメツ委員会

1 名前：ﾓ･ｸ･ﾍ･ｹ菽ｦｯ [01/10/16 00:18 ID:ZujZqkcr.net] Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。 ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ 意味ないじゃん！ Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。 296 名前：292 [02/02/28 05:01 ID:hiYdbzc9.net] >>294 絵文字は論外だと俺は思う。 しかしこれは彼女の話なんだが、 「絵文字をセンス良く使う人は好感がもてる」 有効性(?)って点からは、iモードの絵文字は功罪半ばするところだ。 DoCoMoの絵文字コードポイントは www.nttdocomo.co.jp/mc-user/i/tag/emoji/ もうふやさんでほしい…… 297 名前：login:Penguin [02/02/28 07:02 ID:3yJTluRp.net] 全角英数は、意味のある使われ方もしてますからねえ。 縦書きの時に、縦に書く文字と横に書く文字の違いとして使われている事がある。 そんなのは書式で表現するべきとの意見もあるでしょうが、書式で表現するべき違いか、キャラクターセットで違いを出すべきかは、文化による要素が大きい。 たとえば「…」は、英文の「...」という三点リーダ表現を日本語に取り入れ、縦書きの時に中央揃えになった記号です。 ですので横書きの時には、同じと見なされるべき文字なのです。 さらに「……」と「‥‥‥」という、日本で 298 名前：発達した六点リーダの表現方法が２種類あるキャラクターセットとなってしまっています。 これらに対して、書式で表現するべきで、キャラクターセットが間違っている、と言っても仕方無い話です。 全角英数字も同じ事ですよ。利用実体を認めないと、無意味な議論でしかないです。。 [] [ここ壊れてます] 299 名前：292 [02/02/28 09:10 ID:hiYdbzc9.net] >>296 後半は勉強になった。ありがとう 全角英数・半角カナは静かに消えていくべきものなんだから、 新しく「存在理由」を与えないで欲しい。 ・(半角かなの場合)メールに文字をたくさん詰め込める ・複数行アスキーアートで使い分け 鬱…… 300 名前：login:Penguin mailto:sage [02/02/28 09:49 ID:qz/FHA4q.net] >>295 絵文字自体の存在意義と文字コードの割り当ては同一視すべきではないと思うよん。 漢字や平仮名等の文字よりも遙かに流行り廃れの激しい領域だから、 コードを割り振って一般的に使えるようになった頃にはもう必要なく なっているという事態ではないかと思われるけど。 （それは画像として送ってくれってこと） 結局のところアナログな「表情」や「意志」をデジタルな文字として 表わすこと自体に無理があるといえばそうなんだけど。 301 名前：292 [02/02/28 11:12 ID:hiYdbzc9.net] >>298 DoCoMoがSMTPをコミュニケーションの手段として選んだため、 画像を文章に混ぜるのは(不可能ではないが)難しい。 となると、既存の文字を組み合わせて作る「顔文字」という 方法があるわけだが、端末の画面サイズが決めうちため送信者の 意図通りに表示されないことが多々ありえる。 そのため(問題はあるが)「絵文字」を定義するのが一番コストが少ない。 上は俺の推測。 だから、DoCoMoが勝手に絵文字をぶち込んだのは理解できる。 # むろん納得はできないがな しかしそれより問題なのは半角カナだ。先のことを考えたなら、 メリットよりデメリットの方が大きいと思うんだが…… 302 名前：login:Penguin [02/03/01 00:46 ID:9t6ixOpM.net] 絵文字は文字コードとしては実際どこに 格納されてるの? sjis の空き? 303 名前：292 [02/03/01 05:04 ID:rxMXOdIk.net] >>300 ユーザ定義文字(外字)用の領域のうち、後ろから10%弱に つっこまれてる 304 名前：login:Penguin mailto:sage [02/03/01 11:27 ID:LxuMhOts.net] >>300 >>295のURLを見よ。 305 名前：login:Penguin mailto:age [02/03/23 12:57 ID:qVojErfB.net] 保全age 306 名前：login:Penguin mailto:age [02/04/12 22:58 ID:ee9Vglvq.net] age 307 名前：login:Penguin [02/04/19 17:08 ID:IRZ7c+3a.net] age 308 名前：login:Penguin [02/05/19 00:25 ID:SEv2YXyA.net] 新coding-system提案： iso-2022-2ch 世界初！各文字の文字幅比まで規定したcoding-system! 0x7e は tilda だが、何故か0x5cは円マークのこと。（藁 ＃保全age。 309 名前：unagi [02/05/19 00:34 ID:HWW5oL9x.net] unagi 310 名前：login:Penguin mailto:sage [02/05/19 03:01 ID:mYPYUKFp.net] これどうよ Coventive独自のGiga-Character-Set www.coventive.co.jp/gcswhite.html 311 名前：login:Penguin [02/05/27 00:32 ID:NWrtA+hm.net] 文字符号の歴史 −アジア編−(ISBN4-320-12040-X) 三上喜貴著 Ｂ5変型判，384頁，7500円 kyoritsu-pub.topica.ne.jp/shinkan/shin0203_03.html こんなん出るんだね。 312 名前：login:Penguin [02/06/03 22:25 ID:SlwuhY0T.net] ・1文字32ビットにする(Charactor Set = Encodingにする) ・UCS4を最初から作り直す これで 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の表現能力の限界」っすね。

---

---

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

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