nsIZipWriter not recognizing international characters correctly
Categories
(Core :: Networking: JAR, defect)
Tracking
()
People
(Reporter: cbaker, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 If an international character appears in a filename or path, zipWriter does not interpret it correctly. Example: file = "C:\\tmp\\Régis" zipW.addEntryFile(file, Ci.nsIZipWriter.COMPRESSION_BEST, entry, false); Archive is created with the path "C:\tmp\R+¬gis\" Reproducible: Always
Updated•16 years ago
|
Comment 1•16 years ago
|
||
See https://bugzilla.mozilla.org/show_bug.cgi?id=296795 ZipReader doesn't handle non-ASCII characters. There was considerable resistance to the idea that file names need to handle non ASCII characters in the nsIZipReader and nsIZipWriter components.
Updated•14 years ago
|
Comment 3•13 years ago
|
||
I was just wondering, has there been any update about the status of this bug? I feel like its a limitation that will severely bite Firefox in the leg in the long run.
> (In reply to Gary Johnson from comment #1)
> See https://bugzilla.mozilla.org/show_bug.cgi?id=296795
> ZipReader doesn't handle non-ASCII characters.
>
> There was considerable resistance to the idea that file names need to handle
> non ASCII characters in the nsIZipReader and nsIZipWriter components.
Has sentiment changed since the bug was reported? It's been 3 years, and Unicode (UTF-8 at the very least) is becoming a must in computing these days...
Comment 4•13 years ago
|
||
(In reply to Stanley Chan from comment #3) > I was just wondering, has there been any update about the status of this > bug? I feel like its a limitation that will severely bite Firefox in the leg > in the long run. It looks like no-one is actively working on it. > > (In reply to Gary Johnson from comment #1) > > See https://bugzilla.mozilla.org/show_bug.cgi?id=296795 > > ZipReader doesn't handle non-ASCII characters. > > > > There was considerable resistance to the idea that file names need to handle > > non ASCII characters in the nsIZipReader and nsIZipWriter components. > > Has sentiment changed since the bug was reported? It's been 3 years, and > Unicode (UTF-8 at the very least) is becoming a must in computing these > days... I just re-read the bug and would disagree that there is any resistance at all to the idea that filenames need to handle non-ascii characters. What there is is a set of potential interoperability issues that need to be handled. As the original developer of nsIZipWriter I'd love to see it improved to handle non-ascii characters (amongst other things) provided the complexity isn't too high and its implementation is interoperable with the other major zip utilities.
Comment 5•13 years ago
|
||
Wait a moment. If I understand right, this bug is WFM. Actually my browser seems generating UTF-8 zip entry. There's no "right" way to read non-ascii zip entries, for nobody is sure in what encoding/charset they are written. That's why bug 296795 is hard to fix. On the other hand, how to write a non-ascii zip entry is defined by PKWARE, and nsZIPWriter is following the rule. If there really exists an i18n bug, we need more accurate "steps to reproduce".
Updated•8 years ago
|
Comment 6•1 year ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
Comment 7•5 months ago
|
||
The severity field is not set for this bug.
:Gijs, could you have a look please?
For more information, please visit BugBot documentation.
Comment 8•5 months ago
|
||
I suspect this is WFM. But conveniently Dave said he wrote this in comment #4, a mere 12 years ago, so let's ask him! ;-)
Comment 9•5 months ago
|
||
It's possible that this is fixed but it is more likely that it is working in some combinations of OS and locale and not others. However this code is more properly under the jar module so moving over there. Currently devtools (and add-on tests) are the only actual consumers of it.
Comment 10•5 months ago
|
||
Fixed by bug 296795 on all supported platforms. Bug 296795 was open when comment #12 was written.
Description
•