アカウント名:
パスワード:
相手に「文字化けするんでMUAの設定を変えてください」とか言いづらいのよね。
とはいえ、こっちのMUAがタコだと、引用した相手のメールに含まれる文字の所為で、今度はこっちのメールが相手の手元で文字化けしちゃったりする場合もあったりして。
# テメェのことだよ>Notes
あの、Base64エンコードされたISO-2022-JPのSubjectのわりにBodyがUTF-8で、添付された日本語ファイル名がBase64エンコードされたShift_JISというメールを送ってくる子ですね。
それぞれ文字コードの指定はちゃんとしているので、悪いとは言わないけどセンスがない気がします。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
受け取れない奴が悪い (スコア:2, すばらしい洞察)
どうしても読みたいなら適切なクライアントを用意するはず。
大体、すべてiso-2022-jpで来ることを期待するなんて設計や思想そのものが間違っている。
「送る場合は厳密に、受け取る場合は寛容に」なんて送受信を行う上での基本でしょ。
というのは暴論でしょうか。
Re: (スコア:1, すばらしい洞察)
例えばcharset="iso-2022-jp"なのにSJISで送ってくるようなメールとか、
multipartなのにboundaryがない(MIMEのpreambleしかない)メールを
表示できるような寛容さはスパム対策上好ましくない気がします。
文字コードとは関係ないですけど、IE等の「寛容な」HTML解釈でinvalidなHTML文書
が氾濫した状況を見ると、受け取る場合こそ厳密にやるべきなんじゃないかとも思います。
ビジネス用途だとなぁ (スコア:0)
相手に「文字化けするんでMUAの設定を変えてください」とか言いづらいのよね。
とはいえ、こっちのMUAがタコだと、引用した相手のメールに含まれる文字の所為で、今度はこっちのメールが相手の手元で文字化けしちゃったりする場合もあったりして。
# テメェのことだよ>Notes
Re:ビジネス用途だとなぁ (スコア:1)
あの、Base64エンコードされたISO-2022-JPのSubjectのわりにBodyがUTF-8で、添付された日本語ファイル名がBase64エンコードされたShift_JISというメールを送ってくる子ですね。
それぞれ文字コードの指定はちゃんとしているので、悪いとは言わないけどセンスがない気がします。
運転手は運転がお仕事。笑うのはブギーポップにはできない僕らのお仕事。