.NET Core 2.0 アプリで JIS 形式 (iso-2022-jp) なメールを SmtpClient で送信する

C# などを使い、.NET Core ランタイム上で動作する .NET Core 2.0 なアプリ (ASP.NET Core 含む) を開発していての話。

そのようなアプリ開発で、JIS (iso-2022-jp) エンコードなメールを、System.Net.Mail.SmtpClient を使って送信するにはどうしたらよいか、というのが今回のテーマである。

もっとも、イマドキ、アプリからのメール送信の需要は衰退の一途のような気がする (通知なら Slack や LINE、Skype などへの Bot 投稿で実装するほうがよい?)。
仮にメール送信の需要が発生したとしても、SendGrid の Web API 叩いたり、Microsoft Azure の LogicApps サービスを使ったりしてメール送信を実装したほうがよさげなので System.Net.Mail の出番はなさそうだ。
ましてや今更 JIS エンコードなメールなどほとんど絶滅危惧種ではないかとも思われる。

が、とりあえずそのような要件が発生してしまい、実装に着手したものとする。

標準の文字エンコーディング情報では不足

この場合は、下記のようなコード (例は C#) で実現するのがよくある実装かと思う。
using System.Text;
using System.Net.Mail;
...
var iso2022jp = Encoding.GetEncoding("iso-2022-jp");
var msg = new MailMessage
{
BodyEncoding = iso2022jp,
SubjectEncoding = iso2022jp,
HeadersEncoding = iso2022jp
};このコードは、旧来からある .NET Framework 用アプリでは問題なく動作する。

しかしながら、.NET Core 用アプリでは実行時に下記例外が発生してしまう。System.ArgumentException : 'iso-2022-jp' is not a supported encoding name. 発生個所は「Encoding.GetEncoding("iso-2022-jp")」しているところ。
.NET Core ランタイムでは、標準の文字エンコーディング情報に、JISエンコーディングが含まれていないためだ。

この例外への対処は簡単である。

まず NuGet から System.Text.Encoding.CodePages パッケージをプロジェクトに追加してやる。

System.Text.Encoding.CodePages

あとはアプリの初期化のタイミングで、上記パッケージに収録されているエンコーディング情報をランタイムに登録してやればよい。using System.Text;
...
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);System.Text.Encoding.CodePages パッケージには JIS (iso-2022-jp) エンコーディング情報も収録されている。
よって、上記仕掛けを施したあとは、「Encoding.GetEncoding("iso-2022-jp")」でちゃんと Encoding オブジェクトが返ってくるようになる。

参考: OPC Diary - dotnet coreで対応しているテキストエンコーディング

System.Text.Encoding.CodePages でも不足の点が

ところが、である。

たいていの文字エンコーディングを扱う .NET Core プログラムにおいてはこれで問題解消となるのだが System.net.Mail.SmtpClient を使ったメール送信では、この対処だけではまだ足りない。

Send メソッド実行時に下記例外が発生して、相変わらず JIS (iso-2022-jp) エンコーディングでのメール送信ができないのだ。System.NotSupportedException : No data is available for encoding 50220. この例外のスタックトレースを見てみると、at System.Text.Encoding.GetDataItem()
at System.Text.Encoding.get_BodyName()となっている。

どうも、Encoding オブジェクトの BodyName プロパティの getter で例外発生しているようだ。

念のため Visual Studio 上でブレークポイントを張って問題個所の前で停止させて、JIS エンコーディングのオブジェクトを見てみると、下図のとおり。ご覧のとおり、BodyName プロパティの参照で System.NotSupportedException 例外が発生している (BodyName プロパティに限らないが)。

他に Shift-JIS と euc-jp についても確認してみたところ、いずれも BodyName プロパティ参照で System.NotSupportedException 例外が発生した。

参考までに、ランタイム標準で備わっている UTF-8 (Encoding.UTF8) については、BodyName プロパティは、ちゃんと "utf-8" を返す。

どうやら、System.Text.Encoding.CodePages パッケージで供給される追加のエンコーディング情報、少なくとも上記 JIS, Shift-JIS, EUC-JP については、BodyName プロパティがサポートされていないようである。

いっぽうで System.Net.Mail.SmtpClient は Encoding オブジェクトの BodyName プロパティに依存しているようだ。
それで前述のとおり JIS エンコードなメールを送信しようとすると例外発生に至ってしまうらしい。

ラッパークラスを実装して回避

System.Text.Encoding.CodePages パッケージで供給される追加のエンコーディング情報について、なぜに BodyName プロパティがサポートされていないのか自分はわかっていない。

しかしとにかく、問題のメカニズムは判明したので自前の回避策は実装可能だ。

自分が実施した回避策は、
「BodyName プロパティを正しく返すよう補完実装した、Encoding から派生したラッパークラスを実装する」
という作戦。

