詰んでいた仕事が終わりました。この仕事は物理の仕事みたいなもんだと思ってください。
気になったポイント
これはよい演出過剰ですね、音楽に手が込んでいる、シナリオがいい文章書くもんだから…
さて、バトンですが、2人に回しておいたので、合計5人です。よろしく。
Q4の答えが心配です。Falseなら問題ないんですけど…これTrueなら笑う…
しかし、"そこ"の常識はちょっと変ですよ。大概変な僕が言うから間違えない。
ちなみに"そこ"に僕は含まれないつもりです。"そこ"の2つ隣です。そこでは非常識だけど。
さて、ISO-2022-JPって知ってますよね？これいわゆるJISコードです。
まぁしかし、現実的にこっちの方がよく使うんで…
まぁメールはほぼISO-2022-JPで送られています。これでエンコードしています。
メールは昔の名残でASCIIコードの範囲、7ビットを扱えればいいという考えらしいんで。
この範囲であらわせるように決めたのがISO-2022-JPですから、確かに…
問題点は漢字INと漢字OUTがあること。
おのおの3バイト、アルファベット3文字分消費する。
だから、"あaいiうuえeおo"をISO-2022-JPでエンコードすると45バイトも使う。
なお、Shift_JIS、EUC-JPともに15バイト、EUC-8でも23バイトです。
まぁ現実的にメールでそんなに頻繁には変わらないけど、まぁ…
で、それはあんまり気にする必要はないのですが…
問題は半角カナです。まぁこれも実を言うとパケット節約になるのは間違っちゃいないんだけどね。
半角カナはASCIIの外側、7ビットの外側に書いてあります。だから英語の文章っぽくおくるとだめです。
まずShift_JISはなんのためのShiftなのかといえば半角カナとの共存のため。
そうじゃなきゃEUC-JPの方が優秀すぎます。
JISコードで決められた半角カナの部分を漢字の1バイト目に使わないように…
だからShift_JISで軽くなるのはまぁ当然。
で、EUC-JPは、ISO-2022-JPを単純な方法で移動させただけ。
これでASCIIコードから離したということ。
しかし半角カナとはぶつかるので、0x8Eに続けてあらわすので、
実は2バイト使います。まぁUNIXの常識なので、Webでは節約にならない気もするね。
まぁ僕みたいに強引にもShift_JISを使う人ならともかく、UNIXの常識ですから邪道ですね。
だからまぁEUC-JPは絶対に節約にならんぞと。
で、JIS-2022-JPは、確かに半角カナは1バイトであらわせています。
それも7バイト内に収まってるんで、確かに…
これはびっくりした。なるほど…なら確かに節約になる。
しかし邪道なのは事実だよなぁ…
正直どれだけ長いメールかはしらないが、受信にかかるパケット代ってわずかだし、
送信はそうそう値段変わらないし…
まぁ読みにくいですしね。最近いまいちよくありません。
まぁ昔はこれしかなかったんでね。
そういうことを理解してShift_JISは設定されたんだろうな。
まぁおかげさまで今の時代になっても半角カナを使う人が多いけど…
ちなみに僕はそんなに使わない、というか使ってないんだけれど、
ﾟとﾞだけはたまに使うことが…これも半角カナです。
あんまりよくはないんだけどねぇ…゜と゛であらわすのもレイアウト的に…
まぁこれもあんまり用途はないんだけどね…
うﾞとかいうのには使いそうですけど…
ちなみにShift-JISとかUTF-8で書いた文章をメールで送る方法はあります。
後者はどんな言語も織り交ぜて書けるのでユーザーはいるらしい。
それは、UTF-8でエンコードしてそれをbase64でエンコード。
Base64とは、3バイトがアルファベットなど4文字に変換されるという仕掛け。
これを使うと8ビットフルに使っているのが7バイトの範囲に入る。
添付ファイルで使われている。まぁその仕掛けでかける。
ただし、意味もなくBase64してあるのはフィルタではじけなくて迷惑だけどね。
まぁ聞くところによれば最近のMTAは8ビット使っても大丈夫らしいけど、
バケツリレーで送られるから、そのうち1箇所で欠落したら…
まぁ素直に7ビットにして送りましょ。