Improved safegetzipfile() #567
No reviewers
Labels
No Label
DBF
Dates
Defined Names
Features
Formula
HTML
Images
Infrastructure
Integration
International
ODS
Operations
Performance
PivotTables
Pro
Protection
Read Bug
SSF
SYLK
Style
Write Bug
good first issue
No Milestone
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: sheetjs/sheetjs#567
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "safegetzipfile"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I have an xlsx file that can't be read by this lib because there is a
xl/SharedStrings.xml
file (notice upper case "S").I've improved
safegetzipfile()
function to overcome this issue.@duzun thanks for the heads up! It's a strange error because I can manually produce files with a capital S that work in excel and when fed back to js-xlsx.
If you don't mind doing a bit of sleuthing, can you look at the
[Content_Types].xml
file and find the part name corresponding to the content typeapplication/vnd.openxmlformats-officedocument.spreadsheetml.sharedStrings+xml
? We look at the content types file to find the name of the shared strings file. If that file was written correctly then you should see a line like:If the case is correct then there's some issue with the content types parsing. If you see the part name has a different case, like
PartName="/xl/sharedStrings.xml"
, then we probably should make the getfile functions case insensitive.Related: https://github.com/SheetJS/js-xlsx/issues/439
Hi @SheetJSDev
I've checked that file and found that
"application/vnd.openxmlformats-officedocument.spreadsheetml.sharedStrings+xml"
in[Content_Types].xml
is"/xl/sharedStrings.xml"
, but the file is named"/xl/SharedStrings.xml"
in the archive.I suppose this particular file is generated by some software other then office.
BTW I've tested the new release
0.8.6
and the issue is gone!Thanks!
@duzun either way, as I explained in another comment, readers are supposed to do case-insensitive name comparisons.
And as for the PR, it's preferable to do a direct scan of the keys in this case. I think there may be a few more places where
filter
is used and they should ultimately be reworked with a non-filter variantPull request closed