nDiki : CRLF

CRLF - CR + LF

CR の次に LF がくるシーケンス。

0d + 0a

Perl では "\015\012"

関連情報

スポンサード リンク

2004年1月25日 (日)

[ WiKicker ] 通知メールの Subject: フィールドのエンコーディング修正

WiKicker には通知メールの Subject: フィールドがたまに壊れている問題があるのだが、ずっと放置しておいたままだった。 そろそろ次のバージョンをリリースしたいと思うので、今回修正しておく。

結果半日かかってしまった。

MIME::Words::encode_mimewords

まず現在エンコーディングに使っている MIME::Words::encode_mimewords (5.404)であるが、マニュアルを見ると charset によってはマズいエンコーディングを吐くらしい。 WiKicker で Subject: ヘッダが壊れるのも、この問題のせい。 文字境界を無視してぶったぎってエンコードされてしまう。 ということで、自前でエンコードする事にする。

自前エンコーダ

まぁたいしたものではないが。 最初はエンコードする必要のある部分だけ encoded-word にする事も考えたのだが、面倒なのでやめ。 全部エンコードしてしまう事にする。 エンコーディングも最初は、"Q" encoding実装しはじめたのだが(MIME::Words のデフォルトがそうなので、WiKicker でもそれを使っていた)ちょっと面倒なので、"B" encoding に変更。

タイトルの途中に空白が入ってしまう?

で、テスト。うーん。途中に余分な空白が入ってしまうな。 mew で受信したメールを見ると folding のところで余分な空白が入って表示される。 RFCとか見ても encoded-word に挟まれた CRLF SPACE は無視されるはずなんだけれどなぁ。

UTF-8 の代わりに ISO-2022-JPにしてみたりとか、エンコーディングを変えてみたり(Q or B)したのだが変わらず。 他から受けとっているメールは問題ないから、mew の問題でもなさそうだし。

ん? mew の inbox を確認してみると、他のソフトからのは \n, space でフォールディングされているな。 今書いているコードから送ったやつは \r\n, space でフォールディングされている。 RFC的には CRLF space では?

問題は別のところに

WiKicker で \r\n, space でフォールディングしているところを \n, space でフォールディングするようにしたら直る。 けど、これでいいのかな?

って良く考えたら、他の部分はヘッダでも本文でも改行には \n を使っているんだった(Perl のヒアドキュメントを使っているので)。 ということは今まで、それを標準入力から受けとった sendmail が LFCRLF にしてくれていたのか。 あまり深い事考えてなかったな。 今回はフォールディングのところだけで CRLF にしたため 一個余分に CR がついてしまい、それがタイトルの文字列中の空白として表示されてしまったと。

結局疑うべきは自分のコード。

スポンサード リンク
[ 1月25日全て ]

2005年1月8日 (土)

NSIS が再び Linux でコンパイルできるように

2.01 で POSIX プラットフォームで動くようになった NSIS であるが、2.02、2.03 は Linux上ではソースパッケージからのビルドエラーになってしまっていた。

1月5日に 2.04 がリリースされたので、こちらも試してみる。お、ビルドできた。

 tar jxvf nsis204.tar.bz2
 cd NSIS/Source
 make USE_PRECOMPILED_EXEHEADS=1
 cd ..
 su
 ./install.sh /usr/local/NSIS-2.04

インストール時に Menu ディレクトリが無くてエラーメッセージが出るのは前回と一緒。CVS リポジトリをみるとHTMLで書かれたドキュメントがあるだけのようなので、無くても問題なさそうである。 付属の install.sh も改行コードが CRLF から LF に修正されているためそのまま実行できるようになった。


[ Linux 上で NSIS ]

[ 1月8日全て ]

2006年7月28日 (金)

PerlCR/LF/CRLF 全対応の1行毎読み込み処理

Perl プログラムでテキストファイル処理を 改行コード CR/LF/CRLF 全対応にしようと思ったが、書こうとするとこれが結構面倒臭いことに気がつく。

$/ に正規表現が設定できないため、<FILEHANDLE> で単純に3パターン対応ができない (LFCRLF に対応とかならすぐできる)。

小さいファイルと仮定して良いなら全部読み込んで自前で行分割、大きいファイルならまじめにバッファリングして改行コードをスキャンして行処理するのが正攻法かな。 多少効率悪くなりそうだけれど。

Pod::Html (1.0504) の場合

Perl 5.8.8Pod::Html (1.0504) だと pod2html の中で $/ = "" と設定して、パラグラフ単位で読み込んでそのあと処理している。

PerlIO レイヤー

最近の Perl であれば PerlIO::crlf、 PerlIO::eol あたりが使えそうである。

もちろん Perl 5.005_03 だと NG。

[ 7月28日全て ]

2010年6月3日 (木)

今日のさえずり: ガントチャート上で線をぴゅっと動かして

2010年06月03日

[ 6月3日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.052941s / load averages: 0.44, 0.44, 0.38
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker