[JM:02584] Re: [POST:DP] bzip2 bzip2.1

Back to archive index
matsuand michio_matsu****@yahoo*****
2021年 7月 3日 (土) 12:29:23 JST


matsuand です。
校正確認、ありがとうございます。
以下、長文ですが返信します。

----- Original Message -----
> From: Akihiro Motoki <amoto****@gmail*****>
> To: Linux JM discussion <linux****@lists*****>
> Cc:
> Date: 2021/6/24, Thu 23:43
> Subject: [JM:02541] Re: [POST:DP] bzip2 bzip2.1
...
>> .SH 名前
>> bzip2, bunzip2 \- ブロックソートによってファイルを圧縮・伸長する。バージョン 1.0.8
>
> manpage の見出しのところに「。」が入っているのはあまり見ませんね。
>   〜を圧縮・伸長する (バージョン 1.0.8)
> のような書き方もあるかもしれません。

ご指摘どおりです。
「〜を圧縮、伸長する (バージョン 1.0.8)」の書き方を採用させて頂きます。

※ 中黒「・」は好まないので、句点に変えます。

---
>> .\"O .SH DESCRIPTION
>> .\"O .I bzip2
>> .\"O compresses files using the Burrows-Wheeler block sorting
>> .\"O text compression algorithm, and Huffman coding.  Compression
> is
>> .\"O generally considerably better than that achieved by more
> conventional
>> .\"O LZ77/LZ78-based compressors, and approaches the performance
> of the PPM
>> .\"O family of statistical compressors.
>> .SH 説明
>> \fIbzip2\fP は、Burrows\-Wheeler ブロックソートテキスト圧縮アルゴリズムと Huffman
> コード化を使ってファイルを圧縮する。
>> 圧縮率は、一般的な LZ77/LZ78 ベースの圧縮率に比べると、大抵の場合でとても良い。 また、圧縮速度は、統計的圧縮法である PPM
>> 圧縮の速度に近づいている。
>
> Huffman coding は「ハフマン符号化」と呼ぶことが多いと思います。
> 最後の方に arithmetic coding も出てきますが、こちらも「算術符号化」と呼ぶことが多いです。

ご指摘そのとおりと思いますが、
「ハフマン符号 /*化*/」ではなく、「ハフマン符号」でよいと思います。

---
> conventional は「一般的」というよりは「従来の」くらいでいかがでしょうか。
> 意訳としては「広く使われている」などもいいかもしれません。

ご指摘どおりです。「従来の」を採用します。


>> .\"O The command-line options are deliberately very similar to
>> .\"O those of
>> .\"O .I GNU gzip,
>> .\"O but they are not identical.
>>
>> コマンドラインオプションは \fIGNU gzip\fP のオプションにわざと似せてあるが、同じではない。
>
> 「わざと」でも意味は通じると思いますが「意図的に」などでもいいかもしれません。

ご指摘どおりです。
「わざと」は、くだけ過ぎで不適切であろうと思います。
「意図的」を採用します。

---
>> .\"O .I bzip2
>> .\"O expects a list of file names to accompany the
>> .\"O command-line flags.  Each file is replaced by a compressed
> version of
>> .\"O itself, with the name "original_name.bz2".
>> .\"O Each compressed file
>> .\"O has the same modification date, permissions, and, when
> possible,
>> .\"O ownership as the corresponding original, so that these
> properties can
>> .\"O be correctly restored at decompression time.  File name
> handling is
>> .\"O naive in the sense that there is no mechanism for preserving
> original
>> .\"O file names, permissions, ownerships or dates in filesystems
> which lack
>> .\"O these concepts, or have serious file name length
> restrictions, such as
>> .\"O MS-DOS.
>>
>> \fIbzip2\fP はコマンドラインのフラグを伴ったファイル名のリストを受け取る。
> 各ファイルは、"original_name.bz2" という名前の
>> 圧縮されたファイルに置き換えられる。 圧縮ファイルの修正日・アクセス権・(設定可能な場合の) 所有者は、 元のファイルと同じになる。
>> これにより、伸長時に属性が正しく復元される。 ファイル名の操作は、 元のファイル名・アクセス権・所有者を保存する仕組みが
> ファイルシステムになかったり、
>> MS\-DOS のように深刻なファイル名の長さ制限があるために、 とても面倒である。
>
> 「元のファイル名・アクセス権・所有者を保存する仕組み」に
> "or dates" に対応する部分が抜けています。

ご指摘どおりです。直します。


---
>> ファイル名が指定されない場合、 \fIbzip2\fP 標準入力を圧縮して標準出力に書き出す。
>
> bzip2 の後ろに「は」が抜けています。

ご指摘どおりです。直します。


