色々調査をしたのですが、解決できませんでしたので皆さんのお知恵をお貸しください。

現在、メールの送信はSC_SendMail.phpにて、"ISO-2022-JP"で送信しています。

しかし、色々なお客様がいらっしゃるため、名前や住所で"ISO-2022-JP"に
設定されていない文字を登録される方がいらっしゃいます。
(実際フロントやDBは"UTF-8"なので気づきようがないですね…)

これに対して対策を検討しており、どのような対策がベターなのか行き詰って
しまいましたので、ご意見ください。

1.ヘッダの指定やエンコードを"UTF-8"で送信する。

　⇒一部のメーラやSMTPで文字化けする可能性が…

2.ヘッダは"ISO-2022-JP"でエンコードを"ISO-2022-JP-MS"で送信する。

　⇒デメリットがうまく調べきれませんでした。
　　デメリットがないわけではないと思いますが…

3.1文字ずつ文字コードを確認し、"ISO-2022-JP"に設定がない文字コードの場合、
　"ISO-2022-JP"の文字コードに変換する。
　例.?→(株)、?→１

　⇒うまく変換できない文字の対処が難しい。

4.ほかに妙案があればご意見ください。

引用：

JIS X 0213 の文字集合で追加された文字を使用した場合は、 ISO-2022-JP-2004 に対応したメーラーでないと文字化けしてしまいます。
この点、 最初から UTF-8 でエンコードしておけば、JIS X 0213 の文字集合にも対応しており、対応したメーラーも多いと思われるので、デメリットは少ないと思われます。

そもそも、 OS やフォントが JIS X 0213 の文字集合を扱えない場合は、どちらにしろ文字化けしてしまいます。
素朴な疑問ですが、 ISO-2022-JP しか受けつけないメーラーで、 JSO-2022-JP-MS の拡張文字を完璧に表示できるのでしょうか。。。

ということで、個人的には UTF-8 を推したいですが、ターゲット顧客が使用している環境によって選んだら良いと思います。

# エンコーディング変更は SC_Sendmail を結構慎重にカスタマイズしないと難しかった記憶が。

顧客が不特定多数という位置づけだったので悩んでいたのですが
現実としてあまり困っている人はいないようですね。
とりあえず危ない橋は渡らず人間が文字を直すことで対応しようと思います。
1987年に制定された7ビットコードをずっと使い続けてるってのも
なんか微妙なんですけどねぇ…
化石SMTPが排除されてUTF-8が世界標準にならないかしら…
※OBP25の時に更新されてればいいんですけどねぇ

対応状況→解決済み