Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Microsoft Office can not read generated ZIP containing ODS #59

Closed
prigaux opened this issue Apr 2, 2023 · 2 comments
Closed

[BUG] Microsoft Office can not read generated ZIP containing ODS #59

prigaux opened this issue Apr 2, 2023 · 2 comments
Labels
enhancement New feature or request platform bug Hopefully they'll fix it

Comments

@prigaux
Copy link

prigaux commented Apr 2, 2023

Describe the bug

ODS generated with client-zip is invalid in Microsoft Office

To Reproduce
Steps to reproduce the behavior:

  1. Go to https://sheetjs.com/demo/table
  2. Click on 'Export to ODS'
  3. The generated ODS is a ZIP which works in Microsoft Office
  4. If you generate the same ZIP with client-zip, Microsoft Office rejects it

Investigations
Comparing various ODS that Microsoft Office accepts, Microsoft Office requires a ZIP "version needed to extract" 2.0 instead of 4.5

Possible workaround
Lower the ZIP version number makes it work:

-  header.setUint32(4, 0x2d_00_0800) // ZIP version 4.5 | flags, bit 3 on = size and CRCs will be zero
+  header.setUint32(4, 0x14_00_0800) // ZIP version 2.0 | flags, bit 3 on = size and CRCs will be zero

NB: I edited the issue because I thought I made it work with version 4.5 with different "META-INF/" entry but it seems it was a wrong test...

@Touffy Touffy added the enhancement New feature or request label Apr 3, 2023
@Touffy
Copy link
Owner

Touffy commented Apr 3, 2023

The reason client-zip version 2 always declares version 4.5 required to read is because of the streaming approach, it doesn't know in advance if the file will need Zip64 attributes (file size is known for sure only after copying all its data).

I'm sorry I haven't maintained version 1 very well (also, I haven't nagged contributors to make them develop non-Zip64 features in the nozip64 branch instead of master) but your issue could be solved just by switching to client-zip@nozip64, which specifies version 2.0 to read.

For client-zip 2.x to specify zip 2.0 entries, it would have to add some logic to check for usable metadata on each file, and then check for consistency. It's doable. Just not very useful since most use cases don't have that rather silly requirement you found in Microsoft Office.

@Touffy
Copy link
Owner

Touffy commented May 8, 2023

Version 1.6.2 of client-zip is now up-to-date with all the recent bugfixes and features except empty folders and — of course — Zip64 (which Office clearly cannot read anyway). No more excuse not to use it to create your ODS or XLSX or any other MS Office document :)

@Touffy Touffy closed this as completed May 8, 2023
prigaux added a commit to UnivParis1/comptex that referenced this issue Nov 18, 2024
…ater compat with LibreOffice/MS-Office

Cf Touffy/client-zip#59

NB: fflate is 4 times bigger, but it's no big deal since it is loaded in browser only when needed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request platform bug Hopefully they'll fix it
Projects
None yet
Development

No branches or pull requests

2 participants