This makes a tiny percentage of entries in calendars ugly for latin1
users, but fixes them for UTF-8 users.
This badly needs a solution involving locale-dependent re-encoding.
about to be extracted already exists. The question, and interpretation
of the response is deliberately compatible with Info-Zip.
This change was originally obtained from NetBSD, but has three changes:
- better compatibility with Info-Zip in the handling of ^D
- Use getdelim() rather than getline()
- bug fix: != changed to == in the "file rename" code
I suspect the latter is also a bug in NetBSD, but I can't easily confirm
this.
PR: bin/143307
Reviewed by: rdivacky (change to unzip.c only)
Obtained from: NetBSD src/usr.bin/unzip/unzip.c 1.8
MFC after: 1 month
current state, it can handle all but four of the 991 zip files (including
jar files) I was able to identify in the ports tree. The remaining four
are two self-extracting archives and two which have garbage preceding the
first local header. This limitation is a feature of libarchive(3) which
I am currently working to resolve.
The code is unnecessarily large due to the need to emulate the exact
command-line syntax and behaviour of ports/unzip. My initial incompatible
implementation was one quarter the size of the one I am committing here.
