おい、お前らUNICODEを絶滅させて下ちい。

話の筋と関係ないけど、たまに iso-2022 は grep ができないとか逝ってるやつが居るが、
真面目に iso-2022 で grep しようとするやつなんて居るのかな。
普通内部でコード変換すると思うんだが・・・

unicode で言語タグとか出てきたら結局コンテキスト
見ないとダメなのは似たような問題だな。

lgrepではできるよ。

>>937
言語タグは無視できる、という点が違うけどな。

あれだな、ISO-2022-JP でもエスケープシーケンス無視して grep してしまえば
特に問題なさそうな気もする（ｗ

いっそのこと、ch & 0x7f するか(w

UTF-8

>>941
よし! UTF-7だ!

UTF-6

UTF-1024

組み込み用の64Kbyteのメモリに変換テーブル入れられんかな…。

unicode→SJIS 日本語だけでいいんやけど…。

>>947
UCS-2→SJIS変換テーブルとプログラム作ったけど、不要な部分削って
表引きさせても、50Kぐらい消費する。ヘボくてよければソース出すよ。
SJIS→UCS-2なら、もっと小さくなるのだけどね。

>>948
その変換テーブルはunicode.orgの物？
それともWindows互換？

サイズに関してはそんなに変わらんと思われ。

>>949
Windows用。スマソ。

次スレ立てますか?

>>952
よろしくー。

http://pc.2ch.net/test/read.cgi/tech/1008913670/
↑此れと統合はどうでしょうか?

正直2つのスレをチェックするのは面倒。

>>954
いいんじゃない。
ここの1と、そちらの1で思想は違うみたいだけど。

自分も前から二つのスレを一つにまとめて欲しかったけど、
向うでUTF-8以外の話すると、怒られそうな気がする。

あげ

おい、おまいら ・・・・
　　　　　　　　　　　＿＿＿　００　　　　　　　　／
｜＿＿　＿＿　　＿＿＿＿　　　　　　　　　／
｜ 　　　＿_｜　　　｜　　　＿＿＿＿　　／｜
｜＿＿　＿_｜ 　 ／　 　　　　　　　　　　 　｜　

を流行らすのじゃ！

参考スレッド 森恒二ホーリーランド拳闘暗黒伝セスタス技来静也4
http://comic.2ch.net/test/read.cgi/comic/1025843878/551-591

質問です。
UTF-7ってUCS4じゃなくてUCS2を使う？
その場合、サロゲートも必要なの？

UTF-7はもう忘れとけばいいんじゃないの。

>>960
http://seclan.dll.jp/ccutffaq.htm を読むと、
各コードの表現可能範囲は
UTF-8 0x7FFFFFFF
UTF-7 0x0010FFFF
UTF-16 0x0010FFFF
って書いてある。(UTF-32についてはこのページの情報は古いね。)

0x010000 〜 0x10FFFFの区間はサロゲートペアを使わないと表せないから、
UTF-7でもUTF-16を使う部分ではサロゲートが必要なんじゃない?

正解はこれ見れ。↓
http://www.rfc-editor.org/rfc/rfc2152.txt

ここまで問題がこじれてしまったら、もう内部コードは誰かが
適当文字コードをでっちあげて、wchar的なライブラリを作って、
それを使う形にするのが早道だと思う。ISO C localeとだいたい
同じ発想だけど、実装が1つなら変な非互換問題は出ないし、
complex-textに対応する余地も広がる。
外部コードは、どうせコード変換すれば済むから、正直何でもいい。
その時は、

1.M17Nは諦める。本格的なM17Nが必要な場面では、普通は文字より
グリフが必要とされるから、TRONでも使っておく。

2.ファイルシステムで多言語を使いたい、というような要求は、
M17Nというより、「世界共通ロケール」というべきものだから、
全部UNICODEで表して、世界共通のcollation(単なる数字の比較
でも十分だろう)とかも決めてしまうのが正しい。

3.I18Nに限定すれば、バックスラッシュ問題なんかは全部locale
ごとにポリシーを決めれば済むから、互換性問題はクリアできる。
合字や包接の扱いも、localeのポリシーで決める。ここはSJIS等で
昔から行われて来た習慣に素直に従う。

4.外部コードと内部コードを厳密に区別する。たとえ内部コードに
UNICODEもどきを使うとしても、それはSJISなりEUC-JPなりの
内部表現であって、UNICODEとは別物であるとはっきり決める。
当然ここでは、そのlocaleで1対1に変換できることを優先する。
逆に、外部コードとしてのSJISとUNICODEが1対1でなくても、それは
変換したユーザの責任とする。

ここまでやれば、最大限互換性、柔軟性を確保できると思う。
相変わらずWebページの文字コードをどうするか、とかそういう問題が
残るにしても、内部コードじゃないから、1対1の縛りは弱い。だから、
「ページを作る人が勝手に決める」でも何とかなる(現にあまり問題に
なっていない)。逃げと言われればその通りではある。

>>963
文字コード問題は歴史的な経緯があるので、
どんなに新文字コードを考えようと混乱するよ。
日本で事実上SJISとかEUCとかが普及してるのだから互換性の問題は発生せざるを得ない。

TRONはグリフを集めているだけで、実際の使用とかの事を考えてあるとは思えない。
グリフにこだわるというなら行き着く先はPostScriptだと思うよ。
漢字圏以外の国の事情はよく分からないみたいで、Unicodeに頼ってる部分もあるし。
「後から文字を追加できます。」なんてのは言い訳だろ。それならUnicodeだって同じだ。

現存のコード体系(SJIS、EUC)との互換を重視しつつUnicodeに徐々に移行するのがベターだと思うけどね。
CISなんてやめて、Unicodeベースで、依存コードとの互換性は文字コード変換で乗り切る。

>>964
Unicode同士の互換性すら無くなっているのはいかがなものか。
963の言う通り、ディスク上のプレーンテキストがいくら化けても、
致命的にならないのは確かだけど、バイナリファイルやアプリケーション
内部でバイト数が変わったらシャレにもならない。

>>965
内部はUTF-32でいいじゃん。
これなら文字数が変わらない限り、オクテット数は狂わないよ。
1文字 = 4オクテットで文字数数えるのもらくちんだし。

>>966
結合文字はどうする？

>>967
結合文字は廃止して
全部正規化して欲しい。

結合文字って分割してはならないもんなんだっけ?

>>968
そりゃSystem1だ。

今のUnicodeの使い方を見てると、DIS 10646で良かったじゃんという気がする。
統合漢字なんて面倒なだけ。

>>971
今更ぼやいても、変わらない。

>>971-972
DIS1なんて最低だと思うが。

>>973
DIS1なんて、あんなISO-2022もどき否決されて当然。
Unicode 使うなら Unicode 3.2.0!

>>974
ISO-2022もどきだからこそ無難だという説もある。
Unicodeなんて後発のくせに結局ぐちゃぐちゃになっちゃったし。

>>975
別に、Unicodeだけ使うことを考えればぐちゃぐちゃでも無いだろ。

UNICODE駆逐プログラム
simaguni.pl
UTF-8、UTF-16でエンコードされた文字列（%xx%xx%xx）を
SJIS,JIS,EUCにデコードしてくれる。
→国内向けシステムのUNICODE対策コストを節約できるかも。
http://hp.vector.co.jp/authors/VA014700/simaguni.html

>>977
そして????だらけになるという罠。

>>977
外部データを取り込む部分だけ改造すれば済むという意味では良い。

?978
実体参照だ、実体参照を使うんだ、ルーク

まもなく１０００か。
よく続いたな

1000ゲッターはいつ頃くるんだ?

今出ますた。

1000取ります！！

でも明日はお仕事で忙しいから
夜まで取っておいてね☆

>>984
で、そろそろ夜なんだが…

1000!