857コメント312KB

EUCボクメツ委員会

■ このスレッドは過去ログ倉庫に格納されています

0001ﾓ･ｸ･ﾍ･ｹ菽ｦｯ

01/10/16 00:18ID:ZujZqkcr

Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。

0074login:Penguin

01/10/18 07:13ID:2ftNibmN

手っ取り早く済ます仕事には今も EUC 使っちまうよ。

007559

01/10/18 16:15ID:zQ3uDx9i

結局 iso-2022 で多国語というのはすたれゆく運命ですか?
僕は Unicode よりイイと思ってるんだけど.

0076login:Penguin

01/10/18 16:33ID:YWCxX3Ha

mb/WCの区別をしなくてよくなるのならUnicodeがイイ！に決まってるが、
それは幻想だったことが決定してるので2022でよい(よかった)。

0077login:Penguin

01/10/18 17:17ID:gPhXvV4t

>>75
内部コードとしては一定以上高度な多言語処理ではどっちも使わん
でしょ。Emacs もオリジナルだし。

プログラマの苦労は結局かわらんので、76のいってる通り
2022でよい(よかった)ではあるんだけど、サポートの現状を考
えると、今や、Unicode が圧倒的に有利かな。Unicodeの文章が
とりあえず読み書きできる環境を持つ人はもうざらだから。

専門用途ではオリジナルコードも十分ありと思われ。というか、
実際、現在のDTPでは、最終的には adobe のコードが物を言うし。

0078login:Penguin

01/10/18 21:01ID:o4Mc8Bmx

現実の話、UTFとかワイドキャラクターの導入って
あくまでもクラスライブラリとか
ウインドウシステムのインターフェースとか
ファイルシステムのファイル名の内部形式とか
そこら辺の話に終始してる。
ディスク上のテキストに関しては移行できる
と考えている人はあんまりいない。
ISO-2022が妥当だろう。

0079login:Penguin

01/10/18 21:14ID:YWCxX3Ha

UTFってUTF-16のこと？UTF-8を内部形式で使う奴はおらんだろう。

>ディスク上のテキストに関しては移行できる
>と考えている人はあんまりいない。
XML文書は?普通UTF-8で書くと思うのだが。

>ISO-2022が妥当だろう。ISO-2022系の多言語非対応のエンコーディング(EUC-JP他)、
という意味ならまぁそうかも。

008079

01/10/18 21:16ID:YWCxX3Ha

>>79

改行抜けた。mozillaたんしっかりしてくれハァハァ…

>ISO-2022が妥当だろう。

ISO-2022系の多言語非対応のエンコーディング(EUC-JP他)、
という意味ならまぁそうかも。

0081login:Penguin

01/10/18 21:31ID:o4Mc8Bmx

>UTFってUTF-16のこと？UTF-8を内部形式で使う奴はおらんだろう。
Ruby

008279

01/10/18 21:33ID:YWCxX3Ha

うお、rubyか。じゃ結構普通のことなのかな？
すみません。

0083_

01/10/18 23:03ID:Hq3ecu1b

>>79
次期 GTK+ の GTK+2 も内部は基本的に UTF-8 ですな。

0084login:Penguin

01/10/19 00:31ID:Kw5tPojH

そりゃ、(EUC-JPと同じく)UTF-8は、ASCIIで済む人はASCIIと変わらんdata量で、
過去のcode資産も活用できるから、移行し易いだろ。ISO 8859-1ででもそうだし。

Unique "wchar_t"は幻想だったという事で。

0085名無しさん＠Ｅｍａｃｓ

01/10/19 02:06ID:fpLOIwDH

名スレ化あげ

0086login:Penguin

01/10/19 02:33ID:QKiQs1/Q

>>84
でもRubyは国産なのに意外。なんでUCSじゃないのでしょうか？
質問age

0087login:Penguin

01/10/19 03:23ID:Kw5tPojH

>>86
処理系内部で使うprintf(3)からRuby用にかき直すんかい?
2byte目に'%'や'\'のあるcoding system(e.g. Shift_JIS)用は書き直しだぞ。

008886

01/10/19 04:51ID:QKiQs1/Q

>>87
ごめん、ちょっと意味がわからない。
（なんでprintfが使えることが重要なのか？という点が）
もし暇なら説明をお願いしたいです。

0089login:Penguin

01/10/19 11:39ID:wq307Z9h

87じゃないけど…

