- ベストアンサー
UTF-8でのメール送信の問題点
- UTF-8のメール送信には注意が必要！知っておくべきポイントとは？
- UTF-8とISO-2022-JPの違いは？大手企業のメールはなぜISO-2022-JPを使っているのか？
- 文字化けを防ぐためにはどうすればいい？
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
> 821 は obsolete だから参照しちゃダメですよぉ＞#2. 今なら少なくとも 2821 の方を参照しないと.... 2821 は obsolete だから 5321 を参照しないと。 ただし、UTF8 を使うかどうかの判断に RFC5321 や RFC5322 はあまり関係ない。 (8bit対応してないSMTPサーバーがいるかもしれないから7bitにencodeしてねとかそれくらい) 受け取る人が限られていてその人たちがUTF8で問題ないならUTF8で送れば良いと思います。 Amazon や Yahoo! は受け取る対象が不特定多数なので ISO-2022-JP が無難なわけですね。
その他の回答 (3)
- Tacosan
- ベストアンサー率23% (3656/15482)
821 は obsolete だから参照しちゃダメですよぉ＞#2. 今なら少なくとも 2821 の方を参照しないと.... 2821 には「SMTP サーバは 8BITMIME をサポートしなきゃだめ」って書いてあるけど, 逆に「8BITMIME を無制限に許しているわけではない」という感じに読める (英語だと 8BITMIME SHOULD be supported by SMTP servers. However, it MUST not be construed as authorization to transmit unrestricted eight bit material. と書いてある) ので, 「途中」を考えると 8ビットで送るのはちょっとリスキーかもしれない.
- kabaokaba
- ベストアンサー率51% (724/1416)
逆に聞きますが なぜUTF-8でメールをしようと思うのですか？ なぜISO-2022-JPではダメなんですか？ で・・ISO-2022-JPですけど， この符号化は「7ビット」でOKだから使われてるんですよ． 8ビット目があるとわけのわからんことしてくれる （8ビット目はクリアされてしまう） サーバが昔は結構あったのです． 今でもそーいうサーバが生き残ってるかもしれないし， ＃しらべてみたら・・・SMTPのRFC821では7ビットに規定してるようだ メールシステムはいわば「バケツリレー」だから， 安全性を考えれば，ISO-2022-JPとなるのでしょう．
補足
回答ありがとうございます。 ＞逆に聞きますが ＞なぜUTF-8でメールをしようと思うのですか？ ＞なぜISO-2022-JPではダメなんですか？ ISO-2022-JPでは髙や﨑が文字化けするからです。 先週、ここで質問したときに、UTF-8にするようアドバイスいただきました。 http://oshiete.goo.ne.jp/qa/6471012.html ISO-2022-JPでも髙や﨑が文字化けしない方法あるのでしょうか？
- nora1962
- ベストアンサー率60% (431/717)
日本国内のPC間でやり取りするならほぼ問題ないかと思います。 ただ、歴史的には7bitが保証されているので海外はどうかな？ 後、困ってしまうのが携帯へのメールです。 http://jp.layer8.sh/reference/entry/show/id/198 auはUTF-8には対応していないのです。 というか、キャリアごとにバラバラですね。 > ISO-2022-JP だと 髙 などが文字化けするはずなのですが、髙→高に変換してメー > ル送信しているのでしょうか？ これはしません。文字化けします。
![その他([技術者向] コンピューター) イメージ](https://gazo.okwave.jp/okwave/images/related_qa/c205_4_thumbnail_img_sm.png)
補足
回答ありがとうございます。 相手は不特定多数です。 No.2さんへの補足でも書きましたが、ISO-2022-JPだと髙や﨑が文字化けすると思います。 文字化けすることについて、http://oshiete.goo.ne.jp/qa/6471012.html でアドバイスいただき、UTF-8にしようと思いました。 しかし、UTF-8だと危険なようですね。 ISO-2022-JPでも髙や﨑が文字化けしない方法あるのでしたらいいのですが。。。