ディレクトリに繰り返しファイルを圧縮しました。しかし、最後のいくつかのzipファイルが圧縮されていないことがわかりました。
adding: 1.3.12.2.1107.5.1.4.64517.30000014091005511462300042406.dcm (deflated 0%)
adding: 1.3.12.2.1107.5.1.4.64517.30000014091005511462300042279.dcm (deflated 0%)
adding: 1.3.12.2.1107.5.1.4.64517.30000014091005511462300042466.dcm (deflated 0%)
adding: 1.3.12.2.1107.5.1.4.64517.30000014091005511462300042200.dcm (deflated 0%)
adding: 1.3.12.2.1107.5.1.4.64517.30000014091005511462300042227.dcm (deflated 0%)
adding: 1.3.12.2.1107.5.1.4.64517.30000014091005511462300042372.dcm (deflated 0%)
adding: 1.3.12.2.1107.5.1.4.64517.30000014091005511462300042245.dcm (deflated 0%)
adding: 1.3.12.2.1107.5.1.4.64517.30000014091005511462300042282.dcm (deflated 0%)
zipを使用するときになぜこれが起こるのかを説明できる人はいますか？
答え1
のようにコメントだから質問この内容はほぼ扱っています。今、私はこのデフレが実際にどのように機能するかを試してみたいと思います。だから、次のテストをしてみました。
エントロピーとは何ですか？
エントロピー情報フローの予測不可能性を測定することです。完全に一貫したビットストリーム（すべて0またはすべて1）は完全に予測可能です（エントロピーなし）。完全に予測できないビットストリームは最大エントロピーを持ちます。情報エントロピーの概念は、それを表現する式を提示したClaude Shannonによるものです。
yこれで以下のようなファイルが作成されましたn。
perl -e 'my $y; $y .= int(rand(100))>90 ? "y" : "n" for (0..999); print $y;' > f1
これでコマンドを実行すると、次zip f1.zip f1の結果が表示されます。
zip f1.zip f1
adding: f1 (deflated 89%)
上記のコマンドには予測可能なバイトがあるため、y減少率nは89です。
現在、私は次のような実験を行っています。
dd if=/dev/urandom of=./f2 bs=1M count=1
コマンドを実行すると、zip f2.zip f2これが私が得る出力です。
zip f2.zip f2
adding: f2 (deflated 0%)
これは/dev/urandom完全に予測できないため、デフレ率は0％です。以下に提供される参照リンクには、予測可能なバイトのエントロピーを計算する方法の良い説明があります。
entさらに、Debianベースのシステムでファイルのエントロピーを計算するためのツールがあります。 1つを作成してapt get install entエントロピー比を計算しent filename、正確に何が起こっているのかを調べることができます。
あなたは読むことができますこここのコマンドについて。
引用する