The path separator might not be the biggest problem. Software is supposed to run unicode today, but windows used to use codepages, like
You must be registered to see the links
and
You must be registered to see the links
. It offers a subset of the unicode characterset, but it uses less memory, which used to be important. For instance you can expect Japanese text written in codepage 932 to use 50% more memory if converted to utf-8.
What might happen here is if the zip file is encoded in some codepage and is read with another codepage, or encoded in unicode, but the reader assumes it's a codepage or similar, then it's possible that there is a byte combination, which simply doesn't exist in that codepage, which would result in an error. It's also possible that some text just ends up as garbage, which results in unreadable text.
Example: Let's say a sentence ends with "á.". Western Europe uses codepage 1252, which makes it E1 2E. Reading this in Japanese, it becomes codepage 932, where E1 indicates that it's the first byte in a two byte character. However the second character will never be below 3F meaning the charater E1 2E doesn't exist in that encoding, hence throwing an encoding error.
I will say that I have encountered encoding errors in zip files, so it's plausible that this has something to do with it, through worst case I have encountered has been incorrectly named files. Luckily the 128 first characters are the same in all encodings, so if all characters are in ASCII as in plain English (like a instead of á), then filenames should be correct even if decoded with the wrong encoding.
This is also why some games requires Japanese locale. The games assumes all file paths are encoded in codepage 932, but doesn't actually explicitly tell windows that, so windows falls back to using the locale set in windows for applications, which doesn't tell which locale to use. It's one line of code to make a game tell windows to always use Japanese locale regardless of the settings in windows, but this is rarely used and since it has to be added before compiling, it's something developers should do, not end users.
For quite a number of years the recommendation has been to not use codepages as that will avoid the problems. Microsoft is even working on making it harder to use them to push developers to not keep using them, but that's not the same as developers will stop doing things like they did it 30 years ago, hence why this is still a problem.
I will add that sometimes the problem is not even with the filename, but the path, so if your username has some character, which doesn't work with the encoding in question, then that can make it fail. However if you unzip in something like C:\my_folder, then that will get around that issue. The precise location isn't important, just that it only has plain ASCII and not any extended characters in it.
It's probably not an issue here, but while we are with encoding, some applications have problems with spaces in the path, which is why some foreign developed programs doesn't work inside "program files". This is rare, but