---
>>         filename.bz2    は  filename        になる。
>>         filename.bz    は  filename        になる。
>>         filename.tbz2  は  filename.tar    になる。
>>         filename.tbz    は  filename.tar    になる。
>>         anyothername    は  anyothername.out になる。
>
> 「〜の場合は〜(になる)」などはどうでしょうか。
> 圧縮ファイルが伸長後のファイルになるわけではなく、
> あくまで名前の推測ルールを説明しているわけなので。

ご指摘、なんとなくわかります。
私はどちらでも良いと感じるので、ご提案採用方向で。
むしろ私は、各文末の「になる。」の方が気になります。

再訳として以下のようにしようと思います。
「filename.bz2 の場合は  filename」
(文末の「になる。」を省く)


---
>> .\"O ----------------------------------------
>> .\"O
>> .\"O If the file does not end in one of the recognised endings,
>> .\"O .I .bz2,
>> .\"O .I .bz,
>> .\"O .I .tbz2
>> .\"O or
>> .\"O .I .tbz,
>> .\"O .I bzip2
>> .\"O complains that it cannot
>> .\"O guess the name of the original file, and uses the original
> name
>> .\"O with
>> .\"O .I .out
>> .\"O appended.
>>
>> ファイル名が \fI.bz2\fP, \fI.bz\fP, \fI.tbz2\fP,
> \fI.tbz\fP のような認識される拡張子のいずれかで終っていない場合、
>> \fIbzip2\fP は元のファイル名が推測できないという警告を出し、 \fI.out\fP
> を付加した名前を元のファイル名として使う。
>
> 元のファイル名として扱うのではなく、
> 元のファイル名に .out をつけた名前を使う、
> のではないでしょうか。
> 「元のファイル名」というのは圧縮ファイルの名前のことなので、
> 圧縮ファイルの名前として使うのは文脈的におかしいと思います。

ご指摘どおりです。

再訳
~は元のファイル名が推測できないという警告を出し、
元のファイル名に .out をつけた名前を用いる。


---
>> .\"O You can also compress or decompress files to the standard
> output by
>> .\"O giving the \-c flag.  Multiple files may be compressed
> and
>> .\"O decompressed like this.  The resulting outputs are fed
> sequentially to
>> .\"O stdout.  Compression of multiple files
>> .\"O in this manner generates a stream
>> .\"O containing multiple compressed file representations.  Such a
> stream
>> .\"O can be decompressed correctly only by
>> .\"O .I bzip2
>> .\"O version 0.9.0 or
>> .\"O later.  Earlier versions of
>> .\"O .I bzip2
>> .\"O will stop after decompressing
>> .\"O the first file in the stream.
>>
>> \-c フラグを指定することにより、 圧縮・伸長されたファイルを標準出力に書き出すこともできる。
>
> compreses or decompresses は動詞なので、
> 「ファイルを圧縮、伸長した結果を標準出力に書き出す」のように思います。

ご指摘どおりです。
上記記述を採用させて頂きます。


---
>> .\"O Compression is always performed, even if the compressed
>> .\"O file is slightly
>> .\"O larger than the original.  Files of less than about one
> hundred bytes
>> .\"O tend to get larger, since the compression mechanism has a
> constant
>> .\"O overhead in the region of 50 bytes.  Random data (including
> the output
>> .\"O of most file compressors) is coded at about 8.05 bits per
> byte, giving
>> .\"O an expansion of around 0.5%.
>>
>> 圧縮後のファイルが元のファイルより少し大きくなる場合であっても、 圧縮は常に行われる。 100
>> バイトより小さいぐらいのファイルは、圧縮によって大きくなる傾向がある。 なぜなら、この圧縮メカニズムが 定常的に 50
>> バイトのオーバーヘッドを持つためである。 (大部分のファイル圧縮法による出力を含む) ランダムなデータは、 1 バイト当たり約 8.05
>> ビットでコード化され、約 0.5% 大きくなる。
>
> 「50 バイトのオーバーヘッドを常に持つ」などはどうでしょうか?
> 理解できますが、「定常的に」というのは読んだときにピンと来なかったです。

「定常的」は確かに唐突に感じますが、「常に」としたところで、
全体の表現はさほど変わらないと思います。

よくよく見なおしてみて、以下のように訳そうと思います。
再訳
圧縮メカニズムは 50バイト前後の一定のオーバーヘッドを持つからである。


---
> コード化 → 符号化、でしょうか。

どちらでも。符号化でよいです。


