You are not logged in. This forum allows only logged in users to post. If you want to post in the forum, please log in.
下载
开发软件
账户
下载
开发软件
登录
我忘记用户名和密码了
创建帐户
语言
帮助
语言
帮助
×
登录
登录名
密码
×
我忘记用户名和密码了
简体中文翻译状态
类别:
软件
用户
PersonalForge
Magazine
Wiki
搜索
OSDN
>
浏览软件
>
Text Editors
>
Text Processing
>
skf - simple kanji filter
>
论坛
>
公开讨论
>
segmentation fault他
skf - simple kanji filter
描述
项目概述
开发人员仪表板
项目的网页
开发人员
Image Gallery
List of RSS Feeds
Activity
统计
历史
下载
List of Releases
统计
源代码
Code Repository list
CVS
查看仓库
任务单
Ticket List
里程碑列表
Type List
组件列表
List of frequently used tickets/RSS
Submit New Ticket
文档
沟通
List of Forums
帮助论坛 (3)
公开讨论 (12)
新闻
论坛:
公开讨论
(Thread #8028)
Return to Thread list
RSS
segmentation fault他 (2005-06-28 22:37 by
naruse
#15030)
Create ticket
こんにちは、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)
Create ticket
こんにちは。
すぐ答えられるところだけ、まず。
(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)
Create ticket
(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)
Create ticket
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