No. 220/622 Index Prev Next
Path: titcca!ccut!ascgw!flab!ichikawa
From: ichikawa@flab.flab.fujitsu.JUNET (I.Ichikawa)
Newsgroups: fj.kanji
Subject: SPEC of new-nkf part 1
Message-ID: < 2432@flab.flab.fujitsu.JUNET> 
Date: 24 Dec 87 09:48:50 GMT
Reply-To: ichikawa@flab.flab.fujitsu.JUNET (I.Ichikawa)
Distribution: fj
Organization: Fujitsu Laboratories Ltd., Kawasaki, Japan
Lines: 78
Posted: Thu Dec 24 18:48:50 1987

例によって、公開で決めてしまおうという、新版NKFの仕様です。

カナの処理について、色々な御意見ありがとうございました。
この場をもちまして、御礼申し上げます。

まず、カナ処理をするのは、入力コード系を指定した場合とします。
そうでないと理論的にも統計的にも、はっきりいってむりです。よほどの
判定のための知識を用意しないとむりです。

ということで、まずは、入力コード系の指定では、
1)ユーザが指定する、2)自動確定させる、ということをオプションで指定します。

カナ処理は、
1)行う、2)スルー、の2つを用意します。ただし、いわゆる半角カナなどの、あ
まり好ましくないコードやはっきりいってまちがいのコードがあった場合にはワ
ーニングをstderrに出すということにしますし、処理をする場合にはカナ記号と
カナは特に区別しません。

そして、ワーニングも、1)サイレント(なし)、2)ノーマル(デフォルトで、あっ
たということだけをいう)、3)バーバス(何がどのへんにあったとわめく)を、オ
プションで切り換えていこうと思っています。

ここまでは、決めました。

さて、次の問題です。
(A)
^[ + $ + ...  や ^[ + ( + ... について、今のnkfは常に律義に見ていますが、
^[ + $ + ... または ^[ + ( + ... が来た時には、入力はJISであると確定して
もよろしいでしょうか?

いいかえると、現在、入力コード系の確定は、シフトJISとEUCの間でのみ行って
いますが、これにJISを加えてもいいでしょうか?

(B)
コード系の確定をキャンセルするような文字列(簡単なのがいい)を用意しましょ
うか?

つまり、入力ストリームに、ある文字列が出現すると、コード系確定のキャンセ
ルにして、次の入力からもういちど判定しなおす、というふうにしたいのです。、

こうすると、ある意味において便利になるのですが、判定する文字列(なるべく
なら、文字列でなく、ある文字にしたいのですが)の検出のオーバーヘッドがあ
って、うれしくないですね。

でも、必ずEOFや、コードの範囲をみていますから、それほどオーバーヘッドを
感じないように設定することは可能だとは思っています。しかし、それも、せい
ぜい2文字ぐらいです。それを越えてしまうと、きついように思えます。

例えば、" \nF" なんかはいかがでしょう。行先頭のFは、Fromなどになっていいと
思うのですが....


以上2点について、御意見をおよせ下さい。
なお、なるべくならば、引用は少なめにして、以下の解答欄を御利用していただ
きたいと思います。
---(い)
PS:仕様は勝手に決めたら、という意見も来そうだなぁ。

PPS:シフトJIS JISで、hi-byte, lo-byteについて、
	((hi-byte  << 8) | lo-byte) &  0x1ff
とか
	((hi-byte > 7)) & 0x1ff
を使うと、御利益があるように思いません?

-------------解答欄----------
(A)JISの確定処理をしても(いい/よくない/どっちゃでもいい/その他)
			
   その理由:


(B)確定キャンセル文字列をサポートは(いる/いらん/どっちゃでもいい/その他)
				  
   その候補の文字列:
   その理由:



(その他)カナの処理について、私はこう思う:
Next
Continue < 882@cskvax.csk.JUNET>