3 ms·
Another fairly major flaw with zip is a lack of a defined encoding on filenames. As far as I can tell, it's impossible to 100% reliably include non-ASCII filena
by trothamel 10y ago
Another fairly major flaw with zip is a lack of a defined encoding on filenames. As far as I can tell, it's impossible to 100% reliably include non-ASCII filenames inside a zip. (Probably because the format predates unicode's general acceptance.)
- TAForObvReasons 10y agoAPPNOTE.TXT actually has a comment about it: > D.1 The ZIP format has historically supported only the original IBM PC character encoding set, commonly referred to as IBM Code Page 437. This limits storing file name characters to only those within the original MS-DOS range of values and does not properly support file names in other character encoding, or languages. Extra fields are generally used to implement other code pages. There is a direct way to do it with an extension to the GPBF. Problem is that some writers don't implement the proper flags.
- niftich 10y agoThe spec says filenames are encoded in CP437. UTF-8 filenames are supported as overlays in two different 'extra headers', which essentially amount to vendor-specified extensions. There are noncompliant implementations that generate zip files with filenames in ISO 8859-1 and other 8-bit codepages, and conversely, there are decompressors that try to accommodate such malformed files.
- Graphon1 10y ago> it's impossible to 100% reliably include non-ASCII filenames inside a zip. Yes, the spec does not accommodate this. However there are conventions among popular ZIP creation tools that allow it. If the zip spec were governed by an open body, then this is the kind of thing that would get quickly fixed. (basically standardize the common practice already in use). I don't know why PKWARE never fixed the spec. Maybe because there's no money in it for them, and the pain for the industry is really not that severe.