Create 2 options to decodeStrings without validateFileName
FabriceGaudin opened this issue · 5 comments
Thank you for this lib, it works great !
In my use case, i'd like to ignore the "invalid characters in fileName" errors, to automatically convert backslashes to forward slashes.
I read that @thejoshwolfe recommands using decodeStrings: false here: #54 (comment)
But as he mentions it:
You'll have to do some extra work to do UTF-8 vs CP437 decoding
It's too bad to do this extra work whereas the lib can do it, and this work isn't directly linked to the validation step. I'd like to create 2 different options:
autoValidateFileName: default true, if false, the methodvalidateFileNameisn't calleddecodeStrings: default true, if false, don't decode Buffer.
Or if my use case is not so specific, maybe we can add an option authorizeBackslash to avoid throwing an error in validateFileName.
What do you think about it ?
Can you tell me what zipfile creator is putting backslash characters in filenames? I'd be much more willing to support that non-standard usecase if I can reproduce the problem.
@thejoshwolfe Unfortunately I don't know which zipfile creators are used. It seems that my users are getting zip files from a third party.
I found a suggestion online that Microsoft .NET framework 4.5.0 until 4.6.1 had a bug where System.IO.Compression.ZipFile would not canonicalize the paths you passed into it.
I won't be able to test this myself for several weeks, but this may be the implementation (or one of them) that produced these malformed zipfiles we're all seeing floating around the internet. If I can get confirmation that we've found the culprit, I'll add an option to fix zipfiles while reading them (which will probably be enabled by default).
thanks to @YanBeat in #88 for verifying that .NET 4.5 is indeed the culprit. Expect a fix for this issue coming soon.
published yauzl 2.10.0 which replaces backslashes by default. let me know if this solves your problem.