857コメント312KB

EUCボクメツ委員会

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

0001ﾓ･ｸ･ﾍ･ｹ菽ｦｯ

01/10/16 00:18ID:ZujZqkcr

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

0052login:Penguin

01/10/17 00:26ID:cC5QpbAl

>>51
それってUTF-32か?
普通の目的には4バイトじゃなくても
サロゲート無視のUTF-16(とは呼べんが)でもよさそげな気もする。

個人的にはUTF-8でいいかなと思うけど、
ISO-2022-JPもShift_JISもEUC-JPももうこれだけ広まったらまとめるなんて無理だ
と思うので我慢する、と。

0053login:Penguin

01/10/17 00:30ID:YQKlNfNV

>>38
TRONコードは、誰かが新しい文字が必要だと思い、申請したら、
例え点を一個追加するだけでも、それは追加される。だから、

> なら別々にして必要に応じて変換ライブラリーみたいなの使えばいいと思うぞ。

は、日々変化する。それは「いい」か？
文字の同定の基準が存在し、かつ無闇に文字集合が変動しない、
という取り決めがなかったら、大変だぞ。

> これは運用の問題だろ？
> 斎藤と斉藤と齋藤を区別したいときもあれば同じに扱いたい時もある。

文字集合が固定されている環境でのみ、その要求は満たされる。
新しい「齊」や「藤」が次々に生まれる環境では、それらを「同じに扱」うことは、
原理的には可能だが、現実問題としては難しい。

> しかし37読むとEUC-JPかUTFがいいような気がする

だと思う。まあ、TRONコードも印刷用途だけならまだましだけど。

005449

01/10/17 01:13ID:BOPoQ/5Y

>>51
いや、複数byte列が必要な時点で終ってる。
結局、英語圏の人間は「ASCIIで十分じゃん」ということになる。
例えば、プログラミング言語を作るにしたって、わざわざ
マルチバイトのハンドリングをして「hogecode対応！」なぞと
するより、単一byteを相手にした方が楽に決まってる。

だから、単一byteのビット数を上げるしか道はないんだ！！！

0055login:Penguin

01/10/17 02:20ID:ZtT6Vz1v

>だから、単一byteのビット数を上げるしか道はないんだ！！！

bit増やしても、自分の国で使われることしか考えない奴は
減らないので一緒。
昔よくいたよね下位7bitでマスクかけちゃう奴。

0056login:Penguin

01/10/17 10:51ID:mpfavLge

そんな事より1よ、聞いてくれよ、
昨日、www.unicode.org 行ったんです。www.unicode.org。
そしたらなんかファイルがめちゃくちゃでかくてダウンロード終わんないんです。
で、13MB もある PDF ファイルよく見たら、なんかみんな漢字ばっかりなんです。
もうね、アホかと。馬鹿かと。
お前らな、９万字入りのフォント如きで長々文字表打ち出すために
Unicode 3.1 作ってんじゃねーよ、ボケが。
９万字だよ、９万字。
２バイト固定を信じて作ったアプリもあるのに、よく平気で文字増やせるな。
おめでてーな。
むりやり２万字にＣＪＫまとめながら４万字とか足してるの。もう見てらんない。
お前らな、中華大字典やるからそのコードポイント空けろと。
Unicode ってのはな、漢字は Unify するべきなんだよ。
「桟」の横画が２本か３本かで分けてるのに「浅」は統合されてもおかしくない、
刺すか刺されるか、そんな雰囲気なんだよな。
字を知らなくて単なるデザイン差もわからねーような奴は、すっこんでろ。
で、やっと探してる文字を見つけたかと思ったら、隣のワードと、前のと併せて
１文字なんですよ。
そこでまたぶち切れですよ。
あのな、空き領域でシフトコードなんてきょうび流行んねーんだよ。ボケが。
得意げな顔して何が、UTF-16 だ。
お前は本当に Extension B の字が読み書きできるのかと問いたい。問い詰めたい。
小１時間問い詰めたい。
お前、surrogate したいだけちゃうんかと。
多漢字通の俺から言わせてもらえば今、多漢字通の間での最新流行はやっぱり、
今昔文字鏡、これだね。
今昔文字鏡単漢字10万字版。これが通の頼み方。
文字鏡ってのは漢字が多めに入ってる。そん代わりラテン文字が少なめ。これ。
で、それに西夏文字、梵字。これ最強。
しかしこれを使うとフォントに依存するから文字鏡買わないとデータが編集
できないという危険も伴う、諸刃の剣。
素人にはお薦め出来ない。
まあお前ら初心者は、Mac OS X で JIS X 0213 でも使ってなさいってこった。