---
>> .\"O As a self-check for your protection, 
>> .\"O .I 
>> .\"O bzip2
>> .\"O uses 32-bit CRCs to
>> .\"O make sure that the decompressed version of a file is identical to the
>> .\"O original.  This guards against corruption of the compressed data, and
..
>> データ保護のための自己チェックとして、 \fIbzip2\fP は 32 ビット CRC
>> を破損したファイルを元のファイルと同じにするために使う。
>
> 最初の文はまだ破損したファイルのことは言っていません。
> 伸長後のファイルが元のファイルと同じことを確認するために CRC32 を使っていると言っています。
> 訳としては「bzip2 は 32 ビット CRC を使って、伸長されたファイルが元のファイルと同一であることを保証します。」
> くらいでしょうか。保証するは確認するとかでもいいと思います。

そのとおりです。
修正しますが、本段落全体が、どうもこなれていないため見直します。


---
>> .\"O            This guards against corruption of the compressed data, and
>> .\"O against undetected bugs in
>> .\"O .I bzip2
>> .\"O (hopefully very unlikely).
...
>> これにより、圧縮データの破損とまだ見つかっていない \fIbzip2\fP のバグ (とても少ないことを期待する)
> からデータを保護することができる。
>
> かっこ内ですが、「(めったにないといいが)」くらいのニュアンスだと思います。

ご指摘どおりです。
この訳文は、そもそも表現を読み間違えそうな悪文と思います。

再訳
このチェックにより、圧縮データの破損を防ぐことができる。
また bzip2 に未知のバグ (ないことを望む) があってもデータを守ることができる。

---
>> .\"O Return values: 0 for a normal exit, 1 for environmental
> problems (file
>> .\"O not found, invalid flags, I/O errors, &c), 2 to indicate
> a corrupt
>> .\"O compressed file, 3 for an internal consistency error (eg,
> bug) which
>> .\"O caused
>> .\"O .I bzip2
>> .\"O to panic.
>>
>> 返り値: 正常終了の場合、0 が返される。 実行環境の問題 (ファイルがない・不正なフラグ・ I/O エラーなど) がある場合、1 が返される。
>> 破損した圧縮ファイルの場合、2 が返される。 \fIbzip2\fP にパニックを引き起こす内部整合性エラー (例えば、バグ)
> の場合、3 が返される。
>
> 「例えば、バグ」は「バグなど」くらいでもいいかもしれません。
> 読みやすさだけの話だと思いますが。

同意します。

---
>> .\"O ----------------------------------------
>> .\"O .TP
>> .\"O .B \-f --force
>> .\"O Force overwrite of output files.  Normally,
>> .\"O .I bzip2
>> .\"O will not overwrite
>> .\"O existing output files.  Also forces
>> .\"O .I bzip2
>> .\"O to break hard links
>> .\"O to files, which it otherwise wouldn't do.
>> .TP
>> \fB\-f \-\-force\fP
>> 出力ファイルの上書きをさせる。 通常、 \fIbzip2\fP は既存の出力ファイルを上書きしない。 さらに
> \fIbzip2\fP
>> にファイルへのハードリンクを削除させる。 このオプションが指定されていない場合は、ハードリンクの削除もされない。
>
> 「上書きをさせる」とはあまり言わないように思います。
> 「出力ファイルを上書きする」ではいかがでしょうか。

ご指摘どおりです。ご提案採用します。


---
> break hard links の訳はあまりいい訳が思いつきませんが、
> 正直なところ日本語だけを見たときには意味が分かりませんでした。
> 英語の break を見て初めて理解できました。
...

原文が簡潔なので、訳すと「ぶっきらぼう」になってしまうようです。
説明的ながら、語句を補って、以下のようにしてみようと思います。

再訳
なお bzip2 は、上書きするファイルがハードリンクの場合は、そのリンクを解消する。
オプション指定がなければ、そのようなことは行わない。


---
>> .\"O bzip2 normally declines to decompress files which don't
> have the
>> .\"O correct magic header bytes.  If forced (-f), however, it will
> pass
>> .\"O such files through unmodified.  This is how GNU gzip behaves.
>>
>> 通常 bzip2 は正しいマジックヘッダバイトを持たないファイルを伸長しない。 ただし (\-f)
> で強制すれば、これらのファイルも修正せずに通過させる。
>> これは GNU gzip の動作と同じである。
>
> (-f) で強制 → (-f で) 強制

些末ながら「で」には異議あります。
「で」という助詞は、数多くの意味があり、常々要注意語と認識しています。
ご提案訳は、中途半端に感じられます。
個人的趣向として助詞「で」は、できる限り用いない文章を考えます。

再訳
ただし強制指定 (-f) を行えば、そういったファイルも修正せずに処理する。

