- 1 名前：ﾓ･ｸ･ﾍ･ｹ菽ｦｯ [01/10/16 00:18 ID:ZujZqkcr.net]
- Javaとかのマルチプラットフォームなアプリでも文字コードをいじらないと化けるし。
ICQクローンで Shift_JIS<=>EUC の相互変換をするように加工とか小細工して使ってるのには泣けたＹＯ
せっかく多言語対応の環境で作られたソフトでも日本ローカルのパッチ作んなきゃいけないんじゃ
意味ないじゃん！
Winに比べて少ないアプリがさらに選択肢が狭まっちゃってどうしようもないYO
Linuxにおける日本語の標準コードはWinに倣いShift-JISをメインにすべきである。
- 52 名前：login:Penguin [01/10/17 00:26 ID:cC5QpbAl.net]
- >>51
それってUTF-32か?
普通の目的には4バイトじゃなくても
サロゲート無視のUTF-16(とは呼べんが)でもよさそげな気もする。
個人的にはUTF-8でいいかなと思うけど、
ISO-2022-JPもShift_JISもEUC-JPももうこれだけ広まったらまとめるなんて無理だ
と思うので我慢する、と。
- 53 名前：login:Penguin [01/10/17 00:30 ID:YQKlNfNV.net]
- >>38
TRONコードは、誰かが新しい文字が必要だと思い、申請したら、
例え点を一個追加するだけでも、それは追加される。だから、
> なら別々にして必要に応じて変換ライブラリーみたいなの使えばいいと思うぞ。
は、日々変化する。それは「いい」か？
文字の同定の基準が存在し、かつ無闇に文字集合が変動しない、
という取り決めがなかったら、大変だぞ。
> これは運用の問題だろ？
> 斎藤と斉藤と齋藤を区別したいときもあれば同じに扱いたい時もある。
文字集合が固定されている環境でのみ、その要求は満たされる。
新しい「齊」や「藤」が次々に生まれる環境では、それらを「同じに扱」うことは、
原理的には可能だが、現実問題としては難しい。
> しかし37読むとEUC-JPかUTFがいいような気がする
だと思う。まあ、TRONコードも印刷用途だけならまだましだけど。
- 54 名前：49 [01/10/17 01:13 ID:BOPoQ/5Y.net]
- >>51
いや、複数byte列が必要な時点で終ってる。
結局、英語圏の人間は「ASCIIで十分じゃん」ということになる。
例えば、プログラミング言語を作るにしたって、わざわざ
マルチバイトのハンドリングをして「hogecode対応！」なぞと
するより、単一byteを相手にした方が楽に決まってる。
だから、単一byteのビット数を上げるしか道はないんだ！！！
- 55 名前：login:Penguin mailto:sage [01/10/17 02:20 ID:ZtT6Vz1v.net]
- >だから、単一byteのビット数を上げるしか道はないんだ！！！
bit増やしても、自分の国で使われることしか考えない奴は
減らないので一緒。
昔よくいたよね下位7bitでマスクかけちゃう奴。
- 56 名前：login:Penguin [01/10/17 10:51 ID:mpfavLge.net]
- そんな事より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 でも使ってなさいってこった。
- 57 名前：37 [01/10/17 11:08 ID:6wv4UuNs.net]
- >>46
何も資料参照せずに書いたにしてはそれなりにできたと思てるがどうよ?
完璧な情報を集めて考えたければ2chに頼るのが間違いだろうて。
あ、次何も見ずに書くときに参考にするから、すこっと抜けてそーな事項を
列挙しといてくれるとうれしい。
>>56
なにげに通やね(笑)
- 58 名前：logon mailto:sage [01/10/17 11:25 ID:G2XZ5+M2.net]
- >>56
ﾖｼｷﾞｭｳﾈﾀﾜﾗﾀ!
- 59 名前：名無しさん＠Ｅｍａｃｓ [01/10/17 15:37 ID:rj14CtXF.net]
- emacs で iso-2022-7bit 使って多国語やってますが, これって
国際標準じゃないですよね. iso-2022 で多言語やらないでわざわざ
Unicode 作ったのは, escape 入れなくても一文字見たら何だか
わかるようにするため?
- 60 名前：login:Penguin [01/10/17 15:41 ID:XqIjgTGZ.net]
- >>59
ISO 2022 のフル実装は無理というアメリカ人の妄想のため。
- 61 名前：login:Penguin [01/10/17 16:42 ID:3ILRMCNZ.net]
- >>48
支那人も外人なんだけど
- 62 名前：logon mailto:sage [01/10/17 17:22 ID:5T5C0ttM.net]
- つか、EUCよかS-JISのが腐ってるだろ。
なんだよ、半角かなって。腐ってるじゃねーか。
WinがJISなりUnicodeなりに文字コードをかえればすむこと。
- 63 名前：logon mailto:sage [01/10/17 17:31 ID:5T5C0ttM.net]
- あ、ちなみにEUCとJISは1ビット違うだけなので上の発言には含めてないだけね。
M$ってEUCしそうにないし。
- 64 名前：login:Penguin [01/10/17 18:29 ID:XqIjgTGZ.net]
- >>62
ハァ？
文字集合とエンコーディングを区別しろ。アホか。
- 65 名前：login:Penguin mailto:sage [01/10/17 19:21 ID:YthITvX3.net]
- > iso-2022 で多言語やらないでわざわざ
> Unicode 作ったのは, escape 入れなくても一文字見たら何だか
> わかるようにするため?
それだけだったら、DIS10646.1 (DIS ってのは、ISO のドラフト仕様ね) で良
かったわけだろ。
DIS10646.1 (こいつは、文字集合としては mule の考え方に近い) が潰されて、
Unicode ベースの ISO10646.1 になったのは、16bitに納まらないと都合が悪
いと考えた Unicode コンソーシアムと、それに押し切られたボンクラのせい
だよ。
- 66 名前：Anonoymous mailto:sage [01/10/17 19:46 ID:YAa2k7T0.net]
- >>56
ネタに乗せてかなりコアなことを、かなりうならせられるのう
TORONコードをxfsなどで配信できたら良いと思うのだが
実際、古文書を解析している方々は超漢字を愛用しているそうな（w
- 67 名前：名無しさん＠Ｅｍａｃｓ mailto:sage [01/10/17 21:48 ID:YBwfYzjL.net]
- すべての文書を画像の形式でやりとりするようになれば、
文字コードなどというものは必要なくなる。
ファイル名やコマンドの認識もすべて画像 vs 画像のマッチングにするのだ。
とうぜんソースコードは全部手書きね。
- 68 名前：login:Penguin [01/10/17 23:48 ID:bGZ6eUEA.net]
-
＠ノハ＠ 三○ ｱﾀﾀ!
（ ‘д‘) 三○＜なんでもいいから統一しろ！ >>67以外で
三○
- 69 名前：login:Penguin mailto:sage [01/10/17 23:55 ID:+4YHdf3b.net]
- >>68 いや、67 はいいセン行ってる。
TRON がおバカなのは文字じゃないモノまで文字として扱ってる所。
- 70 名前：login:Penguin [01/10/18 01:18 ID:jQdiwMFy.net]
- >>67
絵がヘタな私は、永久にファイルのコピーもできそうにありません...
- 71 名前：login:Penguin mailto:sage [01/10/18 02:59 ID:d914pY0P.net]
- >>67
面白いね!!
で、仮名漢字変換やｿｰﾄはどうするの?
- 72 名前：login:Penguin [01/10/18 05:24 ID:qKFuLJNE.net]
- ひそかにいいかなと思ってるのは CID だな。
adobe が統一管理してるから混乱ないし、異体字検索問題も対応できる。
新しいコードの追加もそれなりにできる。
コード表とグリフも adobe が提供してくれるしな。合字問題とかどうなってるか知らんが、きっと adobe サマが解決しとるだろう。
内部コードとしてはちょっと複雑すぎる気がするが。
- 73 名前：login:Penguin [01/10/18 05:41 ID:IKIIFWmq.net]
- >>56
> お前、surrogate したいだけちゃうんかと。
ｺﾚ ﾜﾗﾀ.
- 74 名前：login:Penguin mailto:sage [01/10/18 07:13 ID:2ftNibmN.net]
- 手っ取り早く済ます仕事には今も EUC 使っちまうよ。
- 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で統一して問題無しと思うが。
|
 |
