login about faq

After upgrading to "Chilkat C/C++ Libs for VC++ 2015 / win32", we have started to experience some odd behaviour regarding zipping of files (zip.AppendFiles...)
Prior to the zipping we set the codepage to utf-16 (1200). What we experience is that all the files in the zip are truncated. E.g. "MyPicture.jpg" gets truncated to "MyPicture.jp"... This is 100% consistent for all the files.

We don't have this problem if we switch to utf-8.
Running same codes from Visual Studio 2013 (on same computer) with the old chilkat (prior to 2015), does not yield this problem.

Any idea what could cause this ?


zip.put_OemCodePage(1200);  // UTF-16
if (!zip.AppendFiles(pszFilesToAdd, true))
// error handling (we don't get here in our example)
CkString strError;

This yields the following "LastErrorText" (i.e. no error as far as I can see)
    DllDate: Jun 23 2015
    UnlockPrefix: ABCD
    Username: XXPC:YY
    Architecture: Little Endian; 32-bit
    Language: Visual C++ 12.0 (32-bit)
    VerboseLogging: 0
      FilePattern: C:TempJustATest.psn
      AppendFromDir: .
      BaseDir: C:TempJustATest.psn
      FilenamePart: *
      IsSpecificFile: 0
      recurse: 1
      saveExtraPath: 0
      archiveOnly: 0
      includeHidden: 1
      includeSystem: 1
      ignoreAccessDenied: 1
      No exclusion patterns.
      numAdded: 174

Thanks in advance.

asked Aug 25 '15 at 09:33

Hakon's gravatar image


I'll have a look tomorrow...


answered Aug 25 '15 at 22:10

chilkat's gravatar image

chilkat ♦♦

Hi, Any updates on this one ?


(Aug 31 '15 at 01:49) Hakon

Sorry for the delay. I'm looking right now..

(Aug 31 '15 at 12:37) chilkat ♦♦

I reproduced the problem, and I'll work to fix it. However, I suspect it's not a good idea to be using utf-16 in a .zip anyway. I tested opening the .zip what was written using 7-Zip, and the result is as I expected -- each entry only shows the 1st char. This is because a typical zip implementation would be expecting a multibyte charset encoding (i.e. nothing with embedded nulls) and the embedded nulls within utf-16 are unintentionally seen as string terminators. I suspect a lot of zip implementations will have trouble with it..


answered Aug 31 '15 at 13:02

chilkat's gravatar image

chilkat ♦♦

After reviewing the code, this is something that would require more than a quick-fix. Given that I think it's a poor idea to be using utf-16 for the file paths in a .zip (utf-8 is a far better choice), I think the only choice, at least for now, is to avoid using utf-16 and perhaps disallow it as a valid OME code page choice..

(Aug 31 '15 at 13:08) chilkat ♦♦

Ok, thanks for your reply. We have switched to utf-8.

(Sep 01 '15 at 01:47) Hakon
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: Aug 25 '15 at 09:33

Seen: 1,710 times

Last updated: Sep 01 '15 at 01:47

powered by OSQA