NKF(1)

NAME
nkf - ネットワーク用漢字コード変換フィルタ v1.7

SYNOPSIS
nkf [options] [file]

DESCRIPTION
nkfはネットワークでメールやニュースの読み書きをするために作られた、漢 字コードの変換フィルタである。

このnkfの特徴としては、入力漢字コード系の統計的な自動認識機能がある。 このため、利用者は、入力漢字コード系が何であるかを知らなくても、出力漢字 コード系のみ指定すれば良いことになる。ただ、この判定機構は、理論的には完 全ではないが、通常のニュースやメールのメッセージについては確実に動作する 安全なものにはなっている。

現在、nkfが認識できる入力の漢字コード系は、いわゆる「JISコード」(ISO- 2022-JPに基づくもの)、MS漢字コード(シフトJIS)、日本語EUC(AT&Tコード)のい ずれかである。出力する漢字コード系も、この3種類である。

入力は、ファイルを指定しなければ、標準入力となる。出力は標準出力である。

指定できるオプションは、以下の通り。-mu のように続けることができる。

-b  バッファリング出力を行う。(デフォルト)

-u  出力時に、バッファリングしない。 rsh localhost | nkf -u というように使う。

-t  何もしない。

-j  JISコードを出力する。(デフォルト)

-e  EUCコードを出力する。

-s  シフトJISコードを出力する。

-i? JIS漢字を指示するシーケンスとして ESC-'$'-?を使用する。 (デフォルトは、ESC-'$'-'B')

-o? 1バイト英数文字セットを指示するシーケンスとして、ESC-'('-?を使用す る。 (デフォルトは、ESC-'('-'B')

-r  ROT13/47の変換をする。

-v  バージョンを表示する。

-T  テキストモードで出力する。(MS-DOS上でのみ効力を持つ)

-m[QB0]
    MIME を解読する。(デフォルト) ISO-2022-JP(base64)とISO-8859-1(Q encode) のみを解読する。ISO-8859-1 (Latin-1) を解読する時は、 -lフラグも必要である。-m0 ではMIMEを解読しない。-mQ, -mBでは、 Q encode, B encode されているものとして処理する。

-l  0x80-0xfeのコードをISO-8859-1 (Latin-1)として扱う。 JISコードアウトプットとの組合せみのみ有効。 -s, -e, -xとは両立しない。

-f? 一行?文字になるように簡単な整形をおこなう。デフォルトは 60文字である。

-Z  X0208中の英数字と若干の記号をASCIIに変換する。-Z1 はX0208間隔をASCII spaceに変換する。-Z2はX0208間隔をASCII space 二つに変換する。趣味によって 使い分けてほしい。

-J -E -S -X -B
    期待される入力コードの性質を指定する。

    -J  ISO-2022-JPを仮定する。

    -E  日本語EUC(AT&T)を仮定する。

    -S  MS漢字を仮定する。X0201仮名も仮定される。

    -X  MS漢字中にX0201仮名があると仮定する。

    -B  壊れた(Broken)JISコード。ESCがなくなったと仮定する。

        -B1
             ESC-(, ESC-$ のあとのコードを問わない

        -B2 改行のあとに強制的にASCIIの戻す

-x  通常おこなわれるX0201仮名->X0208の仮名変換をしないで、
     X0201仮名を保存する。入力は、MS-Kanjiの1byte仮名、SO/SI、 ESC-(-I, SSOを受け付ける。出力は、日本語EUC中ではSSO、 JISでは ESC-'('-I を使う。

-O  ファイルに出力する。Unixでは不要な機能だがWindowsやMSDOSでは 必要らしい。直後の引き数でなく、最後のファイル名が出力ファイ ル名となり上書きされてしまうので注意。ファイル名がない場合は、 適当に決められる(nkf.outなど)。

-c  NLあとにCRを付加する。

-d  NLあとのCRを削除する。

AUTHOR
市川  至    ichikawa@flab.fujitsu.co.jp    (was ichikawa@fujitsu.JUNET)

ACKNOWLEDGE
morb@fujitsu, kiss@ayumi.stars.flab.fujitsu, cen122@flab.fujitsu, yuki@flab.fujitsu 他、fujitsu & flab.fujitsuの皆さんの協力に感謝。 shinoda@cs.titech, kato@cs.titech, uematsu@cs.titech TNX kono@ie.u-ryukyu.ac.jp

BUGS
実は、入力のコード系の判定は、EUCとシフトJISとの自動判定であり、最初に 特定できる文字が来た時点で確定してしまう。そして、特定不能の間は保留バッ ファにためておかれ、確定後に処理される。このため、

1)  7ビットJISは常に認識される。シフトJIS、EUC混合もほとんどの 場合は問題がない。ただし、

2)  シフトJISのX0201仮名とEUCが識別できない。したがって、 デフォルトではシフトJISのX0201仮名はないと仮定している。

