我有一个加密的 ODT（开放文档文本）文件，我需要将其解压缩。 ODT 是一个 ZIP 文件。加密的 ODT 是一个普通的 ZIP 文件，只是 ZIP 中的一些文件被加密。
使用 ZipFile 在测试中工作正常，但我实际上无法使用 ZipFile，因为内存中有一个流，我不想使用文件。
因此我使用ZipInputStream。但是使用 ZipInputStream.getNextEntry() 会引发可怕的情况
只有 DEFLATED 条目可以有 EXT 描述符
例外。
据我所知，它会抛出 ZIP 包内的第一个加密文件，例如 content.xml。由于 OpenOffice 已加密 xml 文件，因此压缩它可能没有意义，并且它以未压缩的方式存储在 ZIP 包中。
但 ZipInputStream 似乎有问题，我没有找到解决方法。
是的，加密的 ODT 文件是由 OpenOffice Writer 3.2.1 创建的。是的，普通的 ZipInputStream 甚至无法枚举其中的条目。
你有什么建议吗？
I have an encrypted ODT (Open Document Text) file and I need to unzip it. ODT is a ZIP file. An encrypted ODT is a normal ZIP file, just some files inside the ZIP are encrypted.
Using ZipFile works okay in a test, but I cannot use ZipFile really because I have a stream in memory, I don't want to work with a file.
Therefore I use ZipInputStream. But using ZipInputStream.getNextEntry() throws the dreadful
only DEFLATED entries can have EXT descriptor
exception.
From what I can understand, it throws on the first encrypted file inside the ZIP package, for example on content.xml. Because OpenOffice has encrypted the xml file, it was probably no point compressing it and it was stored inside the ZIP package uncompressed.
But ZipInputStream seems to have a problem with it and I don't see a way around.
And yes, the encrypted ODT file was created by OpenOffice Writer 3.2.1. And yes, the stock ZipInputStream cannot even enumerate through entries in it.
Anything you can suggest?
发布评论
评论（3）
该问题与加密无关，而是与以下事实有关：当关联数据未 DEFLATED（即按原样存储未压缩）时，ZipInputStream 不期望（并且不知道如何处理）EXT 描述符。这很可能是 ZipInputStream 中的一个缺陷（“bug”），但我对 zip 规范不够熟悉，无法了解这种或那种方式。
一个不优雅甚至丑陋的解决方法是将流保存到临时文件，然后将其作为 ZipFile 进行处理。
（我是ODFind和上面提到的“解密ODF文件”文档的作者。）
The problem has nothing to do with encryption, but with the fact that ZipInputStream does not expect (and does not know how to handle) an EXT descriptor when the associated data was not DEFLATED (i.e. was stored uncompressed, as-is). This may well be a deficiency ("bug") in ZipInputStream, but I am not familiar enough with the zip specs to know one way or another.
An inelegant, even downright ugly workaround is to persist the stream to a temporary file, and then process it as a ZipFile.
(I am the author of ODFind and the "Decrypting ODF Files" document mentioned above.)
您可以看看 ODF Toolkit 库是否可以
You can have a look if it's possible with ODF Toolkit library
您是否偶然发现了 Ringlord 在 ODFind 读取加密的 ODF 文件？ 此 ODF 文档（以 HTML 格式查看此处由
Google提供）声称根本无法仅依靠 Java 库来解密 OpenOffice.org 文档。不过，作者解释了如何利用 ODF Manifest、RFC 2989、 JBoss3中的PBKDF2Engine以及作者的一些原创发现。最好的祝愿。
免责声明：尽管上面的每个链接都指向 Ringlord 内容，但我与 Ringlord 没有任何关系。
Have you stumbled upon what Ringlord did in ODFind to read encrypted ODF files? This ODF document (viewable as HTML here courtesy
Google) claims there is simply no way to rely solely on the Java libraries to decrypt OpenOffice.org documents. However, the author explains how one can decrypt thecontent.xmlpayload of an ODF file with knowledge of the ODF Manifest, RFC 2989, the PBKDF2Engine in JBoss3 and some original discovery by the author.Best wishes.
DISCLAIMER: I have no affiliation whatsoever with Ringlord despite every link above points to Ringlord content.