- 107 名前：名無しさん＠お腹いっぱい。 mailto:sage [2009/04/19(日) 18:23:25 ]
- 1.EUC-JPはasciiは1バイトなので文字数は予測できない。
内部処理用に効率的なのはUCS2
あと文字形状まで考えたらadobeセットに手を出すと内部処理は楽
FreeBSDのwchar_tは4byteだがxml処理とか考えても無駄過ぎる。
可変長でもUTF-8のが速い。
2.euc-jpの拡張は最初の二文字が特定コードの時次の二文字で決まる。S-JISの半角カナも類似手法であてはまる。
3.現実問題として第二水準に収まる文字であればeuc-jpで困らないが日本の標準はs-jisであってeuc-jpではない。
4.euc-jpの拡張コードは実装されていない場合が多い。
5.インターフェースの文字コードはUTF-8で統一される方向にある。
特定アプリにはiconvかなんかかますのが良い。
6.別にutf-8で起動してもXの特定のターミナルでLANGを変更してアプリを起動できるし
自前のアプリの内部コードをどう最適化するかは自由
あとbzで圧縮するとutf-8は恐ろしく小さくなる。
UTF-8だと「表示がおかしくなる」というのは
日本語文字コードを2byteと決め打ちして表示するプログラムだけの世界の話だと思う。
|
 |
