お世話になっております。
サンプル設置URLで送信テストしたところ、テキストエリアに500文字以上入力すると文字化けします。
https://www.1-firststep.com/samplephp/mailform-v7.1/index.html
iphone7で受信した場合と、macのmailで受信した場合では、
「文字化けが始まる箇所」は一緒でしたが、
文字化けの範囲はiphone7の方が多かったです。
解決法がございましたら教えていただければ幸いでございます。
▼テキストエリアに入力した文字
この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はこの文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はこの文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。この文章は
上記の、
>>iphone7で受信した場合と、macのmailで受信した場合
は、同じメールアドレスで同時に受信した場合です。
なお、受信したアドレスはgmaiiで、その他のメールフォームで文字化けしたことはありません。
Responsive Mailform 文字化け で検索したところ、『入力時htmlspecialchars』をしている
と記載あるページを見つけましたが関係ありますでしょうか。
https://qiita.com/rana_kualu/items/7adb59d3f5734789fe31
デザインや使用感が良いので是非使いたく存じます。
お忙しいところ恐れ入りますがよろしくお願い申し上げます。
症状を確認できました。
これは「メールの本文が1行で998文字を超えてはいけない」というRFC2822の仕様に基づき、サーバのMTA(メール送信機能)側で発生する現象だと思われます。
http://srgia.com/docs/rfc2822j.html#p2.1.1
ですので例えば、
この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。
この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。
この文章はダミーです。文字の大きさ、量、字間、行間等を確認するために入れています。
というように改行を入れておけば、同じだけの文字数を記入して送信しても文字化けは起きません。
メールフォームプログラム側で一定以上の文字数の場合に、自動的に改行を入れる処理をすることも可能です。
が、実際の運用上では改行を一切挟まずに1000文字以上を書く人は稀だと考えられるため、この症状の修正は今すぐには実施せず、次回アップデートの際に実施いたします。
> Responsive Mailform 文字化け で検索したところ、『入力時htmlspecialchars』をしている
> と記載あるページを見つけましたが関係ありますでしょうか。
上記について解説を致します。
このメールフォームでは各入力欄に入力された内容についてhtmlspecialchars関数の処理をしているため、以下の文字が存在した場合は、
& (アンパサンド)
" (ダブルクォート)
' (シングルクォート)
< (小なり)
> (大なり)
それぞれが以下のように変換されます。
&
"
'
<
>
これは文字化けというよりもhtmlspecialchars関数の正常な処理になるのですが、このメールフォームの仕様のようにプレーンテキスト形式でのメール送信の場合は不要な処理となります。
しかし、「入力内容確認アドオン」を使用した際はXSS(クロスサイトスクリプティング)攻撃を防ぐためにhtmlspecialchars関数は必要な処理となるため、現状ではそのまま残してあります。
もしかしたら今後のアップデートで「メール送信時」と「入力内容確認時」で処理を振り分けるかもしれません。
というわけでhtmlspecialchars関数の文字変換については、現状では運用上の大きな問題となっていないため、この症状については「要検討」とさせておいてください。
htmlspecialchars関数の文字変換については、バージョン7.2.1でメール本文のほうでは変換しないように対応されました。
1000文字以上の際に改行させる処理はまだ未対応です。