使い方としては、まず、オリジナルの Encoding オブジェクトを、このラッパークラスのオブジェクトで包んでおく。
そして、そのラッパー Encoding オブジェクトを System.Net.Mail に教えてやる、という寸法だ。

このラッパークラスは、外部からのあらゆる問い合わせを、内包しているオリジナルの Encoding オブジェクトに横流しするだけにしておく。
ただし、オリジナルの Encoding オブジェクトが答えられない、BodyName プロパティについてだけは、オリジナルに代わってラッパークラスが返答する、という仕組みにするわけ。


ということで、そのようなラッパークラス "BodyNamePatchedEncoding" クラスを書いてみた。
下記に置いてある。

https://gist.github.com/jsakamoto/87d5b76387d8287ba6cea0362777c206

このラッパークラスの実装に面白いところは全くない。

このラッパークラスのコンストラクタで、ラップする対象の Encoding オブジェクトと、BodyName プロパティ値を受け取り、このふたつをインスタンスメンバーに保持。

あとは、Encoding オブジェクトとして必要なふるまい・プロパティ値は、メンバーに保持しているラップ対象の Encoding オブジェクトに丸投げするだけ。
ただし、BodyName プロパティだけは、コンストラクタで指定された値を返す。

BodyNamePatchedEncoding クラスの実装コードは行数がなかなかのボリュームになっている。
しかしそのほとんどが前述のとおり、ラップしている Encoding オブジェクトへ処理を横流ししているだけの、刺身タンポポ感たっぷりのコードだ。


なお、実際に BodyNamePatchedEncoding クラスを実装して System.Net.Mail.SmtpClient による JIS エンコーディングなメール送信を試したところ、最初はまたもや例外となった。
その例外の内容を見ると、どうやら SmtpClient は BodyName プロパティのみならず HeaderName プロパティも 参照してる模様。
且つ、HeaderName プロパティも System.Text.Encoding.CodePages パッケージの実装ではサポートされておらず、それでまたもや例外となったようである。
そこで、HeaderName プロパティについても BodyNamePatchedEncoding クラスがオリジナルに代わって返答することとし、返答の内容は、実装の手を抜いて、BodyName プロパティと同値を返すようにした。


以上で、この BodyNamePatchedEncoding クラスを使えば、晴れて、.NET Core アプリでの System.Net.mail.SmtpClient にて JIS エンコーディングなメール送信が実現できるようになった。using System.Text;
using System.Net.Mail;
...
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
...
var iso2022jpOriginal = Encoding.GetEncoding("iso-2022-jp");
var iso2022jpWrapped = new BodyNamePatchedEncoding(
encoding: iso2022jpOriginal,
bodyName: "iso-2022-jp");
var msg = new MailMessage
{
BodyEncoding = iso2022jpWrapped,
SubjectEncoding = iso2022jpWrapped,
HeadersEncoding = iso2022jpWrapped
};

まとめ

.NET Core では、ランタイムが標準で提供している文字エンコーディングはかなり限定されている。

不足のエンコーディング情報が必要な場合は、System.Text.Encoding.CodePages パッケージをプロジェクトに追加して、追加されたエンコーディング情報をランタイムに登録すればよい。

しかし System.Text.Encoding.CodePages パッケージで提供される Encoding クラスの実装では、BodyName プロパティや HeaderName プロパティなどサポートされていない機能がある。

.NET Core の System.Net.Mail.SmtpClient は Encoding オブジェクトの BodyName および HeaderName プロパティを使用するので、System.Text.Encoding.CodePages パッケージで提供される Encoding クラスを指定してのメール送信では例外が発生してしまう。

これを回避する一案としては、実装が不足している機能を補うラッパー Encoding クラスを自前実装することで可能であり、実際に BodyNamePatchedEncoding クラスを実装してみて、無事メール送信に成功した次第。

補足

System.Text.Encoding.CodePages パッケージで提供される Encoding クラスの実装では、なぜ BodyName プロパティなどがサポートされていないのか、その理由が気になるところではある。
どのような設計指針・方針でサポートしないこととなったのだろうか、あるいはまた、System.Text.Encoding.CodePages パッケージの将来バージョンでは、これら機能の実装も追々追加されるのか、要注意ではあると思う。


あともうひとうつ別の話題として、ここまでの実装だと、どこか別の箇所で "Encoding.GetEncoding("iso-2022-jp")" などと Encoding オブジェクトの取得を行った場合は、相変わらず、BdoyName プロパティが機能しないオリジナル版の Encoding オブジェクトが返されることになる。

"Encoding.GetEncoding("iso-2022-jp")" を実行時も、BodyNamePatchedEncoding オブジェクトが返されるようにするには、もうひと手間必要だ。
言い換えると、もうひと手間必要ではあるが、しかしとにかく実装可能ではある。

その方法については、また機会を改めたい。