3)  ちょっと、のろい。(初期の版よりは改良されている)

JIS漢字の新旧版の区別とか、ASCIIとJISローマ字の区別などについては保存さ れない。

このフィルタの変換は、コード系に対応した一括写像を施すだけなので、外字 や特殊記号や罫線素片など、JIS第一、第二水準表において定義されていないコー ドに各社により割り当てられた文字がどうなるかまでは関知しない。そして、第 二水準がないとかあるとかによる問題は、このフィルタの範囲外と思える。それ らは、書き手の責任でなんとかしてもらいたい。

いずれにせよ、通常のニュースの記事については問題はなく変換できるはずで ある。(と思うのだが、今ひとつ自信はない)

kono@csl.sony.co.jp (Shinji Kono) による変更。
nkf 1.4 の冗長だけど昔は便利だったオプションのいくつかは削除されている。 - -n -Bなど。

X0201仮名はデフォルトでX0208に変換される。ただし、シフトJISのX0201仮名 はデフォルトではEUCだと解釈されてしまう。これが望ましくない時には -S や - -X などのフラグを使えば良い。-Xを指定すると一旦確定したシフトJISから EUCに移行することはない。ESC-(-Iによる X0201は常に認識される。SI/SO SSOは、-lが指定されていなければX0201と解釈する。

MIME decodeは、ISO-2022-JPのbase64と、ISO-8859-1の16進encodeのみ decodeする。 MIME decodeは、単純な改行や空白は安全に読み飛ばされる。 ということは、 MIME decode中の空白は保存されない。lessやrnで行が分割 された時は、 Terminalによって異なる ESC-[-K などが挿入されるので、 完全にはdecode できない。ISO-8859-1 出力はJIS コード出力としか両立しない。

Fold 機能はfmtと異なり行頭の空白を無視する。禁則処理はあるが指定された 長さ+5で強制改行する。

X0201仮名はrot47されない。

nkf 1.6 kono@ie.u-ryukyu.ac.jp (Shinji Kono) による変更。
MIME のチェックをきびしくして(遅くなった分)安全になった。 したがって複数行にまたがるMIMEはdecodeされない。 MIME の直後の空白は読み飛ばす。Q-Encding の_は空白に変換される。
 -B のlevelを0,1,2 に増やした。MIMEのbase64, Q-Encodingを解読する 機能を付けた。ヘッダなどは解読しないので、Encodeされた部分だけを 通す必要がある。 -mB は、nkf1.5と違う動きをするので、-B -m とすること。

nkf 1.6.1
-Z で〜 -> ~の変換を止めた。 -Z1 でX0208間隔->ASCII spaceの変換をおこなう。 -Z2 でX0208間隔->ASCII space 2個の変換をおこなう。

kabe@dais.is.tohoku.ac.jp (Taketo Kabe) による日本語roff のソースが できました。

nkf 1.7

ESC-$-(-B などにも対応するようにしました。

MIMEのチェックが厳しすぎるように思うので、STRICT_MIME をdefine した時にのみに厳しいチェックを行う用にしました。

nkf は、本来、network 上に出して安全なコードをデフォルトで出力すべき であるので、デフォルトの出力コードをShift JIS, EUC などにするのは 望ましくないでしょう。

他の人と少し話して、copy right の非営利の条件を緩めました。

Perl Extension として使えるようになりました。