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

1 名前：デフォルトの名無しさん [03/09/10 16:04] 文字コード変換について語りましょう♪ 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」？？？

---

---

[ 続きを読む ] / [ 携帯版 ]

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