- 1 名前：ﾓ･ｸ･ﾍ･ｹ菽ｦｯ [01/10/16 00:18 ID:ZujZqkcr.net]
- Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。
- 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忘れました。
- 482 名前：login:Penguin [03/08/07 17:06 ID:ZrTxZZCU.net]
- lists.debian.or.jp/debian-devel/200306/msg00011.html
[debian-devel:15660] Re: ja_JP locale name
- 483 名前：login:Penguin mailto:sage [03/08/07 21:05 ID:13nJB4vb.net]
- つまり、コードセット名は全て大文字にしなきゃいけない
ことに新しく決まったから eucJP から EUC-JP に変えるっ
てことなのか。
で、なんで全て大文字にしなきゃいけないってことになったの？
互換性を崩してまで統一するメリットってなんなんだろう？
- 484 名前：476 [03/08/07 21:07 ID:13nJB4vb.net]
- またもage忘れ。すんません。
- 485 名前：login:Penguin [03/08/07 22:23 ID:OLNWypPZ.net]
- んなどーでもいいことやる暇があったらja_JP.CP932でもサポートした方が良さそうだが。
- 486 名前：login:Penguin mailto:sage [03/08/07 22:37 ID:/bM3o4Ra.net]
- >>481
ja_JP.SJISがサポートされない理由についてはBruno Haibleが
バックスラッシュがどうたらこうたら言ってたという話を
どこかで見たような気がする。
- 487 名前：login:Penguin [03/08/07 23:04 ID:OLNWypPZ.net]
- >>482
サポートしている商用Unixもあるんだから技術的には不可能ではないと思うのだが、やっぱりめんどくさいからなのかな。
- 488 名前：login:Penguin [03/08/13 01:01 ID:vZiKmtQp.net]
- とにかく文字はアトミックなデーターとして、内部構造に依存せずに
プログラム言語から素直に処理できるのが良い。３２ビットを
１文字にするのが、絶対にいいよ。
- 489 名前：login:Penguin mailto:sage [03/08/13 01:49 ID:Hpn4pIg2.net]
- そうは言っても、Unicodeは半角全角問題とか、
ハイフン問題とか、decomposed正規化とか、
サロゲートペアとかあって一筋縄ではイカンわな。
毛ちょっと何とかしてほしひ。
- 490 名前：login:Penguin mailto:sage [03/08/15 15:29 ID:CM17UZsB.net]
- この文脈でのatomicの意味が分からん。
statelessなencodingのことをいってんのか
thread-safeなlocaleとwchar_t(たとえばwchar_tをUCS4にするとか)のことを
いってるのかｻﾊﾟｰﾘ。
そもそも文字コードといってるのはCCSかCESどっちよ？
- 491 名前：login:Penguin [03/08/15 20:48 ID:d8HSbf3p.net]
- ↑皿仕上げ
- 492 名前：login:Penguin mailto:sage [03/08/15 22:05 ID:uQ1Z8d9X.net]
- 定期的に
www.ietf.org/rfc/rfc2130.txt
www.unicode.org/unicode/reports/tr17/
www.w3.org/TR/1999/WD-charmod-19991129/
あたりすら読まん厨がage続けるスレはここですか？
- 493 名前：山崎 渉 mailto:（＾＾） [03/08/15 22:08 ID:dil3w4kp.net]
- (⌒V⌒)
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
- 494 名前：山崎 渉 mailto:（＾＾） [03/08/15 22:38 ID:dil3w4kp.net]
- (⌒V⌒)
│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
⊂| |つ
（＿）（＿） 山崎パン
- 495 名前：login:Penguin [03/08/16 10:25 ID:+/Q/RORk.net]
- ATOMICということは、その言語の通常の操作では、内部構造がなくて、
分割できない塊としてのみ操作ができるという意味だよ。
たとえばＰａｓｃａｌ言語では、整数型や実数型、文字型、ポインタ型
などのデータは、その内部構造や内部表現にはＰＡＳＣＡＬ言語としては
立ち入ることが出来ない。（もちろん普通は実数も整数も、バイト単位
で構成されていたり突き詰めれば二進数ビットで符号化されているわけだが、
言語仕様上は、そのような内部事情にはアクセス手段がない。だから
化学での原子のように扱える。内部に核があって電子があって、陽子中性子
があるというようなことはとりあえず考えないでいこうということ。）
- 496 名前：login:Penguin mailto:sage [03/08/17 14:20 ID:fizQt/ca.net]
- で、どのレイヤを指して文字ってんのよ？
- 497 名前：login:Penguin mailto:sage [03/08/18 11:47 ID:qg3zTJIe.net]
- 超今更だが、>>37が過ちを犯している。utf-8の漢字は3byteな。
- 498 名前：login:Penguin mailto:sage [03/08/20 00:41 ID:mKHd8Wgb.net]
- >>493
最小で3byteですが最大では6byteですよ
- 499 名前：login:Penguin [03/10/20 03:44 ID:Z7b4Bpl5.net]
- (゜ω゜)ポカーン.....
- 500 名前：login:Penguin [03/11/30 01:44 ID:57WnbG8d.net]
- すいませーん、
オンラインで EUC-JP の規格を参照できるようなサイトはありますか?
文字テーブル（コードvs典型的なグリフ）とかもあると助かるのですが。
>> 165
結局、EUC-JP の 0x21 から 0x7E のあたりって、ASCII なんでしたっけ、
それとも JIS X 0201 ローマ字を使うんでしたっけ?
なんとなく ASCII だと思い込んでいたんですが。。。
Unicode と旧来のエンコーディングを行ったり来たりする処理を使うことが
ときどきありますが、この「ASCII か JIS X 0201 ローマ字か」でいつも
頭が痛いんです。困っているのは僕だけじゃないと思いますが....
どうにかしてくれ > 偉い人
- 501 名前：login:Penguin mailto:sage [03/11/30 03:21 ID:W0msD5oz.net]
- muleに付いている文書、ISO2022.jaを読めば?
www.iana.org/assignments/character-sets もね。
そもそも www.unicode.org/Public/UNIDATA/ じゃないのか?
- 502 名前：login:Penguin [03/12/01 03:18 ID:SviQyXwA.net]
- どうもさんくすです。
> muleに付いている文書、ISO2022.jaを読めば?
これは「規格」なのかどうかはよくわかりませんが、
xemacs を調べてみると、etc/CODINGS というファイルで euc-japan は
ASCII を使うようになってるみたいですね。（僕が見方を間違えていなければ）
> www.iana.org/assignments/character-sets もね。
こちらも、ASCII っぽいですね... ってことで ASCII と思っていいのかな?
> そもそも www.unicode.org/Public/UNIDATA/ じゃないのか?
えーと Unicode の方は規格を知らないということじゃなくて、
例えば Unicode -> ShiftJIS での reverse solidus 問題とかの、
既存のエンコーディングとのからみの話です。もはや、Unicode と既存のエン
コーディングの対応が整備/修正されるのは諦めるしかないのかなあ、なんて
思ったりして。
たぶん、これってもう何度も何度も繰り返された話題でしょうね、ｽﾏｿ。
- 503 名前：>>497 [03/12/01 04:03 ID:YFXe237k.net]
- >>498
規格読みたければ、JISの規格票買えよ。Copyrightがあるからwebでは読めん。
> 文字テーブル（コードvs典型的なグリフ）とかもあると助かるのですが。
もすっきり解決するぜ。印刷に使っているfontも完璧(?)だから。
>>498
> 例えば Unicode -> ShiftJIS での reverse solidus 問題とかの、
> 既存のエンコーディングとのからみの話です。
風間Java国際化本読め。
大体文字使っている奴が reverse solidus として使っているか、
yen sign として使っているか、全くわからんのだから、
文章書いた奴以外完全な解決はできん。そいつも忘れてるかもしれん。
ただ、EUC_Japanなら 0x5c を yen sign として(間違って)使ってる奴は極少だろうがな。
|
 |
