natsuの秘密基地です
カレンダー
10 | 2024/11 | 12 |
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
カテゴリー
プロフィール
HN:
natsu
性別:
男性
趣味:
酒など
自己紹介:
ここに書かれていることはフィクションです。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
最近ではなんか気分が乗らない感じなので。
あれ、おもしろいですよね。
あー。あたまがぐしゃぐしゃになってきた。
Civ4ばっかやってるんだけども。
いや、ばっかってほどにはやってないけど。
1年半ぶりくらいに。
CDを発掘したもんで。
文字コードが私を悩ませるもんだから。
逃避。
あれ、おもしろいですよね。
無印なんだぜ。私の。
逃避したくなるのはEUCとShift JIS。
カバーする領域がかぶってるもんだから、
どっちがどっちやら。
あれはね。Shift Jisが半角カタカナを1byteでやってるからだと思う。
EUCが文字化けしたとき半角カタカナばっかになるけど、
そうゆうことだったんだ、となんか納得。
EUCはSJISっぽく読むと半角カタカナの宝庫なんだよ。
もー。なんでShift Jis半角カタカナ1byteなんだよ。
っていうか、半角カタカナってなんだよ。
っていうか、半角カタカナってなんだよ。
パケ代節約するためー?
携帯がSJISかどうかは知らんけど。
もしEUCなら無駄な努力だったんだよ。
そして、JISならむしろ高くなるんだよ。
パケット境界を読まなきゃ節約になんないんだろうけど、
私はそこまで考えるのめんどくさい。
あー。あたまがぐしゃぐしゃになってきた。
とにもかくにもですよ。
コードが存在する範囲に収まってるかどうか、
ってだけじゃあ、SJISかEUCかはわかんないわけですな。
UTFやらJISやら、割とわかりやすいのを先に判別しておいて、
最終決戦でEUC vs SJISをやればいいのだろうか。
んで、ぽいほうに軍配をあげる。
っていうか、どっちがぽいか、なんてどう判断すんのよ。
まずSJISから読んでみて、
半角カタカナばっかになってきたら、
それEUCっぽくね?てフラグでも立てとくか。
で、EUCが失敗したら、
あーやっぱSJISでしたね。
みたいなノリでいいか。
それ、コギャルのメールだったのさ。きっと。
今、コギャルなんていわないよ。きっと。
PR
確実に文字コードを判別する方法は無いにしても、
まっとうなJISは0x7F以下のコードで出来ていて、
まあまあうまくいく。ってな方法はあるんだと思う。
まず、問題を簡単におさめるため、
環境的に日本語と英語しか使わないっていう前提で。
まっとうなJISは0x7F以下のコードで出来ていて、
特定のエスケープシーケンスが含まれている。
エスケープシーケンスが入ってないISO-2022-JPは
2byte文字や半角カタカナが入っていない。
すべてのコードがASCIIのコードで収まっているから、
ASCIIだっ。って言い張っていいと思う。
っていうか、それ以外言いようが無い。
前のエントリの結果から、
ISO-2022-JPかどうかが判断できたなら、
なんとかごまかせそうな気がする。
まずISO-2022-JPかどうか私が調べて、
そうだったらそう読み込めばいい。
ISO-2022-JPのコードがくる可能性が無ければ、
Shift JIS、EUC-JP、UTF-8は
それぞれのコード指定かUTF-16でしか読み込まれない。
UTF-16の読み込みより前にこれらを試行しておけば
まちがって読み込まれる心配が無い。
で、最後に残ったのがUTF-16。
これを最後に試行。
うっかりバイナリを読み込めてしまうかも。
っていうのは今思った。
そんなわけで、とりあえず、
ISO-2022-JPをなんとかできればね。
何とかなりそうな気がするけども、
出来ればNSStringじゃなくて、
私が文字コードを判別したいな、
というのは思う。
なんかね。
文字コードの問題はめんどくさい。
また扱うと思うけど、
ちょっとお休み。
っていうかおまえら。
ヘッダかなんか持て。
次からでいいから。
やりたいことが増えていく。
この一連のはまりはあんがい壮大なのかもしれない。
NSStringを使ってエンコード指定なしの、
引数の一番少ないstringWithContentsOfFileを呼び出して
EUCをロードすると、
ロードが出来たのでよかった。
と思いきやデバッガに意味不明な文字列が。
あー。ぐちゃぐちゃ。
ここは、Shift JISを読み込もうと思ったところなので、
エンコードを指定してやる。
Shift JISに指定してやると、
EUCでちゃんと失敗するようになった。
stringWithContentsOfFile:usedEncoding:error
はISO-2022-JP、いわゆるJISが読み込めてしまう。
あー。ぐちゃぐちゃ。
usedEncodingで返された値は4。
これはUTF-8だと。
俺が言うから確かなんだと。
そうっすか・・・
stringWithContentsOfFile:usedEncoding:error
は、UTFだと解ってるとき以外使っちゃ駄目ってこと?
でまあ、結局単純な当たって砕けろ式でコーディング。
エンコード指定して読み込む。
だめだったら別のエンコード指定して読み込む。
だめだったら別のエンコード指定して読み込む。
おおぅ。UTF-8はUTF-16指定でも読めるねぇ。
EUCもUTF-16指定で読める。
で、UTF-16はISO-2022-JP指定で読めちゃう。
ISO-2022-JPはShift JIS指定で読める。
あー。もう、全部ぐちゃぐちゃ。
できんことはするな。
といいたい。
で、まとめると。
Shift JIS
Shift Jis、ISO-2022-JP、UTF-16指定で読めてしまう
EUC
EUC、ISO-2022-JP、UTF-16指定で読めてしまう
ISO-2022-JP
なんでもこい
UTF-8
UTF-8、ISO-2022-JP、UTF-16指定で読めてしまう
UTF-16
UTF-16、ISO-2022-JP指定で読めてしまう
とりわけISO-2022-JPの優秀さが光る。
順番で何とかなるかと思いきや、
こいつのせいで何ともならない。
日本語文字コード大杉。
使い始めちゃったら、使い続けざるをえんのよねぇ。
Shift JISなんかあるせいで、
どれだけのPHPプログラマが血祭りにあげられたことか。
EUCでいいじゃんとかおもうけど。
経緯がいろいろあるんでしょ。
半角カタカナとか。
あーなんかね。当たって砕けた感じ。
基本的に
「当たって砕けろだっ!」
って思ってやるとき、ってね。
大体くだけるもんなんですよ。
恋愛だってそうでしょ。
砕ける、っていうか砕け散る。というか。
さて。文字コード。どうしようかねぇ。