faq

psp上的reader 这个是以月光老大的cnreader为基础 增加了zip文件浏览功能

    Yes. Please read the license in zlib.h.

23. Is zlib under the GNU license?

    No. Please read the license in zlib.h.

24. The license says that altered source versions must be "plainly marked". So
    what exactly do I need to do to meet that requirement?

    You need to change the ZLIB_VERSION and ZLIB_VERNUM #defines in zlib.h. In
    particular, the final version number needs to be changed to "f", and an
    identification string should be appended to ZLIB_VERSION. Version numbers
    x.x.x.f are reserved for modifications to zlib by others than the zlib
    maintainers. For example, if the version of the base zlib you are altering
    is "1.2.3.4", then in zlib.h you should change ZLIB_VERNUM to 0x123f, and
    ZLIB_VERSION to something like "1.2.3.f-zachary-mods-v3". You can also
    update the version strings in deflate.c and inftrees.c.

    For altered source distributions, you should also note the origin and
    nature of the changes in zlib.h, as well as in ChangeLog and README, along
    with the dates of the alterations. The origin should include at least your
    name (or your company's name), and an email address to contact for help or
    issues with the library.

    Note that distributing a compiled zlib library along with zlib.h and
    zconf.h is also a source distribution, and so you should change
    ZLIB_VERSION and ZLIB_VERNUM and note the origin and nature of the changes
    in zlib.h as you would for a full source distribution.

25. Will zlib work on a big-endian or little-endian architecture, and can I
    exchange compressed data between them?

    Yes and yes.

26. Will zlib work on a 64-bit machine?

    It should. It has been tested on 64-bit machines, and has no dependence
    on any data types being limited to 32-bits in length. If you have any
    difficulties, please provide a complete problem report to [e-mail]

27. Will zlib decompress data from the PKWare Data Compression Library?

    No. The PKWare DCL uses a completely different compressed data format
    than does PKZIP and zlib. However, you can look in zlib's contrib/blast
    directory for a possible solution to your problem.

28. Can I access data randomly in a compressed stream?

    No, not without some preparation. If when compressing you periodically
    use Z_FULL_FLUSH, carefully write all the pending data at those points,
    and keep an index of those locations, then you can start decompression
    at those points. You have to be careful to not use Z_FULL_FLUSH too
    often, since it can significantly degrade compression.

29. Does zlib work on MVS, OS/390, CICS, etc.?

    We don't know for sure. We have heard occasional reports of success on
    these systems. If you do use it on one of these, please provide us with
    a report, instructions, and patches that we can reference when we get
    these questions. Thanks.

30. Is there some simpler, easier to read version of inflate I can look at
    to understand the deflate format?

    First off, you should read RFC 1951. Second, yes. Look in zlib's
    contrib/puff directory.

31. Does zlib infringe on any patents?

    As far as we know, no. In fact, that was originally the whole point behind
    zlib. Look here for some more information:

    http://www.gzip.org/#faq11

32. Can zlib work with greater than 4 GB of data?

    Yes. inflate() and deflate() will process any amount of data correctly.
    Each call of inflate() or deflate() is limited to input and output chunks
    of the maximum value that can be stored in the compiler's "unsigned int"
    type, but there is no limit to the number of chunks. Note however that the
    strm.total_in and strm_total_out counters may be limited to 4 GB. These
    counters are provided as a convenience and are not used internally by
    inflate() or deflate(). The application can easily set up its own counters
    updated after each call of inflate() or deflate() to count beyond 4 GB.
    compress() and uncompress() may be limited to 4 GB, since they operate in a
    single call. gzseek() and gztell() may be limited to 4 GB depending on how
    zlib is compiled. See the zlibCompileFlags() function in zlib.h.

    The word "may" appears several times above since there is a 4 GB limit
    only if the compiler's "long" type is 32 bits. If the compiler's "long"
    type is 64 bits, then the limit is 16 exabytes.

33. Does zlib have any security vulnerabilities?

    The only one that we are aware of is potentially in gzprintf(). If zlib
    is compiled to use sprintf() or vsprintf(), then there is no protection
    against a buffer overflow of a 4K string space, other than the caller of
    gzprintf() assuring that the output will not exceed 4K. On the other
    hand, if zlib is compiled to use snprintf() or vsnprintf(), which should
    normally be the case, then there is no vulnerability. The ./configure
    script will display warnings if an insecure variation of sprintf() will
    be used by gzprintf(). Also the zlibCompileFlags() function will return
    information on what variant of sprintf() is used by gzprintf().

    If you don't have snprintf() or vsnprintf() and would like one, you can
    find a portable implementation here:

        http://www.ijs.si/software/snprintf/

    Note that you should be using the most recent version of zlib. Versions
    1.1.3 and before were subject to a double-free vulnerability.

34. Is there a Java version of zlib?

    Probably what you want is to use zlib in Java. zlib is already included
    as part of the Java SDK in the java.util.zip package. If you really want
    a version of zlib written in the Java language, look on the zlib home
    page for links: http://www.zlib.org/

35. I get this or that compiler or source-code scanner warning when I crank it
    up to maximally-pedantic. Can't you guys write proper code?

    Many years ago, we gave up attempting to avoid warnings on every compiler
    in the universe. It just got to be a waste of time, and some compilers
    were downright silly. So now, we simply make sure that the code always
    works.

36. Will zlib read the (insert any ancient or arcane format here) compressed
    data format?

    Probably not. Look in the comp.compression FAQ for pointers to various
    formats and associated software.

37. How can I encrypt/decrypt zip files with zlib?

    zlib doesn't support encryption. The original PKZIP encryption is very weak
    and can be broken with freely available programs. To get strong encryption,
    use GnuPG, http://www.gnupg.org/ , which already includes zlib compression.
    For PKZIP compatible "encryption", look at http://www.info-zip.org/

38. What's the difference between the "gzip" and "deflate" HTTP 1.1 encodings?

    "gzip" is the gzip format, and "deflate" is the zlib format. They should
    probably have called the second one "zlib" instead to avoid confusion
    with the raw deflate compressed data format. While the HTTP 1.1 RFC 2616
    correctly points to the zlib specification in RFC 1950 for the "deflate"
    transfer encoding, there have been reports of servers and browsers that
    incorrectly produce or expect raw deflate data per the deflate
    specficiation in RFC 1951, most notably Microsoft. So even though the
    "deflate" transfer encoding using the zlib format would be the more
    efficient approach (and in fact exactly what the zlib format was designed
    for), using the "gzip" transfer encoding is probably more reliable due to
    an unfortunate choice of name on the part of the HTTP 1.1 authors.

    Bottom line: use the gzip format for HTTP 1.1 encoding.

39. Does zlib support the new "Deflate64" format introduced by PKWare?

    No. PKWare has apparently decided to keep that format proprietary, since
    they have not documented it as they have previous compression formats.
    In any case, the compression improvements are so modest compared to other
    more modern approaches, that it's not worth the effort to implement.

40. Can you please sign these lengthy legal documents and fax them back to us
    so that we can use your software in our product?

    No. Go away. Shoo.