Comment 78 for bug 580961

I contacted the author of last patches (compiled into PPA by @frol) about reported flaw with Hebrew and possibly other languages than Russian.

He said he just solved problem for himself, published the solution on his favorite local Linux/FOSS site "so it won't be lost", and doesn't want to work on it any further.

Also he said he wrote an email to the original author of 'libnatspec' and zip/unzip patches using it, with an offer to include his contribution. The email was never answered.

So, this path of solution looks like a blind alley - at least if we want flexible worldwide solution.
--------
From my perspective, the problem is in clinging to the old piece of legacy code what tries to be extremely portable at the cost of architectural layering, use of libraries and system-specific facilities.

I see the solution in abandoning InfoZIP altogether and writing a gcc/*nix only zip/unzip in either of two ways:
1) Well designed to the modern coding standards library for zipfile format (say 'libzipfile'), with all reasonable hooks and callbacks for stream and piece-wise processing, NOT doing any data transformations ex for ZIP record structures and calling zlib for (de-)compression itself. And atop of this library, also modern well-designed command line tools, relying on Linux/*NIX specific libraries for things like charset conversion, command line options etc, written for clarity and flexibility.
2) Stopgap scripts in Python, wrappers around it's zipfile and iconv modules, minimal to the requirements of GUI's like FileRoller and it's KDE counterpart.