アカウント名:
パスワード:
Content-Transfer-Encoding: base64 という手もありますね。
というか、たれ込みの時点で文字集合と符号化を混同しているような気がします。
シフトJISでもUTF-8でもbase64で符号化したら7bitで通せますよね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
受け取れない奴が悪い (スコア:2, すばらしい洞察)
どうしても読みたいなら適切なクライアントを用意するはず。
大体、すべてiso-2022-jpで来ることを期待するなんて設計や思想そのものが間違っている。
「送る場合は厳密に、受け取る場合は寛容に」なんて送受信を行う上での基本でしょ。
というのは暴論でしょうか。
Re: (スコア:5, 興味深い)
e-mail の場合、送信者と受信者だけでなく中継者も考えに入れる必要があります。
昔は8ビット目をクリアしてしまう中継者がたくさん居ました。
運悪くそのような中継者に当たってしまうと、文字化けします。
そのような中継者が絶滅したと言い切れないのであれば、
iso-2022-jp を使うべきです。
# もう絶滅したよね、と思ってたら2006年に遭遇しました…。
# いい加減滅ぼしてくれよ。
Re:受け取れない奴が悪い (スコア:3, すばらしい洞察)
Content-Transfer-Encoding: base64 という手もありますね。
HIRATA Yasuyuki
Re:受け取れない奴が悪い (スコア:3, すばらしい洞察)
というか、たれ込みの時点で文字集合と符号化を混同しているような気がします。
シフトJISでもUTF-8でもbase64で符号化したら7bitで通せますよね。
Re:受け取れない奴が悪い (スコア:1)
base64のデコードくらいは別途コマンドなどでも可能なのですが、よほど重要な(人からの)メールじゃない限り読み飛ばしてしまうでしょうね。
Best regards, でぃーすけ