---
>> .\"O .TP
>> .\"O .B \-v --verbose
>> .\"O Verbose mode -- show the compression ratio for each file
> processed.
>> .\"O Further \-v's increase the verbosity level, spewing
> out lots of
>> .\"O information which is primarily of interest for diagnostic
> purposes.
>> .TP
>> \fB\-v \-\-verbose\fP
>> 詳細表示モード \-\- 各ファイル処理について圧縮率を表示する。 さらに \-v の数を増やすと、詳細表示のレベルも上がり、
>> 主に診断を目的とする多くの情報を書き出す。
>
> each file processed は「処理した各ファイル」です。
> 「ファイル処理」ではなく「処理されたファイル」なので。

ご指摘どおりです。そのように直します。


---
>> .\"O .TP
>> .\"O .B \--repetitive-fast --repetitive-best
>> .\"O These flags are redundant in versions 0.9.5 and above.  They
> provided
>> .\"O some coarse control over the behaviour of the sorting
> algorithm in
>> .\"O earlier versions, which was sometimes useful.  0.9.5 and
> above have an
>> .\"O improved algorithm which renders these flags irrelevant.
>> .TP
>> \fB\-\-repetitive\-fast
> \-\-repetitive\-best\fP
>> これらのフラグは、バージョン 0.9.5 以降では余計なものである。 これらのフラグは、以前のバージョンでソートアルゴリズムの動作を
>> 大雑把に制御するために提供されたもので、時々は役立ったものである。 0.9.5 以降では、これらのフラグが無関係になる
>> 改良されたアルゴリズムが使われている。
>
> 無関係になる、というのは、フラグが参照されない、ということでしょうか?
> そうであれば「0.9.5 以降では、完了されたアルゴリズムが使われており、
> これらのフラグは意味を持たない」くらいが読みやすいと思います。

原語だけでは解釈困難であったので、ソースも確認しました。
オプション指定してもエラーになるコードとなったようです。
$ bzip2 --repetitive-fast ...
bzip2: --repetitive-fast is redundant in versions 0.9.5 and above

ご提案訳が適切と思います。 ただし s/完了/改良/


---
>> .\"O .I bzip2
>> .\"O usually allocates several megabytes of memory to operate
>> .\"O in, and then charges all over it in a fairly random fashion. 
> This means
>> .\"O that performance, both for compressing and decompressing, is
> largely
>> .\"O determined by the speed at which your machine can service
> cache misses.
>> .\"O Because of this, small changes to the code to reduce the miss
> rate have
>> .\"O been observed to give disproportionately large performance
> improvements.
>> .\"O I imagine
>> .\"O .I bzip2
>> .\"O will perform best on machines with very large caches.
>>
>> \fIbzip2\fP は通常、操作のために数メガバイトのメモリを確保し、 とてもランダムな方法で確保されたメモリを変更する。
>
> all over it のニュアンスが翻訳に反映されていません。
> 「〜方法で確保したメモリ全体を変更する」ということを言っているのだと思います。

そもそも charges の訳を「変更」とすることが誤っていると思います。
邪推すると changes と読み間違えているのかもしれません。
原語の typo ではないと思います。
圧縮伸長の両処理過程において、その時々の1かたまりのデータを保持するのに、
割り当てたメモリ内をランダムに利用する(charge=充填する)、ということと解釈します。

再訳
bzip2 は通常、 数メガバイトのメモリを割り当てて処理を行う。
そしてそのメモリ全体の利用は、かなりランダムな方法で行われる。


---
>> .\"O .SH CAVEATS
>> .\"O I/O error messages are not as helpful as they could be.
>> .\"O .I bzip2
>> .\"O tries hard to detect I/O errors and exit cleanly, but the
> details of
>> .\"O what the problem is sometimes seem rather misleading.
>> .SH 警告
>> I/O エラーのメッセージは、それほど役立たない。 \fIbzip2\fP は、できるだけ I/O
> エラーを検知して正しく終了しようとする。
>
> cleanly なので「正しく」というよりは「きれいに」といったニュアンスだと思います。
> 「きれいに」がいい訳だとは思っていませんが。

「正常に」でよいと思います。

再訳
bzip2 は、I/O エラーをできるだけ検出した上で、正常終了する。

---
>> しかし、何が問題なのかの詳細は、ときどきかなり間違ったものに見える。
>
> misleading なので、誤解を招きやすい、わかりにくい、といったニュアンスだと思います。
> 「〜の詳細は、ときどきかなりわかりにくいこともある」くらいでしょうか。
> いまいちな案ですが。。。

「わかりにくい」よりは「誤解を招く」の方がよいと思います。

再訳
ただし問題が何であったのかという詳細は、ときどき誤解を招く場合がある。



linuxjm-discuss メーリングリストの案内
Back to archive index