基本としては、「アプリケーションはなるべくシステムのlibcを使うべき」
ってことだろね。きちんと整備されてるＯＳなら、libcを使うのが
パフォーマンス的にも、開発効率上も有利。それが標準の存在意義。
それから「アプリケーションの互換性重要」ってのが背景にある。

printfとかに代表される標準Cライブラリの昔からあるものってのは、
ASCII以外は設計の想定外。だから、SJISとかUCSのような、ASCIIと干渉する
エンコーディングをそれで扱おうとするとまず間違いなく誤動作する。
本来これを避けるための Wide Character なんだけど、残念ながら、
この部分は実装依存度がやたら高い。無いOSも多いし、内部構造もOS毎に
ばらばらだ。もちろん過去のコードはもちろんこんなもの使ってないわけで、
使うとしたらかなり書き直しに陥るはめになる。

そうなると、選択肢としては、なんとか char のまま、普通の libc で
扱えるようにしちゃおうって考えが浮上してくるわけだ
(技術的には逃げなので退化)

必要要件は
　1. ASCII に干渉しないマルチバイト(char の配列)きぼんぬ
　2. 文字区切りが確実容易なほうがイイ！
3. 何か標準に沿ってるほうがイイ！
こんなところで、それを満たす UTF-8 になるのは自然な流れだろう。

やっぱでかいのは互換要因のほうかな。完全に1から書くのなら、
UCSだろうがオリジナルだろうが好きなのを採用すればよろし。

009077

01/10/19 13:05ID:wq307Z9h

>>78
79もいってるけど、「非多言語対応」なら、ISO-2022系が
妥当だろう。実際そっちのが多いと思うし。

話の流れは「多言語用」だよね。ISO-2022-JP-2 とかを扱える環境(emacsとか)
をそろえてる人は、UTF-8 扱える環境をもってる人より少ないよねって
のがオレの指摘。

今はWinいれたらそれだけでとりあえず日常用途で使う範囲なら、読むのも
書くのもできるからね > UTF-8

0091login:Penguin

01/10/19 13:10ID:LpodI9Q2

>>45
> 情報交換符合と内部表現、
> 文字セットとエンコーディング、
> コードとグリフ、

これらの区別が説明されているサイトはありますか？
出来れば日本語ｄ

0092login:Penguin

01/10/19 18:32ID:mx7DeiuF

欧米の人たちが ASCII や ISO-8859-x で足りてるなんてのは
わりと誤解で、文字をもっと増やしたいと思っている人が多いです。
XFree86 で強硬に Unicode を推進している人たちはそんな感じ。

JIS X 0208 の記号とかを使った英語のプレゼン資料とか見せると
羨ましがられるよ。

0093login:Penguin

01/10/19 18:42ID:mx7DeiuF

>>15
Solaris や NetBSD は SJIS ろけーるもあったかと。
Solaris だと ja_JP.utf8 とかもできるんじゃなかったかな。

Linux (つーか glibc) は内部 Unicode なんだっけ?

0094login:Penguin

01/10/19 18:56ID:+gP9D3Wa

