【UTF8】文字コード変換【SJIS】

1 名前：デフォルトの名無しさん [03/09/10 16:04] 文字コード変換について語りましょう♪ 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] �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なのではなく（ｒｙ 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」のデコードを行いたいのですが、 ｇoogleでヒットするいろいろなサンプル関数をためしましたが、例えばこれでも 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 板に帰ってくれ。 487 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 01:09] >>485 >UTF-8を使えば国際化されるのであれば話は別だが、strstrとか一部の結果だけ >取り上げて既存の文字コードより優れてると主張するのは、木を見て森を見ない馬鹿か >Markus Kuhnのような確信犯。まあ>>484は前者だろう。 UTF8の場合、何も修正しなくても大丈夫なことが多いと言うことが言えるわけで、 それが理解できないなら、UTF8について理解できてない。 488 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 01:16] >>485 試しに、UTF8に変えたとき破綻する例上げてみなはれ。 例えば、人が解釈するなら、「文字数を出す」という関数を、 「バイト数を返す」に「意味の解釈」を修正しないと駄目だけど、 コンピュータ内部では、何も修正せずに矛盾無く辻褄が合う。 はっきり言えば、ある意味変な解釈のまま、関数同士がお互いに間違い続ける から矛盾が生じないという事になる。 489 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 01:17] 自分が理解できないのを他人のせいにするのが流行ってまんな。2chは 大体そんなものだけど（笑）。 490 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 01:32] というより、専門の「煽り屋」の仕業だな。多分。 なぜなら、こんな馬鹿で失礼な人、自分の周りではあったこと無いから。 よく考えたら、実際問題、こんな失礼な人間、町歩いて手もいないもんな(笑)。 491 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 01:33] やっぱり1chの西さんの言うように、専門の煽り屋が居るって言う噂は、 本当なんだね。 492 名前：デフォルトの名無しさん mailto:sage [04/03/14 03:00] 最近放置気味だったのが、相手にしてもらえてうれしいようだ。 493 名前：デフォルトの名無しさん mailto:sage [04/03/14 03:09] >>485 の言うとおり regex は随分変更を受けると思うが。 標準関数じゃないが、よく使われるので重大だ。 あと、１文字のバイト数が固定じゃなくなるので、 strchr は strstr で代用できるとしても、 strrchr は使えなくなってしまう。 他にも strpbrk や strtok も改変が必要。 isleadbyte も改変が必要で、 後続バイト数を返すようにする必要がある。 あとは、標準関数だけじゃなく、 独自のライブラリの関数も軒並みアウトだろうな。 まぁ、想定する文字コードが違うんだから、 １文字１文字処理していくタイプの処理が使いまわせないのは 当然っちゃー当然だけど、 Shift-JIS か EUC かって程度なら isleadbyte 使ってりゃ何とかなることを考えると UTF-8 は随分面倒だ。 UTF-8 だと日本語は３バイト以上だし、どうやっても誤魔化せないな。 494 名前：デフォルトの名無しさん mailto:sage [04/03/14 03:11] お願いします。これ以上構うと閣下の病状が極端に悪化してしまいますので このあたりで勘弁してあげてもらえませんでしょうか。。。 495 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 07:35] >>493 >strrchr は使えなくなってしまう。 ASCIIに対しては無修正で使えるので、これも人間側の解釈の問題で、 コンピュータ内部では全く問題が発生しません。 それに対して、これがもし、Shift_JISであったならばそうは行きません。 >regex は随分変更を受けると思うが。 どのように変更を受けるんでしょうか?(笑) 496 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 07:36] 多分、>>493も、UTF8の特性を理解してませんね。 試しに、regexの修正点を上げてみて下さい。 497 名前：デフォルトの名無しさん mailto:sage [04/03/14 08:34] >>496 文字単位でマッチングしないと使い物にならないからじゃないか? mblenなどをしっかり使っていればあまり問題は出ないはずなのだが 実際のアプリではロケールの初期化すらまともにされていなかったりする 498 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 08:45] >>497 >文字単位でマッチングしないと使い物にならないからじゃないか? 何故? regexの主たる目的は置換。 それに何故、文字数が必要? バイト位置で足りるはず。 せっかく、何もしなければ辻褄が合ってるのに、mblen()なんて使うと 破綻します。 499 名前：デフォルトの名無しさん mailto:sage [04/03/14 08:50] 単純に、こんな場所で偉ぶっていい気になってる「LightCone ◆sSJBc30S5w」が 可哀相に思えるのは私だけですか？ 500 名前：デフォルトの名無しさん mailto:sage [04/03/14 09:18] >>498 この界隈のｺﾃﾊﾝは相手が誤解していると思いこむ傾向が強いように見えるけど 実際は両方が誤解している場合が多そうだよ この件も問題にしている部分が違うだけ 501 名前：デフォルトの名無しさん [04/03/14 09:37] アホコテさらしage 502 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 09:43] >>500 それは、違いますな。 何故かというと、ワテと話していて全く誤解が生じない人種と あったことがあるからです。 すんなり話が通じて楽しかった。 はっきり言って、一般人と話すのは苦手です。バカの壁を感じるから。 503 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 09:47] ワテと話していてワテが間違っていると思う人は、 まず、99.99%位、あんたの間違いだと思って大丈夫。 それに大抵の優秀な人は、深読みするのでそうそう簡単に相手の間違いを 断定しない。 はっきり言って、間違ったことを行ったときでさえ、それなりに意味の 通じる解釈をする人が多い。 2chラーで批判ばかりしている人は全くの逆で、知能の低さがすぐに分 かる。 結局、辻褄の合う解釈法が重い浮かばなくて、理解できないんだよ（笑）。 アホ 504 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 09:49] はっきり言って、邪魔になるから、そういう人達には勉強などさせずに、 遊ばせてやったらいいんじゃないかと思ってる。 505 名前：デフォルトの名無しさん mailto:sage [04/03/14 09:52] >>503 相手の発言の意図を読む意志がないと指摘しているだけなんだが 無駄な発言をして悪かったよ 506 名前：デフォルトの名無しさん mailto:sage [04/03/14 09:55] >>502 > 何故かというと、ワテと話していて全く誤解が生じない人種と > あったことがあるからです。 M-x doctorかい？ 507 名前：デフォルトの名無しさん mailto:sage [04/03/14 10:00] >>503 ＞それに大抵の優秀な人は、深読みするのでそうそう簡単に相手の間違いを ＞断定しない。 ＞ ＞はっきり言って、間違ったことを行ったときでさえ、それなりに意味の ＞通じる解釈をする人が多い。 あんたはアホウだということだね。自認しているとは謙虚なやつだ（ｗ 508 名前：デフォルトの名無しさん mailto:sage [04/03/14 10:04] とりあえずUnicodeいらね＞自分コード作ったという所らしいけどさ、中共政府並みの強制力とか 影響力がない個人でやるのはきついだろうねぇ。 LightConeて人がどういう人か知らんのでOS板見て来たら自分でOS作ってる人なんだね。 それならそこでの実装に限定してそっちで話してればいいんじゃなかろうか？って思う訳だが。 ム板に来てやってんのはどういうあれなんだろう？ このスレは最初は単発質問スレっぽい雰囲気だったけども、ほとんど既存のOSの上で規格として 動いてるUnicodeとローカルエンコードの変換とかの話してたと思うんだが。 なんで、このスレなんだろう？ 自分コードを自分OSに実装したよの宣伝だとしたらちょっといただけないんだが。 自分で掲示板作ってそっちでやってるもんだとばっかり思ってたんだが、ここにきて煽りに対抗 するためだけに書き込みしてるみたいでちょっと痛いぞ。 ここでやってないでそっちでちゃんとした議論してた方がいいんじゃなかろうか？ 老婆心だけどね。 509 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 10:09] >>507 なんか、なんでも基準を曖昧にしたがるようだけど、取りあえず、 悪いけど、そういう人種の人たちには、ワテ自身が確信していることに 対して批判を受けたことは未だにないんだよ。 もう、答えが出てしまって、証明済みで、なんの迷いもない結論に 達しているのに、まだ反論してくる人が居るのは、ネットのみの経験 だから、違いが如実。 510 名前：デフォルトの名無しさん [04/03/14 10:13] 発作age! 511 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 10:14] はっきり言うとね、ワテだって、結構間違うことはあるんだよ。 でも、そういう場合、 「そんなことがあったんですかいな!?」 「まいった、見落としてた!!」 「また、アホなミスをしった!!」 と思うわけ。 結局、指摘が的を射てるわけなんですよ、そういう連中は。 512 名前：デフォルトの名無しさん mailto:sage [04/03/14 10:23] 宣伝なら業者みたいに黙々とコピペしまくればいいのに。 513 名前：デフォルトの名無しさん mailto:sage [04/03/14 10:48] すいません、コーンたんはこういう人なんです。 すごくやる気があります。それは確かです。 でも、いつも車輪をダウングレードして再発明する人なんです。 しかも、人の指摘や忠告を聞く気はサラサラなく、一方的に放送した挙句、 最後はいつも「おまえらアホだ、俺は正しいのに」で終わるのです。 514 名前：デフォルトの名無しさん mailto:sage [04/03/14 12:07] 正規表現の . がある。 これは任意の１文字にマッチングする。 ASCII の１文字は１バイト固定だが、 UTF-8 の１文字は１バイトとは限らない。 sed の書き方になるが、 s/a.a/aa/g の場合、UTF-8 の "aあa" を置換しようとしても、 ASCII の regex を使うと ''あ' は３バイトなため、マッチしない。 515 名前：デフォルトの名無しさん mailto:sage [04/03/14 12:14] 2chは、確かに引きこもりやら、学生やらが多い。（俺も学生です・・・。） 確かにろくに分かっていないことでも、分かっているように言っている人も多いだろう。 ただし問題は時々有り得ないほど知識を持った人が紛れ込んでいること。 引きこもりばっかだと思えば、イケメンやら美人やらが紛れ込んでいるという事実。 不特定多数が集う匿名掲示板である以上、言葉遣いには気をつけるべし。 「車輪の再発明」という言葉を多用して批判する人がいるが、 こいつ自分の言葉に酔っているんだなぁと思うことはある。 516 名前：デフォルトの名無しさん mailto:sage [04/03/14 12:15] で、ﾗｲﾄなんたら氏は そのあり得ないほど知識を持った人だと？ 517 名前：デフォルトの名無しさん [04/03/14 12:18] 声を大にしていいたい。 日本が戦争に負けたとき、マッカーサーにより 日本は日本語を廃止し、すべて英語になるべきだった。 あまりにくだらないロスがおおすぎる。 当時まさかコンピューターでこんなロスが発生するとは 考えてもいなかったろうが。 すべて英語だったら、モジコードうんぬんなんて こんなくだらない苦労しなくてすむのに。 518 名前：デフォルトの名無しさん mailto:sage [04/03/14 12:19] 暴言ｷﾀｰ 519 名前：らいとこうん mailto:sage [04/03/14 12:21] ワテはOSを作れるほど知識を持った優秀な人間です。 520 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 12:25] >>514 >正規表現の . がある。 >これは任意の１文字にマッチングする。 >ASCII の１文字は１バイト固定だが、 >UTF-8 の１文字は１バイトとは限らない。 なるほど、それは確かにそうです。 UTF-8でも無修正で完全対応とは行かない例の一つですね。 考えるまでもなく、「文字数」が意味を成している部分はことごとく 駄目になります。今の場合でも、1文字ではなく「任意の文字の列」 でいいなら、「a.*a」で行けると思います。つまり、1「文字」と いう「文字数を数える行為」に失敗しているのが原因なのですね。 521 名前：デフォルトの名無しさん mailto:sage [04/03/14 12:25] >517 お前は効率のために生きてるのか？ 文化には多様性が必要だと思わないのか？ まあ始皇帝も文字と秤を統一したがったけど、 アメリカみたいなインチが主流の国も世の中にはあるからな。 当分ラクにはならんよ。 522 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 12:36] >>514 ついでなので、「.」以外にもありますか? 523 名前：デフォルトの名無しさん mailto:sage [04/03/14 12:38] 文字数に関わるもの全て。 {n,m} とか。 524 名前：デフォルトの名無しさん mailto:sage [04/03/14 12:41] あと文字種の考え方自体もunicodeとそれ以外じゃ違う。 perlunicodeとか見たらそれなりの準備されてるのがわかるはずだ。 525 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 12:45] >>523 a{2,5} とか、 (あ){2,5} とかなら問題ないのでは? 526 名前：デフォルトの名無しさん mailto:sage [04/03/14 12:46] >525 なんすかその不自然な括弧は？ 527 名前：デフォルトの名無しさん mailto:sage [04/03/14 12:47] あまり適当なことを言うと > 484 名前：LightCone ◆sSJBc30S5w 投稿日：04/03/14 01:41 > 2chって、詳しい人が多いのかと思ってたけど、かなり勘違いみたいですね。 > > そういう勘違いが起きてしまう理由は、いくつかの可能性がありますね。 > > 一つには、来る人が多いから、全然詳しくなくて断片的な知識を持ったいさま > ざまな人が来るため、一見もの凄く詳しい人が居るように見えるだけで、実際は、 > 断片知識の烏合の衆の集まりに過ぎない可能性。 こんな事言われちゃうよｗ 528 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 12:48] >>526 そりゃしゃあない。 529 名前：デフォルトの名無しさん mailto:sage [04/03/14 12:49] そのカッコをつければできるとしても、 そのカッコはつけたくないなぁ。 530 名前：デフォルトの名無しさん mailto:sage [04/03/14 12:53] 相手にしすぎると > 515 ：デフォルトの名無しさん ：04/03/14 12:14 > 2chは、確かに引きこもりやら、学生やらが多い。（俺も学生です・・・。） > 確かにろくに分かっていないことでも、分かっているように言っている人も多いだろう。 > ただし問題は時々有り得ないほど知識を持った人が紛れ込んでいること。 > 引きこもりばっかだと思えば、イケメンやら美人やらが紛れ込んでいるという事実。 > > 不特定多数が集う匿名掲示板である以上、言葉遣いには気をつけるべし。 > > 「車輪の再発明」という言葉を多用して批判する人がいるが、 > こいつ自分の言葉に酔っているんだなぁと思うことはある。 こんな事言われちゃうよｗ 531 名前：デフォルトの名無しさん mailto:sage [04/03/14 12:55] そして雪崩れ込むように > 517 名前：デフォルトの名無しさん 投稿日：04/03/14 12:18 > 声を大にしていいたい。 > 日本が戦争に負けたとき、マッカーサーにより > 日本は日本語を廃止し、すべて英語になるべきだった。 > あまりにくだらないロスがおおすぎる。 > > 当時まさかコンピューターでこんなロスが発生するとは > 考えてもいなかったろうが。 > すべて英語だったら、モジコードうんぬんなんて > こんなくだらない苦労しなくてすむのに。 こんな事言われちゃうよｗ 532 名前：デフォルトの名無しさん mailto:sage [04/03/14 12:56] >>529 つけたくないなぁと言われても。 533 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:01] 論旨は「バイト単位の正規表現モジュールでutf8も問題なく扱える」だったと思うが、 . や [] のことも考えてない「全然詳しくなくて断片的な知識を持った」人だったと。 まあ間違えたのは仕方ない。しかし間違った後にうだうだいってるのは無様だし、 間違いを書く前に自分で検証する姿勢が足りてないのが暴言の数々から読み取れる。 頭冷やしてきなよ。 534 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:01] >>525 つまり世界中のregular expressionを使ったプログラムを修正して回れってこと？ 普通の人は、regular expressionのライブラリのほうを修正すると思うが。 535 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:04] LightCone様の足下にも及ばない厨房のくせにいきがってんじゃねーよ。 536 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:06] >>535 何故そこでよく分からない横槍が入るｗ 537 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:06] いや正規表現側で工夫してきたのが今までの日本のperl文化だからなぁ。 どこにでもあるからって理由でperl使ってた人はそこに適応するようにスクリプト側で工夫してたわけ。 それも普通じゃないってこと？ まあLightCornが破綻してるのは既に明らかだが。 538 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:06] >>534 普通の人はOSなんか作らないよ！ とフォローにもならない暴言を吐いてみる 539 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:09] 話は変わるけど俺はucs2よりもutf8の方が寿命が長そうだから好きだ。 何度も書き直したくないじゃん？なら可変長のエンコーディングで通した方が将来性がある。 \0があまり登場しないから既存OSとの親和性も悪くないし。 540 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:10] 既にucs2対応のOSでしか動かないとか、 システムコールの度にエンコード変換するとか、 そういうのはイヤですわ。 541 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:15] Ruby は正規表現に日本語が使えるよ！ やっぱ使えたほうが便利だよ。 542 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:17] 文字コード総合スレあっても良かったんかなぁ。 このスレの主旨って元々はピンポイントに「変換」だし。 543 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:19] ひまわりなら日本語だけで書けるよ！ 544 名前：LightCone ◆sSJBc30S5w mailto:sage [04/03/14 13:22] 正規表現ルーチンは、UTF8を使っても要修正でした。 すんません、訂正します。 これで気が済むんでっか? 545 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:23] 自分が独りワイワイと騒いどいて何いじけてんの？子供だね。 546 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:26] >>544 こっちはコーンたんが何言おうともはや気にしてないけど。 547 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:29] という訳で終ー了ー。 548 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:29] 見てて不憫になってきた。 549 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:32] 文字が UTF-8 が表現されるとすると、 strrchr("あいあい", 'あ'); とかいう１文字逆検索ができない。 'あ' は３バイトだし、UTF-8 は最長６バイトだから、 こういう表記自体に問題があるかもな。 文字列の逆検索があれば代用できるんだけど...。 あと、strpbrk, strtok, strspn, strcspn の第二引数も改変が必要。 こういう１文字＝１バイトを仮定されると困る処理は軒並みアウトだ。 550 名前：デフォルトの名無しさん mailto:sage [04/03/14 13:51] ungetc()とかきっと1バイトしか戻せないよ……。 551 名前：デフォルトの名無しさん mailto:sage [04/03/14 14:25] 英語圏のプログラムで、設定ファイルを読んだりログを書いたりする程度ならまあ改造なしでも通るけどさ。その程度だよな。 552 名前：デフォルトの名無しさん mailto:sage [04/03/14 14:28] 結局書き直しまくりだねぇ 553 名前：デフォルトの名無しさん mailto:sage [04/03/14 16:14] regexはcharacter classとcollation orderも扱うのだが、 何故UTF-8など修正無しでOKだと思ったんだろう。 554 名前：デフォルトの名無しさん mailto:sage [04/03/14 16:32] Perlなんかでも正規表現は漢字1文字が2バイトになるって分かって書いてきたからね。 そういう感覚を前提にしたら、検索で誤マッチしないだけで充分ってことでは。 555 名前：デフォルトの名無しさん mailto:sage [04/03/14 17:06] collationなんてやりだしたら修正どころじゃないな 556 名前：デフォルトの名無しさん mailto:sage [04/03/14 17:28] glibcのregex国際化 lc.linux.or.jp/lc2001/papers/dfa-i18n-paper.pdf lc.linux.or.jp/lc2002/papers/hasegawa0918h.pdf 557 名前：デフォルトの名無しさん mailto:sage [04/03/14 20:07] >上述の通り、我々の実装はDFA をベースとしている。 >このため、NFA ベースの実装では避けられないback tracking の問題 >が生じない。 NFAベースでもバックトラック無しの実装をアップしとるのに。 複数の状態変数のパラレルな遷移という例で。 >しかし、Single UnixSpecification[3] などの規格において、 >あるコードポイントに文字が割り当てられているかどう >かをエンコーディングから独立に調べる方法が用意されていない。 着眼点が悪い。 実は既に正規表現式から必要最小限な集合を抽出する方式がある。 つまり、入力値の範囲ではなく、パターン自体にその答えがある。 オーバーヘッド無し、むしろ従来より高性能な実装は可能。 と、ここで書いてみる。 どうせダウンロードとしてないんだろうな。 従来と違うアプローチの実装例をいくつも出したのに。 558 名前：デフォルトの名無しさん mailto:sage [04/03/15 00:10] >>554 いつの時代のperlの話だよ。.を1byteと見做すなんて。 PCRE is short for Perl Compatible Regular Expressions. www.regular-expressions.info/pcre.html 559 名前：デフォルトの名無しさん mailto:sage [04/03/15 00:15] それから、printf系がUTF-8で問題ないって言う人いるけど、 %c, %lcが全く駄目じゃん。範囲限定で使えないことはないレベル。 560 名前：デフォルトの名無しさん mailto:sage [04/03/15 00:34] 複数回 %c すればー、ということじゃない？ 改変するとすれば、アドレス渡すようにしないといかんのかな。 そもそも文字リテラルの仕様をどうすればいいんだろうか？ 561 名前：デフォルトの名無しさん mailto:sage [04/03/15 01:04] >>558 現状ではこの手のツールの漢字対応って大抵無理やり動かすパッチだけど。 ggrepの日本語対応パッチで比較回数が爆発したりとかするやつあったし。 562 名前：デフォルトの名無しさん mailto:sage [04/03/15 01:10] 漢字対応って一体何の話? ここはUnicodeのスレですよ? >>553の言っていること理解できる? 563 名前：デフォルトの名無しさん mailto:sage [04/03/15 01:12] ああ、すまん、マルチバイト対応だ。打ち間違い。 564 名前：デフォルトの名無しさん mailto:sage [04/03/15 09:43] >>558 一般人にもっとも馴染みの深いプロバイダのおまけCGI環境だと今でも普通だが。 565 名前：デフォルトの名無しさん mailto:sage [04/03/15 09:49] >>559 さすがにそれは言いがかりだろ。 マルチバイトでcharに入らない時点でどう転んでも無理。 wchar_tでwprintf使ってなさいってこった。 566 名前：デフォルトの名無しさん mailto:sage [04/03/15 09:50] >>564 まさかそれが正しいことだと思ってるんじゃなかろうな・・・ 567 名前：デフォルトの名無しさん mailto:sage [04/03/15 09:51] >>565 いや、だから>>559は「どう転んでも無理」という話をしているのだが・・・ 568 名前：デフォルトの名無しさん mailto:sage [04/03/15 09:55] >>564 その環境100%信頼してバッチジョブで 漢字ファイル名の自動リネームに使うとあぼーん。 Rubyも1.8になるまで不具合連発だったし、今でも警戒してる。 569 名前：デフォルトの名無しさん mailto:sage [04/03/15 10:00] そこはバッドノウハウで回避ですよ。 570 名前：デフォルトの名無しさん mailto:sage [04/03/15 10:06] バッドノウハウ？ ちゃんと再設計すりゃいいじゃんか、アルゴリズムを変えて。 マルチバイトの対応は10年たっても20年たっても不完全。 571 名前：デフォルトの名無しさん mailto:sage [04/03/15 10:12] >>570 おつむの弱い人ですか? アルゴリズムて 誰がregexライブラリ設計の話してるの… 572 名前：デフォルトの名無しさん mailto:sage [04/03/15 11:16] >>571 551から554,556,558の流れなんだけど。 573 名前：デフォルトの名無しさん [04/03/15 14:51] 571はLightCone 574 名前：デフォルトの名無しさん mailto:sage [04/03/15 21:00] 彼は名無しで煽らないよ。 575 名前：デフォルトの名無しさん mailto:sage [04/03/15 22:12] いやぁ、ときたま名無しのLightConeがまぎれているような気がするんだが。 なぁ、>>574 576 名前：デフォルトの名無しさん mailto:sage [04/03/16 01:28] >>562 誰も突っ込んでないようだが、 このスレは別に Unicode のスレじゃない。 577 名前：デフォルトの名無しさん mailto:sage [04/03/16 02:12] 文字コード総合スレあった方が良かったかな？ 僅かな需要はあるのかも。 578 名前：Shift_JIS mailto:sage [04/03/16 02:24] 私の頃忘れないで… 古い欠点ばかりの女とお思いでしょう。けどわたし…(ﾓｼﾞﾓｼﾞ 579 名前：デフォルトの名無しさん [04/03/16 07:59] UTF8とSJISのスレだと勘違いされてもしかたないタイトルだな。 580 名前：デフォルトの名無しさん mailto:sage [04/03/16 15:43] java厨ならその2つだけでなんとかなるからな 581 名前：デフォルトの名無しさん mailto:sage [04/03/16 23:12] なるかボケ 582 名前：デフォルトの名無しさん [04/03/16 23:52] 質問です。 VBscriptでUTF8からSJISに変換という 関数や方法はあるのでしょうか。 583 名前：デフォルトの名無しさん mailto:sage [04/03/17 01:00] >582 ふつーに変換DLLをインポートできねーの？サーバサイドだよね？ 584 名前：デフォルトの名無しさん [04/03/18 00:11] できれば、VBscript内で行いたいです。 そのＶＢscriptファイルををダブルクリックすると 指定したUTF8のファイルを読み込み、SJISに変換したものを 別ファイルとして吐き出す っていうのを作りたいのです。 585 名前：デフォルトの名無しさん mailto:sage [04/03/18 00:42] んー、UTF8からUCS2への変換はふつーに書けるよね。 UCS32からCP932への変換はAPI呼ぶとか自前でテーブル持つとかでできるね 586 名前：デフォルトの名無しさん [04/03/18 00:50] >>585 basp21 の「kconv」を使ってはみたのですが、どうもうまくいきません。 使い方間違っているのでしょうか・・ 587 名前：デフォルトの名無しさん mailto:sage [04/03/18 03:00] UTF8 ─自前ルーチン→ UCS2 ─WideCharToMultiByte→ SJIS UTF8 → UCS2 www.linux.or.jp/JM/html/LDP_man-pages/man7/utf-8.7.html 588 名前：デフォルトの名無しさん [04/03/18 23:20] やはりこれってのはスレがたつほどなんで 文字コード知識ある人でも難しい問題なんですか？ basp21でできそうだったんですが・・・できないものですね。 589 名前：デフォルトの名無しさん mailto:sage [04/03/18 23:40] ﾜﾗﾀ 590 名前：デフォルトの名無しさん mailto:sage [04/03/18 23:40] 普通の人でもある程度書けるけど正確さを目指すと規格の曖昧さで苦労する問題です。 588はもーちょっと修行すれ。もしくはちゃんとコードとエラー内容を出して質問すれ。 591 名前：デフォルトの名無しさん mailto:sage [04/03/19 11:21] >>587 WideCharToMultiByte使うなら、Win95での動作を想定しなくてよければ MultiByteToWideCharでUTF-8＞UCS-2変換すればいいと思うが。 592 名前：デフォルトの名無しさん mailto:sage [04/03/19 12:36] MSLU入れてもその辺アップデートされないの？ 593 名前：デフォルトの名無しさん mailto:sage [04/03/19 13:13] >>592 unicow.dll(だっけ?)をリンクしているアプリからしか使えない。 VBScriptからという条件じゃ無理 594 名前：デフォルトの名無しさん [04/03/19 22:04] すみません、全くの初心者なのですが、perl 5.8.2での質問です。 test.txtという、shift-jisで保存されたテキストファイルがあります。 （ファイル名も、置かれているディレクトリも常に同じ。） このファイルを、utf-8に変換したいのですが、やり方がわかりません。 いろんなサイトを参考にして、何種類かやり方があるようなことがわかり、 試しに、 use utf8; $input_filename ='C:\hoge\test.txt'; $output_filename ='C:\hoge\test.txt'; open my $in,'<:encoding(shift_jis)',$input_filename or die "open $input_filename: $!\n"; open my $out,'>:encoding(utf8)',$output_filename or die "open $output_filename: $!\n"; while(<$in>){print $out $_; } close($in) or die "read $input_filename: $!\n"; close($out) or die "write $output_filename: $!\n"; という風に書いてみましたが、結果はtest.txtの中が空になるだけでした。 また、別のやり方として、 use utf8; $input_filename ='C:\hoge\test.txt'; $output_filename ='C:\hoge\test.txt'; use Encode qw(from_to); open my $in, "<", $input_filename or die; open my $out, ">", $output_filename or die; while(<$in>){ from_to($_, "shift_jis", "utf8"); print $out $_; } という風なやり方も試してみましたが、結果は同じでした。 どこがいけないのでしょうか？ どなたか詳しい方、よろしくお願いします。 595 名前：デフォルトの名無しさん mailto:sage [04/03/19 22:53] perlは門外漢なんだが、入力と出力が同じファイル名でいいの？ ファイルが空になるような。 596 名前：デフォルトの名無しさん mailto:sage [04/03/19 23:01] windowsだと確実にダメなはず。出力を開いた時点でファイルサイズが０になる。 597 名前：デフォルトの名無しさん [04/03/20 01:24] 結局のところ UTF8→ShiftSJIS 直変換は無理ってこと？ 598 名前：デフォルトの名無しさん [04/03/20 01:25] BASP使っては無理？ 599 名前：デフォルトの名無しさん mailto:sage [04/03/20 02:24] 結局変換コード自前で書いたとしても、 UTF8 から UCS2 のコードを求めて それを SJIS に変換するってコードを書くことになるしな。 まぁ、１文字１文字変換した方が 余計なバッファが要らない分効率はいいかとは思うけど、 変換に MultiByteToWideChar/WideCharToMultiByte を使うと 呼び出しコストが高そうなので、全部自前で組まないと意味が無いかも。 ただ、使用言語が VBScript なので、ひょっとしたらひょっとするかも？ 600 名前：デフォルトの名無しさん mailto:sage [04/03/20 06:22] ShiftSJIS 。 ムリでもなんでもねーよ。てめーがヘタなだけだ 601 名前：594 [04/03/20 08:57] 594です。 無理なのでしょうか？できるのでしょうか？ perlのスレとかに行ったほうがわかるのでしょうか？ 602 名前：デフォルトの名無しさん mailto:sage [04/03/20 09:59] >601 inとoutで開くファイル名変えれ。それだけだ。 603 名前：デフォルトの名無しさん [04/03/20 13:08] 簡単に変換する方法ないですか？ 604 名前：デフォルトの名無しさん mailto:sage [04/03/20 13:34] つかお前誰だ 605 名前：デフォルトの名無しさん [04/03/20 22:01] www.vector.co.jp/soft/win95/util/se314832.html これを元に、なんとかできないかな 606 名前：デフォルトの名無しさん mailto:sage [04/03/20 22:21] パイナリファイル 607 名前：デフォルトの名無しさん mailto:sage [04/03/24 00:06] JISの半角カナなんだけどさ ESCJ と shift-out と 7bit が続く場合と ESC I の後に 7bitが続く場合は ASCII扱いでOK? 7bitの場合で他（というとESC I +shift-out+7bitのことだが）はX201扱いでOK? 608 名前：デフォルトの名無しさん mailto:sage [04/03/24 00:50] やや意味不明。ESC J って、ESC ( J のことか？ そうだとして、SO の後は G1 に何が入っているかによる。 日本ではX0202の右側を入れることが多いかな。 ESC ( I の後は X0201右側が G0 に designate されているから、 7bitならX0201右側しかない。 「7bitの場合で他」って、なんで一通りに決まる？ ESC ( I SO の後は、最初の場合と同じで G1 に何が入っているかによる。 609 名前：デフォルトの名無しさん mailto:sage [04/03/24 00:52] ↑のX0202はX0201のことな 610 名前：デフォルトの名無しさん mailto:sage [04/03/24 01:02] JIS の半角カナって、M$ の仕様拡張じゃなかった？ 611 名前：デフォルトの名無しさん mailto:sage [04/03/24 01:13] おまえはこのスレにいる資格なし 612 名前：デフォルトの名無しさん mailto:sage [04/03/24 09:27] いまどきこんなDQNエンコード使ってるほうが悪いんだよ 613 名前：デフォルトの名無しさん mailto:sage [04/03/24 09:50] >>608 X0201右側って何? 片仮名用図形文字集合のこと? 614 名前：デフォルトの名無しさん mailto:sage [04/03/24 10:06] > ESC ( I の後は X0201右側が G0 に designate されているから、 > 7bitならX0201右側しかない。 これ以前にG1〜G3がGLに呼び出されていれば そこに何が入っているかによる。 ESC 2/8 FでG0に何が指示されようと関係ない。 (一意な符号化が要求されている場合は使用可能な文字が 変わるかもしれないけど) 615 名前：デフォルトの名無しさん mailto:sage [04/03/24 10:18] >>614 > これ以前にG1〜G3がGLに呼び出されていれば > そこに何が入っているかによる。 そうだった。SOとかLS2/LS3が先行してる場合があるか。 >>613 そのつもり。 616 名前：デフォルトの名無しさん mailto:sage [04/03/24 10:26] >>615 7bitで「右側」という表現に違和感を感じたので。 確かにX0201に規定されている8ビット符号は片仮名をGRに 呼び出すものしかないけど 617 名前：デフォルトの名無しさん mailto:sage [04/03/24 22:29] >612 悪いな。IRC関連なんだよ 618 名前：デフォルトの名無しさん mailto:sage [04/03/29 10:48] IRCの日本語文字コードってISO-2022-JPじゃなかったっけ? 619 名前：デフォルトの名無しさん [04/03/30 01:46] age 620 名前：デフォルトの名無しさん [04/05/05 19:26] BOMありUTF-8などというばかげたものが禁止されていないのはなぜですか？ 621 名前：デフォルトの名無しさん [04/05/05 20:13] >>620 UTF-8を自動識別できるから(ｗ ASCII/ANSI互換がメリットなのだから、BOMは付けるべきではないというのが 一般論。でも付けて違反とはISO 10646にもRFCにも規定はないですね Use caseによるんじゃないですか？ XMLやHTMLなら、encodingパラメータでコードセットを取得できるので不要、 でもそうでないものやencoding指定が無い場合は識別方法が7fhコードが 含まれているかとかあやふやな、確実に特定する手段無いし・・・ それはS-JIS、GB 2312、Big5、KS C5601(KS X1001)、CNS 11643等でも 同様ですが 622 名前：デフォルトの名無しさん mailto:sage [04/05/05 20:14] >>620 Byte Order Mark の何たるかをご存知でない お間抜けちゃんがこの業界を仕切っているからでぬるぽ。 623 名前：デフォルトの名無しさん mailto:sage [04/05/05 22:54] いきなりレベルの低い話になりますが、〜問題は皆どうやって 回避してますか？ 624 名前：デフォルトの名無しさん mailto:sage [04/05/06 07:38] ~→〜のこと? 625 名前：デフォルトの名無しさん mailto:sage [04/05/06 07:59] WAVE DASH(〜)が\u301cにマッピングされる問題でしょ。 626 名前：625 mailto:sage [04/05/06 08:02] 失礼、「U+301C」の方が良いですね。 627 名前：デフォルトの名無しさん mailto:sage [04/05/06 10:13] iconvもglibcも使うときはSJISじゃなくてCP932を指定してる。 emacsもCP932変換テーブルを作って、さらにutf-8 decode部分を書き換え。 実際どうなんだろう、SJISが必要な人って、どれぐらいいるんだろう？ 大部分の人はCP932が欲しいわけで、SJISじゃないと思うのだけど、 そうでもない？ 628 名前：デフォルトの名無しさん mailto:sage [04/05/06 11:28] >>621 > でも付けて違反とはISO 10646にもRFCにも規定はないですね どういう場合に付けてはいけないか(というか付いてたときZWNBSP ではなくBOMであると解釈してはいけないか)はRFC 3629で 明確化された 629 名前：デフォルトの名無しさん mailto:sage [04/05/06 13:54] >>627 Unicode→SJISで、「どっちが来てもいいように」対応することは可能だけど SJIS→Unicodeだと、どっちにするか決めないといけない という問題がありますね。 それと、OracleのNLSのような、ハック不可能な領域だとかなりどうしようも ない気が。 そういえば、JavaはもうShift_JISがWINDOWS-31JじゃなくてSJISのエイリアス になってるんでしたっけ。これ、困る人が多いんじゃないのかなあ。 630 名前：デフォルトの名無しさん mailto:sage [04/05/06 16:46] > Unicode→SJISで、「どっちが来てもいいように」対応することは可能だけど U+005CとかU+007Eが来たときどう変換する? Shift_JISがX0208の附属書1どおりじゃなくて 1バイト部分はASCIIであるとみなせば対応は可能だけど 631 名前：デフォルトの名無しさん mailto:sage [04/05/06 20:09] >>630 実際問題として、ASCIIと見なさないと、使い物にならないでしょう。 \にどういうグリフが当てられていようと、日本人もそれをエスケープ記号や パスのデリミタとして(バックスラッシュと同じ意味で)使っているんだから、 他のコードポイント割り当てたら、はっきり言って実用上はお話にならない。 従来通りFontの問題として対応するのが「今のところは」現実的じゃないの。 632 名前：デフォルトの名無しさん mailto:sage [04/05/06 23:53] エスケープ記号はともかくパスのデリミタはWindowsの場合だから それは単にエンコーディングとしてCP932を想定しているというだけの 話だと思うんだけど。 実際Appleの変換表は円記号をU+00A5に割り当てるし 633 名前：デフォルトの名無しさん mailto:sage [04/05/07 00:26] そのエスケープ記号が大問題だと思うが。 世の多くのプログラミング言語だのTeXだのシェルだのにおいて メタキャラクタとして使われてるんだから。既存のソースの類が突然にして コンパイル不能な屑の山になるでしょ。 無論DOS, Windowsユーザにとっちゃパス区切りであることの方が さらに問題だが。 634 名前：デフォルトの名無しさん mailto:sage [04/05/07 03:27] >>631 そりゃ、プログラマ至上主義だね。 普通の文書に半角円記号使ってた人は困る。 635 名前：デフォルトの名無しさん mailto:sage [04/05/07 08:16] >>634 そしてTerminal上でバックスラッシュと円記号の混乱でうめき、SafariでWebの円記号がバックスラ ッシュになってもがくOSXユーザが湧いてでてくると。 636 名前：デフォルトの名無しさん mailto:sage [04/05/07 09:14] >>632 Mac OS Xだと、Shift JISのprogramを、 UTF-8で保存して、REVERSE SOLIDUS(0x5c)のつもりが、 YEN SIGN(0xa5)になって悩んでいる学生さんが、 既にいらっしゃいますよ。 Terminal.appで、YEN SIGNが出力されていても、(\nとか) 教科書にYEN SIGN書いてあんだもん、初級の人はわけが分からないよね。 637 名前：デフォルトの名無しさん mailto:sage [04/05/07 09:48] Safariの ~ が 〜 になっちゃうよ問題とか。 638 名前：デフォルトの名無しさん mailto:sage [04/05/07 09:53] 「どっちが来てもいいように」対応するというのも そんな簡単じゃない。 たとえばPARALLEL TOとDOUBLE VERTICAL LINEしか違わない 名前のファイルが同じディレクトリにあると、どちらか片方しか 開けないとかどっちが開かれるかわからないとか、 どっちが作成されるか分からないとか。 そもそも両者を同一視したいというのは日本だけの都合であって、 たとえばGBKには両方とも存在するから勝手に同一視されたら 多分困る。 639 名前：デフォルトの名無しさん mailto:sage [04/05/07 12:57] <item1 name="セーター" price="\500" image="c:\image\item1.jpg"> みたいなのをきちんと utf-8 にする処理は多言語対応では難しいよね・・・ 640 名前：デフォルトの名無しさん mailto:sage [04/05/07 13:15] >>639 > <item1 name="セーター" price="\500" image="c:\image\item1.jpg"> と記述するcoding systemがyenとbackslashを区別できていれば問題ないし、 区別できていないのなら、それはコード変換とは別ドメインの問題だろ。 641 名前：デフォルトの名無しさん mailto:sage [04/05/07 13:24] 見た感じXMLっぽいがそれなら price="&yen;500" と書くことで曖昧さがなくなる 642 名前：デフォルトの名無しさん mailto:sage [04/05/07 13:33] >>640 Shift_JISは問題ないの? 643 名前：デフォルトの名無しさん mailto:sage [04/05/07 16:13] >>641 xml 的には後半の \ は ¥ にするや否や、というような話。スレ違いだけど。 >>640 元のコードが Shift_JIS の場合、どんな風に変換されるべき？ 644 名前：デフォルトの名無しさん mailto:sage [04/05/07 16:56] >>643 後半はしたら駄目に決まってる 645 名前：デフォルトの名無しさん mailto:sage [04/05/08 04:06] ところがShift JISで書いた場合は、両方でOKなわけだ。 646 名前：デフォルトの名無しさん mailto:sage [04/05/08 04:07] 両方HALFWIDTH YEN SIGNでOKなわけだ。 647 名前：デフォルトの名無しさん mailto:sage [04/05/08 09:10] >>645 意味がわからん 「両方」って何と何のことで何が「OK」なの? >>646 HALFWIDTH YEN SIGNなんてものはない ただのYEN SIGNならある 648 名前：デフォルトの名無しさん [04/05/09 05:04] LightConeは? 649 名前：デフォルトの名無しさん mailto:sage [04/05/09 20:00] >>648 LightCone乙 650 名前：デフォルトの名無しさん [04/05/18 10:46] 書き込みがないな。 またLightConeが来てくれないかな。 651 名前：デフォルトの名無しさん [04/05/18 18:31] iso-8859-22って、いわゆるなに？ iso-8859-1って、いわゆるLatin1でいいの？ 652 名前：デフォルトの名無しさん mailto:sage [04/05/19 02:37] 8859-22 なんてあったのか？ 16までなら聞いたことがあるが。 653 名前：デフォルトの名無しさん [04/05/20 19:14] EZ端末からPOST形式でフォームをサブミットすると x-up-destcharset=17 というのが勝手に送られるのですが、 これって何のためのものでしょうか？ 654 名前：デフォルトの名無しさん mailto:sage [04/05/20 19:20] で、それがなんの関係があると？ 655 名前：デフォルトの名無しさん [04/05/20 19:23] >>654 誤爆? 656 名前：デフォルトの名無しさん mailto:sage [04/05/20 19:24] >>655 残念。ちゃんとした回答。 657 名前：デフォルトの名無しさん [04/05/20 19:48] >>656 >>653への回答か? スレ違いだと言いたいのか? 658 名前：デフォルトの名無しさん mailto:sage [04/05/21 18:41] >>220 さんのページってどこですか？ 659 名前：デフォルトの名無しさん mailto:sage [04/05/21 18:58] EUC補助漢字の判定 でぐぐってみたらわかりました。 使える文字コード判定ってあんまり情報ないので助かります 660 名前：デフォルトの名無しさん mailto:sage [04/05/22 01:41] >>399 UCS4で正規化すりゃ万事解決。 32ビットコードはMuleとかで先例もあるし。 661 名前：デフォルトの名無しさん mailto:sage [04/05/22 02:12] wcschrでヒットしたその位置は何文字目? という問いに 簡単に答えられない点が問題。X0208の範囲に限定するなら そうでもないがそれならそもそも4バイトもいらん 正規化がUnicode Normalizationのことを指してるなら UTF-8の文字数を先頭から数えても大して変わらんような… 662 名前：デフォルトの名無しさん [04/05/22 09:25] >>660 遅レス乙! 663 名前：デフォルトの名無しさん mailto:sage [04/05/22 21:37] >>660 コードポイントと文字は１対１対応ではない。 NFCで正規化しても複数コードポイントの組合せで １文字を表すケースはいくらでもある。 664 名前：デフォルトの名無しさん mailto:sage [04/05/22 22:37] たしかに↓とか読んでると気が遠くなってくるな。 www.horagai.com/www/moji/devnag.htm アラビア語や上の例みたいに文字を分かち書きしない言語では 「一文字」っていう単位がそもそもそれほど明確じゃないのかも。 日本語は「単語」を分かち書きしないけど 時枝文法とか文法のとらえ方次第で「単語」も変わるしそもそも 日本人は単語の区切りなんてふだん意識してないみたいな感じか。 （助詞とか） 素人なので間抜けな事いってるかも知れないが。 665 名前：デフォルトの名無しさん mailto:sage [04/05/22 23:31] >>663 というかそれはまさに>>399で言ってることそのものなわけで 文盲にマジレスしても無駄かと 666 名前：デフォルトの名無しさん mailto:sage [04/05/24 02:59] ｐｃ関係詳しい方！ ぜひこの暗号解けないものでしょうか！？ 325argf493rdtr521styh075artg625agfa113ller041fsre.2122ffj7343qer7813fda 667 名前：デフォルトの名無しさん mailto:sage [04/05/24 08:55] それをこのスレにもってくる神経を疑う 668 名前：デフォルトの名無しさん mailto:sage [04/05/24 09:33] >>667 その謎を解くのだ。 669 名前：デフォルトの名無しさん mailto:sage [04/05/24 10:45] >>666 ↓↓US-ASCII復号による解読結果です↓↓ 325argf493rdtr521styh075artg625agfa113ller041fsre.2122ffj7343qer7813fda 670 名前：デフォルトの名無しさん mailto:sage [04/06/04 22:06] 325|argf 493|rdtr 521|styh 075|artg 625|agfa 113|ller 041|fsre . 2122|ffj 7343|qer 7813|fda 671 名前：デフォルトの名無しさん mailto:sage [04/06/07 11:25] BASE64? 672 名前：デフォルトの名無しさん mailto:sage [04/06/09 06:26] 英大文字をまったく含まないというのは BASE64にしては不自然すぎるな 673 名前：デフォルトの名無しさん mailto:sage [04/07/06 12:32] JISを元にした文字コードとunicodeとの変換表が複数ある状況は なんとかならんのかね。それが正しかろうがなんだろうがとにかく 統一されてさえいれば楽に使えるのに、バラバラだからいらぬ変換 の手間がかかってわけわからん状況に。勘弁してくれよう。 674 名前：デフォルトの名無しさん mailto:sage [04/07/06 13:31] なんともならんでしょうね。 675 名前：デフォルトの名無しさん mailto:sage [04/07/08 04:21] JISは対応が存在するだけまだマシなほうですよ Big5やKPS9566なんてそもそも変換できない場合があるし 676 名前：デフォルトの名無しさん mailto:sage [04/07/08 11:52] まあ、応用によって変換表が違うのは当然って文字の組み合わせもあるでしょう。 *→＊,×, ※など。あまりいい例じゃないからもっといいのきぼん↓ 677 名前：デフォルトの名無しさん mailto:sage [04/07/08 16:43] printf("値段は \\%dです\n", Nedan); \\は&yen;(¥)1文字に変換されるのが理想だし、\nはバックスラッシュとnに変換してくれないと困るし。 678 名前：デフォルトの名無しさん mailto:sage [04/07/08 16:49] もう、面倒だから\記号使うのやめよう。 printf("値段は %d円です\n", Nedan); で良いじゃないか。 ごたごたに巻き込まれたくないPGより。 679 名前：デフォルトの名無しさん mailto:sage [04/07/08 21:18] ￥ でいいよ 680 名前：デフォルトの名無しさん [04/07/28 08:02] age 681 名前：デフォルトの名無しさん mailto:sage [04/07/28 08:33] >>679 I/Oライブラリに勝手に\に変換されたり… 最近2chでも~→〜があるみたいだし。 682 名前：デフォルトの名無しさん mailto:sage [04/07/28 09:10] 文字のことは中国人に任せときゃいいんだよ 漢字のほんの一部を借りて使ってるだけの日本人なんかに何が出来るんだ 683 名前：デフォルトの名無しさん mailto:sage [04/07/28 13:46] >>682 マッカーサーに従って、日本語で文章を書くのを止める、とか？ 684 名前：デフォルトの名無しさん mailto:sage [04/07/28 22:02] >>682 アルファベットも中国人任せか? 685 名前：デフォルトの名無しさん mailto:sage [04/07/28 22:38] >>681 ~→〜はSafariの悪戯だろ 686 名前：デフォルトの名無しさん mailto:sage [04/10/02 21:36:08] SJIS、EUC、JIS、UTF-8を判別するアルゴリズムを紹介しているページってどっかある？ ttp://kasumi.sakura.ne.jp/~gm/gpj/dev/tips/other/kanji.shtml を参考にしているんだけどイマイチはっきりしないところがあるので… 687 名前：デフォルトの名無しさん mailto:sage [04/10/03 00:31:32] イマイチはっきりしないところを書いてくれないとはっきりしない。 688 名前：デフォルトの名無しさん [04/10/04 04:34:15] age 689 名前：デフォルトの名無しさん mailto:sage [04/10/04 13:53:50] ｸﾞｸﾞﾙさんのキャッシュは日本語サイトの \ を＼にするから激しく困る(`Д´) ｸﾞｸﾞﾙさんのﾃﾞｶﾁﾝｺ！ヽ(｀Д´)ノ世界最早男！ 690 名前：686 mailto:sage [04/10/05 02:18:46] 遅レスｽﾏｿ >>687 具体的には判定箇所が具体的に書かれていないところ 例： > 0x80 <-> 0xA0であるならばSJIS 　SJISと言うことは第1バイトか？ > 0xA1 <-> 0xDFが出た場合はSJIS半角カナ・EUC全角かな・カナの強い可能性 　これも第1バイト？ > 0xA1 <-> 0xFEの場合はEUCの強い可能性で0xFD・0xFEの場合はEUC(確定) 　第1バイトと第2バイトの両方？ 691 名前：デフォルトの名無しさん mailto:sage [04/10/05 02:22:48] 文字コード判別・変換クラスてのがあるけど ttp://kasumi.sakura.ne.jp/~gm/gpj/dev/tips/net/txtenc.shtml 692 名前：デフォルトの名無しさん mailto:sage [04/10/05 08:14:19] >>689 これいいなあ。でもどうせなら＼ではなく、逆に全角(じゃなくてU+00A5でもい いが)の￥にするのが正しいと思う……それはさておき。 日本語圏、とりわけShift_JIS(とMSKK的Unicode)では \ (0x5c) が文字として意味をなさない (コードポイントとしての機能しかない) から、仕方ないとも言えるんだよ。 Shift_JISでは0x5cはYEN SIGNという定義なんだけど、実際の使われ方は REVERSE SOLIDUS (ASCIIでの0x5c)でもあるという状態なんだから。 EUC-JPはShift_JISと違って0x5cがREVERSE SOLIDUSなんで、EUC-JPなページの キャッシュでは0x5cは0x5cのままになってるよ。 ああなった理由を考察すると、クロールしたデータをキャッシュとして保存する ときはUTF-8に変換するが0x5cは0x5cのまま通してしまった。一方、キャッシュ を出力するときはShift_JISに変換するのだが、このときShift_JISでは0x5cが YEN SIGNであってREVERSE SOLIDUSではないので、0x5c(REVERSE SOLIDUS)は仕方 ないから＼になる、ということではないかな。 不整合に見えるけど、単に時間差があるだけでしばらく待ってると保存時にも変 換されたものでデータが入れ替わって揃うのかも。それでもページが更新されな いとキャッシュデータが書き換わらない可能性はあるが。 693 名前：デフォルトの名無しさん mailto:sage [04/10/05 08:50:29] Perl6だとYEN SIGN(U+00A5)に演算子として意味を割り当てるので、 扱いとしては完全にREVERSE SOLIDUSと別にせざるを得ないらしいじゃん。 日本語Windowsユーザはどうするのか。 本当はUnicodeに移行してればこんなことで悩まなくなってるはずなんだが、 問題解決に絞るべき知恵のなかったMSKKが 「0x5cは見掛けYEN SIGN、意味は場合によって世界標準Unicodeにおける U+005C(REVERSE SOLIDUS)かYEN SIGN」 なんつー考えナシUnicodeを始めてしまったもんだから、 21世紀になっても悩みがつきないわけだなあこれが。 694 名前：デフォルトの名無しさん mailto:sage [04/10/05 13:11:27] そこでUnicodeの再設計ですよ 695 名前：デフォルトの名無しさん mailto:sage [04/10/05 13:30:33] >>693 MS の CP932 では EUC-JP と同様に 0x5C は Unicode の \u005C にマッピングされてるわけで、 MS 的には CP932 <-> Unicode の相互変換で違う文字になるなんてことは無いはず。 Shift_JIS なんてやめて、CP932 に移行すべき。 しかしC# の XMLWriter で CP932 で書き出すと、encoding="Shift_JIS" になる orz... 696 名前：デフォルトの名無しさん [04/10/05 14:26:23] 0x5cは、全員バックスラッシュにすれば済む話じゃん。 ￥マークは全角で使用して、半角の￥は存在しないと思えば良い。 それよりも、日本語Windowsで0x5cをバックスラッシュで表示してくれないのが困る。 697 名前：デフォルトの名無しさん mailto:sage [04/10/05 14:58:38] 勉強になりそうなので読んでいますが、 CP932? REVERSE SOLIDUS?…(´･ω･｀) もうついていけません…。 たとえばWindows環境では、フォントによって\がバックスラッシュで 表示されたり \のままだったりしますが、これというのはつまり フォントごとに、その文字コードに対応する文字イメージが 異なっているというだけなんでしょうか。それともハードウェアの レベルで何かが起こっているんでしょうか。 文字コードと、実際に画面に表示される文字イメージが どこでどう関連づけられているのか、いまひとつ分かりません。 698 名前：デフォルトの名無しさん [04/10/05 15:13:26] >>697 文字イメージが違うだけ。0x5cは0x5cのまま何も変わっていない。 フォントを書き換えれば、バックスラッシュにできるんだが、改造はしたくない。 マイクロソフトが強制的にバックスラッシュにしてくれればありがたいのだが。 699 名前：デフォルトの名無しさん mailto:sage [04/10/05 15:45:15] >>697 Shift_JISの0x20〜0x7FはASCIIに似てASCIIじゃない文字セット(JIS X 0201)だというのが混乱の原因。 0xA5はASCIIではREVERSE SOLIDUS(バックスラッシュ)なんだけど、JIS X 0201ではYEN SIGN。 で、「\」この文字をUnicodeに変換するとき、Shift_JISはYEN SIGNに割り当てるのに、 cp932(Shift_JISをMSが拡張したもの)ではREVERSE SOLIDUSに割り当てる。 MS的には、Unicodeに変換したときにパス区切り文字が使えなくなると困るから こうせざるを得なかったようだ。JIS X 0201がASCIIから変更した箇所と、 MSがパス区切り文字に使っていた文字が重なってしまった不幸な偶然を恨むしかない。 700 名前：デフォルトの名無しさん mailto:sage [04/10/05 16:20:55] まあそれでも「〜」あたりの混乱よりはマシだな。 701 名前：697 mailto:sage [04/10/05 16:31:42] >>698-699 なるほど、だんだん分かってきました。 もう少し分からないんですが、たとえばマルチバイトモードから Unicodeモードに切り替えてコンパイル・実行したとすると、 文字コード自体は変わってしまっても見た目は(概ね?)同じ ですよね。 同じフォントから同じ文字イメージを取り出すには、この 文字コードの違いを吸収する仕組みが必要だと思うのですが、 どのようになっているのでしょうか。 文字セットごとに「文字イメージ位置検索テーブル」のような ものが用意されていて、文字コードからフォント内の文字イメージ 位置を検索できるようになっているのではと想像してみたのですが 実際のところはどうなっているのでしょうか。 702 名前：デフォルトの名無しさん mailto:sage [04/10/05 16:39:23] >>701 最近のGUIベースのOSだと、フォントセットは大抵 Unicode でのコードポイントにたいして タイプフェイスが割り当てられています。そうして文字コードから Unicode のコードポイントに 変換する仕組みも別途存在します。「どのようになっている」かは、OSやウィンドウシステムに よって異なります。 703 名前：697 mailto:sage [04/10/05 17:02:28] >>702 なるほど、フォント内の文字の並びが何に従っているのか次に 質問しようと思っていたところなんですが、Unicode に合わせて あるんですね。その上で、文字コードをUnicode の文字コードに 変換する仕組みが備わっている(仕組みは環境ごとに異なる)という ことなんですね。納得致しました。 ご回答ありがとうございました。 704 名前：デフォルトの名無しさん mailto:sage [04/10/05 18:05:15] >>703 欧文フォントなんかだと、Unicode ではなく ISO 8859-1 (Latin-1) で入ってたりするものもある。 705 名前：686 mailto:sage [04/10/05 23:45:34] >>691 できました。thx サンプルコードあったのか…気が付かなかった…il||li ○|￣|＿ 706 名前：デフォルトの名無しさん mailto:sage [04/10/06 01:12:14] >>697 euc.jp/i18n/ucsnote.ja.html読めばあ? 707 名前：697 mailto:sage [04/10/06 17:50:44] >>704 Unicode とは並び方の異なるものもあるんですね。そのような フォントの場合はどう扱っているのでしょう。Unicode のコード ポイントに変換する方法では上手くいきませんよね…。使用する フォントがどんな文字セットのコードポイントに一致しているか という情報も、どこからか取り出しているのでしょうか。 >>706 ありがとうございます。 記号の読み方などバッチリ出てますね^^; 内容的にはまだよく分からない部分もありますが、 とりあえず最後まで読みすすめてみようと思います。 708 名前：706 mailto:sage [04/10/06 22:47:40] >>707 そんな難しいことは書いてないです。 良く書けているページなので何回も読んでみてください。 先入観を取り払えば、理解できるはずです。 ちなみに>>698は間違っているのでスルーしてください。 文字実体、グリフという概念を理解してない。 709 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:07:24] JIS X201はもはや業界のお荷物でしかない 710 名前：デフォルトの名無しさん mailto:sage [04/10/08 11:45:03] 和文フォントはWinの文字コード表でみると円記号の上に ツールチップで"REVERSE SOLIDUS"と出るのが激しく間抜けだ。 せめてREVERSE SOLIDUSのグリフをどこかに突っ込んでおいてくれよう。 711 名前：デフォルトの名無しさん mailto:sage [04/10/08 12:17:57] JIS X 0208的には1区32点(＼)がREVERSE SOLIDUSなんだけど、またもやMSが(略 712 名前：デフォルトの名無しさん mailto:sage [04/10/08 12:32:42] >>711 Microsoft のは CodePage 932 っていう、彼らの定義したコーディングシステムなわけで、 文句言うのはよいけど「JISと違うやん」ってのは文句にすらなってないような･･･ 日本のコンピュータ言語関連の書籍でも、ソースコードのREVERSE SOLIDUSを \ で 印字してるものが結構あるよね。あれってどういう習慣から来ているんだろう・・・ 713 名前：デフォルトの名無しさん mailto:sage [04/10/08 13:21:16] PC-9801 714 名前：デフォルトの名無しさん mailto:sage [04/10/08 15:04:37] >>712 X0201の影響じゃ？てかISO/IEC646だかであのあたりは国毎に勝手にしる！ってのが未だに尾を引いてるだけかと。 715 名前：デフォルトの名無しさん mailto:sage [04/10/09 14:58:11] >>712 > 日本のコンピュータ言語関連の書籍でも、ソースコードのREVERSE SOLIDUSを \ で > 印字してるものが結構あるよね。あれってどういう習慣から来ているんだろう・・・ 凄い文章だな。 716 名前：デフォルトの名無しさん mailto:sage [04/10/12 18:04:57] >>712 でもさー、JISとCP932って相互変換できるのに、対応する文字が それぞれ別のunicodeへマッピングされるのってすごい使いにくい んだよね。なんとかしてくれよ... 717 名前：デフォルトの名無しさん mailto:sage [04/10/12 19:26:18] >>712 そう思うんならMS明朝の0x5cのグリフが円記号なのは納得いかん。 718 名前：デフォルトの名無しさん mailto:sage [04/10/14 00:32:17] ISO-2022-JPとEUC-jpとShift JIS(JISに載ってるやつ)とCP932は含む文字の集合が違うのに、 たいていの人はそれらの間で1対1の変換が出来ると思っている。 また、文字コード変換{ライブラリ, プログラム}もそうであるように見せかけている。この辺が混乱の元だろう。 「危ない文字(コード)は使わない」ということをリテラシーとして教えるべきだ。 719 名前：デフォルトの名無しさん mailto:sage [04/10/14 02:48:47] 「危ない文字(コード)は使わない」ってことなら 危ない文字(コード)を表にでもして教えてよ。（出来れば理由も） あとお勧めの変換ソフトがあるなら教えて！ 720 名前：デフォルトの名無しさん [04/10/14 02:56:32] その環境で、何の文字コードを使うかは何処で決定されるのでしょうか？ windos環境とunix環境のそれぞれの決定のされかたを簡単でいいんで教えてください。 721 名前：デフォルトの名無しさん [04/10/14 02:57:41] man locale 722 名前：デフォルトの名無しさん mailto:sage [04/10/14 04:28:43] >>719 論外: ・いわゆる環境依存文字(丸付き数字など) ・JIS X 0201 片仮名(いわゆる半角カタカナ) ・CP932でJIS X 0201のRVERSE SOLIDUSを円記号として扱う 避けた方が無難: ・JIS X 0208でASCIIと同じ名前のもの(いわゆる全角英数記号類。疑問符とか) ・和字間隔(いわゆる全角スペース) ・JIS X 0208のYEN SIGN(漢字の「円」を使う) 723 名前：デフォルトの名無しさん mailto:sage [04/10/14 11:24:06] >>722 しかしunicodeはさむと従来は何の問題もなく同じだった「〜」なんかも 違う文字になっちゃうからな〜。 724 名前：デフォルトの名無しさん mailto:sage [04/10/15 03:39:30] ちょっと話題からずれてしまうかもしれませんが teknap masternap.org/teknap/ で UTF-8 のファイル名を Shift-JIS に変換して共有したいのですが ソースコードへのパッチの当て方が分かるかたいませんか。 725 名前：デフォルトの名無しさん [04/10/16 15:00:13] age 726 名前：デフォルトの名無しさん [04/10/17 03:19:24] age 727 名前：デフォルトの名無しさん mailto:sage [04/10/18 20:31:59] 関係ないけど、WindowsがJIS X 2013:2004に完全対応すると言われている2006年以降に JIS X 2013:2004に完全対応したISO-2022-JP-3 （あるいは、ISO-2022-JP-3-StrictやISO-2022-JP-3-Compatible）って メールの文字コードの主流になるのでしょうか？ 一足飛びにUTF-7に移行するような気もしないでもないのですが、 メールソフトが間違えて（あるいは対応していなくて）ISO-2022-JPでデコードしてしまうと ひどいことになってしまうのですが… P.S. >>722によると、この文章で使っている、いわゆる全角丸括弧や全角疑問符も いけないことになってしまいますね。 いわゆる半角丸括弧や半角疑問符は幅が詰まりすぎているから使いたくないんですけどね。 728 名前：デフォルトの名無しさん mailto:sage [04/10/18 20:57:15] 何度も書くようだけど、このままWindowsにJIS X 0213:2004が採用されたら、 辻さんや樋口さんや榊原さんの大半が困ってしまう事態が起きるということは もっと世間に認知されていてもよいと思うんですけどね。 「字体が変わる」のは防げないにしても（防げるに越したことはないが）、 「以前の字体が（事実上）出せない」のは固有名詞にも配慮していないので、 固有名詞にも対応すべきである工業規格としてまずいと思います。（※1） （※1）この点で、「現に地名・人名などの固有名詞に用いられている字体にまで 及ぶものでもない」としている表外漢字字体表とは軌を異にします。 なお、表外漢字字体表では「現に」と表記しているとおり、表外漢字字体表発表以降の 地名・人名は表外漢字字体表に従うことを要望している（そして、実際に表外漢字字体表に 沿う形で人名用漢字が追加された）のですが、なんと市町村合併で最近誕生した 「葛城市」（奈良県）と「薩摩川内市」（鹿児島県）はそれに従っていません （官報に記載された「葛」と「薩」の字体が、表外漢字字体表の印刷標準字体と異なっている）。 幸い、1面1区から1面13区までの間に40字弱の保留領域（ただし非漢字領域ですが）が ありますので、ここに「互換用漢字」としてJIS X 0208:1997の例示字体どおりの 「辻」「樋」「榊」などを追加するのもよいでしょう。あと、「葛」「薩」もですね。 できればJIS X 0208:1997の例示字体ではなく、JIS X 0213:2004で変更されたほうの字体 （つまり、表外漢字字体表の印刷標準字体）のほうを「互換用漢字」にしたいのですが、 再々変更は避けたいので、いかんともしがたいところです。 729 名前：デフォルトの名無しさん mailto:sage [04/10/18 21:12:49] >>727 詰まりすぎでないフォントを使えばいいのでは? 730 名前：デフォルトの名無しさん mailto:sage [04/10/18 23:15:56] もうリッチな環境なんだからUTF-32で CJKとか使えなすぎ 731 名前：デフォルトの名無しさん mailto:sage [04/10/19 00:01:36] >>727 > 一足飛びにUTF-7に移行するような気もしないでもないのですが、 ぷっ +MHcwYw- 732 名前：デフォルトの名無しさん mailto:sage [04/10/19 00:36:12] >>694 そんなことしたら新旧混在して混乱に拍車を掛けますがな 733 名前：デフォルトの名無しさん mailto:sage [04/10/19 00:42:00] >・CP932でJIS X 0201のRVERSE SOLIDUSを円記号として扱う えーとすみません 煽りじゃ無しにこの一文の意味が本気で分かりません 734 名前：デフォルトの名無しさん mailto:sage [04/10/19 04:01:43] >>727 確か UTF-7 は過渡期の産物で、MIME を併用した UTF-8 が本命じゃなかったけ？ 735 名前：デフォルトの名無しさん mailto:sage [04/10/19 07:52:39] 主にメールのために考えられたはずだけど、 現実的にはUTF-8 + base64が多いな。無用の長物だな。 736 名前：デフォルトの名無しさん mailto:sage [04/10/19 08:15:06] >>712 JIS C (JIS X 3010)に円記号を使っていいと書いてる 737 名前：デフォルトの名無しさん mailto:sage [04/10/19 09:49:47] >>728 ケチケチせずに半角カナの領域削ればいい。 どうせWindowsは採用する気ないんだから ISO/IEC 10646への追加要求のソースになってくれさえすれば 誰も実装しなくても問題はない 738 名前：デフォルトの名無しさん mailto:sage [04/10/19 19:23:16] >>727 > 1段落目 なりません。 > P.S. これについては >>729 の人が書いている通り。 >>733 値段をあらわすのに使うと、ひどい目に遭うかもしれないよということです。 739 名前：デフォルトの名無しさん mailto:sage [04/10/19 19:44:51] そもそもJIS X 2013:2004に完全対応なら符号化表現の名称は ISO-2022-JP-2004でなくてはならんし。 これはIANAに登録されていないのでメールで使ってはならない。 740 名前：デフォルトの名無しさん mailto:sage [04/10/19 19:45:32] コピペしたら間違いまでコピペしてしまったorz JIS X 0213:2004ね 741 名前：デフォルトの名無しさん mailto:sage [04/10/19 23:54:35] >>722 >・CP932でJIS X 0201のRVERSE SOLIDUSを円記号として扱う >>733 > えーとすみません > 煽りじゃ無しにこの一文の意味が本気で分かりません >>738 > 値段をあらわすのに使うと、ひどい目に遭うかもしれないよということです。 「JIS X 0201のREVERSE SOLIDUS」？？？ 「CP932で(略)REVERSE SOLIDUS」？？？ 742 名前：デフォルトの名無しさん mailto:sage [04/10/20 01:48:46] >>741 後者。 743 名前：デフォルトの名無しさん mailto:sage [04/10/20 10:03:35] ・CP932で0x5cを円記号として扱う って事ですか? 744 名前：デフォルトの名無しさん mailto:sage [04/10/20 14:36:42] >>743 そうです。 745 名前：デフォルトの名無しさん mailto:sage [04/10/22 03:57:53] > 値段をあらわすのに使うと、ひどい目に遭うかもしれないよということです。 ひどい目にあったところが実際にあるんでしょうか？ 国内のインターネット通販やってる所って遭遇する可能性が．．． 746 名前：デフォルトの名無しさん mailto:sage [04/10/22 09:57:55] Googleの検索結果上ではよく文字化けしてる 747 名前：デフォルトの名無しさん mailto:sage [04/10/22 11:53:40] >>745 「ウリの環境だとウォンと書いてるニダ、それ以上は払わないニダ」 748 名前：デフォルトの名無しさん mailto:sage [04/10/22 13:21:17] 韓国語版WindowsのU+005CにはWON SIGNのグリフが入ってるから 円記号問題と似たようなことが起こるらしいな 749 名前：デフォルトの名無しさん mailto:sage [04/10/22 13:40:26] >>747 日本側が中小だと実際にそれでごねて契約の十分の一しか支払われなかった ケースもあるらしい。 750 名前：デフォルトの名無しさん mailto:sage [04/10/22 16:05:33] >>749 嘘つきは泥棒の始まりか 751 名前：デフォルトの名無しさん mailto:sage [04/10/25 17:55:53] >>728 「市町村合併 字体」とかでぐぐると分かるけど >当用漢字表以外の漢字についても、当用漢字字体表の字体に準じた >字体を用いてもよい。 みたいですね。この時点ですでに表外漢字字体表とは 食い違っているという… 752 名前：デフォルトの名無しさん mailto:sage [04/10/25 18:42:21] >>751 字体表は答申どまりで内閣告示にならなかったからな。 朝日新聞とかにも無視されてるし（内閣告示だったら無視できなかったはず）。 字体表を尊重しているのなんて、 国語審議会のメンバーを送り込まれたJIS X 0213:2004だけじゃねえか。 753 名前：デフォルトの名無しさん mailto:sage [04/10/25 19:15:06] 人名用漢字部会も。 「芦」はなぜか簡易慣用字体のほうが採用されたけど。 754 名前：デフォルトの名無しさん mailto:sage [04/10/28 06:53:30] ひょろっと書いた自作のユニコードライブラリを 鬼門・合成に対応させようか迷っとります。 コンパクトな構造が崩れる悪寒。そこまでサポートする意味あるのか…。 欧米人の心境が１�_�gくらいわかったような気分す。 755 名前：デフォルトの名無しさん mailto:sage [04/10/28 12:29:56] >>754 ISO 10646-1は全てのシステムが合字処理を実装することを要求 していないよ。実装レベル分けされていて、合字のない実装は Level-1に分類される。 756 名前：デフォルトの名無しさん [04/11/10 22:17:25] ここで質問して良いのか分かりませんが、 Unicodeでのエスケープシーケンス一覧はどこかにありますか？ 757 名前：デフォルトの名無しさん mailto:sage [04/11/10 22:55:38] Unicodeはエスケープシーケンスなんか使いませんが 758 名前：デフォルトの名無しさん mailto:sage [04/11/11 00:48:03] 単にunicodeの一覧の話か？ 759 名前：デフォルトの名無しさん mailto:sage [04/11/11 05:43:47] UTF-8 指示用の「ESC % G (1B 25 47)」というのが規定されてはいる。 X の Compound Text で使われているようだ。 760 名前：デフォルトの名無しさん mailto:sage [04/11/11 05:54:20] とりあえずここにまとめられてるのでぜんぶだとおもう。 www.itscj.ipsj.or.jp/ISO-IR/2-8-1.htm www.itscj.ipsj.or.jp/ISO-IR/2-8-2.htm 761 名前：デフォルトの名無しさん mailto:sage [04/11/11 10:09:30] JIS/SJIS/EUCから変換されたunicodeテキストがあります。 ただし変換表がどれか(MS系かJIS系かとか)わかりません。 これを適当に自動判別して元のJIS/SJIS/EUCに戻せるような ライブラリってないですかね? perlのモジュールになってる と楽なんですけど。 762 名前：デフォルトの名無しさん mailto:sage [04/11/11 23:15:20] JIS(っていうかISO-2022-JPだよね？)だったのか、EUC-JPだったのか、 あるいはShift_JISだったのか、を判別したいんですか？ だったら無理。 変換表がどっちなのかを判別したいんですか？ だったらそれなりに可能だろうけど、既存のライブラリはたぶんない。 わりと簡単に作れるので、勉強だと思ってガンバレ。 763 名前：デフォルトの名無しさん mailto:sage [04/11/12 10:03:30] >>762 変換表をどっちか判別したいだけです。紛らわしい書き方ですまん。 同じ変換表で変換されたものの元がJISかEUCかを判定したいわけでは もちろんありません(全く同じ結果になるからできるわけないし(笑))。 で、既存のライブラリはなさげですか。どっちかの変換でしか現れない 文字に着目して判定できるとは思うのですが、きちんと漏れなく調べる のが面倒なのであればいいなと期待していたのですが。 764 名前：デフォルトの名無しさん mailto:sage [04/11/12 12:26:15] 「XML日本語プロファイル」がいちおう既存の変換表を網羅しているはず だから(Apple除く)それを参考にして作れ 765 名前：デフォルトの名無しさん [04/11/22 16:15:28] 766 名前：デフォルトの名無しさん mailto:sage [04/11/25 12:18:47] 質問いいですか OS Windows2000 Japanese version(韓国語言語インストール済み) 開発言語 VB6.0 テキストファイルを読み込んでその内容をテキストボックスに出力させるプログラムをつくったのですが 文字化けしてしまいます。 テキストファイルには、韓国語と日本語がはいっています。 テキストファイルはUnicode形式で保存しています。 これをバイナリ−データとして開いてそれぞれ変数に代入して テキストボックスに出力しています。 Unicode形式なのに韓国語が文字化けしてしまうのです。 どうしてでしょうか？ 767 名前：デフォルトの名無しさん mailto:sage [04/11/25 12:38:52] 代入しているコードを貼らずに質問とな。 768 名前：デフォルトの名無しさん mailto:sage [04/11/25 12:47:40] >>766 Textbox自体がUNICODEの表示に対応していないから。 WebBrowserコントロールにでも出せばいい 769 名前：デフォルトの名無しさん mailto:sage [04/11/25 14:39:51] Private Sub Command1_Click() Dim lngFileNum As Long Dim strText As String lngFileNum = FreeFile Open "d:\VB\test.dat" For Input As #lngFileNum Input #lngFileNum, strText Label1.Caption = strText Close #lngFileNum End Sub コードをかかずにすみませんでした。 テキストボックスではなくてラベルボックスでした unicode形式のテキストファイルを読みこんで出力するだけなのですが どうしても文字化けしてしまいます。 770 名前：デフォルトの名無しさん mailto:sage [04/11/25 14:53:40] VBスレへどぞー、って感じだな。 771 名前：デフォルトの名無しさん mailto:sage [04/11/26 05:24:45] >>768の通りなんだけどな。 VBの中はUnicodeだけど、外から見える部分は勝手にAnsiてかShift_JISにしちゃうんよ。 コントロールしかり。 772 名前：デフォルトの名無しさん mailto:sage [04/11/26 07:40:18] >>768 >>771 そうだったのですか！ありがとうございます。 Private Sub Command1_Click() 　Dim lngFileNum As Long 　Dim strText As String 　lngFileNum = FreeFile 　Open "d:\VB\test.dat" For Input As #lngFileNum →Input #lngFileNum, strText 　Label1.Caption = strText 　Close #lngFileNum 　End Sub ですが、上の→の行でファイルを読みこんで変数に代入するときに 文字化けしたものが代入されているのですが、これは内部処理ではないのでしょうか？ 773 名前：デフォルトの名無しさん mailto:sage [04/11/26 11:42:44] >>772 Input 文が、勝手に「ファイルの中身はShift_JISだ」と仮定して変換しちゃってるんだと思う。 VB スレで訊いてみて。 774 名前：デフォルトの名無しさん mailto:sage [04/11/26 12:04:22] だったら日本語も表示されないでそ と思ったら、「日本語は化けない」とは言っていないのか。 775 名前：デフォルトの名無しさん mailto:sage [04/11/26 12:14:45] ありがとうございます。VBスレで聞いてみます。 長々すみませんでした。あ、日本語は化けてません。 776 名前：謎！ mailto:sage [04/11/26 17:38:46] 02 - \202\307\202\361\202\310\202\306\202\253\202\340\201B.mp3 この文字列を読める日本語に変換するにはどういう解釈をすればいいでしょうか。 \はバックスラッシュです。 元となっているエンコーディングが分かりませんし 数値も256を超えるのがあったりしてシングルバイトの文字列でもないようです。 よろしくおねがいします。 777 名前：デフォルトの名無しさん mailto:sage [04/11/26 18:16:40] >>776 「どんなときも。」であってるよな… だったら、\の後は8進数だよ。文字コードはSJIS。 778 名前：謎！ mailto:sage [04/11/26 18:44:41] >>777 8進数！謎が解けました。どうもありがとうございます。 779 名前：謎！ mailto:sage [04/11/26 20:38:23] 付け加えて、>>776のフォーマット（書式？）の名前は一般的には何と呼ばれていますか？ Googleで検索して調べようにもキーワードがわかりません、、、 780 名前：デフォルトの名無しさん mailto:sage [04/11/26 21:07:51] 単に、表示側の対処法の違いだけだと思うけど 781 名前：デフォルトの名無しさん mailto:sage [04/11/26 22:09:18] >>779 Cの規格書的には、octal escape sequenceだな。 JIS翻訳版なら8進逆斜線表記。 782 名前：デフォルトの名無しさん mailto:sage [04/11/26 22:14:15] ナル文字としてよく使う'\0'も実はその8進表記。 783 名前：デフォルトの名無しさん mailto:sage [04/11/26 22:25:57] てか、普通に 0 ってかくと字句解析的には8進表記とみなされるんじゃなかったっけ？ 784 名前：デフォルトの名無しさん mailto:sage [04/11/26 23:11:18] その通り。 785 名前：デフォルトの名無しさん mailto:sage [04/11/27 00:38:12] その通りだが、0が8進数なのと、\0が8進エスケープシーケンスなのとは、 次元がまったく違うので、Cの規格書を読んで、Cスレにでも行け 786 名前：デフォルトの名無しさん mailto:sage [04/11/27 10:22:28] 質問なのですが、 Windows2000のコントロールパネルの項目にある「地域のオプション」についてなのですが、 韓国語のソフトをインストールして使用したいので、システムロケールを韓国語にしたのですが、 ユーザーロケールも韓国にしないといけないのでしょうか？ ユーザーロケールは通貨や単位の表記法の設定と書いてあるのですが、 やはりシステムロケールとユーザーロケールが食い違うとうまく表示してくれないのでしょうか？ 787 名前：デフォルトの名無しさん mailto:sage [04/11/27 12:03:18] とりあえずユーザーロケールはそのままでも動くんじゃないか？ 駄目みたいだったらユーザーロケールも変えてみれば良いじゃないか。 788 名前：デフォルトの名無しさん mailto:sage [04/11/27 16:35:39] >>786 板違い 789 名前：謎！ mailto:sage [04/11/27 23:32:55] >>781さん、どうもありがとうございました。おかげさまで必要な情報も検索で得られました。 790 名前：デフォルトの名無しさん mailto:sage [04/12/08 02:19:26] BMP内のUnicode Standard 4.0の文字ができるだけたくさん表示できるtrue typeフォントを教えてください。 Arialの穴が多少なりとも埋まるとありがたいのですが。 791 名前：デフォルトの名無しさん mailto:sage [04/12/08 02:52:36] Code2000とかはどうなんだろ 792 名前：デフォルトの名無しさん mailto:sage [04/12/09 21:23:51] インド語とか、ただ文字が入ってるだけだとUnicode Standardの文字表を 表示する役にしか立たんぞ 793 名前：デフォルトの名無しさん mailto:sage [04/12/14 03:41:39] >>791 >>792 レスが遅れましたが、ありがとうございます。 今から入れてみます。 794 名前：デフォルトの名無しさん [04/12/17 05:10:50] MTで使用するのにEUC−JPかUTF-８って 結局どっちがお勧めだと思いますか？ 795 名前：デフォルトの名無しさん mailto:sage [04/12/17 10:59:20] 「MT」とは何か 796 名前：デフォルトの名無しさん mailto:sage [04/12/17 11:06:57] たぶんメルセンヌツイスターかマルチスレッドと思われる。 EUC-JPやUTF-8との絡みがよく分からんが、きっとこのあと説明してくれるのだろう。 まかり間違ってもGoogleで調べればすぐ分かるような、Movable Typeのことではあるまい。 797 名前：デフォルトの名無しさん mailto:sage [04/12/17 12:29:51] はあ？ マニュアルトランスミッションのことに決まってるじゃん 798 名前：デフォルトの名無しさん mailto:sage [04/12/17 14:30:37] Magnetic TapeじゃなかったのかYO 799 名前：デフォルトの名無しさん [04/12/17 14:58:41] その調べればすぐわかるMovable Typeのこと でも文字コードの設定を変えるのは簡単だけど、 結局世の中使ってる奴がバラバラで統一されて無いもんだからこまるのさ でもって、みんなはどっちを選択してんのかなって思ったわけ ちなみに自分は最近EUCからUTFへ変えてみた 800 名前：デフォルトの名無しさん mailto:sage [04/12/17 17:25:24] Movable Type なら専用スレで聞いた方が早くね？ 801 名前：デフォルトの名無しさん mailto:sage [04/12/17 18:52:27] ここが２ちゃんでよかったな 802 名前：796 mailto:sage [04/12/17 20:57:06] >>799 UTF-8を選ぶでしょ。 Googleで調べてみれば、多くの人がそっちへ乗り換えてるはず。 それにUTF-8なら、Windowsでもきちんとバックスラッシュが表示されるし(どうでもいい?)。 でも俺はUnicodeは嫌いだから、あえてEUC-JPを使いたい。 803 名前：デフォルトの名無しさん [04/12/18 01:34:15] >>802 794=799 そうなんだよね 実は俺も同じような考えで、時代の流れには従うしかないか ってわけでUTF-8に乗り換えたんだけど やっぱUnicodeっていまいち好きじゃあないんだよね 796のような発言でちゃらかす人は、そういうすぐに検索かかるほど 一般的なもので使用可能な統一文字コードを開発＆普及さして欲しいもんですな 気長に待ってますよ 804 名前：デフォルトの名無しさん [04/12/18 01:37:21] ■関連サイト(ノード) ┣ rightp2p.s68.xrea.com/node/ ┣ www.stereoz.net/node/ ┗ moejump.s6.x-beat.com/node.php ■関連サイト(本体・BBS・その他) ┣ rightp2p.s68.xrea.com/ ┣ phphp.s58.xrea.com/ ┣ www.stereoz.net/ ┣ printf.jugem.jp/ ┗ www.ero8.com/ 805 名前：796 mailto:sage [04/12/18 01:42:54] >>803 おいおい、ちゃらかすって...。 プログラム板で「MT」って書いたから、一番可能性の高い物を出してやったのに。 :) まず聞く場所が違う、MTで通じるわけがない(エスパー募集中?)、「Unicodeが好きじゃない」なんて 前提が書いてない、いろいろ問題がありすぎるんだよ。 君はねえ、ISO-2022を使いなさい。あれが今のところベスト。 806 名前：デフォルトの名無しさん mailto:sage [04/12/18 01:48:37] 関連スレでも出てたけど、 www.unicode.org/versions/corrigendum3.html なんか笑えるね。 807 名前：デフォルトの名無しさん mailto:sage [04/12/18 02:35:30] >>806 関連スレってどこ? しかし、Unicodeもぼろぼろだな。GB18030で中国は離反するしな。 あれはなかなかうまかった。さすが計略に長けた中国。 808 名前：デフォルトの名無しさん mailto:sage [04/12/18 07:56:22] そんなに簡単にバレるものは計略とは言わない 809 名前：デフォルトの名無しさん mailto:sage [04/12/19 19:07:18] GB18030の採用に関する解釈が正反対なのが笑える www2.xml.gr.jp/log.html?MLID=xmlmoji&N=814 810 名前：デフォルトの名無しさん mailto:sage [04/12/19 19:22:06] >>809 GB18030なんて一言も出てきてないぞ。 だいたいこれ、2000年6月の話だし。 811 名前：デフォルトの名無しさん mailto:sage [04/12/20 15:05:56] 日本語については既存の文字コードとの変換を一意に 決められずに乱立を許した時点でunicodeは失敗したと 思うね。 812 名前：デフォルトの名無しさん mailto:sage [04/12/20 15:14:09] MSとAppleとSunとJISCが話し合って変換テーブルを統一するなんて 現実的にあり得そうもないことをしなくちゃならなかったんだから、 失敗は必然だったとか言ってみる。 813 名前：デフォルトの名無しさん mailto:sage [04/12/20 16:33:12] unicodeが失敗って、どこの世界の住民？ unicode以上に国際的な文字コードってなに？ 814 名前：デフォルトの名無しさん mailto:sage [04/12/20 16:45:30] TRONコードにきまってるだろ 815 名前：デフォルトの名無しさん mailto:sage [04/12/20 20:15:00] >>813 > unicode以上に国際的な文字コードってなに？ ISO-2022。 でも現実としては、今のところUnicode。 > unicodeが失敗って、どこの世界の住民？ あきらかに失敗だよ。作りが悪すぎる。それでも使わざるをえない。 すぐ分かるのはUTF-16のサロゲートペア。他にもたくさんあるよー。 816 名前：デフォルトの名無しさん mailto:sage [04/12/20 21:39:18] 一文書中にアラビア語と韓国語を交えた日本語とかを書くには Unicodeは便利です。 817 名前：デフォルトの名無しさん mailto:sage [04/12/20 23:10:21] >>815 それはUTF-16の問題であってUNICODEの問題ではないでしょ。 UCS-4的にはまとまってるわけで。 どっちかというと言語タグとかの方が問題だとは思うが・・・ ISO-2022が理想かというと激しく疑問だし。 TRONコード? 窓から捨てちゃってよ。 実際マルチランゲージ対応しようとするとUNICODEが無難だとは思うがなぁ。 UNICODE <-> ISO-2022 とか UNICODE <-> EUC を考えると 頭が痛くなるのは同意するけどね。 818 名前：デフォルトの名無しさん mailto:sage [04/12/20 23:54:41] >>817 Unicodeのそもそもは「16ビットに収めたい」ってところが出発点だから、 UTF-16のダメさはUnicodeのダメさと直結してるんだよ。 # そうでなければ、ISO-10646 DISを否決する必要がなかった。 だからCJKのunificationなんて、少し考えればやばそうなことをやっちゃったわけで。 あのころISO-2022が現実的でなかったのは、その複雑さとステートフルなところだったんだけど、 今となってみると、Unicodeの方がよっっっっぽど複雑なんだよね。なんだかな。 819 名前：デフォルトの名無しさん mailto:sage [04/12/21 00:50:37] 当初日本人の多くは積極的に係わらなかったから、 # それ仕方なかったことだったと思うけれど あんまりチェックできなくて、>>812,>>806みたいな問題をたくさん残してしまったね。 820 名前：デフォルトの名無しさん mailto:sage [04/12/21 03:20:55] >>818 もう少し勉強しよう。UCS-2は16bitに収まってます。 UTF-16はUCS-4をカバーしようとしてサロゲートペアなんて出てきたわけで。 (もはや)UNICODE＝16bitではありません。 UNICODEってISO-2022に比べて「っ」が4つ並ぶような複雑さですかね？ よっぽどISO-2022のほうが複雑だと思うのですが･･･。 821 名前：デフォルトの名無しさん mailto:sage [04/12/21 03:25:54] >>816 しかし日本語と中国語を混ぜては書けない。 同じ文字があるから、言語タグや上位レイヤーの助け無しにはどちらの言語か分からないし、 結果として字体もヘンテコなものになるだろう。 822 名前：デフォルトの名無しさん mailto:sage [04/12/21 03:28:12] >>820 君が勉強しなさい。 そもそも、UnicodeはBMPに全部収めるつもりだったんだよ(と言えば分かるか?)。 しかし全然収まらないから、サロゲートペアで16面ほど追加せざるをえなかったの。 823 名前：デフォルトの名無しさん mailto:sage [04/12/21 03:38:19] ISO-2022なんて、実装しようとしたら結局内部的に固定長コードに 置き換えることになるんだがなあ。 初めから内部UCS-4にしとくのと大差ない。 824 名前：822 mailto:sage [04/12/21 03:42:39] >>823 それはそうなんだけど、その話をするにはまず、外部交換コードと内部処理コードを 分けて考える必要がある。 # じゃないと、そういう考え方をしたことがない人が理解出来ずに暴れ出す。 825 名前：デフォルトの名無しさん mailto:sage [04/12/21 03:45:30] >>823 UCS-4を使っても固定長にはならないよ。 複数のcode pointを組合せて表現する文字は沢山ある。 826 名前：デフォルトの名無しさん mailto:sage [04/12/21 23:51:52] ばか゜か゛ 827 名前：デフォルトの名無しさん mailto:sage [04/12/22 05:15:12] つーかなんでISO 2022とUnicodeの対立になるか意味不明なんですが。 外部交換コードはISO 2022だけど内部処理コードはUnicodeって無茶苦茶ありうる 828 名前：デフォルトの名無しさん mailto:sage [04/12/22 08:14:33] そんな可逆性が保証できないものを内部コードに採用した設計者はクビだ 829 名前：デフォルトの名無しさん mailto:sage [04/12/22 10:09:22] >>828 きちんと変換を定義すれば可逆にできるでしょ。外部との やりとりはISO 2022しか使わないんだから、誰かが好き勝手 な変換表使ってISO 2022からUnicodeに変換したあとで渡して くる心配はいらないわけで。 あとでなぜそうしたか知る人が失われた頃、内部ユニコード ならそのままもらえば変換しなくてイイジャンとかヴァカが 考えてはまりそうではある。 830 名前：デフォルトの名無しさん mailto:sage [04/12/22 11:07:27] 「骨」問題も可逆にできるの？ 831 名前：デフォルトの名無しさん mailto:sage [04/12/22 12:25:54] 確かに内部をUnicode系にすると、CJKVの漢字の使い分けできないな。 832 名前：デフォルトの名無しさん mailto:sage [04/12/22 12:30:50] 当然UCS-4にするんでしょう? それでもISO-2022-JPじゃなくて、 ISO 2022 + ISO character set registry全体と可逆かどうかなんて目眩しそうだけど… 833 名前：デフォルトの名無しさん mailto:sage [04/12/22 14:27:22] >>828 >>831 まったくだ。 >>829 >>832 UCS-4にしたとして、言語情報をどうやって持つんだい。言語タグ? 上位レイヤー? >>830 もちろんダメだし、それだけではなく日本語と中国語の漢字の区別が吹っ飛ぶ。 834 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:04:53] >>833 >日本語と中国語の漢字の区別が吹っ飛ぶ。 大袈裟すぎ。可読性に影響を与えるほどの違いなんかねえよ。 細かい区別は符号化文字集合のスコープ外。 骨とかを区別したいなら、XMLなりPDFなり好みのフォーマットで交換しやがれ。 835 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:08:10] >>834 グリフの違いだと勘違いしちゃってるんだよね。 まず、検索・翻訳が出来ない。もちろん読み上げもできない。 一度言語情報が失われると、後からの追加は非常に難しい。 836 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:14:37] >>835 原則論としては、言語情報とそれに依存する処理はUnicodeのスコープ外。 ただし読み上げなどのためには言語タグが用意されている。 で、何か問題でも？ 837 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:15:35] また、それだけではない。 >>834 の人は分かってるみたいだけど、包摂基準という物がある。 たとえば、カタカナの「ロ」と漢字の「口」(くち)は、非常に似ているが同じ文字にはしない。 なぜなら、意味が違う、音が違うからだ。 同じように、漢字という物も義(意味)、音、形がある。 Unicodeの漢字の包摂は形しか見てない。 表音文字であるアルファベットを使う人たちにとって、表意文字の概念は理解しにくいからね。 結局、漢字の一番大事な「義」は無視して包摂されることになってしまった。 838 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:18:12] >>836 言語タグは使うべきではない、と規格に書いてあるね。 あれは「一応言い訳としてつけておきました」程度の物。 > で、何か問題でも？ 問題あるよ。君はプレインテキストでは検索はしないの? 839 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:20:49] >>837 >結局、漢字の一番大事な「義」は無視して包摂されることになってしまった。 無視されてねえよ（Noncognate Rule）。 840 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:25:10] >>838 >言語タグは使うべきではない、と規格に書いてあるね。 「言語タグは使うべきではない」なんてどこに書いてある？ XMLと併用するときはUnicodeではなくXMLのほうのタグを使えって話ならあったが。 841 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:25:45] >>839 そういう意味ではない。 たとえば、それぞれの言語での意が違う漢字でも「同じ文字」として扱われている。 あと、>>836 に対してさらに。 > ただし読み上げなどのためには言語タグが用意されている。 あらかじめ、「読み上げが必要である」って誰が判断するんだい? それは読み上げソフトウェアを使って読む側が判断することで、書き手が判断できる事じゃない。 842 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:40:00] >>841 漢字統合に文句があるのか、言語情報がないことに文句があるのか、どっち？ >たとえば、それぞれの言語での意が違う漢字でも「同じ文字」として扱われている。 そんなのは漢字に限った話ではない。 >あらかじめ、「読み上げが必要である」って誰が判断するんだい? だから言語情報は与えることもできるけど あくまでオプションだというのがUnicodeの考え方だろ。 常に情報は多けりゃ多いほどいいってもんじゃないだろうに。 843 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:43:01] 5.10 Language Information in Plain Text より。 A common misunderstanding about Unicode Han Unification is the mistaken belief that Han characters cannot be rendered properly without language information. This idea might lead an implementer to conclude that language information must always be added to plain text using the tags. However, this implication is incorrect. The goal and methods of Han Unification were to ensure that the text remained legible. Unicodeについてのありがちな誤解は、「漢字は言語情報無しにはきちんと表示出来ないからHan Unificationは間違いだ」と信じられていることだ。 この考えは、実装者に「プレインテキストには、必ず言語情報をタグで付けなければならない」と思わせる可能性がある。 しかしながら、この実装は間違いだ。 Han Unificationの目標と構想は、テキストを読みやすく残しておくためのものだからだ。 ようするに、この文章を書いたヤツは 「英語とドイツ語のaが同じであるのと同じ程度に、日本語と中国語の骨は同じだ」 と思っている。表音文字の論理を表意文字にあてはめちゃってるんだよ。lol 844 名前：デフォルトの名無しさん mailto:sage [04/12/22 16:54:11] >>843 >「英語とドイツ語のaが同じであるのと同じ程度に、日本語と中国語の骨は同じだ」 同じだろ。 プレーンテキストの基準は可読性。「骨」は読み間違いようがない。 ローマン体「H」とドイツの伝統的なフラクトゥール体の「H」など、 ラテンスクリプトにも同様の例がある。 845 名前：デフォルトの名無しさん mailto:sage [04/12/22 17:41:00] >>844 > ローマン体「H」とドイツの伝統的なフラクトゥール体の「H」など、 > ラテンスクリプトにも同様の例がある。 だから表音文字と表意文字を同じにするなよ。 「起源のラテン語が同じでスペルが似ているから、同じ単語にしろ」ってのと同じことだ。 846 名前：デフォルトの名無しさん mailto:sage [04/12/22 17:51:39] >>842 > そんなのは漢字に限った話ではない。 > あくまでオプションだというのがUnicodeの考え方だろ。 設計がダメダメなんだよ。検索の適合率(precision)を考えたことがあるのか? 847 名前：デフォルトの名無しさん mailto:sage [04/12/22 17:53:57] >>845 たとえが不適切。問題外。「同じ単語にしろ」ってのは、 ごく初期の誤解だらけのUnicode批判に見られた言い方と同じ。 848 名前：デフォルトの名無しさん mailto:sage [04/12/22 17:55:01] >>847 それは反論になっていないが。 849 名前：デフォルトの名無しさん mailto:sage [04/12/22 17:56:43] >>846 >検索の適合率(precision)を考えたことがあるのか? もうちょい具体的に頼む。 850 名前：デフォルトの名無しさん mailto:sage [04/12/22 17:59:29] >>849 適合率と再現率を知らないなら、 www.internetclub.ne.jp/EASY/20030204.html ここの最初を読んで。 それをふまえて、 「言語情報の無いUnicodeなテキストから検索をしたときに、別の言語の漢字がひっかかってしまい、 適合率が下がる」 851 名前：デフォルトの名無しさん mailto:sage [04/12/22 18:10:16] そもそも漢字の統合にもっともな理由があるなら、ここまで「Unicodeの設計はクソ」なんて言わない。 # それでもかなりまずいが。 もともとは「全ての文字を16ビットに収めたい」という、無謀な考えから始まったもの。 おかげで日本人はかなり割を食う羽目になってしまった。 中国は乱暴だが賢明だ。 GB18030で文字集合のコントロールを自国に取り戻し、すくなくとも中国語は検索・表示できるようにした。 852 名前：デフォルトの名無しさん mailto:sage [04/12/22 18:13:27] >>850 すでに書いたことの繰り返しになるけどさ、 言語情報のあるのとないのを比べたら、あるほうが高機能に決まってる。 だからといって情報量をとにかく増やせばいいってもんじゃないだろ。 要はプレーンテキストをどの程度コンパクトなものにするかについての 考え方の違い。 853 名前：デフォルトの名無しさん mailto:sage [04/12/22 18:16:16] >>851 韓国もひどい話で、最初は母音・子音の合成でOKだと言っていたのに、合成文字のサポートに不安をおぼえたのか 後から全文字追加させるし。結果、16ビットの幻想崩壊の引き金になった。 854 名前：デフォルトの名無しさん mailto:sage [04/12/22 18:22:43] >>852 その考え方は、「中国語と日本語の漢字は同じ文字で、違いは属性で表せる」という考えが基盤になっているね。 こっちは、「そもそも別の文字だ」と言っている。 855 名前：デフォルトの名無しさん mailto:sage [04/12/22 18:26:55] >>854 そゆこと。 856 名前：852 mailto:sage [04/12/22 18:29:21] まぎらわしいコメントだったので名前欄に入れてもう一度。 >>854 そゆこと。 857 名前：デフォルトの名無しさん [04/12/22 19:12:30] まー、漢字ぐらいなら可愛い問題だな。 ハイフンとか地獄だぞ。 858 名前：デフォルトの名無しさん mailto:sage [04/12/22 19:22:58] >>857 あれは笑えるな。あと有名なのは鉛筆ネタか? 「漢字はUnifyしちゃうけど、ベンダの文字はどれだけ似てても別にする」という、これまた初期Unicode推進者の 頭の悪さを露呈するような内容。 でもJIS X 0208の丸も良い勝負だったりする。 ○←丸印 ◯←大きな丸(合成用丸) おまけ: 〇←漢数字ゼロ 859 名前：デフォルトの名無しさん mailto:sage [04/12/22 19:47:40] >>854 意味が違う字の包摂なんてJISでもやっちゃってるじゃん。柿とか。 860 名前：デフォルトの名無しさん mailto:sage [04/12/22 20:46:07] だからTRONコードにしろって 861 名前：デフォルトの名無しさん mailto:sage [04/12/22 20:53:36] >>821 文字コードの指定と言語の指定は基本的に無関係。 www.asahi-net.or.jp/~wq6k-yn/lang.html >>828 ほんの一例を挙げるとWindowsやMacでEUCのWebページを見ている場合とか。 誰かMicrosoftとAppleをクビにして国産PCにはBTRON採用を義務付けてください。 なんて絵空事は置いといて >>833 なんか妙な方向に話が行ってるけど可逆性が保証できないのはISO 2022の「仕様」。 GBとJISの使い分けで「骨」のカギの向きを区別できると考えるのは JIS X 0201と0208の使い分けで「全角」と「半角」を区別できると考えるのと 同じくらい間違ってる。 逆に内部ISO 2022系で外部UCSという場合もありうる。Unicode化されてない テキストエディタでUTF-8を入出力する場合とか。内部コードに変換できない Unicodeの文字は可逆にならないけどそれもISO 10646の「仕様」。 >>845 「make」が「負け」なのか「作る」なのかは言語情報なしでは判別できない。 JIS X 0201だったら前者でUS-ASCIIだったら後者ですかまさか >>859 それどころかnon cognate ruleがあるUnicodeならunifyされない字もJISだと 包摂されちゃう。 862 名前：デフォルトの名無しさん mailto:sage [04/12/22 20:59:28] そんな中、颯爽とUnicode 4.1.0β登場ですよ。 863 名前：862 mailto:sage [04/12/22 21:18:46] なんとなく日本人に関係ありそうなとこだけ独断と偏見で挙げるね。 ソースはUnicodeData-4.0.1,txtと同-4.1.0d8.txtを比較しただけ。 もっといろいろ詳しく知りたいなら本家Unicode.orgを参照のこと。 追加: 　31C0..31CF CJK BASIC STROKE 　9FA6..9FBB CJK UNIFIED IDEOGRAPH 　FA70..FAD9 CJK COMPATIBILITY IDEOGRAPH 　FE10..FE19 PRESENTATION FORM FOR VERTICAL CHARACTER 変更: 　30FB KATAKANA MIDDLE DOT : General Category Pc->Po 　FF0F FULLWIDTH SOLIDUS : Bidi Class ES->CS 　FF65 HALFWIDTH KATAKANA MIDDLE DOT : General Category Pc->Po 864 名前：デフォルトの名無しさん mailto:sage [04/12/22 21:23:55] >>861 > GBとJISの使い分けで「骨」のカギの向きを区別できると考えるのは > JIS X 0201と0208の使い分けで「全角」と「半角」を区別できると考えるのと > 同じくらい間違ってる。 それはすでに同じ文字として見なしているからであって、別の文字だという主張に対する反論になっていない。 865 名前：デフォルトの名無しさん mailto:sage [04/12/22 21:30:46] >>861 > 「make」が「負け」なのか「作る」なのかは言語情報なしでは判別できない。 > JIS X 0201だったら前者でUS-ASCIIだったら後者ですかまさか 無いところから生成する必要はない。 必要な物を捨てていると言っている。 > それどころかnon cognate ruleがあるUnicodeならunifyされない字もJISだと > 包摂されちゃう。 何を指しているのか思いつかない。例はある? 866 名前：デフォルトの名無しさん mailto:sage [04/12/23 22:22:57] スレタイとはなれてる気もするが良スレの予感 :-) 867 名前：デフォルトの名無しさん mailto:sage [04/12/23 23:44:01] 文字コード関係スレは常に糞スレから始まって、 知識の鎬合いスレと化する。 868 名前：デフォルトの名無しさん mailto:sage [04/12/24 14:41:28] >>864 参考までに聞いておきたいんだが、お前さんの「主張」だと 以下のうち「別の文字」となるのはどのケースかな？ 1. GB 2312の「一」とJIS X 0208の「一」 2. GB 2312の「骨」とGB 12345の「骨」 3. GB 2312の「骨」とCNS 11643の「骨」 4. CNS 11643の「骨」とKS X 1001の「骨」 869 名前：デフォルトの名無しさん mailto:sage [04/12/24 15:30:48] A Ａ Α А 上記4つは、JISコードではそれぞれ別のコードが割り当てられているし Unicodeでも別のコードが割り当てられている。 しかも4つのどれもが、「アルファベット大文字の1番目」 ていうか俺にも万人が納得できる解がどれなのか判断つかねっ 870 名前：デフォルトの名無しさん mailto:sage [04/12/24 15:33:33] それぞれの相反する解に支持者がいる以上、 万人が納得する解はあり得ないと思われ。 871 名前：デフォルトの名無しさん mailto:sage [04/12/24 15:51:17] >>869 0201の「A」を一緒にすんなよ。 872 名前：デフォルトの名無しさん mailto:sage [04/12/24 19:30:11] >>869 > ていうか俺にも万人が納得できる解がどれなのか判断つかねっ 包括的な解はともかく、個々の文字の選択場面でも既に問題が出ている。 Mac OS Xの"コトエリ"は、-を入力して変換すると、 横棒系の文字を大量に候補に出す。 起動環境を日本語環境にしてあってもEN DASHが候補に含まれている。 ただ、こういう雑多な問題は、ここ数年になんとか解決するかも知れない。 ・UTF-8への移行が一気に進む、あるいは ・日本語環境の起動においては、JISに含まれない文字を選択肢に出さない など。 873 名前：デフォルトの名無しさん mailto:sage [04/12/24 22:48:25] Unicodeの設計が嫌いな俺様が来ましたよ。 >>868 コンテキストより、Shift JISであると仮定する。後付けの明文化だが、文字集合はJIS X 0201とJIS X 0208とする。 # ここで「いやCP932だ」とか「普通ASCII」などは話がそれるので勘弁。 (1) A……JIS X 0201の「LATIN CAPITAL LETTER A」 (2) Ａ……JIS X 0208の「LATIN CAPITAL LETTER A」 (3) Α……JIS X 0208の「GREEK CAPITAL LETTER ALPHA」 (4) А……JIS X 0208の「CYRILLIC CAPITAL LETTER A」 (1)と(2)は同じ文字、(1)≠(3)、(1)≠(4)。 # (2)を慣用的な利用との互換として「FULLWIDTH LATIN CAPITAL LETTER A」とみなせば全部別の文字だが、 # それはあくまで例外である。 > Unicodeでも別のコードが割り当てられている。 Unicodeも(1)と(2)を別の文字とみなす事は出来る。しかしUnicode StandardもJISと同じく 「(FULL|HALF)WIDTHは慣用的な利用との互換のため、こんなの使わずに文字幅は上位レイヤーでやれ」 という立場。これは >>861 の人も触れているね。 > JIS X 0201と0208の使い分けで「全角」と「半角」を区別できると考えるのと > 同じくらい間違ってる。 874 名前：873 mailto:sage [04/12/24 23:03:14] ここで、話の流れが分かっていない人が 「JIS X 0208では漢字に『CJK UNIFIED IDEOGRAPH-*』という名前が付いているんだから、unifyには問題ない」 という反論をするかも知れないのであらかじめ書いておく。 >>864 で書いたが、それはすでにunifyしてしまったためにそういう名前がついているわけだ。 俺は「UnicodeのCJK Unificationは設計としておかしかった」と言っているわけ。 unifyの損失についてはすでに書いた( >>835 >>837 >>850 )。 それに対し、unifyの唯一の理由は「Unicodeを16ビットに収めるため」という、今考えてみれば頭が痛くなるような理由。 # もちろん、あの当時でも分かっている人たちは反対していた。 875 名前：デフォルトの名無しさん mailto:sage [04/12/24 23:30:52] >>874 漢字も基本的にアルファベットと見なせると思うけど。カタカナ「ロ」と漢字 の「口」はアルファベットとして違うからunifyできない。でも日本語として の「骨」と中国語としての「骨」はアルファベットとして同じだからunifyで きる。英語のAとフランス語のAがunifyできるのと同じように。「骨」という 記号そのものに言語情報は含まれていないのではないか。言語情報は後から附 加するものだと思う。 876 名前：デフォルトの名無しさん mailto:sage [04/12/24 23:41:34] >>875 > の「骨」と中国語としての「骨」はアルファベットとして同じだから そうなの? >>873 の (1) と (3) のような関係じゃないかと思うんだけど。 877 名前：デフォルトの名無しさん mailto:sage [04/12/24 23:43:07] グリフも少し違うからcapitalじゃなくて小文字のaとαかな。 878 名前：デフォルトの名無しさん mailto:sage [04/12/24 23:44:16] (1)と(3)というよりは(1)と(4)かも。 879 名前：デフォルトの名無しさん mailto:sage [04/12/24 23:50:02] ふーん。 とあるローカルな符号化方式で符号化された既存データとの相互変換で、バイトストリーム的に ロスレスに元に戻せるという可逆性については皆さん案外重視してないんですね・・・ 実際に世にある既存システムでは、全角半角が入れ替わったりしたらそれなりに問題視される ケースもあると思うけど・・気のせいかも知れない。 880 名前：デフォルトの名無しさん mailto:sage [04/12/24 23:56:46] いや、localなcoding systemに変換するmailerでPGPとかまるで駄目でしょ。 WindowsやMacはShift_JISに変換してfolderに保存するの多いけど。 881 名前：デフォルトの名無しさん mailto:sage [04/12/25 02:31:48] >>875 > でも日本語としての「骨」と中国語としての「骨」はアルファベットとして同じだから そう、ここなんだよね。 Unicodeのunifyを知らなかったら、ほとんどの日本人は「別の文字」と見なしていると思うんだけどな。 なまじunifyされた現状を知っているから、同じ文字だと思いこんでるだけで。 882 名前：デフォルトの名無しさん mailto:sage [04/12/25 02:57:28] >>881 少なくともunifyは意味によってするわけじゃない もちろんグリフでもない 883 名前：デフォルトの名無しさん mailto:sage [04/12/25 03:24:34] >>882 意味によってunifyしたのもあるし、グリフのみでunifyしちゃったのもあるが。 884 名前：デフォルトの名無しさん mailto:sage [04/12/25 03:29:41] >>883 どのような基準でunifyすべきだと思う？ 885 名前：デフォルトの名無しさん mailto:sage [04/12/25 03:39:27] 意味でunifyするなら日本語の母と中国語の娘みたいなのも全部unifyされるんだろうな グリフでもunifyしたらロも口も□も同じになるんだろうな やっぱunicodeは支持できない 886 名前：デフォルトの名無しさん mailto:sage [04/12/25 17:58:13] >>872 EN DASHはJIS X 0213に含まれてる(3区92点)から日本語環境で出てきておっけー。 JIS X 0213は伊達にEN DASHを含んでいる訳ではなく、「校正必携」を典拠と して (規格票 p.304)、現代日本で使われている記号として収録している。 887 名前：デフォルトの名無しさん mailto:sage [04/12/25 18:09:14] そだね。けど、ISO-2022-JPに含まれないから、 日本語環境だとtext/plain; charset=UTF-8にすべきだとおもうけど、 GB2312になっちゃうんだよ。Mail.appでさ。 0213使ったEUC系にする方法もあると思うけど、 メーラだからUTF-8が一般的だよね。 888 名前：デフォルトの名無しさん mailto:sage [04/12/26 02:43:09] >>872 ことえりはOSXのずっと前からUnicodeベースのインプットメソッドに なっている。クライアントアプリケーションがUnicodeを扱えればその まま渡すし、Shift_JISベースなら変換して渡す。 OSXでShift_JISベースのアプリに対してはEN DASHは候補には上がる が、入力はできないと明示される。 >>887 それはMail.appの使い方次第、System Preferences/Internationalで のLanguagesの設定も優先使用するencodingに影響する。 889 名前：デフォルトの名無しさん mailto:sage [04/12/26 11:55:15] >>885 ・文字は本質的に視覚的存在であり、個別具体的な字形を抽象化した概念である。 ・文字はある表記系(script)の中における差異によって特定される。 ・表記系が異なれば形が同一に見えても別の文字とみなす。 従って、形に基づいて包摂するのは正しい。 しかしその包摂は表記系をまたがることはできない。(例: ロと口は包摂不可) また、同一表記系の中で区別される形の差異は包摂できない。(例: 土と士は包摂不可) ここで困難なのは、表記系の中で「同じ文字」とみなされる区別が必ずしも 文字の使用者の間で合意されないケースがあること。例えば「骨」問題。 「とにかく分けちゃえ」という意見もあるが(坂村健)、分離したらしたで、「骨」 のカギの部分を「人」の形に作った書き方をどちらで符号化したら良いかという 問題が生じ、きりがない。 ここまでくると、文字コードという技術的な問題ではなく、言語学的、文献学的 問題になる。西洋近代の言語学は文字を単なる音の移しとしか見なかったため、 文字の研究は遅れている。 890 名前：デフォルトの名無しさん mailto:sage [04/12/26 11:56:07] 日本語の「谷」（たに）と中国語（簡体字）の「谷」（≒日本語の「穀」）のようなものも 「グリフでunify」になってしまうのだろうか？ 891 名前：デフォルトの名無しさん mailto:sage [04/12/26 12:12:14] 「意味の違いを無視してグリフでunify」と「グリフの違いを無視して意味でunify」の 2つがあることが問題なのかな？ Unicodeに限った問題ではなく、JIS X 0208でもある問題だけど。 892 名前：デフォルトの名無しさん mailto:sage [04/12/26 13:58:57] >>889 表記系なんてものはないよ。別に日本語が漢字とひらがなとかたかなで表記さ れなければならない義理はない。ローマ字で表記しようが、ヘブライ文字で表 記しようが、全く新しい文字を作り出して表記しても日本語は日本語だ。 893 名前：Unicodeの設計が嫌いな人 mailto:sage [04/12/26 16:14:24] >>889 > ここまでくると、文字コードという技術的な問題ではなく、言語学的、文献学的 > 問題になる。西洋近代の言語学は文字を単なる音の移しとしか見なかったため、 > 文字の研究は遅れている。 表音文字だけを使ってきた人たちには、表意表音文字を本質的には理解出来ないだろうね。 漢字なんてしょせん絵文字程度としか思っていない。 これは別にけなしているわけではなく、人は未知なるものを理解する事は非常に困難だからだ。 Unicodeの問題点を俺なりに総括すると、「文化の領域に踏み込みすぎた」という事だな。 unifyなんて必要なら後からやればいいんだよ。テーブル引くだけなんだから。 逆にいったんunifyしちゃうと分離はほとんど不可能なんだし。 あと正規化も同様。文脈によって全然違うんだから、わざわざ泥沼に入らんでもいいのに。 894 名前：デフォルトの名無しさん mailto:sage [04/12/26 18:07:24] >>893 ラテン文字＝表音文字、漢字＝表意文字という図式に凝り固まりすぎなんじゃないの？ 漢字だって表音的に使われることだって山ほどあるだろ？ ラテン文字一つ一つに意味を持たせる場合だってあるだろ。 > 表音文字だけを使ってきた人たちには、表意表音文字を本質的には理解出来ないだろうね。 んなことない。バカにしすぎ。 895 名前：デフォルトの名無しさん mailto:sage [04/12/26 18:22:55] >>894 > 漢字だって表音的に使われることだって山ほどあるだろ？ 当たり前だ。>>893 で表意表音文字と書いてるだろ。 > ラテン文字一つ一つに意味を持たせる場合だってあるだろ。 はいはい、例外を出して一般化しないようにね。 確かにaは最初、zは最後、という風に文字自身に意味を持たせる文脈はある。 しかしそんなことを考えながら単語から成る文章を理解するのか? > んなことない。バカにしすぎ。 こう誤解されそうだから、>>893 でわざわざ書いたのにな。読んでないのか? 相手が理解出来ないからこそ、表意文字を使う人たちはきちんと意見を伝える必要があるんだよ。 もちろん礼儀を持ってね。別に相手は悪意がある訳じゃないんだから。 896 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:55:34] >>895 > はいはい、例外を出して一般化しないようにね。 別に一般化などしていない。ラテン文字＝表音文字、漢字＝表意文字という一 般化はできないということだけを言っているわけ。漢字が表音表意文字ならラ テン文字、その他の文字だって表音表意文字だ。 多分あなたは文字というものを言語に一対一に対応するようなものだと考えて いる。例えば日本語と中国語は別言語だから日本語の文字である「骨」と中国 語の「骨」は別の文字である。だからunifyすべきじゃない、というような。 こういう意見には賛成できない。 897 名前：デフォルトの名無しさん mailto:sage [04/12/26 20:59:43] ﾏﾀｰﾘ砲発射！ _|￣| (((●ｺﾛｺﾛ 898 名前：デフォルトの名無しさん mailto:sage [04/12/26 21:04:27] >>896 > 漢字が表音表意文字ならラテン文字、その他の文字だって表音表意文字だ。 意味が分からん。解説よろしく。 > 多分あなたは文字というものを言語に一対一に対応するようなものだと考えて > いる。 そんな単純ではないんだが。今まで書いたのからそう読めるんだろうか。 > こういう意見には賛成できない。 なぜ? 899 名前：デフォルトの名無しさん mailto:sage [04/12/26 21:16:48] >>898 > 意味が分からん。解説よろしく。 自分で「確かにaは最初、zは最後、という風に文字自身に意味を持たせる文脈はある。」などと書いてるじゃないか。 ヘブライ文字や梵字も表意的に使わることがある。その他いろいろあるだろう。 要するにすべての文字は表意的にも表音的にも使われることがあるということ。 > そんな単純ではないんだが。今まで書いたのからそう読めるんだろうか。 「骨」に関しては「日本語と中国語は別言語だから日本語の文字である「骨」 と中国語の「骨」は別の文字である。だからunifyすべきじゃない」というこ とだろ？ 900 名前：デフォルトの名無しさん mailto:sage [04/12/26 22:41:50] >>899 > 要するにすべての文字は表意的にも表音的にも使われることがあるということ。 おいおい……。>>895 は読んでくれた? 「しかしそんなことを考えながら単語から成る文章を理解するのか?」と続いてるんですけど。 > 「骨」に関しては「日本語と中国語は別言語だから日本語の文字である「骨」 > と中国語の「骨」は別の文字である。だからunifyすべきじゃない」ということだろ？ あのねえ、そんな単純じゃないんだよ。 そういう考え方*も*あるし、実用的・技術的な面から見ても問題点がある。そのへんはもう書いた。 テーブルを作ってしまえばunifyするのはすごく簡単なことだ。しかし逆変換はほぼ不可能。 そしてunifyの理由であった「Unicodeを16ビットにおさめる」は、とっくに破綻している。 よってUnicodeの設計はダメダメですね、という話なんだが。 901 名前：デフォルトの名無しさん mailto:sage [04/12/26 23:03:58] >>900 > 「しかしそんなことを考えながら単語から成る文章を理解するのか?」と続いてるんですけど。 言語の原理的なことを言っているわけ。ラテン文字＝表音文字、漢字＝表意文 字ということはないということが伝わればそれでいい。 > そういう考え方*も*あるし、実用的・技術的な面から見ても問題点がある。そのへんはもう書いた。 unifyのことを言っている。「骨」をunifyするべきじゃないのは「そういう考え方」に基くんだろう？ 文字の「義」が違うからunify不能だと。 > テーブルを作ってしまえばunifyするのはすごく簡単なことだ。しかし逆変換はほぼ不可能。 逆変換などする必要はない。Aを英語とフランス語とに区別する必要がないという意味で。 言語＝文字の集合じゃない。 > よってUnicodeの設計はダメダメですね、という話なんだが。 設計にはいろいろ無理があることは知っている。ただ多くの文字を統一的に扱 かおうとすること、それにともなうunifyには賛同できる。 # キリがないのでこの辺で 902 名前：デフォルトの名無しさん mailto:sage [04/12/26 23:22:08] >>901 > # キリがないのでこの辺で 正直俺もこの辺で切り上げたい。 なぜなら、「同じ文字かどうか」というのは多分に文化的な問題だからだ。 これは専門の人が一生かけて一文字包摂できるかどうかというレベルの話だと思うし、軽々しく扱うのは畏れ多いことだ。 # HALFWIDTH、FULLWIDTHは別。あれには俺は文化的なものを見いだしていない。 # あんな恥ずかしい区別、さっさと捨ててしまうべきだ。 だからこそいったんunifyしてしまうと、その区別はもう二度と取り戻せないわけで、逆変換不能なunifyを Unicodeが軽々しくやってしまったのは完全に失敗だ。 903 名前：デフォルトの名無しさん mailto:sage [04/12/26 23:31:45] >>901 でもまぁ、せっかく書いてくれたんだし返事はしよう。 > 言語の原理的なことを言っているわけ。ラテン文字＝表音文字、漢字＝表意文字と > いうことはないということが伝わればそれでいい。 一般的には「ラテン文字=表音文字、漢字=(表音)表意文字」だが。 あくまで例外としてラテン文字に表意を持たせることがあるという程度。 たとえば普通、文章中に"text"という単語が出てきた場合、t, e, x, tのそれぞれの文字に意味は無いだろう。 しかし「文章」という言葉の場合は、二つの文字に意味があり、そこから単語の意味が組み立てられているわけだ。 > 文字の「義」が違うからunify不能だと。 だから違うって。ブール代数とか苦手な人? 命題が真な時、逆も裏も真とは限らないんだよ。 904 名前：デフォルトの名無しさん mailto:sage [04/12/26 23:37:18] ちょっと横槍だけど >>902 ># HALFWIDTH、FULLWIDTHは別。あれには俺は文化的なものを見いだしていない。 ># あんな恥ずかしい区別、さっさと捨ててしまうべきだ。 もう既に絵文字と言う文化ができてるから、 俺的には残ってもいいんじゃないかなぁと思ってる。 確かに技術的にはテキストでイメージを表現しようとするのは 間違った事かもしれんけどここまで発展した絵文字が失われるのは惜しい。 905 名前：デフォルトの名無しさん mailto:sage [04/12/26 23:54:43] >>904 君が引用している部分は、 「一応書かないとまたアホが全角半角言い出すからなぁ。でもこの部分には返事が付かないといいな」 と思いながら書いた。 > もう既に絵文字と言う文化ができてるから、 > 俺的には残ってもいいんじゃないかなぁと思ってる。 戦争でも起こらん限り、駆逐は難しいね。 906 名前：デフォルトの名無しさん mailto:sage [04/12/27 00:02:11] FULL, HALFは互換のために仕方ないだろ。 もしUnicode的になくしたとしたら、FULLの方をなくしたわけだろうけど、 今以上にアンチUnicodeの嵐になっているぞ。 ただこういう疵をUnicodeは新たに作ってしまったな。 # JIS 1978→1982や補助漢字も凄いけどな。 907 名前：905 mailto:sage [04/12/27 00:17:52] >>906 言ってる内容は概ねその通りだが、 > もしUnicode的になくしたとしたら、FULLの方をなくしたわけだろうけど、 これは違うよ。互換用のだけ「FULLWIDTH」「HALFWIDTH」が付いてる。 「HALFWIDTH KATAKANA LETTER A」……JIS X 0201由来の「ア」 「FULLWIDTH QUESTION MARK」……JIS X 0208由来の「?」 908 名前：906 mailto:sage [04/12/27 00:39:00] ああ、俺は「FULLの方」っていうのはグリフの事を言ってしまっていたよ。 909 名前：デフォルトの名無しさん mailto:sage [04/12/27 11:50:43] ところで>>868に答える人はいないのか？ 910 名前：デフォルトの名無しさん mailto:sage [04/12/27 13:02:29] >>909 1〜4、全て別。 911 名前：デフォルトの名無しさん mailto:sage [04/12/27 16:14:10] >>910　0点 912 名前：デフォルトの名無しさん mailto:sage [04/12/27 17:00:28] ㍘ 913 名前：デフォルトの名無しさん mailto:sage [04/12/27 17:02:38] >>910 満点 914 名前：デフォルトの名無しさん [05/01/08 16:40:28] 結局、32ビットコードの文字集合を新たに製作して、そこに文字を 「グリフが違えばすべて違う文字と考える」 ように収録するのが最も一般的な解決方法だろうか？ AdobeのCIDは「グリフが違えばすべて違う文字と考える」考え方だよね。 それを全言語・全文字に拡張すれば… 915 名前：デフォルトの名無しさん mailto:sage [05/01/08 22:12:17] それだと使うときかなり困ると思うけど…… 現状でも満足になされていない、ハイフン類の使い分け問題みたいなのが もっと拡大するので、ただ書くだけならいいけど、機械処理に困る。 916 名前：デフォルトの名無しさん mailto:sage [05/01/09 11:41:02] >>914 それ「超漢字」じゃん。 917 名前：デフォルトの名無しさん [05/01/10 11:26:36] 龍龍 龍龍 ↑これユニコードに入ってたっけ？ 918 名前：デフォルトの名無しさん [05/01/10 16:29:18] >>917 U+2A6A5 www.unicode.org/cgi-bin/GetUnihanData.pl?codepoint=2A6A5 919 名前：デフォルトの名無しさん mailto:sage [05/01/10 16:40:31] 助かりました。まさか入っているとは。 920 名前：デフォルトの名無しさん [05/01/10 16:53:10] 興*4はないっぽいけどね。Simsun (Founder Extended)入れとけば楽に探せる。 921 名前：デフォルトの名無しさん mailto:sage [05/01/10 21:41:37] ていうかUnihan Radical-Stroke Index使って自分で探せるようになると便利よ。 ttp://www.unicode.org/charts/unihanrsindex.html 知らない人のために簡単に説明。知ってる人は読み飛ばして下せぇ。 ・Strokes in radical: 部首の画数を選択 ・Minimum & Maximum: 探したい漢字の(部首を除いた)最小画数と最大画数を選択 ・Use UTF-8: 漢字の画像を表示するか自分のマシンのフォントで表示するか選択 ・部首の画像から検索したい部首をひとつ選択 ・submit後、一覧から目的の漢字をみつけてクリック→詳細情報 どこから来た漢字なのかや、各国での読み、異体字とか色々載ってるんで、 文字コード関係以外の時でも結構使えます。 922 名前：デフォルトの名無しさん mailto:�dパ文字もあるのか？ [05/01/11 13:51:16] ありがとうございます。そんな便利なものがあったのですね。 これから活用します。 923 名前：デフォルトの名無しさん mailto:sage [05/01/11 14:29:09] >>915 >>914 漢字だけに関して言えば [ロケールコード][文字コード][異体字(グリフバリエーション?)番号] がビット固定長で並んでるのが理想だと思う。 検索するときは異体字コードはマスクして無視するとか。 ただ、世の中にはリガチャしまくりで「どこからどこまでを１文字とするか」 が立場や処理によって変わる文字とかいろいろあるからなぁ、、 UNICODEのフル実装は個人や１企業の手に余る気がする、、、 フォントやPnPのドライバみたくオンデマンドで 必要なロケールの処理モジュールをダウンロードすればすむ様な 仕組みはできないものか。 それがロケール単位でいいのかって議論もあろうけども。 924 名前：デフォルトの名無しさん mailto:sage [05/01/11 14:39:57] トンパはない。 925 名前：デフォルトの名無しさん mailto:sage [05/01/11 15:30:18] ちょっと気になったのだが。 龍龍 龍龍 U+2A6A5だから、これはUCS-4で定義される文字になるわけですね。 ちょっと古い記事などを読むと、UCS-4で群00面00（=UCS-2）以外には まだ文字は配置されていない、とか書いてあるが、現在、既に配置は 始まっているということなのか？ 926 名前：デフォルトの名無しさん mailto:sage [05/01/11 16:14:22] Unicode 3.1.0で初めてBMP外に配置された。 詳しくはDerivedAge.txtを参照のこと。 927 名前：デフォルトの名無しさん mailto:sage [05/01/11 19:57:55] >>921 おぉぅ、興*4あったわ（U+2053B）。ｽﾏｿ 928 名前：デフォルトの名無しさん mailto:sage [05/01/11 22:11:18] CJK Unified Ideographs Extension B を眺めてると結構楽しいな 変な漢字があったりとかして 929 名前：デフォルトの名無しさん mailto:sage [05/01/12 00:35:53] 書き順が想像付かないやつとか普通の漢字にはありえない曲線とかあるなｗ 930 名前：デフォルトの名無しさん mailto:sage [05/01/12 00:50:08] >>925 > UCS-4で定義される文字になるわけですね 「UCS-4で表現されうる文字になるわけですね」が正しい、と突っ込んでみる 931 名前：デフォルトの名無しさん mailto:sage [05/01/13 07:03:17] >>864 > それはすでに同じ文字として見なしているからであって、別の文字だという主張に対する反論になっていない。 だってISO 2022はそういう仕様だって言ってるだけだもん。 あくまで別の文字だと主張して区別したい人にとってもはやISO 2022は使い物にならない。 それこそ鎖国してTRON使わせるくらいしか道はない。 # 話の枕は「unicode以上に国際的な文字コード」なのにどうして「鎖国」って結論になるんだ そもそも何を根拠に別の文字だって主張してるのか謎なんだけど 932 名前：デフォルトの名無しさん mailto:sage [05/01/13 07:03:34] >>865 > 何を指しているのか思いつかない。例はある? >>859 つーか97JISの解説嫁。類型異字でもかまわず包摂しますが何か? と高らかに 宣言してるぞ 933 名前：デフォルトの名無しさん mailto:sage [05/01/13 07:04:00] >>874 > 俺は「UnicodeのCJK Unificationは設計としておかしかった」と言っているわけ。 何も考えないで丸ごと詰め込むほうが設計としておかしい。 > unifyの損失についてはすでに書いた( >>835 >>837 >>850 )。 だからLATIN SMALL LETTERをUnifyしたらプレーンテキストで「make」の検索も 翻訳もできない。 > もちろん読み上げもできない。 グリフがまったく同じでも読みごとに別のコードを振るべきだと思う? <丶｀∀´>＜思うニダ > それに対し、unifyの唯一の理由は「Unicodeを16ビットに収めるため」という、 > 今考えてみれば頭が痛くなるような理由。 アメリカ人はもっと凄いこと言ってたようだけど。 www2.xml.gr.jp/log.html?MLID=xmlmoji&N=1553 統合漢字の原案(HCC)を出したのは中国。 934 名前：デフォルトの名無しさん mailto:sage [05/01/13 07:04:24] >>876 > そうなの? > >>873 の (1) と (3) のような関係じゃないかと思うんだけど。 日本人は日本の漢字で漢文を書くし中国人は古典も簡体字化してる。 違うスクリプトとは思えない(むろん言語は違う)。 935 名前：デフォルトの名無しさん mailto:sage [05/01/13 07:04:40] >>881 > Unicodeのunifyを知らなかったら、ほとんどの日本人は「別の文字」と見なしていると思うんだけどな。 そりゃ漢字の知識がないだけ。ほとんどの中国人は「同じ文字」とみなす。 アルファベットの知識がなかったら2種類の「g」が違う文字に見えるかもしれない。 936 名前：デフォルトの名無しさん mailto:sage [05/01/13 07:04:52] >>880 むしろNormalizatinしないで署名したりダイジェスト作ったりするのがだめ。 「必要なら後からテーブル引いてUnifyすればいい」という発想だと そのときどんなテーブル使ってたのか分からないと署名の検証ができなくなる。 937 名前：デフォルトの名無しさん mailto:sage [05/01/13 10:08:13] >>936 binaryに対する署名のようにAS ISでいいじゃん。 PGP/MIMEなんかでは、canonicalizationって言ってもline endingだけだし。 938 名前：デフォルトの名無しさん mailto:sage [05/01/13 11:22:57 ID:??? BE:21439837- ] >>935 確かに、日本人であっても2種類の「骨」が「別の文字」に見える人は「漢字の知識」がないと 言われても仕方ないかもしれない。「別の字体」に見える、ならまだしも。 下を丸める「g」と下を丸めない「g」も「別の文字」に見える人は「アルファベットの知識」がないと 言われても仕方がないと思うが、「別の字体」に見えるというのなら「アルファベットの知識」が ないとは言い切れない。 939 名前：デフォルトの名無しさん mailto:sage [05/01/13 11:37:03 ID:??? BE:30627465- ] >>923 以下、[ ]で囲ったのは実際にはそれぞれがビットを表していると考えてほしい。 「辺」を表すのが[日本語][辺][異体字0]で、 「邊」を表すのが[日本語][辺][異体字1]で、 「邉」を表すのが[日本語][辺][異体字2]で(以下ry みたいな構成がいいということになるのかな? 繁体字中国語では 「邊」を表すのが[繁体字中国語][邊][異体字0]で、 簡体字中国語では 「しんにょう+力」を表すのが[簡体字中国語][しんにょう+力][異体字0]で…となるのかな? 異体字ビットは何ビットくらいあれば必要十分なんだろうか? 1文字につき2^6=64くらいかな? 940 名前：デフォルトの名無しさん mailto:sage [05/01/13 15:32:45] > 異体字ビットは何ビットくらいあれば必要十分なんだろうか? 実際やるとしたら、UnicodeのVariation Selectorを使うのが現実解かなぁ……。 FE00-FE0Fの16コードポイントでCJKV等の言語を割り当てて、 E0100-E01EFの240コードポイントで言語ごとに字形テーブルとノーマライズを標準化する。 941 名前：363 [05/01/18 14:57:09 ] すみません。シェルの中における漢字の文字コード についてなのですが二つのシェルにおいて同じマシン で同じ漢字書いたとき文字コードがかわるという こはあるんでしょうか？実際一方では動作して、 もう一方では動作しないという現象が起きてしまって いるのです。この問題に対しての解決方法があれば どなたかおしえていただけないでしょうか？ お願いします。 942 名前：デフォルトの名無しさん mailto:sage [05/01/18 15:26:16 ] 何をやったのかを、第三者にも分かるように書かないと。 とりあえず、2つのシェルの環境変数とかロケールとかは全く同じでも再現する？ 943 名前：デフォルトの名無しさん mailto:sage [05/01/18 15:37:05 ] >>941 ・両者ともにその「漢字」に対応したバイナリかどうか ・ロケール等の環境変数は合っているか ・端末側の文字コードは合っているか とか確認してみてはどうでしょう。 漏れはシェルによって日本語通らなくなったりするのは わりと当たり前って思ってるな・・・ 944 名前：デフォルトの名無しさん mailto:sage [05/01/18 16:06:35 ] 何で漢字テキストを書いたかも書いてないしな。 スレ違いだろ。UNIX板の初心者スレがいいんじゃないの? 945 名前：363 [05/01/18 17:25:01 ] ありがとうございます。わかりづらくてすみません。 自分の今やっていることはテキスト文章の編集をやっていて sedである部分を削除しようと思いsedの中に削除目的の 日本語を入れたところ、うまく消えなかったのです。 cat $f | grep -v '#'| grep -v '^$'| cut -f2- | sed 's/^/<s> /'| sed 's/$/\ <\/s>/'| sed 's/\/読み未登録//g' このような感じで書きました。(ファイル名はtextmake.csh) そこから試行錯誤して理由は良くわからないのですが そのシェルとは別のシェルの中にはじめに作ったシェル を入れ、textmake.csh | sed 's/\/読み未登録//g' このようにしたら上手く削除できたのです。 後で調べてみたら前の最初のシェルはシフトＪＩＳで 後のシェルはeucのコードになっていたみたいだった のです。それでなぜなのだろうと思い。質問したという わけなのです。環境変数などがわからないので調べて みようと思います。 946 名前：デフォルトの名無しさん mailto:sage [05/01/18 17:30:25 ] シェルってシェルスクリプトのことかYO! おじさんビックリだ。 947 名前：デフォルトの名無しさん mailto:sage [05/01/18 17:36:05 ] >>945 シェルスクリプト書いた奴に聞きなよ。 使ったエディタとその環境を。 948 名前：デフォルトの名無しさん mailto:sage [05/01/18 20:14:08 ] > ・シェルスクリプトのことをシェルってゆーな by UNIX板 シェルスクリプト総合スレ >>1 949 名前：363 [05/01/19 10:31:07 ] なんかスレ違いだったみたいかなぁ。すいません！ ありがとうございました。 950 名前：お願いします [05/01/19 10:58:05 ] 論理式eが与えられた時、eと等価なCNFを求める述語cnf/2を定義せよ。 という問題がわかりません。 誰か教えてくれませんか？ 951 名前：デフォルトの名無しさん mailto:sage [05/01/19 11:07:36 ] マルチかつスレ違い。氏ね。 952 名前：デフォルトの名無しさん mailto:sage [05/01/25 13:38:52 ] JIS X 0213にも「異体字を表す制御文字」を追加することができないだろうか？ 確か第1面にも30文字程度の空き区点（バラバラに存在する）があったはずなので、 そこを「異体字を表す区点」にしてしまえば比較的簡単に異体字を表現することができる。 ほとんど使われていないJIS X 0213を捨ててしまって、また別のJIS X 0208上位互換の 文字コード体系を作ればすっきりした体系になるのはわかってはいるのだが、 JIS X 0212でさえ完全には捨て切れない現状を考えると… 953 名前：デフォルトの名無しさん mailto:sage [05/01/25 13:48:59 ] ttp://headlines.yahoo.co.jp/hl?a=20050125-00000401-yom-soci だからどうという程のものでもないがな。 954 名前：デフォルトの名無しさん mailto:sage [05/01/25 14:44:44 ] まぁ現状よりましになるんじゃない？ ていうか今までがひどかったのか。 955 名前：デフォルトの名無しさん mailto:sage [05/01/26 09:44:44 ] JISの中の人は、また包摂の解説→議論やらないといけないね… 956 名前：デフォルトの名無しさん mailto:sage [05/01/26 15:13:00 ] そしてあの包摂基準では国語審議会側やら何やらを納得させられないので(ry 957 名前：デフォルトの名無しさん mailto:sage [05/01/31 18:47:26 ] かなりずれるが 草かんむり、３画に　４画派・大修館書店が「決断」 news.goo.ne.jp/news/asahi/shakai/20050131/K2005013101680.html 　３画か４画か――漢和辞典で長い間、揺れていた「草かんむり」の画数が、 大修館書店が出した「新・漢語林」で３画に変わった。同書店は世界最大の 漢和辞典、諸橋轍次の「大漢和辞典」（１９６０年）を発行している老舗（しにせ）。 中国の古い文書を読もうとする専門家が頼りにする「大漢和」では４画だ。 常用漢字や人名用漢字の３画に追随するのは、「大きな決断」だった。 　「新・漢語林」部首解説によると、草かんむりは、 国語審議会の表外漢字字体表（００年）やＪＩＳ漢字で３画とされ、 明朝体活字は３画で作られている。真ん中が切れた形の４画は 「漢和辞典の見出し字を除いて極めて少ない」という。 　「新・漢語林」編集部の円満字二郎さんは「表外漢字字体表がきっかけで、 電子辞書に搭載するにも３画、４画両方では負担が大きい。 諸般の事情を考えて決断したのに残念ながら反響は全くありません」という。 958 名前：デフォルトの名無しさん mailto:sage [05/01/31 18:48:12 ] > 残念ながら反響は全くありません に少々受けてしまった 959 名前：デフォルトの名無しさん mailto:sage [05/02/04 22:00:42 ] SJISとUnicodeの半角ｶﾅ←→全角カナ変換をする ツールを作りたいんですが、この辺のノウハウに ついての詳しい情報ありませんか？ 半角全角変換のみで、SJISとUNICODEの変換は 必要ないです。 960 名前：デフォルトの名無しさん mailto:sage [05/02/04 23:03:29 ] 以前倪永茂氏のAlgorithmCollectionという有名なホームページに あったな、今は削除されているけど。 961 名前：デフォルトの名無しさん mailto:sage [05/02/04 23:57:52 ] wchar_t Hankaku2Zenkaku(wchar_t wc) { if(wc == L' ') return L'　'; else if(wc < L'ｦ' || wc > L'ﾟ') return wc; else if(wc >= L'ｱ' && wc <= L'ｵ') return L'ア' + (wc - L'ｱ') * 2; else if(wc >= L'ｶ' && wc <= L'ﾁ') return L'カ' + (wc - L'ｶ') * 2; else if(wc >= L'ﾂ' && wc <= L'ﾄ') return L'ツ' + (wc - L'ﾂ') * 2; else if(wc >= L'ﾅ' && wc <= L'ﾉ') return L'ナ' + (wc - L'ﾅ'); else if(wc >= L'ﾊ' && wc <= L'ﾎ') return L'ハ' + (wc - L'ﾊ') * 3; else if(wc >= L'ﾏ' && wc <= L'ﾓ') return L'マ' + (wc - L'ﾏ'); else if(wc >= L'ﾔ' && wc <= L'ﾖ') return L'ヤ' + (wc - L'ﾔ') * 2; else if(wc >= L'ﾗ' && wc <= L'ﾛ') return L'ラ' + (wc - L'ﾗ'); else if(wc == L'ﾜ') return L'ワ'; else if(wc == L'ｦ') return L'ヲ'; else if(wc == L'ﾝ') return L'ン'; else if(wc >= L'ｧ' && wc <= L'ｫ') return L'ァ' + (wc - L'ｧ') * 2; else if(wc >= L'ｬ' && wc <= L'ｮ') return L'ャ' + (wc - L'ｬ') * 2; else if(wc == L'ｯ') return L'ッ'; else if(wc == L'ｰ') return L'ー'; else if(wc == L'ﾞ') return L'゛'; else if(wc == L'ﾟ') return L'゜'; return wc; } 962 名前：デフォルトの名無しさん mailto:sage [05/02/04 23:59:32 ] int Zenkaku2Hankaku(wchar_t wc, wchar_t *ans) { if(wc == L'　'){ *ans = L' '; return 1; } else if(wc == L'ワ'){ *ans = L'ﾜ'; return 1; } else if(wc == L'ヲ'){ *ans = L'ｦ'; return 1; } else if(wc == L'ン'){ *ans = L'ﾝ'; return 1; } else if(wc == L'゛'){ *ans = L'ﾞ'; return 1; } else if(wc == L'゜'){ *ans = L'ﾟ'; return 1; } else if(wc == L'ー'){ *ans = L'ｰ'; return 1; } else if(wc < L'ァ' || wc > L'ロ'){ *ans = wc; return 1; } else if(wc == L'ッ'){ *ans = L'ｯ'; return 1; } else if(wc >= L'ァ' && wc <= L'オ'){ int x = (wc - L'ァ'); *ans = ((x % 2) ? (L'ｱ' + (x / 2)) : (L'ｧ' + (x / 2))); return 1; }else if(wc >= L'カ' && wc <= L'チ'){ int x = (wc - L'カ'); *ans = L'ｶ' + (x / 2); if(x % 2){ *(ans+1) = L'ﾞ'; return 2; }else{ return 1; } 963 名前：デフォルトの名無しさん mailto:sage [05/02/05 00:00:03 ] }else if(wc >= L'ツ' && wc <= L'ト'){ int x = (wc - L'ツ'); *ans = L'ﾂ' + (x / 2); if(x % 2){ *(ans+1) = L'ﾞ'; return 2; }else{ return 1; } }else if(wc >= L'ナ' && wc <= L'ノ'){ *ans = L'ﾅ' + (wc - L'ナ'); return 1; }else if(wc >= L'ハ' && wc <= L'ホ'){ int x = (wc - L'ハ'); *ans = L'ﾊ' + (x / 3); if((x % 3) == 1){ *(ans+1) = L'ﾞ'; return 2; }else if((x % 3) == 2){ *(ans+1) = L'ﾟ'; return 2; }else{ return 1; } }else if(wc >= L'マ' && wc <= L'モ'){ *ans = L'ﾏ' + (wc - L'マ'); return 1; 964 名前：デフォルトの名無しさん mailto:sage [05/02/05 00:00:44 ] }else if(wc >= L'ャ' && wc <= L'ヨ'){ int x = (wc - L'ャ'); *ans = ((x % 2) ? (L'ﾔ' + (x / 2)) : (L'ｬ' + (x / 2))); return 1; }else if(wc >= L'ラ' && wc <= L'ロ'){ *ans = L'ﾗ' + (wc - L'ラ'); return 1; } return 0; } 965 名前：デフォルトの名無しさん [05/02/07 20:54:12 ] >>957 この新漢語林読んだんだけど、なぜか芸亭（ウンテイ）の芸だけが4画で残っているの。 草冠を3画に統一するんだったら、ゲイとウンを餘と余みたいに同一文字の扱いにするか、 「同一字形だけど別字」にしたほうがよいと思ったんだけどなぁ。 966 名前：デフォルトの名無しさん [05/02/15 19:54:00 ] Jcode-1.99_04 make とおりまんた。 かんきょうは OpenBlock S200 , perl 5.6.1 でし。 よかったね。 [a@obss Jcode-1.99_04]$ make test make[1]: Entering directory `/home/a/src/Jcode-1.99_04/Unicode' make[1]: Leaving directory `/home/a/src/Jcode-1.99_04/Unicode' PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib -I/usr/lib/perl5/5.6.1/ppc-linux -I/usr/lib/p erl5/5.6.1 -e 'use Test::Harness qw(&runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t t/append.....ok t/convert....ok t/getcode....ok t/h2z........ok t/length.....ok t/mime.......ok t/new........ok t/perl581....skipped all skipped: Perl 5.8.1 or later required t/regex......skipped all skipped: Perl 5.8.1 or later required t/tr.........ok All tests successful, 2 tests skipped. Files=10, Tests=220, 119 wallclock secs (90.21 cusr + 25.26 csys = 115.47 CPU) make[1]: Entering directory `/home/a/src/Jcode-1.99_04/Unicode' No tests defined for Jcode::Unicode extension. make[1]: Leaving directory `/home/a/src/Jcode-1.99_04/Unicode' [a@obss Jcode-1.99_04]$ 967 名前：デフォルトの名無しさん [05/02/15 21:19:29 ] >>959 窓ならLCMapString 968 名前：デフォルトの名無しさん [05/02/19 01:15:40 ] 学校の宿題教えて禁止 ここのスレはみんなが見てますやめましょう 969 名前：デフォルトの名無しさん [05/02/19 01:17:02 ] 学校で宿題出されました。どなたか解答お願いできませんでしょうか？ 970 名前：デフォルトの名無しさん mailto:sage [05/02/20 22:28:34 ] あまり真剣に考えてもらわなくてもいいんですが、 多少間違ってても、判定不可という結論でもいいから 主にSJIS,EUC,UTF-8で書かれた短い文章のコードを判定するのに 上手い方法はありませんかね？ というか、ぶっちゃけ2ch内に張られた googleとかwikiへのリンクのURLエンコードされた部分を iconv辺りを使ってSJISに直して表示してリンクしたら面白いかな、と ちょっと思ってみただけなんで 判定不可ならそのまま%xx%yyで表示すればよいだけなんで。 971 名前：デフォルトの名無しさん mailto:sage [05/02/21 01:36:35 ] SJISにしか出てこない値が出てきたらSJIS EUCにしか出てこない値が・・・（以下略 972 名前：デフォルトの名無しさん mailto:sage [05/02/21 04:43:01 ] ASCIIにしか出てこない値が出てきたらASCII 973 名前：デフォルトの名無しさん mailto:sage [05/02/21 05:46:07 ] 色々切り替えて読めればそれ 974 名前：デフォルトの名無しさん mailto:sage [05/02/21 21:45:22 ] EBCDICとかどうよ 975 名前：デフォルトの名無しさん mailto:sage [05/02/21 21:46:02 ] なにが？ 976 名前：デフォルトの名無しさん mailto:sage [05/02/21 21:55:27 ] EBCDIKでどうよ 977 名前：デフォルトの名無しさん mailto:sage [05/02/21 22:01:00 ] >>970 SJISのシーケンスを受理するオートマトン、 EUCのシーケンスを受理するオートマトン、 UTF-8のシーケンスを受理するオートマトン、 を用意して、入力バイト列を3つのオートマトンに入れてみる。 入力が終ったときに、受理したままのオートマトンが1つだけなら、 その文字コードで確定。 確定しない場合があるので、そういうときは追加の知識を使うしかない (google で ie= パラメータがあったら〜、とか) 978 名前：デフォルトの名無しさん mailto:sage [05/02/21 22:06:24 ] ↓オートマトン 979 名前：デフォルトの名無しさん mailto:sage [05/02/21 22:28:46 ] メェェー 980 名前：デフォルトの名無しさん mailto:sage [05/02/21 22:39:27 ] SJISのシーケンスを受理するヤギ、 EUCのシーケンスを受理するヤギ、 UTF-8のシーケンスを受理するヤギ、 を用意して、印刷物を3匹のヤギに食わせてみる。 食い終ったときに、「メェェー」って言ったヤギが1匹だけなら、 その文字コードで確定。 二匹啼いたときは、一匹殺せば無問題。 981 名前：デフォルトの名無しさん mailto:sage [05/02/21 22:44:47 ] それじゃぁ手始めに979を殺すということで 982 名前：デフォルトの名無しさん mailto:sage [05/02/21 23:14:52 ] >>970 |多少間違ってても、判定不可という結論でもいいから |主にSJIS,EUC,UTF-8で書かれた短い文章のコードを判定するのに |上手い方法はありませんかね？ たぶん変換コード書いた人なら悟ってると思うけど、 3種類出力させて、判断は人間にまかせるのが簡単確実。 問題はその表示のしかたをどう分かりやすくできるかだが… 983 名前：デフォルトの名無しさん mailto:sage [05/02/21 23:50:46 ] 確実に判定することは不可能だけど 実用上は980^H^H77の方法でほとんど困らないと思う 利用者としてはリンク開くときに常に3択やらされるたらいやだなぁ 984 名前：デフォルトの名無しさん mailto:sage [05/02/21 23:52:10 ] 前半は980で、 二匹鳴いたら二匹並べればいいだろ。 985 名前：デフォルトの名無しさん mailto:sage [05/02/22 02:39:43 ] やっぱむやみにヤギを殺すのはよくないよね 986 名前：デフォルトの名無しさん mailto:sage [05/02/22 03:46:34 ] べつに 987 名前：デフォルトの名無しさん mailto:sage [05/02/22 11:07:32 ] というかさ、ヤギじゃなくてヒツジじゃないの？ 988 名前：デフォルトの名無しさん mailto:sage [05/02/22 14:42:16 ] IE5 以上を入れているならばならば、IMultiLanguage にそんなメソッドがあったような？ 989 名前：デフォルトの名無しさん mailto:sage [05/02/23 00:32:02 ]   SJISのシーケンスを受理するヒツジが一匹、   EUCのシーケンスを受理するヒツジが二匹、   UTF-8のシーケンスを受理するヒツジが三匹、   .   .   zzz 990 名前：デフォルトの名無しさん mailto:sage [05/02/23 14:46:57 ] 次スレは？ 991 名前：デフォルトの名無しさん mailto:sage [05/02/23 14:54:35 ] 【UTF8】文字コード変換 二匹目【SJIS】 992 名前：デフォルトの名無しさん mailto:sage [05/02/23 15:35:36 ] 次スレ立てるなら文字コード統一スレとか Unicodeスレとかがいいんじゃね？ 993 名前：デフォルトの名無しさん mailto:sage [05/02/23 21:35:57 ] 文字コード統一スレ 1文字目 プログラムにおける文字コードの取り扱いについて議論する統一スレッド です。 ほぼ前スレ 【UTF8】文字コード変換【SJIS】 pc5.2ch.net/test/read.cgi/tech/1063177450/ 参考ホームページ Unicode Home Page www.unicode.org/ Java Character Encodings www.ingrid.org/java/i18n/encoding/ euc.JP: tech docs, BeOS tools euc.jp/ ISO-IR - 2.8.1 Coding systems with Standard return www.itscj.ipsj.or.jp/ISO-IR/2-8-1.htm ISO-IR - 2.8.2 Coding Systems without Standard return www.itscj.ipsj.or.jp/ISO-IR/2-8-2.htm こんなんでどうですか？ 994 名前：デフォルトの名無しさん mailto:sage [05/02/23 21:49:38 ] >>970 結局んとこは確率になるからなぁ 特に極短い文だとね IMultiLanguage2::DetectInputCodepage でもできるけど識別率はどんなもんだろ 試してないからわからんが中国語とかも識別できるだろうからいいかも？ あとは>>691ででてた ttp://www.gprj.net/dev/tips/net/txtenc.shtml これか？ これも識別率はわからん C#だけど 995 名前：デフォルトの名無しさん mailto:sage [05/02/23 23:39:52 ] >>994 多分みんな作ったことあるんだろうな(笑) 俺もある。 短い文だと誤判定が多くなるねー。 いわゆる「半角カタカナ」などというものが滅んでしまえば、かなり楽なんだが。 # 正確にはカタカナのJIS X 0201の方 泥臭いけど、日本語としての特徴を使えば認識率はあがるよ。 漢字ばかりになることはないとか、ひらがなは半分以上であるとか、そういうので点数をつける。 EUC-JPとしてみれば10点、Shift-JISなら25点というふうに。 996 名前：デフォルトの名無しさん mailto:sage [05/02/23 23:45:39 ] もとの質問の対象がURL中の文字列つーのがきついよね。 997 名前：デフォルトの名無しさん mailto:sage [05/02/23 23:56:34 ] >>993 に一票 >>995 gaucheの実装がそんな感じだね。ソースも切り取りやすくてすてき。 998 名前：993 mailto:sage [05/02/23 23:58:43 ] 立てられませんでした。どなたかお願いします。 999 名前：デフォルトの名無しさん mailto:sage [05/02/23 23:59:22 ] 999 1000 名前：デフォルトの名無しさん mailto:sage [05/02/24 00:00:14 ] 1000ならunicode死滅 1001 名前：１００１ [Over 1000 Thread] このスレッドは１０００を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef