Improve robustness when the wrong encoding was passed into 
ZipArchiveInputStream / ZipFile
------------------------------------------------------------------------------------------

                 Key: COMPRESS-170
                 URL: https://issues.apache.org/jira/browse/COMPRESS-170
             Project: Commons Compress
          Issue Type: Improvement
          Components: Archivers
    Affects Versions: 1.3
            Reporter: Trejkaz


If a zip file is in one encoding and I try to read it using a different 
encoding, what I expect to happen is that the filenames get garbled but the 
data otherwise extracts correctly (which is what I see using native tools to 
extract a zip file in this fashion.)

However, what Commons Compress can do is to try and decode a name, fail, and 
ultimately give us no zip entries to work with.

Here's a test to show what I mean: 

    @Test
    public void testWrongEncodingPassedIn() throws Exception {
        // Making the test zip file:
        File inputFile = new File(scratch, "test.dat");
        byte[] inputData = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };
        FileUtils.writeByteArrayToFile(inputFile, inputData);
        File file = new File(scratch, "test.zip");
        try (ZipArchiveOutputStream out = new ZipArchiveOutputStream(file)) {
            out.setEncoding("windows-31j");
            ZipArchiveEntry entry = new ZipArchiveEntry(inputFile, 
"\u767A\u8D77\u4EBA\u6C7A\u5B9A\u66F8");
            out.putArchiveEntry(entry);
            out.write(inputData);
            out.closeArchiveEntry();
        }

        // Trying to iterate over it:
        int entryCount = 0;
        try (ZipArchiveInputStream in = new ZipArchiveInputStream(new 
FileInputStream(file), "windows-1252", false)) {
            ZipArchiveEntry entry = in.getNextZipEntry();
            if (entry == null) {
                break;
            }
            entryCount++;
        }

        assertEquals("Wrong number of entries", 1, entryCount);
    }

In this situation it's definitely the caller's "fault", but unfortunately the 
end user is often the one supplying the encoding and they would rather see 
garbled contents with the actual data intact, than no data at all.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to