1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
|
<section> <date> 2004 </date>
<H2> FAQ </H2> (non)frequently asked questions
<BLOCKQUOTE>
While using the zziplib some people come up with questions and
problems that need a little longer to be explained. So here is
a list of these notes for your information. Keep it up.
</BLOCKQUOTE>
<ul>
<li> <a href="#latin-1">extended ascii characters in names of zipped files </a>
</li>
<li> <a href="#utf-8">unicode support for names of zipped files </a>
</li>
<li> <a href="#timestamps">timestamps of zipped files </a>
</li>
<li> <a href="#install">installation instructions </a>
</li>
<li> <a href="#php">php zip module installation </a>
</li>
<li> <a href="#license">commercial support </a>
</li>
</ul>
<DL>
<DT><a name="latin-1" />
zziplib does not support extended ascii characaters, winzip does</DT>
<DD><P>
That's somehow incorrect - the ascii range is the 7bit lower plane of
an 8bit character encoding. The upper plane had been non-standard for
decades including the age when the ZIP file format was invented. The
first instances of pkware's zip compressor were used on DOS with a
codepage 437 which has a way different encoding for the upper plane
than todays latin-1 encoding which in fact used in <em>all</em>
modern operating systems. So what really see is a mismatch of
character encodings that you are used to.
</P><P>
Even more than that the character encoding had never been specified
at all for the filenames in the central directory part. An alert
reader will however recognize that <em>each</em> file entry does
also have version-info field telling about the compressor that did
create the file entry. That version-info has an upper byte telling
about the host OS being in use while packaging. A heavy-weight
zip decoder might use that value to infer the character encoding
on the host OS (while compressing), to detect a mismatch to the
current OS (while decompressing), and going to re-code the filename
accordingly.
</P><P>
Even more than that the zip file format has seen various extensions
over time that have found their place in an extra info block. There
are info blocks telling more about the filename / codeset. However
the zziplib library does not even attempt to decode a single extra
info block as zziplib is originally meant to be a light-weight library.
However one might want to put a layer on top of the structure decoding
of zziplib that does the necessary detection of character encodings and
re-coding of name entries. Such a layer has not been written so far.
</P></DD>
<DT><a name="utf-8" />
zziplib does not support any unicode plane for filenames </DT>
<DD><P>
The pkware's appnote.text has an extra info block (id-8) for the
unicode name of the file entry but it was never actually being
used AFAICS. This might be related to the current developments of
older systems to drop usage of latin-1 encoding in the upper plane
of 8bit characters and instead choosing the multibyte encoding
according to UTF-8. This is again highly system specific.
</P><P>
Basically, you would need to instruct the compressor to use
UTF-8 encoding for the file-entries to arrive at a zip archive
with filenames in that specific character encoding. Along with
this zip archive one can switch the application into utf-8 usage
as well and take advantage of filename matches in that encoding.
This will make it so there is not mismatch in character encoding
and implicit re-coding being needed.
</P></DD>
<DT><a name="timestamps" />
zziplib does not return stat values for file timestamps </DT>
<DD><P>
That's correct and again a re-coding problem. The original
timestamp in each file entry is in DOS format (i.e. old-FAT).
The stat value is usually expected to be in POSIX format. The
win32 API has an extra function for conversion but none of the
unix compatibles has one, so it would be needed to ship a
conversion function along with zziplib.
</P><P>
However the zziplib is intended to be light-weight system and
used largely for packaging data for an application. There it
is not used strictly as a variant of Virtual File System (vfs)
that would need to map any information from the zip file system
to native host system. Of course applications are free to cut
out the DOS file timestamp and re-code it on their own. It's
just that zziplib does not provide that re-coding originally.
</P></DD>
<DT><a name="install" />
how can one install the zziplib package </DT>
<DD><P>
The zziplib project is opensource which effectly gives two ways of
installing the package: one can download the source archive and use
a C compiler to derive a binary executable for whatever computer
it needs to be on (see the platform compatibility list). This is
the preferred way but for convenience one can download a binary
installation archive with precompiled executables.
</P><P>
The current project uses autoconf/automake for cross platform
support which includes most unix compatible systems and their
native C compilers. The derivates of the GNU C compiler (gcc) have
replaced most of these native C compilers in the past years. The
<a href="http://www.mingw.org">mingw32</a> project has ported a
unix born C compiler to win32 and zziplib can be compiled with
it for the various win32 platforms.
</P><P>
There exist some C compilers which can not be embedded easily into
a unix compilation framework. The zziplib source archive ships with
project files for MSVC6 and MSVC6 (Microsoft Visual C). Adapting
these project files might help with installation problems of the
DLL hell on win32 platforms. There exist no sufficient guidelines to
mix binary helper libraries for many applications on windows.
</P><P>
There exists win32 binary archives as zip files on the download area
of zziplib (MSI is always on my wishlist). Including the project as
a helper library however you should not use it but instead compile
from source. The general library installation on unix are better,
the zziplib download area contains regularly some linux binary
archives (rpm). Many vendors of unix compatible systems provide
precompiled binary packages of zziplib on their own.
</P></DD>
<DT><a name="php" />
after installing zziplib the php zip module still does not work </DT>
<DD><P>
Now that is one of <b>the most</b> frequently asked questions that
I do receive. There is just one major problem with it: I did not
write the php zip module (which uses zziplib) and I have no idea
how php modules work or how to tell apache's php sandbox to make
it work. Really, I do not have the slightest clue on that.
</P><P>
I was posting to some php developer sites to spread awareness of
the fact and hopefully to find a guy that I could forward any
questions on the php zip module installation. But so far there is
nothing, it merily seems that such installation problems are in no
way related to zziplib anyway but exists <b>with any other module with a
third party library dependency</b> as well. So the answers on php forum
sites will ask for details of the current php and apache configuration.
</P><P>
Since I do not run a php zip whatever nor any other php stuff, it's
just that those hints were not quite helpful to me. It would be really
really great if someone with a php zip background could be so nice to
write a short roundup of the areas to check when a php zip module
installation fails, so that I could post it here. Where are you?
Yours desperatly... ;-)
</P></DD>
<DT><a name="license" />
how to obtain a license and support contract for a commercial project </DT>
<DD><P>
The zziplib has been created as a spare time project and it is put
under a very easy free public license. Even for commercial projects
there is hardly any need to negotiate a separate license since the
restrictions of the GNU LGPL or MPL can be matched easily. As a
general hint, if the zziplib is shipped unmodified with your project
then you are right within the limits of the free public license.
</P><P>
Sometimes the question for a personal license comes up for very
different reason - the need for a support contract and/or the setting
of functionality guarantees. The free public licenses include a safeguard
clause to that end, "in the hope that it will be useful,
but <em>without any warranty</em>; without even the implied warranty of
<em>merchantability</em> or <em>fitness for a particular purpose</em>."
Since the project was developed as a spare time project however there
have never been personal licenses going beyond.
</P><P>
In general you can still try to negotiate a support contract but it
will be very costly. It is much more profitable for you to tell one
of your developers to have a look at the source code and ensure the
required functionality is there, with hands on. The source code is
written to be very readable, maintainable and extensible. Just be
reminded that the free public licenses have restrictions on shipping
modified binaries but I can give you a cheap personal license to
escape these. (Such licenses can be obtained in return for tax-deductible
donations to organisations supporting opensource software).
</P></DD>
</DL>
<P> and as always - <em> Patches are welcome </em> - </P>
</section>
|