Cœur

It's a progress of number of unzipped files out of total number of files. To make it based on actual data being processed, it would require to rework it. So...

Apple seems to address this CVE in: - **iOS 15.5 and later**, tvOS 15.x and later, watchOS 8.x and later (aka: only the latest public releases, no backports) - **macOS...

Then stay on an older version of ZipArchive. Or manually store a local copy of the Podfile/Cartfile and configure it the way you want for your needs.

Nice feature. But we can't change the signatures of `createZipFileAtPath:::` and `open` like that: we need to keep a compatibility layer, which I can easily write eventually.

Hi, thanks for reporting this issue. Can you share the zip file with me?

`printf("%s\n", filename)` gives: >\202\255\202\351\202\334.pdf `NSLog(@"%@", @(filename))` gives: >(null) Then it goes to `NSStringEncoding enc = CFStringConvertEncodingToNSStringEncoding(kCFStringEncodingGB_18030_2000);` that was added by https://github.com/ZipArchive/ZipArchive/pull/273 because the first mention of the issue was specific...

For reference, I consider this issue as a duplicate of #269. But thanks for the zip file, it was very useful.

I know. I got a solution as you can see in the linked issue. I just need to make sure it doesn't break Chinese or other encodings.

After testing, it's compatible with both Japanese and Chinese. Here is my solution in #385: NSData *data = [NSData dataWithBytes:(const void *)filename length:sizeof(unsigned char) * fileInfo.size_filename]; [NSString stringEncodingForData:data encodingOptions:nil convertedString:&strPath...

@nguyenngochanh Can you share the file? Which system and version is that? Which app is displaying this? I need a way to reproduce your issue to help you. :)