>>93
linuxでもできる。KondaraではUTF-8なロケール使って、
X上でximを切り替えてCJK混在な文書とかも作れたはず。
Debian sid でもutf-8なロケール作ってやればできるでしょ？
まあアプリ全てがちゃんと動くわけではないが。
(ATOK X のメニューが化けて鬱だった記憶が）
ほかのディストリとかは知らない。

0095login:Penguin

01/10/19 19:03ID:Y1kLvlVv

>>91
そんなに難しい話じゃないよ。
「文字」の定義が甘いのをとりあえず横に置いとけば。

文字セット：「この文字を扱う」という範囲。各文字を識別する ID つき
エンコーディング：上の文字セットをコンピュータで表現するための数値化の方法
情報交換符合：通信、ファイルなど、外部とやりとりするための文字セット+エンコーディング
内部表現：OS やアプリケーションでの文字の内部表現
コード：数字。文字コードね。
グリフ：形。目に見えるものね。
この手のお話だと、必ずこのあたりがごっちゃになった議論になってわけわかになるので、釘さしてみただけ。

0096login:Penguin

01/10/19 20:53ID:PkKT5Zqx

>printfとかに代表される標準Cライブラリの昔からあるものってのは、
>ASCII以外は設計の想定外。だから、SJISとかUCSのような、ASCIIと干渉する
>エンコーディングをそれで扱おうとするとまず間違いなく誤動作する。
>本来これを避けるための Wide Character なんだけど、残念ながら、
>この部分は実装依存度がやたら高い。無いOSも多いし、内部構造もOS毎に

だから俺はCやめざろう得なかった。
Standard C++ならば標準ライブラリは全部マクロなんで
自動的に展開されて解決。
C++を嫌うならばKylixがある。
KylixはCのようなポインター操作もできるし、
GUIなしのデーモンプロセスも書ける。
ヘッダーさえなんとかすればドライバも書ける可能性あり。
Cユーザーにとって、字面以外は抵抗なしに受け入れられる。

>ばらばらだ。もちろん過去のコードはもちろんこんなもの使ってないわけで、
>使うとしたらかなり書き直しに陥るはめになる。

過去の資産に関しては同意。

0097login:Penguin

01/10/19 20:58ID:QKiQs1/Q

へ？？

>Standard C++ならば標準ライブラリは全部マクロなんで
>自動的に展開されて解決。
ここだけでいいから、なにが解決されるのか具体的に書いて。

0098login:Penguin

01/10/19 21:09ID:PkKT5Zqx

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;
型の定義だけでほとんどを解決し、ロジックはいじらない。
うまくいくと変数の宣言文を触れるだけで全部解決。

0099login:Penguin

01/10/19 21:14ID:QKiQs1/Q

>>98
ああそういう意味か。了解。
でも、話の流れは、wchar_tじゃぁ駄目って事だったんじゃ…。

#個人的にはふつ～のアプリはWC使って書くのが好きですが。

010098

01/10/19 22:30ID:dckKBkBJ

>Unique "wchar_t"は幻想だったという事で。
wchar_tイコールUCS2でないよ。
MSの2バイトwchar_tは幻想だが。

http://www-6.ibm.com/jp/developerworks/unicode/000616/j_uniwchar.html
C 規格では、wchar_t に対して厳密にどれというタイプを指定していません。

0101login:Penguin

01/10/19 22:58ID:Kw5tPojH

>>100
> >Unique "wchar_t"は幻想だったという事で。

Uniqueというのは、

> wchar_tイコールUCS2でないよ。
> MSの2バイトwchar_tは幻想だが。

などから一つを選択してそれのみでやっていく事を目指す、というつもりで、書きました。

> http://www-6.ibm.com/jp/developerworks/unicode/000616/j_uniwchar.html
> C 規格では、wchar_t に対して厳密にどれというタイプを指定していません。

はもちろん知っています。
ただ、上のようにUniqueになろうと"UNI"codeは目指したと思います。少なくとも当初は。

0102login:Penguin

01/10/19 23:03ID:dckKBkBJ

4バイトでUniqueになればいいじゃないか。

0103login:Penguin

01/10/20 06:16ID:g2GqcdkH

どうやら、このスレには、ちゃんと理解しているのが３人しかおらず、
それ以外はコード表（どれか１つでも）も見たことがない奴らだけの
ようだ
まだ、青木光恵の旦那の方が３８倍ましって感じ

0104ななしさん＠おなかいっぱい

01/10/20 07:28ID:a3ky6FMM

>>103
「ちゃんと理解している」のが3人もいれば2ch的には充分のような気も。
あと、そーいうことをいう人には、どのポストに正しいことが書いてあるの
か指摘してもらえると嬉しいかな、とか。

0105login:Penguin

01/10/20 11:51ID:mRQL8QGY

>>56
やっぱり謎の中国人に「アイヤー、漢字特盛りにしちゃうアルヨー」
と言わせてほしかったな。

0106login:Penguin

01/10/20 13:09ID:2B2NfqxB

>>102
それについては、>>65の言う通りで、>>56が詳しい(w
「もうUnicode捨てたいんと違うんか？」と小１時間問い詰めたい。

http://euc.jp/i18n/ucsnote.ja.html
Unicodeの安易さが持ち込んだ問題で、10646が腐るのは困る。

0107login:Penguin

01/10/20 16:11ID:8ZJLlTqR

このスレッド面倒だから読んでいない。
重複する内容だったら失礼。

シフトジスになぜしないかというとシフトジスには欠点があるから。
その代表的なものは0x5c問題。
0x5cはダブルコーテーションという記号だがシフトジスの漢字はこれを含む
漢字もある。
アスキーコード0x5cが文字列に入っているとシフトジスはおかしくなる。
プログラムでこの問題を回避する処理を入れないといけないがそれは大変だ。
実際、WINDOWS版のソフトでこの問題を回避できていないソフトは多い。
EUCだと、8ビット目を殺さないようにするだけで無変更でコンパイラなどが
日本語をソースに入れても問題なく使える。
それによってgccなどは英語版そのものを使ってもEUCなら日本語を入れたソース
をコンパイルできる。
しかしシフトジスだと0x5c問題にかかるので改造しないと使えない。
改造しても行の先頭から順番に読んでいかないと半角か全角か判断できないと
いうシフトジスの大きな欠点のため速度が遅くなるという欠点が出る。
仮にシフトジスに変えてしまうとほとんどのLinuxソフトが日本語使えなくなる。
かといってシフトジス対応という膨大な作業を誰がするというのだろう。
シフトジス対応すると本家と英語版とソースが分岐するので古いバージョンを
使わざる得ないとか不都合がたくさんでる。
結果的にシフトジス標準は不可能だ。こんなことはプログラマーならわかると思うが 1 はユーザー専門なんだろう。

0108login:Penguin

01/10/20 17:52ID:cvBqh8vR

このスレ案外詳しいよ. スレッド名に反して役に立った.

0109login:Penguin

01/10/20 17:53ID:n/co2nXu

文字の割り当ての正当さなんぞ気にしていたら
あと何百年かかるかわからんだろ。
「てめーら勝手にしろ」でコード領域広く取って
各地域24ビットぐらい割り当てちまえばよい。
で日本では従来のJISを突っ込んで終わり。
グリフだのなんだのとわめいていたら、孫の代まで
に完成しねえぞ。

0110login:Penguin

01/10/20 19:04ID:2B2NfqxB

>>109
それで解決するのは、Han Unificaionだけで、
http://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 マイナス
:
互換性を求めて既存のを無制限に突っ込んだ挙げ句がこれ…

0111login:Penguin

01/10/20 19:11ID:DsyBUQBQ

>>110
それでもいい。
それは子孫の時代に解決する問題。
現状では再コンパイル一発で将来の文字コードに
対応できるインフラの整備が大事だと思う。

0112login:Penguin

01/10/20 19:48ID:XktlMTUg

>>107
>このスレッド面倒だから読んでいない。
>重複する内容だったら失礼。
こういっちゃなんだが、すでに、ビット並びの字面(とでもいうのか?)の話はし
てないです。

ワイドキャラクタを使用しない、m17nな独自内部コードとしては、開発効率の観点
からビットの字面が大事(UTF-8を使わざるをえない)なんていう話はでたけど話
のレイヤがかなり違う。

>シフトジス対応すると本家と英語版とソースが分岐するので古いバージョンを
>使わざる得ないとか不都合がたくさんでる。
localeとはなにか？と、mbstowcs関数をはじめとした、ワイドキャラクタを
利用したプログラムの書き方でも覚えてくれ。

すると、分岐せずに(=localizeせずにinternationalizeすることで)Shift_JIS
に移行できなくはないことがわかる。ソースコードは改変する必要はあるかも
しれんし（本家に統合は可能だろう）、OSのlocaleまわりもいじらないとい
かんかもしれないが。

蛇足だが、
何度か言われているが、character set と encoding を区別してくれ。
ISO 2022 とはなにかを理解してくれ。暇があれば UCS, UTF とはなにか
を学んでくれ。書籍もいくつかでてるが、まずは http://euc.jp/ を読む
とよい。

理解した上の発言ならすまん。

0113login:Penguin

01/10/20 21:03ID:7W8DCi3g

>>110
文字コードと文字集合を世界で統一しようという
アイデア自体には大賛成だが、ここまで致命的な問題点を
見せられると困るな。
日本だけを見てもこの状況だから、他の諸外国でも
いろんな問題があるんだろうな。
ほんと孫の代になるまで解決しそうにないな。
漏れが現役の間は EUC-JP で頑張るしかないかな。

0114login:Penguin

01/10/21 01:58ID:3nI2LT/o

Flashの日本語が読めないのは誰のせい…

0115login:Penguin

01/10/22 00:36ID:vff311A1

結局, 中国語と日本語を両方ともまともに使う人から見て,
Unicode の CJK Unified は満足できるものなんでしょうか?

結局どっちかをメインとして使わないと文面の字面がキモくなる
ような気がするんですが.

それなら Emacs で ISO 2022 で違う font を使って表示した方が
ましのような.

0116login:Penguin

01/10/22 07:46ID:EJ6V2X5S

16bitに無理矢理収めたくてUnifyしたのに、
>>56にあるように9万(>2^16)字になっちゃったんです。意味ないんですぅ
Unifyの意味ないのに、UnifyされたのがISO 10646.1(>>65)になっちゃったんですぅ
しかも>>110にあるように漢字以外のUnifyの基準が使いものにならないですぅ
Unicodeは文字コードの世界に新しく増えた負の遺産なんですぅ

//最近のtechnical reportは面白いのあるけど。

0117login:Penguin

01/10/22 08:00ID:RZQUGhKz

Emacsの内部コードって何つかってんの?

0118login:Penguin

01/10/22 09:01ID:7trpRy3z

HTMLってSJISは論外としてEUCとJISのどっちで書くのがいいの？

0119login:Penguin

01/10/22 09:08ID:Pupx5KWC

>>118
あんまり考えずに全文検索とかするためにはバッティングしない
EUCの方が楽なんじゃない？

0120login:Penguin

01/10/22 13:05ID:U0CK64Pe

iso-2022-jpでしょ。>>118

0121login:Penguin

01/10/22 13:28ID:w9iNU5fE

ネスケの 4.x だと
たまに ISO-2022-JP を認識できないことがある。
ネスケのバグ?

0122login:Penguin

01/10/22 15:33ID:cV0J5a3p

charset= が間違ってるとかじゃなくて？

0123login:Penguin

01/10/22 15:54ID:dRSBo2ui

>>120
根拠は?

0124login:Penguin

01/10/22 17:12ID:uLX7lQZs

surrogate して使う文字は utf-8 で encoding すると普通の
漢字より byte 数を食いますか?

あまりかわらないんだったらそっちにいろいろ文字入れれば
Han Unification も救いようがあると思うんですけど.

0125login:Penguin

01/10/22 18:36ID:WlYpkgCt

>>118
ちゃんとコード指定するならSJISでも全く問題ないよ。
俺は各種処理が楽なので、今のところ EUC-JP 使ってる。

0126login:Penguin

01/10/22 18:52ID:+lMZ2zFA

>>125
ちょっと問題あるかもね。
charset=Shift_JIS は文字セットが曖昧だから:)

とはいえ、Windows-31J とか書いても理解してくれるブラウザは…
>>123
漢字コードの自動判別がしやすいからでしょ。
そもそも charset 書かないのがよろしくないんだけどさ。

0127login:Penguin

01/10/22 21:30ID:WlYpkgCt

>>115
RTF とか HTML とか XML とかマークアップ言語使って
ラッピングして使うってのがもう実用的につかわれてるよん。
さらばプレーンテキスト。一回 Outlook とか使ってみそ。よくできてるから。

あ、プレーンテキスト用の「言語タグ」ってのも一応表にはのっかってる
けど使うなって書かれてます。わはは。

Solairs の UTF版　Motif の実装も似たようなことしてるはず
だけど使ったことないから詳細不明。あと、GTK で pango が UTF-8
ベースなんだけど、こいつもオリジナルのマークアップかけることで、
ちゃんと「多言語」処理できるようになってるね。

もう世の中の流れ的には、少なくとも新しいものを実装する上では、
困ったところをうだうだ言うフェーズは終わってるといえるかもね。

0128login:Penguin

01/10/23 12:54ID:CcIiXv/t

>>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 オクテット。

0129124

01/10/23 15:41ID:ODoryf+d

>>128
したらやっぱり surrogate pair に jisx0208 をまるごと入れて
使うというのは実用的じゃないですね.

0130UNIFYダメ

01/10/23 21:36ID:TioyS6YQ

http://news.2ch.net/test/read.cgi/news/1003826777/

統合など不可能。
できもしないことを高望みしないほうが良い。

0131login:Penguin

01/10/24 01:13ID:eNcfec5S

>>118
wget でwebページを取得するとき、ISO-2022-JPでHTML書いてあると
うまく取得できない。 wgetがASCII前提のソフトだからだけど。
EUC-JPで書いてあるのがいちばんいいと思う。

0132login:Penguin

01/10/24 02:14ID:mCLLGjB8

>>131
んなこたーないだろ

0133login:Penguin

01/10/24 03:14ID:crtkuShb

>>130
ごめん. そのスレがどう関係するのかわからないんだけど.

0134login:Penguin

01/10/24 03:30ID:SXmLmgbB

もし Unicode 3.x をフル実装できるのならば、ISO-2022 は楽勝でフル実装でき
るだろうなぁ。

結局、statefull かつ可変長コードな体系がもうひとつできただけか…。

0135131

01/10/24 04:00ID:eNcfec5S

>>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にする利点は
今となっては少ないんじゃないかな。

0136login:Penguin

01/10/24 04:11ID:SXmLmgbB

>>135
wget 1.7 で何の問題もないんだけど。robots.txt を読みにいって失敗している
のを気にしているの?

0137131

01/10/24 04:33ID:eNcfec5S

wget 1.6での話でした...でなおしてきます

0138login:Penguin

01/10/24 05:05ID:Rq945OPL

wget なんて中身がなにかなんて気にしてないだろ。
バイナリだってとれるんだから。ふつーに。

0139login:Penguin

01/10/24 05:22ID:osZWRGWi

>>138
-rを使ったことないアフォ発見。

0140131

01/10/24 05:23ID:JalIbsLX

いやそうじゃなくて、HTMLを解析してリンク先のファイルも取得するよう指定 ( -rオプション) したとき、HTMLの解析に失敗していた、ということ。
wget1.6のHTML解析ルーチンは、ISO-2022-JPと相性がわるかった、と。

0141login:Penguin

01/10/24 09:14ID:TG+/cFwo

>ごめん. そのスレがどう関係するのかわからないんだけど.
誤用によって日本語が日々変化していると見るけど。
最初は誤用→やがて一般化と思える。

0142login:Penguin

01/10/24 13:01ID:kWLrrN8M

>>140
あー確かに <> が入ってナニなことになる可能性はあるかもねー

0143login:Penguin

01/10/24 20:00ID:4dNCtF18

eucってなに？

0144login:Penguin

01/10/24 20:06ID:XZp0N0cm

>>143
EUC isn't Useful Code

0145login:Penguin

01/10/24 21:24ID:mCLLGjB8

>>144
ウマイ

0146login:Penguin

01/10/25 01:50ID:xeHLuFXc

EUC is Useful Code.

0147login:Penguin

01/10/27 21:03ID:FAMIO6An

age

0148ネタにツコム

01/10/27 22:17ID:GBl4KnAH

>>145　全然うまくない。
GNUの場合はgnuっていう英単語があるから語呂合わせになっているの。
AUC,BUC,CUC,DUC、でも良くなっちゃうし。そも語呂合わせになっていない。
よっと全然うまくない。ネタとしてもいまいち。

0149login:Penguin

01/10/28 02:02ID:8H0orc/X

良スレ age といきたいが, そもそものタイトルがよくないな

0150pu

01/10/28 13:12ID:uad7byVd

EUCは撲滅すべきだろSJISといっしょにな─

0151login:Penguin

01/10/28 20:19ID:N4TbNfCy

UTF-8って、一般的な圧縮への相性はどうですか？
理想的な圧縮なら、同一の文ならEUCと同じになるはずなんだから、
ディスク上だろうがネット上だろうが、UTF-8で統一して問題無しと思うが。

0152login:Penguin

01/10/28 20:23ID:N4TbNfCy

同一って、同一bit列って意味じゃ無く、バイト数ね。（笑

0153login:Penguin

01/10/28 20:28ID:N4TbNfCy

同一の文なら、圧縮後のバイト数は、エンコードによらず同一バイト数にできるはず。
プレーンテキストのバイト数を問題視するのは、古臭いって言いたい訳だ。

0154login:Penguin

01/10/29 01:03ID:Wi7PNY4l

GNUの場合もgnuっていう英(?)単語はあるぞ。
ネタもこのスレにマッチしてる。

0155login:Penguin

01/10/29 01:33ID:HLzkzUYP

>>153
原理的にはそうかも知れないが, 実際の圧縮では理想的に
data を解析してくれる訳ではないので, エンコーディングの仕方によって
大きさは変化するように思う.
だから実際は utf-8 の方が大きくなるような気がする.
もっとも大した問題でもないと思うけど.

0156login:Penguin

01/10/29 02:48ID:TzGAB923

>>155
だね。plain text のデータ量なんて気にする必要まるでないし。
だからこそ、XML で markup して…なんていう話だって出てくるわけだし。

0157login:Penguin

01/10/29 03:30ID:H1KcL6kF

>plain text のデータ量なんて気にする必要まるでないし。

そんなもん内容と利用頻度によるだろ。
XMLが限られた場面でしか使われないのは、その辺りが問題視
されてんじゃねえのか?

0158login:Penguin

01/10/29 04:18ID:4Zx5WUc3

56は、歴代２ｃｈコピペ史上もっとも頭いいコピペだな。
あまりにも楽屋オチすぎるが、アニオタ系楽屋落ちギャクよりかはマシだし。

0159login:Penguin

01/10/29 06:12ID:gPKsJk4L

しっかし、XMLでmark upしないと本格的には
使えないようなcode体系って悲しいよな～

0160login:Penguin

01/10/29 08:42ID:fAUo4XEm

第1水準、第2水準など無視して部首順に並べ直した時点で
よく使う漢字のコード領域が連続してないので、どんなに
圧縮したとしても同じだけには縮まない。

せめて両仮名だけでもU+07ffまでに入れておけば、UTF-8で
日本語を書いた時のデータ量が2割ほど縮んだのに。
もし、基本的な punctuation と漢字の頻度上位500文字(率
では8割を超える。)も2バイトで表せる範囲にあったなら、
EUCの数%増し程度だったのに…。

大陸中国・台湾・日本全部ひっくるめた使用頻度計算する
のって、客観的方法が無くて難しいだろうけどさ。

0161login:Penguin

01/10/31 09:14ID:rxyU2JEX

中国と日本で同じ字でも意味がぜんぜん違ったりするのは
割とあることだし。
中国人はそもそも包摂されることに抵抗はないらしい。
文化大革命でさんざん文字を弄くったお国柄だしな。
韓国はハングル文字にしか興味ないみたいだし。

日本が ISO から意見を求められたときに、国内できちんと
した議論をした上での包摂規準を提示できなかったのが痛い。
結局痺れを切らした外人が Unicode 作っちゃったわけだし。

ISO10646 の問題は、裏返すと言語学としての「日本の漢字」
の研究がいかに貧弱だったかを揶揄してるように思う。
もういまさら「ほら貝」を鵜呑みにしてる人もいないよね。

0162login:Penguin

01/10/31 09:44ID:aL+2nYNF

日本のJISってISOから馬鹿にされてそうだもんな。
全角英数字は入れちゃうし、互換性の無い変更をしちゃうしな。
よく問題になる半角カタカナってのも、規格の連続性を考えれば
全角の方を使わないべきなんだろうし…
欧米からUnicodeで良いじゃん、と思われても自業自得。

0163login:Penguin

01/10/31 11:27ID:QUoePdRs

>>161
日本人が文字の形にこだわりだしたのは戦後に漢字についての
法令がいろいろ出だしてからだそうですね。特にJIS漢字制定されて
コンピュータで扱うようになってからが顕著。それ以前はやっぱ手書き
メインだから、文字にゆらぎがあるのはあたりまえのことで、
少々変わってもだれも気にしなかったの。

>>162
規格読んだことないっしょ。
全角英数字は JIS X 0208/0213 の中では単独でしか存在しないんだから
入ってて当然。アルファベットは現在日本語で一般的に使う文字で、
JIS文字は現在日本語の記述に使うための文字だからね。

その上で、別の文字集合を組み合わせて使う場合は、「同じ文字」は、
ISO-2022に従って、割り当て領域の番号が小さいほうを使うことになってる。
だから、英数字は ASCIIのものを使うし、カタカナは208のものを使うんだよん

ま、実装の努力が欠けてるのは事実だし、その点で Unicode に完全に
遅れをとっちゃったのは事実だねん。

馬鹿にするとかそういったレベルの話ではないでしょ。
そもそも目的が違う規格なんだから。

0164エディタを作ってる人

01/10/31 11:52ID:FRmV6cBQ

エディタを作っているのですが、全角と半角英字の区別は
それほど問題ではないのですね。
２バイトのうち使ってる部分がどこかってだけの違いですから。
面倒なのは半角カナです。半角なのにEUCでは２バイト使っている。
この場合わけがかなり大変です。

0165login:Penguin

01/10/31 11:52ID:WSuL6NVB

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 って
ことでいいんかな。

0166login:Penguin

01/10/31 11:54ID:U8Ydp6qc

> 結局痺れを切らした外人が Unicode 作っちゃったわけだし。

うーむ、君、全然経緯を知らないのね。
現在の Unicode の CJK ideogram を決めたグループには、日本人もちゃんと
入ってたんだよ。何が問題だったかっていうと、利用可能なコードの範囲が決
まっていたため、本来は包摂すべきじゃないような文字まで、包摂しちゃった
ことなのさ。
実際、初期の日本案では、もっと包摂基準は厳密だったんだけど (たとえば、
「直」は分離していた)、それだとコードの範囲を食い過ぎるという圧力に負
けて、今みたいな包摂になっちゃったの。で、結局、今になってやっぱり
16bit じゃ納まらないからといって、数万字の漢字を追加しているし。
そんなことしたって、既に包摂しちゃった文字は分離できないんだから
(分離して文字コードが変わったら、どこかの国がバチをかぶるんだから、
国際問題モノ。よって分離不能) 手遅れもいいとこ。
言語タグや variant タグで救済とか言っているけど、本来分離すべき文字を
包摂しておいて、扱いの面倒な方法で胡麻化すなんて、非常にババいやり方。
統合漢字は、ちゃんと時間をかけてきっちり決めれば確かにそれはそれで素晴
らしいんだけど、Unicode のやり方は、あまりにひどすぎ。

当たり前だけど、上記の問題があるので、Unicode フォントは、CJK ideogram
を使う国では、共有できません。Unicode フォントを使うと幸せになるとか
言う人間を見るたびに、ヘナヘナになる日々…

0167login:Penguin

01/10/31 12:03ID:WSuL6NVB

>>164

半角で表すかどうかは規格で決めてるこっちゃない。

NEC PC-9801 のキャラジェネは漢字を半分だけ出せるような
仕様だったんで、PC-9801 ローカルな「 SJIS 2 バイト半角」
なんてものもあった。

0168login:Penguin

01/10/31 12:18ID:RZr+0hFu

半角全角なんてのは、日本ローカルのプロポーショナルフォントなんで、
固定ピッチのフォントで使うのは駄目でしょ。
つうか、日本のフォントと言いながら、英数字を正確に1/2や2/3で表示できない
プロポーショナルフォントって何？

0169login:Penguin

01/10/31 12:32ID:ZVg2pVZt

>163
規格としてのそういう事になってると言っても、
それまで蓄積されてた0201のコードをテーブル変換しなきゃならない
0208って悪しき前例でしょう。
それなら、Unicodeでも変換すれば良いって事になる訳ですからね。

さらに結局、ポケベル・携帯で、同じトラブルを繰り返してるんですから、
EUCを考える時に、また非力な環境が主流になるかも？と考えられる
人が居なかったのが悔やまれる。

0170login:Penguin

01/10/31 12:49ID:WSuL6NVB

>>169

だったら、日本人は永遠に 0201 に縛られて濁点が
サフィックスになってるコード系を使い続けてれば
よかった、ってこと ?

ポケベル・携帯の時にはすでに十分明らかになってた問題点。
回避すべきはポケベル・携帯側。
DBCS が使えないポケベルはともかく。

0171login:Penguin

01/10/31 13:47ID:QUoePdRs

>>165
当時すでに各社処理系が同種のコードをつかいはじめてたんだけど、
物によって ASCII だったり 201 だったりまざってたはず。
で、それはよくなかろうってことで、集まって相談して、
今の形の日本語EUCを決めたはず。

0172login:Penguin

01/10/31 18:22ID:peF8TTWo

>170
濁点付の仮名を追加の形で付けるべきだったのでしょう。
ソートを問題視する人も居そうですが、ひらがなカタカナ混ぜてのあいうえお順
じゃなければ同じ事ですからね。

漢字が使えるポケベルも有ったのでは?コードは分かりませんが。
少しも回避する気が無かったようですからねえ。
積極的に1バイトカナを使いたがってたと思われます。

0173login:Penguin

01/11/03 08:21ID:KZcvtfAV

>>172
> 濁点付の仮名を追加の形で付けるべきだったのでしょう。

それが0208でしょ。
0201 kana(右面)に濁点付の仮名追加出来る余裕ある?

0174login:Penguin

01/11/03 09:09ID:yDgQv8+0

0208は0201とカナ配列の順序違うじゃん。
濁点付きカタカナだけなら後ろの31Byteでも良いが、素直に別区に追加で良いっしょ。
「あいうえお」に「゛゜」付きなど全組み合わせを用意してさ。
後から泥沼式に「か゜き゜く゜け゜こ゜」を追加する羽目になるなんて見苦しい事をせずにね。

■ このスレッドは過去ログ倉庫に格納されています