Fredrik Claesson

I don't think there's an issue with the source code or library. Rather I think this is caused by the file archive that's being extracted. Can you provide an example...

If the file names are not encoded with UTF-16, then you will need to manually convert the file names to the correct character set. For example, as follows converting to...

The 7-Zip-JBinding library will _not_ make any code page conversions. The library will provide all strings from the archive unmodified. That is the strings will be in the same format...

> If the file names are not encoded with UTF-16, then I will need to manually convert the file names to the correct character set. Yes, correct. > But how...

> I'm also facing this issue with Chinese file name, I compressed that file using macOS default compression. > On extracting this file on Android using this library, I see...

7-Zip supports UTF-8 and UTF-16-LE character encoding. Mac/OSX on other hand uses GBK for Chinese characters. It appears that Keka uses UTF-8, which is why this works with 7-Zip. I...

Check how you're implementing [ISequentialInStream.read()](http://sevenzipjbind.sourceforge.net/javadoc/net/sf/sevenzipjbinding/ISequentialInStream.html#read(byte[])). You may need to provide the contents of each file in smaller sections. For example, even if `read()` requests "16777216" bytes you may not want...

> I get an Exception when the compression level is greater than 3: I created the following project to try and debug the "out of memory" error. (This uses the...

When archiving large files with a high level of compression, the [sevenzipjbinding](https://github.com/borisbrodski/sevenzipjbinding/issues) library can use large amounts of Java heap memory. To be able to handle such scenarios on Android,...

Please see sevenzipjbinding [Issue #7](https://github.com/borisbrodski/sevenzipjbinding/issues/21) "OutOfMemoryError while constructing ByteArrayStream": > But it is the case of "It's not a bug, it's a feture" :) Sorry. > > You see, the...