login about faq

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!

asked Jan 12 '15 at 22:33

Veda's gravatar image


edited Jan 12 '15 at 22:39

I tried this as well with, and I see the same issue - Unicode filenames don't appear to be supported as far as I can tell (even when passing a Unicode filename to the AppendData method).

I don't see any methods for setting the Charset used by the ChilkatZip object either.

Does the ZIP file format support Unicode? I've tried using 7-zip to zip a unicode file name, and it looks good when I open the file back in 7zip, but Windows Explorer Shell doesn't show the right filename, so maybe unicode support is a proprietary extension?

(Jan 13 '15 at 09:31) jpbro ♦

@jpbro ♦ A unicode version CkZipW is provided, but is not placed on the homepage. google CkZipW and you could get its documentation. It has the same properties and methods as CkZip, but the occurrences of "char" are replaced with "wchar_t".

(Jan 13 '15 at 20:56) Veda

Thanks for the info Veda - I actually use the ActiveX version, so I can't take advantage of the CkZipW component. I'm surprised the ActiveX doesn't support Unicode though, but maybe there's a good reason?

(Jan 13 '15 at 21:35) jpbro ♦

  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: http://www.example-code.com/cpp/zip_utf8.asp Set the OemCodePage property equal to 65001 prior to calling AppendFiles.

answered Jan 14 '15 at 08:58

chilkat's gravatar image

chilkat ♦♦

Thanks very much! Your point 6 and point 7 help me solve my problem! Actually you are right about 7-Zip and OemCodePage. I add objZip.put_OemCodePage(65001) before calling objZip.AppendFiles(,), and use 7-zip to extract the zipped file, then it works with Simplified Chinese filename and Japanese filename. Again, thanks for your advice:)

(Jan 14 '15 at 21:49) Veda

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.


answered Jan 14 '15 at 21:49

chilkat's gravatar image

chilkat ♦♦

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or __italic__
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported



Asked: Jan 12 '15 at 22:33

Seen: 1,026 times

Last updated: Jan 14 '15 at 21:49

powered by OSQA