bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#65305: 29.1; archive-mode can not handle subfile names encoded with


From: awrhygty
Subject: bug#65305: 29.1; archive-mode can not handle subfile names encoded with utf-8
Date: Tue, 15 Aug 2023 22:53:01 +0900

Eli Zaretskii <eliz@gnu.org> writes:

>> From: awrhygty@outlook.com
>> Date: Tue, 15 Aug 2023 13:31:16 +0900
>> 
>> 
>> With python 3.10, ZIP archive can be created with:
>>   python -m zipfile -c ARCHIVE.zip subfile
>> 
>> If the subfile name contains non-ASCII characters, they are encoded with
>> utf-8 in anyway. Such subfile names are decoded with local language
>> encoding(cp932 for Japanese Windows OS) in archive-mode.
>> 
>> For example, archive 一.txt in test.zip with python:
>>   python -m zipfile -c test.zip 一.txt
>> The subfile name is shown as 荳\200.txt in archive-mode buffer and the
>> entry can not be extracted. 
>
> Is there any way of distinguishing these Python-created ZIP archives
> from ZIP archives created by other Windows programs?
>
> Emacs by default assumes that file names in a ZIP archive created by a
> Windows program are encoded in the console codepage, and it enforces
> using that encoding for file names when the "creator" of the ZIP
> archive indicates the archive was created by Windows programs such as
> InfoZip's zip.exe and the File Explorer.  In my testing, zip archives
> created by Python as above record the "creator" as number 0 (zero),
> which is identical to what InfoZip does.  So, unless someone explains
> how to distinguish these zip archives from those created by InfoZip, I
> don't see how can Emacs know whether to use the InfoZip heuristics or
> the Python heuristics.  Without the InfoZip/File Explorer heuristics
> we have in arc-mode.el today, Emacs on Windows would be completely
> unable to support non-ASCII file names in ZIP archives.

There is a bit flag indicating that the subfile name is encoded with
utf-8. Bytes 6-7 in local file header or bytes 8-9 in central directory
header are general purpose bit flag. And bit 11 of the flag represents
file encoding flag(1 for utf-8 encoding).

I guess unzip.exe does not support utf-8 encoded subfile name.
Writing batch file with utf-8 encoding:
  c:\Emacs\emacs-29.1\bin\unzip.exe test.zip 一.txt
and run with chcp 932, 荳\200.txt is extracted.
With chcp 65001, extraction failed.

Writing batch file with cp932 encoding:(same as above)
  c:\Emacs\emacs-29.1\bin\unzip.exe test.zip 一.txt
and run with chcp 65001, 荳\200.txt is extracted.
With chcp 932, extraction failed.
This is not an ideal behavior, but extraction to STDOUT may work.

To the contrary, 7z.exe extracts 一.txt correctly.
If batch file is encoded with utf-8, it works with chcp 65001.
If batch file is encoded with cp932, it works with chcp 932.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]