元々使用禁止なのは一部サーバが8ビット目を通さない為だったはずだから、base64エンコードしてあれば問題無し。
http://anond.hatelabo.jp/20070413110712 http://anond.hatelabo.jp/20070413113434 ですよねー。 てなわけで、有料通信でメールヘッダを調べてみました。 content-type: text/plain; charset="ISO-2022-JP" の文字列を確認。 ...
正直に書くと、その手の表に出ない部分はまったく感知しない、してても工数の関係であえて無視すると言うのが当然にまかり通ってるメーカーが多い。 当然後で無駄な保守費用が発生...
http://anond.hatelabo.jp/20070413135718 RFC的には正しくないけど (少なくとも私の環境では)文字化けせずに届いてるし メールの通信パケットも節約してる。 サービス提供元に「RFC違反だ糞 直せ...
自分とこさえよければいいよ論者ですか。 間違ったのを厳密に駄目、直させろ!って言ってる訳じゃないけど、メールの中継パスに規格を厳密に守ったサーバが1台でもあれば、届いた...
サービス提供元に「RFC違反だ糞 直せ糞」ってゴネたところで 誰一人特をしない問題だと思うんですが なんで誰一人得をしないの? 論理が繋がっていないじゃん。
ISO-2022-JP を名乗っているならRFC的にアウト。 ISO-2022-JP にいわゆる半角カタカナは定義されていないから。