- 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
- 331 名前：デフォルトの名無しさん mailto:sage [2005/08/18(木) 18:42:33 ]
- >>330
C++でもいいんならバベルはどうだ？
サンプリングしたデータを下にスコアリングを行うからかなりの精度で判別するぞ。
- 332 名前：321 mailto:sage [2005/08/18(木) 18:56:46 ]
- >>331
ありがとうございます、Babelの存在を忘れていました。一応C♯とC++を
考えているので、考慮に入れたいと思います。
- 333 名前：デフォルトの名無しさん mailto:sage [2005/08/20(土) 00:41:24 ]
- >>327
意味不明
- 334 名前：デフォルトの名無しさん mailto:sage [2005/08/20(土) 02:53:04 ]
- >>333
もちろん意味わかっててそう言ってるんだよな。
- 335 名前：デフォルトの名無しさん mailto:sae [2005/08/20(土) 08:31:29 ]
- 0x22, 0x27, 0x2Fとかきりがないけどな。
いまやUTF-8の時代だし。
- 336 名前：デフォルトの名無しさん mailto:sage [2005/08/20(土) 13:34:04 BE:39938742- ]
- >>328
このページの判定ルーチンは、一バイト目に0のあるバイナリファイルを食わせると、
配列の外にアクセスして例外が起きそうな気が。
- 337 名前：デフォルトの名無しさん mailto:sage [2005/08/20(土) 14:48:40 ]
- まあ.NETならそれを足がかりにバッファオーバーフロー起こして攻略とかできないから
- 338 名前：デフォルトの名無しさん mailto:sage [2005/08/20(土) 14:52:07 ]
- >>335
だいたいそれならISO-2022-JPを真っ先に滅ぼさなきゃならない
(実際日本語を想定してないメールゲートウェイでトラブルの元になってる)
ことには気付いてるんだろうかね
- 339 名前：デフォルトの名無しさん mailto:sage [2005/08/20(土) 23:16:21 ]
- >>338
> (実際日本語を想定してないメールゲートウェイでトラブルの元になってる)
( ﾟдﾟ)
(つд⊂)ｺﾞｼｺﾞｼ
(；ﾟдﾟ)
(つд⊂)ｺﾞｼｺﾞｼ
_, ._
（；ﾟ Дﾟ）
- 340 名前：デフォルトの名無しさん mailto:sage [2005/08/21(日) 02:55:12 ]
- ESCを捨てるゲートウェイの話とか聞いたことない?
- 341 名前：デフォルトの名無しさん mailto:sage [2005/08/21(日) 06:57:30 ]
- ISO-2022-JP の問題なら今は ESC よりも瘢雹だろう。
- 342 名前：デフォルトの名無しさん mailto:sage [2005/08/21(日) 10:38:35 ]
- amp;(瘢雹)は挟まるだけだからまだマシ
<→<や>→>はその後が全部化ける
- 343 名前：デフォルトの名無しさん mailto:sage [2005/08/21(日) 17:22:03 ]
- utf-8の日本語
すでに複数存在するって本当？
- 344 名前：デフォルトの名無しさん mailto:sage [2005/08/22(月) 00:42:02 ]
- >>338
いつの話だよ。
MIMEエンコードもしてないメールなの?
Structual fieldなら問題外だし。
- 345 名前：デフォルトの名無しさん mailto:sage [2005/08/22(月) 04:15:44 ]
- 瘢雹でぐぐればそういうメールアーカイブがバリバリ現役なのは分かると思いますが。
いくら綺麗事を並べたところでascii圏の認識なんてそんなもん。
- 346 名前：デフォルトの名無しさん mailto:sage [2005/08/22(月) 19:39:20 ]
- メールアーカイブなんぞメールのトラブルとは何の関係もないやんけ
- 347 名前：デフォルトの名無しさん mailto:sage [2005/08/22(月) 22:19:43 ]
- >>343
MicrosoftとAppleとLinux(つーかglibc?)とJavaとJISで全部ちょこっとづつ違うんじゃなかったっけ。
「〜」等の記号のコードポイントが違ったり正規化表現が違ったり。(正規化はUnicodeの範疇だけど)
- 348 名前：デフォルトの名無しさん mailto:sage [2005/08/23(火) 05:22:31 ]
- >>346
メールのトラブルじゃなきゃ何が起きてもいいわけじゃないし
- 349 名前：デフォルトの名無しさん mailto:sage [2005/08/23(火) 07:05:13 ]
- >>347
それはUTF-8ではなくShift_JISの方
そして違うのはコードポイントというかUCSへのマッピング
- 350 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 02:10:00 ]
- >>349
でも全部UTF-8で処理するCGI作ってWinとMacからそれぞれ「スケジュール2005年4月〜9月」などと入力してPOSTしたら、「〜」が異なるコードポイントでやってきますですよ?
- 351 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 02:17:29 ]
- そもそもWinとMacでは同じに見えても違う波線だから当然と言えば当然。
- 352 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 06:44:13 ]
- >>350
だからUTF-8の方は一種類なんだって。
1. あるUTF-8にはＸＸＸという文字があるけど違うUTF-8にはない、みたいなことはない。
2. あるUTF-8のYYYというコードポイントの文字はZZZだけど違うUTF-8では別の文字、みたいなこともない。
でもShift_JISでは、1. も2. も現実に起こってるの。
で、そのいろいろ微妙に違うShift_JIS達をユニコードに変換するときに、それぞれがいろいろ微妙に違う変換テーブルを使ってるのが原因。
UTF-8側の問題じゃないの。OK?
- 353 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 07:54:01 ]
- 原規格との変換テーブルを規定しないUnicode側の問題だろ。
- 354 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 08:26:17 ]
- むかしは規定してたけどな。
きっと管理しきれなくなってやめたんだろうなぁ……。
ちゃんとやろうとするなら、SJISだけでいくつの方言を面倒みないといけないやら。
- 355 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 08:32:03 ]
- > でも全部UTF-8で処理するCGI作って
- 356 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 08:39:26 ]
- ていうかユニコード側が規定してもベンダが従うとは限らないし、
ベンダはマッピングを変更したり増やしたりもするだろうし、
ユニコード側にそれの管理をさせるのは無茶だろ。
混乱の元だってのは確かにその通りかもしれないけど、他にどうしろと？
- 357 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 08:52:17 ]
- よしUTF-128ぐらいで手を打とうじゃないか
言語問わず、今現在使われてる部分は意地でも文字振りません
- 358 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 16:22:59 ]
- Unicodeがマッピング・テーブルを公開していた頃も
ベンダはそれに従ってなかったし。
- 359 名前：デフォルトの名無しさん [2005/08/24(水) 18:55:15 ]
- >>357
UTF-8でも、36bitコードまでリニアな拡張で扱えるが。
- 360 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 19:11:20 ]
- それはUTF-8ではない。
- 361 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 19:31:36 ]
- ＞36bitコード
( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )
- 362 名前：デフォルトの名無しさん [2005/08/24(水) 20:05:55 ]
- >>360
だから、「UTF-8の *リニアな拡張* 」だって言ってんだろ？
先頭バイトの上位ビットに7個1が並んでいたら、↓ 36bitになるだろうが。
11111110 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
- 363 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 21:23:35 ]
- UTF-8 符号化では 0xfe と 0xff のバイトは絶対に使用しない。
- 364 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 21:35:56 ]
- 拡張って言葉の意味が分からないの?
- 365 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 21:36:49 ]
- ちなみに0xfeと0xffを使わない理由はUTF-16のBOMが100%判別できるようにするためだな
- 366 名前：347=350 mailto:sage [2005/08/24(水) 22:50:04 ]
- >>351 >>352
ええと、理屈はわかるんですが、現実として、WinとMacとLinuxの混在環境
で全部UTF-8に統一しても、人間から見たら「同じ」と認識されるはずの
ものが異なるバイトパターンを構成するために、システム的には「同じ」
にならないと言う問題があって、これを解決するためには、どこかで
UTF-8 to UTF-8変換をする必要があるのではないでしょうか。
この状況を称して「UTF-8の日本語はすでに複数存在する」と言っても
過言ではない、と思うんですけれども。
- 367 名前：デフォルトの名無しさん mailto:sage [2005/08/24(水) 22:59:33 ]
- > UTF-8 to UTF-8
お前が言わんとすることに似たようなことは既に存在する。
www.google.co.jp/search?hl=ja&c2coff=1&q=Unicode+%E6%AD%A3%E8%A6%8F%E5%8C%96&lr=lang_ja
- 368 名前：デフォルトの名無しさん [2005/08/24(水) 23:02:00 ]
- >>366
UTF-8は文字エンコードの規格。
見た目は同じで違う文字、というのは文字セットの問題。
だから、UTF-8云々の議論はかみ合わない。
それに、バイトパターンが一致しないのは、BOM有無とか改行の問題じゃないの？
あるいは、UTF-8なら本来2バイトで表せる文字を3バイトで記録するような誤った実装の
アプリを使っているとか、サロゲートペアをそのまま2文字で扱うエラーとか…
- 369 名前：366 mailto:sage [2005/08/25(木) 00:49:19 ]
- >>367
ぅぃ。問題自体が今さらなのは承知しております。
が、その対策が、この関数／メソッドを呼べばOK!にはなってなくて、
未だにアプリケーション毎の個別対応に依存しているようにしか
見えないのはどうしたものかと。
Javaの世界ですら、10年前から既知の問題なのにどこにも(ベンダ依存
マッピング問題を含む)統一されたフレームワークが見あたりません……。
私が知らないだけだったら、是非教えてください。
- 370 名前：366 mailto:sage [2005/08/25(木) 01:02:13 ]
- >>368
厳密にはそうなんですが、現状は、
Conten-Type: text/html; charset="UTF-8"
や
export LANG=ja_JP.UTF-8
のように、文字セットの情報は交換してないので、事実上UTF-8というだけで
文字セットまで含んでしまってます。せめてUTF-8-msとかUTF-8-appleのよう
に区別してくれたら〜(;_;)
ちなみにバイトパターンについては、「スケジュール4月〜9月」という文字列
を、Windowsのメモ帳とMac OS Xのテキストエディットで入力、エンコーディ
ングはどちらもUTF-8で保存すると、以下のようになります。
od -j 3 -tx1 win.txt (BOMが入るので頭3バイト切り捨ててます)
0000003 e3 82 b9 e3 82 b1 e3 82 b8 e3 83 a5 e3 83 bc e3
0000023 83 ab 34 e6 9c 88【ef bd 9e】39 e6 9c 88
od -tx1 mac.txt
0000000 e3 82 b9 e3 82 b1 e3 82 b8 e3 83 a5 e3 83 bc e3
0000020 83 ab 34 e6 9c 88【e3 80 9c】39 e6 9c 88
おや、MacでもNFCなのか。WebDAVのリクエストはNFDで投げてくるので、
てっきりNFDになるのかと……。
- 371 名前：デフォルトの名無しさん mailto:sage [2005/08/25(木) 02:16:26 ]
- MACのwebdavリクエストってかなり行儀悪いよねえ
俺も複数あるようにとれちゃうけど、
とにかくあれだUTF-8って統括してるってのりじゃないんだ
マッピング誰がつけたの？
- 372 名前：デフォルトの名無しさん mailto:sage [2005/08/25(木) 05:15:33 ]
- >>370
厳密な指定が無い限りユーザが何を入力するかは好み(運)次第でしょ。
MacOSXのinput methodだとU+301C WAVE DASHの方が入力し易いけど、
U+FF5E FULLWIDTH TILDEも入力できるし、WindowsのIMEで「から」を
入力するとU+301C WAVE DASHになるみたいだし。
MacOSXではHFS+との互換性や同じファイル名を作らせないためにVFSは
NFDにnormalizeしてるけど、NFC/NFD/複雑な合成文字のいずれも扱えます。
developer.apple.com/ja/qa/qa2001/qa1173.html
- 373 名前：デフォルトの名無しさん mailto:sage [2005/08/25(木) 08:02:25 ]
- >>370
あほ? (w
- 374 名前：デフォルトの名無しさん mailto:sage [2005/08/25(木) 08:48:22 ]
- >>370
だからUTF-8の問題ではないだから、UTF-8-msとかUTF-8-appleとかを作って解決すべき問題ではないの。
- 375 名前：デフォルトの名無しさん mailto:sage [2005/08/25(木) 08:54:41 ]
- euc.jp/i18n/ucsnote.ja.html
これだろ?
UnicodeじゃなくてJIS X 0208に限っても、
−〜ー─と利用者が入力し間違う余地はある。
これを文字コード(のエンコーディング)の問題だと思う奴は馬鹿じゃないの?
- 376 名前：デフォルトの名無しさん mailto:sage [2005/08/25(木) 14:11:34 ]
- >>370
これ読んで出直し。
www.unicode.org/reports/tr17/
- 377 名前：デフォルトの名無しさん mailto:sage [2005/08/25(木) 15:23:50 ]
- Content-Typeがutf-8で萎えた、こだわって欲しかった
こんなんに任せてっからだめなんだよ！そのうちUとuの変換表作り始めるぜ
- 378 名前：デフォルトの名無しさん mailto:sage [2005/08/26(金) 06:02:23 ]
- >>374
GNU libiconvはNFDが扱えないため、DarwinのlibiconvはUTF-8にだけNFCへの
normalizerを追加してUTF-8-MACと称してます。
Darwin的にはUTF-8の問題ではない物をUTF-8-APPLEを作って解決するのはありw
- 379 名前：デフォルトの名無しさん mailto:sage [2005/08/26(金) 07:13:57 ]
- そもそもAppleのNFDって互換漢字をNormalizeしないよな
されたらそれはそれで困るけど。
- 380 名前：デフォルトの名無しさん mailto:sage [2005/08/26(金) 07:15:27 ]
- ↑はHFS+に格納する場合
- 381 名前：デフォルトの名無しさん mailto:sage [2005/08/26(金) 15:03:48 ]
- >>380
詳しく
- 382 名前：デフォルトの名無しさん mailto:sage [2005/08/26(金) 21:29:09 ]
- >>381
developer.apple.com/ja/technotes/tn1150.html#UnicodeSubtleties
- 383 名前：デフォルトの名無しさん mailto:sage [2005/08/26(金) 21:35:39 ]
- 規格上は同一の文字コードでも出力時の選択に応じて
便宜上別の名前をつけるのはよくあることだべ
エンディアンの違いでx-utf-16le-bomとx-utf-16be-bomとか
使用するエスケープシーケンスの違いでiso-2022-jp-3とiso-2022-jp-3-strictとか
- 384 名前：デフォルトの名無しさん mailto:sage [2005/08/27(土) 07:42:26 ]
- >>383
IANAにもUTF-16LEとかあるのでその辺は承知してます。
それらの場合、UTF-16やISO-2022に直結した問題なので説得力があるのですが、UTF-8-MAC
はSambaが動かないバグに泥縄で対処するために作った物の様です。
UTF-8-DARWIN-VFSとでも名付けるのが機能や泥縄感wを表して良いと思うのですが、
UTF-8-MACを使ったためにこのスレでも見られる変な誤解が広まっています。
- 385 名前：デフォルトの名無しさん mailto:sage [2005/08/27(土) 07:59:42 ]
- Mac OS Xは、HFS+のドライバ@Darwinや
CarbonのFrameworkに個別の変換実装を持っていてアホ丸出し。
- 386 名前：デフォルトの名無しさん mailto:sage [2005/08/27(土) 09:01:44 ]
- >>384
UTF-16LEはBOM禁止でUTF-16とは明確に違うべ
- 387 名前：デフォルトの名無しさん mailto:sage [2005/09/12(月) 17:09:19 ]
- MSGOTHICの文字情報を
euc-jpのマッピングに揃えたら
euc見れる？？サイズかわって無理？
- 388 名前：デフォルトの名無しさん mailto:sage [2005/09/12(月) 19:33:41 ]
- >>387
何が知りたいのかよくわからんが、
「MS Gothic フォント内のグリフの並び方をEUC-JPの並びに変えたら、
Win32 API の文字表示APIでシフトJIS文字列を渡すところでEUC-JP文字
列を渡して画面に表示できるようになるか？」
という意味？
- 389 名前：デフォルトの名無しさん mailto:sage [2005/09/12(月) 22:24:07 ]
- 相手にしないのが吉
- 390 名前：デフォルトの名無しさん mailto:sage [2005/09/13(火) 06:29:36 ]
- >388
ですです！
フォントについて知らな過ぎのくせにイメージだけで喋っちゃってました。
グリフって？ってとこから構築してました
伝わってよかったありがとう
>389
ひどい！
shiftjisもeucもアスキーよけた同じような感じだと思ってたんだけど
結論は無理っぽい？？
- 391 名前：デフォルトの名無しさん mailto:sage [2005/09/13(火) 06:33:51 ]
- これ半角カナ全滅しますね、フォントだけで吸収できないもんですか
ハイもう喋りません、ごめんなさい
- 392 名前：デフォルトの名無しさん mailto:sage [2005/09/13(火) 09:20:39 ]
- 半角カナ ｲﾗﾈ
- 393 名前：デフォルトの名無しさん mailto:sage [2005/09/13(火) 09:47:44 ]
- 392 名前：デフォルトの名無しさん[sage] 投稿日：2005/09/13(火) 09:20:39
半角カナ ｲﾗﾈ
- 394 名前：デフォルトの名無しさん mailto:sage [2005/09/13(火) 10:22:05 ]
- 393 Name： デフォルトの名無しさん [sage] Date： 2005/09/13(火) 09:47:44 ID: Be:
392 名前：デフォルトの名無しさん[sage] 投稿日：2005/09/13(火) 09:20:39
半角カナ ｲﾗﾈ
- 395 名前：デフォルトの名無しさん mailto:sage [2005/09/13(火) 10:25:18 ]
- 質問です。
WindowsAPIもしくは、C言語関数で
ISO-8859-*からUNICODEへ変換する関数はありますか？
教えて君で申し訳ないですが、いくら調べても見つからないので、
書き込ませてもらいました。
ご存じでしたらお願いします。
- 396 名前：デフォルトの名無しさん mailto:sage [2005/09/13(火) 11:01:03 ]
- >>395
> 教えて君で申し訳ないですが、いくら調べても見つからないので、
このスレくらい読め。
- 397 名前：デフォルトの名無しさん mailto:sage [2005/09/13(火) 11:49:10 ]
- iconv <- unix
MultiByteToWideChar <- win32api
# MultiByteToWideChar, 新しいMSDNのページだと検索に引っかかってこない……。
- 398 名前：半角撲滅ﾘｰﾀﾞｰ mailto:sage [2005/09/13(火) 12:07:48 ]
- 半角に包まれたcursesダイアログが目に染みるあなた
起動時のくるくるインジケータ※に￥が混ざりどっち回転なのかわからなくなるとお悩みの方！
コピーライトゥ にせんご、と読んでる天然も共に戦いましょう！
今こそ立ち上がるのです！！！
- 399 名前：デフォルトの名無しさん mailto:sage [2005/09/13(火) 12:16:29 ]
- 半角って難ですか?
- 400 名前：395 mailto:sage [2005/09/13(火) 13:14:44 ]
- >>397
MultiByteToWideCharで可能と言うことでしょうか？
因みにmbstowcsでも可能でしょうか？
あと、対象OSはWindowsCEなのですが、
第1引き数のCP_UTF7・8はCEでサポートされないとMSDNに書いてあるのですが、
ここには何をしていすれば良いですか？
全くの素人で申し訳ないですが、宜しくお願いします。
- 401 名前：デフォルトの名無しさん mailto:sage [2005/09/13(火) 17:28:11 ]
- >>400
最初の引数はIsValidCodePage()の引数がそのまま使える。
IsValidCodePage()の項目にはコードページの一覧がある。
- 402 名前：デフォルトの名無しさん mailto:sage [2005/09/13(火) 20:43:08 ]
- >>400
第一引数はマルチバイト文字列に関するコードページなので、
ISO-8859-*に対応するコードページを指定してやればいい。
変換後はUCS-2かUTF-16固定のはず。
- 403 名前：デフォルトの名無しさん mailto:sage [2005/09/14(水) 09:45:15 ]
- >>401-402
ありがとうございます。
助かりました。
- 404 名前：デフォルトの名無しさん mailto:sage [2005/09/15(木) 01:53:38 ]
- 太玄経(U+1D300〜)の文字名間違い指摘キター
- 405 名前：デフォルトの名無しさん [2005/09/15(木) 07:20:39 ]
- UTF-8な以下のXMLファイルを（notepadで作成し、UTF-8でセーブしました）、
<?xml version="1.0" encoding="UTF-8"?>
<RootNode><ChildNode value="てすと" /></RootNode>
以下のMSXMLを使ったプログラムで読み込もうとしています。
#import "msxml4.dll"
using namespace MSXML2;
int main()
{
CoInitialize(0);
{
IXMLDOMDocumentPtr pzDomDoc( "MSXML.DOMDocument" );
pzDomDoc->validateOnParse = VARIANT_FALSE;
pzDomDoc->load( "C:\\temp\\japanese_text.xml" );
IXMLDOMElementPtr pzDomRoot = pzDomDoc->documentElement;
IXMLDOMElementPtr pzDomNode = pzDomRoot->firstChild;
/*-->*/_variant_t varAttr(pzDomNode->getAttribute( "value" ));
}
CoUninitialize();
return 0;
}
"-->"の行のvarAttrに空文字が帰ってきてしまいます。環境はVisualC++6.0英語版です。
原因がわかる方いらっしゃいますでしょうか。
- 406 名前：405 [2005/09/15(木) 07:22:42 ]
- （XML関連のスレはあまり人がいらっしゃらないような気がしたので敢えてここで質問させていただきましたが
もしスレ違いでしたらすみません、、、。）
- 407 名前：405 mailto:sage [2005/09/15(木) 08:00:41 ]
- ちなみに>>405のコードの中で
pzDomDoc->save( "C:\\temp\\japanese_text_out.xml" );
としてファイルにセーブしなおしてみたところ日本語の属性がきちんと元のままセーブされていました。属性を取り出すところで何かが起こってるのだと思うのですが、、、。
言い忘れましたがOSは"英語版"WindowsXP(SP1)です。VC++も含めて英語版の環境であることが問題なのでしょうか？
- 408 名前：デフォルトの名無しさん mailto:sage [2005/09/15(木) 08:12:24 ]
- とりあえずBSTRはwcharらしいから
リテラルにL付けてみたら？
- 409 名前：405 mailto:sage [2005/09/15(木) 08:17:33 ]
- すみません、私の勘違いだったようです。デバッガでは>>405のコードのvarAttrの値が
varAttr{"" VT_BSTR}
と表示されるので空文字が返ってきているのだと思ってしまっていました。文字列はちゃんと返されているようです。
一人でスレを汚してすみませんでした！
- 410 名前：デフォルトの名無しさん mailto:sage [2005/09/15(木) 08:18:32 ]
- XMLのｽﾚへ帰れ。原因は知ってるがここでは教えてやらん。
ただ、ヒントだけは出しておく pzDomRoot != "/RootNode"
- 411 名前：デフォルトの名無しさん mailto:sage [2005/09/15(木) 17:51:38 ]
- >>410
カコワルイ
- 412 名前：デフォルトの名無しさん [2005/09/16(金) 01:56:08 ]
- 我々も文字コードで天下を統一するぞ！！！！
UTF-8で天下統一だ！！！
UTF-8は尾張の織田信長だ！！！！
- 413 名前：デフォルトの名無しさん mailto:sage [2005/09/16(金) 09:10:01 ]
- UTF-8でなくて、Unicodeと言っちゃダメなのか? と突っ込んでみる。
- 414 名前：デフォルトの名無しさん mailto:sage [2005/09/16(金) 12:47:52 ]
- 413＝明智光秀
- 415 名前：デフォルトの名無しさん mailto:sage [2005/09/16(金) 22:42:58 ]
- >>413
UTF-8はUnicodeの一形態なんだから、お前の文は意味がない。
- 416 名前：デフォルトの名無しさん mailto:sage [2005/09/17(土) 02:20:17 ]
- UTF-7も仲間に入れてよ〜、ということだろう。
- 417 名前：デフォルトの名無しさん mailto:sage [2005/09/17(土) 02:42:46 ]
- UTF-7イラネ
RFCも更新されずに見捨てられてるし
- 418 名前：デフォルトの名無しさん mailto:sage [2005/09/17(土) 15:56:13 ]
- >>416
いやいや、UTF-32も仲間に入れてよ〜、ということだな。
- 419 名前：デフォルトの名無しさん mailto:sage [2005/09/17(土) 16:24:41 ]
- UCS-2＝松平家康
UCS-4＝羽柴秀吉
UTF-7＝明智光秀
UTF-8＝織田信長
UTF-16＝徳川家康
UTF-32＝豊臣秀吉
- 420 名前：デフォルトの名無しさん mailto:sage [2005/09/17(土) 16:54:46 ]
- UTF-8がUTF-7にヌッコロされるという図は想像出来んのだが
- 421 名前：デフォルトの名無しさん mailto:sage [2005/09/17(土) 17:30:51 ]
- ISO-2022 毛利
- 422 名前：デフォルトの名無しさん mailto:sage [2005/09/17(土) 17:50:30 ]
- Shift_JIS＝武田信玄
EUC-JP＝上杉謙信
- 423 名前：デフォルトの名無しさん mailto:sage [2005/09/17(土) 17:50:46 ]
- >シフトJISは共通基盤となっている。この共通基盤を維持することが、
>言語の共通性を維持するために、とても大事なのだ。
ttp://openblog.seesaa.net/article/6106946.html#comment
- 424 名前：423 mailto:sage [2005/09/17(土) 17:58:36 ]
- 16秒遅かったか。
- 425 名前：デフォルトの名無しさん mailto:sage [2005/09/17(土) 22:01:10 ]
- >>423
南堂、あいかわらずだなヽ( ´ー`)ノ
- 426 名前：デフォルトの名無しさん mailto:sage [2005/09/17(土) 22:26:34 ]
- 「シフトJISが共通基盤」って鎖国でもするつもりか？
内部コードSJIS対応パッチなんてどこもマージしてくれないぞ。
Citrus Projectでもない限り。
- 427 名前：デフォルトの名無しさん mailto:sage [2005/09/18(日) 02:22:29 ]
- >>423
> 私の旧型パソコン（Windows98）は、対応できなかった。google に接続するたびに、異常を起こした。
> たいていは、マシンがビジー状態になってストップするだけであり、再起動すれば直った。しかし、
> あるときついに、ビジー状態のあげく、CPUが過熱して、パソコンが壊れてしまった。
>
> つまり、UTF-8 という文字コードを採用したせいで、パソコンが壊れてしまったわけだ。
> つまり、UTF-8 という文字コードを採用したせいで、パソコンが壊れてしまったわけだ。
> つまり、UTF-8 という文字コードを採用したせいで、パソコンが壊れてしまったわけだ。
> つまり、UTF-8 という文字コードを採用したせいで、パソコンが壊れてしまったわけだ。
> つまり、UTF-8 という文字コードを採用したせいで、パソコンが壊れてしまったわけだ。
お茶吹いたｗ
- 428 名前：デフォルトの名無しさん mailto:sage [2005/09/18(日) 03:27:22 ]
- >>426
それも日本のプロジェクトだな。
- 429 名前：デフォルトの名無しさん mailto:sage [2005/09/18(日) 07:47:36 ]
- >>427
UTF-8って怖いね(w
- 430 名前：デフォルトの名無しさん mailto:sage [2005/09/18(日) 10:01:33 ]
- UTF-8のせいでうちのおじいちゃんは…
- 431 名前：デフォルトの名無しさん mailto:sage [2005/09/18(日) 10:07:50 ]
- 巷で「UTF-8最強！！！！」と叫ぶ輩を見掛けるのには
こんな理由があったのか。
|
 |
