OSDN -- 開發和下載開源軟體
繁體中文翻譯狀態 translation status for zh-tw

討論區: 公開討論 (Thread #8028)
Return to Thread list RSS

segmentation fault他 (2005-06-28 22:37 by naruse #15030)

こんにちは、naruseと申します。

skfの動作で気になったところがいくつかありましたので報告します。

まず、--ocについて。
skf --oc= hoge.txt
のように--oc=の後を空白にするとsegmentation faultを起こします。
--oc=euc-jp-x0213-2004などでも落ちるのですが、
なお、--ic=ではこの問題は起きないようです。


次にNetBSDでのコンパイルについて。
./configure && makeすると、

gcc -DDYNAMIC_LOADING -DKEIS_EXTRA_SUPPORT -DOLD_NEC_COMPAT -DKUNIMOTO -DFAST_GETC -DHAVE_GETENV -DHAVE_CONFIG_H -I. -I. -I. -DUSE_UBUF -DROT_SUPPORT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DFOLD_SUPPORT -DTABLEDIR="\"/usr/local/share/skf/lib\"" -c brgtconv.c
make: don't know how to make -lintl. Stop

make: stopped in /home/naruse/src/skf-1.93
などと、途中で停止してしまいます。

生成されたMakefileの338行目の
$(PROGRAM): $(OBJS) $(LIBS) $(INCLUDES)
にある、$(LIBS)を削除したらコンパイルはできました。


また、--ic=cp932ですが、
% nkf -eS cp932.txt
ABCDE12345あいうえおアイウエオ
∥～－￠￡￢ⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩ№℡㈱
% skf --oc=eucjp --ic=cp932 cp932.txt
ABCDE12345{}〓
。〓シミム ｜〓〓〓〓〓〓〓〓〓〓(c)≪±
以上のようになってしまいます。

また、ここで入力にshiftjisを指定しても、
% skf --oc=eucjp --ic=sjis cp932.txt
ABCDE12345あいうえおアイウエオ
∥～－￠￡￢｜IIIIIIIVVVIVIIVIIIIXXNoTEL(株)
と、正規分解？されます。
分解されないようにしたい場合はどうするのでしょうか。


さらに、Unicodeへの変換についてですが、
http://www2d.biglobe.ne.jp/~msyk/charcode/cp932/
にもあるようなeuc-jp-msの導入を提案します。
skf --oc=utf-8 --ic=euc-jp --use-compat --use-ms-compat euc.txt
を
~/bin/skf --oc=utf-8 --ic=euc-jp-ms euc.txt
と、書けるようになる、と。
同様に、CP932についても、
--ic=cp932が --use-compat --use-ms-compatを内包するといいのではないでしょうか。

端的に言えば、この辺はiconv的になるとわかりやすいな、と思うのです。

よろしくおねがいします。

RE: segmentation fault他 (2005-07-04 17:37 by efialtes #15094)

こんにちは。
すぐ答えられるところだけ、まず。
(1) NetBSD の件は autoconf の指定の問題っぽいです。手元のマシンだと libintl は入れてあったので気がついていませんでした。報告ありがとうございます。対処します。
(2) 正規分解されない形で、sjis 出力する機能はつけていません。これは sjis が JIS x0208(1997) のシフト符号化に倒しているため。本来は cp932 で出すべきなのですが、これはまだやっていません。テーブル定義だけの問題なので、何とかしたいと思います。
(3) euc-jp-ms は cp50932 （だったかな）で実装する予定 (コーディングはしたような気もするけど、未テスト）。iconv には codeset の概念無いので、素直には入れにくいところがあります (上記だけなら、テーブルのエントリを一カ所追加するだけなんですけど）。ちょっと考えさせてください。
(4) ほかは見落としなので、なおします。

よろしくお願いします。
回覆: #15030

RE: segmentation fault他 (2005-07-10 14:10 by naruse #15193)

(1),(2)は了解です、よろしくおねがいします。

(3)について、iconvを出したのは--icと--ocの引数文字列についての話で、
引数を厳密なcodesetでなく、若干ルーズな意味でもとると便利だねって意味です。
例えばeuc-jp-msやUTF-8-MACなどですね。

なおCP51932を指定させるよりもEUC-JP-MSを指定させる方が一般的な気はします。
Googleにて以下のとおりですし。
* EUC-JP-MS の検索結果 約 4,270 件
* CP51932 の検索結果 約 150 件
もっとも、aliasが張ってあればいい話なので強くは主張しません。


ところで、codesetの概念がないので、というのはGNU libiconvはUCS正規化を使っている、という話でしょうか。

“codeset”がUTR#17に言うCCSとCESを併せた概念ならば、
GNU libiconvは確かに文字集合は常にUnicodeなのでCESにあたるencodingという概念しかありません。
http://www.unicode.org/unicode/reports/tr17/
http://www.gnu.org/software/libiconv/
“can convert from any of these encodings to any other, through Unicode conversion”

しかし、Citrus Iconv（NetBSDで採用）はCSI方式なのでcodesetという概念もありますよ。
http://netbsd.gw.com/cgi-bin/man-cgi?iconv++NetBSD-current
http://citrus.bsdclub.org/
http://citrus.bsdclub.org/doc/


ついでに要望を。
正規分解に対応しているということは、NFCにも対応しているのでしょうか。
対応しているのでしたら、UTF-8-MACに対応するのもよいかもしれません。
わたし自身は困っていませんが、対応するとうれしい方もいらっしゃるかと。

UTF-8-MACはUnicodeのNFCと若干異なっていますが、Appleが説明を公開しています。
http://developer.apple.com/ja/qa/qa2001/qa1173.html
回覆: #15030

一部修正、一部は検討中です。 (2005-07-10 15:21 by efialtes #15195)

cp932 の入力が壊れている件、ic/oc のコードサーチに失敗したときの処理がおかしい件は patch 2 で対応しました。cp932 での --use-ms-compat, --use-compat のセットも入れています。正規分解の件は、破断線以外は --oc=sjis-x0213 でできるため、今回はまだ直していません。NetBSD の件も、考え中。

codeset の概念がないという件は、ここでいう CES が CCS を一つ以上含んだものである、という概念がないことを指します。端的に言って、euc-jp が JIS x-0208, 0201, 0212 を組み合わせて作られた euc という CES で表現されたエンコーディングであるという考え方が全くありませんし、指定にもそれが反映しています。Citrus もそこまでは考えていないように思えます (まだコード見てないけど)。skf はすでに入力サイドでは iso-2022 的には好き勝手に CCS を組み合わせられるようになっていますし、出力側もそれを前提とした作りになっています。出力側は現在の実装の都合、というか主に速度の関係ででやっていないだけです。この関係で、iconv っぽくやるのは将来の方向性を含めて検討中、ということにしたいです。
また、個人的には CSI はちょっと、と思います。実装面で文字集合独立にするのはいいと思いますが、euc-jp と JIS の CCS は元々一つですので、別物であるけど同じ CCS であるものとして再正規化するのは変、というか CCS と CES をきっちり切り分けていないと言われても仕方がないと思う。
回覆: #15030