文字コード統一スレ 1文字目

1 名前：とりあえず立ててみた [05/02/24 00:07:38 ] プログラムにおける文字コードの取り扱いについて議論する統一スレッド です。 ほぼ前スレ 【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 852 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 00:48:24 ] STLPort 5.0.1をWindowsでビルドしたんだけど、UnitTestで3/329が通らない。 見てみると、std::use_facet<>のテストでのassert。 調べてみると、どうも「CP1252(Latin-1)な言語環境じゃなきゃ通らない」テストになってた。 しかも、use_facet<>の実装も間違ってる始末。 ポンド記号とかをGetLocaleInfoA()で取得した後、MultiByteToWideChar(CP_ACP)→WideCharToMultiByte(CP1252) なんて処理を行ってる。 これだから外人は… 853 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 00:59:43 ] >>852 微妙にスレ違いな気がするぽ もっと適切なスレに逝け 854 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 01:38:25 ] ここでいいと思う。 855 名前：デフォルトの名無しさん mailto:どう考えてもSTLスレのほうが適切・・・ [2006/02/01(水) 15:03:31 ] いや、やっぱりよくない 856 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 15:23:10 ] まあいいじゃねえかよ。 言いたかったのは「これだから外人は」ってことなんだろうから。 857 名前：デフォルトの名無しさん [2006/02/04(土) 10:44:45 ] >>849 いや英語圏というか文字の種類が数十文字の言語にとっては 現時点でももうオーバースペックだよ。 858 名前：デフォルトの名無しさん mailto:sage [2006/02/04(土) 15:09:32 ] 一般人にとってはそうだろうね。 けどUnicodeなんかはベンダー主導の部分も大きくて、 英語圏のソフトウェアベンダーに取っては必要不可欠。 ドメスティックな奴は彼らにとってはわけわからんし。 859 名前：デフォルトの名無しさん mailto:sage [2006/02/04(土) 16:03:22 ] 英語圏の人間でも各種記号が増えるのは嬉しいんじゃないの。 860 名前：デフォルトの名無しさん mailto:sage [2006/02/04(土) 16:29:34 ] ¢ € £ 861 名前：デフォルトの名無しさん [2006/02/04(土) 19:16:41 ] ユニコードってのは、最初はCJKなんて含んでいなかったんですよ。 8859シリーズが増えすぎて手に負えなくなって、しかたが無いから 16ビットにしてしまえと。まあ、確かに、欧米だけならBMPだけで 間に合っていただろうけど。 862 名前：デフォルトの名無しさん [2006/02/08(水) 03:38:36 ] bitmap にしてしまうと bmpstrcmp() とかいうイメージの比較関数を C言語に標準で用意する必要性が・・・。(リターン値は double で 何パーセント似ているかが返される)。 863 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 04:28:05 ] BMPってBasic Multilingual Planeのことだろ･･･ 864 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 06:39:21 ] ハハ。以前打ち合わせ2時間やった帰り際に>>861みたいなことを お客さんに言われたことがあるよ。どうしようかと思ったｗ 865 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 22:52:42 ] >>862 フィッシングで釣り放題の予感 866 名前：デフォルトの名無しさん mailto:sage [2006/02/08(水) 23:02:44 ] > C言語に標準で 「言語情報や字体情報はリッチテキストで表せばいい」って 絵空事を言ってる人たちが意図的に触れない点ですな。 char→wchar_tすら遅々として進まないのに プログラミング言語の標準ライブラリとかOSのAPIがすべて文字列の代わりに XMLのマークアップとか受け取れるようになるなんて本気で思ってる人 どれくらいいるんでしょうかね。 ただでさえ > 英語圏の連中にとってオーバースペックにもほどがある のに。 867 名前：デフォルトの名無しさん mailto:sage [2006/02/09(木) 10:03:21 ] 欧米で日本語流行らないかな 漢字をおしゃれだと思ってる欧米人も少なくは無いんだろうが 身体に亀仙人とか彫っちゃう感覚なんだもんな 意味含めて1ヶ月流行らんかな 868 名前：デフォルトの名無しさん [2006/02/11(土) 02:51:33 ] 日本語をローマ字で書く程度ならそんなに苦労はしないかも知れないが、 実際には平仮名カタカナ漢字と3種類の文字を覚え、更に漢字の音読み 訓読みを覚えなければならないので全部使えるようになるまでは英語圏の やつらにはかなり大変なんじゃねえの? 869 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 02:54:37 ] 日本はまだマシなものだ 870 名前：デフォルトの名無しさん [2006/02/11(土) 03:22:08 ] そうか? 要するに言葉を覚えるより文字を覚えるのが大変ということだが。 まあ、中国語とかも大変そうだが。 871 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 07:57:24 ] 日本語を流暢に話す欧米人はそこそこみかけるが（ＴＶでね） 仮名漢字交じりの文章をスラスラ書く欧米人は見たことないなぁ。 872 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 09:53:17 ] >>871 それがいるんだ。 873 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 11:56:00 ] 中には日本好きが高じすぎて、当の日本人より詳しいのも。 希出漢字の書き順まで完璧。知識階級に多い。 874 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 12:57:05 ] 夏期休暇でアメリカに行った際の出来事。 ＬＡで信号待ちをしていると 気の良さそうな２人組のお兄さんが、 「おまえは 日本人か？」と気さくに聞いてきました。 「そうだ」と答えると、「漢字のタトゥー （刺青）を 彫ったんだけど、 どういう意味か教えろよ」と言われ、差し出された腕を見ると 『武蔵』と彫ってありました。 「日本で最も有名な剣豪だよ」と伝えると 彼は満面の笑みを浮かべていました。 続いてもう一人が腕を差し出すと そこには『朝鮮』と大きく彫ってありました。 「KOREAだよ」と教えてあげた後の彼の悲しそうな顔が忘れられません。 875 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 13:25:47 ] コピペ乙 876 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 13:32:20 ] 全米が泣いた 877 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 14:19:51 ] 「K-1ファイターだよ」と教えてあげた後の彼の悲しそうな顔が忘れられません。 878 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 16:41:39 ] WinFX Runtime ComponentのJan CTPを入れて、Loose XAMLで >>125みたいな指定が実際に可能である(エラーにならない)ことを確認した。 ただしXPではUniscribeが古いままなせいか、それとも単にまだ実装されていないのか、 メイリオや小塚明朝を指定しても実際に字形の切り替えは反映されなかった。 879 名前：デフォルトの名無しさん [2006/02/11(土) 22:10:48 ] はやっているのは日本語ではなくて中国語だという説も。 中国は簡体字だろうって？ 台湾も香港も、大陸系でも欧米に往来するような連中は教養として 繁体字を書けますので。 880 名前：デフォルトの名無しさん mailto:sage [2006/02/13(月) 00:36:29 ] 正体字か常用漢字体かは見分けられるだろう 881 名前：デフォルトの名無しさん mailto:sage [2006/02/13(月) 22:33:39 ] >>879 海外の華僑は繁体字を使ってるんでしょ? 882 名前：デフォルトの名無しさん [2006/02/13(月) 23:32:35 ] 例えば、円のような字があれば紛れもなく日本語だろうけど、常用漢字体と いっても、それまで草の根で使われてきた字を公認したものもあるので、 単純には見分けられない。台湾香港の手書きの繁体字が日本の正字体 （康煕字典体）と一致しているわけでもない。活字は示偏で手書きはネ偏 とかいうのも普通です。 883 名前：デフォルトの名無しさん mailto:sage [2006/02/17(金) 20:16:11 ] UTS #37の承認キター www.unicode.org/reports/tr37/ で、AJ1-6の登録マダー? (AAry 884 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 05:26:49 ] ietf-charsetsのメーリングリストがいつ行っても落ちてるんですけど 今さら新しいcharsetを登録したいやつなんかいないだろって感じですか? mail.apps.ietf.org/ietf/charsets/threads.html 885 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 09:09:41 ] 前に揉めたから日本人ははねてるんだろうな(w 886 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 23:48:33 ] ISO-2022-JP-3を事実上葬った太田センセイですか? 今となっては結果的にGJだった気もするが(w 887 名前：デフォルトの名無しさん mailto:sage [2006/02/22(水) 15:31:18 ] So? 888 名前：ハーピィ mailto:sage [2006/02/24(金) 11:51:00 ] E・∇・ﾖﾉｼ　＜888ｹﾞｯﾄ♫ 889 名前：デフォルトの名無しさん [2006/02/26(日) 03:04:47 ] javaでISO-2022-JPからUTF-8への変換は出来るの？ 890 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 03:28:05 ] Java API でって事か? 891 名前：デフォルトの名無しさん [2006/02/26(日) 07:22:44 ] >>889 できる。 892 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 06:49:17 ] ISO-2022-JP-2でG2にISO-8859-7が指示できるのは何のため? 893 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 15:02:36 ] ギリシャ文字使うのにX0208使いたくなかったから。 894 名前：デフォルトの名無しさん mailto:sage [2006/03/06(月) 23:15:19 ] >>893 JIS X 0201カナ（´・ω・） カワイソス つーかマジでダブルスタンダードだとは誰も思わなかったのかね入れた奴らは 895 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 00:15:34 ] むしろISO-8859-5あたりが指示できない方が問題じゃないかと。 896 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 05:11:55 ] ロシヤ文字はkoi8のほうが標準だったからね。 897 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 06:46:39 ] 結局ISO-2022で世界統一しようというのも日本人だけの妄想ってことだな 898 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 12:06:46 ] X11はcompound textでやっていたけどね。 ISO-2022-JP-2みたいな文字(集合)利用制限付きはうまくいかなかった。 なんでもぶっ込み型しか利用されないのよね。 ctextにしてもunicodeにしても。 899 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 12:55:15 ] ISO-2022-INTがRFCになってたらうまくいってたんだろうか 900 名前：デフォルトの名無しさん [2006/03/09(木) 13:49:16 ] 　　　 _ 　∩ 　　< ｀∀´>彡　KPS9566!KPS9566! 　　(　 ⊂彡 　 　|　　　|　 　 　し ⌒Ｊ 901 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 15:34:39 ] DNSやURL w/UTF-8で、 似た文字を一つにUNIFYして正規化する、とかいうのどうなったの? 902 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 20:06:02 ] よくわからんがとりあえずnameprepでぐぐってみれ 903 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 23:41:59 ] もとはといえば最初に常用漢字とＪＩＳが違うという縦割り行政丸出しの時点で もうだめだったな・・・ 904 名前：デフォルトの名無しさん mailto:sage [2006/03/10(金) 00:44:49 ] 俺的には昔より最近の「印刷標準字体」にたまげた 905 名前：野村 mailto:sage [2006/03/10(金) 06:54:06 ] >>903 その差を埋めようとしたのが83JISじゃないか! 何であんなに叩かれるんだ! 906 名前：デフォルトの名無しさん mailto:sage [2006/03/10(金) 07:52:03 ] 安易だからさ。 907 名前：デフォルトの名無しさん [2006/03/10(金) 17:46:20 ] >>905 非互換の変更で、朝日文字を採用したからでしょ。 908 名前：たちざき [2006/03/13(月) 13:29:45 ] Unicode FA11 は崎の異体字、大→立です。いわゆる「たちざき」 この JIS コードは 7975 だそうです。 たしかに手元のブラウザで EUC-JP F9F5 で表示できます。 しかし JIS X 0213-2004 の1面89区85点を見てもみあたりません。 www.itscj.ipsj.or.jp/ISO-IR/233.pdf どこを見れば「たちざき」が載っているのでしょうか？ 909 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 13:39:49 ] 1-47-82 910 名前：たちざき [2006/03/13(月) 13:46:25 ] >>909 ありがとうございました、無事見つかりました。 今まで区点コードとJISコードは 0x2020 の違いだけだと 思い込んでいたのですが、そうではないのでしょうか？ JISコードと区点コードの間にも Unicode との マッピングのようなマッピングを持たなければならないのでしょうか？ 911 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 14:07:04 ] >>908 > この JIS コードは 7975 だそうです。 それはNEC選定IBM拡張文字としてのコードであって、正式な（？）JISコードじゃないから。 912 名前：たちざき [2006/03/13(月) 14:07:41 ] いま、下の変換表を見てみましたところ、 examples.oreilly.de/english_examples/nutshell/cjkv/adobe/jisx0213-all.txt EUC-JP F9F5 = JIS 7975 = 区点 1-89-85 = Unicode U+7CBC のようです。 U+7CBC は CJK Unified Idiograph で「憐」のつくりをへんに持ち、 「喩」の右下の二本の並行曲線をへんに持つ、変わった漢字です。 手元のブラウザで EUC-JP F9F5 は「たちざき」に見えているのですが。 913 名前：たちざき [2006/03/13(月) 14:11:06 ] >>911 え？そうだったんですか。丸付き数字とかだけかと思ってました。 ということは、EUC-JP F9F5 で「たちざき」が見えているこのコードは、 「えせ」EUC-JP ってことでしょうか？ 914 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 14:13:46 ] >>913 「えせ」ってのは響きが宜しくない。 「独自拡張された」EUC-JP（JIS X 0208ベース）ぐらいが適当か。 915 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 14:14:25 ] 1-89-85が﨑な文字コードと1-47-82が﨑な文字コードは別の物だよ。 916 名前：たちざき mailto:sage [2006/03/13(月) 16:16:43 ] >>914 >>915 わかりました。DBの統合に際して 気をつけなければと思って調査しているのですが、 どうやらJIS X 0208 + 拡張文字ベースの EUC-JP と JIS X 0213 ベースの EUC-JP が混在しているようです。 マップを細かく切り替えながら乗り切ることにします。 917 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 19:59:11 ] うわ、eucJP-openとEUC-JISX0213が混ざっているのですか・・・がんばってください・・・。 EUC-JISX0213はJIS X 0213を見ればいいとして、 eucJP-open（独自拡張されたEUC-JP）は、 www2d.biglobe.ne.jp/~msyk/charcode/cp932/eucJP-ms.html やここからいけるリンクの先をご覧になるとよろしいかと。 918 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 00:11:27 ] ところでUnicode 5.0(ベータ)でUTF-8最後の2byte領域につっこまれたNKoってどこの文字か知ってる人います？ 919 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 01:00:14 ] >>913 むしろ丸付き数字はNEC拡張とJIS X 0213で互換性がある。 920 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 08:02:42 ] std.dkuug.dk/jtc1/sc2/WG2/docs/n2765.pdf >Manden (or Manding) people live mainly in West Africa >literary dialect commonly known as Kangbe ‘the clear language’, and also known as N’Ko. これかなー 921 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 09:43:04 ] Vai script はまだなのか…… 922 名前：デフォルトの名無しさん [2006/03/14(火) 22:25:35 ] UTF-9を使うとLaten-1が1バイト、CJKは2バイトに収まるというが 923 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 23:51:28 ] >やるならヒキヅナの正しい文字を追加してもらいたい 化石レス、スマソ。それって、 hp.vector.co.jp/authors/VA000964/hikiduna.htm のこと？だいたい、あそこで言ってる事って正しいの？ 924 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 00:11:21 ] >>922 バイトには違いないがオクテットじゃなくてノネット(9ビットバイト)だからあまり実用的 じゃない。つーかJoke RFCだし。 UTF-9ってRFC 4042に載ったもの以外に、こんなのもあったなあ。 www3.ietf.org/proceedings/99jul/I-D/draft-abela-utf9-00.txt 925 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 00:12:06 ] >>923 それこそ自分の目で確かめろだ 926 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 00:28:15 ] >925 あのページって、南堂某みたいなトンデモだと思ってた。 927 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 00:55:49 ] 南堂某と一緒くたにしたらあまりに失礼だ。 928 名前：デフォルトの名無しさん mailto:age [2006/03/15(水) 16:23:55 ] Legacy Encoding Project sourceforge.jp/projects/legacy-encoding/ > 　主要な OSS (libiconv、glibc、Perl、Ruby、Python、PHP、ostgreSQL、 > MySQL、nkf など) の各ソフトウェアで、Microsoft標準キャラクタセット > をシフト JIS符号化方式、日本語EUC符号化方式、7ビットJISコード符号化 > 方式の各々 の間で相互変換できるようにする事を目的とします。 929 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 20:30:46 ] Windows-31JはともかくISO-2022-JP-MSは混乱を新たに追加するだけだと 思うがなあ…。 930 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 20:33:04 ] >>928 OSCや、 www.ospn.jp/osc2006/modules/eguide/index.php?begin=1142521200&end=1142607600&msg=1 YAPCで発表もなさいますね。 tokyo.yapcasia.org/blog/ja/sessions.html 931 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 21:42:30 ] そうだ！南堂某にあやまれ。 932 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 22:07:45 ] ISO-2022-JP-MSって、変換に問題が生じるから新しく作るってことか？ なんか考え方がunicode的というか傲慢というか。 実装だけでなくガイドラインもとか言ってるから自分たちの提唱する 方式が支配的になればハッピーというつもりだろうが、 それなら最初の問題の立て方の段階から合意を形成する必要があるよね。 933 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 22:46:24 ] >>932 私の代わりにISO-2022-JP-MSが本当に必要なのかMLで議論してきてください（ぉ まぁ、この手のプロジェクトの必要性自体は認めますけど。 Perl/EncodeでEUC-JP使っていて、U+301C周りではまったことあるし。 934 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 23:50:07 ] 辛辣ですな(w slashdot.jp/~alp/journal/348517 slashdot.jp/~witch/journal/348491 slashdot.jp/~oku/journal/348499 > Unicode.org の変換表は、4.0.1 で規格に取り込むかたちで完全に策定されています。 これ本当? OBSOLETEになったEASTASIAの変換表も更新されて 取り込まれたりしてるの? >>933 面倒なので勝手にやってもらって勝手にコケてもらうことにします。 自分の関わってる某OSSプロダクトでISO-2022-JP-MSをサポートしろとか言われたら 全力で拒否するけど。 935 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 00:41:50 ] ISO-2022-JP-MS はともかく、CP932/CP1932/eucJP-ms についてはこけることはないでしょ。 だって、もう八割方終わってるし。 936 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 07:20:13 ] コケル、ってのは広まらない、ってことでそ。 937 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 07:28:04 ] > CP1932 CP51932? 938 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 09:00:38 ] >>921 日本人でこれ使いたい人がいるとは・・・ lucia.itscj.ipsj.or.jp/itscj/servlets/ScmDoc20 を見ると、Amendment 3にvai が入ってるね。まだDAMレベルの投票だから、あと １年半待て。 939 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 09:09:00 ] iso-2022-jp-ms なんてデファクトでしょ。 Outlook Expressで、何の躊躇いもなく「�@」とか送ってくる輩がゴマンといるし、 gooだのyahooだののwebメールで textarea に入れた「�@」もメールでは同様に エンコードされる。 ただＵnicodeと関わらない普通のOSSはサポートなんて考えなくていいんじゃないかな。 iso-2022のコードを、unicodeに変換するルーチンはサポートして欲しい気もするけど。 いちいちメールに半角カナ中点とか�@とか使う連中に「使うな」と注意してるとこっちが 木印扱いされかねない昨今だからなぁ。 940 名前：938 mailto:sage [2006/03/16(木) 09:16:03 ] すみません、ここはservletのURLでしたね。 std.dkuug.dk/jtc1/sc2/ このリンクから“REGISTERS & SEARCH”をクリックして、 vaiで検索すると、n3817が出てきます。 941 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 09:24:28 ] どうしてISO-2022-JP系である必要があるのか分からない。 変換テーブルの非互換を増やさないため、 典型的な変換テーブルを持った文字コードを増やすというのは分かるけど、 文字集合が違うとあらたに文字コードが増えただけなのでは? 942 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 10:23:08 ] >>939 iso-2022-jp-ms と cp5022x は違うよ。 おまけに cp5022x は WideCharToMultiByte と ConvertINetUnicodeToMultiByte で同じじゃなかったりする。 WideCharToMultiByte は補助漢字使えるけど、ConvertINetUnicodeToMultiByte は使えないとか。 iso-2022-jp-ms と eucJP-ms も補助漢字サポートする/しないで 一貫性なかったりしてなんだかなー、な感じがある。 943 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 10:37:06 ] >>936 本家libiconvに取り込まれれば、それだけで実装としては広まるよね。 まぁ、ユーザが知らなければ駄目なわけですが。 >>937 すみません、CP51932ですね >>939 発想がiconv的なのだと思います。（Unicode的という声もログにありましたけど） iconvは定義外の文字を投げるとエラーを出す実装が多いので、 いわゆる機種依存文字は変換できない（と思います）。 変換するためには、 * "iso-2022-jp" でいわゆる機種依存文字も許容するようにする * いわゆる機種依存文字を許容する別の名前を作る の二種類があり、後者を取った、と。 iconvのようにエラーを出さないルーズな実装では、 iso-2022-jpのaliasにiso-2022-jp-msをつくるだけ、の場合もあるかもしれません。 nkf とかだと、いわゆる機種依存文字を許容するかどうかはオプションで指定などと逃げられますが、 iconvだとそうもいきませんからね。 944 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 19:38:19 ] 俺は必要悪だと思て消極的に応援してる。 945 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 22:28:24 ] >>930 今日のOSCの報告きぼんぬ。 946 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 16:57:01 ] すでに>>942が指摘してるがISO-2022-JP-MSの問題はCP50220/50221と互換性が 「ない」点。(「いわゆる機種依存文字」に限れば交換できそうだけど)。 そのくせMSの方言と互換性があるかのような誤解を招くネーミングもひどい lists.sourceforge.jp/mailman/archives/mutt-j-users/2005-October/000082.html > ISO-2022-JP-MS は、Windows Codepage 50220, 50221 と互換性がありますので、 なんてほざいてるが www2d.biglobe.ne.jp/~msyk/cgi-bin/charcode/bbs.cgi?c=r&n=277 > CP50220/CP50221/CP50222 のいずれかを実装する事も考えた事がありますが、 > ユーザー定義文字をエンコードできないとか、一般的にあまり実態が知られていない > エンコーディングの為、イマイチだと感じています。 > 仕方が無いので、ISO-2022-JP-MS というものを独自に定義して実装する事を考えています。 どう見ても互換性ありません。本当にありがとうございました。 www2d.biglobe.ne.jp/~msyk/cgi-bin/charcode/bbs.cgi?c=r&n=280 > JIS規格だけでは実装するのに情報が不十分で とか平然と嘘まで吐くし、むしろこいつこそ南堂某の仲間にしてやりたい 947 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 17:09:04 ] > おまけに cp5022x は WideCharToMultiByte と ConvertINetUnicodeToMultiByte > で同じじゃなかったりする。 ついでにWin9xだと WideCharToMultiByte では使えなくて ConvertINetUnicodeToMultiByte しかサポートしていないとか。 本来GB18030対応のために用意されたと思われるWin2kのDLL based codepageを ISO-2022-JP系エンコーディングの実装に流用したんだろうな。 948 名前：http://www.vector.co.jp/soft/win95/util/se072729.html [2006/03/18(土) 20:02:01 ] TextSS　のWindowsXP(Professional)64bit化おながいします もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？ 949 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 20:03:41 ] > ついでにWin9xだと WideCharToMultiByte では使えなくて それは知らんかった。情報ありがと。 950 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 22:57:30 ] >>946 >ISO-2022-JP-MS は、Windows Codepage 50220, 50221 と互換性がありますので、NEC特殊文字(13区)、 >NEC選定IBM拡張文字 (89区〜92区) を正しく扱えるようになっています。 13区と、NEC選定IBM拡張文字が使えるというのがポイントかと。 そうするとiso-2022-jp-cp932とかいう名前だったらOKとか（ｗ 951 名前：デフォルトの名無しさん mailto:sage [2006/03/18(土) 23:37:38 ] そうじゃなくて、ESC $ ( ? という謎のエスケープが使えることなのでわ？ 実際、UDCを使ってOutlookで2022でエンコして送ったらどーなるんだ？ 952 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 07:33:26 ] >>951 > そうじゃなくて、ESC $ ( ? という謎のエスケープが使えることなのでわ？ その通り。 そもそもMSに媚びた変換表を使う理由はWindowsとの相互運用のためなのに Windowsで認識できない独自拡張を含める時点で手段と目的が転倒してる。 eucJP-msは比較的古くからあるし内部エンコーディングとしての用途もあるが ふつう内部用には使わないステートフルなエンコーディングをわざわざ今さら 発明するのが全く意味不明。 > 実際、UDCを使ってOutlookで2022でエンコして送ったらどーなるんだ？ ISO-2022-JP-MSでぐぐったページのどこかに書かれてたが、 1バイト目が(ISO 2022の用語でいう)C1領域とかにはみ出すらしい。 つまり範囲チェックすらせず機械的にCP932から変換している模様。

---

---

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

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