validateFileName problem?

[HC1988]

hi ,respect for @thejoshwolfe

just now, i got a problem, when i use zipfile.readEntry, it got a " invalid characters in fileName" ,so I trace code, find blow code

in index.js
but "fileName" are Common formats and have no error like "path\to\file.extension" ,
so i add a single line of code " fileName=fileName.replace(/\/g,'/') " at function's start ,and it's ok .
env:
OS: windows 10 ,×64
software: nodejs in nw.js
my question is why " invalid characters in fileName" come out ?

you got my respect, and thank you will be resolving my question.

[thejoshwolfe]

Sorry for the delayed response.

The error you're getting is due to an entry is the zipfile having backslash characters in its filename. If you think the filenames don't have backslashes, then perhaps you're examining the zipfile with a tool that is transforming the backslashes into forward slashes before showing them to you.

Here's some background information:

The zip file specification forbids backslash characters in entry filenames. Although windows paths are typically and canonically represented with backslash separators, zip files are not specific to windows and must use forward slashes in entry file names. For reference, backslash characters are legitimately allowed in Linux file names (not as separators, but actually in the name of a file).

The zip file specification probably forbids backslash characters in filenames because of the confusion that would arise from zipping a Linux file called one\name.txt and having it extract in Windows as file called name.txt in a directory called one. There are also security concerns with paths being difficult to understand, but that may be beside the point. The issue at hand is that if a zipfile has backslash characters in entry file names, then it's a malformed zipfile, and yauzl's error is correct.

However, it may be desirable to ignore this particular type of error. There's already a feature in yauzl that can accomplishing this, which is the decodeStrings option. By turning that option off, you can do whatever transformations you'd like to on the string before passing it to validateFileName(), or you could even skip validation altogether (not recommend for security reasons). You'll have to do some extra work to do UTF-8 vs CP437 decoding, especially when it comes to the Info-ZIP Unicode Path Extra Field. See README.md to read all about how to use decodeStrings: false in your code.

Again, sorry for the delayed response.