zlib and unicode/multi-character filepath
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 18/12/2006 at 22:32, xxxxxxxx wrote:
User Information:
Cinema 4D Version: 8.2-10.0
Platform: Windows ; Mac ; Mac OSX ;
Language(s) : C++ ;---------
I know this is a little wide in scope, but since you guys implemented a zip class, maybe you can tell me how to get zlib to work with unicode/multicharacter filepaths.The problem is that gzopen() is just a wrapper for fopen() which, as we all know, only understands CHAR - not WCHAR or such. When passed a filepath with >8-bit characters, it fails. For instance, Poser(tm) where the (tm) is a non-ASCII character causes failures because fopen() can't possibly handle non-ASCII characters (by definition and implementation). You need something like wfopen() for this! This would be superbly great.... except that libz.dylib is slightly beyond my ability to control. Apple supplies that - their fault completely (blame - blame - blame!). How can they provide a zlib library for a UNICODE and multi-character system without providing support for the said library to open UNICODE and multi-character file paths (shame - shame - shame! on them).
The only way around a simple compressed-file-in to decompressed-file-out would be to open the file another way for read and stream the decompression in memory to another file for write. Don't know how fun that is, but let's just say that I used the former method as it wasn't ten times as complex...
-
THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED
On 21/12/2006 at 11:04, xxxxxxxx wrote:
Let's bring this back into scope. Don't know what it is, but this behaviour is only occurring in (tada!) Universal Binary versions - no problems (afaik) on Windows and no problems with PPC versions. The PPC versions chug along merrily, but it is UB where zlib is failing.
Any information on this that can be provided? I've been scouring the internet for days trying to find anything related and nigh a peep about this.
Remember this is only because there is a wide-character (multibyte or unicode - I don't know) in one of the folder names in the path. Seems that PHP had an issue with this, but that's PHP and no info on how it was rectified at the lowest levels.
Thanks,