EUCボクメツ委員会
■ このスレッドは過去ログ倉庫に格納されています
0001ﾓ･ｸ･ﾍ･ｹ菽ｦｯ
01/10/16 00:18ID:ZujZqkcrICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。
0284login:Penguin
02/02/27 12:59ID:EMez+aasネット上のゴミにしかなってないんじゃ。。。
0285login:Penguin
02/02/27 13:01ID:2qxooejq0286login:Penguin
02/02/27 13:05ID:Fv8Z2UaF0287login:Penguin
02/02/27 13:07ID:5Le7VrIb見るか見ないかじゃなくて、必要かどうかを言いたいんではないかと。
意味合いも用途も同じなのに別のコードが割り当てられてるのは
プログラム上で同一に扱いたいとき面倒なだけでメリットが何もないし。
# まぁ、いまさら廃止したとしてもユーザが使い続けてる限り
# 撲滅はできないとは思うけども。。。
0288login:Penguin
02/02/27 13:24ID:HUK2U80k(データ処理側で変換するとしても)
IMEではdefaultで半角英数にしておけばいいのにね。
WindowsのPPP接続の電話番号設定ではよくあるトラブルの一つだな。
Dailup widzardが半角変換しないから。ユーザ名とかも。
0289login:Penguin
02/02/27 23:41ID:xsQ6CV0uそういや，
[0x80〜0xFF]x任意個＋[0x00〜0x7F]で１文字を表すようなコードって
誰も提案しないの？
＃まあ，UTF-8の変形ですかね．
これだったら任意数の文字を表現できるけど，プログラム処理は
そんなに大変にならないと思うんだけど．
0290289
02/02/27 23:48ID:xsQ6CV0u\とか/とか:とかのコードは外さないと危ないじゃん．
逝ってきます……
0291login:Penguin
02/02/28 01:40ID:tMYcWs/Nテキストの規格が普及してれば
全角と半角とで苦労したりしなくてすむのに。
ascii と JISX0208 で意味的に重なっている記号を
同一視するとかの問題もなくなるし。
0292login:Penguin
02/02/28 03:52ID:hiYdbzc9「メールで半角カナは良くない」っていうのが広まる直前に、
DoCoMoのアホ共が!
ISO-2022-JPに含まれてねーだろ<JIS X 0201カナ集合
0293292の続き
02/02/28 03:56ID:hiYdbzc9上でも書いてる人いるけど、何故デフォで全角英数にする?
Justsystem何考えてるんじゃー。
それともなんらかのメリットがあるのか?
0294login:Penguin
02/02/28 04:51ID:WilwHU5r電話会社は今でもどんどん絵文字増やしてるね。
まあencoding schemeが滅茶苦茶なのはもう諦めるから、
せめてcharacter setをちゃんと登録して、
そのcode pointくらい発表して欲しい。
0295292
02/02/28 05:01ID:hiYdbzc9絵文字は論外だと俺は思う。
しかしこれは彼女の話なんだが、
「絵文字をセンス良く使う人は好感がもてる」
有効性(?)って点からは、iモードの絵文字は功罪半ばするところだ。
DoCoMoの絵文字コードポイントは
http://www.nttdocomo.co.jp/mc-user/i/tag/emoji/
もうふやさんでほしい……
0296login:Penguin
02/02/28 07:02ID:3yJTluRp縦書きの時に、縦に書く文字と横に書く文字の違いとして使われている事がある。
そんなのは書式で表現するべきとの意見もあるでしょうが、書式で表現するべき違いか、キャラクターセットで違いを出すべきかは、文化による要素が大きい。
たとえば「…」は、英文の「...」という三点リーダ表現を日本語に取り入れ、縦書きの時に中央揃えになった記号です。
ですので横書きの時には、同じと見なされるべき文字なのです。
さらに「……」と「‥‥‥」という、日本で発達した六点リーダの表現方法が２種類あるキャラクターセットとなってしまっています。
これらに対して、書式で表現するべきで、キャラクターセットが間違っている、と言っても仕方無い話です。
全角英数字も同じ事ですよ。利用実体を認めないと、無意味な議論でしかないです。。
0297292
02/02/28 09:10ID:hiYdbzc9後半は勉強になった。ありがとう
全角英数・半角カナは静かに消えていくべきものなんだから、
新しく「存在理由」を与えないで欲しい。
・(半角かなの場合)メールに文字をたくさん詰め込める
・複数行アスキーアートで使い分け
鬱……
0298login:Penguin
02/02/28 09:49ID:qz/FHA4q絵文字自体の存在意義と文字コードの割り当ては同一視すべきではないと思うよん。
漢字や平仮名等の文字よりも遙かに流行り廃れの激しい領域だから、
コードを割り振って一般的に使えるようになった頃にはもう必要なく
なっているという事態ではないかと思われるけど。
（それは画像として送ってくれってこと）
結局のところアナログな「表情」や「意志」をデジタルな文字として
表わすこと自体に無理があるといえばそうなんだけど。
0299292
02/02/28 11:12ID:hiYdbzc9DoCoMoがSMTPをコミュニケーションの手段として選んだため、
画像を文章に混ぜるのは(不可能ではないが)難しい。
となると、既存の文字を組み合わせて作る「顔文字」という
方法があるわけだが、端末の画面サイズが決めうちため送信者の
意図通りに表示されないことが多々ありえる。
そのため(問題はあるが)「絵文字」を定義するのが一番コストが少ない。
上は俺の推測。
だから、DoCoMoが勝手に絵文字をぶち込んだのは理解できる。
# むろん納得はできないがな
しかしそれより問題なのは半角カナだ。先のことを考えたなら、
メリットよりデメリットの方が大きいと思うんだが……
0300login:Penguin
02/03/01 00:46ID:9t6ixOpM格納されてるの? sjis の空き?
0301292
02/03/01 05:04ID:rxMXOdIkユーザ定義文字(外字)用の領域のうち、後ろから10%弱に
つっこまれてる
0302login:Penguin
02/03/01 11:27ID:LxuMhOts>>295のURLを見よ。
0303login:Penguin
02/03/23 12:57ID:qVojErfB0304login:Penguin
02/04/12 22:58ID:ee9Vglvq0305login:Penguin
02/04/19 17:08ID:IRZ7c+3a0306login:Penguin
02/05/19 00:25ID:SEv2YXyAiso-2022-2ch
世界初！各文字の文字幅比まで規定したcoding-system!
0x7e は tilda だが、何故か0x5cは円マークのこと。（藁
＃保全age。
0307unagi
02/05/19 00:34ID:HWW5oL9x0308login:Penguin
02/05/19 03:01ID:mYPYUKFpCoventive独自のGiga-Character-Set
http://www.coventive.co.jp/gcswhite.html
0309login:Penguin
02/05/27 00:32ID:NWrtA+hm三上喜貴著 Ｂ5変型判，384頁，7500円
http://kyoritsu-pub.topica.ne.jp/shinkan/shin0203_03.html
こんなん出るんだね。
0310login:Penguin
02/06/03 22:25ID:SlwuhY0T・UCS4を最初から作り直す
これで全てOKだよ。互換性問題以外は。
0311login:Penguin
02/07/02 02:05ID:zRK+hHNjC言語の文字を表す型名char をバイトサイズのデータ型と混同して
プログラミングで使うというスタイルが実に良くない。
既存のCで書かれたソースをすべてchar を byte という型名で置き換え、
Charという型名でもって、４オクテット文字をあらわす型名とし、
従来のアスキーコードは右端のバイトに埋め込み、Charが符号無しか
符号付であるかによって左の３バイトはオールゼロにするか、
あるいは右端のアスキーコードの符号付延長とする。
GCCを改造して、文字は４オクテットとして、データ―タイプbyteを
導入する。たとえばCのソース中に 'a' と文字が書かれていたら、
それは４バイトのデータになるし、"ABCD"と文字列がかかれていたら
それは全部で２０バイトになるという具合だ。
デバイスドライバーや通信プログラムには、従来の
コードとの変換フィルターを作ったりする必要があるかもしれない。
内部コードのみ４バイトとして、通信コードにはJISを用いたり、
必要に応じて圧縮をするべきかもしれない。。。。
ともかく、文字が４バイトの固定長であって、（出来れば符号無しか
符号付かをも含めて統一すべきだ）くれれば、ものごとは
実に単純明快になる。
0312login:Penguin
02/07/02 04:50ID:yx04ZA8s0313login:Penguin
02/07/02 05:34ID:W8RRbPwE１文字４バイトで、"ABCD"がなぜに２０バイト？
１６バイト？ それとも俺って何かぬかしてる・・・？
文字列終端のNULLも４バイトってこと？
0314login:Penguin
02/07/02 10:11ID:J9ewXkSUそだろ。
なにか問題でも？高々4倍だろ。しかも、中はスカスカだから、
圧縮率高いし。
0315login:Penguin
02/07/03 23:19ID:4sQNVHL5Unicodeだのいう前に「シフトJIS」統一してくれ…。
せめて名前の峻別だけでも…頼むよ。
0316login:Penguin
02/07/04 02:20ID:oPs3IW0a0317
02/07/17 00:41ID:TeaEgqOVOSとコンパイラが完成して広まれば、それが各国の言語で共通に使える
プラットホームとなりうる。相違点は、入力フロントエンドとか、
ワープロの文則、禁則の処理の仕様とか、かな？
＃
もしも３バイトで全世界の文字が十分に利用可能であるならば、
上の１バイトは書体をあらわす指定にすることもできるかもしれないな。
（ただ、そういうことをあまやらないほうがいいという考え方もあるな）
0318login:Penguin
02/07/17 00:45ID:TK6Nax3rできたら教えて。
0319login:Penguin
02/07/17 03:31ID:tpoiTIS/0320login:Penguin
02/07/17 14:34ID:ru8f1smn超漢字で使えるやつ？
0321login:Penguin
02/07/17 23:45ID:kNSTOrUx0322login:Penguin
02/07/19 02:49ID:PgHw/Khc0323login:Penguin
02/07/20 00:52ID:b3Zy3R0nなんでだと思いますか？
0324login:Penguin
02/07/21 09:46ID:9P133XK7いちおう、JISの1997年版で各社の違いが比較され、
JIS版のShift-JISが定義されますが？
0325login:Penguin
02/07/21 12:27ID:h3ICbItJ文字コードは 64bit
16bit 種類のベンダーが勝手に決めるコード体系に 32bit 種類の文字／グリフと 16bit 種類のフォント表現
ベンダーの管理するサーバが常時稼動
文書記述したいときは IME にどの語にどの読みとどのベンダーのどのグリフ列を与えるかの辞書を使い
文書を視認したいときはローカルなフォントでなくサーバからその都度フォントを引っ張ってキャッシュ
コード内の各グリフ、各コード間の各グリフで「同じ」か「違う」かを変換するサーバを用意
しかしハイフン様の文字、「か゜」と「が」、AとＡとАとΑを同じとするかどうかのポリシーは
ベンダーが勝手に決めてその多数決、ユーザー有志も常に多数決に投票可
マッチングのたんびに多数決の結果がどうなってるかサーバに問い合わせ
ｱﾋｬﾋｬﾋｬ
0326login:Penguin
02/07/21 20:00ID:TcSW6VAc多数決より、 option で指定できた方が良いな…
異体字の同一視とかも、その都度指定したい。
0327login:Penguin
02/07/22 03:01ID:Wv+UJQXsX68000にはあったはず。
1/4角文字とかも。
0328login:Penguin
02/07/22 21:51ID:ZW0bDY+fMSX にもあったぞ
0329login:Penguin
02/07/24 01:18ID:6Xasd6b0JIS X 0208:1997附属書1ですね。
せめて「増補改訂 JIS漢字字典」に収録の縮刷版でいいからJIS X0208と
JIS X0213を読んでから書き込んでくれ…頼むよ。
0330
02/07/26 15:10ID:hqzfU9HAたとえ漢字全体の字の形状データ―といえども、
それほどたいしたデータ―量ではないな。
DNSのシステムのように、各国にその国のコードの体系と字形を
収めたルートサーバーがいくつかあって、階層的にキャッシュ
がされていて、最終的にはローカルマシン、あるいはその直上
にはその会社のフォントキャッシュサーバーへアクセスに
いけばよいということになるかな。文字が64ビットコードであるか
32ビットコードであるかはともかくとして、昔の磁気テープの
ANSIラベルのように、ファイルにはそれに付属したラベルが
あって、そこにどのコード体系（いつの時点、バージョンであるかも
ふくめて）で記述されているかを512オクテット程度の量で指定
したものを、外部公開用のファイルの基本のやり方とすると、
１０年２０年後に、古文章を開くときに、どの文字コードで読めば
よいかということを試行錯誤しなくてよいはずだ。
0331login:Penguin
02/07/27 09:31ID:aH8wXR91古文書だと、 server の維持が大変そう…
減多に使われないけど、無くなったら誰も其の言語の file を読めなくなっちゃう…
廃れて行く言語って、結構有るみたいだし…
大きさを気にしないなら、全部画像にしちゃった方が良いんじゃないかな。
font が無くても、見る事だけは出来るから。
0332login:Penguin
02/08/06 08:27ID:mZ95nMRZhttp://www.ruby-talk.com/blade/45931
http://www.ruby-talk.com/blade/45933
以下同スレで発言多数
RubyのUNICODE対応に関するスレッドの中で、
Rubyを離れて日本人のUNICODE嫌いについて文句を言っている
I18Nにはそれなりに詳しくて経験あるようだが、
妙に鋭い所とアメ人特有の無神経さが同居しているような気がする
このスレのエラい人にこの人の意見に対する見解キボーン
0333login:Penguin
02/08/06 16:58ID:wkw+ALMi私的には、UNICODEはでっかいEUCとして使う利便性だけ得られるかと
実装はUNICODEのアホンダラ!!!!!
0334login:Penguin
02/08/06 23:39ID:5RFCcanmっていうか、[GI] [GO] マンセー
0335login:Penguin
02/08/07 20:46ID:q4PusX4LUNICODEって、Ver 1とVer 3の間に互換性がなかったような…
0336login:Penguin
02/08/07 21:12ID:1ua9JQMr0337login:Penguin
02/08/08 20:45ID:h5Ite4hL内部処理されるLinuxOSカーネルとGnu-Cコンパイラを作って、それのブート
イメージあるいはブートストラップCDイメージを作ってくれれば、案外する
するっと文字コードは固定長３２ビット・６４ビットに技術が突然シフトして
移行するかもね。きわめて自然だし、へんなUNICODEのようなアメリカ帝国主義
的な要素がないから。あとはGPLだし。
0338login:Penguin
02/08/08 21:05ID:vwpNtz+mワイドキャラクタって知ってる?このスレの上のほうでも出てきているんだけど。
0339login:Penguin
02/08/09 00:28ID:8e06bABa使い物にならないことは知ってる。
0340login:Penguin
02/08/09 00:45ID:K7okXid5(ﾟДﾟ)ﾊｧ?
ワイドキャラクタとは一文字の大きさが固定の文字列のことだぞ。
例えば、gtk-1.2.x & GNOME-1.xはシステム標準のワイドキャラクタを使って
国際化されているし、QT-2.x, 3.x & KDE-2.x, 3.xはQStringという独自のワイド
キャラクタ文字列を全面的に採用して国際化している。
どの辺が使い物にならないか言ってみそ。
0341login:Penguin
02/08/09 00:50ID:K7okXid5>>337とDIS10646.1あたりをワイドキャラクタの文字コ−ドに採用したのと
どう違うの?さらに言えば、UCS-4/UTF-32なワイドキャラクタを採用している
現行のglibc-2.xと>>337はどう違うんだ?
0342login:Penguin
02/08/09 01:15ID:8e06bABaそれぞれが独自にやりすぎちゃって互換性もクソもない。
0343login:Penguin
02/08/09 01:28ID:K7okXid5（ ﾟдﾟ）ﾎﾟｶｰﾝ（ ﾟдﾟ）ﾎﾟｶｰﾝ（ ﾟдﾟ）ﾎﾟｶｰﾝ
もう一度書こう。
ワイドキャラクタとは一文字の大きさが固定の文字のことだぞ。
ワイドキャラクタ関係の関数はISO Cで標準化されているし、そもそも本来はワイド
キャラクタの文字コ−ドに依存しないように書かなくてはならない。さらに、C99で
新しく定義したマクロにより、ワイドキャラクタの表現をISO10646として扱っても
よいことになった。
真っ当に国際化されているUNIXのどのシステムでどう独自にやっていてその結果
どう問題が生じたか具体的に言え。
0344login:Penguin
02/08/09 01:47ID:K7okXid5意味まともなところ。
UNICODE固定でやるならヘタにシステム標準のワイドキャラクタをいじったりせず、
独自に突っ走ってくれたほうがよかったりする。まあ、QTは閉じた体系でQT内で全部
行うライブラリだから、独自のワイドキャラクタでも問題ないんだが。
ただ、システム側でちゃんと国際化しISO Cの国際化フレームワークに基づいたワイド
キャラクタシステムが提供され、それを使って国際化するのが真っ当な道。ISO Cの
国際化フレームワークに従いISO Cで定義された標準Cライブラリを使って正しく国際化
するなら、ワイドキャラクタの扱いで問題が生じることはないし、互換性の問題もない。
0345login:Penguin
02/08/09 02:10ID:K7okXid5で、>>341はどうなんだい?
0346login:toor
02/08/09 02:24ID:EN04GVuNhttp://www.geocities.co.jp/SiliconValley-PaloAlto/8090/
これ読んで出直せ。
0347↑おまえの名前キモい。
02/08/09 08:35ID:VJ0HrLof禿同。
あんな互換性も糞も無いような物はさっさと滅べ。
そしてこれからはICUを使えといいたい。
ついでにg++のwstring周りのヘボさをVC、BCB程度には何とかしろともいいたい。
コメント如きの解析に失敗して下らんエラー吐いてんじゃねーよ。コメントだよ。コメント。
コメントなんざ開始記号に当たったらゴール記号まですっ飛ばせ。ヴォケが。
無駄な時間使わせやがって。コメントまで一々読んでんじゃねーよ。
つーか、STL周りもヘボすぎ、いっそのことSTLportを標準で採用しる。
0348login:Penguin
02/08/09 12:16ID:K7okXid5ワイドキャラクタうんぬん以前にSTL自体の互換性がダメダメじゃん。その
発想で逝くならSTL自体使い物にならないからさっさと滅べになるぞ。
Unicode固定ならICUでいいと思うけどね。
0349login:Penguin
02/08/09 21:07ID:8e06bABaそれらに依存したプログラムが生産されてしまうのは悲しい。
gccの L"" の実装のアホさ加減はどうにかならないのかなあ。
0350login:Penguin
02/08/09 21:13ID:rdAeGCpP0351login:Penguin
02/08/09 21:26ID:K7okXid5もう一度聞くが、>>341はどうなんだ?
君の逝っているのは互換性のダメダメな独自に突っ走ったワイドキャラクタの
一種だろ。違うか?
0352login:Penguin
02/10/14 12:33ID:JLQPtdaZ0353login:Penguin
02/10/29 20:40ID:SYhTKn3M0354login:Penguin
02/10/29 21:57ID:a4KVTkgD0355login:Penguin
02/11/10 14:02ID:KHhL1iGr0356login:Penguin
02/11/17 02:01ID:roKdiGN4透明な４オクテットコードによる実装を実現して欲しい。
ついでに官製のフリーなフォントも充実させて欲しい。
0357login:Penguin
02/11/18 03:47ID:Gf2/ARBradobe が acroread 用のフォントを自由に使わせてくれるといいんだが…。
0358login:Penguin
02/11/19 04:00ID:Bmojh6sRそいつの名前はMULTICODEで決まりですか？
0359login:Penguin
02/11/20 03:36ID:ycIE/NKT情報量を持つ漢字を扱うには根本的に無理がある
ここはやはり"肛門"は"月エ門"、"姦"は"女女女"のそれぞれ合成文字として
扱う漢字文化マンセーなCESキヴォンヌ。
しかし"多"は"タタ"なのか"夕夕"なのかでJISが大揉めになるやもしれん罠。
それに合成文字はフォントが鬼門かのう。
英語圏の人間が
grep "tel" -> telephone television telnet...
とか、接頭語等で類語を検索するように、漢字圏の人間が
grep -bushu "雨" -> 雪 雷 雹 ...
とできるようになる日がいつになったら来るのやら。
# ってテーブル用意すりゃ今でもできるけどさ。
0360login:Penguin
02/11/20 10:29ID:YEjhkZZC言うの勝手だが実装する奴の身にもなれやボケ。
まぁ、そんなことをしたら美しい日本語フォントが消滅するわけだが。
それ、日本語知らない外国人の発想だよ。
0361login:Penguin
02/11/20 12:34ID:Lrodec+Qまぁ、>>360のようなフォント(グリフ)のエンコードと文字符号化方式が区別できんアフォにも消滅してほしいわけだが。
0362login:Penguin
02/11/20 12:49ID:YEjhkZZCそんなことするなら初めから1:1対応させた方が幸せになれるわけで。
0363login:Penguin
02/11/20 13:52ID:60UMuHNB合成文字だとフォントが問題になるって話なのにどこを縦に読めば
こういうレスをつけられるのか
脊髄反射もええかげんにせえやヴォケが
0364login:Penguin
02/11/20 20:10ID:xJzR2YEl実際は半角かなと同じなんだが…
0365login:Penguin
02/11/20 21:13ID:2ILmZHLUだから合成文字の符号化と、合成後のグリフ(フォント)は別ってことでしょ。
"雨"と"田"の合成文字を表すのに"雨"と"田"のグリフを合成するんじゃなくて、
"雷"のグリフを持つ。
ただ文字符号として"雨"と"田"の合成ということがわかる符号化だから
grep 雨で"雷"がひっかかるってこと。
俺はもうUCS-4でいいやって思ってるからこんなのいやだけど。
嬲る
男女男
0367login:Penguin
02/11/20 21:29ID:ACdoqChd文章から部首で検索したい状況ってのが思いつかんが。
それよりはまだ類字・略字テーブル付きの正規表現で検索できたほうが使えそうだ。
0368login:Penguin
02/11/20 22:12ID:dTPov+yh例で言えば"雷"みたな個別の文字のグリフは持っていられないのでは
一部を持ってもいいけど、全ての組み合せは持てないでしょ
グリフが既に有る組み合せはそのグリフを使ってそれ以外は動的生成とか？
あんまし格好良いとは思えない
どっかのソフト会社が研究用にDnDで部首からグリフを生成するような
ソフトを出したという話を聞いたことがあったな、そういや
バランスの良いグリフを生成するのはノウハウの塊なんだとか
それでも一つ一つ人間がデザインしたのに比べれば、やっぱり美しくないだろうし
0369login:Penguin
02/11/21 20:46ID:zqZBnzTZ> 例で言えば"雷"みたな個別の文字のグリフは持っていられないのでは
> 一部を持ってもいいけど、全ての組み合せは持てないでしょ
持てるでしょ？符号化は文字集合の枠を逸脱しないと思うんですが。
部首でバラす符号化がJISX0208とか既存の文字集合に準拠してれば
既存のフォント(-*-jisx0208.1990-0など)はそのまま使えるよね。
つまり「男女男 = 嬲」はJISにある文字だからOKだけど「女男女」は存在しない
文字、だからエンコーディングエラー。豆腐でも表示しときゃ良いんじゃない？
まあ、現実には部首集合とそのグリフをどうするのかの問題はあるけど。
JIX0214？(w
0370login:Penguin
02/11/22 01:55ID:N/6qdEgdいわゆる国際化は出来ても、国際化の最終段階としての地域化で
非常に大きなハンディキャップを背負うことになる。
例えば句読点を特別扱いしたいという時、ISO C的に正しい
アプリケーションは、現在のlocaleを見て、いったんマルチバイトに
戻してから処理しなければならない。それを避けようと思えば、
際限無くマルチバイトctypeを増やさなくてはならない。
句読点レベルならさすがにマルチバイトに戻してもいいかも知れないが、
BiDiや結合文字のサポートがctypeレベルですら行われていないのは酷い。
その点ではUCSで統一した方がはるかにまし。
やはり、ワイドキャラクタはopaqueであるべきだ、という考え自体が
諸悪の根源だと思う。libcが提供する情報しか扱えないのでは、外部の
ライブラリのレベルで機能を追加することもままならない。
ワイドキャラクタの中が分かれば、実装ごとに提供する情報に差があっても、
アプリケーションの側が足りない部分「だけ」を実装すればいい。
UCSみたいなやり方が嫌なら、個々のロケールごと、つまり言語ごと、
エンコーディングごと、包接基準ごとにワイドキャラクタの仕様を決める
という方法もあって、それなら変な文化問題も互換問題も無くなる。
0371login:Penguin
02/11/22 05:04ID:W3DPkTzr> 例えば句読点を特別扱いしたいという時、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)とかの戻り値は各プラットフォームによってメタメタですな。
でもそんぐらいのような気がするんですけど、他なんかあります？
0372login:Penguin
02/11/22 09:07ID:qpegcL4Wその辺の市役所がアフガニスタン語が表示されなくて困ることもなし。
0373login:Penguin
02/11/23 01:28ID:thlNcqVy>いちいちmultibyteに戻さんでも、句読点をwchar_tに変換すりゃいいじゃんとか思うけど...
確かにその手はあるなあ。
>その「句読点レベル」でない処理ってーのを、もっと詳しく説明キボンヌ。
句読点を処理したい、というレベルになると、もう相当高度な自然言語処理
だから、BiDiみたいにもっと基本的な処理は一般性のある形で処理できて
ほしい、という意味で書いた。
>BIDI、結合文字はlibcが扱う範囲を越えてると思いまつ。
>Xとかcursesの扱うレイヤでは？
>libcにはwcswidth程度の実装があれば必要十分なんでは。
>何でもlibcさんのせいにしたらlibcさんが可哀想ですぅ。
Xやcursesのために、どの文字が結合文字になるか、という程度の情報は
is???()でlibcから取れるようにしておくべきだと思うけどなあ。
もちろんそれだけでは何も出来ないから、X,cursesもロケール個別の
処理をやらなくてはならないが。で、そうやって各層で国際化を
積み重ねて行くためには、どこかで情報を共有できないと困る。
そのためにはワイドキャラクタの中を晒してしまうのが一番
手っ取り早いと思うわけ。
0374login:Penguin
02/11/23 02:03ID:LOD4l8AE0375login:Penguin
02/11/23 02:23ID:8aEtw4PB本題とはずれるが、やはり日本語のベクターフォントは容量食うので
合成しようって話はあるよね。
# あくまでフォントの話
0376login:Penguin
02/11/23 04:04ID:taFbs00T> 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では機能は足りてないかも。
0377376
02/11/23 04:10ID:taFbs00T×ret = iswctype((wint_t)*s, tp);
逝ってきます....
0378376
02/11/23 04:11ID:taFbs00T○ret = iswctype((wint_t)*s, tp);
さらにもう一発逝ってきます....
0379376
02/11/23 04:20ID:taFbs00Tそのへんはisligatureは用意するとか、class名は登録制にして
char ** wctypeSupportedClassNameList()とかも必要なんすかねぇ...
0380376
02/11/23 04:28ID:s8Fyt+ei○wchar_t *s; /* <- リガチャなwide文字列 */
だめぽ。
0381login:Penguin
02/11/23 09:33ID:Jj9OvgEA0382login:Penguin
02/11/23 13:26ID:thlNcqVy> >>371で書いた通りwctype classはロケール固有に自由にclassを定義しても良いはずなんで
それが実装されていないlibcでも上のレイヤでカバーできるように
するためには、やっぱりwchar_tの中が見えた方が良くないか？
0383login:Penguin
02/11/24 01:59ID:AQbo0hieロケールだのと面倒な、ASCII文字の場合と違うソースのかき方になる
ような変なことをしなければならないのかと思うよ。
0384login:Penguin
02/11/24 02:27ID:lWARrYsy■ このスレッドは過去ログ倉庫に格納されています