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
751 名前:デフォルトの名無しさん mailto:sage [2006/01/16(月) 04:53:11 ] >>748 ひとつのフォントにすべての文字を詰め込むなんて発想はUnicode 2.0時代の遺物です。 d.hatena.ne.jp/kazama/20041207/p2
752 名前:デフォルトの名無しさん mailto:sage [2006/01/16(月) 16:09:00 ] >>751 そうだったんか、知らんかった。
753 名前:デフォルトの名無しさん mailto:sage [2006/01/16(月) 17:15:17 ] Windows 2000からフォントリンクがあるからそれでとりあえずはなんとかしろ。
754 名前:デフォルトの名無しさん [2006/01/18(水) 13:22:55 ] EUC←→SJISの変換だけができる、ごくごく小さい ライブラリってあります? C言語用で。
755 名前:デフォルトの名無しさん mailto:sage [2006/01/18(水) 15:29:15 ] 自分で書くのが一番早い
756 名前:デフォルトの名無しさん mailto:sage [2006/01/18(水) 16:16:48 ] >>754 スレ違い。
757 名前:デフォルトの名無しさん [2006/01/18(水) 20:45:20 ] >>754 単純なEUC-SJIS変換だと、片道10ステップ程度なので、ライブラリになる ような規模ではない。で、JVC外字とかX0213とか言い出すと仕様が発散 して綺麗なライブラリーにならない。あるかもしれないけど、定番というもの はないので、自分で書く方が利口です。
758 名前:デフォルトの名無しさん mailto:sage [2006/01/18(水) 23:42:23 ] >>754 ttp://web.archive.org/web/20040220152952/alfin.mine.utsunomiya-u.ac.jp/~niy/algo/s/sjis2euc.html ttp://web.archive.org/web/20040208203415/alfin.mine.utsunomiya-u.ac.jp/~niy/algo/e/euc2sjis.html
759 名前:デフォルトの名無しさん mailto:sage [2006/01/19(木) 03:06:40 ] static inline unsigned sjis2jisKanji(unsigned char * dest, unsigned char const * src) { #if 0 // 仕様のまま実装した例。理解のために残す。 if (code1 >= 0xe0) {// 1バイトカナの隙間 code1 -= 0x40; } if (code2 >= 0x80) {// 0x7fの穴 --code2; } if (code2 >= 0x9e) {// 偶数ブロック code1 = (code1 - 0x70) * 2; code2 -= 0x7d; } else {// 奇数ブロック code1 = (code1 - 0x70) * 2 - 1; code2 -= 0x1f; } #endif unsigned code1 = src[0];code1 = code1 * 2 - 0xe1; code1 &= 0x7f;// 1バイトカナの隙間 unsigned code2 = src[1];code2 -= 0x1f; if (code2 > 0x7f - 0x1f) {// 0x7fの穴 --code2; } if (code2 >= 0x7f) {// 偶数ブロック code2 -= 0x5e; ++code1; } dest[0] = code1;dest[1] = code2;return 2; } static inline unsigned sjis2eucKanji(unsigned char * dest, unsigned char const * src) {unsigned rtn = sjis2jisKanji(dest, src);dest[0] |= 0x80;dest[1] |= 0x80;return rtn;}
760 名前:デフォルトの名無しさん mailto:sage [2006/01/19(木) 23:51:21 ] UCS2<===>EUC-JPの変換表で 005c<===>5c '\' 007e<===>7e '~' ff3c<===>a1c0 '\' ff5e<===>8fa2b7 '〜' のところが 005c<===>5c '\' 007e<===>7e '~' 005c<===>a1c0 '\' 007e<===>8fa2b7 '〜' となっている物があったのですが、理由はなんでしょうか?
761 名前:デフォルトの名無しさん mailto:sage [2006/01/20(金) 13:26:06 ] ttp://www.opengroup.or.jp/jvc/cde/ucs-conv.html#ch3_1_1
762 名前:デフォルトの名無しさん mailto:sage [2006/01/20(金) 19:59:19 ] その変換表だとa1c0で \ のサニタイジングを貫通されそうで怖い
763 名前:デフォルトの名無しさん [2006/01/20(金) 23:06:48 ] UCS<===>EUC-JP 005c<===>5c '\' 007e<===>7e '~' 005c<===>a1c0 '\' 007e<===>8fa2b7 '〜' 微妙に誤記がありそう。UCSの005cはEUCの何になる?
764 名前:デフォルトの名無しさん mailto:sage [2006/01/21(土) 07:47:39 ] >>763 多対一マッピングじゃないの? 確かJDKがそういう変換をする。 プログラミング言語なのでASCIIの範囲はそのままマップするしかないけど それ以外は可能な限り規格票に忠実な変換をするというポリシーだった希ガス
765 名前:デフォルトの名無しさん mailto:sage [2006/01/21(土) 08:14:46 ] ってEUCか。Shift_JISなら分かるんだけど
766 名前:デフォルトの名無しさん mailto:sage [2006/01/21(土) 08:45:53 ] 005c<===>5c '\' 007e<===>7e '~' であれば、 005c<===>a1c0 '\' 007e<===>8fa2b7 '〜' はありえなくて、 005c<===a1c0 '\' 007e<===8fa2b7 '〜' でしょう? そこんところはちゃんとして。
767 名前:デフォルトの名無しさん mailto:sage [2006/01/21(土) 09:19:15 ] まぁ、言葉の厳密な定義なんて、決まってないかもしれんし、色々あると思うけど、 Unicode --> 文字セットを定義し、各文字に一意のコードポイントを定義 UTF-8, UTF-16, UTF-32 --> エンコーディングスキームでUnicodeの文字セットのコードポイントを どのコードユニットにマッピングさせるかを定義。 まぁ、そんな感じに俺は言葉を使ってる。 UCS-2とかは、まだ、お勉強中。
768 名前:デフォルトの名無しさん [2006/01/21(土) 13:11:11 ] >>764 005c<===>5c '\' 005c<=== a1c0 '\' なのか 005c<=== 5c '\' 005c<===>a1c0 '\' なのか 00a5<===>5c '\' 005c<===>a1c0 '\' なのか これで話が違ってくるのだが。
769 名前:デフォルトの名無しさん mailto:sage [2006/01/21(土) 15:32:33 ] そもそもEUCの0x5cは円マークじゃ無いでそ。
770 名前:デフォルトの名無しさん mailto:sage [2006/01/21(土) 15:39:04 ] JIS X 0201を採用しているベンダもある
771 名前:デフォルトの名無しさん mailto:sage [2006/01/21(土) 18:09:07 ] yen a5; backslash c;
772 名前:デフォルトの名無しさん mailto:sage [2006/01/22(日) 23:11:31 ] ¥ ¥ \
773 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 00:40:08 ] yensignとbackslash を適切にutf-8に移行させる方法は?
774 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 02:01:00 ] >773 究極的には自分で「適切」と思われるコンバータ書くしかないんでは。
775 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 07:49:37 ] ¥と\
776 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 07:51:07 ] printf("そのコンバータの値段は¥4です。\n");
777 名前:デフォルトの名無しさん [2006/01/25(水) 21:44:37 ] >>773 yensign と backslash というのは yen sign と back solidus のことですか。 もし、そうなら、簡単です。 yen sign は 5c (u+005c) back solidusは c2a5 (u+00a5) これ以外の方法はありません。他は全て誤りです。でも、万一、yensign が fullwidth yen sign を意味しているとしたら話が変わってきますので、そこの ところ、もう一度、ご確認くださいませ。
778 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 22:07:06 ] というのは誤りです。
779 名前:デフォルトの名無しさん mailto:sage [2006/01/25(水) 22:37:55 ] >>777 REVERSE SOLIDUSちゃいますの?
780 名前:デフォルトの名無しさん [2006/01/26(木) 00:22:03 ] 書きながら何か違和感があると思ったんだが、そういうことだったのか。 orz
781 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 14:09:14 ] >>777 は釣りの類なのか?
782 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 14:42:56 ] 結局>>776 はどうすんだよ?
783 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 18:24:48 ] ソース内で意図的にyen使ってる奴は漢の中の漢
784 名前:デフォルトの名無しさん [2006/01/26(木) 20:42:18 ] 777です。間違えたのは素で間違えたので釣る積もりはなかったです。 でも、冗談半分、本気半分。 まじめな話、元のコードは何なのかってこと。ASCIIなのかX0201なのか。 X0201ならC的に誤り。エスケープシーケンスの逆スラッシュを円記号で 代用することはANSIでもISOでも許されていない。理屈からいうと??/と するべきだが、これは飽くまでも理屈でしかない。 実用上、ASCIIだと思うしかない。だから、円記号はX0208の216fに書き 換えるしかない。或いは、逆スラッシュの形状が円記号に見えるフォントを 使いつづけるか。誰が見ても円記号に見えるけど、これは逆スラッシュを デフォルメしたものなのですと言い張る。
785 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 21:12:13 ] > 誰が見ても円記号に見えるけど、これは逆スラッシュをデフォルメしたものなのですと言い張る。 MSは本気でこういうこと逝っているんじゃなかったっけ? 0x5cは見た目はYEN SIGNだけどREVERSE SOLIDUS。誰がなんといおうとも¥はREVERSE SOLIDUS。 アッヒャッヒャ!ヽ(゚∀゚)ノ
786 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 21:39:47 ] >>784 JIS Cでは「X0201を使うならバックスラッシュを円記号に置き換える」と書いてある。
787 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 22:02:19 ] 「JIS X 0201の文字集合を使うから」となっているのかな? それならShift_JISでは¥でいいということですね。 cp932ではどうなってんだ? >>785 なのか?
788 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 22:27:10 ] UNICODEの日本語ソート順序、」みたいな 一見すると訳わからんものをMSは実装している。
789 名前:デフォルトの名無しさん mailto:sage [2006/01/26(木) 22:33:13 ] >>787 MSの資料 Windows Codepage 932 ttp://www.microsoft.com/globaldev/reference/dbcs/932.mspx では、字形は¥で、5C = U+005C : REVERSE SOLIDUS (YEN SIGN)と曖昧な定義になっている。 CP932のUnicodeの変換表 ttp://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP932.TXT では、0x5C 0x005C #REVERSE SOLIDUSと定義。 どう表示されるかにかかわらずCP932では常に0x5cをREVERSE SOLIDUSとして扱う、でいいはず。
790 名前:デフォルトの名無しさん [2006/01/26(木) 22:39:13 ] JISのC言語の規格を読んだことが無いので786が本当だと仮定すると、 X0201で書かれたJIS規格C言語のプログラムをX0201以外に変換する ときには、円記号をバックスラッシュに変更しなければならない。 つまり、単純な文字コードの変換では済まず、C言語のプログラムに 特化した変換処理が必要になる。そういうゴタゴタを避ける為、 ANSIやISOは逆スラッシュと円記号の混同(欧州大陸ではアクセント 付き英字と括弧類の混同)を許していない。 ところで、ANSI準拠やISO準拠ではなくて、JIS準拠のコンパイラーって 世間に存在するのかな。
791 名前:デフォルトの名無しさん mailto:sage [2006/01/27(金) 04:26:01 ] JIS X 3010 解説より JIS X 0201で規定する文字集合の中には、プログラム言語Cの基本文字集合の要素\と~ は, 含まれていないが, この規格(JIS X 3010)では, 国際一致規格の趣旨に沿って, 元の 国際規格どおりの(\と~を含む)文字集合を採用した。ただし, ASCIIでの\と~ は, それぞれ, JIS X 0201 では, ¥(円記号)と‾(オーバライン)に対応しており, 原始プログラム中で, \と~の代替表記として¥と‾を使用して混乱が生じる おそれはない。したがって, 処理系が, 符号化文字集合として JIS X 0201 を採用している場合は, この規格の中の\と~をそれぞれ¥と‾に置き換えて仕様を解釈しても, 実用上は, 問題ない。ただし, ¥と‾を使って記述されたプログラムは, 規格厳密合致 プログラムではない。 >>790 ISO規格合致の処理系は JIS X 0201 で\を使って書かれたプログラムを処理 できるので「ISO準拠でなくて、JIS準拠のコンパイラー」というのは意味がない。
792 名前:デフォルトの名無しさん mailto:sage [2006/01/27(金) 07:52:51 ] >>791 > JIS X 0201 で\を使って書かれた 書けへんやん
793 名前:デフォルトの名無しさん mailto:sage [2006/01/27(金) 17:40:59 ] >>792 「JIS X 0201で」は「処理できる」にかかってるんじゃねえの。
794 名前:デフォルトの名無しさん [2006/01/27(金) 20:21:23 ] >>
795 名前:デフォルトの名無しさん [2006/01/27(金) 20:26:44 ] ちなみに、フォントをBatangやGulimにするとW横線になります。
796 名前:デフォルトの名無しさん [2006/01/27(金) 20:41:59 ] >>791 つまり、JISのCは現実を公式に追認したということになるが、 本音はともかく、建前としては拙いのではなかろうか。 真面目にロケールを見てソース文字集合を判断するコンパイラーは 使えないかもね。
797 名前:デフォルトの名無しさん mailto:sage [2006/01/27(金) 21:09:46 ] >>796 いや問題の記述はUnicodeなんて影も形もなかったC89からありますから 単にISO 646シリーズのことしか想定してないだけ
798 名前:デフォルトの名無しさん mailto:sage [2006/01/27(金) 21:30:49 ] >>796 > 規格厳密合致プログラム ってわざわざ"strictly"付けてるけど、 "conforming program"でもないんじゃないの? ¥や‾なprogramは。
799 名前:デフォルトの名無しさん [2006/01/27(金) 22:18:48 ] 昔は printf ("暴\風雨警報"); なんぞと書いたりしましたね。 「暴」の第2バイトが5Cなのですが、最初、これには完全にはまった。 そういえば DOS 2.10 の時代に「蜃気楼」というファイル名を使って ファイルが消えてしまったこともありのした。先頭バイトE5が削除された ファイルの印だったりするもので。今となっては遠い昔の語りぐさ。
800 名前:デフォルトの名無しさん mailto:sage [2006/01/27(金) 22:36:33 ] >>799 FATは今でも生き残ってるわけだが 削除ファイルの表し方は変わったんだっけ?
801 名前:デフォルトの名無しさん mailto:sage [2006/01/27(金) 22:43:21 ] ファイル名の方をいじって保存するんじゃなかったか
802 名前:>>798 mailto:sage [2006/01/27(金) 22:44:00 ] あれ? >>796 →>>791 ね。 まあ「解説」だからアレなのかな。
803 名前:デフォルトの名無しさん [2006/01/27(金) 22:55:19 ] javaで文字列をアスキーコードへ変換方法教えて下さい
804 名前:デフォルトの名無しさん mailto:sage [2006/01/28(土) 00:28:22 ] ほんとうにASCIIでいいのか? 実はCP932とかに変換したいんじゃないのか?
805 名前:デフォルトの名無しさん mailto:sage [2006/01/28(土) 00:51:45 ] >>799 蜃気楼ワロス 先頭がE5のファイル名はディスク上では05として保存される。 で、LFNを使うと5番目のエントリは最初の一文字が05になったりして、またややこしい。
806 名前:デフォルトの名無しさん mailto:sage [2006/01/28(土) 02:37:12 ] >>805 言われてようやく思い出した テラナツカシス
807 名前:デフォルトの名無しさん [2006/01/29(日) 23:40:41 ] ってか日本の公用語を英語にしちゃえばいいんじゃない?
808 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 23:46:25 ] アメリカの州の一つにすればいいよね。実質そうなんだし。
809 名前:デフォルトの名無しさん mailto:sage [2006/01/29(日) 23:49:11 ] >>807-808 日本語の中の人に謝れ!
810 名前:デフォルトの名無しさん [2006/01/30(月) 00:02:36 ] >>808 んなことしたら、アメリカの首都が日本になってしまうぞ。なんたって、 GDPの1/3近くが集中しているのだからな。
811 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 01:46:06 ] 日本自体はカリフォルニアやニューヨーク並かそれ以上の有力州になるが、 英語の下手な元日本人は二等国民扱いになるぞ、それ。 ……十年もすれば全米でもっとも英語のスコアの高い州になりそうな気もするが。
812 名前:デフォルトの名無しさん [2006/01/30(月) 02:14:17 ] >>803 String str = "abc"; byte[] ascii = str.getBytes("US-ASCII");
813 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 15:59:07 ] GDP で首都が決まるかよ。Ex. アメリカの都市を見よ スコアは高くてもしゃべれない、ということになりそう…
814 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 16:12:53 ] オーストラリアなんて当時メルボルンとシドニーが首都をめぐって揉めに揉めた末に その中間にあるキャンベラが首都になったという経緯があるくらいだしな
815 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 16:14:50 ] printf("わが国の2005年度のGDPがnになると仮定します。\n");
816 名前:org mailto:sage [2006/01/30(月) 16:16:20 ] printf("わが国の2005年度のGDPがyen;nになると仮定します。\n");
817 名前:org mailto:sae [2006/01/30(月) 16:16:54 ] ドロンするとします
818 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 16:18:20 ] ハワイ
819 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 16:25:09 ] まぁもし仮になるにしてもたぶんグアムと同じ扱いってことになるんじゃないか? もし選挙権ありだったら日本は票全体の1/3くらいを握ることになるからすごく優遇されるぞ
820 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 16:38:17 ] >>819 アメリカの選挙、特に大統領選の方式知ってる?
821 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 17:34:48 ] 日本はアメリカに常に YES なんだし選挙権いらないんじゃない?
822 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 17:57:12 ] スレタイ的にはUnicode追従という事でよろしいですね。
823 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 18:14:33 ] >>820 大統領選なら推薦人120人くらいになるんじゃない?ものすごく大きいと思うが。 まぁそうなるからもしアメリカに入るになっても選挙権はつけないとなるんだろうと言ってる。 そもそもアメリカに入るという話自体ありえないんだけどな。
824 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 18:16:36 ] もう属国だからね。
825 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 18:20:52 ] そんなに属国がいやならまずは核武装とエネルギー資源の確保をしないとなぁ・・・ あと食料自給率もどうにかしないと
826 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 18:24:00 ] 自民党が政権を持つ限りアメリカ追随のまま
827 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 18:27:00 ] 民主党になってもその点はほぼ同じだと思われ
828 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 19:30:19 ] 民主党の歴史を考えればな。つまり属国のまま。
829 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 20:18:18 ] アメリカの属国が嫌だという人間の大半は中国の属国にしたい奴か、鎖国したい奴のどっちか
830 名前:デフォルトの名無しさん [2006/01/30(月) 20:38:10 ] 自民党で括りなさんな。田中一族だって自民党だよ。
831 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 22:08:05 ] 戦争に全面的に協力して街壊してから 食料衣服もっていく日本の政治家達見てると ちゃんと義務教育とか終えたのか心配になっちゃうよね 靖国に感情的な奴もぐるだろうか、 今って太平洋戦争の時よりもあくどいように感じる 俺は零戦で突っ込む!誇りをもて!
832 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 22:10:24 ] お願いだからスレタイを見てください。
833 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 22:29:15 ] 世界征服して文字コードを強制統一スレが何か?
834 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 22:32:18 ] そりゃ中国とかモンゴルとかじゃね? 中国語は句読点が真中に来るのがどうも慣れない。なんだありゃ。
835 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 22:33:27 ] >833 まずは国内の統一からどーぞ
836 名前:デフォルトの名無しさん [2006/01/30(月) 22:46:06 ] 句読点を真中に打つのは台湾だけではありませんか。
837 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 23:22:49 ] 各国毎に文字コードを統一して、 それを UTF-64 に含めよう。
838 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 23:24:45 ] UCS64じゃなくて、UTF-64なんだ。
839 名前:デフォルトの名無しさん mailto:sage [2006/01/30(月) 23:41:51 ] そうやってちまちま 16→32→64 てな流れでやるから あ、やっぱり足りね!とかってことになんだよ! 思い切っていっきに1024ぐらいまでいっとけ、な?
840 名前:デフォルトの名無しさん [2006/01/30(月) 23:42:40 ] UTF64か。全ての人に1群(256面)づつ割り当てて自由に使わせても 1000年くらいは持つだろうな。足りなくなる前はUTF128とUTF256を 標準化すれば銀河の寿命が尽きるまで安泰というわけだ。
841 名前:デフォルトの名無しさん mailto:sage [2006/01/31(火) 00:04:25 ] せっかく自主憲法制定しても、UTF-8で符号化ですか? TRONコー(ry
842 名前:デフォルトの名無しさん mailto:sage [2006/01/31(火) 00:06:00 ] >840 銀河評議会辺りから「んなローカルな文字コード使ってんじゃねーよ田舎モン」言われそうだw
843 名前:デフォルトの名無しさん [2006/01/31(火) 03:13:28 ] UTF4096 UTF16384 UTF65536 UTF131072 UTF1M UTF1G UTF1T もはやここまできたら文字の図形そのまんま転送してるのと同じ。
844 名前:デフォルトの名無しさん mailto:sage [2006/01/31(火) 07:37:28 ] >>843 マジメな話、将来的には全部画像ファイルになるかもな。 各種記憶メディアの容量は馬鹿でかくなり続けてるし、 CP'Uに処理速度もアホみたいに速くなってればOCR処理も一瞬で終わるし、 画像ファイルならフォントがなくて表示できないだとか、 ロケールの違いでうまく表示・処理できないなんて類のことから解放されるし。
845 名前:デフォルトの名無しさん mailto:sage [2006/01/31(火) 07:57:49 ] OCRした結果は何コードにするの?
846 名前:デフォルトの名無しさん mailto:sage [2006/01/31(火) 08:09:04 ] >>845 UTF-1024
847 名前:デフォルトの名無しさん mailto:sage [2006/01/31(火) 15:16:28 ] コードなんて内部でも必要とせず、 常に画像データで持ち比較の場合は画像類似度で判定。
848 名前:デフォルトの名無しさん [2006/01/31(火) 16:33:59 ] 文字コードに「日ペンの美子ちゃん」が追加される時代がくる
849 名前:デフォルトの名無しさん mailto:sage [2006/01/31(火) 23:59:52 ] そんな英語圏の連中にとってオーバースペックにもほどがある代物は 一部の日本人の妄想の中にしか存在しません
850 名前:デフォルトの名無しさん mailto:sage [2006/02/01(水) 00:09:51 ] 表示と印刷に限ればPDFがすでに実現してる
851 名前:デフォルトの名無しさん mailto:sage [2006/02/01(水) 00:13:11 ] 検索も結構いけてる > PDF
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 みたいなことを お客さんに言われたことがあるよ。どうしようかと思ったw
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 ] 日本語を流暢に話す欧米人はそこそこみかけるが(TVでね) 仮名漢字交じりの文章をスラスラ書く欧米人は見たことないなぁ。
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 ] 夏期休暇でアメリカに行った際の出来事。 LAで信号待ちをしていると 気の良さそうな2人組のお兄さんが、 「おまえは 日本人か?」と気さくに聞いてきました。 「そうだ」と答えると、「漢字のタトゥー (刺青)を 彫ったんだけど、 どういう意味か教えろよ」と言われ、差し出された腕を見ると 『武蔵』と彫ってありました。 「日本で最も有名な剣豪だよ」と伝えると 彼は満面の笑みを浮かべていました。 続いてもう一人が腕を差し出すと そこには『朝鮮』と大きく彫ってありました。 「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! ( ⊂彡 | | し ⌒J
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 ] もとはといえば最初に常用漢字とJISが違うという縦割り行政丸出しの時点で もうだめだったな・・・
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レベルの投票だから、あと 1年半待て。
939 名前:デフォルトの名無しさん mailto:sage [2006/03/16(木) 09:09:00 ] iso-2022-jp-ms なんてデファクトでしょ。 Outlook Expressで、何の躊躇いもなく「@」とか送ってくる輩がゴマンといるし、 gooだのyahooだののwebメールで textarea に入れた「@」もメールでは同様に エンコードされる。 ただUnicodeと関わらない普通の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とか(w
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か(w
955 名前:デフォルトの名無しさん mailto:sage [2006/03/19(日) 21:29:27 ] >>954 > それってOutlookの問題っすか? 変換APIの問題だな。つーか実際にOutlookで転送を試してみた訳じゃなくて 変換APIの仕様から予想される挙動を書いただけだから。 > C1はつかっていないみたいだけど。 だから互換性がないんだってば。 > iso-2022-jp-udcか(w つーかそうやって何でもかんでも名前を付けたがる時点で終わってる。 文字コードは変換表ではない 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 ご紹介有難うございます。 その後ぐぐって説明を読んでいますが、想像以上に複雑怪奇ですね。 自分のアプリの機能の1つは、ファイルをダブル・クリックすると文字であろうが 絵であろうが内容を見て表示するということです。文字の場合はしかるべき変換を して 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
977 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 14:52:55 ] >>976 >Shift_JISはCP932 工エエ(´Д`)エエ工
978 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 15:04:25 ] なんでCP51932が使えないMultiByteToWideCharを出してんだろ…… CP51932がMultiByteToWideCharで使えないのってWindowsXPだけなんかな?
979 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 16:15:40 ] >>977 Shift-JISとCP932との違いを知らない人は相当いるよ。 あるいは知っていても大体同じだと言って区別をしない人も。
980 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 16:58:22 ] CP932と区別する場合は、Shift-JISではなくShift_JISと書きたい。
981 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 17:33:21 ] 旧マックは正しいShift-JIS?
982 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 17:38:15 ] 正しくないShift_JISはあるが、Shift-JISには正しいも正しくないもない。
983 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 17:49:20 ] >>980 Shift-JISとShift_JISとの違いを知らない人は相当いるよ。 あるいは知っていても大体同じだと言って区別をしない人も。
984 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 18:34:03 ] ShitJIS
985 名前:971,968 mailto:sage [2006/03/23(木) 18:39:30 ] >>976 ご助言を有難うございます。code page は GetACP() で済ませていまして 932 とかいうを知ったのはほんの数日前 VC++2005EE を使ってみてから。 WinAPI を使った変換は既に使っています。hex 表示でも右側に ascii 表示 をしますが、このときも SJIS, UTF-16, 純ascii、・・・ をマウスの 右クリックで変更可能にしないと何があるのか判別しにくいですから。 ただ、UTF は 16 しか対応していませんでした。というか GetACP() まかせ。
986 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 19:50:54 ] っていうか、Windowsで「Shift_JIS」って言っている時、 たいていShift_JISじゃなくてCP932じゃん。
987 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 20:20:48 ] 「Windowsで」とは?
988 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 20:00:46 ] それこそ、意味もわからず「Shift_JIS」と書いているんだろ。
989 名前:デフォルトの名無しさん mailto:sage [2006/03/25(土) 03:58:22 ] 文字コードの種類は何故複数あるのでしょうか? pc8.2ch.net/test/read.cgi/tech/1093251312/l50
990 名前:デフォルトの名無しさん mailto:sage [2006/03/26(日) 09:35:52 ] ↑
991 名前:デフォルトの名無しさん mailto:sage [2006/03/26(日) 09:39:05 ] ↑
992 名前:デフォルトの名無しさん mailto:sage [2006/03/26(日) 21:21:33 ] ↓ 文字コード総合スレ part2 pc8.2ch.net/test/read.cgi/tech/1143375639/ ↓
993 名前:デフォルトの名無しさん mailto:sage [2006/03/26(日) 21:31:10 ] ←
994 名前:デフォルトの名無しさん mailto:sage [2006/03/26(日) 21:48:06 ] ↓ ←
995 名前:985,971 mailto:sage [2006/03/27(月) 07:15:05 ] 教えて貰って UTF-16, UTF-8 の文書をファイル名ダブルクリックで表示するよう やってるんだが、rich edit control は EM_STREAMIN & SF_UNICODE で UTF-16 は表示するが、UTF-8 は無視される。VS C++2005EE では project.sin ファイル が UTF-8 なので、これで試しているが、手抜きだなあ。
996 名前:デフォルトの名無しさん mailto:sage [2006/03/27(月) 09:20:09 ] 出て行け
997 名前:デフォルトの名無しさん mailto:sage [2006/03/27(月) 11:48:18 ] 渡世人でごさんす。通りすがりでちょいとご挨拶したまでで、 長いは毛頭いたすつもりはありやせん。ご懸念なく。ヘイ。 おあにいさんもシマの見張りをご苦労さんでござんす。
998 名前:デフォルトの名無しさん mailto:sage [2006/03/27(月) 13:07:15 ] UTF-8 と UTF-16 は別物。 SF_UNICODE の 「UNICODE」 は UTF-16 のことだから、UTF-8 が認識されないのは当たり前。
999 名前:デフォルトの名無しさん [2006/03/27(月) 15:35:15 ] 次スレは?
1000 名前:デフォルトの名無しさん mailto:sage [2006/03/27(月) 15:37:16 ] 文字コード総合スレ part2 pc8.2ch.net/test/read.cgi/tech/1143375639/
1001 名前:1001 [Over 1000 Thread] このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。