- 1 名前：デフォルトの名無しさん [03/09/10 16:04]
- 文字コード変換について語りましょう♪
- 307 名前：デフォルトの名無しさん mailto:sage [04/03/04 11:16]
- みんなUTF-8で結構おなか一杯だからなぁ。
- 308 名前：デフォルトの名無しさん mailto:sage [04/03/04 11:32]
- >>303
Unicodeを混ぜることができる,EUC-JP/シフトJISの一種と考えたら
そこそこ面白い。
- 309 名前：デフォルトの名無しさん mailto:sage [04/03/04 12:43]
- >>308
その手の拡張は>>239にもあるし>>240-にもあるしおなかいっぱい
- 310 名前：デフォルトの名無しさん mailto:sage [04/03/04 13:21]
- 主にどういう局面で利用される事を想定してるんだろうか。
UTF-8でも少しサイズが大きい程度で、そんなに気にならないんだけど。
独自にやる苦労に見合うだけの結果が得られるかは微妙だ。
打算計算を抜きにすれば、自作のOSで自作の文字コード使って
色々実験するのは楽しそうとは思うけどね。(^^;
- 311 名前：LightCone ◆sSJBc30S5w [04/03/04 16:31]
- >>308, >>309
「Unicodeを混ぜることの出来るEUC-JP/SJIS」に、「簡単に逆戻り可能」な
性質を取り入れたような感じなんです。
ちなみに、>>239の符号では、逆戻りは出来ないと思いますが、
さらに、「\」コードを含んでいるので、色々と問題があると思います。
というわけで、いかがでしょうか。
新しいコードは、みんなが使い始めるか、よっぽど良い性質がない限り、
抵抗感がある物かも知れませんが。
- 312 名前：LightCone ◆sSJBc30S5w [04/03/04 16:42]
- >>310
>主にどういう局面で利用される事を想定してるんだろうか。
>UTF-8でも少しサイズが大きい程度で、そんなに気にならないんだけど。
そう思われる人が多いのであれば、せっかくでしたが、余り意味がないかも
知れません。
でも、今まで2BYTE表せていた文字に3BYTEを当てるのに抵抗がある人には、
需要があるのではないかと思うんです。
その点だけでは、>>239の符号もいいと思いますが、UTF-JAPANの方は、
逆戻り可能の性質を持っている点や、多バイト文字に\コード等を含んで
ない点で、解析やエディタ作りなどにおいて、真価を発揮する場面がある
のではないかと思います。
EUCも、2バイトの範囲では逆戻り可能ですけど。>>239に書かれている拡張EUC:
web.archive.org/web/20030218074331/www.ksky.ne.jp/~smile4me/charcode/xeucjp.htm
においては、UTF-16,UTF-32対応する3バイト以上のコードでは、逆戻りが
出来なくなっているようですし。
- 313 名前：LightCone ◆sSJBc30S5w [04/03/04 16:46]
- >>304
この符号の場合、基本的に地域や言語ごとに違う変換テーブルを用意する
必要がありますね。それをOSがサポートして、欲しいフォーマットに
まで変換を世話してくれればアプリの負担は減るとは思うんですが。
全世界で全く同じコードを用いたいのであれば、漢字が３バイトになって
しまうのは、元々やむを得ないかも知れない。
- 314 名前：LightCone ◆sSJBc30S5w [04/03/04 16:53]
- >>305
UTF-8の場合、strcmp()は、単純な昔ながらの1バイト単位の比較のまま
無修正で利用できてしまうんですよね。
それは凄い性質ではあると思いますが、結局、コードを無修正で済ました
いばっかりに、データサイズが大きくなる犠牲を払っているんだと思うん
です。
- 315 名前：LightCone ◆sSJBc30S5w [04/03/04 16:54]
- なお、
UTF-JAPANを、「UTF-COMPACT-JAPAN」と改名して、
「UTF-COMPACT-ARABIA」
「UTF-COMPACT-CHINA」
なども定義すれば、strcmp()等の修正は、言語数分まで及ばずに
一回だけで済むかも知れませんね。
- 316 名前：LightCone ◆sSJBc30S5w [04/03/04 16:57]
- >>237 から続く発言は、なんと先月のものなんですね！
うまく合併できないかな。
- 317 名前：LightCone ◆sSJBc30S5w [04/03/04 17:02]
- >>261の
>CPU等が速くなってんのにアプリの体感速度が変わらないとう現象の
>原因を作っている人たちはココにいたんですね。。
これは、今まで2バイトで表現できていた物を3バイトにしようとすることとも
その一つかな。
全世界の文字を使えるのはいいことではあるけれど、日本人が、英語と
JIS第一,第二以外の言語を使用する頻度は低いし、文字集合はUNICODEを
使うにしても、地域ごとに違った符号があってもいいのではないかな。
- 318 名前：LightCone ◆sSJBc30S5w [04/03/04 17:04]
- UTF-COMPACTの変換テーブルは、OSが提供するだろうから、
UTF-COMPACT-xxxxx用のアプリは、いずれのxxxxx言語にも
無修正で対応できるのではないだろうか?
- 319 名前：LightCone ◆sSJBc30S5w [04/03/04 17:10]
- 例えば、HTMLヘッダに、
<meta http-equiv="Content-Type" content="text/html;
charset=
utf-compact-japan">
~~~~~~~~~~~~~~~~~
を書いておけばいいんじゃないかな。
SJISや、EUC-JPでやってることと何ら変わりないと思うし。
- 320 名前：デフォルトの名無しさん mailto:sage [04/03/04 17:25]
- アメ公がUTF-16嫌ってUTF-8に走るのとまったく同じ論法だよね
自分たちが使いもしない文字のことなんてどうでもいいと思うのは
世界共通というか
- 321 名前：LightCone ◆sSJBc30S5w [04/03/04 17:34]
- >>320
でも、自分たちの地域で効率を上げることにも、一利はあると思うんです。
UNICODEを全否定しているわけではなく、符号長に地域ごとに偏りを
持たせるだけですし。
- 322 名前：LightCone ◆sSJBc30S5w [04/03/04 17:36]
- SFみたいな世界になって、文字種が爆発的に増えた場合、やっぱり、
地球では地球語に短い符号を割り当てるんじゃないかな。
そういう意味で、偏りを持たせる発想は、古くさい考えではないと思う。
- 323 名前：デフォルトの名無しさん mailto:sage [04/03/04 17:38]
- だったらローカルコードでいいし
地域の数だけ馬鹿でかい変換テーブル持つなんて馬鹿の極み
- 324 名前：デフォルトの名無しさん mailto:sage [04/03/04 17:41]
- 日本語が多くてサイズが増えるのが嫌なら、UTF-16を使えばいいのでは？
- 325 名前：デフォルトの名無しさん mailto:sage [04/03/04 17:41]
- > 制御コード、特殊記号、\コードを含まず
C1文字は制御コードじゃありませんか
そうですか
- 326 名前：デフォルトの名無しさん mailto:sage [04/03/04 17:43]
- > JIS X 0213 2000 JIS第三、第四 4344字
今さら2000年版かよ
- 327 名前：デフォルトの名無しさん mailto:sage [04/03/04 17:43]
- > 情報交換用漢字符号系
つーかずいぶんと古い資料参照してるな
- 328 名前：デフォルトの名無しさん mailto:sage [04/03/04 17:44]
- そもそもたった一つのインプリで他言語をカバーしようとしたのがUnicodeじゃないの？
それを地域ごとに独自テーブル作ったら意味ないじゃん
- 329 名前：デフォルトの名無しさん mailto:sage [04/03/04 17:44]
- > /[^\x81-\xde]任意の文字列/
「任意の文字列」が先頭だったらヒットしなくなるね
- 330 名前：328 mailto:sage [04/03/04 17:45]
- 失礼
X他言語
O多言語
- 331 名前：328 mailto:sage [04/03/04 17:47]
- そもそも
UTF-JAPAN
ってのがかっこわるいよね
せめて
UTF-JPとかUTF-jaとかにすればいいのに
- 332 名前：デフォルトの名無しさん mailto:sage [04/03/04 17:48]
- せめてもう少し間隔おいて自演したら？
- 333 名前：デフォルトの名無しさん mailto:sage [04/03/04 17:49]
- > SJISや、EUC-JPでやってることと何ら変わりないと思うし。
なんら変わりなく欠点を引き継いでどうするんだよ
- 334 名前：デフォルトの名無しさん mailto:sage [04/03/04 17:51]
- >>332
誰に言ってるんですか?
- 335 名前：デフォルトの名無しさん mailto:sage [04/03/04 18:41]
- ちょっと考えてはみたけど、UTF-8越えは難しいな。
使っててあまり不満ねーもの。（慣れたのもある）
その俺コードで外人と文書のやり取りする時はどうする気なんだ？
>>331
確かに微妙な名前だ。
>>333
文字集合がUnicodeでやろうと思えば多くの文字を表現出来る点が重要なんじゃね？
サイズを気にするなら圧縮で十分って気がするけど。
- 336 名前：LightCone ◆sSJBc30S5w [04/03/05 00:09]
- 中国には、JIS第一水準と同様に、「第一級漢字」が定まっていて:
www.kishugiken.co.jp/cn/code09c.html
このようになってます↑
ご覧の通り、JIS第一、第二水準と重複する部分も多く、興味深いのです。
これと、JIS第一水準を合わせた部分を2BYTEで表せるような、UNICODE符号を
作れば、中国人と日本人の両方にメリットがあるかも知れないと思うのですが、
いかがですか?
- 337 名前：LightCone ◆sSJBc30S5w [04/03/05 00:17]
- ちなみに、UNICODEのCJK統合漢字部分は、頻度の低い漢字も何も考えずに
並べてあり、頻度毎に分類できないので、どうしても22000文字程度
をまとめて符号化する必要があります。ASCII符号と互換性を持たせ
つつ、これら全ての文字集合を2BYTEで表現しきることは、ほぼ不可能
です。
しかし、中国の第一級、第二級漢字と、日本のJIS第一、第二水準漢字
には重複する部分が多く、それらの「和集合」の文字なら、2BYTEで
表せる範囲の数ではないかと踏んでるんです。
- 338 名前：デフォルトの名無しさん mailto:sage [04/03/05 00:19]
- 各文字に割り振るコードの順番にも意味があるから、単に足し合わせれば良いという物でも
ないと思うけど。
- 339 名前：LightCone ◆sSJBc30S5w [04/03/05 00:23]
- 大体の目安としては、一万五千字程度の文字なら、ASCII符号と互換性
を持たせ、「逆戻り可能」で、しかも、後続バイトを付ければUCS-4全体
を表現しきれるような、2BYTEの符号を作る事が出来ると見ています。
- 340 名前：LightCone ◆sSJBc30S5w [04/03/05 00:27]
- >>338
せっかく、JIS第一水準で五十音順、第二水準で部首順になってるのが、
中国の文字セットと合成した際に失われると言うこと?
- 341 名前：デフォルトの名無しさん mailto:sage [04/03/05 00:28]
- GB18030は何文字格納できるんだっけか？
- 342 名前：LightCone ◆sSJBc30S5w [04/03/05 00:29]
- UNICODEでは、部首順らしいので、統合する際にそれにならえばいい
のでは?
- 343 名前：LightCone ◆sSJBc30S5w [04/03/05 00:30]
- >>341
わても知らんので、調べて。
- 344 名前：デフォルトの名無しさん mailto:sage [04/03/05 00:30]
- >>342
コテハンには聞いていない。
- 345 名前：デフォルトの名無しさん mailto:sage [04/03/05 02:12]
- 150万文字ぐらい入るんだっけか＞GB18030
- 346 名前：デフォルトの名無しさん mailto:sage [04/03/05 13:18]
- >>345
うん。約1,611,668文字かな。
- 347 名前：デフォルトの名無しさん [04/03/05 13:49]
- ちなみに、GB18030は、逆戻り不可だし、検索も複数バイト文字の途中で
ヒットする。
- 348 名前：LightCone ◆sSJBc30S5w [04/03/06 00:44]
- UNICODEの新符号「UTFCP」を発案しました:
nowsmartsoft.or.tv/nws/Japanese/nwsos_utf.htm
2バイトの符号で1万5千文字以上を表せて、なおかつ、文字列を文字単位で
正確に逆戻りできる、UNICODE符号です。UCS-4全体を表現できます。
また、多バイト符号にASCII符号を一切含まないので、英大文字小文字変換に
対しても安定です。
理論上、日本語のJIS第一、第二水準漢字、中国語の第一級、第二級漢字の両方
をコードページの切り替えなしに2BYTE符号で表せますので、
UTF8に比べ、頻度の高い日本語や中国語の文章が2/3に(50%減)コンパクトに
なります。
いかがでしょう？ (^_^;)
- 349 名前：デフォルトの名無しさん [04/03/06 01:44]
- ハードディスクが何百GBになる時代に、テキストファイルの容量が数十%減ったくらいでは
あまり利点を感じないけどなぁ。
むしろ、>>240-243みたいに(書いたの漏れだけど)EUC-JPやShift_JISの完全上位互換規格を
考えたほうがまだ意味があると思う。
- 350 名前：デフォルトの名無しさん mailto:sage [04/03/06 07:53]
- 情報の冗長性を取り除いて小さくまとめようとすると
たいてい少し複雑な演算が必要になるよね。
UTF8と張り合うなら演算量も念頭にいれる必要があるかも。
UCS4とUTF8の変換では１〜２個の条件分岐と
長さ*(シフト、OR、AND)演算＋入出力程度で変換してる。
- 351 名前：デフォルトの名無しさん mailto:sage [04/03/06 08:13]
- >>348
各文字コードの主要な正規表現エンジン各々での探索コストの大まかな比較をやってみてほしい。
- 352 名前：デフォルトの名無しさん mailto:sage [04/03/06 12:06]
- ただでさえ混乱している文字コード周りの処理をさらに混乱させないでくれ。
- 353 名前：デフォルトの名無しさん mailto:sage [04/03/06 12:21]
- >>348
「俺コード」を作るな。
有用だと信じるなら、IETFとかUnicode.orgにでも提案しろ。
- 354 名前：デフォルトの名無しさん mailto:sage [04/03/06 13:50]
- >>352-353
作るのは勝手なんじゃね？
気に入らないなら使わなけりゃ良いだけ。
案が未熟だというだけで作る事自体を否定するものではないかと。
因みに俺もUTF8で不満は無い。
文字コードみたいなもので冒険せずに他で頑張った方が良いんじゃないかと。
高いリスクを冒した結果、成功したところで見返りは小さい。
- 355 名前：デフォルトの名無しさん mailto:sage [04/03/06 14:12]
- まあ、独自Unicode系CESなんて、普及するわけもないから、
悪影響も少ないわな。機種依存文字なんかはすぐに悪影響が出るけど。
- 356 名前：デフォルトの名無しさん mailto:sage [04/03/06 19:34]
- 俺アプリのベースエンコーディングに使う為の独自エンコーディングの開発ならオケですか？
- 357 名前：デフォルトの名無しさん mailto:sage [04/03/06 20:49]
- 俺OSのベースエンコーディングに使う為の独自エンコーディングの開発ならオケです。
- 358 名前：デフォルトの名無しさん mailto:sage [04/03/06 21:35]
- >>350
1つの文字を複数の表現で符号化できる規則は可能なら避けたほうがいい
UTF-8で避けようとすると加減算が余分に入るけど
- 359 名前：デフォルトの名無しさん mailto:sage [04/03/07 01:11]
- お前ら釣られるなよw
- 360 名前：デフォルトの名無しさん mailto:sage [04/03/07 03:20]
- >>358
UTF-8は一つのコードに対して複数の表現は許していないはずだけど
文字とか字形の話…？
- 361 名前：デフォルトの名無しさん mailto:sage [04/03/07 04:05]
- >>360
・・・・は？
- 362 名前：LightCone ◆sSJBc30S5w [04/03/07 19:28]
- UTFCPについて、詳しく書いておきました。
符号の読み取りや、逆戻りの状態遷移図やソースプログラムもあります。
また、1バイト単位の正規表現ルーチンでも検索に利用できることも分かったので
書いておきました。
www.nowsmartsoft.or.tv/nws/Japanese/nwsos_utf.htm
- 363 名前：デフォルトの名無しさん mailto:sage [04/03/07 19:34]
- 2chで宣伝とは・・・
- 364 名前：デフォルトの名無しさん mailto:sage [04/03/07 22:20]
- >>362
gobackUTFCP が動くとは思えないのだが。
- 365 名前：LightCone ◆sSJBc30S5w [04/03/07 22:54]
- >>364
動くと私は思います。
動かないと思われる例を挙げてみて下さい。(^_^;)
- 366 名前：デフォルトの名無しさん mailto:sage [04/03/07 23:02]
- >>362
だから○とか×じゃなくて探索コストで比較しろって。
あんたが主張する利点は対象データの処理がUTF8に比べて
速いということだろ。今の状態では説得力0だ。
- 367 名前：デフォルトの名無しさん mailto:sage [04/03/07 23:05]
- >>366
いい加減放置しろって・・・
明らかな宣伝ということで削除依頼もしておいた。
- 368 名前：LightCone ◆sSJBc30S5w [04/03/07 23:09]
- >>366
速いという事じゃなく、サイズがコンパクトと言うこと。
ディスクに保存するときは速いだろうけど。
- 369 名前：デフォルトの名無しさん mailto:sage [04/03/07 23:19]
- >>368
んなんだから、院試に落ちるんだよ。
偉そうなお題目なんてのは後にしろ。時間の無駄だ。
- 370 名前：LightCone ◆sSJBc30S5w [04/03/07 23:24]
- >>369
どの大学の、何学科の院試か知りませんが、工学部の院で良ければ、
東大でも受かります。
- 371 名前：LightCone ◆sSJBc30S5w [04/03/07 23:25]
- 第一、京大の理学部物理学科だって、研究室によれば簡単に受かるし。
- 372 名前：デフォルトの名無しさん mailto:sage [04/03/08 00:13]
- >>365
動く動かないは別として、初期状態が符号列の最後のバイトに
なければならないというのがダメダメ。
そんな前提を置いた上でなら、EUCだってSJISだって
「複数バイト文字の最後のバイトから高々符号長分遡るだけで、
その符号の先頭バイトを発見可能」
って言えてしまうんだが。
- 373 名前：LightCone ◆sSJBc30S5w [04/03/08 00:36]
- >>372
>そんな前提を置いた上でなら、EUCだってSJISだって
>「複数バイト文字の最後のバイトから高々符号長分遡るだけで、
>その符号の先頭バイトを発見可能」
>って言えてしまうんだが。
言えません。
例えば、SJISでは、
全角「キ」のコードは、0x83, 0x4c
全角「ャ」("キャ"などの小さい"ヤ")のコードは、0x83,0x83
半角「c」のコードは、0x63
全角「宴」のコードは、0x89, 0x83
全角「ツ」のコードは、0x83, 0x63
となり、
キャc ---> 0x83, 0x4c, 0x83, 0x83, 0x63
宴ツ ---> 0x89, 0x83, 0x83, 0x63
となるので、cにあるとき遡ると、0x63,0x83,0x83と
なり、ツの最後のバイトにあるとき遡ると、0x63,0x83,0x83となり、
全く同一になり、cなのか、ツなのか区別が付かない。
EUCでは、最後尾バイトからスタートする限りは大丈夫。
UTF8では、どこからスタートしても大丈夫。
UTFCPでは、最後尾バイトからスタートする限りは大丈夫。
- 374 名前：LightCone ◆sSJBc30S5w [04/03/08 00:44]
- ちなみに、SJISでは、例えば、
ラャc ---> 0x83, 0x89, 0x83, 0x83, 0x63
宴ツ ---> 0x89, 0x83, 0x83, 0x63
のように、最悪のケース、1000バイトも遡っても、遡り始めた文字が、
半角なのか全角なのか判断付きかねる文字列を作れる。
つまり、「ツ」なら全角、「c」なら半角なのだが、その区別が長く遡っても
なかなか付かないような文字列が存在し得リますです。
- 375 名前：デフォルトの名無しさん mailto:sage [04/03/08 00:50]
- >>374
UTF8より優れているにしろ使われなきゃどうしようもない。
こんなとこよりもっと有効なところで発表すれば？
- 376 名前：デフォルトの名無しさん mailto:sage [04/03/08 01:02]
- >>374
自分のコードがまったくおんなじ問題を抱えているのに
気付いていないんだろうか？
＃こういうのリアルタイムで見たの久しぶりだな...
- 377 名前：デフォルトの名無しさん mailto:sage [04/03/08 01:46]
- >>365
符号が DBA で、現在位置が A のとき。
- 378 名前：デフォルトの名無しさん mailto:sage [04/03/08 01:57]
- > LightCone
まずは自分のOSで使用してみたら？
せっかく独自のOSを開発しているんだから。
- 379 名前：デフォルトの名無しさん mailto:sage [04/03/08 02:14]
- 結論: wchar_t使えやボケ
- 380 名前：デフォルトの名無しさん mailto:sage [04/03/08 02:17]
- >>358
UTF-8では禁止されたはず。
確かそれ周りのセキュリティーホールもあったような。
（特定文字のチェックをすり抜けるようなやつ）
- 381 名前：デフォルトの名無しさん mailto:sage [04/03/08 03:33]
- >>380
イチから作るなら「禁止」じゃなくて理論上重複符号化がありえない
設計にしたほうがいいって趣旨。UTF-8の場合は互換性の問題から
不可能だったわけだが。
セキュリティホールの話は>>232-あたりで出てるね
- 382 名前：デフォルトの名無しさん mailto:sage [04/03/08 05:07]
- UTF-8はtransformation format of ISO 10646なんだから
UCSに戻して使うのが本来の使い方。
それを正しく把握していれば重複符号化が可能でも何ら問題無い。
- 383 名前：デフォルトの名無しさん mailto:sage [04/03/08 07:02]
- >>363
宣伝ではなくて、突っ込み貰うのが目的なんだろ。
叩き台出してみてマシになるかどうかという。
置き換えるには既にUTF-8が広がり過ぎていると思うが。
- 384 名前：LightCone ◆sSJBc30S5w [04/03/08 08:45]
- >>377
>符号が DBA で、現在位置が A のとき。
そんなのは全く問題ありませんよ。あなたが全く理解してないだけです。
www.nowsmartsoft.or.tv/images/UTFCP-BW.png
↑の図を見てもすぐ分かることだし、下の関数冒頭を見ても分かる通り、
*ptr <= 0x7f の判定が真になるので、すぐに、「A」に場合分けできて、
1バイト符号に分類されます。
unsigned char *gobackUTFCP( unsigned char *ptr )
{
if ( *ptr <= 0x7f ) {
//(1) A
ptr--;
}
...
- 385 名前：デフォルトの名無しさん mailto:sage [04/03/08 10:20]
- >>382
> UTF-8はtransformation format of ISO 10646なんだから
> UCSに戻して使うのが本来の使い方。
まったくです。
情報交換用コードと情報処理用コードは分けて考えるべきなのに、
UTF-8をそのまま処理することを考えているのは愚かすぎます。
> それを正しく把握していれば重複符号化が可能でも何ら問題無い。
それはどうかと思いますが。
見識の低い人が実装することもあるわけですし。
- 386 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/08 10:58]
- 逆戻りがなぜ可能か分かりにくい人が多いようですので、
解説しておきます。ご覧アレ:
www.nowsmartsoft.or.tv/nws/Japanese/nwsos_utfcp.htm
これで。UTFCP符号が間違いなく逆戻りできることの証明になって
いると思います。
- 387 名前：385 mailto:sage [04/03/08 10:58]
- >>386
そもそも情報交換用コードで逆戻りする必要がありません。
- 388 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/08 11:00]
- >>387
ASCIIもオンメモリで、32BITで保持するつもりなんでっしゃろか?
- 389 名前：デフォルトの名無しさん mailto:sage [04/03/08 11:11]
- >>388
必要ならそうするんでは?
ASCIIだけでよい文脈なら1バイトで処理すればいいし、
そうでないなら4バイトで処理すればいいですし。
あと保持というのがよく分かりません。UTF-*とUCS*の
どちらで保持するかは文脈によるのでは。
- 390 名前：デフォルトの名無しさん mailto:sage [04/03/08 11:14]
- ときどきいるよね。自称大発見とか大発明とか。
そろそろ春も近いしね。
- 391 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/08 11:20]
- >>385
そもそも、情報交換用なら、BOCU圧縮を使えば、UTF8よりコンパクトに
なる:
www-6.ibm.com/jp/developerworks/unicode/010921/j_u-binary.html
UTF8は、情報処理用としてもかなり考慮されていて、ASCII用に書かれ
た古い検索ルーチンや文字処理ルーチンを無修正でUnicodeに対応でき
る特徴をっている。こんな特性は、よく知られている他の可変長符号に
はない。
- 392 名前：デフォルトの名無しさん mailto:sage [04/03/08 11:28]
- 別に内部コードとしてUTF-8を採用することが
禁止されてるわけでもないのに愚か過ぎるだの見識が低いだの
とまで言われなければならない理由は何ですか
- 393 名前：デフォルトの名無しさん mailto:sage [04/03/08 11:32]
- >>383
意見を求めているふりをして人の話などぜんぜん
聞くつもりがないところを見る限り違うような気がします。
では何が目的なのかと言われてもさっぱり分かりませんが
- 394 名前：デフォルトの名無しさん mailto:sage [04/03/08 11:34]
- >>391
> UTF8は、情報処理用としてもかなり考慮されていて、ASCII用に書かれ
> た古い検索ルーチンや文字処理ルーチンを無修正でUnicodeに対応でき
> る特徴をっている。こんな特性は、よく知られている他の可変長符号に
> はない。
それはEUC-JPでも普通に行われてきたのでは?^^;
「問題が出ないようにしてある」のと「情報処理用に作ってある」のとは別です。
EUC-JPでもShift JISでもISO-2022-JPでも、内部処理用に使おうと思えば
可能です。実際そういうソフトウェアもあるわけですし。
ただ、その場合処理が複雑になるしその分エンバグする可能性も高いわけです。
> そもそも、情報交換用なら、BOCU圧縮を使えば、UTF8よりコンパクトに
> なる:
> www-6.ibm.com/jp/developerworks/unicode/010921/j_u-binary.html
ここまでするなら、レイヤーを分けて普通にハフマン符号化した方が良いと思うんだけど。
- 395 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/08 11:38]
- >>394
>それはEUC-JPでも普通に行われてきたのでは?^^;
多分、UTF8の特性をご存じない。
EUC-JPでは、全角文字をASCII用のstrstr()で探そうとすると、
別の全角文字の途中にヒットしてしまうことがあるが、UTF8では
ない。
- 396 名前：デフォルトの名無しさん mailto:sage [04/03/08 11:43]
- >>395
> EUC-JPでは、全角文字をASCII用のstrstr()で探そうとすると、
> 別の全角文字の途中にヒットしてしまうことがあるが、UTF8では
> ない。
確かにそうですね。失念していました。
- 397 名前：396 mailto:sage [04/03/08 11:48]
- ですが情報処理コードとして適切でないのは明らかです。
strstr()して得た開始位置は、全体の何文字目なのでしょうか?
- 398 名前：デフォルトの名無しさん mailto:sage [04/03/08 11:53]
- ところで疑問なのは
なんでUTFCPとUTF-JAPANと言う二つの符号化方式を用意したかだ。
- 399 名前：デフォルトの名無しさん mailto:sage [04/03/08 11:56]
- それを言うならUCSの一単位は一文字とは限りませんが。
結合音節文字とかご存知ありませんか。
固定長によるインデックスアクセスですべて済まそうと
考えること自体が漢字文化圏の幻想です。
- 400 名前：デフォルトの名無しさん [04/03/08 12:03]
- 400get
盛り上がってきました
- 401 名前：デフォルトの名無しさん mailto:sage [04/03/08 12:11]
- >>384
「if ( ptr[-1] <= 0x7f )」だろマヌケ。
それとも、DBA の B を指すのが正解なのか?
- 402 名前：デフォルトの名無しさん mailto:sage [04/03/08 12:30]
- >>399
> 固定長によるインデックスアクセスですべて済まそうと
> 考えること自体が漢字文化圏の幻想です。
この考えは「どうせAという処理をしなければならないのだから
Bという処理が増えてもかまわない」と言っているようで奇妙
です。問題を分割することは基本なのに。
- 403 名前：デフォルトの名無しさん mailto:sage [04/03/08 12:46]
- >>398
自分のOS作るのにどういう文字コードをメインに据えるかを考えているらしい。
UTF-8だと漢字のサイズが大きいから気に入らないそうだ。
OSとセットでもなけりゃ独自コードの生き残りは辛そうだから、
良い機会と言えば良い機会なんだろうが。
超漢字が無かったらTRONコードなんて……。
- 404 名前：デフォルトの名無しさん mailto:sage [04/03/08 12:52]
- >>402
「どうせ文字数を数えなくてはいけないのだから文字の間に
マッチしたかどうか判定する必要があっても構わない」
というのは奇妙ですよね。要は程度の問題です。
そもそもUCS*ではstrstr()一切使えないし
(charが16ビットや32ビットでない限り)
- 405 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/08 13:10]
- >>401
マヌケなのはあなたです。Aを指すのが正解で、*ptr <= 0x7fのままで
間違ってません。
- 406 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/08 13:13]
- >>398
最初思いついたのが、UTF-JPで、複数バイト文字に、A-Z, a-zなどを
含んでいるのが、欧米人が何も考えずにstrupr()する人が多い事情を
考えると良くないと指摘されて、頭を悩めて作ったのが、UTFCPです。
UTFCPは苦労して導きました。0x80以上だけを使って逆戻り出来る
符号としては、これ以上コード・ポイントは増やせないかも。
- 407 名前：デフォルトの名無しさん mailto:sage [04/03/08 13:16]
- てかコテハンでうだうだやるのもほどほどに。
俺様規格考えた〜まではまぁ、いいかもしれないが、その先はここでやらんと自サイトに掲示板でも
作ってそこで勝手にやってて欲しいな。
面白いとおもった香具師はそっちで反応するだろう。少なくともここでやられては迷惑なだけだ。
|
 |
