EUCボクメツ委員会
■ このスレッドは過去ログ倉庫に格納されています
0001ﾓ･ｸ･ﾍ･ｹ菽ｦｯ
01/10/16 00:18ID:ZujZqkcrICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。
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:lWARrYsy0385login:Penguin
02/11/24 02:37ID:SVTsCyE/文字幅って表示をヌキにして(単純にlibcレベルで)判定できるものなのかな...
たとえば「★」や「”」が全角幅のフォントと半角幅のフォントがあって
(efontなんか半角だったな...)
これをwcwidthで判定すると(wcwidthはフォント情報なんて知らないから)
どっちも同じ幅を返す
しかしたとえば XwcTextEscapement なんかで幅をもってくると
差がでてくる
そんな場合はどっちを信用したらいいか
やっぱり表示に用いられる条件ヌキにして文字幅情報の判定は困難かと
(そのヒントだけならなんとか...?)
なんか勘違いしていたらスマソ
0386login:Penguin
02/11/24 02:49ID:5DSLS8t6http://slashdot.jp/journal.pl?op=display&uid=64&id=77518
0387login:Penguin
02/11/24 02:55ID:21x7eWWmそれが問題じゃねーかな。
0388login:Penguin
02/11/24 04:30ID:YgGFtLsl結局ロケールってば、要は抽象化プログラミングなんすよ。
そーゆーのが得意な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ごととか、細かく
# 別オブジェクトにする必要あるだろーけど、いーかげんに書けばこんな感じでしょう。
ごく普通のプログラミング手法だと思うけどな。
0389login:Penguin
02/11/24 04:34ID:YgGFtLsl中身は (言語)-(地域)-(文字符号化方式)に応じて手前らお好き勝手に実装せい、
んで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; 程度のもんです。
0390385
02/11/24 12:35ID:toan50Vo固定幅文字用のフォントをみても、同じ文字がフォントによって
全角/半角と変わったりする場面があるんで、表示と切り離して
文字幅を考えることができるのかなと...
もっとも、表示をきちんと(ずれないように)行う、という意味では
Xwc(mb)TextEscapementなんかつかってまじめにピクセル位置を
求めるのが正攻法っぽいけど。
ただ、ISO10646のフォントでXwcTextEscapementがちゃんと動かない
場面があった(それはうちの環境の問題だな...)と、
じゃぁということでwcwidthを使ってみると、EUC-JPやSJISと
文字幅がちがうものがあったりということがあったんで
...失礼しました
0391370(==373,382)
02/11/26 03:23ID:Lk149imn> #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だけでは
ないはず。
0392login:Penguin
02/11/26 11:34ID:/BqcUjeRあの思い切った姿勢が大好き。
0393マカース受信中
02/11/26 13:14ID:6Jv4mTS/#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の表現能力の限界」っすね。
0394login:Penguin
02/11/26 13:42ID:9t3zkyFpで、strlen<ucs4>()
これ、最強。
……素直にC++使っとけ。
0395login:Penguin
02/11/26 21:58ID:Lk149imn0396login:Penguin
02/11/27 03:21ID:HhmqaFh8文字コードによらずにかけるべきだというものだ。
英語のサンプルプログラムを書いた本があったときに、
それを日本語翻訳して、サンプルプログラムの中の文字列とかコメントを
日本語に直せば（文字数が変るのは別として）、それで正しいプログラム
になるというようなもの。（英語と日本語の文法の違いは考慮しない。）
たとえば
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 函数なども、全部同じ書き方。
もちろんソースは４バイト固定長の文字によりかかれているものとする。
0397login:Penguin
02/11/27 03:21ID:HhmqaFh8文字を処理する場合に、全角だとか半角だとか、幅が１だとか２だとか、
内部表現が１バイトだとか２バイトだとか３バイトだとか４バイトだとか
そういうことをぐちゃぐちゃとまぜこぜにしているから、頭が混乱するのだ。
文字「A」はもじ「A」であって、字形とか内部表現の文字数とか、表現
コードの種類とか、いろいろなことを気にしてプログラムを書いたら、
気が散っていけない。どうしても必要な時にはフォントの幅とか字体とか
内部表現のコード系を考慮してもよいかもしれないが、たとえば、日本語を
英語に翻訳するプログラムを書いているときに、幅が１か２かは関係ない。
１文字は1文字として、それが全角半角は関係なし、幅が１か２は関係ない。
そもそも、英語の活字も単語の中で幅が異なるのが正しいのだし、毛筆体なら
とかでもそうなる、しかし一端、文字の列であると認識して処理する場合に、
幅とか字体とか字形は無関係にプログラムが（望めば）かけねばならない。
エディターに表示するために、であれば、そのときには、字形やフォントの
情報にアクセスしにいって、それらを考慮したプログラムにしてもよいだろう。
0398login:Penguin
02/11/27 22:02ID:N9f6Y7xH字体字形も「幅」なるものもコンテキストによって変わるし、場合によっては「高さ」かもしれない。
行なんてモノが意味が無くなるかもしれない。
論理構造でプログラムを組んで、見た目側を独立させようなんてのは、所詮は夢物語の理想論な気がする。
HTML ですら fixed でない layout を理解できない奴らがふつーな世界なのに。
0399login:Penguin
02/11/27 22:14ID:DCJVBuF/0400login:Penguin
02/11/28 03:34ID:ZTs0Sb/2EUC にひきずられてるぐらいだと思うが(根本的には ASCII だが)。
0401login:Penguin
02/11/28 19:53ID:k3y9tCkpあとついでにwchar_t == UCS4派の方々の為に
演算子オーバロードを導入して
ucs4_t zensp = '\u3000';
wchar_t wc;
wc = zensp
をきぼー(変換不可の文字の場合はraise exception)。
これでwchar_tが特定のCCSに縛られることによる
非互換性 or 情報欠落 or 誤変換 or *政治*は発生しない。
…素直にC++(以下略
0402login:Penguin
02/11/28 20:32ID:k3y9tCkp>>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の時に意味を為さないもん。
0403login:Penguin
02/11/29 12:40ID:raYwjZ0Jなぜ \0 で終端しない?
>そもそもL'あ'なんてロケールko_KR.eucKRの時に意味を為さないもん。
xfd -fn '-*-ksc5601.1987-0' してみろよ?
0404login:Penguin
02/11/29 14:22ID:MQGqKzTm入力ミスでつ、失礼。
> xfd -fn '-*-ksc5601.1987-0' してみろよ?
おお、KSC5601とかGB2312、BIG5あたりにも平仮名ってあったのね、Thx.
じゃー s/ko_KR.eucKR/ru_RU.KOI8-R/とでもしとおきまつ。
0405login:Penguin
02/12/01 05:03ID:wdAcIpdA0406login:Penguin
02/12/15 02:05ID:Ra09IIC20407login:Penguin
02/12/15 04:06ID:JcBJBO9o0408login:Penguin
02/12/15 04:35ID:95NNaRk10409login:Penguin
02/12/15 21:24ID:7gUpNzERASCIIがMS-BASIC, MS-DOSのために考えたから。
0410login:Penguin
02/12/16 01:54ID:bS9goAzKバイトの列と捉えること自体が、既に既存のASCII的
英米中心主義に足をとられている証拠だ。文字の実現が
何バイトであるかを知らずとも、char が文字１つを
あらわし、文字は何か特別な処理（函数を呼び出すなど）を
しないかぎり、内部構造を見られないものとして、プログラムが
かけなければ、いつまでたっても、ぐちゃぐちゃのいきあたり
ばったりでわけのわかりにくいソースコードの地獄から抜け出られないよ。
実数（単精度でも倍精度）でも、通常は、内部の二進表現がどうであるか
を気にしなくてもプログラムがかけるように、文字も内部で同表現されて
いるかによらずにソースプログラムがかけるようなインフラの土台を
作るべきなんだ。
そのためにも、一番適当なのは、いまや３２ビット固定幅の文字であり、
従来のシステムからの移行の便宜を考えるならば、コンパイラには、
ソースがどういう従来の文字コード体系でテクストとしてかかれているかを
オプションとして引数に渡し、でてくるオブジェクトは、すべて３２ビット
固定幅の文字コードを前提とした出力とするのがよい。
とにかく、英米以外の国々は、行き当たりばったりの変な文字コードと
その処理の複雑さや函数の仕組みなどにより、ASCIIオンリーでプログラミング
ができる場合に比べて過大ともいえる苦労を強いられてきた。バグも多くなる。
開発コストも高い。 いまや多少の性能、容量のオーバーヘッドを犠牲にして
でも、ソフトが自然に、まるでASCIIのみしかない場合のように書けて、
32ビットに収まるほぼ全世界の文字をひとつのソースで、ロケールなど気にせずに
処理できる、そういう理想郷が必要だ。
面倒で不便なその場当たりなコードのために英米に比べて日本などの国々は
著しい文化的不利益を被ってきたし、このままだと被りつづけることになる。
今こそ、この状況を跳ね返して、英米中心主義のコード体系、計算機言語や
ライブラリーにNOといおう。
0411login:Penguin
02/12/16 01:58ID:CE1D5wUJ0412login:Penguin
02/12/16 02:44ID:kZumFsPJMS-DOS が出る以前に ShiftJIS を見たのは幻だったのか…
0413login:Penguin
02/12/16 06:44ID:4qHLRA5Wせめて、「包接基準」程度の言葉を覚えてから書こうね。
0414login:Penguin
02/12/16 07:26ID:FwnNqLr5この字でええんかと小一時間
0415login:Penguin
02/12/16 18:51ID:klsjmqv90416login:Penguin
02/12/18 04:11ID:pxr5ilKA0417login:Penguin
02/12/18 04:17ID:9zCa8KtI萎えた状態で 3mm でも皮被ってたら包茎ですか？
カリ首が見えないとダメですか？
0418login:Penguin
02/12/21 01:50ID:EFgh3ncW>>410
> 32ビットに収まるほぼ全世界の文字をひとつのソースで、
> ロケールなど気にせずに処理できる、そういう理想郷が必要だ。
まあ、ロケールが文字コードだけの問題と思っているようじゃ...
0419IP記録実験
03/01/08 22:08ID:+M/1sqI1http://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を提出することがある。
0420login:Penguin
03/01/09 01:25ID:0uJfVOg+0421login:Penguin
03/01/09 01:36ID:0uJfVOg+0422IP記録実験
03/01/09 02:01ID:Eya/RVuphttp://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を提出することがある。
0423login:Penguin
03/01/09 02:09ID:I0ACnG/A0424login:Penguin
03/01/09 02:48ID:h7UDho/FIPを記録しないでくださいお願いします
0425login:Penguin
03/01/09 03:31ID:mK/aEqnH0426山崎渉
03/01/15 11:30ID:+BGYmUVc0427login:Penguin
03/02/18 02:10ID:pSq8jkiV0428login:Penguin
03/02/24 13:15ID:xcdIcF3X馬鹿ですか？8ビットコードをSJIS無くしてEUC統一ならともかく。
0429login:Penguin
03/02/24 14:27ID:mKA/Y3vi今更EUCに8ビットコードを統一なんて非現実的な事をいうほどは馬鹿じゃない。
0430login:Penguin
03/02/24 18:43ID:JRC7EHKD数多く存在する模様。
■ このスレッドは過去ログ倉庫に格納されています