utf-16の世間の扱いがひどすぎる件

ちょっととある雑誌記者からメールでの取材があったのでメールで返信したのだが、本文中にインラインで返信する場合、どうしても一定文字数ごとに改行を入れなくてはならない。

これを怠ると相手のメーラーが気を利かして勝手に改行を入れてしまいかねない。そうなると変なところで改行されてしまう。かと言ってこちらの文章も行の終わり以外のところでも改行を適宜入れるとなると私の文章をコピペして編集するときに改行を削除する作業が必要になる。

正規表現を理解している編集者なら"\r\n"(改行)を""(空の文字列)に置換するなどして一気にやってしまうんだろうけど、そうでない場合は手作業でやることになって文字を余計に消してしまい脱字してしまったりする。

そこで私はコピペしてそのまま使えるようにメールにインラインで返信するのではなく、この手のインタビューではテキストファイルとして添付して返信することを心がけているのだが、このときテキストファイルのエンコードを何にするのかという問題がある。

私が愛用しているテキストエンコードはもっぱらutf-16なのだがWindows XPのメモ帳はutf-16に対応しておらず(←間違いでした。対応してました。対応してるのですが、開くときにエンコードとして「Unicode」を指定しないとうまく開けず文字化けしました。自動判別らしいのですがその判定精度が低いのが難点で、相手に事前にエンコードを伝えておかないとまずいですね。)、世間ではいまだにshift-jisが主流なのである。秀丸も最新バージョン(8.00)より前のバーションでは、標準のエンコードとしてBOM付きutf-16を選択できなかった。

おまけに秀丸の最新バージョンですらディフォルトではutf-16をエンコードの自動判別のリストのなかに入っていない。秀丸に自動判別させるためには動作環境のメニュー(下図)の左下にある「上級者向け設定」のチェックボックスにチェックを入れて「エンコード1」のところにあるutf-16のチェックボックスにチェックを入れなければならない。

さらに言えば、それでもuft-16の判定の優先順位が低いのでBOMをつけてあっても秀丸は他のエンコードと誤認することが多々ある。ゆえに、utf-16の優先順位を一番上に持ってきて「複数のエンコードの種類に適合する場合」のところ「優先順位に従う」を選ぶ必要がある。

まあ、テキストエディタとして抜群の知名度を持つ秀丸ですらutf-16の扱いはこの程度のものなのでutf-16で書かれたテキストファイルを添付して「文字化けして読めないんですけど」とか電話がかかってくるのも無理はない。

結局、改行する文字を削除するのが面倒だろうと思って私は気を使ってテキストファイルで添付しているのに雑誌編集者に余計に手間をかけさせてしまっているのが私の実情である。

こういう説明を毎回するのが面倒なのでここに書いておき、次からはutf-16でエンコードされたテキストファイルを添付するときはここのリンクを貼り付けることにする。utf-16愛好家(私の他にどれくらい居るのかは知らんが)の方は、相手に説明するのが面倒なとこはこの記事にリンクを相手に紹介すると良いですよっと。

でもいまのところ、相手に渡す前にshift-jisにエンコードしなおして渡すようにしたほうが無難という気が…。