charset(IANA) | |
Shift_JIS | シフト JIS |
EUC-JP | 日本語EUC(圧縮形式) |
ISO-2022-JP | ISO-2022-JP (RFC1468) |
UTF-8 | UTF-8 (RFC3629) |
HTML 4.01 では charset は文字エンコーディング(character encoding)のことを指す (符号化文字集合としては UCS を使用するとしている)。
値に設定できるのは
で定義されているもの(大文字小文字は区別しない)。
WiKicker には通知メールの Subject: フィールドがたまに壊れている問題があるのだが、ずっと放置しておいたままだった。 そろそろ次のバージョンをリリースしたいと思うので、今回修正しておく。
結果半日かかってしまった。
まず現在エンコーディングに使っている 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 が LF を CRLF にしてくれていたのか。 あまり深い事考えてなかったな。 今回はフォールディングのところだけで CRLF にしたため 一個余分に CR がついてしまい、それがタイトルの文字列中の空白として表示されてしまったと。
結局疑うべきは自分のコード。
仕事のドキュメント書き。 「ドキュメント管理用 Subversionリポジトリ作成」にのっとってやってみる(結局前回考えて以降、時間がとれなくて Subversion に投入していなかった)。
今期、プロジェクトでこの方式を採用しようと思っているのだが Windows ユーザと協同作業しようとすると charset の問題があるな。 とりあえずいわゆるJISにしておけば pTeX としては問題ないと思うが、他の作業環境はどうなのだろう。
DiKicker でのコメント機能についてだがあらためて実装するのも大変なので、たつを氏のくっつき BBSを組み込んでみた (v1.0rc2)。
$HOME/etc/kuttukibbs/kuttukibbs.conf - 設定ファイル (一部変更) $HOME/var/log/kuttukibbslog.txt - 管理者用ログファイル $HTML/kuttukibbs/kuttukibbs.cgi - CGIプログラム (一部変更) $HTML/kuttukibbs/getlog.cgi - (一部変更) $HTML/var/kblog/$ID.log $HTML/var/kblog/$ID.js
記事毎ののHTMLフラグメントを生成する際に、kuttukibbs.cgi へのリンクと、(getlog.cgi経由での)Feedファイルの読み込み部分を埋め込むように変更。
くっつくFeedファイルが無い場合は commentshortクラスの div要素 (tDiary スタイル)が存在しなくなるようにしたかったのでレンダラではこれを埋め込まず、getlog.cgi で出力するようにした。
ついでに getlog.cgi は
した。
Feedファイル用にコメントを切りつめる際、UTF-8 だと後続バイトが切り捨てられる場合がある。 WiKicker に UTF-8 用の substr / length ラッパがあるのでこれを使うように修正。
tDiary では日単位でのコメントでありテーマもそれにあわせてデザインされている。 DiKicker では記事単位にコメントをつけるようにしたいので(またそうでないと記事単位で集約した場合に困るので)、使っているテーマ(Nana さんの flower をベースにしているもの)のCSSを修正。
テストした範囲ではうまくいっているようだ。 HTMLレンダリング済みの記事はキャッシュが更新されないとコメントするためのリンクが現れないが順次出てくるはず。
くっつきとして見るには要 JavaScript サポート。
Windows 上での TeX 書きユーザと仲良くするために。
svn propset svn:eol-style native report.tex
~/.subversion/config で
[miscellany] enable-auto-propcs =yes [auto-props] *.tex = svn:eol-style=native
デフォルトで作成される config ではセクション名もコメントアウトされている事に注意。 個人の設定ではなくて、リポジトリとして設定することはできないのかな。
WiKicker の Windows 上での動作確認の続き。 WiKicker のPPM パッケージを作成して ActivePerl 5.8.6.811 上にインストール。 依存するモジュールで、ActivePerl に入っていないものは以下の通り。
既に手元で PPM パッケージ化済みなので、これもインストールしておく。
後は RCS をパスの通っているディレクトリに入れてタイムゾーンを設定。
TZ=JST-9
で CGI プログラムとして実行。 お、表示できた。 書き込みはと。
エラー。
予想していたけれど、sendmail に依存していたところ。 sendmail が見つからない場合はメールの送信をスキップするように修正。
これでうまく動くかなと思ったら、日本語名のページを作るとうまく表示できない問題を発見。
WiKicker では UTF-8 文字列をURIエスケープして WikiPage のURLを生成している。 このURIにアクセスされると WiKicker は、PATH_INFO から WikiName を取り出す。 この文字列がシフト JIS になってしまっている。
Windows がファイル名に使用する charset にあわせて、Apache が変換してしまっているようだ。 調べてみると他の WikiEngine でも同様の問題にあっているという記事が見つかった。
将来の 2.0 系でパッチが取り込まれて修正されるとか、そうでないとか。
現状どうするかなぁ。 WiKicker 側でシフト JIS から UTF-8 に戻すというのもできない事はないけれど、あまりやりたくはないな。 いったんシフト JIS を介しているという時点で、シフト JIS に無い文字の扱いに関する問題をかかえてしまっているし(Apache が)。
対策案:
自分の開発チームでは、 Subversion を用いて pLaTeX2e ドキュメントを共同執筆というスタイルが随分多くなってきた (自分が推進しているわけだが)。
チームメンバのほとんどは Windows 上で TortoiseSVN を使っているのだが、内蔵の差分ビューアを使っていると charset を自動判別してくれないので、いわゆる JIS コードで書いている TeX のソースファイルの扱いがちょっと不便である。
そういえば以前はこの問題の声が聞かれたけれど、最近誰も言わなくなったな。 解決したのか、差分とか見なくなったのか。
数行書き換えて、一つの変更点としてコミットメントログを残せる単位でガシガシコミットしてしまう私と一緒に作業している人は、いつもコミット負けしているはずなのだが。
ということで TortoiseSVN で外部差分ビューアとして使えるツールを調べておこう。 まずは差分表示アプリケーション Rekisa。
日本語のファイルの charset を自動判別してくれるし、表示が美しい。 差分を見るには良さそうである。
マージ作業もあわせてするとすると編集機能が必要だが、Rekisa 自身では直接編集できないようだ(外部エディタを呼び出すことはできる)。
マージまですると WinMerge が本命? こちらはまだ試していないので後日。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。
#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。 それとは別に nNote にもちょっとしたノートがあります。
※内容は個人的見解であり所属組織とは関係ありません。