- 1 名前：デフォルトの名無しさん [03/09/10 16:04]
- 文字コード変換について語りましょう♪
- 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]
- てかコテハンでうだうだやるのもほどほどに。
俺様規格考えた〜まではまぁ、いいかもしれないが、その先はここでやらんと自サイトに掲示板でも
作ってそこで勝手にやってて欲しいな。
面白いとおもった香具師はそっちで反応するだろう。少なくともここでやられては迷惑なだけだ。
- 408 名前：デフォルトの名無しさん mailto:sage [04/03/08 13:22]
- >>407
どうせ余所でやっても見ないし。俺はここでやってくれてかまわないよ。
別のネタを話すにしても並行して話せばいいだろう。今までもそうやって
きたんだから。
- 409 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/08 13:24]
- >>407
分かりました。
UTFCP符号について興味のある人は、下記の「UTFCP符号について」ス
レッドで議論を継続するようにして下さい:
www.nowsmartsoft.or.tv/bbs/test/read.cgi/NWSOS/
- 410 名前：デフォルトの名無しさん mailto:sage [04/03/08 13:24]
- 俺もここでやるのは構わないけど、コテハンでやるなら
多少煽り口調で言われても落ち着いてキレずにやって欲しいのぅ。
- 411 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/08 13:26]
- >>410, >>408, >>407
個人的にはどっちでもいいです。
- 412 名前：デフォルトの名無しさん mailto:sage [04/03/08 13:37]
- だんだん本性を現してきたな。
自分の巣に帰りなよ。貴公子さんよ。
pc.2ch.net/test/read.cgi/os/1075632569/
- 413 名前：デフォルトの名無しさん mailto:sage [04/03/08 13:43]
- >>403
でもそのOSがあんな前時代的な仕様ではねぇ・・・
- 414 名前：デフォルトの名無しさん mailto:sage [04/03/08 13:48]
- >>413
？
何か困る事でも？
- 415 名前：デフォルトの名無しさん mailto:sage [04/03/08 13:51]
- >>414
>>403 生き残りは辛そうだから、
- 416 名前：デフォルトの名無しさん mailto:sage [04/03/08 13:59]
- そういや、中国のGB2312って、日本のひらがな、カタカナが含まれるって
本当?
- 417 名前：デフォルトの名無しさん mailto:sage [04/03/08 14:07]
- >>416
らしいね。
big5にも入ってるって話だぞ。
- 418 名前：デフォルトの名無しさん [04/03/08 14:29]
- >>416
>>336
- 419 名前：デフォルトの名無しさん mailto:sage [04/03/08 14:48]
- ここで UTF-8 以外のコードを提案してる人って、
SQL とかそーいうものも全部これから用意しよう、用意されるはずだ、というような
主張も imply してるって考えていいのかな。
それとも既存ライブラリやシステムと関連しない小規模な自作PG用としての提案なのかな。
そのへんはっきりさせてくれないと、批判とか批評とかしにくいと思うんだけど。
- 420 名前：328 mailto:sage [04/03/08 15:02]
- ねぇねぇ最初UTF-JPじゃなくてUTF-JAPANじゃなかった？
- 421 名前：デフォルトの名無しさん mailto:sage [04/03/08 15:06]
- UTF-ｼﾞｬﾍﾟｰﾝ
- 422 名前：デフォルトの名無しさん mailto:sage [04/03/08 15:07]
- COMPJAPAN互換？
- 423 名前：デフォルトの名無しさん mailto:sage [04/03/08 16:22]
- 大多数にとっては標準化を考えているのかどうか、それだけが問題じゃないのか？
こんなん考えました〜 だけだと誰もついてこないと思われ。
- 424 名前：デフォルトの名無しさん mailto:sage [04/03/08 16:26]
- 俺エンコーディング大流行の予感。
- 425 名前：デフォルトの名無しさん [04/03/08 17:34]
- >SQL とかそーいうものも全部これから用意しよう、
>用意されるはずだ、というような
8bit目がonであればたいていOKなんだが。
あと再コンパイルが許されるならUCS-4が一番楽だろ。
C++ならインターフェース変更するだけでロジックは変わらんのだから。
- 426 名前：デフォルトの名無しさん [04/03/08 18:40]
- 質問させてください。
PHPで、EUCでソースを保存して、
CHARSETをShift_jisでブラウザ出力させたいのですが、
どうやったら出力させることができるでしょうか？
教えて下さい。お願いします。
- 427 名前：デフォルトの名無しさん [04/03/08 18:41]
- PHPで、ソースをEUCで保存して、
Shift_jisでブラウザに表示したいのですが、
どうしたらうまくいくでしょうか？
ご存知の方、おしえてください。お願いします。
- 428 名前：デフォルトの名無しさん mailto:sage [04/03/08 18:47]
- 俺も新しいコードを考えてここの住人を煽ろうかな。
- 429 名前：デフォルトの名無しさん mailto:sage [04/03/08 19:37]
- >>425
>8bit目がonであればたいていOKなんだが。
いや、エラー無く通るってだけじゃなくて、検索とかさ・・・
- 430 名前：デフォルトの名無しさん mailto:sage [04/03/08 20:20]
- lexとかgrep関係はいろいろとあるんだけど、
それは適切なアルゴリズムでちゃーんとビルドフロムスクラッチすればOK。
- 431 名前：デフォルトの名無しさん mailto:sage [04/03/08 20:30]
- >>430
面倒
|
 |
