ZipArchive::addFile needs variant with std::wstring

jjYBdx4IL commented 6 months ago

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

ctabin commented 5 months ago

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

jjYBdx4IL commented 5 months ago

Looking into it

jjYBdx4IL commented 5 months ago

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.

ctabin / libzippp

ZipArchive::addFile needs variant with std::wstring #226