- 1 名前：ﾓ･ｸ･ﾍ･ｹ菽ｦｯ [01/10/16 00:18 ID:ZujZqkcr.net]
- Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。
- 75 名前：59 [01/10/18 16:15 ID:zQ3uDx9i.net]
- 結局 iso-2022 で多国語というのはすたれゆく運命ですか?
僕は Unicode よりイイと思ってるんだけど.
- 76 名前：login:Penguin [01/10/18 16:33 ID:YWCxX3Ha.net]
- mb/WCの区別をしなくてよくなるのならUnicodeがイイ！に決まってるが、
それは幻想だったことが決定してるので2022でよい(よかった)。
- 77 名前：login:Penguin [01/10/18 17:17 ID:gPhXvV4t.net]
- >>75
内部コードとしては一定以上高度な多言語処理ではどっちも使わん
でしょ。Emacs もオリジナルだし。
プログラマの苦労は結局かわらんので、76のいってる通り
2022でよい(よかった)ではあるんだけど、サポートの現状を考
えると、今や、Unicode が圧倒的に有利かな。Unicodeの文章が
とりあえず読み書きできる環境を持つ人はもうざらだから。
専門用途ではオリジナルコードも十分ありと思われ。というか、
実際、現在のDTPでは、最終的には adobe のコードが物を言うし。
- 78 名前：login:Penguin [01/10/18 21:01 ID:o4Mc8Bmx.net]
- 現実の話、UTFとかワイドキャラクターの導入って
あくまでもクラスライブラリとか
ウインドウシステムのインターフェースとか
ファイルシステムのファイル名の内部形式とか
そこら辺の話に終始してる。
ディスク上のテキストに関しては移行できる
と考えている人はあんまりいない。
ISO-2022が妥当だろう。
- 79 名前：login:Penguin [01/10/18 21:14 ID:YWCxX3Ha.net]
- UTFってUTF-16のこと？UTF-8を内部形式で使う奴はおらんだろう。
>ディスク上のテキストに関しては移行できる
>と考えている人はあんまりいない。
XML文書は?普通UTF-8で書くと思うのだが。
>ISO-2022が妥当だろう。ISO-2022系の多言語非対応のエンコーディング(EUC-JP他)、
という意味ならまぁそうかも。
- 80 名前：79 mailto:sage [01/10/18 21:16 ID:YWCxX3Ha.net]
- >>79
改行抜けた。mozillaたんしっかりしてくれハァハァ…
>ISO-2022が妥当だろう。
ISO-2022系の多言語非対応のエンコーディング(EUC-JP他)、
という意味ならまぁそうかも。
- 81 名前：login:Penguin [01/10/18 21:31 ID:o4Mc8Bmx.net]
- >UTFってUTF-16のこと？UTF-8を内部形式で使う奴はおらんだろう。
Ruby
- 82 名前：79 mailto:sage [01/10/18 21:33 ID:YWCxX3Ha.net]
- うお、rubyか。じゃ結構普通のことなのかな？
すみません。
- 83 名前：_ [01/10/18 23:03 ID:Hq3ecu1b.net]
- >>79
次期 GTK+ の GTK+2 も内部は基本的に UTF-8 ですな。
- 84 名前：login:Penguin mailto:sage [01/10/19 00:31 ID:Kw5tPojH.net]
- そりゃ、(EUC-JPと同じく)UTF-8は、ASCIIで済む人はASCIIと変わらんdata量で、
過去のcode資産も活用できるから、移行し易いだろ。ISO 8859-1ででもそうだし。
Unique "wchar_t"は幻想だったという事で。
- 85 名前：名無しさん＠Ｅｍａｃｓ mailto:sage [01/10/19 02:06 ID:fpLOIwDH.net]
- 名スレ化あげ
- 86 名前：login:Penguin [01/10/19 02:33 ID:QKiQs1/Q.net]
- >>84
でもRubyは国産なのに意外。なんでUCSじゃないのでしょうか？
質問age
- 87 名前：login:Penguin mailto:sage [01/10/19 03:23 ID:Kw5tPojH.net]
- >>86
処理系内部で使うprintf(3)からRuby用にかき直すんかい?
2byte目に'%'や'\'のあるcoding system(e.g. Shift_JIS)用は書き直しだぞ。
- 88 名前：86 [01/10/19 04:51 ID:QKiQs1/Q.net]
- >>87
ごめん、ちょっと意味がわからない。
（なんでprintfが使えることが重要なのか？という点が）
もし暇なら説明をお願いしたいです。
- 89 名前：login:Penguin [01/10/19 11:39 ID:wq307Z9h.net]
- 87じゃないけど…
基本としては、「アプリケーションはなるべくシステムのlibcを使うべき」
ってことだろね。きちんと整備されてるＯＳなら、libcを使うのが
パフォーマンス的にも、開発効率上も有利。それが標準の存在意義。
それから「アプリケーションの互換性重要」ってのが背景にある。
printfとかに代表される標準Cライブラリの昔からあるものってのは、
ASCII以外は設計の想定外。だから、SJISとかUCSのような、ASCIIと干渉する
エンコーディングをそれで扱おうとするとまず間違いなく誤動作する。
本来これを避けるための Wide Character なんだけど、残念ながら、
この部分は実装依存度がやたら高い。無いOSも多いし、内部構造もOS毎に
ばらばらだ。もちろん過去のコードはもちろんこんなもの使ってないわけで、
使うとしたらかなり書き直しに陥るはめになる。
そうなると、選択肢としては、なんとか char のまま、普通の libc で
扱えるようにしちゃおうって考えが浮上してくるわけだ
(技術的には逃げなので退化)
必要要件は
1. ASCII に干渉しないマルチバイト(char の配列)きぼんぬ
2. 文字区切りが確実容易なほうがイイ！
3. 何か標準に沿ってるほうがイイ！
こんなところで、それを満たす UTF-8 になるのは自然な流れだろう。
やっぱでかいのは互換要因のほうかな。完全に1から書くのなら、
UCSだろうがオリジナルだろうが好きなのを採用すればよろし。
- 90 名前：77 [01/10/19 13:05 ID:wq307Z9h.net]
- >>78
79もいってるけど、「非多言語対応」なら、ISO-2022系が
妥当だろう。実際そっちのが多いと思うし。
話の流れは「多言語用」だよね。ISO-2022-JP-2 とかを扱える環境(emacsとか)
をそろえてる人は、UTF-8 扱える環境をもってる人より少ないよねって
のがオレの指摘。
今はWinいれたらそれだけでとりあえず日常用途で使う範囲なら、読むのも
書くのもできるからね > UTF-8
- 91 名前：login:Penguin mailto:sage [01/10/19 13:10 ID:LpodI9Q2.net]
- >>45
> 情報交換符合と内部表現、
> 文字セットとエンコーディング、
> コードとグリフ、
これらの区別が説明されているサイトはありますか？
出来れば日本語ｄ
- 92 名前：login:Penguin [01/10/19 18:32 ID:mx7DeiuF.net]
- 欧米の人たちが ASCII や ISO-8859-x で足りてるなんてのは
わりと誤解で、文字をもっと増やしたいと思っている人が多いです。
XFree86 で強硬に Unicode を推進している人たちはそんな感じ。
JIS X 0208 の記号とかを使った英語のプレゼン資料とか見せると
羨ましがられるよ。
- 93 名前：login:Penguin [01/10/19 18:42 ID:mx7DeiuF.net]
- >>15
Solaris や NetBSD は SJIS ろけーるもあったかと。
Solaris だと ja_JP.utf8 とかもできるんじゃなかったかな。
Linux (つーか glibc) は内部 Unicode なんだっけ?
- 94 名前：login:Penguin [01/10/19 18:56 ID:+gP9D3Wa.net]
- >>93
linuxでもできる。KondaraではUTF-8なロケール使って、
X上でximを切り替えてCJK混在な文書とかも作れたはず。
Debian sid でもutf-8なロケール作ってやればできるでしょ？
まあアプリ全てがちゃんと動くわけではないが。
(ATOK X のメニューが化けて鬱だった記憶が）
ほかのディストリとかは知らない。
- 95 名前：login:Penguin [01/10/19 19:03 ID:Y1kLvlVv.net]
- >>91
そんなに難しい話じゃないよ。
「文字」の定義が甘いのをとりあえず横に置いとけば。
文字セット：「この文字を扱う」という範囲。各文字を識別する ID つき
エンコーディング：上の文字セットをコンピュータで表現するための数値化の方法
情報交換符合：通信、ファイルなど、外部とやりとりするための文字セット+エンコーディング
内部表現：OS やアプリケーションでの文字の内部表現
コード：数字。文字コードね。
グリフ：形。目に見えるものね。
この手のお話だと、必ずこのあたりがごっちゃになった議論になってわけわかになるので、釘さしてみただけ。
- 96 名前：login:Penguin [01/10/19 20:53 ID:PkKT5Zqx.net]
- >printfとかに代表される標準Cライブラリの昔からあるものってのは、
>ASCII以外は設計の想定外。だから、SJISとかUCSのような、ASCIIと干渉する
>エンコーディングをそれで扱おうとするとまず間違いなく誤動作する。
>本来これを避けるための Wide Character なんだけど、残念ながら、
>この部分は実装依存度がやたら高い。無いOSも多いし、内部構造もOS毎に
だから俺はCやめざろう得なかった。
Standard C++ならば標準ライブラリは全部マクロなんで
自動的に展開されて解決。
C++を嫌うならばKylixがある。
KylixはCのようなポインター操作もできるし、
GUIなしのデーモンプロセスも書ける。
ヘッダーさえなんとかすればドライバも書ける可能性あり。
Cユーザーにとって、字面以外は抵抗なしに受け入れられる。
>ばらばらだ。もちろん過去のコードはもちろんこんなもの使ってないわけで、
>使うとしたらかなり書き直しに陥るはめになる。
過去の資産に関しては同意。
- 97 名前：login:Penguin [01/10/19 20:58 ID:QKiQs1/Q.net]
- へ？？
>Standard C++ならば標準ライブラリは全部マクロなんで
>自動的に展開されて解決。
ここだけでいいから、なにが解決されるのか具体的に書いて。
- 98 名前：login:Penguin [01/10/19 21:09 ID:PkKT5Zqx.net]
- C++のstringというのはbasic_string<char>という
テンプレートマクロ。
ワイドはbasic_string<wchar_t>とするだけ。
そうすると、stringと同一の機能をwstirngが受け継ぐ。
printf("%s%d\n", s, d)は
cout << s << d << endl;
wcout << ws << d << endl;
型の定義だけでほとんどを解決し、ロジックはいじらない。
うまくいくと変数の宣言文を触れるだけで全部解決。
- 99 名前：login:Penguin [01/10/19 21:14 ID:QKiQs1/Q.net]
- >>98
ああそういう意味か。了解。
でも、話の流れは、wchar_tじゃぁ駄目って事だったんじゃ…。
#個人的にはふつ〜のアプリはWC使って書くのが好きですが。
- 100 名前：98 [01/10/19 22:30 ID:dckKBkBJ.net]
- >Unique "wchar_t"は幻想だったという事で。
wchar_tイコールUCS2でないよ。
MSの2バイトwchar_tは幻想だが。
www-6.ibm.com/jp/developerworks/unicode/000616/j_uniwchar.html
C 規格では、wchar_t に対して厳密にどれというタイプを指定していません。
- 101 名前：login:Penguin [01/10/19 22:58 ID:Kw5tPojH.net]
- >>100
> >Unique "wchar_t"は幻想だったという事で。
Uniqueというのは、
> wchar_tイコールUCS2でないよ。
> MSの2バイトwchar_tは幻想だが。
などから一つを選択してそれのみでやっていく事を目指す、というつもりで、書きました。
> www-6.ibm.com/jp/developerworks/unicode/000616/j_uniwchar.html
> C 規格では、wchar_t に対して厳密にどれというタイプを指定していません。
はもちろん知っています。
ただ、上のようにUniqueになろうと"UNI"codeは目指したと思います。少なくとも当初は。
- 102 名前：login:Penguin [01/10/19 23:03 ID:dckKBkBJ.net]
- 4バイトでUniqueになればいいじゃないか。
- 103 名前：login:Penguin [01/10/20 06:16 ID:g2GqcdkH.net]
- どうやら、このスレには、ちゃんと理解しているのが３人しかおらず、
それ以外はコード表（どれか１つでも）も見たことがない奴らだけの
ようだ
まだ、青木光恵の旦那の方が３８倍ましって感じ
- 104 名前：ななしさん＠おなかいっぱい mailto:sage [01/10/20 07:28 ID:a3ky6FMM.net]
- >>103
「ちゃんと理解している」のが3人もいれば2ch的には充分のような気も。
あと、そーいうことをいう人には、どのポストに正しいことが書いてあるの
か指摘してもらえると嬉しいかな、とか。
- 105 名前：login:Penguin [01/10/20 11:51 ID:mRQL8QGY.net]
- >>56
やっぱり謎の中国人に「アイヤー、漢字特盛りにしちゃうアルヨー」
と言わせてほしかったな。
- 106 名前：login:Penguin [01/10/20 13:09 ID:2B2NfqxB.net]
- >>102
それについては、>>65の言う通りで、>>56が詳しい(w
「もうUnicode捨てたいんと違うんか？」と小１時間問い詰めたい。
euc.jp/i18n/ucsnote.ja.html
Unicodeの安易さが持ち込んだ問題で、10646が腐るのは困る。
<!-->>102はHan Unificationの問題「だけ」を言っているのかな？-->
- 107 名前：login:Penguin [01/10/20 16:11 ID:8ZJLlTqR.net]
- このスレッド面倒だから読んでいない。
重複する内容だったら失礼。
シフトジスになぜしないかというとシフトジスには欠点があるから。
その代表的なものは0x5c問題。
0x5cはダブルコーテーションという記号だがシフトジスの漢字はこれを含む
漢字もある。
アスキーコード0x5cが文字列に入っているとシフトジスはおかしくなる。
プログラムでこの問題を回避する処理を入れないといけないがそれは大変だ。
実際、WINDOWS版のソフトでこの問題を回避できていないソフトは多い。
EUCだと、8ビット目を殺さないようにするだけで無変更でコンパイラなどが
日本語をソースに入れても問題なく使える。
それによってgccなどは英語版そのものを使ってもEUCなら日本語を入れたソース
をコンパイルできる。
しかしシフトジスだと0x5c問題にかかるので改造しないと使えない。
改造しても行の先頭から順番に読んでいかないと半角か全角か判断できないと
いうシフトジスの大きな欠点のため速度が遅くなるという欠点が出る。
仮にシフトジスに変えてしまうとほとんどのLinuxソフトが日本語使えなくなる。
- 108 名前：かといってシフトジス対応という膨大な作業を誰がするというのだろう。
シフトジス対応すると本家と英語版とソースが分岐するので古いバージョンを
使わざる得ないとか不都合がたくさんでる。
結果的にシフトジス標準は不可能だ。こんなことはプログラマーならわかると思うが 1 はユーザー専門なんだろう。 [] - [ここ壊れてます]
- 109 名前：login:Penguin [01/10/20 17:52 ID:cvBqh8vR.net]
- このスレ案外詳しいよ. スレッド名に反して役に立った.
- 110 名前：login:Penguin [01/10/20 17:53 ID:n/co2nXu.net]
- 文字の割り当ての正当さなんぞ気にしていたら
あと何百年かかるかわからんだろ。
「てめーら勝手にしろ」でコード領域広く取って
各地域24ビットぐらい割り当てちまえばよい。
で日本では従来のJISを突っ込んで終わり。
グリフだのなんだのとわめいていたら、孫の代まで
に完成しねえぞ。
- 111 名前：login:Penguin [01/10/20 19:04 ID:2B2NfqxB.net]
- >>109
それで解決するのは、Han Unificaionだけで、
euc.jp/i18n/ucsnote.ja.htmlの問題はどんどん拡大する。
# 各国内での互換性を維持できたわけだし、>>109はそれでもいいと言っているのだろうが。
しかし、以下は妥当な文字非統合だろうか？(上のURLから一部だけ抜き出した)
U+002D HYPHEN-MINUS (ASCIIのマイナス)
U+00AD SOFT HYPHEN 語中の折り返し可能個所、表示されないかもしれない
U+2011 NON-BREAKING HYPHEN (右端でも折り返されないハイフン)
U+2010 HYPHEN 複合語などの一般的なハイフン
U+2212 MINUS SIGN マイナス
:
互換性を求めて既存のを無制限に突っ込んだ挙げ句がこれ…
- 112 名前：login:Penguin [01/10/20 19:11 ID:DsyBUQBQ.net]
- >>110
それでもいい。
それは子孫の時代に解決する問題。
現状では再コンパイル一発で将来の文字コードに
対応できるインフラの整備が大事だと思う。
- 113 名前：login:Penguin [01/10/20 19:48 ID:XktlMTUg.net]
- >>107
>このスレッド面倒だから読んでいない。
>重複する内容だったら失礼。
こういっちゃなんだが、すでに、ビット並びの字面(とでもいうのか?)の話はし
てないです。
ワイドキャラクタを使用しない、m17nな独自内部コードとしては、開発効率の観点
からビットの字面が大事(UTF-8を使わざるをえない)なんていう話はでたけど話
のレイヤがかなり違う。
>シフトジス対応すると本家と英語版とソースが分岐するので古いバージョンを
>使わざる得ないとか不都合がたくさんでる。
localeとはなにか？と、mbstowcs関数をはじめとした、ワイドキャラクタを
利用したプログラムの書き方でも覚えてくれ。
すると、分岐せずに(=localizeせずにinternationalizeすることで)Shift_JIS
に移行できなくはないことがわかる。ソースコードは改変する必要はあるかも
しれんし（本家に統合は可能だろう）、OSのlocaleまわりもいじらないとい
かんかもしれないが。
蛇足だが、
何度か言われているが、character set と encoding を区別してくれ。
ISO 2022 とはなにかを理解してくれ。暇があれば UCS, UTF とはなにか
を学んでくれ。書籍もいくつかでてるが、まずは euc.jp/ を読む
とよい。
理解した上の発言ならすまん。
- 114 名前：login:Penguin [01/10/20 21:03 ID:7W8DCi3g.net]
- >>110
文字コードと文字集合を世界で統一しようという
アイデア自体には大賛成だが、ここまで致命的な問題点を
見せられると困るな。
日本だけを見てもこの状況だから、他の諸外国でも
いろんな問題があるんだろうな。
ほんと孫の代になるまで解決しそうにないな。
漏れが現役の間は EUC-JP で頑張るしかないかな。
- 115 名前：login:Penguin mailto:sage [01/10/21 01:58 ID:3nI2LT/o.net]
- Flashの日本語が読めないのは誰のせい…
- 116 名前：login:Penguin [01/10/22 00:36 ID:vff311A1.net]
- 結局, 中国語と日本語を両方ともまともに使う人から見て,
Unicode の CJK Unified は満足できるものなんでしょうか?
結局どっちかをメインとして使わないと文面の字面がキモくなる
ような気がするんですが.
それなら Emacs で ISO 2022 で違う font を使って表示した方が
ましのような.
- 117 名前：login:Penguin [01/10/22 07:46 ID:EJ6V2X5S.net]
- 16bitに無理矢理収めたくてUnifyしたのに、
>>56にあるように9万(>2^16)字になっちゃったんです。意味ないんですぅ
Unifyの意味ないのに、UnifyされたのがISO 10646.1(>>65)になっちゃったんですぅ
しかも>>110にあるように漢字以外のUnifyの基準が使いものにならないですぅ
Unicodeは文字コードの世界に新しく増えた負の遺産なんですぅ
//最近のtechnical reportは面白いのあるけど。
- 118 名前：login:Penguin [01/10/22 08:00 ID:RZQUGhKz.net]
- Emacsの内部コードって何つかってんの?
- 119 名前：login:Penguin [01/10/22 09:01 ID:7trpRy3z.net]
- HTMLってSJISは論外としてEUCとJISのどっちで書くのがいいの？
- 120 名前：login:Penguin mailto:sage [01/10/22 09:08 ID:Pupx5KWC.net]
- >>118
あんまり考えずに全文検索とかするためにはバッティングしない
EUCの方が楽なんじゃない？
- 121 名前：login:Penguin mailto:sage [01/10/22 13:05 ID:U0CK64Pe.net]
- iso-2022-jpでしょ。>>118
- 122 名前：login:Penguin mailto:sage [01/10/22 13:28 ID:w9iNU5fE.net]
- ネスケの 4.x だと
たまに ISO-2022-JP を認識できないことがある。
ネスケのバグ?
- 123 名前：login:Penguin mailto:sage [01/10/22 15:33 ID:cV0J5a3p.net]
- charset= が間違ってるとかじゃなくて？
- 124 名前：login:Penguin [01/10/22 15:54 ID:dRSBo2ui.net]
- >>120
根拠は?
- 125 名前：login:Penguin [01/10/22 17:12 ID:uLX7lQZs.net]
- surrogate して使う文字は utf-8 で encoding すると普通の
漢字より byte 数を食いますか?
あまりかわらないんだったらそっちにいろいろ文字入れれば
Han Unification も救いようがあると思うんですけど.
- 126 名前：login:Penguin [01/10/22 18:36 ID:WlYpkgCt.net]
- >>118
ちゃんとコード指定するならSJISでも全く問題ないよ。
俺は各種処理が楽なので、今のところ EUC-JP 使ってる。
- 127 名前：login:Penguin [01/10/22 18:52 ID:+lMZ2zFA.net]
- >>125
ちょっと問題あるかもね。
charset=Shift_JIS は文字セットが曖昧だから:)
とはいえ、Windows-31J とか書いても理解してくれるブラウザは…
>>123
漢字コードの自動判別がしやすいからでしょ。
そもそも charset 書かないのがよろしくないんだけどさ。
- 128 名前：login:Penguin [01/10/22 21:30 ID:WlYpkgCt.net]
- >>115
RTF とか HTML とか XML とかマークアップ言語使って
ラッピングして使うってのがもう実用的につかわれてるよん。
さらばプレーンテキスト。一回 Outlook とか使ってみそ。よくできてるから。
あ、プレーンテキスト用の「言語タグ」ってのも一応表にはのっかってる
けど使うなって書かれてます。わはは。
Solairs の UTF版 Motif の実装も似たようなことしてるはず
だけど使ったことないから詳細不明。あと、GTK で pango が UTF-8
ベースなんだけど、こいつもオリジナルのマークアップかけることで、
ちゃんと「多言語」処理できるようになってるね。
もう世の中の流れ的には、少なくとも新しいものを実装する上では、
困ったところをうだうだ言うフェーズは終わってるといえるかもね。
- 129 名前：login:Penguin [01/10/23 12:54 ID:CcIiXv/t.net]
- >>124
RFC 2044 からいんにょー:
UCS-4 range (hex.) UTF-8 octet sequence (binary)
0000 0000-0000 007F 0xxxxxxx
0000 0080-0000 07FF 110xxxxx 10xxxxxx
0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx
つまり、BMP 内だったら最高でも 3 オクテット、
surrogate pair が必要な文字(U+10000〜U+10ffff)は 4 オクテット。
- 130 名前：124 [01/10/23 15:41 ID:ODoryf+d.net]
- >>128
したらやっぱり surrogate pair に jisx0208 をまるごと入れて
使うというのは実用的じゃないですね.
- 131 名前：UNIFYダメ [01/10/23 21:36 ID:TioyS6YQ.net]
- news.2ch.net/test/read.cgi/news/1003826777/
統合など不可能。
できもしないことを高望みしないほうが良い。
- 132 名前：login:Penguin [01/10/24 01:13 ID:eNcfec5S.net]
- >>118
wget でwebページを取得するとき、ISO-2022-JPでHTML書いてあると
うまく取得できない。 wgetがASCII前提のソフトだからだけど。
EUC-JPで書いてあるのがいちばんいいと思う。
- 133 名前：login:Penguin mailto:sage [01/10/24 02:14 ID:mCLLGjB8.net]
- >>131
んなこたーないだろ
- 134 名前：login:Penguin [01/10/24 03:14 ID:crtkuShb.net]
- >>130
ごめん. そのスレがどう関係するのかわからないんだけど.
- 135 名前：login:Penguin [01/10/24 03:30 ID:SXmLmgbB.net]
- もし Unicode 3.x をフル実装できるのならば、ISO-2022 は楽勝でフル実装でき
るだろうなぁ。
結局、statefull かつ可変長コードな体系がもうひとつできただけか…。
- 136 名前：131 [01/10/24 04:00 ID:eNcfec5S.net]
- >>132
実際できないよ。たとえばここ。
wget -r -l0 -np kanji.zinbun.kyoto-u.ac.jp/~yasuoka/JavaScript/
とやっても、取得できないページがある。
そもそも ISO-2022-JP って、Shift_JIS の 0x5cどころじゃなく
2byte文字の中にASCII領域が出てきまくる、というかASCII領域だけ使ってるからなぁ。
ASCIIやISO-8859-1前提のソフトとは非常に相性わるい。
8bit目を使わないことで転送データ量は増えるし、ISO-2022-JPにする利点は
今となっては少ないんじゃないかな。
- 137 名前：login:Penguin [01/10/24 04:11 ID:SXmLmgbB.net]
- >>135
wget 1.7 で何の問題もないんだけど。robots.txt を読みにいって失敗している
のを気にしているの?
- 138 名前：131 [01/10/24 04:33 ID:eNcfec5S.net]
- wget 1.6での話でした...でなおしてきます
- 139 名前：login:Penguin [01/10/24 05:05 ID:Rq945OPL.net]
- wget なんて中身がなにかなんて気にしてないだろ。
バイナリだってとれるんだから。ふつーに。
- 140 名前：login:Penguin mailto:sage [01/10/24 05:22 ID:osZWRGWi.net]
- >>138
-rを使ったことないアフォ発見。
- 141 名前：131 [01/10/24 05:23 ID:JalIbsLX.net]
- いやそうじゃなくて、HTMLを解析してリンク先のファイルも取得するよう指定 ( -rオプション) したとき、HTMLの解析に失敗していた、ということ。
wget1.6のHTML解析ルーチンは、ISO-2022-JPと相性がわるかった、と。
- 142 名前：login:Penguin [01/10/24 09:14 ID:TG+/cFwo.net]
- >ごめん. そのスレがどう関係するのかわからないんだけど.
誤用によって日本語が日々変化していると見るけど。
最初は誤用→やがて一般化と思える。
- 143 名前：login:Penguin mailto:sage [01/10/24 13:01 ID:kWLrrN8M.net]
- >>140
あー確かに <> が入ってナニなことになる可能性はあるかもねー
- 144 名前：login:Penguin [01/10/24 20:00 ID:4dNCtF18.net]
- eucってなに？
- 145 名前：login:Penguin mailto:sage [01/10/24 20:06 ID:XZp0N0cm.net]
- >>143
EUC isn't Useful Code
- 146 名前：login:Penguin mailto:sage [01/10/24 21:24 ID:mCLLGjB8.net]
- >>144
ウマイ
- 147 名前：login:Penguin mailto:sage [01/10/25 01:50 ID:xeHLuFXc.net]
- EUC is Useful Code.
- 148 名前：login:Penguin mailto:age [01/10/27 21:03 ID:FAMIO6An.net]
- age
- 149 名前：ネタにツコム mailto:sage [01/10/27 22:17 ID:GBl4KnAH.net]
- >>145 全然うまくない。
GNUの場合はgnuっていう英単語があるから語呂合わせになっているの。
AUC,BUC,CUC,DUC、でも良くなっちゃうし。そも語呂合わせになっていない。
よっと全然うまくない。ネタとしてもいまいち。
- 150 名前：login:Penguin mailto:sage [01/10/28 02:02 ID:8H0orc/X.net]
- 良スレ age といきたいが, そもそものタイトルがよくないな
- 151 名前：pu [01/10/28 13:12 ID:uad7byVd.net]
- EUCは撲滅すべきだろSJISといっしょにな─
- 152 名前：login:Penguin [01/10/28 20:19 ID:N4TbNfCy.net]
- UTF-8って、一般的な圧縮への相性はどうですか？
理想的な圧縮なら、同一の文ならEUCと同じになるはずなんだから、
ディスク上だろうがネット上だろうが、UTF-8で統一して問題無しと思うが。
- 153 名前：login:Penguin [01/10/28 20:23 ID:N4TbNfCy.net]
- 同一って、同一bit列って意味じゃ無く、バイト数ね。（笑
- 154 名前：login:Penguin [01/10/28 20:28 ID:N4TbNfCy.net]
- 同一の文なら、圧縮後のバイト数は、エンコードによらず同一バイト数にできるはず。
プレーンテキストのバイト数を問題視するのは、古臭いって言いたい訳だ。
- 155 名前：login:Penguin mailto:sage [01/10/29 01:03 ID:Wi7PNY4l.net]
- GNUの場合もgnuっていう英(?)単語はあるぞ。
ネタもこのスレにマッチしてる。
- 156 名前：login:Penguin [01/10/29 01:33 ID:HLzkzUYP.net]
- >>153
原理的にはそうかも知れないが, 実際の圧縮では理想的に
data を解析してくれる訳ではないので, エンコーディングの仕方によって
大きさは変化するように思う.
だから実際は utf-8 の方が大きくなるような気がする.
もっとも大した問題でもないと思うけど.
- 157 名前：login:Penguin [01/10/29 02:48 ID:TzGAB923.net]
- >>155
だね。plain text のデータ量なんて気にする必要まるでないし。
だからこそ、XML で markup して…なんていう話だって出てくるわけだし。
- 158 名前：login:Penguin mailto:sage [01/10/29 03:30 ID:H1KcL6kF.net]
- >plain text のデータ量なんて気にする必要まるでないし。
そんなもん内容と利用頻度によるだろ。
XMLが限られた場面でしか使われないのは、その辺りが問題視
されてんじゃねえのか?
- 159 名前：login:Penguin mailto:sage [01/10/29 04:18 ID:4Zx5WUc3.net]
- 56は、歴代２ｃｈコピペ史上もっとも頭いいコピペだな。
あまりにも楽屋オチすぎるが、アニオタ系楽屋落ちギャクよりかはマシだし。
- 160 名前：login:Penguin [01/10/29 06:12 ID:gPKsJk4L.net]
- しっかし、XMLでmark upしないと本格的には
使えないようなcode体系って悲しいよな〜
- 161 名前：login:Penguin [01/10/29 08:42 ID:fAUo4XEm.net]
- 第1水準、第2水準など無視して部首順に並べ直した時点で
よく使う漢字のコード領域が連続してないので、どんなに
圧縮したとしても同じだけには縮まない。
せめて両仮名だけでもU+07ffまでに入れておけば、UTF-8で
日本語を書いた時のデータ量が2割ほど縮んだのに。
もし、基本的な punctuation と漢字の頻度上位500文字(率
では8割を超える。)も2バイトで表せる範囲にあったなら、
EUCの数%増し程度だったのに…。
大陸中国・台湾・日本全部ひっくるめた使用頻度計算する
のって、客観的方法が無くて難しいだろうけどさ。
- 162 名前：login:Penguin mailto:sage [01/10/31 09:14 ID:rxyU2JEX.net]
- 中国と日本で同じ字でも意味がぜんぜん違ったりするのは
割とあることだし。
中国人はそもそも包摂されることに抵抗はないらしい。
文化大革命でさんざん文字を弄くったお国柄だしな。
韓国はハングル文字にしか興味ないみたいだし。
日本が ISO から意見を求められたときに、国内できちんと
した議論をした上での包摂規準を提示できなかったのが痛い。
結局痺れを切らした外人が Unicode 作っちゃったわけだし。
ISO10646 の問題は、裏返すと言語学としての「日本の漢字」
の研究がいかに貧弱だったかを揶揄してるように思う。
もういまさら「ほら貝」を鵜呑みにしてる人もいないよね。
- 163 名前：login:Penguin [01/10/31 09:44 ID:aL+2nYNF.net]
- 日本のJISってISOから馬鹿にされてそうだもんな。
全角英数字は入れちゃうし、互換性の無い変更をしちゃうしな。
よく問題になる半角カタカナってのも、規格の連続性を考えれば
全角の方を使わないべきなんだろうし…
欧米からUnicodeで良いじゃん、と思われても自業自得。
- 164 名前：login:Penguin [01/10/31 11:27 ID:QUoePdRs.net]
- >>161
日本人が文字の形にこだわりだしたのは戦後に漢字についての
法令がいろいろ出だしてからだそうですね。特にJIS漢字制定されて
コンピュータで扱うようになってからが顕著。それ以前はやっぱ手書き
メインだから、文字にゆらぎがあるのはあたりまえのことで、
少々変わってもだれも気にしなかったの。
>>162
規格読んだことないっしょ。
全角英数字は JIS X 0208/0213 の中では単独でしか存在しないんだから
入ってて当然。アルファベットは現在日本語で一般的に使う文字で、
JIS文字は現在日本語の記述に使うための文字だからね。
その上で、別の文字集合を組み合わせて使う場合は、「同じ文字」は、
ISO-2022に従って、割り当て領域の番号が小さいほうを使うことになってる。
だから、英数字は ASCIIのものを使うし、カタカナは208のものを使うんだよん
ま、実装の努力が欠けてるのは事実だし、その点で Unicode に完全に
遅れをとっちゃったのは事実だねん。
馬鹿にするとかそういったレベルの話ではないでしょ。
そもそも目的が違う規格なんだから。
- 165 名前：エディタを作ってる人 [01/10/31 11:52 ID:FRmV6cBQ.net]
- エディタを作っているのですが、全角と半角英字の区別は
それほど問題ではないのですね。
２バイトのうち使ってる部分がどこかってだけの違いですから。
面倒なのは半角カナです。半角なのにEUCでは２バイト使っている。
この場合わけがかなり大変です。
- 166 名前：login:Penguin [01/10/31 11:52 ID:WSuL6NVB.net]
- EBCDIC は置いといても、
ASCII と ISO 646 だって似たようなもの。
チルダとかキャレットとかマイナスハイフンとか。
集合が小さいから傷口が小さく見えるだけ。
83 JIS はともかく、78 JIS は、専用機ワープロの
世界までが、それ以前のメインフレームや写植機のような
独自コードの嵐になるのを水際で食い止めるのに、
ぎりぎりの妥協でケリを付けて間に合わせたということで、
評価は高くていい。
むろん、そのあと議論を継続できなかった。
83 JIS が最悪だったのは確かで、関係者の言語屋にも
日本語屋にも計算機屋にも責任はある。
10646 と Unicode に対して返事をロクに出来なかった
と言えばそうだが、そうすぐに返事をできるような
問題ではない。(議論を継続してりゃ出来たかもしれんが)
これは日本ばかりの問題ではなく、他の Unicode に
ぶちこまれてる言語も多くがまともに研究をされないまま
欧米の理屈で放り込まれてる。
0201 の右半分は DBCS をサポートできない系のためのもので、
0208 が使えるのなら使うなというのは妥当。
\ を ￥ の代わりに使うのやめれ、という主張が妥当か
どうかは微妙だな。そういう意味で SJIS とか EUC(jp) って、
地が 0201 なのか ASCII なのか決めとったのかな ?
SJIS はわざわざ右半分の空きを使うんだから 0201 で、
EUC は ISO 2022 に則っているから GL は ASCII って
ことでいいんかな。
- 167 名前：login:Penguin mailto:sage [01/10/31 11:54 ID:U8Ydp6qc.net]
- > 結局痺れを切らした外人が Unicode 作っちゃったわけだし。
うーむ、君、全然経緯を知らないのね。
現在の Unicode の CJK ideogram を決めたグループには、日本人もちゃんと
入ってたんだよ。何が問題だったかっていうと、利用可能なコードの範囲が決
まっていたため、本来は包摂すべきじゃないような文字まで、包摂しちゃった
ことなのさ。
実際、初期の日本案では、もっと包摂基準は厳密だったんだけど (たとえば、
「直」は分離していた)、それだとコードの範囲を食い過ぎるという圧力に負
けて、今みたいな包摂になっちゃったの。で、結局、今になってやっぱり
16bit じゃ納まらないからといって、数万字の漢字を追加しているし。
そんなことしたって、既に包摂しちゃった文字は分離できないんだから
(分離して文字コードが変わったら、どこかの国がバチをかぶるんだから、
国際問題モノ。よって分離不能) 手遅れもいいとこ。
言語タグや variant タグで救済とか言っているけど、本来分離すべき文字を
包摂しておいて、扱いの面倒な方法で胡麻化すなんて、非常にババいやり方。
統合漢字は、ちゃんと時間をかけてきっちり決めれば確かにそれはそれで素晴
らしいんだけど、Unicode のやり方は、あまりにひどすぎ。
当たり前だけど、上記の問題があるので、Unicode フォントは、CJK ideogram
を使う国では、共有できません。Unicode フォントを使うと幸せになるとか
言う人間を見るたびに、ヘナヘナになる日々…
- 168 名前：login:Penguin [01/10/31 12:03 ID:WSuL6NVB.net]
- >>164
半角で表すかどうかは規格で決めてるこっちゃない。
NEC PC-9801 のキャラジェネは漢字を半分だけ出せるような
仕様だったんで、PC-9801 ローカルな「 SJIS 2 バイト半角」
なんてものもあった。
- 169 名前：login:Penguin [01/10/31 12:18 ID:RZr+0hFu.net]
- 半角全角なんてのは、日本ローカルのプロポーショナルフォントなんで、
固定ピッチのフォントで使うのは駄目でしょ。
つうか、日本のフォントと言いながら、英数字を正確に1/2や2/3で表示できない
プロポーショナルフォントって何？
- 170 名前：login:Penguin [01/10/31 12:32 ID:ZVg2pVZt.net]
- >163
規格としてのそういう事になってると言っても、
それまで蓄積されてた0201のコードをテーブル変換しなきゃならない
0208って悪しき前例でしょう。
それなら、Unicodeでも変換すれば良いって事になる訳ですからね。
さらに結局、ポケベル・携帯で、同じトラブルを繰り返してるんですから、
EUCを考える時に、また非力な環境が主流になるかも？と考えられる
人が居なかったのが悔やまれる。
- 171 名前：login:Penguin [01/10/31 12:49 ID:WSuL6NVB.net]
- >>169
だったら、日本人は永遠に 0201 に縛られて濁点が
サフィックスになってるコード系を使い続けてれば
よかった、ってこと ?
ポケベル・携帯の時にはすでに十分明らかになってた問題点。
回避すべきはポケベル・携帯側。
DBCS が使えないポケベルはともかく。
- 172 名前：login:Penguin [01/10/31 13:47 ID:QUoePdRs.net]
- >>165
当時すでに各社処理系が同種のコードをつかいはじめてたんだけど、
物によって ASCII だったり 201 だったりまざってたはず。
で、それはよくなかろうってことで、集まって相談して、
今の形の日本語EUCを決めたはず。
- 173 名前：login:Penguin [01/10/31 18:22 ID:peF8TTWo.net]
- >170
濁点付の仮名を追加の形で付けるべきだったのでしょう。
ソートを問題視する人も居そうですが、ひらがなカタカナ混ぜてのあいうえお順
じゃなければ同じ事ですからね。
漢字が使えるポケベルも有ったのでは?コードは分かりませんが。
少しも回避する気が無かったようですからねえ。
積極的に1バイトカナを使いたがってたと思われます。
- 174 名前：login:Penguin [01/11/03 08:21 ID:KZcvtfAV.net]
- >>172
> 濁点付の仮名を追加の形で付けるべきだったのでしょう。
それが0208でしょ。
0201 kana(右面)に濁点付の仮名追加出来る余裕ある?
- 175 名前：login:Penguin [01/11/03 09:09 ID:yDgQv8+0.net]
- 0208は0201とカナ配列の順序違うじゃん。
濁点付きカタカナだけなら後ろの31Byteでも良いが、素直に別区に追加で良いっしょ。
「あいうえお」に「゛゜」付きなど全組み合わせを用意してさ。
後から泥沼式に「か゜き゜く゜け゜こ゜」を追加する羽目になるなんて見苦しい事をせずにね。
|
 |
