ZipArchive::addFile needs variant with std::wstring

[jjYBdx4IL]

Otherwise boost (and likely std::filesystem::path) users need to convert wstring to multibyte before libzippp internally converts it back to wstring. :)

[ctabin]

Hi @jjYBdx4IL,
Thanks for the suggestion, it seems to be a good idea.
Do you mind making a PR ?

[jjYBdx4IL]

Looking into it

[jjYBdx4IL]

Here is what I currently do on Windows:

    ZipArchive zf(Util::Win32::conv2mbcs(_zipFile.wstring()));
    BOOST_CHECK(zf.open(ZipArchive::Write));

    // no wstring support, doesn't work:
    //BOOST_CHECK(!zf.addFile(textFile.lexically_relative(rootPath).generic_wstring(), textFile.generic_wstring()));

    // doesn't work - resulting data is garbage:
    //boost::iostreams::mapped_file_source src(textFile);
    //BOOST_CHECK(zf.addData(Util::Win32::conv2mbcs(textFile.lexically_relative(rootPath).generic_wstring()), src.data(), src.size()));
    //src.close();

    BOOST_CHECK(zf.addFile(
        Util::Win32::conv2mbcs(textFile.lexically_relative(rootPath).generic_wstring()),
        Util::Win32::conv2mbcs(textFile.generic_wstring())));

The utility function is essentially just the winapi WideCharToMultiByte function.

I looked at the code and I also tried some other zip libs and they all show the same behavior. It seems to boil down to libzip not supporting UTF-16 on Windows - or only via UTF-8. So I'd say it's an upstream issue. We could hack the Windows conversion function into libzippp, but that would just mask the upstream issue.

[BengtGustafsson]

Can't the libzip open function zip_source_win32w_create() be used together with ZipArchive::fromSource to fix this easier?

I guess the problem might be that ZipArchive stores the path from the ctor temporarily in a data member of type std::string until the archive is opened. Could the data member be changed to std::filesystem::path, maybe?

The code from the original issue author will not work if the path contains characters not representable in the active code page.