UTF8 Support

[KevBradford]

Unzipping files with UTF8 characters, such as accent marks in other languages, results in an invalid character in the filename.

[Shchvova]

Thank you for creating the issue. This is really the best way to report issues. As per issue itself, it is complicated. Like, plugin right now does support UTF8. Problem is that system implementations of zip vary widely, and you would have to specify which platforms and tools you have issues with. Like, what are you using to create and upack and on which platforms. For example, here is tiny test.zip with single Cyrillic file тест.txt which I created and unpacked with Solar2D on macOS. I tried it pretty much in all scenarios on macOS: creating archive both with code and with OS, and unpacking it with both. I just did a small test, opening project sandbox (File -> Show Project Sandbox) and putting there test.zip , then uncompressing, deleting archive, compressing, deleting file, uncompressing. Here is my code:

local json = require "json"
local zip = require("plugin.zip")

display.newText("Compress", display.contentCenterX, display.contentCenterY*0.5, nil, 25):addEventListener("tap", function()
    zip.compress({
        zipFile = "test.zip",
        zipBaseDir = system.DocumentsDirectory,
        srcBaseDir = system.DocumentsDirectory,
        srcFiles = { "тест.txt" },
        -- includeFilePath = true,
        listener = function( e )
            print(json.prettify( e ))
        end
    })
end)

display.newText("Uncompress", display.contentCenterX, display.contentCenterY*1.5, nil, 25):addEventListener("tap", function()
    local zipOptions =
    {
        zipFile = "test.zip",
        zipBaseDir = system.DocumentsDirectory,
        dstBaseDir = system.DocumentsDirectory,
        files = { "тест.txt" },
        listener = function( e )
            print(json.prettify( e ))
        end

    }
    zip.uncompress( zipOptions )
end)

[KevBradford]

Thanks Vlad! For now we have just created a workaround and use non UTF8 characters so we don't run into compatibility issues. Interesting it is more an issue with Windows compress than the plug-in. If we do this again we'll try another compression tool.

[Gil4]

Hey Vlad, thanks a lot for looking into this! I've also encountered this or a similar issue and thought it's a more general problem with UTF8, but guess not.

I don't have access to the PC where it happened atm, but back when it happened I tested it on several PCs and more or less remember the details: it was an archive created and encrypted with WinRAR on Windows 10, and the Zip plugin was uncompressing it perfectly fine on several PCs except for the one which had the Cyrillic username. Also uncompressing worked fine on that PC too when targeting a folder that didn't contain Cyrillic in its path. As such, I presumed that it was likely an issue with the original target path instead — DocumentsDirectory which resulted in C:\Users\*Cyrillic_Username*\AppData\... .

I got curious and changed your example slightly to test it out with a file inside a directory with a Cyrillic name within the DocumentsDirectory. It worked fine.

Then it made me wonder if the DocumentsDirectory itself tolerates Cyrillic characters within its path, so I created a new Solar project with a Cyrillic name. That way the DocumentsDirectory gets placed inside a Cyrillic_name-random_hash directory (тестЗип-AA6792B4073AA5A3AD7E7AFB779E54C9 in my case). And then the aforementioned example of yours stopped working, even after I copypasted it anew so that no changes of mine with additional directories were involved. Here's the response I'm getting from the plugin:

03:33:03.903  {
03:33:03.903    "errorMessage":"",
03:33:03.903    "isError":true,
03:33:03.903    "name":"zip",
03:33:03.903    "response":[],
03:33:03.903    "type":"compress"
03:33:03.903  }

After that, to make sure that it's only an issue with the plugin and not with Solar's DocumentsDirectory overall, I added the following code to the listener:

local path = system.pathForFile( "тест.txt", system.DocumentsDirectory )
local testFile = io.open( path )

if testFile then
   print( "File exists." )
   testFile:close()
else
    print( "File does not exist." )
end

And the output became:

03:37:19.555  {
03:37:19.555    "errorMessage":"",
03:37:19.555    "isError":true,
03:37:19.555    "name":"zip",
03:37:19.555    "response":[],
03:37:19.555    "type":"compress"
03:37:19.555  }
03:37:19.555  File exists.

To sum up, could it be that the issue only happens when one of the base directories itself specified in the zipBaseDir/srcBaseDir/dstBaseDir contains non-UTF8 characters?