文字コード統一スレ 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 152 名前：デフォルトの名無しさん mailto:sage [2005/05/11(水) 22:59:31 ] セミナー：　CJKV 日中韓越情報処理 ttp://www.jtpa.org/event_in_silicon_valley/000285.html 講演は英語だってさ。 153 名前：デフォルトの名無しさん mailto:sage [2005/05/11(水) 23:16:08 ] 最近（でもないか?）CJKV って聞く様になったけど、何で越南だけ追加されたんだろう 154 名前：デフォルトの名無しさん mailto:sage [2005/05/12(木) 00:42:46 ] >>151 OSXは現状で合成に対応してます。 ATSUIは正しくレンダリングするし、区切り判定も合成文字を１文字と 認識します。 このスレでも散見されるけど、合成対応は意味がないから無視という姿 勢のアプリケーションではだめですね。 155 名前：デフォルトの名無しさん mailto:sage [2005/05/12(木) 00:52:27 ] >154 おお。なかなか。 ところでデーヴァナーガリーなんかのリガチャはどうなるんだっけ? あれを一律「一文字」にされると古典を扱うときヽ(`Д´)ﾉｳﾜｧｧﾝなことになるんでちと気になって。 156 名前：デフォルトの名無しさん mailto:sage [2005/05/12(木) 05:16:53 ] >>151 青空文庫の中の人によればShift_JIS-2004には未対応 www.siesta.co.jp/aozora/archives/001145.html これは去年の話だからもしかしたらTigerは対応したのかもしれないが そこまでは知らん 157 名前：デフォルトの名無しさん mailto:sage [2005/05/12(木) 07:51:51 ] 包摂に対する考え方が、JISとUnicodeは違うけど、 2004なら追加文字で問題がなくなる→JIS X 0213対応ってわけ? 158 名前：デフォルトの名無しさん mailto:sage [2005/05/12(木) 11:10:39 ] >>150 いまはまだ過渡期とはいえ、Unicode でレパートリが揃い、使えれば 「JIS X 0213:2004 対応」と言う段階に入ってきていると思う。 少なくとも、ジャストシステムが「JIS X 0213:2004 対応フォント」 と言うときには、その意味で使っている。 このフォントで、Shift_JIS-2004 のテキストが表示できるわけじゃない。 ATOK2005も「Unicodeを使うJIS X 0213:2004 対応」での入力手段。 >>119 にあるように、規格作成当事者からも > JIS X 0213の「エンコーディング」を捨ててしまう は追認されてる。 159 名前：デフォルトの名無しさん mailto:sage [2005/05/12(木) 12:45:04 ] 蛇足だけど、Unicode マンセーって言ってるわけじゃない。 Unicode導入とは非関税障壁撤廃が進んでいるというだけのこと。 ただ、それで便利にできる所は利用する。 中国の方が日本より上手に対応してきた。 160 名前：デフォルトの名無しさん mailto:sage [2005/05/12(木) 19:35:44 ] >>159 > 中国の方が日本より上手に対応してきた。 これマジレス? 161 名前：デフォルトの名無しさん mailto:sage [2005/05/13(金) 04:48:38 ] つまり中国を見習って、Unicodeの全文字を含み1文字最大4バイトで表現する 新しい文字集合とエンコーディングをJISで定義して、全ての市販ソフトに その採用を義務付けろと主張するわけだな? >159 162 名前：デフォルトの名無しさん mailto:sage [2005/05/13(金) 17:44:09 ] 超漢字マンセー 163 名前：デフォルトの名無しさん mailto:sage [2005/05/13(金) 20:15:32 ] GB18030の影響でMeは発禁 164 名前：デフォルトの名無しさん mailto:sage [2005/05/13(金) 20:21:36 ] >>157 2004で追加された以外の文字ではまだ問題が残ってる。 JISとUnicodeで包摂規準が明らかに矛盾してる文字の一覧とか 調べてみたいんだが面倒で挫折中。 165 名前：デフォルトの名無しさん mailto:sage [2005/05/13(金) 20:24:14 ] >>160 波ダッシュはチルダではないとか意地を張ったりしないで GBKをそのまんま追認した点とか。 166 名前：デフォルトの名無しさん mailto:sage [2005/05/13(金) 23:40:13 ] >>165 > 意地を張ったりしないで これってマジレス? 167 名前：デフォルトの名無しさん mailto:sage [2005/05/14(土) 10:14:12 ] >>155 複雑なリガチャ付き文字はマウス操作やカーソルキー移動では１文字扱いですが、 デリート時は適度に分割されて扱われます。 Devanagariは理解できないので実装の正確さは判断できません。 OSX標準の状態でもDevanagariを扱うためのリソースは揃っていますので、実物で 確かめてみて下さい。 168 名前：デフォルトの名無しさん mailto:sage [2005/05/16(月) 20:57:28 ] >>166 94x94の表の空き領域にも全部PUAへの写像を定義した点とか 169 名前：デフォルトの名無しさん mailto:sage [2005/05/16(月) 21:41:37 ] Unicode 4.1でU+2B00とU+2B01、U+2B08とU+2B09のグリフが入れ替わった件について www.unicode.org/versions/Unicode4.1.0/erratafixed.html 170 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 15:31:46 ] >>169を見て気づいた。 Code2001のU+1D301〜U+1D303の実装がおかしい。 171 名前：デフォルトの名無しさん mailto:sage [2005/05/18(水) 06:35:24 ] 実はU+1D300〜U+1D305の文字名で地と人が入れ替わってる件について 172 名前：デフォルトの名無しさん mailto:sage [2005/05/18(水) 11:17:35 ] >>171 academy3.2ch.net/test/read.cgi/gengo/1040929046/170 173 名前：デフォルトの名無しさん mailto:sage [2005/05/18(水) 20:23:41 ] >>172 つーかそれ書いたの漏れ。 U+3020のナンバー君がMeiryoでポストン君に変わってる件について www.post.japanpost.jp/zipcode/zipmanual/image/052-1.jpg これは包摂の範囲なんですか? U+3004のJISマークもそのうち変わりますか? www.jisc.go.jp/newjis/newjismknews.htm ちなみにユーロ記号はデザインが変わったとき新たにコードを割り当てられた。 まあUnicodeの欧米偏重は今に始まったことじゃないけど 174 名前：デフォルトの名無しさん mailto:sage [2005/05/18(水) 21:12:03 ] この際だから>>169も解説しちゃおう U+2B00〜U+2B0Dの矢印類はKPS 9566をソースに北朝鮮が追加提案した(N2056)。 std.dkuug.dk/jtc1/sc2/wg2/docs/n2056/J1n599903.pdf このときの並び順は右上→左上の順だった。 すくなくともPDAM2まではその順だったのだが(N2395)、 std.dkuug.dk/jtc1/sc2/wg2/docs/n2395.pdf FPDAM2になってなぜか突然グリフの順番が左上→右上に入れ替わった。 std.dkuug.dk/jtc1/sc2/wg2/docs/n2491.pdf 後から説明しているところによると(N2926 T.7とか)、Unicodeの他の矢印では 左上→右上だったからそれに合わせたかったのだろうとか。 でもFPDAM2で入れ替えたのはグリフだけで、名前を入れ替え忘れて(証拠は N2491のチャートに残ってる)、そのままAmendment 2=Unicode 4.0 BMPに なってしまった。 正式にAmendmentになってしまった以上もう名前は変えられないので グリフを入れ替えることにした(N2926)。 std.dkuug.dk/jtc1/sc2/wg2/docs/N2926.pdf もうアホかと。 175 名前：デフォルトの名無しさん mailto:age [2005/05/20(金) 11:49:25 ] ユニコードHPが見られなくなっているんですが、 自分だけでしょうか･･･。 Unicode Home Page www.unicode.org/ 176 名前：デフォルトの名無しさん mailto:sage [2005/05/20(金) 12:52:42 ] >>175 世界中であなただけです。 177 名前：デフォルトの名無しさん mailto:sage [2005/05/25(水) 22:49:03 ] Ideographic Variation Sequencesキター www.unicode.org/reports/tr37/tr37-1.html # 例によって日本はシカトして事実上中国のSimplified Variant専用になる予感 178 名前：デフォルトの名無しさん [2005/05/28(土) 20:45:42 ] >>175 一週間以上たってるが、俺も見れねぇ。 179 名前：デフォルトの名無しさん mailto:sage [2005/05/28(土) 23:26:48 ] 今見られるよ ちなみに Announcements のトップは UCB の記事で 2005.05.06 の日付け 180 名前：デフォルトの名無しさん mailto:sage [2005/05/28(土) 23:27:12 ] 2005.05.09 だったorz 181 名前：デフォルトの名無しさん mailto:sage [2005/05/31(火) 09:50:40 ] サロゲートペア、動作テスト中 呼吸深く𠹭囉仿謨(コロロホルム)や吸ひ入るる――北原白秋 呼吸深く��囉仿謨(コロロホルム)や吸ひ入るる――北原白秋 182 名前：デフォルトの名無しさん mailto:sage [2005/06/02(木) 15:10:19 ] サロゲートペア対応 Netscape ○ Firefox ○ MS IE6 × 183 名前：デフォルトの名無しさん mailto:sage [2005/06/02(木) 17:54:59 ] >>182 IEはレジストリ弄る必要がある　ウチはIEで表示出来てるぞ 184 名前：デフォルトの名無しさん mailto:sage [2005/06/03(金) 12:05:48 ] >>183 そうだったのか、知らなかった。と、調べてみたものの、よくわからなかった。 レジストリの弄り方、教えて下さいませ。 185 名前：184 mailto:sage [2005/06/03(金) 12:50:10 ] おっと、「non BMP対応」を説明した charset.info/surrogate.html を発見。 ここの「レジストリを修正してフォントを指定する」をやったら IEで無事に表示できました。 186 名前：デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:21:15 ] >>157 >>164 Unicode での JIS X 0213対応で問題として残っているのは、包摂規準以外にもありそう。 JIS X 0213 の文字の中には、完成形での収録が認められず、 「文字合成」で表現することになった文字が25文字ある。 charset.info/composite.html ここにある。 １文字だけでは表現することができない文字があるわけで、 表現するには合成可能な「結合文字」を使わなければならないんだが、 これを全部正しく処理できるシステムとフォントという条件は、かなり敷居が高い。 表示できても、「正規化」に対応していないと問題が起こるし。 今は厳しすぎかも。とりあえず Y.OzFont4 がベストなのかな。 Macならうまくいくか? 187 名前：デフォルトの名無しさん mailto:sage [2005/06/26(日) 13:37:37 ] >>186 それは規格に適合してない処理系だから、 >>157>>164の話とはレベルが全然違うでしょ 188 名前：デフォルトの名無しさん mailto:sage [2005/06/26(日) 14:14:45 ] そう。「規格に適合してない」という実装の問題が一つあって、 これは、きちんと実装されれば解決の話。確かにレベル違うな。 一方、U+309Aの合成可能な半濁点を使わなければ、鼻濁音等が表現できないんだが、 これは JIS X 0213にはなかったりするズレは、 やはり Unicodeと JIS X 0213の関係の問題でもあるんじゃないかと 思ったりするが、どんなもんなんでしょう。 JIS X 0213:2004対応を言うジャストシステムの平成書体で、 U+309A が合成可能になっていないのはバグだろうか。 189 名前：デフォルトの名無しさん mailto:sage [2005/06/26(日) 14:25:37 ] ジャストシステムの書体使ってるけどU+309Aはちゃんと合成できるよ (ただしJIS X 0213に規定されてる組み合わせだけ) そんなことよりこの書体の問題はU+02EFとU+02F0に規格違反の文字が 入ってること 190 名前：デフォルトの名無しさん mailto:sage [2005/06/26(日) 14:37:07 ] U+02EFとU+02F0 にこれがあるのは知らなかった。 Y.OzFont4 もここに同じグリフがあるんだけど、どうしてなんでしょう? 事情おしえて。 191 名前：デフォルトの名無しさん mailto:sage [2005/06/26(日) 14:48:24 ] あれ。 U+02EF MODIFIER LETTER LOW DOWN ARROWHEAD U+02F0 MODIFIER LETTER LOW UP ARROWHEAD となってて、どちらも Introduced in Version: 4.0 とある。 規格になったんじゃないでしょか。 192 名前：デフォルトの名無しさん mailto:sage [2005/06/26(日) 14:59:41 ] 規格になっているのなら、 これとJIS X 0213の声調記号 1-11-69 (U+02E9 U+02E5) と 1-11-70 (U+02E5 U+02E9) が 文字合成でできたりすることとの関係は、どうなってんだろう。 同じなら、どっちが正規化形式なのか調べておこう。 193 名前：デフォルトの名無しさん mailto:sage [2005/06/26(日) 15:10:33 ] >>190-192 U+02EF MODIFIER LETTER LOW DOWN ARROWHEAD U+02F0 MODIFIER LETTER LOW UP ARROWHEAD はUnicodeのチャート見れば分かるけど www.unicode.org/charts/PDF/U02B0.pdf JIS X 0213の1-11-69、1-11-70とはまったく違う文字。 じゃあ何でY.OzFont4やジャストシステムの平成書体がそこにグリフ入れてるかというと たぶんJIS X 0213:2000のカッコ付きUCSがその値だったからだと思うけど Unicode的には完璧に違反。 194 名前：デフォルトの名無しさん mailto:sage [2005/06/26(日) 15:12:07 ] ちなみにカッコ付きUCSは単なる「参考」であって、 JIS X 0213:2000では1-11-69、1-11-70には対応するUCSは存在しないと 「規定」されていたので、いちおう違反はしていないという建前 195 名前：デフォルトの名無しさん mailto:sage [2005/06/26(日) 15:30:57 ] なるほど。 合成の方の 1-11-69 (U+02E9 U+02E5) と 1-11-70 (U+02E5 U+02E9) とは Unicode 的には無関係ということか。 こういうケースも、包摂範囲とは認められない違反となるのか。 でもって、これらのフォントでは、無関係だけどグリフ置換でこれを使うために、 あえてこの形で置いてあるわけかな。 196 名前：デフォルトの名無しさん mailto:sage [2005/06/26(日) 15:42:34 ] いやこの場合まったく包摂の余地ないし。なんでもかんでも多重にグリフを付与できる 魔法の言葉じゃないですよ? グリフ置換するためにコードを与える必要はない。 Y.OzFont4は独自仕様であえて与えている(技術的問題ではない)と作者が明言している。 ジャストシステムのほうは知らないけど。 197 名前：デフォルトの名無しさん mailto:sage [2005/06/26(日) 15:47:45 ] そうなんだ、いろいろ教えてもらいました。ありがとう。 198 名前：デフォルトの名無しさん [2005/06/29(水) 09:18:53 ] "こんにちは"とだけ書いたUTF-8なテキストファイルを作成するコンソールプログラムを作りたいのです。 環境はMSVC6.0でして、プリプロセッサ定義の_MBCSを消去して_UNICODEとUNICODEを追加し、リンクオプション・エントリポイントには「wmainCRTStartup」を設定しました。 結果は文字化けしたものが出力されてしまいます。何がいけないのかご教授願えますでしょうか。 #define tstring wstring #define tofstream wofstream // IMBUE_NULL_CODECVTマクロについては　ttp://www.codeproject.com/vcpp/stl/upgradingstlappstounicode.asp） // からコピーしました。長いので略します。 void _tmain(int argc, TCHAR* argv[], TCHAR* envp[]) { USES_CONVERSION; tofstream zFileOut ; IMBUE_NULL_CODECVT( zFileOut ) zFileOut.open( "C:\\temp\\test.txt", ios::out|ios::binary ) ; zFileOut << _T("こんにちは"); } 199 名前：デフォルトの名無しさん mailto:sage [2005/06/29(水) 18:34:44 ] >>198 そもそもそこのURLの中にUTF-8という言葉も出てこなし、UTF-16から8への変換をしているコードも見当たらない。 肝心のクラスもNullCodecvtっていかにも何もしなさそうな名前だ。（実際そうだし） つまりそこのはASCII限定だろ。 200 名前：198 [2005/06/30(木) 11:09:52 ] >>199 すみません、UTF-8とUTF-16の違いもわかっていませんでした。 少し調べたのですが、UNICODEは文字セットの呼称、そのためのエンコード方式にUTF-8（可変マルチバイト）, UTF-16（固定マルチバイト）などがある、ということでよいでしょうか。 また、リンク先の記事では、メモリ中のUNICODE（16ビット固定？）の文字をwfstreamでファイル出力すると ASCII文字のコードが8ビットにされてしまうことが問題にされているのですね。 質問を変えさせてください。 (1)　"<?xml version="1.0" encoding="UTF-8"?>"といったようにUTF-8が指定されているXMLファイル がありますが、これはそのファイル自体の文字コードがUTF-8でなければならないことを意味するのでしょうか。 (2) STLのfstreamでUTF-8形式のファイルを作成したいのですが以下のコードでは うまく行きません。解決方法をご教授願えませんでしょうか。 （環境はMSVC6です。プリプロセッサで"_UNICODE"を定義したうえエントリポイントも 先の投稿の通り変更しています。） void _tmain(int argc, TCHAR* argv[], TCHAR* envp[]) { wofstream zFileOut ; zFileOut.open( "C:\\temp\\test.txt", ios::out) ; zFileOut << _T("こんにちは");} } 201 名前：デフォルトの名無しさん mailto:sage [2005/06/30(木) 11:47:11 ] (1) ファイルは別のエンコーディングでも構わない。 ただ、そのXMLデータの場合、処理系が解釈する場合はUTF-8と想定する。 処理系に渡す際、UTF-8エンコーディングに変換するのは、 XML処理系を含むシステムの責任。 例えば、JIS X 0208に含まれる文字しか使われていないとして、 ファイルはShift_JIS, EUC-JP, ISO-2022-JPエンコーディングで、 処理系に渡す際に(encoding="UTF-8"と宣言されているので)UTF-8に変換して 渡すシステムも一向に問題がない。 これは例えばhttpによるContent-Type: text/xml; charset=XXXも場合も同様。 www.w3.org/TR/2004/REC-xml-20040204/#sec-guessing-with-ext-info ドキュメントエンティティと外部表現の違い。 ドキュメントエンティティがどのような外部表現をもつかXMLの仕様が関与するところではない。 202 名前：デフォルトの名無しさん mailto:sage [2005/06/30(木) 13:19:15 ] >>200 (1)XMLパーザにそのファイルをそのまま渡すのなら、UTF-8でなければ ならない。201さんも書いているようにUTF-8でなくてもいい場合も あるけど、ややこしいのでUTF-8にしときなさい。 (2)Windowsだったら WideCharToMultiByte(CP_UTF8, 0, L"こんにちは", -1, dest, destlen, NULL, NULL); てな感じでUTF-8にしてからofstream(wofstreamではない)に出せばいい んじゃないかな。C++標準の範囲でUTF-8化できるかどうかは知らない。 203 名前：デフォルトの名無しさん mailto:sage [2005/06/30(木) 14:33:53 ] 上のURL本文のプログラムは、確かにUTF-8化ができる様子ないな。UTF-16だけでしょ。 あとのスレッド www.codeproject.com/vcpp/stl/upgradingstlappstounicode.asp#xx557556xx の codecvt_UTF16_to_CESU8 あたりがUTF-8化のものなのか、試したら。 ここのCESU-8とか"UTF-8 light"って、どんなものかは知らないが。 204 名前：デフォルトの名無しさん mailto:sage [2005/06/30(木) 15:11:37 ] CESU-8 で検索するといろいろ出るな。 UTF-8 ならsarrogate対応を4バイトでするところを、 3バイト×2 = 6バイトにしておく方法か。 205 名前：デフォルトの名無しさん mailto:sage [2005/06/30(木) 20:53:59 ] CP_UTF8にはセキュリティホールがある罠 206 名前：デフォルトの名無しさん mailto:sage [2005/06/30(木) 21:11:09 ] KPS9566を拡張すれば結構いい感じの文字コードになるかも。 207 名前：デフォルトの名無しさん mailto:sage [2005/06/30(木) 21:25:28 ] KPS9566ってどっちかというと最悪に近いと思うけど (将軍様専用ハングルの件は置いたとしても) 208 名前：デフォルトの名無しさん mailto:sage [2005/06/30(木) 21:39:54 ] そうかもしれんな… 209 名前：デフォルトの名無しさん mailto:sage [2005/06/30(木) 22:15:25 ] >>205 マジ？ 210 名前：デフォルトの名無しさん mailto:sage [2005/06/30(木) 22:34:43 ] 詳しくはほぼ前スレに書いた 211 名前：デフォルトの名無しさん mailto:sage [2005/06/30(木) 22:43:07 ] >>210 読んだ。なるほどと思った気がする。 212 名前：198 [2005/07/01(金) 08:51:51 ] アドバイスありがとうございます。 (1)については了解いたしました。ファイルはUTF-8のエンコーディングで行きたいと思います。 >>202 以下のようなコードを試して見ましたがやはり文字化けしたものが出力されます。 （結果のファイルをWinのノードパッドでUTF-8形式でオープンして確認しました。） void _tmain(int argc, TCHAR* argv[], TCHAR* envp[]) { ofstream zFileOut; char dest[1024]; WideCharToMultiByte(CP_UTF8, 0, L"こんにちは", -1, dest, 1000, NULL, NULL); zFileOut.open( "C:\\temp\\test.txt", ios::out ) ; zFileOut << dest << endl; } デバッガではdestのアドレスに以下のようなコードが書き込まれていました。 E2 80 9A C2 B1 E2 80 9A C3 B1 E2 80 9A C3 89 E2 80 9A C2 BF E2 80 9A C3 8D 00 ちなみにC形式でのFILEを用いて出力してみましたが、まったく同じ結果が得られました。 >>203 こちらも試しましたがやはり文字化けしてしまいます。 なにかさらにヒントがあればご教授ください、、、。 213 名前：デフォルトの名無しさん mailto:sage [2005/07/01(金) 09:22:44 ] そのソースは何エンコーディングでファイルに保存されているの? WideCharToMultiByte()のWideCharっていうのは、そのエンコーディングのことなの? # なおそのAPIのことは全然知りません。 214 名前：デフォルトの名無しさん mailto:sage [2005/07/01(金) 10:32:39 ] >>212 こぴぺして試したらきちんとUTF-8で保存されていた。 ソースはSHIFT-JISで保存。 215 名前：デフォルトの名無しさん mailto:sage [2005/07/01(金) 11:06:51 ] いろいろやって出来ればいいんだけど、 その場合、UTF-8にしたくて標準C++の範囲でよいなら、簡単な話としては、 ソースファイルをUTF-8で保存してコンパイルが通るか、という問題なんじゃないの。 MSVC Toolkit 2003(フリーのやつ)でやる限り、 入門的な標準C++プログラムをUTF-8(ただしBOM付き)で保存すれば、 > "こんにちは"とだけ書いたUTF-8なテキストファイルを作成するコンソールプログラム は出来てしまうんだけどね。MSVC6.0は知らないけど。 gcc だと、BOMなしのUTF-8にすればコンパイルできるようだな。 216 名前：デフォルトの名無しさん mailto:sage [2005/07/01(金) 12:54:33 ] >>214 そのコンパイラはShift_JISを理解して、 wchar_tなL"こんにちわ"の文字列リテラルを構成するんだね。 wchar_tはUCS-2なのかな? 217 名前：デフォルトの名無しさん mailto:sage [2005/07/01(金) 13:34:10 ] >>212 たしかに、おかしいね。 L"こんにちは" が期待通りの値になってないのかな? 218 名前：デフォルトの名無しさん mailto:sage [2005/07/01(金) 13:50:23 ] WideCharToMultiByte() というのは、名前は変だけど、 エンコーディング変換をするWin32APIを使っているんでなかったっけ。 219 名前：デフォルトの名無しさん mailto:sage [2005/07/01(金) 17:04:02 ] >>212 俺はそのコードでうまくできたけど。 220 名前：デフォルトの名無しさん mailto:sage [2005/07/01(金) 21:24:42 ] VC6とBCC5.5ではうまくいくことを確認した。 どちらもソースはSHIFT-JISで保存。 221 名前：198 mailto:sage [2005/07/01(金) 22:21:50 ] アメリカに在住しておりまして、返事が遅くなりすみません。 コードを試していただいた方々ありがとうございました。 大切なことを言い忘れていましたが、私の環境は英語版XP上の英語版MSVC6なんです。 XPのシステムロケールはJapaneseにしています。 （コントロールパネル->Regional and Language Options->Advancedタブ->Language for non-Unicode programsにJapaneseを指定） ソースファイル自体はSHIFT_JISで保存されているように思われます。 （Meadowのモード行でSと表示されています。） 222 名前：デフォルトの名無しさん mailto:sage [2005/07/01(金) 22:31:56 ] いっそのこと、自前で書いてしまうのはどうか？ UTF16とCESU-8の相互なら大した手間ではないと思う。 223 名前：デフォルトの名無しさん mailto:sage [2005/07/01(金) 23:57:27 ] >>221 L"申し上げます"がメモリ内でどうなっているか、hex dumpするとどうなってる? $ printf 申し上げます | iconv -f euc-jp -t shift_jis | hexdump -C 00000000 90 5c 82 b5 8f e3 82 b0 82 dc 82 b7 |.\..........| つーわけで2byte目がbackslashなんだけど処理できている? 出来てないならコンパイラがShift_JISを扱えないね。 224 名前：デフォルトの名無しさん mailto:sage [2005/07/02(土) 00:30:55 ] echo "こ"(cp932で"82 B1") | iconv -f cp1250 -t utf-8 | hex E2 80 9A C2 B1 cp1251でもcp1252でも同じだからそういったヨーロッパ言語を使うようになってんじゃないの。 vcがosの言語の設定を見てないのか、設定方法が間違ってるか...。 225 名前：198 mailto:sage [2005/07/02(土) 07:25:45 ] >>222 私の技量ではちょっと遠慮したい感じです。 >>223,224 確かに224さんの"こ"のメモリダンプ結果が私がデバッガで見たものと同じですね。 > vcがosの言語の設定を見てないのか、設定方法が間違ってるか...。 みたいですね。XPのシステムロケール以外に設定する項目を知らないのですが、 いずれにしてもプログラム的には問題なさそうなので（みなさんの環境では動いているようですし）、 設定あたりの線で調べてみたいと思います。ありがとうございました。 226 名前：デフォルトの名無しさん mailto:sage [2005/07/02(土) 08:18:33 ] 日本版のVC++が特別版(Shift_JIS対応)ってことはないかな? 　wchar_t *p = L"申し上げます"; 　for (char *q = (char *)p; *q != '\0'; q++) { 　 printf("%02x ", *q); 　} printf("\n"); するとどうなるの? 227 名前：198 mailto:sage [2005/07/02(土) 10:35:50 ] 英語版MSVCのソースエディタ内で「申し上げます」とタイプすると変換を確定した時点で 「\し繧ｰます」などと表示されてしまいます。Meadowで編集した上でセーブし（この際には一応 SHIFT_JISでセーブされているように見えます）、コンパイルすると warning C4129: '�' : unrecognized character escape sequence というwarningが出ます。warningをコピペしましたが'\202'は画面上では'・'のように見えます。 一応ビルドは終了するので実行するとコンソールには ffffff90 と表示されました。何かおわかりになりますでしょうか。 228 名前：198 mailto:sage [2005/07/02(土) 10:38:11 ] >「\し繧ｰます」などと表示されてしまいます。Meadowで編集した上でセーブし（この際には一応 MSVCのエディタでは「申し上げます」が入力できないので、代わりにMeadowで編集した、という意味です。 229 名前：223=226 mailto:sage [2005/07/02(土) 12:28:48 ] >>227 そのコンパイラ/統合環境はShift_JIS対応じゃないです。 「申」の2byte目にあるbackslashを処理できてない。 m18nされてないのでしょう。 一応、L"文字列"を解釈しようとしているようですが。 とりあえずヘルプを読んだ方が良さそう。 実はwchar_t文字列リテラルに対応してないか、UTF-8辺りに固定なのか。 230 名前：デフォルトの名無しさん mailto:sage [2005/07/02(土) 22:16:29 ] VCのコンパイラは日本語版でもShift_JISにL10Nされてるだけで、UTF-8すら使えない。 英語版だとどんなMBCSも使えないんでは。 231 名前：223=226 mailto:sae [2005/07/03(日) 01:13:29 ] 日本版は過去の経緯という事情でShift_JISオンリーになっていても、 米版はUTF-8利用可能という可能性がないでもないが…さて 232 名前：デフォルトの名無しさん mailto:sage [2005/07/03(日) 03:04:22 ] どのバージョンか忘れたけどutf-8なソースをコンパイルしようとすると 「utf-8には対応してません」的なメッセージを出してたときがあったな。 .NET Framework SDK v2.0のcl.exeを試してみたら cp932のソースは問題なくコンパイルできた。 utf-8のソースはBOMなしだとcp932として扱うみたい(つまり文字コードの判定はしない)。 BOM付きだとutf-8として認識した。ただし、 char str[] = "こんにちは"; みたいな普通の文字列はcp932に変換された状態でstrに入る。 ワイド文字リテラル(L"こんにちは")は正しく変換された。 233 名前：デフォルトの名無しさん mailto:sage [2005/07/03(日) 07:12:37 ] WindowsはそもそもUTF-8なMBCSはサポートしてないからな 234 名前：デフォルトの名無しさん mailto:sage [2005/07/03(日) 09:15:51 ] cp65001とかあるし脈はあると思うけどね。実際にちょっとだけ機能するし。 sjis依存なコードがたくさんあるから実用できないだろうけど。 235 名前：デフォルトの名無しさん mailto:sage [2005/07/04(月) 05:25:45 ] 残念ながらシステムのコードページとしては利用できない。APIの仕様上不可能。 たとえばWM_IME_CHARは1文字が3バイト以上になることをまるっきり考慮してない。 (64ビットWindowsならWin16を捨てたから実装可能かも) *.nlsは1文字2バイト以下のDBCS←→UCS-2の変換しかサポートできない構造だし。 GB18030も同様にシステムのコードページには設定できない。 236 名前：デフォルトの名無しさん mailto:sage [2005/07/04(月) 09:32:17 ] 今のVC++2003のサブセットにあたる VC++ Toolkit 2003はフリーダウンロードだから、 試す価値ある。英語版しかないから、日本でもこれ使ってるよ。 msdn.microsoft.com/visualc/vctoolkit2003/ これはUnicodeのソースファイルを解釈できる。 UTF-8 でも UTF-16 でもいい。ただし、BOMがないと判定に失敗して コンパイルエラーになることが多い。 この場合、C++でやる限り、文字列リテラルやstringは、 実行ファイル内ではUTF-8になっている。 だから、ofstream のファイル出力もUTF-8になる。 cout出力からファイル名・パス名までUTF-8になってしまうので、注意いるが、 リダイレクトでUTF-8を得るには好都合な時もある。 ソースがUTF-16でも結果はUTF-8。ソースがShift_JISなら結果もShiff_JIS。 237 名前：デフォルトの名無しさん mailto:sage [2005/07/04(月) 10:18:14 ] > 実行ファイル内ではUTF-8になっている。 "UTF-8の文字列リテラル" L"UTF-8の文字列リテラル" のどっちが? 238 名前：デフォルトの名無しさん mailto:sage [2005/07/04(月) 10:54:25 ] これは標準C++と.NET Frameworkだけがサポートされるバージョンだから、それが前提で "UTF-8の文字列リテラル" の方 239 名前：238 mailto:sage [2005/07/04(月) 12:27:54 ] 簡単なサンプルさらしちゃえば、これをUTF-8(BOM付き)かUTF-16で保存して実行すれば、 UTF-8(BOM付き)のテキストができる、ということで。 標準C++だけの VC++ Toolkit 2003では、文字列に L つけたらエラーになっちゃう。 #include <iostream> #include <fstream> #include <string> using namespace std; int main() { char bom[] = {0xEF, 0xBB, 0xBF}; // UTF-8のBOM string s = "こんにちは。𠹭囉仿謨はnon-BMPテスト"; ofstream out("test.txt"); out.write(bom, 3); out << s << endl; } 240 名前：デフォルトの名無しさん mailto:sage [2005/07/04(月) 14:14:43 ] >>238 要するに「何もしてない」って事だと思うが、 BOMがないとどうしてコンパイルエラーになるんだろう… 一応コードポイントの有効範囲くらいは調べているのだろうか。 241 名前：デフォルトの名無しさん mailto:sage [2005/07/04(月) 21:29:12 ] シグニチャが無いと、Shift_JISだとしてリテラル解釈するから 文字列が不完全になってコンパイルエラーになるのよ。 シグニチャありだと一応そこら辺を処理しているように見えるけど、 実はLatinとして扱っているだけという可能性もある。 242 名前：デフォルトの名無しさん mailto:sage [2005/07/05(火) 08:44:25 ] >>241 えーと、では、>>236にあるように英語版しかないけど、 そのコンパイラはソースのエンコーディングをShift_JISとして解釈するって事ですか? OSのロケールにしたがって、l10n処理しているんでしょうか。 "申"とか大丈夫なのかな? (2byte目がbackslashだけど) 243 名前：デフォルトの名無しさん mailto:sage [2005/07/05(火) 09:09:02 ] BOMがないとシステム設定のコードページを優先して、 Unicodeエンコーディングの判定はBOM付けてくれれば可能だから、 BOMなしのときは、Unicodeだとの判定は絶対確実でないとされないのかな、 とか推測してみたりする。 244 名前：デフォルトの名無しさん mailto:sage [2005/07/05(火) 09:21:52 ] >>243 Windowsはメモ帳なんかもBOM付けるから、その仕様だと自然な感じですね。 245 名前：デフォルトの名無しさん mailto:sage [2005/07/05(火) 11:02:30 ] VisualStudio 2003付属のCL.exeは、シグネチャ付きUTF-8のソースなら MBCS文字列もワイド指定付き文字列も、ちゃんと処理しているみたいよん。 246 名前：デフォルトの名無しさん mailto:sage [2005/07/05(火) 13:08:36 ] >>239 のサンプルコードは、Cygwin版のgcc や MinGW でも、 BOM無しUTF-8で保存してコンパイルできた。結果は同じ。 こちらは、どうエンコーディング判定してるのかな。 247 名前：デフォルトの名無しさん mailto:sae [2005/07/05(火) 13:20:00 ] gccのmbchar拡張がなければ、{ 　gccはBOMさえ外してあればスルーでしょ。要するに判定なし。 　これはどの環境でも同じ。 } 248 名前：デフォルトの名無しさん mailto:sage [2005/07/05(火) 13:37:26 ] そうでしたか。判定しなくていい仕様なのか。 249 名前：デフォルトの名無しさん mailto:age [2005/07/30(土) 15:58:16 ] マイクロソフトは「Windows Vista」で日本語フォント環境を一新。 JIS X 0213:2004規格に対応するとともに、 画面上での可読性を大幅に向上させるまったく新しいデザインのフォント（フォント名：メイリオ） 開発を開発中と発表。 ttp://www.microsoft.com/japan/presspass/detail.aspx?newsid=2353 ttp://pc.watch.impress.co.jp/docs/2005/0729/ms.htm ttp://www.itmedia.co.jp/news/articles/0507/29/news049.html 【社会】"混乱大丈夫？" 次期OSウィンドウズ・ビスタで漢字１５０字形を変更 ttp://www.yomiuri.co.jp/national/culture/news/20050729i306.htm news19.2ch.net/test/read.cgi/newsplus/1122621294/l50 Windows Vista 日本語フォント環境を一新 pc8.2ch.net/test/read.cgi/pcnews/1122649116/l50 250 名前：デフォルトの名無しさん mailto:sage [2005/07/30(土) 16:07:47 ] >>249 Visa、 XP以前の混在企業システム環境だと、オワットル。 251 名前：デフォルトの名無しさん mailto:sage [2005/07/30(土) 16:17:04 ] ＞開発を開発中 ＞Visa 252 名前：デフォルトの名無しさん mailto:sage [2005/07/30(土) 19:29:27 ] よろこんでコピペする前に>>122-あたりから嫁 さんざん既出だし前の字体が使えなくなるなんてこともない

---

---

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

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