んとねあのね。
とりあえず嫌な結果になりました orz
発端は「メールで半角かなを送りたい」いやだからiso-2022-jpに半角かなって世界観無いから。
…ともいえず。なにせ他社がやってる(ここで「他人が違反をしたら自分も違反をしていいのか」とかいった類の議論は破却される)。
とりあえず淡い期待と灰色の脳細胞が生み出す可能性を色々と実験。
まずは軽くジャブ。
$s = 'ﾊﾝｶｸｶﾅ';
という文字列(sjis)と
$ss = mb_convert_encoding($s, 'iso-2022-jp', 'sjis');
という文字列を用意、手持ちの「文字列をバイナリ出力(ようはdump)」でチェックしてみました。
((ca)(dd)(b6)(b8)(b6)(c5)) ((3f)(3f)(3f)(3f)(3f)(3f))
ちなみに3fはアスキーコードで？。
この時点で「iso-2022-jp」がNGですいけない子ちゃんです使えないことが判明です。
次。ちょいと雑に
mb_send_mail('wdsliusr@localhost' , 'ｻﾌﾞｼﾞｪｸﾄ' , '全体としてはﾊﾝｶｸｶﾅによるメッセージ');を、やはりsjisで。
メールの結果は
Subject: =?UTF-8?B?wrvDjMOewrzDnsKqwrjDhA==?=
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: BASE64wpFTwpHDjMKCw4bCgsK1woLDhMKCw43DisOdwrbCuMK2w4XCgsOJwoLDpsKCw6nCg8KBwoNiwoNa woFbwoNX
となります。
base64を解いてみますが
((c2)(91)(53)(c2)(91)(c3)(8c)(c2)(82)(c3)(86)(c2)(82)(c2)(b5)(c2)(82)(c3)(84)(c2)(82)(c3)(8d)(c3)(8a)(c3)(9d)(c2)(b6)(c2)(b8)(c2)(b6)(c3)(85)(c2)(82)(c3)(89)(c2)(82)(c3)(a6)(c2)(82)(c3)(a9)(c2)(83)(c2)(81)(c2)(83)(62)(c2)(83)(5a)(c2)(81)(5b)(c2)(83)(57))
ちなみに「全然だめ」です(どゆ変換したのかすら不明)。
次。もしかして「文字コードの自動認識の問題？」と疑い、
mb_send_mail('wdsliusr@localhost' , mb_convert_encoding('ｻﾌﾞｼﾞｪｸﾄ', 'utf-8', 'sjis') , mb_convert_encoding('全体としてはﾊﾝｶｸｶﾅによるメッセージ', 'utf-8', 'sjis'));こちらを実験君。
Subject: =?UTF-8?B?w6/CvcK7w6/CvsKMw6/CvsKew6/CvcK8w68=?=
=?UTF-8?B?wr7CnsOvwr3CqsOvwr3CuMOvwr7ChA==?=
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: BASE64w6XChcKow6TCvcKTw6PCgcKow6PCgcKXw6PCgcKmw6PCgcKvw6/CvsKKw6/CvsKdw6/CvcK2w6/C
vcK4w6/CvcK2w6/CvsKFw6PCgcKrw6PCgsKIw6PCgsKLw6PCg8Khw6PCg8KDw6PCgsK7w6PCg8K8
w6PCgsK4
微妙いけてそうですが、やはり駄目です。
というわけで。まず「ざくりとmb_send_mail使った」程度ではいかんともしがたいことが判明しました(なんかTipsがある可能性はありますが…まぁ使いにくいです)。
つぎ。
面倒なんで、各キャリアの受信状況をチェックします。
popenつかって /usr/sbin/sendmail コマンドにpipeで接続、任意の文字列流し込んで意図にそうように動かしました。
ちなみに。SoftBankは大変にガードが固く。From行で嘘ついたり(サーバ情報が違うとNGっぽい)するとはねられます。
今回は
Mime-Version: 1.0
Content-Transfer-Encoding:
Content-Type: text/plain; charset=
Subject:
を添付しました。
で、実験。
方向性としては
・文字コードshift-jis
・文字コードshift-jisで、本文をbase64エンコード( headerに Content-Transfer-Encoding: BASE64 を添付)
・文字コードEUC
・文字コードEUCで、本文をbase64エンコード( headerに Content-Transfer-Encoding: BASE64 を添付)
・文字コードUTF-8
・文字コードUTF-8で、本文をbase64エンコード( headerに Content-Transfer-Encoding: BASE64 を添付)
面倒なんで結果から。
utf-8及びeucがEZのみ文字化け。bodyをbase64化するのもEZがだめ。
あと問題になるのは概ね半角かな文字です(絵文字は、おそらく「sjift_jisバイナリ」のみを受付ます：未実験なので誰か知ってたら追記よろしくです：実態参照については実験の結果「未変換」であることが確定しています)。
かくして結論は「生のshift-jis」しかありえないだろう、という結論に達しています。
# 半角かなと絵文字がない、真っ当なメールならiso-2022-jpでよいのですが
さてはて…先人の知恵とかRFCとかなんとかってのはいったいどこに消えたのでしょう？ 的結果になりましたが。
とりあえず、これがどうやら現実です。
………困ったものです orz
