Archived Forum Post

Index of archived forum posts


Question about unicode filenames in CkZipW, and how to add a zipfile into a password protected zip object

Jan 14 '15 at 21:49

I have two questions about CkZip. Anyone gives a clue will be appreciated.

Problem 1: When I tried to append files with Simplified Chinese filename or Japanese filename, the files appended to the final zip file, can NOT keep correct filenames. I tried 4 text files to zip. Their names are in English, Japanese, traditional Chinese and simplified Chinese respectively.



3)你觉得简体字能不能行呢.txt(Simplified Chinese)

4)真的是只有繁體字才可以嗎簡體呢.txt(Tranditional Chinese)

But after zipping their filenames become the followings:



3)你得体字能不能行呢.txt(Simplified Chinese)

4)真的是只有繁體字才可以嗎簡體呢.txt(Traditional Chinese)

It shows only the English and traditional Chinese filenames keeps correctly, all Japanese characters are missed and two simplified Chinese characters are missed. I’d love to know the reason and how to fix it. My code is like this:

CkZipW objZip;
objZip.NewZip((const wchar_t*)wFINALZIP);
objZip.AppendFiles(wPathFileToZip, true);

Problem 2: I tried to zip several files including an already zipped file into a new zip file and set a password to it. I’m using

objZip.AppendFiles(wTxtToZip, true);

But I found that with objZip.AppendZip(Azippedfile), the password is no longer set to the zip file. It works fine without it. I would love to know a solution to set a password to the zip file in this situation.

Thank anybody who would help very much in advance!

Accepted Answer

  1. Let's handle one problem at a time. This thread will only cover the 1st problem regarding Japanese + Chinese filenames. Please post the 2nd problem to a separate forum message so that its discussion can be kept separate.
  2. ActiveX is always Unicode by default. All strings passed to and from any ActiveX are always Unicode. (In COM they are known as BSTR's.)
  3. The issue has nothing to do with whether the CkZipW (wide-char API) or CkZip (multibyte-char) API is used. The wide-char API pertains to the strings passed in to Chilkat methods/properties and the strings returned. They are wchar_t instead of "char". The internal unicode capabilities of Chilkat Zip (or any Chilkat class) exist regardless of whether an app is passing multibyte (ANSI or utf-8) chars or whether the app is passing wchar_t.
  4. Your app is calling AppendFiles and passes wPathFileToZip. This tells the Zip component the root path of the directory tree to recursively append. The internal behavior of adding files to the zip is the same as if you used the multibyte API (CkZip instead of CkZipW) to call AppendFiles. The only purpose of the Unicode (wchar_t) is to make it more convenient for the app to pass the path of the directory tree to append. In other words, just because an app uses the multibyte object (CkZip) to pass the path of the directory tree to append, this does NOT mean the internals are confined to ANSI. The internals are the same regardless, and fully unicode capable.
  5. If the filesystem of the directory tree you are adding to the zip is NOT unicode capable, then there is no solution. For example, imagine you are on a Linux system where the filesystem is not Unicode. If you type "ls" to get a directory listing, perhaps the Chinese filenames are listed correctly, but Japanese, Hebrew, Greek, etc. filenames will NOT be listed correctly. In this case, it's generally impossible. NOTE: this is likely NOT the case for you, but it is a possibility.
  6. It's possible that Chilkat Zip is working perfectly OK, and your zip is perfectly OK, but the software you are using to view the contents of the Zip does not support the Zip utf-8 (Unicode) features. Use a good program such as 7-Zip, WinZip, etc. to view the contents.
  7. See this example: Set the OemCodePage property equal to 65001 prior to calling AppendFiles.


Turn on verbose logging by setting the VerboseLogging property = true, and then post the LastErrorText's for both the AppendFiles method call and the WriteZipAndClose method call.