1 名前:デフォルトの名無しさん [03/09/10 16:04] 文字コード変換について語りましょう♪
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じゃぜんぜん足りませんが何か ゚し-J゚
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( 最初からグリフでデータ交換すれば文字コードなんて概念消滅するんだけど ゚し-J゚
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] Sの大きいやつとかbとか合成顔文字とか、 そんなのをどんどん含めていくとして まあそれでも一億は越えないよな。
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で表示する際、 どうしても文字化けが起こってしまいます。この場合に対処する方法としての プログラムの記述の仕方を知っている方がいらっしゃたら教えてください。
470 名前:デフォルトの名無しさん mailto:sage [04/03/11 17:30] そんなDQN言語使うからだ
471 名前:デフォルトの名無しさん mailto:sage [04/03/11 18:38] 言語がDQNなのではなく(ry WebProg pc2.2ch.net/php/
472 名前:デフォルトの名無しさん mailto:sage [04/03/11 21:18] 俺の知らない新言語が出来てるのかと思った。
473 名前:デフォルトの名無しさん [04/03/12 00:38] 質問です。 VBscriptを使って 「UTF-8」→「base64」→「UTF-8」のデコードを行いたいのですが、 googleでヒットするいろいろなサンプル関数をためしましたが、例えばこれでも www.geocities.co.jp/SiliconValley/4334/unibon/asp/base64.html どれもbase64→SJISにデコしようとしてる?のか、日本語が文字化けします。 とんでもない見たこともないような特殊漢字に化けます。英数は正常です。 なんとかUTF-8にデコードする方法はありませんでしょうか。 y = decodeStreamSJIS(l, k) ' シフト JIS として解釈する場合。 ' y = decodeStreamEUC(l, k) ' EUC として解釈する場合。 の部分に、unicode(UTF-8)にデコードするものを作ればいいのですが、いかんせん知識不足です。 目的としてはエンコードがかかったファイルをvbscriptバッチをはさみデコードするというものです。 ちなみにbasp21のデコード機能でさえ文字化けしました。 どれもみなSJISには直してくれるのですが、エンコ前の元データがUTF-8で、UTF-8にもどす となると見つかりません。 なにか良い方法はないでしょうか。
474 名前:デフォルトの名無しさん [04/03/12 01:05] すみません、質問です。 JSP画面で漢字表記するために必要なセンテンスって 何でしょうか?教えてください!!
475 名前:デフォルトの名無しさん mailto:sage [04/03/12 06:29] >>473 base64ってバイナリをそのままエンコード、デコードするものだと思うのだが。 文字コードと何の関係が?
476 名前:LightCone ◆sSJBc30S5w mailto:sage [04/03/12 22:52] www.nowsmartsoft.or.tv/nws/Japanese/jpcn1.htm
477 名前:LightCone ◆sSJBc30S5w mailto:sage [04/03/12 22:55] 投稿ミス(早走)りました。↑は、JIS第1水準+中国第一級。 ↓が、JIS第1第2+中国第一級、第二級 www.nowsmartsoft.or.tv/nws/Japanese/jpcn12.htm ついでに、Unicodeが、西洋の言語にヒイキ気味なことは、↓の最後の 方に書いてあります。異論あればどうぞ。 www.nowsmartsoft.or.tv/nws/Japanese/unciode.htm
478 名前:473 [04/03/13 12:34] >>475 確かにそうなんですけど。
479 名前:デフォルトの名無しさん mailto:sage [04/03/13 12:44] >>478 VBScriptの内部コードがUTF-8だからSJIS(EUC-JP)->UTF-8変換が入ってるんじゃないか? おそらく不要なコード変換部分をカットすれば良いだけだろう
480 名前:デフォルトの名無しさん [04/03/13 13:14] あ、しまったマルチになってしまいました。 えっと>>479 www.geocities.co.jp/SiliconValley/4334/unibon/asp/base64.html を使っているのですが、見た感じ、 SJIS→UTF-8ってのは無いかんじですが、どのあたりでしょうか。
481 名前:デフォルトの名無しさん mailto:sage [04/03/13 13:26] >>480 だからUTF-8とかSJISとかは実際のところ問題ではなくて バイト列->内部コード変換をカットしろという話なんだが…
482 名前:デフォルトの名無しさん mailto:sage [04/03/13 20:41] > 455 :LightCone ◆sSJBc30S5w :04/03/09 15:07 > 合成文字まで考えると、結局、UTF8でも、ASCIIしか考慮していない > strstr()では正しく検索できないね。 お前、 wcsstr/wcswcs って知ってる?
483 名前:LightCone ◆sSJBc30S5w mailto:sage [04/03/13 20:47] >>482 あなたは全く意味分かってないね。
484 名前:LightCone ◆sSJBc30S5w mailto:sage [04/03/13 20:50] >>482 要するに、そういうものを使えば、あらゆる文字コードに対応できるのは 当たり前なので言うまでもないことなんだよ。 だけど、UTF8は、strstr()でさえも、合成文字以外は正しい結果を出すように 工夫されていると言うこと。 人を馬鹿にする前に自分が勉強すること。
485 名前:デフォルトの名無しさん mailto:sage [04/03/14 00:08] string.h、ctype.h、regex.hなどの文字(列)に関係する関数全てが UTF-8を使えば国際化されるのであれば話は別だが、strstrとか一部の結果だけ 取り上げて既存の文字コードより優れてると主張するのは、木を見て森を見ない馬鹿か Markus Kuhnのような確信犯。まあ>>484 は前者だろう。
486 名前:デフォルトの名無しさん mailto:sage [04/03/14 01:05] OS 板に帰ってくれ。