When zipping files with non-ASCII characters in their name, the resulting zip file will contain corrupted file names and reading this zip file with Gradle again will also yield incorrect file names.
I attached a Spock spec to illustrate the issue. ZipSpec.zip (612 Bytes)
As a workaround one may set a system property to specify the encoding for apache’s zip util classes, but Gradle should be able to read its own zip files out of the box.
Thanks for the report. We’ve got an open PR about this that we’ll likely do something with in the next release.
As a general rule, I always recommend ensuring that JVM’s (Gradle build JVM included) run with -Dfile.encoding=utf-8 (this is the default for all modern OSs except Windows). This is the best way I’ve found over the years to deal with encoding issues. There are plenty of libraries that don’t let you specify encoding and using UTF-8 as the default causes the least amount of tears.
Thanks for clarifying that this is a Windows-only issue.
I cannot decide whether making Gradle’s zip creation UTF-8 by default would break more than it would mitigate, but I think unzipping an archive, that has been created on the same machine should always work, whether it uses Unicode or some native code page.
It’s not really a Windows only issue. It’s an issue whenever the JVM’s default encoding isn’t UTF-8, and Windows is the only modern OS where this is the case out of the box.
but I think unzipping an archive, that has been created on the same machine should always work
It’s not really down to the machine, it’s about aligning encodings.