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

1 名前：デフォルトの名無しさん [03/09/10 16:04] 文字コード変換について語りましょう♪ 152 名前：デフォルトの名無しさん mailto:sage [03/12/26 00:58] UCS4だよ。一文字32ビット固定でいいやんけ。 153 名前：デフォルトの名無しさん mailto:sage [03/12/26 12:55] 合成があるってば 154 名前：デフォルトの名無しさん mailto:sage [03/12/26 14:13] 漢字圏の人間はついついUCS-4で全部解決と 思ってしまうんだよなあ。 155 名前：デフォルトの名無しさん mailto:sage [03/12/26 15:06] その典型が昔のTRONですね www.horagai.com/www/den/kanken.htm#04 最近のバージョンでは解決してるの? 156 名前：デフォルトの名無しさん [04/01/06 02:05] うーん、実態はそんなに単純じゃないんだけどなあ。 TRONの関係者の中にも多言語処理の複雑さを理解している 人たちはちゃんといたよ。昔のweblogをみると多言語の問題と 取り組んで悪戦苦闘している様子がうかがえた。 合成の問題のことは頻繁に話題になっていたよ。 一応TRONでは80年代ごろから多言語処理には 4層構造(言語層、文字属、スクリプト、フォント)で対応する ということになっていたんだけど、悲しいかな人手不足で 全然研究、ましてや実装は進まなかったんだよ。 今超漢字の販売元は組み込み向けの製品に注力していて、 超漢字にはあまり時間をかけていない様子。改善されているのも 相変わらず漢字処理が中心だよ。明るいニュースはごく最近 SUNがJavaのTRONコードへの対応を約束したことぐらいかな。 まだまだ先の道のりはながいよ。 157 名前：デフォルトの名無しさん mailto:sage [04/01/06 20:27] > TRONの関係者の中にも多言語処理の複雑さを理解している > 人たちはちゃんといたよ。 こんなのとか? www.sumire.sakura.ne.jp/~oguma/tron/btm1999z.html#19991203 漢字がどうしても中心になるのは分からなくもないけどね 使いもしない文字のサポートが強化されたって一般受けしないばかりか 「シリア語ブラクラ」なんて汚名まで被る始末だし 158 名前：デフォルトの名無しさん [04/01/08 04:12] 思ったんだけど、 わざわざ全ての文字を１つの文字コードに詰め込まなくても、 JIS コードみたいに文字コードの切り替えを行うマークを導入すれば かなりすっきりするんじゃない？ 159 名前：デフォルトの名無しさん mailto:sage [04/01/08 04:22] その切り替えタグに当たるコードは どうすれば必要十分で、どういうルールで割り当てていく？ 160 名前：デフォルトの名無しさん mailto:sage [04/01/08 04:30] 仮に一文字２バイトで固定するなら、 文字として使える領域と 切り替えタグにしか使えない領域に分割すれば いいんじゃない？ 161 名前：あぼーん mailto:あぼーん [あぼーん] あぼーん 162 名前：デフォルトの名無しさん mailto:sage [04/01/08 04:44] >>158 エスケープ・シーケンス unix で検索しる。 163 名前：デフォルトの名無しさん mailto:sage [04/01/08 05:02] >>162 Compound Text ってやつ？ なるほど、既にその手のものはあるんですな。 これで問題になることって何があるのかな？ 164 名前：デフォルトの名無しさん mailto:sage [04/01/08 11:50] >>163 まともな処理をするのがめんどうくさい。 165 名前：デフォルトの名無しさん mailto:sage [04/01/08 11:58] そもそも、プログラミングを容易にするために（＝国際化の容易さに直結）、 シフトを追放しランダムアクセス性を付与することが、 Unicodeの重要目標だったわけで。 166 名前：デフォルトの名無しさん mailto:sage [04/01/08 18:45] ttp://www.d2.dion.ne.jp/~kuropoo/kanban/shimbun/iwateken.jpg ↑この看板のコウの字がJIS X0208その他の文字集合に見あたらないのですが、 「工」に包摂されているんでしょうか、それとも探し方が悪いのでしょうか……？ 167 名前：デフォルトの名無しさん mailto:sage [04/01/11 05:54] >>166 MacOSX 10.3のヒラギノProに異字体として入ってるから（Stdの方には入ってないし、他のUnicodeフォントにも存在してない）文字集合としてはAdobe-ほげほげ-1.5とか以上でないと 入ってなさそうな感じですね。 印刷物に使うのはかまわないけど、インターネットとかには使えないよという警告がでますな。 168 名前：デフォルトの名無しさん mailto:sage [04/01/11 14:54] ほうちゃんと警告が出るのか。 つーかちゃんと異体字指定の方法を標準化して インターネットでも使えるようにしてほしいんだが 169 名前：デフォルトの名無しさん mailto:sage [04/01/12 00:05] >>168 その辺はまだこれからの課題なんじゃないかな？ AdobeとAppleだけだもんな。今んとこ。 XにContributeされてるAdobeのフォントに日本語のが入ってくれば状況は一気に変わるのかも 知れないけど。 WinはOTFのヒラギノ購入＆インストールで対応できるのかな？ Win持ってないんで判らんのでWinの方でヒラギノ入れてるような奇特な人は試してください。 あ、でもInDesignでドキュメントが完全にコンパチブルだとか売りにしてるようだから、ちゃんと 使えるのだろうな、きっと。 170 名前：デフォルトの名無しさん [04/01/19 08:20] UTF-8 から JIS X 0208 への変換テーブルってどっかない？ 171 名前：デフォルトの名無しさん mailto:sage [04/01/19 08:28] >>170 Perlかなんかで作れ。 172 名前：デフォルトの名無しさん mailto:sage [04/01/19 08:57] >>170 ftp://unicode.org/Public/ のどっか。 173 名前：170 mailto:sage [04/01/19 09:24] UTF-8 って UNICODE を千切って可変長にねじ込んでるだけだったんだね。 ash.jp/ash/src/codetbl/jis0208.txt UNICODE <-> JIS X 0208 の変換テーブルは見つかったから、これを使ってやってみるよ。 >171 >172 ありがとう 174 名前：デフォルトの名無しさん mailto:sage [04/01/19 14:44] 合成なんて、あきらめちゃっていいんじゃないの? 韓国も逃げちゃったし。 既存のコード体系でもしばしば合成を仕様に含めてるけど、まともに利用されてないしさ。 175 名前：デフォルトの名無しさん mailto:sage [04/01/19 15:25] 漢字なんて、あきらめちゃっていいんじゃないの? 既存のコード体系でもしばしば10万字もの漢字を仕様に含めてるけど(ry というのに賛成なら別に反対しないけど。 古ハングルは合成で表すことになってるし 実際にそれを実装したフォントも存在する デヴァーナーガリーやアラビア語のスクリプトは 重ね打ちで処理できない合成が必須 176 名前：174 mailto:sage [04/01/19 15:31] >>175 > デヴァーナーガリーやアラビア語のスクリプトは > 重ね打ちで処理できない合成が必須 あぁ、そうなのか。そりゃ俺が浅はかだった。 177 名前：デフォルトの名無しさん [04/01/29 03:16] DB(ORACLE) + JRUN(JAVA + JSP)で 日本語と韓国語を同じページ（一枚のJSP)に混在させて表示させたいのですが 文字コードの設定はどのようにしたらよろしいのでしょうか。 できればＤＢの同じカラムに日本語と韓国語を突っ込んで DBはORACLE9iだとUTF-16でしたがUTF-8にかえてJSP側でEUC-Krにしては 日本語がばけるしshift-Jisに設定したら韓国語が化ける。 178 名前：デフォルトの名無しさん [04/01/29 08:33] JSP側でUNICODE… 179 名前：デフォルトの名無しさん mailto:sage [04/01/29 12:40] JSP側で日本語と韓国語を同時に使える文字コードを選ぶのは ものすごく当然だと思うが何に困ってるわけ? つーか最後の3行日本語になってない 180 名前：デフォルトの名無しさん mailto:sage [04/01/29 12:51] > つーか最後の3行日本語になってない 韓国語を直訳でもしたんじゃないか? 181 名前：デフォルトの名無しさん [04/01/29 18:53] VB.NETを使ってるんですが、 日本語文字の自動判別が出来るライブラリってありませんか？ もしくはShiftJISとeucJPを見分ける賢いやり方誰か教えて〜 182 名前：デフォルトの名無しさん mailto:sage [04/01/29 18:56] Shift_JISとeuc_jpは完全には見分けられないなあ。 183 名前：デフォルトの名無しさん mailto:sage [04/01/29 20:42] A0 以外の Shift-JIS の半角カナが偶数個あるものは EUC-JP と区別がつきまそん。 184 名前：181 [04/01/29 21:01] ありがとうございます。 半角カナが奇数個なら判別可能という事なんでしょうか？ 詳しい解説キボン 185 名前：デフォルトの名無しさん mailto:sage [04/01/29 21:05] 例えば MSB の立っているバイトが奇数個だけ連続している（前後はMSBがゼロ） 場合には EUC-JP ではなさそうだな、ということはいえると思う。 186 名前：デフォルトの名無しさん mailto:sage [04/01/29 21:15] A1〜DF が２つあるやつは、 Shift-JIS の半角カナ２文字と、 EUC-JP の２バイト文字１文字と、 両方の可能性がある。 でも、奇数個なら Shift-JIS にしかなりえない。 他にも E0〜FC で始まり、A1〜FC で終わる文字も Shift-JIS か EUC-JP か区別できなかったりする。 187 名前：デフォルトの名無しさん mailto:sage [04/01/29 21:41] >>185 EUC-JPは補助漢字も考慮に入れる必要があるので、奇数個続く可能性はある。 188 名前：デフォルトの名無しさん mailto:sage [04/01/29 21:55] 文字コードだけでは区別しにくい場合でも 日本語の文章の場合、「ひらがな」が多く含まれる事が判定の一助になる場合がある。 例えばSJISだと0x81-0x83(だったか忘れたけど)が多いとか。 189 名前：デフォルトの名無しさん mailto:sage [04/01/29 22:51] ヒューリスティックな方法だけど、いくつかのプログラム （例えばnkfとfile(file2)とiconv）にそれぞれ判定してもらって、 多数決をとるっていうのはどーだろ？ 190 名前：デフォルトの名無しさん mailto:sage [04/01/29 23:38] UHCもGBKもEUCの上位互換になるような拡張だから 判定ミスで文字化けに悩まされてるのは日本くらいだよなあ 191 名前：デフォルトの名無しさん mailto:sage [04/01/30 13:26] 半角カナ１文字だと分かってればstrlen()一発で判別できるんだがな。 …何の役にもたたん話だが。 192 名前：デフォルトの名無しさん [04/01/30 18:09] ファイル入出力をユニコードに対応させたいのですが _wfopen()使うとWindows95シリーズを切っちゃいますよねぇ。 いっそ切っちゃおうか…、悩ましい。 193 名前：デフォルトの名無しさん [04/02/03 14:28] Windowsでは、UNICODEとSJISが使われてますね。 UNICODEが多国語Winでぶつからないのは分かりますが、 SJISは多国語Winで別の国のコードとぶつかっちゃうんでしょうか？ 194 名前：デフォルトの名無しさん mailto:sage [04/02/03 15:27] >>193 ぶつからないよ。非ユニコードのマルチバイト系のAPIを使うときは 暗に陽にキャラクターセットが指定されるから、ぶつかりようが無い。 195 名前：193 mailto:sage [04/02/03 16:01] >>194 そこが凄く知りたいところです。 もっと詳しく教えて下さい。 多国語対応してますが、 Delphi/標準VCLだとASCIIしか受け入れてくれないんですが、 キャラクターセットはどこで指定されるんでしょう。 DBの中身はUTF8で画面入出力時にUTF8ToAnsi/AnsiToUtf8してますが、 画面の入出力で文字化けしたら嫌だな、と思って。 196 名前：デフォルトの名無しさん mailto:sage [04/02/03 17:42] Windows で ANSI コードページと言った場合、おそらくは GetACP で得られる コードページ (日本語ロケールなら CP932 のシフトJIS）への変換だと思うのですが、 これはタダの ShiftJIS ですから、JIS にある文字以外は表現できません。 こんなので答えになってるんだろうか・・・ この辺見てみては？ ttp://www.microsoft.com/globaldev/handson/dev/muiapp.mspx 197 名前：デフォルトの名無しさん [04/02/04 00:49] javaではUCS-4はサポートされていないのでしょうか？ 以下のソースでUnsupportedEncodingExceptionが出ました。 FileOutputStream fo = new FileOutputStream(args[0]); String str = "A"; fo.write(str.getBytes("ISO-10646-UCS-4")); 198 名前：デフォルトの名無しさん mailto:sage [04/02/04 09:57] java 1.4 は Unicode 3.0 だからなぁ・・・ BMP にない文字は扱えないぽ。 199 名前：デフォルトの名無しさん [04/02/04 21:11] 質問です。 fopenでファイルを開くときWindowsの場合、テキスト形式で開いてたら 0x1AをEOFと判断して、バイナリだと0x1AをEOFと判断しないと聞きました。 それでUnixの場合はバイナリでもテキストでも一緒とも聞いたんですが、それではUnix系はどうやってファイルの終端を確認しているんですか？ Unixのファイル終端の識別子はなんなんですか？ （なんか僕が勘違いなどしてるところがあったらズバット指摘してくれてけっこうです） 200 名前：デフォルトの名無しさん mailto:sage [04/02/04 21:14] >>199 > （なんか僕が勘違いなどしてるところがあったらズバット指摘してくれてけっこうです） その質問はスレ違い。 201 名前：199 mailto:sage [04/02/04 21:27] え、文字コードだからここじゃダメですか？ 202 名前：デフォルトの名無しさん mailto:sage [04/02/04 22:11] C言語の実装の詳細の話だな。 203 名前：デフォルトの名無しさん mailto:sage [04/02/04 22:14] 殆どの近代的なファイルシステムでは、「ファイルの長さ」というものがきちんと管理されているので、 適当なコードを使って終端を示す必要はありません。 一部の処理系の一部の関数において 0x1A をファイル終端としていることがあるのは、ファイル長が 128バイト単位でしか管理されていなかった CP/M という OS との互換性のためです。 204 名前：デフォルトの名無しさん mailto:sage [04/02/04 23:14] >>203 ありがとうございます。 205 名前：デフォルトの名無しさん mailto:sage [04/02/05 00:33] xmodemを思い出すな・・・ 206 名前：デフォルトの名無しさん mailto:sage [04/02/05 12:03] UTFとかUNICODEとか言われてもわっかんねーよ 大体おれソフト開発の際そんなこと気にしたことないしな（汗 やっぱりWeb開発者じゃないと気にしないのかな？ 207 名前：デフォルトの名無しさん mailto:sage [04/02/05 12:08] まぁアプリのジャンルや開発環境によって違うだろうね。 一生気にせずに済むのなら、それはそれで幸せだとは思う。 208 名前：デフォルトの名無しさん mailto:sage [04/02/05 12:09] .NETとかJava開発者なら知らぬ間に使ってますよ 209 名前：デフォルトの名無しさん mailto:sage [04/02/06 10:24] BCCで可能な限りwin32apiだけを使ってSJISをUTF8へ変換する関数がほしい… ただしMultiByteToWideCharで直接UTF8へ変換するのはWin95では×らしいので… 210 名前：デフォルトの名無しさん mailto:sage [04/02/06 10:27] まずUTF-16(95ならUCS-2か)に変換してからRFC3629を見てがんがる 機械的な計算だけでできるから大して難しくないよ 211 名前：デフォルトの名無しさん mailto:sage [04/02/06 10:36] ちなみにWindows 2000でもMultiByteToWideCharでUTF-8→UTF-16は セキュリティの問題があるので勧めない。 XPではセキュリティの問題を防ぐためにnon-shortest-formの文字を 削除するようになったとMSDNに書いてるが、削除だと別の問題が 発生するのでMB_ERR_INVALID_CHARSフラグが必要。 212 名前：デフォルトの名無しさん mailto:sage [04/02/07 01:39] お忙しいところ失礼します。 やり方が分からないので立ち寄らせていただきました。 某板での記事からなのですが、 あるゲームのツールがヨーロッパ(たぶんITALY)で作られて、 日本語がもともと入っているデータがあって、 文字化けして表示されているんですが、 ゲーム中ではちゃんと表示されるんです。 でもそのEditorだとやはり文字化けしてしまうんです。 そこで他の方の質問からの解答で、 文字コードをS-JISからUTF-8へ変換。 とお答えになっていたのですが、 どのようにやればよいかわかりませんか？ 本当にやりたいんで御願いします。 ちなみにCとか全く分かりません。 何かソフトありませんか？ OSはXPです。 213 名前：デフォルトの名無しさん mailto:sage [04/02/07 01:41] メモ帳は UTF-8 で保存可能だ。 214 名前：デフォルトの名無しさん mailto:sage [04/02/07 01:45] >>213 さっそくの回答ありがとうございます。 コードはどーやって変えるんでしょうか？ 215 名前：デフォルトの名無しさん mailto:sage [04/02/07 01:50] >>212 ここはそんなレベルの低い質問をするスレッドではない。 Windows XPなら、メモ帳がUTF-8に対応しているので 1, Shift JISで書かれたテキストファイルをメモ帳で開く 2, 「名前を付けて保存」のダイアログで、「文字コード」に「UTF-8」を指定 216 名前：デフォルトの名無しさん mailto:sage [04/02/07 01:51] >>214 pc2.2ch.net/pcqa/ 217 名前：デフォルトの名無しさん mailto:sage [04/02/07 01:57] >>214>>215 本当にありがとうございます。 後一個だけおねがいです。 Shift JISで書くのもメモ帳ですか？ それとも何かありますか？ 218 名前：デフォルトの名無しさん mailto:sage [04/02/07 02:01] メモ帳はデフォルトで ShiftJIS だ。 219 名前：デフォルトの名無しさん mailto:sage [04/02/07 02:03] よごしてすんませんでした。 本当助かりました、ありがとう！ 220 名前：長いと言われたので分割 [04/02/07 13:13] 遅レスだけど もし参考になれば >>181 自分のHPからの抜粋今のところうまくは行ってるけど・・・(C#で作ってます) 最近文字コードの勉強しだしたんで間違えてたらｽﾏｿ あとわかりづらいとおもうけどｽﾏｿ ■1 ISO-2022-JPの判別 各ESC(0x1B〜)が出た場合はISO-2022-JP(確定) ■2 UTF-8の判別 0xC0<->0xFDが出た場合はUTF-8の強い可能性 第2バイト以降が全て0x80<->0xBF内であればUTF-8の強い可能性、そうでない場合は他コード 第1バイトで指定された長さ以下の場合は他コード ■3 EUC半角の判定 第1バイトが0x8Eで第2バイトが0xA1<->0xDFな場合はEUC半角カナの可能性 ただし既に他の文字コードの強い可能性ありと判断されてない場合に限る 第2バイトがEUC半角カナ範囲外で0x80<->0xA0であるならばSJIS(確定) 以上に当てはまらない場合は不明コード 221 名前：長いと言われたので分割2 [04/02/07 13:14] ■4 EUC補助漢字の判定 第1バイトが0x8Fで第2・3バイトが0xA1<->0xFEな場合はEUC補助漢字の強い可能性 ただし既に他の文字コードの強い可能性ありと判断されてない場合に限る 第2・3バイトどちらかが0xFD・0xFEであるならばEUC補助漢字(確定) 第2・3バイトがEUC補助漢字範囲外で0x80<->0xA0であるならばSJIS(確定) 以上に当てはまらない場合は不明コード ■5 SJISの判定 0x80<->0xA0であるならばSJIS ■6 SJIS半角カナの判定 0xA1<->0xDFが出た場合はSJIS半角カナ・EUC全角かな・カナの強い可能性 ただし既に他の文字コードの強い可能性と判断されてない場合に限る 第1バイトが0xA4か0xA5で第2バイトが[かな]0xA1<->0xF3[カナ]0xA1<->0xF6であるならば EUC全角ひらがな・カタカナの弱い可能性 第2バイトをチェックして0xE0<->0xFEであるならばEUCの強い可能性で0xFD・0xFEの場合はEUC(確定) 第2バイトが存在しない場合はSJISの強い可能性 以上に当てはまらない場合はSJIS半角カナの強い可能性 ■7 EUCの判定 0xA1<->0xFEの場合はEUCの強い可能性で0xFD・0xFEの場合はEUC(確定) 当てはまらない場合は不明コード 222 名前：長いと言われたので分割3 [04/02/07 13:15] [１]→ ISO-2022-JP確定 ↓ [２]→UTF-8強可能性→UTF-8強可能性→次ループ(ポインタ=+UTF8サイズ) ｜　　　　　　　　　＋→他コードの強可能性→[３]へ ↓ [３]→EUC半角カナ強可能性→EUC半角カナ強可能性→次ループ(ポインタ=+1) ｜　　　　　　　　　　　　　＋→EUC半角カナ確定 ｜　　　　　　　　　　　　　＋→SJIS確定 ｜　　　　　　　　　　　　　＋→不明コード→次ループ(ポインタ=+1) ↓ [４]→EUC補助漢字強可能性→EUC補助漢字強可能性→次ループ(ポインタ=+1) ｜　　　　　　　　　　　　　＋→EUC補助漢字確定 ｜　　　　　　　　　　　　　＋→SJIS確定 ｜　　　　　　　　　　　　　＋→不明コード→次ループ(ポインタ=+1) ↓ [５]→SJIS確定 ↓ [６]→SJIS半角カナ強可能性→SJIS半角カナ強可能性→次ループ(ポインタ=+1) ｜　　　　　　　　　　　　　＋→EUC全角かなカナ弱可能性→次ループ(ポインタ=+2) ｜　　　　　　　　　　　　　＋→EUC強可能性→次ループ(ポインタ=+1) ｜　　　　　　　　　　　　　＋→EUC確定 ↓ [７]→EUC強可能性→次ループ(ポインタ=+1) ＋→EUC確定 ↓ 不明コード→次ループ(ポインタ=+1) 223 名前：デフォルトの名無しさん mailto:sage [04/02/07 13:31] BOMは無視？ 224 名前：デフォルトの名無しさん mailto:sage [04/02/07 13:37] utf-8 → Shift_JIS （Shift_JISに無い文字はTeXのutf package用に\UTF{xxxx}） がほしい 225 名前：220 mailto:sage就活( ﾟДﾟ)ﾀｲﾍﾝﾀﾞｰ [04/02/07 14:13] >>223 BOMと言うものを知らなかったので・・・ 今検索してみてわかりました UTF-8に関しては 変換するときは消したほうがよさそうですが 判別の時は特に考えなくてもいいかと 判断された文字コードをスコア化して１番多いものをその文字コードと判断してるんですが それに対して重みをつける(通常+1を+2ぐらい)でいいかなと そのうちUTF-16とかにも対応したいので非常に勉強になりました ありがとうございます 226 名前：220 mailto:sage [04/02/07 15:18] とおもったらUTF-8・UTF-8Nと区別するんですね＿|￣|○ .NETのEncodingクラスには無さそうだけどためしに変換してみたら ゴミデータが付いてきたから標準でUTF-8Nなのかなぁ 227 名前：デフォルトの名無しさん mailto:sage [04/02/07 15:43] >>220 > 0xC0<->0xFDが出た場合はUTF-8の強い可能性 0xC0, 0xC1 が出た場合はUTF-8ではない(確定) Unicode(U+10FFFFまで)はサポートするけどISO10646の UCS-4(U+7FFFFFFF)はサポートしないなら0xF5-FDも除外できる RFC2279/3629参照 228 名前：220 mailto:sage [04/02/07 16:35] >>227 RFC読みました C0、C1がセキュリティ上禁止されていることがわかりましたので 早速条件に入れたいとおもいます UCS-4に関してはとりあえずサポートして置きたいので入れて起きます ありがとうございます 奥が深い・・・ 229 名前：デフォルトの名無しさん [04/02/07 22:00] >> 220 どこかのHPにまとまっている？ 230 名前：220 mailto:sage [04/02/07 22:25] >>229 はいまとまってるとおもいますが２ｃｈで晒すほど度胸無いので・・・ 最近ページ追加したばっかりでgooglebotは数回きてるんですが反映はまだ見たいです 231 名前：デフォルトの名無しさん [04/02/08 03:44] 予言： 　　1　0　年　後　に　は　、　U　T　F　-　6　4　が　標　準　に　な　り　ま　す　。 ＿|￣|○ 232 名前：デフォルトの名無しさん mailto:sage [04/02/10 10:27] >>211 どの場合も、事前に必要バッファ長を取得してから、 バッファ長指定して呼び出せば大丈夫じゃない？ 233 名前：デフォルトの名無しさん mailto:sage [04/02/10 17:20] >>232 セキュリティの問題というのは>>227-228でもちょっと触れてるけど たとえばディレクトリトラバーサル対策で「2E 2E」という文字列を フィルタリングしても、「C0 AE 2E」とか書くと貫通してしまうという問題。 altba.com/bakera/hatomaru.aspx/glossary/0055006e00690063006f006400650020005700650062002000540072006100760065007200730061006c あるいは「<」をnon-shortest formで送ることでXSSを発動させるとか。 www.cert.org/tech_tips/malicious_code_mitigation.html#3 対策としてXPではC0 AEのようなシーケンスを削除するようになった わけだが、今度は「2E C0 AE 2E」とか書くと貫通する。 もう少しモノを考えて修正してくれMicrosoftと小一時間(ry ただしMB_ERR_INVALID_CHARSを付けるとエラーになってくれる。 234 名前：デフォルトの名無しさん mailto:sage [04/02/10 17:46] >>233 おお、なるほど。 勉強になります。 結局のところ、有効な対策の一つとしては、 「API側の対策をあてにせず、UTF-16 or UCS-2に変換した後に危険な文字をチェックしろ」 ってことですかね？ 235 名前：デフォルトの名無しさん mailto:sage [04/02/10 18:28] 逆では? UTF-16 or UCS-2 のままでのチェックだけではなく、 API に渡される実際の引数レベルでもチェックをするって感じ？ 236 名前：デフォルトの名無しさん mailto:sage [04/02/11 05:47] >>235 違う。 237 名前：デフォルトの名無しさん [04/02/11 23:12] Shift_JISやEUC-JPやRFC1468に直接Unicode文字や補助漢字、JIS第3・第4水準の文字を 埋め込める規格を考案したけど、実用価値あるんだろうか？ Shift_JISで直接Unicode文字が使えたら機種依存文字の問題はなくなると思うんだけどね… 238 名前：デフォルトの名無しさん mailto:sage [04/02/11 23:29] >>237 > Shift_JISやEUC-JPやRFC1468に直接Unicode文字や補助漢字、JIS第3・第4水準の文字を > 埋め込める規格を考案したけど、実用価値あるんだろうか？ 率直にいって無いだろう。でもせっかくだから言ってみたらどうだろう? 目新しいアイデアなら、ほかのところで生かせるかもしれない。 まさか制御文字の一部を使って符号化する、なんてアイデアじゃないだろうな…… それと、文字コードの話するなら > Unicode文字 > ？ > 機種依存文字 この辺は直した方がいいよ。 239 名前：デフォルトの名無しさん mailto:sage [04/02/11 23:36] >>237 イオさんという人が昔「拡張シフトJIS」「拡張EUC-JP」「拡張ISO-2022-JP」 とかいうの考案してましたね。サイト消えちゃったけどWayBack Machineから発掘 web.archive.org/web/20030211003418/www.ksky.ne.jp/~smile4me/charcode/index.htm > Shift_JISで直接Unicode文字が使えたら機種依存文字の問題はなくなると思うんだけどね… GBK/GB18030はGB2312と上位互換を保ったままUnicodeの文字を 全部使えますね。 Unicodeに移行しようと思ったら既存のデータを全部変換するか 捨てる必要があるシフトJISやBig5圏から見たらうらやましい限り。 240 名前：デフォルトの名無しさん [04/02/12 12:14] >>238 端的にいうと、JIS X 0208の未定義領域を利用して、Unicodeのサロゲートペアみたいに、 面サロゲート、区サロゲート、点サロゲートの3文字(合計6バイト)を組み合わせて (サロゲートトリオと呼ぶことにします)JIS X 0208にない文字を表現するんです。 たとえば面サロゲートは09区〜12区、14区〜15区、85区〜88区のどこか、 区サロゲートは93区、点サロゲートは94区を使用することにします。 13区と89区〜92区はWindowsの外字と衝突するので使用しません。 多分面サロゲートは940文字も要らない(*1)と思うので85区〜88区だけでいい (*2)とは思いますが。 (*1)使える総文字数は940*94*94-(940+94+94)=8304712文字 (*2)使える総文字数は376*94*94=(376+94+94)=3321772文字 >>238 すみません。「?」はJIS X 0201/ASCIIのほうを使用しろということでしょうか。 「機種依存文字」は「JIS X 0208未定義文字」、「Unicode文字」は 「Unicodeに含まれてJIS X 0208に含まれていない文字」のほうが正しい言い方ですね。 上のほうでも「Windowsの外字」なんて怪しげな言葉を使っていますが、ご勘弁を… 241 名前：デフォルトの名無しさん [04/02/12 13:18] >>240の続きです。 85区01点はJIS X 0213第1面(第3水準)に収録されている文字のうち、 JIS X 0208に含まれない文字を区点番号はそのままで収録します。 JIS X 0208に含まれている文字の場所は空けておき、使用禁止にします。 同じように、85区02点はJIS X 0213第2面(第4水準)に収録されている 文字を収録します。 85区03点はJIS X 0212(補助漢字)を収録します。 Unicodeに収録されている文字は0x000000〜0x10FFFFの1114112文字 (サロゲートペアは使用を禁止するが、文字数には含めておく)ですが、 これを94進法でサロゲートトリオの各サロゲートを求めます。 面サロゲートは全部で127個必要になりますので、85区04点〜86区36点を 使用することにします。 86区37点〜89区94点はとりあえず保留領域にしますが、将来の拡張として 大漢和辞典に収録されている漢字でJISやUnicodeにない文字や、 人名・地名用の異体字を収録する領域にしておきます。 同じ文字がJIS X 0201、JIS X 0208、JIS X 0213、JIS X 0212、Unicodeに 重複して収録されていることもありますが、この場合、 JIS X 0201 > JIS X 0208 > JIS X 0213 > JIS X 0212 > Unicode の順番に優先して文字コードを使用することにします。 たとえばJIS X 0213、JIS X 0212、Unicodeに重複して収録されている文字は JIS X 0213の文字コードを使用することになります。 242 名前：デフォルトの名無しさん mailto:sage [04/02/12 13:24] ・・・Unicode使うよ。。。 243 名前：デフォルトの名無しさん [04/02/12 13:26] >>240-241の続きです。 これだけの文字(>>240参照)を使用することになると、すべての文字を 収録したフォントを製造することが難しくなります。 そこで、フォントに「収録基準」を設け、それをフォントのパッケージに 明示することによってフォントの収録文字数を明らかにします。 収録基準0 JIS X 0201(またはASCII) + JIS X 0208 収録基準1 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 収録基準2 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212 収録基準3 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212 + Unicodeの漢字(BMPのみ)(*3) 収録基準4 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212 + Unicodeの漢字(BMP以外を含む)(*3) 収録基準5 JIS X 0201(またはASCII) + JIS X 0208 + JIS X 0213 + JIS X 0212 + Unicodeのすべての文字 (*3)CJK統合漢字、CJK互換漢字、CJK互換文字のうちの漢字 説明は以上です。長文ご容赦ください。 244 名前：デフォルトの名無しさん mailto:sage [04/02/12 14:13] 1バイト部分がJIS X 0201かASCIIかによって使用禁止の区点が 変化しますがそこは曖昧なままですか? 245 名前：デフォルトの名無しさん mailto:sage [04/02/12 16:14] >>240の総文字数が誤っていたので訂正します。 (*1)使える総文字数は94*94-(940+94+94)+940*94*94=8313548文字 (*2)使える総文字数は94*94-(376+94+94)+376*94*94=3330608文字 >>244 だよねぇ。 1バイト英数字をASCIIにするのをやめてJIS X 0201にするとはっきり宣言してしまったほうが Shift_JISとの互換性を考えるといいのかも。 246 名前：デフォルトの名無しさん mailto:sage [04/02/12 16:25] > 1バイト英数字をASCIIにするのをやめてJIS X 0201にするとはっきり宣言してしまったほうが イラネ。 247 名前：デフォルトの名無しさん mailto:sage [04/02/12 16:32] > JIS X 0201にするとはっきり宣言してしまったほうが それはセキュリティの問題が発生するので すくなくともWindowsのコードページとしては採用不可能 248 名前：デフォルトの名無しさん mailto:sage [04/02/12 17:12] すなおにUTF32使おうよ・・・ 249 名前：デフォルトの名無しさん mailto:sage [04/02/12 18:05] ということは1バイトの英数字がASCIIで、1バイトのカタカナがJIS X 0201なのが 一番いいということなのかな。 1バイトのカタカナなんて廃止してしまえ!!という強硬な意見はあると思うけど、 互換性を考えるとどうしても廃止できないと思う。 250 名前：デフォルトの名無しさん mailto:sage [04/02/12 18:13] シフトJISの上位互換こそが特長なんだから 1バイトカナを廃止したら話にならん 互換性がなくていいならそれこそ>>248だ 251 名前：デフォルトの名無しさん mailto:sage [04/02/13 01:17] UTF32 って何が嬉しいのでしょうか。固定長ではないのですよね? 252 名前：デフォルトの名無しさん mailto:sage [04/02/13 01:39] BOM...かな？

---

---

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

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