005737

01/10/17 11:08ID:6wv4UuNs

>>46
何も資料参照せずに書いたにしてはそれなりにできたと思てるがどうよ?
完璧な情報を集めて考えたければ2chに頼るのが間違いだろうて。

あ、次何も見ずに書くときに参考にするから、すこっと抜けてそーな事項を
列挙しといてくれるとうれしい。

>>56
なにげに通やね(笑)

0058logon

01/10/17 11:25ID:G2XZ5+M2

>>56
ﾖｼｷﾞｭｳﾈﾀﾜﾗﾀ!

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

01/10/17 15:37ID:rj14CtXF

emacs で iso-2022-7bit 使って多国語やってますが, これって
国際標準じゃないですよね. iso-2022 で多言語やらないでわざわざ
Unicode 作ったのは, escape 入れなくても一文字見たら何だか
わかるようにするため?

0060login:Penguin

01/10/17 15:41ID:XqIjgTGZ

>>59
ISO 2022 のフル実装は無理というアメリカ人の妄想のため。

0061login:Penguin

01/10/17 16:42ID:3ILRMCNZ

>>48
支那人も外人なんだけど

0062logon

01/10/17 17:22ID:5T5C0ttM

つか、EUCよかS-JISのが腐ってるだろ。
なんだよ、半角かなって。腐ってるじゃねーか。
WinがJISなりUnicodeなりに文字コードをかえればすむこと。

0063logon

01/10/17 17:31ID:5T5C0ttM

あ、ちなみにEUCとJISは1ビット違うだけなので上の発言には含めてないだけね。
M$ってEUCしそうにないし。

0064login:Penguin

01/10/17 18:29ID:XqIjgTGZ

>>62
ハァ？

文字集合とエンコーディングを区別しろ。アホか。

0065login:Penguin

01/10/17 19:21ID:YthITvX3

> iso-2022 で多言語やらないでわざわざ
> Unicode 作ったのは, escape 入れなくても一文字見たら何だか
> わかるようにするため?

それだけだったら、DIS10646.1 (DIS ってのは、ISO のドラフト仕様ね) で良
かったわけだろ。
DIS10646.1 (こいつは、文字集合としては mule の考え方に近い) が潰されて、
Unicode ベースの ISO10646.1 になったのは、16bitに納まらないと都合が悪
いと考えた Unicode コンソーシアムと、それに押し切られたボンクラのせい
だよ。

0066Anonoymous

01/10/17 19:46ID:YAa2k7T0

>>56
ネタに乗せてかなりコアなことを、かなりうならせられるのう
TORONコードをxfsなどで配信できたら良いと思うのだが
実際、古文書を解析している方々は超漢字を愛用しているそうな（w

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

01/10/17 21:48ID:YBwfYzjL

すべての文書を画像の形式でやりとりするようになれば、
文字コードなどというものは必要なくなる。

ファイル名やコマンドの認識もすべて画像 vs 画像のマッチングにするのだ。
とうぜんソースコードは全部手書きね。

0068login:Penguin

01/10/17 23:48ID:bGZ6eUEA

　　＠ノハ＠三○ ｱﾀﾀ!
　　（　‘д‘) 三○＜なんでもいいから統一しろ！ >>67以外で
　　　　　　　　三○

0069login:Penguin

01/10/17 23:55ID:+4YHdf3b

>>68 いや、67 はいいセン行ってる。
TRON がおバカなのは文字じゃないモノまで文字として扱ってる所。

0070login:Penguin

01/10/18 01:18ID:jQdiwMFy

>>67
絵がヘタな私は、永久にファイルのコピーもできそうにありません...

0071login:Penguin

01/10/18 02:59ID:d914pY0P

>>67
面白いね!!
で、仮名漢字変換やｿｰﾄはどうするの?

0072login:Penguin

01/10/18 05:24ID:qKFuLJNE

ひそかにいいかなと思ってるのは CID だな。
adobe が統一管理してるから混乱ないし、異体字検索問題も対応できる。
新しいコードの追加もそれなりにできる。
コード表とグリフも adobe が提供してくれるしな。合字問題とかどうなってるか知らんが、きっと adobe サマが解決しとるだろう。

内部コードとしてはちょっと複雑すぎる気がするが。

0073login:Penguin

01/10/18 05:41ID:IKIIFWmq

>>56
> お前、surrogate したいだけちゃうんかと。
ｺﾚﾜﾗﾀ.

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で統一して問題無しと思うが。

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