バイナリファイル用の高性能なデコーダ
uudeview
は、電子メールや Usenet から受け取ったエンコードされた形式のファイルを
デコードする。標準付属の
uudecode (1)
に似ているが、これよりも快適かつ柔軟である。
uudeview
はエンコーディング方法として
uuencoding, xxencoding, Base64, BinHex
をサポートしており、分割ファイル(複数の部分に分けて送られたもの)を扱う
ことができ、さらに複数のファイルを同時に扱うこともできる。したがって、
デコードの手間を大きく省くことができる。ユーザは普通、デコードの準備を
するためにファイルを手で編集する必要はない。
uudeview
は起動されると、与えられたファイルを全てスキャンしてデコードすべきデー
タを探し、そのデータとデータに含まれるパートをソートし、うまくデコード
できそうなファイルの一覧をユーザに示す。ユーザはこの一覧からデコードす
るファイルを個別に選ぶ。
-i
uudeview
はファイルをデコードするかどうかをユーザに問い合わせず、デコード可能な
ものを即座にバッチ処理でデコードする。
-d
uudeview
を desperate モードにする。このモードでは、不完全なファイルもデコード
の候補となる。この機能が有効なのは 50 個のパートに分かれた投稿の最後の
部分が欠けているような場合であるが、大抵の場合は、無理にデコードしたファ
イルは単に壊れているだけで利用はできないだろう。不完全なファイルがどの
程度使えるかはファイルの種類による。
-f
uudeview
は各入力ファイルに多くとも 1 ファイルしか含まれていないものと想定する。
これは普通、ニューススプール内にあるファイルについては成り立つ。このオ
プションを指定すると、複数の記事に分かれた入力ファイルのデコードは
中断される
。また、データが正しいかどうかのチェックも一部が無効になるので、誤りが
あるファイルもおそらくデコードの候補として示される。デコードの時にエラー
メッセージを受け取ることもあるし、単に不正なファイルができることもある。
このような問題に遭いたくないなら
-f
オプションは使わないこと。
-o
-v
-b1
uudeview
のポリシーを変更する。このオプションが必要となるのは稀であるが、
例えば複数に分割して投稿が行われた時のように、パート番号が 括弧 () や
ブラケット [] 内に書かれている場合だけは必要となる。デフォルトでは、
uudeview
はまず 括弧 () 内にある数字を使う。しかし、この番号が全体のファイル数
を示しており、パート番号はブラケット [] に書かれている場合には、このパ
ラメータを使って
uudeview
に他の数字を最初に読み込ませるようにすること。このオプションは、1 種類
のブラケットしか含まないファイルや、どちらの種類のブラケットも含まない
ファイルの展開には影響を与えない。必要ならば、このオプションは
-b[]
のように使うこともできる。
-s
uudeview
がサブジェクト行の正しい展開に失敗してパート番号の推定時にエラーを出力
し、パートの順番が狂う場合にはこのオプションを試すとよい。このオプショ
ンを使うと、パートは必ず順番通りに繋げられる(したがって、入力ファイル
ではパートを正しい順に並べなければならない)。また、このオプションを使
うと、プログラムは欠けているパートを検出することはできない。
注意:
この場合でも、きちんとした
MIME
ファイルに含まれている正しいパート番号は評価される。このオプションを
2 回指定すると、サブジェクトそのものも無視され、パートのグループ付けに
は使われない。パートを配送する一連のメッセージのサブジェクト行がそれぞ
れ異なる場合には、このオプションを使用すること。
-m
-n
-t
MIME
メッセージに入っているテキストパートやエンコードされていないデータもデ
コード対象として示される。プレーンテキストのメッセージにはファイル名が
付けられていないことが多いので、これらには 4 桁の通し番号を使ったユニー
クな名前が付けられる。
uudeview
に読み込ませる。このファイルでは 1 行に 1 つだけオプションを書かなけ
ればならない。このファイルはプログラムの終了時に
削除される
。この機能を使うとファイルを何個でも指定することができる。
find (1)
の機能と組み合わせれば、ディレクトリツリー全体(ニューススプールのディ
レクトリ等)を処理することができる。
環境変数 $UUDEVIEW にオプションを指定することもできる。この値はコマン
ドラインのオプションを処理する前に読み込まれる。
d
y
x
n
b
i
e
l
r
p
q
?
Begin/End
mailfile.gz
が見つかったことを示す。ファイルは uuencode されており(UUData)、6 つ
のパートからなる。また、begin トークンが最初のパートで見つかり、
end トークンが 6 番目のパートで見つかった。全て揃っているように見え
るので、このファイルには OK のタグが付けられる。
State
には以下に示す各種ビットが設定される。ビットの値は OR されることもあるだろう。
1
2
4
8
16
32
64
ほぼ
」というのは、規約ではファイルが複数のメッセージを含むことは認められて
いないけれど、
uudeview
はこの制限なしで動作するからである。実際には、コマンドラインオプション
-f
を用いて必ずこの状態になるようにすれば、このプログラムは RFC1521 に完
全に準拠する。
(このオプションが設定されていても、正しい MIME マルチパートメッセージ
に含まれるパートは全て処理される。)
スキャンの処理部分は、MIME メッセージの外部にある短い Base64 データ(4
行以下)を無視することがよくある。この状態に対するチェックがいくつか
desperate モードで行われるが、これを行うとエンコードされたデータを誤っ
て検出し、不正なファイルができることがある。
ファイルは最初は必ず一時ファイルにデコードされ、その後に最終的な場所に
コピーされる。これは、後になってからデコードできないことが分かるような
データで既存のファイルを誤って上書きすることを防ぐためである。したがっ
て、必要なサイズの 2 倍の空きスペースを予め確保すること。また、標準入
力から読み込みを行う時には、全てのデータは一時ファイルに書き込まれ、そ
の後にこのファイルに対して通常のスキャン処理が始められる。
Subject 行があれば、
uudeview
は必要な情報全てをこの行から取り出そうとする。Subject 行にゴミが入っ
ている場合や、プログラムがユニークな識別情報とパート番号を Subject 行
から見つけられなかった場合でも、
uudeview
は別のヒューリスティクスを用いてファイルをデコードすることができるが、
この場合の結果は運任せである。
ただし、これが関係あるのはファイルが分割されている場合だけである。エン
コードされたファイルが全て 1 つのパートだけからなる場合には何も心配す
る必要はない。
このプログラムの名前を変えたり、コピーしたり、リンクをすることによって
uudecode
にした場合、このプログラムは標準の
uudecode
の高性能な代用プログラムとして動作し、同じコマンドラインオプションを受
け付ける。ただし、テストはまだ十分でない。
uudeview
のホームページ:
http://www.uni-frankfurt.de/~fp/uudeview/
fp@informatik.uni-frankfurt.de
宛に送ること。
現在は
BinHex
データに入っているチェックサムは無視される。
このプログラムは、分割されたマルチパートメッセージ(複数のメールに分割
された MIME 形式のマルチパートメッセージ)を完全に処理することができな
い。各パートが識別されて 1 つにまとめられ、これに含まれているマルチパー
トメッセージがプレーンテキストファイルに「デコード」されるが、このファ
イルを再び
uudeview
に入力しなければならない。しかし、このようなメッセージは滅多にないので
心配する必要はない。