ひさびさのちょっとプログラマーっぽいこと。
とあるシステムで、入力された内容をメールの本文に張り付けて送信する、というプログラムを組んだ。
組んだ、というか、引き継ぎプロジェクトだから、組まれてた。
で、システム自体はうまく動いてたんだけど、あるとき、送信したメールが途中から文字化けしたと、クライアントから問い合わせが。
■原因はなにかを調査。
最初は、文字のエンコードを疑ったけど、そもそもエンコードの問題なら全体が化けるだろ、ってことで、この線は消えた。
次に、機種依存、環境依存の文字が入ってるのかな?とも考えたけど、文字の化け方からして、どうやらそんな感じでもない模様。
文字が、「$$30$FKJQ$@,s-$o」みたいな感じになっていた。
で、Google先生のお力に頼っていたところ、どうやら、メール1行あたりの文字数が多すぎることが原因のようだった。
■RFC2822
2.1.1. Line Length Limits
There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF.
RFC「インターネットメッセージフォーマット」から抜粋。
1行の長さは998文字でなければならない。(必須)そして、78文字以内でおさめるべきである。(推奨)
「文字」となっているけれど、これはおそらく、998バイト、また、78バイトが正しいように思える。
半角英数字は、1文字が1バイト。
ここは日本。使われる日本語はほとんどが2バイト以上になる。
とすると、半角英数2文字で、日本語1文字分に相当するので、1行あたりの最大入力文字数は、約500文字ってことになるわけ、だよね?
photo by MIKI Yoshihito (´・ω・)
■もういちど問い合わせを見直す。
添付してくれた、文字化けメールを見たところ、1行に800文字入ってた。
・・・。
普段、自分がメールしたり、問い合わせ用のテキストフォームに入力するときは、適当に改行してたので、思いもよらなかった。
ということで、現在その対策処理を実装中。
詳しくは書かないけど、入力された内容を改行文字で配列に入れて、1行あたりの文字数を調査。
一行あたりの最大文字数を下回るまでその行の途中で強制的に改行文字を挿入していく。
それが終わったら、また次の行に・・・みたいな感じ。
改行文字で分割して配列にいれて、foreach、でwhileで一行ずつ検査してったらすぐできるっしょ。
wordwrapという便利な関数があるけど、マルチバイト対応してないな・・・
あ、smartyにmb_wordwrapがあるみたい。
- 作者: 網野衛二
- 出版社/メーカー: 技術評論社
- 発売日: 2010/01/06
- メディア: 単行本(ソフトカバー)
- 購入: 4人 クリック: 129回
- この商品を含むブログ (11件) を見る