Namazu-devel-ja(旧)

[Tadamasa Teranishi <yw3t-trns@xxxxxxxxxxxxxxx>]

寺西です。

Tadamasa Teranishi wrote:
> 
> >   このパッチ自体はずいぶん前にもらっていたのですが、いまの今までなかを
> > 見ていませんでした。分離しつつ、utf8 の物も別途用意しているのですね。
> 
> パッチの中身を見ずに書くのも何ですが、
> EUC 前提の mknmz に utf8 の物を別途用意していて、うまくいくような
> 仕組みが仕掛けられているのですか?
> 
> .pl では、EUC文字を埋め込んでいるだけでなく、各所で EUC 前提に
> プログラムが書かれているはずですが...。
> 
> # やっぱり namazu-2.0.12-fixinutf8.patch を見ないとダメですね。
> # 目を通します。

やっとパッチの中身を見ることができました。
仕組みは VC++ の String Table のようなものと理解しました。

VC++(MFC) では、外部ファイルのリソースにある文字列を、
文字列リソースIDを指定して、CString にロード
する LoadString() がありますので、対応づけると

  ・リソースファイル -> langspec.txt, langspec.txt.utf8
　・文字列ID -> $func
  ・LoadString -> util::read_langspec_char_from_file() 

こんな感じになりますかね。
この仕組み自体は、ごく自然なものですので、この方式で実装するのは
基本的には良いかと思います。

ただ、そのまま組み込むのはちょっとまずいので、多少手を加えた
方が良いかとは思います。
=====================================================================
util::read_langspec_char_from_file() 内でファイルを開いているので、
毎回ファイルアクセスが必要になります。
最初に一回読み込んで、取り出す方式に変えた方が効率的でしょう。
=====================================================================
util::read_langspec_char_from_file() 内で I18N::Langinfo を使って
います。
Perl 5.8.3 には入っていますが、Perl 5.6.1 には入っていないようなので
インストールの必要があります。
(require 5.000; なので、インストールさえすれば使える!?)
=====================================================================
で、ここからが問題なのですが、心配した通り、
langinfo (CODESET ()); の結果によって読み出すファイルを切り替えて
います。
UTF-8 なら langspec.txt.utf8,  それ以外なら langspec.txt。
そして、それらのファイルを読み出して、そのまま返しています。

これは問題です。

というのも mknmz の内部コードは eucJP 固定です。UTF-8 を返されても
正しく動作しません。
少なくとも現在の mknmz では eucJP で返されなくてはなりません。
(単純に素の namazu-2.0.12 のソースを UTF-8 に変換するとうまく
動かないことが確認できるでしょう。)
# eucJP 前提で文字列の処理をするようんい書かれていますから。

あるいは、内部コードを eucJP と UTF-8 のどちらかに切り替える機能
を付けるかです。しかし、それは面倒なので、eucJP から UTF-8 に変更
することはあっても、両方切り替えできるようにする必要はないでしょう。
そうすると、util::read_langspec_char_from_file() で、読み出すファイル
を切り替える機能は不要です。langspec.txt は、内部コードと同じeucJP
か UTF-8 であれば良いのです。

(ただし、mailnews.pl_mailnews_citation_filter_1　にいたっては、
eucJP を仮定したコードの判定部分が含まれますので、漢字部分を単純に
UTF-8 に変換してもダメです。)

当面は eucJP ファイルだけで良いでしょう。
将来、内部コードが UTF-8 になったならば、langspec.txt も UTF-8 に
すればよいかと思います。

ここまでは日本語を処理する場合の話です。日本語以外にも対応するの
ならば、内部コードが UTF-8 になった後、langspec.txt に日本語以外も
突っ込むか、あるいは langspec.xx で分けるかです。

先のメールでは、突っ込むのはまずいと書きましたが、単純に翻訳して
langspec.xx を用意すれば良いというわけでもないので、むしろ、
突っ込んだ方が良いのかもしれませんね。
(何でも日本語と同列に同じ処理ができるわけではないので、
言語にとわず共通の処理でできるラベルは、様々な言語を加えて記述し、
ある言語依存の処理に使うラベルは、その言語のみで記述すると
いったことになるのかもしれません。)

しかし、突っ込んでしまったら、UTF-8 対応のエディタで開かないと
壊しちゃいますね。(メンテしにくいかな。)
-- 
=====================================================================
寺西 忠勝(TADAMASA TERANISHI)  yw3t-trns@xxxxxxxxxxxxxxx
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E