問題タブ [apache-commons-compress]

tar アーカイブから単一のファイルを抽出するアプリケーションを作成しました。アプリケーションは *.tar を適切に読み取りますが、ファイルを抽出しようとすると、アプリケーションは正しいファイル名で新しいファイルを作成するだけです... ファイルは空 (0kb) です。だから...おそらく、抽出する代わりに新しいファイルを作成するだけです...

この時点で全くの初心者です...

Apache Commons Compress ( https://commons.apache.org/proper/commons-compress/ )に代わる圧縮 Java ライブラリを探しています。Commons Compress は、deflate64 である「ENHANCED_DEFLATED」を使用して圧縮された zip エントリを読み取ろうとすると、エラーをスローします。例外をスローするサンプルの抜粋を次に示します。

スタック トレースの関連部分は次のとおりです。

org.apache.commons.compress.archivers.zip.UnsupportedZipFeatureException: サポートされていない機能メソッド 'ENHANCED_DEFLATED' が org.apache.commons.compress.archivers.zip.ZipUtil.checkRequestedFeatures(ZipUtil.java:357) のエントリ test.docx で使用されていますorg.apache.commons.compress.archivers.zip.ZipFile.getInputStream(ZipFile.java:404) at ZippingAround.doRecurseZip(ZippingAround.java:23)

Commons Compress を置き換えることができる、または deflate64 圧縮方法のためにそれと連携して動作する可能性のある別の zip ライブラリを知っている人はいますか?

tar.gzを使用してアーカイブを読んでいます

ArchiveEntry entry = tarArchiveInputStream.getNextEntry();

質問: このArchiveEntryをに変換して、InputStream実際にファイルを に読み込んで処理できるようにするにはどうすればよいStringですか?

tar からファイルを抽出するために、ここの別の投稿の apache commons compress の例を使用していますが、次のように失敗しています:

これは、私が渡している一部の vmware ova ファイル (これは tar ファイルです) でのみ発生しますが、すべての ova ファイルでは発生しません。他の人は正常に動作します。

コードは次のとおりです。

問題は、destFile の値を設定しようとする時点で tarEntry.getName() に導入されたようです。デバッガーでそれをステップ実行すると、destPath は余分な表示できない文字と、パス内の「someone」という単語を取得しています。

正常に untar できる ova ファイルの場合、desPath の値は正常に見えます。

hexdump -C で表示すると、両方の tar (ova) ファイル ヘッダーにこのテキストが表示されるため、「someone」テキストは適切な手がかりになります。ただし、それらは同じ場所にありません。

ここでの解決策は、ファイル名が保存されているオフセットを特定し、その特定のオフセットから読み取ることに関係していると思います。それは私の最善の推測ですが、16進数を読むのはあまり得意ではありません。

私の目標は ova 内の ovf xml ファイルを読み取ることであり、ova の作成を制御していないことに注意することが重要です...そのため、事前にヘッダーの問題を修正することはできません。ova ファイル自体は完全に機能しており、tar -xvf test.ova を使用してコマンド ラインから正常に解凍することもできます。実際、コマンド ラインから tar ファイルを再パッケージ化すると、上記のコードが機能します。

オラクルがウェブサイトでZIP/GZIP ファイルの圧縮/圧縮解除方法について言及していることは承知しています。しかし、ネストされた ZIP/RAR が含まれているかどうかをスキャンして確認する必要があるシナリオがあります。たとえば、次の場合です。

apache commons compress パッケージと java.util.zip は広く使用されているパッケージであり、commons compress が実際に java.util.zip に欠けている機能 (zipout を実行する際の文字設定など) に対応していることを私は知っています。しかし、私が確信していないのは、ネストされたzipファイルを再帰するためのユーティリティであり、SOで提供されている回答はこれを行う良い例ではありません. 次のコード (Oracle ブログから取得したもの) を試しましたが、ファイルが見つからないため、ネストされたディレクトリの再帰が失敗するのではないかと疑っていました。

何か間違ったことをしている、または間違ったユーティリティを使用している可能性があります。私の目的は、ファイルまたはネストされた zip ファイルのいずれかに、許可していないファイル拡張子が付いているかどうかを特定することです。これは、ユーザーが禁止されているファイルを圧縮している場合でもアップロードできないようにするためです。再帰的な解析を実行できる Tika を使用するオプションもありますが (Zukka Zitting のソリューションを使用)、メタデータを使用してこの検出を希望どおりに実行できるかどうかはわかりません。

どんな助け/提案も大歓迎です。

Apache Commons Compress を使用して、7zip アーカイブのエントリを解析しています。特定のファイル (「thisfile.xml」など) を検索できるようにする必要があります。アーカイブ内のすべてのエントリをループする以外に、より良い方法があるかどうか疑問に思っていました。

私が現在行っていることの種類は次のとおりです。

多くのエントリが存在する可能性があるため、アーカイブ内のすべてのエントリを特に反復処理したくはありません。

どんなアイデアでも大歓迎です