アカウント名:
パスワード:
日本中の全ての人がPC、ないしはスマホでメールを読んでくれるのならUTF-8でもいい。だがガラケーとかいうクソ馬鹿端末が存在する以上、日本語のメールはISO-2020-JP、それも-1でも-2でも-3でも、ましてや2004でもなく無印一択。なぜならあのクソ馬鹿端末は、全てのメールはISO-2022-JPという仮定の元にデコードするから。UTF-8やEUC-JPが文字化けするのは勿論、ダメ文字が含まれればUS-ASCIIでさえ容易く文字化けする。
ああわかってる。「ガラケーにメールを直接送ることなんてない。」そう言いたいんだろ?だが君が例えばGmail宛にメールを投げたとして、相手がGmailで読むとは限らない。相手はGmailに飛んできたメールは全てガラケーに転送してるかもしれない。そうしてある日突然言われるんだ。「君から送られてくるメールがさ、いつも文字化けしてるんだ。どうにかなんない?」などとね…
どうして未だに「文字コードはISO-2022-JP決め打ち」「一回に遅れる文字数は○○文字まで」などという、わけのわからない制限のついたガラケーが持て囃されるのだろう?最低限スマホで読めよ。むしろPCで読め。俺はそう言いたい。上司だから言わんけど…
http://blog.layer8.sh/ja/2012/04/16/pc%E3%81%8B%E3%82%89%E6%90%BA%E5%B... [layer8.sh]http://d.hatena.ne.jp/NAOI/20120113/1326430732 [hatena.ne.jp]ここらへん見た限りではガラケー=ISO-2022-JPとは限らないような。
#上記サイトの信憑性までは知りません。
コメントありがとうございます。
①や㈱を今まで通り無断で(1)や(株)に変換してISO-2022-JPで踏襲する踏ん切りがつきました。
「どのガラケーが」ISO-2022-JP決め打ちなんだろう。そこらがないと、1機種でも残っている限りという条件にしてしまうと、いつまで経っても状況は変わらないと思うんだけど。
一応ウィルコムだと京セラ系、SII系はUTF-8通るみたい。新規参入のシャープがあやしいけど不明。
問題は、・SMTPの仕様として問題が無いか・相手の環境で表示できるかの2段階に分かれるので、まずそこを切り分けるべきかと。
SMTPは、7bitまでしか使えないんだから、7bitに収まるようなデータを送るべき。っていう話であれば、・7bitに収まるようになってるISO-2022-JPで送る・しかるべきエンコーディングをして7bitに収めて送るのどちらか、ってことになるし。拡張SMTPじゃ8bitも使えるし、今の世の中、8bit通さないサーバなんて残ってないよ。っていうなら、そこは気にしなくていいと思います。
相手の環境の話で言うと、今時の環境で今時のメーラであれば、utf8が読めないとか、一般的なエンコード形式に非対応とか、そんなことはないでしょうし。ほとんど気にしなくていいんじゃないですかね?
まあ、それでも、結論としては、『ISO-2022-JPで送るのが一番無難で確実』ってことになるんでしょうけど、ISO-2022-JPだけではどうしようもない場合もあるので、一択とは言わずに、必要に応じてutf8も使う。ってくらいに考えておけばいいんじゃないかと思います。
あと、いわゆる『ガラケー』は、インターネットメールを直接送受信できず、キャリア側が、コード変換等を含めた中継処理を行っています。なので、適当な文字コードで投げても、だいたい問題はないはずです。
試しにezwebのガラケーに、Content-Type: text/plain; charset=utf-8でメール投げてみましたが、基本的にはちゃんと読めました。ただし、半角カナは、全角カナに置き換わっていたので、そのへんは考慮する必要があるかもしれませんが。
まさにガラパゴス、害悪しか撒き散らさない
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
そこはISO-2022-JP無印一択 (スコア:1)
日本中の全ての人がPC、ないしはスマホでメールを読んでくれるのならUTF-8でもいい。
だがガラケーとかいうクソ馬鹿端末が存在する以上、日本語のメールはISO-2020-JP、それも-1でも-2でも-3でも、ましてや2004でもなく無印一択。
なぜならあのクソ馬鹿端末は、全てのメールはISO-2022-JPという仮定の元にデコードするから。
UTF-8やEUC-JPが文字化けするのは勿論、ダメ文字が含まれればUS-ASCIIでさえ容易く文字化けする。
ああわかってる。「ガラケーにメールを直接送ることなんてない。」そう言いたいんだろ?
だが君が例えばGmail宛にメールを投げたとして、相手がGmailで読むとは限らない。
相手はGmailに飛んできたメールは全てガラケーに転送してるかもしれない。
そうしてある日突然言われるんだ。「君から送られてくるメールがさ、いつも文字化けしてるんだ。どうにかなんない?」などとね…
どうして未だに「文字コードはISO-2022-JP決め打ち」「一回に遅れる文字数は○○文字まで」などという、わけのわからない制限のついたガラケーが持て囃されるのだろう?
最低限スマホで読めよ。むしろPCで読め。俺はそう言いたい。上司だから言わんけど…
Re:そこはISO-2022-JP無印一択 (スコア:2)
http://blog.layer8.sh/ja/2012/04/16/pc%E3%81%8B%E3%82%89%E6%90%BA%E5%B... [layer8.sh]
http://d.hatena.ne.jp/NAOI/20120113/1326430732 [hatena.ne.jp]
ここらへん見た限りではガラケー=ISO-2022-JPとは限らないような。
#上記サイトの信憑性までは知りません。
Re:そこはISO-2022-JP無印一択 (スコア:1)
コメントありがとうございます。
①や㈱を今まで通り無断で(1)や(株)に変換してISO-2022-JPで踏襲する踏ん切りがつきました。
Re:そこはISO-2022-JP無印一択 (スコア:1)
「どのガラケーが」ISO-2022-JP決め打ちなんだろう。そこらがないと、1機種でも残っている限りという条件にしてしまうと、いつまで経っても状況は変わらないと思うんだけど。
一応ウィルコムだと京セラ系、SII系はUTF-8通るみたい。新規参入のシャープがあやしいけど不明。
Re:そこはISO-2022-JP無印一択 (スコア:1)
問題は、
・SMTPの仕様として問題が無いか
・相手の環境で表示できるか
の2段階に分かれるので、まずそこを切り分けるべきかと。
SMTPは、7bitまでしか使えないんだから、7bitに収まるようなデータを送るべき。
っていう話であれば、
・7bitに収まるようになってるISO-2022-JPで送る
・しかるべきエンコーディングをして7bitに収めて送る
のどちらか、ってことになるし。
拡張SMTPじゃ8bitも使えるし、今の世の中、8bit通さないサーバなんて残ってないよ。
っていうなら、そこは気にしなくていいと思います。
相手の環境の話で言うと、
今時の環境で今時のメーラであれば、
utf8が読めないとか、一般的なエンコード形式に非対応とか、
そんなことはないでしょうし。
ほとんど気にしなくていいんじゃないですかね?
まあ、それでも、結論としては、
『ISO-2022-JPで送るのが一番無難で確実』
ってことになるんでしょうけど、
ISO-2022-JPだけではどうしようもない場合もあるので、
一択とは言わずに、必要に応じてutf8も使う。ってくらいに考えておけばいいんじゃないかと思います。
あと、いわゆる『ガラケー』は、インターネットメールを直接送受信できず、
キャリア側が、コード変換等を含めた中継処理を行っています。
なので、適当な文字コードで投げても、だいたい問題はないはずです。
試しにezwebのガラケーに、
Content-Type: text/plain; charset=utf-8
でメール投げてみましたが、基本的にはちゃんと読めました。
ただし、半角カナは、全角カナに置き換わっていたので、
そのへんは考慮する必要があるかもしれませんが。
Re: (スコア:0)
まさにガラパゴス、害悪しか撒き散らさない