文字コード統一スレ 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 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から変換している模様。 953 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 07:57:46 ] ESC $ ( ? はどんな文字集合を扱うんですか? 954 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 10:12:15 ] >>952 >> 実際、UDCを使ってOutlookで2022でエンコして送ったらどーなるんだ？ >ISO-2022-JP-MSでぐぐったページのどこかに書かれてたが、 >1バイト目が(ISO 2022の用語でいう)C1領域とかにはみ出すらしい。 >つまり範囲チェックすらせず機械的にCP932から変換している模様。 それってOutlookの問題っすか？ ESC$(?つーのは https://sourceforge.jp/docman2/?group_id=2198 をみるとUDC（外字）を交換するための独自拡張みたいっすね。 C1はつかっていないみたいだけど。 iso-2022-jp-udcか（ｗ 955 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 21:29:27 ] >>954 > それってOutlookの問題っすか？ 変換APIの問題だな。つーか実際にOutlookで転送を試してみた訳じゃなくて 変換APIの仕様から予想される挙動を書いただけだから。 > C1はつかっていないみたいだけど。 だから互換性がないんだってば。 > iso-2022-jp-udcか（ｗ つーかそうやって何でもかんでも名前を付けたがる時点で終わってる。 文字コードは変換表ではない web.archive.org/web/20030629173513/http://www.geocities.co.jp/SiliconValley-Oakland/1479/i5.html まあiconvがパラメータにcharsetの名称しか取れないから Ideographic Variation Sequencesと同じように「必要悪」なんだけど。 このスレの上の方で出ていたNFCとNFDに別のcharset名を付ける、みたいな 956 名前：デフォルトの名無しさん mailto:sage [2006/03/19(日) 21:59:30 ] 文字コードって次から次へと枠組み壊すヤツが出てくるよな。 957 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 08:20:55 ] 野村雅昭とか野村雅昭とか野村雅昭とか？ 958 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 11:42:13 ] せめて3つ目の一文字ぐらい伏せてあげて 959 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 11:47:54 ] 字形変更と文字入れ換えとか 字形変更と文字入れ換えとか 字形変更と文字入れ換えとか 960 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 16:19:36 ] 必要悪と言うか、「文字コード」ってそういうものだと思い始めてきた今日この頃。 > 文字コードは変換表ではない 「文字コード」自体がそもそも多義的だし、MIMEのcharsetとXMLのencoding/charsetは違う。 XMLはUTF-32の世界だから、encodingはUnicodeへの変換表だし。 UCS正規化の世界では、「‘文字コード’は変換表です。」 しかし、試しに実装していて思ったが、ISO-2022-JP-MSって中途半端だな。 ユーザ定義文字をなくすか、補助漢字も入れるかすればいいのに。 名前的にeucJP-msの文字を全部持ててほしいなぁ。 961 名前：デフォルトの名無しさん mailto:sage [2006/03/20(月) 16:49:52 ] MIMEのcharset、XMLのencodingは、 CCS(Coded Character Set)のことでしょ。 XMLのcharsetはCS(Character Set)のこと。 > 文字コードは変換表ではない これは、たぶんというか当然、前者のことでしょう。 962 名前：デフォルトの名無しさん mailto:sage [2006/03/21(火) 00:53:23 ] XML 日本語プロファイルをみると、 www.w3.org/TR/japanese-xml/ 確かに、XML の "Encoding" は CES であり、charset は “A charset is a set of rules for mapping from a sequence of octets to a sequence of characters.” と書かれてて、つまり ACS+CCS+CES なので両者は異なるわけだけど、 4.3.3 Character Encoding in Entities www.w3.org/TR/REC-xml/#charencoding には Encoding を charset 的に扱うことが示唆されている。 ここで、XML の charset と encoding が同一視できる。 次に 2.2 Characters www.w3.org/TR/REC-xml/#charsets をみると、 “A character is an atomic unit of text as specified by ISO/IEC 10646:2000 [ISO/IEC 10646].” とあり、 XML の文字集合は常に Unicode。 そしたらもう charset とか言いつつもただの Unicode への変換表じゃん。 ってか、ぶっちゃけ XML の話に限れば、両方 XML パーサーが文字コード変換プログラムに渡すパラメータでしょ？と。 str.decode(charset); ここまで話は XML が UCS 正規化されているのを前提としているので、 MIME charset は変換表では無い、というのなら同意。 まぁ、遅かれ早かれこちらも毒されていくのだろうけど。 963 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 01:53:51 ] >>952 > ISO-2022-JP-MSでぐぐったページのどこかに書かれてたが、 > 1バイト目が(ISO 2022の用語でいう)C1領域とかにはみ出すらしい。 > つまり範囲チェックすらせず機械的にCP932から変換している模様。 それと同じ挙動のencodingを定義しろよ。 iso-2022-jp-ms なんてイラネ。 964 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 11:15:56 ] こわそうなスレのようですが、教えてもらいたくてお寄りしました。 自前のアプリで unicode text も扱えるようにしようと調べているところですが、 unicode で書出すファイルには先頭に BOM を付けるようになっているようですが これは必須ですか。またまじめな文書には必ず付いているものですか。 それとも、文字コードを見て、判定しないといけないのでしょうか。 965 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 12:39:51 ] >>964 UTF-16ならBOM必須。 つーか、BOMのないものは UTF-16BEまたはUTF-16LEと明示する必要がある。 UTF-8のシグネチャは、まあ、好きにしてくれ。 966 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 14:02:39 ] >>964 UTF-16(Little Endian) のことを「unicode」って呼んでる？ それだったら、名前を「UTF-16(Little　Endian)」とかにした上で、BOMはつけよう。 UTF-8は「UTF-8(BOM)」と「UTF-8N」に対応しておくのが無難だと思う。 967 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 14:43:11 ] >>966 > 名前を「UTF-16(Little　Endian)」とかにした上で、BOMはつけよう。 「UTF-16（Little Endian）」なんていう紛らわしい表示にすると、 利用者からUTF-16LE（つまりBOMなし）と誤解される予感。 BOMが付いてるなら、単に「UTF-16」でいいやん。 968 名前：964 mailto:sage [2006/03/22(水) 14:49:28 ] >>965-966 ご親切に有難うございます。 unicode と言っているのは、VC++2005EEで default でコンパイルすると なってしまう文字コードを想定しています。 しかし「明示する」とか「つける」という意味が初めてで分かりません。 ファイル先頭に 0xFFFE だか 0xFFEF だかをただ付けるだけでは駄目な のですね。ファイル先頭の様式を並べたサイトとかあると助かりますが ぐぐって見ます。 969 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 15:23:20 ] >>968 Unicode本で、32、47、79-81、400-402ページあたりを参照。 お望みの表は80ページのやつかな。 www.unicode.org/versions/Unicode4.1.0/ www.unicode.org/versions/Unicode4.0.0/ch02.pdf www.unicode.org/versions/Unicode4.0.0/ch03.pdf www.unicode.org/versions/Unicode4.0.0/ch15.pdf 970 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 17:54:17 ] >>968 > unicode と言っているのは、VC++2005EEで default でコンパイルすると > なってしまう文字コードを想定しています。 それだったら VisualStudioのスレで聞くか、 Microsoft のサポートに直接聞いた方が早いような気もする。 コンパイル結果の文字コードってのと、 実行時に特定のAPI使って生成された文字列の文字コードと、 VC++2005EE のエディタがデフォルトで使用する文字コードってのは全然別。 コンパイル結果の文字コードってのも、先頭に L が付いてる文字列リテラルとか _T() で括られた文字列リテラルとか、etc etc ちゃんと区別しないと何の事言ってるのかわからん。 とりあえず、スレ違いっぽい。 971 名前：968,964 mailto:sage [2006/03/22(水) 18:19:09 ] >>969 ご紹介有難うございます。 その後ぐぐって説明を読んでいますが、想像以上に複雑怪奇ですね。 自分のアプリの機能の１つは、ファイルをダブル・クリックすると文字であろうが 絵であろうが内容を見て表示するということです。文字の場合はしかるべき変換を して edit control へ送り込んでいます。dos, linux, mac, jis, euc, .rtf, .doc, .html（tagを抜く）, base64, ...と拡張して来ました。 edit control で文字にならないなら、.... 最後は hex。 これに unicode も含めたい。 で、今までのところ種種の文字変換を自前ってのは大変だなあとの感じ。 当面 SF_UNICODE を指定して edit control へ送るのかなと弱気になって います。 972 名前：デフォルトの名無しさん mailto:sage [2006/03/22(水) 20:39:56 ] 「N'ko」って何て発音すればいいの? 973 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 06:02:07 ] 「ンコ」でいいかと。 974 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 11:24:51 ] 次スレのタイトルは、文字コード総合スレ part2　でよろ 975 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 14:03:41 ] 統一はおかしいよな 976 名前：デフォルトの名無しさん mailto:sage [2006/03/23(木) 14:11:17 ] あぁ、Raruty の右側のダイアログみたいな感じですね？（ぇ UTF-16なテキストに対応するのでしたら、BOMがあるものだけ対応しておけばよいかと。 ついでにUTF-8も対応しておくといいんじゃないかな。 なお、edit controlまわりの話はわからないのですけれど、 文字コード変換はWin32 APIを使った方がいいのでは？ Shift_JISはCP932、EUC-JPはCP51932だと思えば、とりあえずはいいので。 msdn.microsoft.com/library/ja/jpintl/html/_win32_multibytetowidechar.asp

---

---

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

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