- 1 名前：デフォルトの名無しさん [03/09/10 16:04]
- 文字コード変換について語りましょう♪
- 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
面倒
- 432 名前：デフォルトの名無しさん mailto:sage [04/03/08 20:38]
- >>431
ポマエラ、公開しても落としに来ないくせに。
- 433 名前：デフォルトの名無しさん mailto:sage [04/03/08 21:39]
- 既存のアルゴリズムで速くなければ意味ない。
- 434 名前：デフォルトの名無しさん mailto:sage [04/03/08 22:55]
- 古いアルゴリズムでマルチバイト対応のパターンマッチング処理は
恐ろしくムダ。
文字クラスの対応パッチなんて組み合わせが爆発するロジックのがある。
- 435 名前：デフォルトの名無しさん mailto:sage [04/03/08 23:19]
- >>391
そういう優れたUTF-8というものが既に存在しているのに、なんで
新しくわざわざ欠点の多い符号化法を提唱するのかねぇ？
- 436 名前：デフォルトの名無しさん mailto:sage [04/03/08 23:34]
- Unicodeの合成文字って、合成する順序は決まってるんですか?
必ず。Group-1 ---> Group-2 ---> Group3 の順序で符号を並べる
のか、それとも、順序は動でもいいのか。
順序がどうでもいいなら、完成形としては同じになるのに、符号としては
異なる文字もあることになる。
ハングル文字なんかも、合成済みの物と、素片(?)のものとがあったから、
検索するときは配慮しないと行けないような。
- 437 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/08 23:41]
- >>435
日本語の文字に対するバイト数の増加が納得できないため。
- 438 名前：デフォルトの名無しさん mailto:sage [04/03/08 23:48]
- >>436
順序どうでもいいよ。
配慮しないといけないよ。
現実ってこんなもん
- 439 名前：デフォルトの名無しさん mailto:sage [04/03/08 23:51]
- >>438
ということは、合成文字に関しては、1バイト単位での検索ルーチンでは
対応できないということですね。
ちゃんとしたロジックを組まないと行けないんでしょうね。
- 440 名前：デフォルトの名無しさん mailto:sage [04/03/08 23:59]
- >>436
ttp://www.unicode.org/versions/Unicode4.0.0/ch02.pdf
の2.10辺りとかを参照。
> 完成形としては同じになるのに、符号としては異なる文字
も「あり」。
じゃあ文字を比較するときどうすんだ、というのは
ttp://www.unicode.org/reports/tr15/tr15-23.html
辺りとかを参考にどうぞ。
- 441 名前：デフォルトの名無しさん [04/03/09 01:18]
- もう面倒くさいから一文字64bitでいいよ
でかけりゃgz
- 442 名前：デフォルトの名無しさん mailto:sage [04/03/09 01:43]
- 合成文字は終端記号として処理すべきかギモンヌ。
なぜtexのようなシンタックスとして扱わんのかと。
- 443 名前：デフォルトの名無しさん mailto:sage [04/03/09 09:29]
- >>441
さんせー
- 444 名前：さっきゅん ◆GG1SfzBGbU mailto:sage [04/03/09 09:33]
- ＿
/～ヽ
(｡･-･) ｡oO( 64bitじゃぜんぜん足りませんが何か
ﾟし-Ｊﾟ
- 445 名前：デフォルトの名無しさん mailto:sage [04/03/09 09:40]
- 256bitでどうだコンチクショー
- 446 名前：デフォルトの名無しさん mailto:sage [04/03/09 10:03]
- >>445
どんだけ使えば気が済むんですか。
- 447 名前：さっきゅん ◆GG1SfzBGbU mailto:sage [04/03/09 13:22]
- ＿
/～ヽ
(｡･-･) ｡oO( 最初からグリフでデータ交換すれば文字コードなんて概念消滅するんだけど
ﾟし-Ｊﾟ
- 448 名前：デフォルトの名無しさん mailto:sage [04/03/09 13:29]
- utf-2000とかどうか。
- 449 名前：デフォルトの名無しさん mailto:sage [04/03/09 13:41]
- >>447
お前さんの言う「グリフ」ってのは「グリフイメージ」のことか？
- 450 名前：デフォルトの名無しさん mailto:sage [04/03/09 13:42]
- >>448
古い。
- 451 名前：デフォルトの名無しさん mailto:sage [04/03/09 14:34]
- 検索どうするんだよ
- 452 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/09 15:00]
- >>447
それだと、フォントが変えられないし、HTMLブラウザやコンパイラや
インタプリタに光学文字読み取り機を内蔵しなきゃならないし。
- 453 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/09 15:02]
- 合成文字まで考えるとやはり、結局固定長符号でも可変長符号でやる場合と
余り手間が変わらないのかな。
- 454 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/09 15:06]
- 合成文字がある場合は、UCS4符号を使っていたとしても、例えば「n文字目」の
ポインタを得たいとき、言わずもがな、いきなり
ptr = &linebuf[n-1]
みたいなことをやるわけにも行かず、普通は、カレント位置から順番にたどって
行くことになるだろうらら。
- 455 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/09 15:07]
- 合成文字まで考えると、結局、UTF8でも、ASCIIしか考慮していない
strstr()では正しく検索できないね。
- 456 名前：デフォルトの名無しさん mailto:sage [04/03/09 16:59]
- >>444
この世の中に180京文字以上もあるのか？
1つの言語ごとに1億文字分のスペースあたえても余裕だと思うが。
>>合成文字
手抜きせず全部展開これ最強。
もっと富豪になれいつまでも貧乏性はｲｶﾝ
- 457 名前：デフォルトの名無しさん mailto:sage [04/03/09 17:14]
- >>456
8文字しか表現できないと思ったのか？
- 458 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/09 17:23]
- >>456
>この世の中に180京文字以上もあるのか？
64BITじゃ足りないというのは、合成文字も含めてのことでは?
- 459 名前：デフォルトの名無しさん mailto:sage [04/03/09 19:56]
- ⑳の大きいやつとか㍍とか合成顔文字とか、
そんなのをどんどん含めていくとして
まあそれでも一億は越えないよな。
- 460 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/09 23:52]
- 日中混合漢字テーブルを作ってみました:
www.nowsmartsoft.or.tv/nws/Japanese/japan_china.htm
- 461 名前：デフォルトの名無しさん mailto:sage [04/03/10 01:33]
- 文字コード変換について語りましょう♪
- 462 名前：デフォルトの名無しさん mailto:sage [04/03/10 03:08]
- たぶん24ビット（1677万文字）もあれば、合成なしで世界中の全部の文字を収録することが
出来そうな気がするが…
- 463 名前：デフォルトの名無しさん mailto:sage [04/03/10 07:47]
- >>462
DecompositionやNFDを使うのは派生形や辞書順での扱いを容易に
するためであって、文字が足りないからではない。
- 464 名前：デフォルトの名無しさん [04/03/10 10:37]
- >>463
- 465 名前：デフォルトの名無しさん mailto:sage [04/03/10 15:11]
- >>464
- 466 名前：デフォルトの名無しさん mailto:sage [04/03/10 15:15]
- >>465?
- 467 名前：デフォルトの名無しさん mailto:sage [04/03/10 18:36]
- >>467
- 468 名前：467 mailto:sage [04/03/10 18:36]
- _|￣|●
- 469 名前：デフォルトの名無しさん [04/03/11 16:20]
- Webアプリでhtmlで漢字入力した場合、サーブレットを通して最終的にJSPで表示する際、
どうしても文字化けが起こってしまいます。この場合に対処する方法としての
プログラムの記述の仕方を知っている方がいらっしゃたら教えてください。
|
 |
