KAKASI の補助漢字 ― 2007年11月04日 15時32分49秒
EUC-JP で 0x8f は補助漢字の1バイト目。KAKASI は3バイト漢字に対応していないため、1バイト目を削除して動くようです。 NKFでは(デフォルトでは)3バイトとも削除します。
$ echo -n -e "\x8f\xd4\xda" | kakasi -ieuc -oeuc| od -tx1 0000000 d4 da $ echo -n -e "\x8f\xd4\xda" | nkf -Ee | od -tx1 0000000
本来正しい動作ではありませんが、補助漢字をサポートしていない仕様なので文字化けは仕方がないところです。 異常終了しないようになっているだけマシということですね。
補足) これは man KAKASI の EUC のところを見ると説明がありました。
EUC: GL -- G0 -- ASCII G1 -- JISx0201のかたかな G2 -- JISx0201のかたかな GR -- G3 -- JISx0208 の文字
この説明にはいささか疑問を持つところもありますが、G3 に JISX0208 を割り当てることになっているので、KAKASI の仕様ということでしょう。 昔の商用 UNIX では補助漢字に対応していなかったので、この仕様は十分に意味がある(あった)と思います。
なお、実際は
EUC: GL -- G0 -- ASCII GR -- G1 -- JIS X 0208 の文字 G2 -- JIS X 0201のかたかな G3 -- JIS X 0208 の文字 (本来は JIS X 0212 補助漢字)
となっているはずです。
訂正) と思いましたが、man のままで何故かデフォルトで GR に G3 が割り当てられているという変則でした。 そういえば、G4 まで用意していたり、SJIS を同様に扱っていたりとかなりの変則をやっているので??? なところは他にも多々あります。
utf8_to_eucjp のコード変換ツールによる処理の違いを修正 ― 2007年11月16日 19時11分23秒
filter/{msword.pl, excel.pl, powerpoint.pl} のそれぞれで使用している utf8_to_eucjp で、コード変換ツールの違いによって処理が異なる部分があったので、これを修正しました。(stable-2-0, development-2-1)
具体的には Perl 5.8 の場合と NKF 2.04 以降の場合に改行コードの変換と制御コードの削除が行われていませんでした。
ただし、これらの処理はこれらのフィルタではまず必要ないので実害はないでしょう。
HEAD に関しては処理が違うので、修正していません。
normalize_jp_document の追加他 ― 2007年11月17日 02時30分33秒
- HEAD の pl/codeconv.pl に normalize_jp_document を追加しました。これは stable-2-0 の normalize_eucjp_document に相当します。
- HEAD の doccat の出力コードが EUC-JP のままであったので、これを UTF-8 に変更しました。
- normalize_eucjp (あるいは normalize_jp) を通っていない処理があったので、これを修正しました。
OLE オブジェクトの誤認を回避するための修正 ― 2007年11月18日 19時43分02秒
OLE オブジェクトは、File-MMagic では 'application/msword' と判定され、全て Word とみなされます。 Excel, PowerPoint, Visio 等、種類を判定するのは、今のところ拡張子で判定しています。(本来は中身で判定すべき)
この拡張子で判定する部分は各フィルタの add_magic で追加しています。 しかし、対応するメディアタイプのフィルタが有効な場合は良いのですが、無効な場合はその拡張子のファイルは全て Word とみなされています。
例えば、Visio のファイルを mknmz で処理した場合に、olevisio.pl が有効になっていないと、pltests が通りません。
これを回避するために、Word を処理する olemsword.pl と xdoc2txt.pl の add_media に他の種類のメディアタイプを判定するための処理を追加しました。
最近のコメント