とりあえず、弊社で確認できる範囲で文字化けが発生しないことを確認しましたので、post.timelog.jpも新しいサーバを経由するようにし、新サーバが本番運用開始になりましたのでお知らせいたします。

Gmailでの送信で文字化けしないことを確認しています！　しかし、それでもまだ文字化けは発生する環境が存在するようです。

ただ、弊社で確認できる範囲ではもう対策をやり尽くしており、これ以上、資料がないとどうしようもありません。いったいどういうメールが文字化けするのか、知ることができないと、私としても対策を考えることができません。

実際、メーラーやキャリアによって、そのメールの仕様がまちまちであり、すべての仕様を把握するのはまず不可能で、弊社にテスト送信環境がないとなかなか原因をつかめません。

ですので、ロガーの皆様には、お願いがございます。

文字化けする環境をお持ちのロガー様は、そのメールを
info@timelog.jp
にお送りいただきたいのです。とにかく、多数のメールのヘッダをみて、それぞれの処理をどうしたらいいかの参考にしたいのです。弊社で再現環境がない以上、サンプルがないとどうしようもないのです。

この問題につきましては、本番運用をもちまして、いったん解決とさせてはいただきますが、弊社は、この件に関しましては引き続き開発を継続したいと考えています。

そこで、前述の通りのロガーの皆様のご協力がどうしても必要なのです。

現在、ご協力いただきました1名のロガー様には感謝申し上げますと共に、他のロガー様にも、ご協力をお願いしたいと思います。

よろしくお願いします！

以下、技術的考察です。

メールの標準仕様は、文字コードISO-2022-JP、7bitエンコードです。Timelog開発時は、これだけで対応出来ていたので、これ以上のサポートは考えていなかったようです。実際、ClassicASP環境ではUnicodeを扱うのが難しいため、そもそも、これ以外のメールが存在するということ自体、想定外だったと思います。

ですので、これを対応させるのは非常に難しい作業となります。Timelog側がどんな文字コードも柔軟に受け入れてくれれば問題は発生しないのですが、ClassicASPにそんなことは求めることはできません。

なので、メールサーバのPHP側で、送信されたメールを一つずつ解析し、文字コードやエンコードを解析した上で、ISO-2022-JP、7bitへ変換し、Timelogサーバに引き渡すという処理が必要になって参ります。

そのPHP側での解析で、様々なサンプルが必要になってきます。

ISO-2022-JP、7bitだと判断すればそのまま投稿。UTF-8、base64エンコードだと、デコード後、文字コード変換でOKでした。ここまでは弊社の環境で再現できました。

追って、UTF-8、8bitエンコードの環境も発見され、デコードせずに文字コード変換する分岐処理も加えました。また、メールをお送りいただいたロガー様のヘッダを解析し、文字コードやエンコードの表記揺れが発生することが確認されましたので、これに対応し、表記に誤差があっても文字コードやエンコードを判定できるように改良しました。

しかし、それでもなお、文字化けが発生する環境が存在するようです。それはいったいどんな文字コードなのか、どんなエンコードなのか、そしてそれはどのように記述されているのか。

そもそも、その記述は、実際の文字コードやエンコードと一致しているのか。

メールって標準仕様があるはずなのに、各社が勝手に色々やってて、もう分からないことが多すぎます。もうヘッダの記述は当てにせず、実際の本文だけで文字コードを自動判定する仕組みを導入した方が当たる確率が高いのかな、と思ったり。

メールを送信いただく形のご協力の他にも、PHPソースコードの開発においてご協力いただけるロガー様も募集します。