pax_global_header00006660000000000000000000000064144516413220014514gustar00rootroot0000000000000052 comment=2c5ca63a4590f5328a5c42968f3d5eeeb7d314fb Zipios-2.3.2/000077500000000000000000000000001445164132200127755ustar00rootroot00000000000000Zipios-2.3.2/.gitignore000066400000000000000000000000641445164132200147650ustar00rootroot00000000000000tmp *~ *.sw? /.idea/ /cmake-build-*/ seed.txt tree* Zipios-2.3.2/AUTHORS000066400000000000000000000021411445164132200140430ustar00rootroot00000000000000Emeritus main author: Thomas Sondergaard (thomass@deltadata.dk) FreeBSD port maintainer: Ying-Chieh Liao (ijliao@csie.nctu.edu.tw) Conversion to c++11: Alexis Wilke (alexis@m2osw.com) General management stuff: Russel Winder (russel@winder.org.uk) The files zipios++/directory.h and zipios++/directory.cpp originate from the dir_it library written by Dietmar Kuehl (it's available for download at http://www.boost.org) contrib/zipios++.spec.in contributed by Rui Miguel Silva Seabra libtool/shared library patch contributed by Arkadiusz Miskiewicz (arekm) Russel Winder (was r.winder@180sw.com, now russel@winder.org.uk) did the work of amending the code so as to work with GCC 3.2.1. Ross Burton (was r.burton@180sw.com, now ...) transformed zipios++.spec into zipios++.spec.in and made it more RedHat tradition conformant. Mark Donszelmann (Mark.Donszelmann@slac.stanford.edu) added gzipoutputstream and made several fixes for Visual C++ 6.0 and 7.0. Alexis Wilke converted version 1.x to 2.x and made it C++11 compatible. The API changed fairly heavily to comply with newer C++ versions. Zipios-2.3.2/CMakeLists.txt000066400000000000000000000211011445164132200155300ustar00rootroot00000000000000# Zipios -- a small C++ library that provides easy access to .zip files. # Copyright (C) 2000-2007 Thomas Sondergaard # Copyright (c) 2015-2022 Made to Order Software Corp. All Rights Reserved # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either # version 2.1 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public License # along with this library; if not, write to the Free Software Foundation, # Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA cmake_minimum_required(VERSION 3.10.2) project(zipios_project) option(RUN_TESTS "Enable CTest support and turn on the 'test' make target." OFF) if(${RUN_TESTS}) enable_testing() endif() # See `dev/version` set( ZIPIOS_VERSION_MAJOR 2 ) set( ZIPIOS_VERSION_MINOR 3 ) set( ZIPIOS_VERSION_PATCH 2 ) set( ZIPIOS_VERSION_BUILD 0 ) set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake" ${CMAKE_MODULE_PATH}) if(MSVC) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_WARNINGS") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DNOMINMAX -D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_WARNINGS") add_definitions(-DZIPIOS_WINDOWS) else() if(BORLAND) message(FATAL_ERROR "Borland compiler not supported!") endif() # SUNOS is not set by cmake string(REGEX MATCH "SunOS" SUNOS ${CMAKE_SYSTEM_NAME}) set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fwrapv -fPIC" ) set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -Werror -Wall -Wextra -Wunused-parameter") set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} -O3" ) # if(CYGWIN) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=gnu++17") else() set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC") endif() set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -g -O0 -fdiagnostics-show-option -Werror -Wall -Wextra -pedantic -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wdisabled-optimization -Winit-self -Wlogical-op -Wmissing-include-dirs -Woverloaded-virtual -Wredundant-decls -Wshadow -Wsign-promo -Wstrict-null-sentinel -Wstrict-overflow=4 -Wundef -Wno-unused -Wunused-variable -Wno-variadic-macros -Wno-parentheses -Wno-unknown-pragmas -Wwrite-strings -Wswitch -Wunused-parameter -Wfloat-equal -Wold-style-cast -Wnoexcept") set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -O3") endif() option(BUILD_SHARED_LIBS "Build the ${PROJECT_NAME} libraries shared." ON) if(BUILD_SHARED_LIBS) set(ZIPIOS_LIBRARY_TYPE SHARED) else(BUILD_SHARED_LIBS) set(ZIPIOS_LIBRARY_TYPE STATIC) endif(BUILD_SHARED_LIBS) option(BUILD_DOCUMENTATION "Build the ${PROJECT_NAME} documentation." ON) # To generate coverage, use -D_COVERAGE=ON # and -DCMAKE_BUILD_TYPE=Debug option(${PROJECT_NAME}_COVERAGE "Turn on coverage for ${PROJECT_NAME}." OFF) if(${${PROJECT_NAME}_COVERAGE}) if(MSVC) message(FATAL_ERROR "Coverage is not available on this platform (yet).") endif() message("*** COVERAGE TURNED ON ***") find_program(COV gcov) if(${COV} STREQUAL "COV-NOTFOUND") message(FATAL_ERROR "Coverage requested, but gcov not installed!") endif() if(NOT ${CMAKE_BUILD_TYPE} STREQUAL "Debug") message(FATAL_ERROR "Coverage requested, but Debug is not turned on! (i.e. -DCMAKE_BUILD_TYPE=Debug)") endif() # set(COV_C_FLAGS "-fprofile-arcs -ftest-coverage") set(COV_CXX_FLAGS "-fprofile-arcs -ftest-coverage") set(COV_SHARED_LINKER_FLAGS "-fprofile-arcs -ftest-coverage") set(COV_EXE_LINKER_FLAGS "-fprofile-arcs -ftest-coverage") # set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${COV_C_FLAGS}" ) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${COV_CXX_FLAGS}" ) set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} ${COV_SHARED_LINKER_FLAGS}") set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${COV_EXE_LINKER_FLAGS}" ) endif() # # Default install locations, override cache variables to change. # include(GNUInstallDirs) set(BIN_INSTALL_DIR ${CMAKE_INSTALL_BINDIR} CACHE PATH "Location to install binaries relative to the install prefix." ) set(INCLUDE_INSTALL_DIR ${CMAKE_INSTALL_INCLUDEDIR} CACHE PATH "Location to install headers relative to the install prefix." ) set(LIB_INSTALL_DIR ${CMAKE_INSTALL_LIBDIR} CACHE PATH "Location to install libraries relative to the install prefix." ) set(DATA_INSTALL_DIR ${CMAKE_INSTALL_DATADIR} CACHE PATH "Location to install data files relative to the install prefix." ) #set(CMAKE_MODULES_INSTALL_DIR ${CMAKE_INSTALL_CMAKEMODULESDIR} CACHE PATH "Location to install data files relative to the install prefix." ) find_package(ZLIB REQUIRED) configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/zipios/zipios-config.hpp.in ${CMAKE_CURRENT_BINARY_DIR}/zipios/zipios-config.hpp ) # Generate the RPM package specification file set(PACKAGE "libzipios") configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/contrib/zipios.spec.in ${CMAKE_CURRENT_BINARY_DIR}/contrib/zipios.spec ) configure_file( ${CMAKE_CURRENT_SOURCE_DIR}/contrib/zipios.metainfo.xml.in ${CMAKE_CURRENT_BINARY_DIR}/contrib/zipios.metainfo.xml ) include_directories( ${CMAKE_SOURCE_DIR} ${CMAKE_BINARY_DIR} ) add_subdirectory(cmake) add_subdirectory(src ) add_subdirectory(tools) add_subdirectory(tests) add_subdirectory(doc ) install( DIRECTORY zipios DESTINATION ${INCLUDE_INSTALL_DIR} PATTERN "*.in" EXCLUDE ) install( FILES ${CMAKE_BINARY_DIR}/zipios/zipios-config.hpp DESTINATION ${INCLUDE_INSTALL_DIR}/zipios ) if(${CMAKE_SYSTEM_NAME} MATCHES "Linux") install( FILES ${CMAKE_CURRENT_BINARY_DIR}/contrib/zipios.metainfo.xml DESTINATION ${DATA_INSTALL_DIR}/metainfo ) endif() # todo: how do we determine the correct destination? # (i.e. 3.x is now out and 2.8 will probably fail for those users) #install( DIRECTORY cmake/ # DESTINATION ${CMAKE_MODULES_INSTALL_DIR} #) add_custom_target(zipios_code_analysis # Make sure we have an output folder COMMAND mkdir -p ${PROJECT_BINARY_DIR}/analysis # Count the number of TODO, XXX, TBD, FIXME, and \todo COMMAND echo "TODO -- output ${PROJECT_BINARY_DIR}/analysis/todo.txt" COMMAND sh dev/todo.sh "${PROJECT_BINARY_DIR}/analysis" # Search for files with "invalid" (unwanted really) spaces COMMAND echo "Spaces -- output ${PROJECT_BINARY_DIR}/analysis/spaces.txt" COMMAND sh dev/spaces.sh "${PROJECT_BINARY_DIR}/analysis" # Boost inspect tool that reports various problems in the source # Note: I use `... || true` because inspect attempts an SVN check which # obviously is going to fail here COMMAND echo "inspect -- output ${PROJECT_BINARY_DIR}/analysis/inspect.html" COMMAND inspect -tab -crlf -end -path_name -ascii -minmax -assert_macro -deprecated_macro -unnamed -copyright >"${PROJECT_BINARY_DIR}/analysis/inspect.html" || true # All of these are expected to work on source code so make sure we are # in the source code top directory WORKING_DIRECTORY ${PROJECT_SOURCE_DIR} ) ## ## To pack the source ## set(CPACK_PACKAGE_NAME "zipios") set(CPACK_PACKAGE_DESCRIPTION_SUMMARY "Zipios is a small C++ library for reading and writing zip files.") set(CPACK_PACKAGE_VENDOR "Made to Order Software Corporation") set(CPACK_PACKAGE_CONTACT "alexis@m2osw.com") set(CPACK_RESOURCE_FILE_LICENSE "${zipios_project_SOURCE_DIR}/COPYING") set(CPACK_SOURCE_GENERATOR "TGZ") set(CPACK_SOURCE_IGNORE_FILES "/CVS/;/work-files/;/.git/;.swp$;.*~;cscope.*;/tmp/;BUILD;Build") set(CPACK_PACKAGE_VERSION "${ZIPIOS_VERSION_MAJOR}.${ZIPIOS_VERSION_MINOR}.${ZIPIOS_VERSION_PATCH}") set(CPACK_PACKAGE_VERSION_MAJOR "${ZIPIOS_VERSION_MAJOR}") set(CPACK_PACKAGE_VERSION_MINOR "${ZIPIOS_VERSION_MINOR}") set(CPACK_PACKAGE_VERSION_PATCH "${ZIPIOS_VERSION_PATCH}") set(CPACK_SOURCE_PACKAGE_FILE_NAME "zipios-${ZIPIOS_VERSION_MAJOR}.${ZIPIOS_VERSION_MINOR}.${ZIPIOS_VERSION_PATCH}") include(CPack) # Local Variables: # indent-tabs-mode: nil # tab-width: 4 # End: # vim: ts=4 sw=4 et nocindent Zipios-2.3.2/COPYING000066400000000000000000000575061445164132200140450ustar00rootroot00000000000000 GNU LESSER GENERAL PUBLIC LICENSE Version 2.1, February 1999 Copyright (C) 1991, 1999 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. [This is the first released version of the Lesser GPL. It also counts as the successor of the GNU Library Public License, version 2, hence the version number 2.1.] Preamble The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public Licenses are intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This license, the Lesser General Public License, applies to some specially designated software packages--typically libraries--of the Free Software Foundation and other authors who decide to use it. You can use it too, but we suggest you first think carefully about whether this license or the ordinary General Public License is the better strategy to use in any particular case, based on the explanations below. When we speak of free software, we are referring to freedom of use, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish); that you receive source code or can get it if you want it; that you can change the software and use pieces of it in new free programs; and that you are informed that you can do these things. To protect your rights, we need to make restrictions that forbid distributors to deny you these rights or to ask you to surrender these rights. These restrictions translate to certain responsibilities for you if you distribute copies of the library or if you modify it. For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. We protect your rights with a two-step method: (1) we copyright the library, and (2) we offer you this license, which gives you legal permission to copy, distribute and/or modify the library. To protect each distributor, we want to make it very clear that there is no warranty for the free library. Also, if the library is modified by someone else and passed on, the recipients should know that what they have is not the original version, so that the original author's reputation will not be affected by problems that might be introduced by others. Finally, software patents pose a constant threat to the existence of any free program. We wish to make sure that a company cannot effectively restrict the users of a free program by obtaining a restrictive license from a patent holder. Therefore, we insist that any patent license obtained for a version of the library must be consistent with the full freedom of use specified in this license. Most GNU software, including some libraries, is covered by the ordinary GNU General Public License. This license, the GNU Lesser General Public License, applies to certain designated libraries, and is quite different from the ordinary General Public License. We use this license for certain libraries in order to permit linking those libraries into non-free programs. When a program is linked with a library, whether statically or using a shared library, the combination of the two is legally speaking a combined work, a derivative of the original library. The ordinary General Public License therefore permits such linking only if the entire combination fits its criteria of freedom. The Lesser General Public License permits more lax criteria for linking other code with the library. We call this license the "Lesser" General Public License because it does Less to protect the user's freedom than the ordinary General Public License. It also provides other free software developers Less of an advantage over competing non-free programs. These disadvantages are the reason we use the ordinary General Public License for many libraries. However, the Lesser license provides advantages in certain special circumstances. For example, on rare occasions, there may be a special need to encourage the widest possible use of a certain library, so that it becomes a de-facto standard. To achieve this, non-free programs must be allowed to use the library. A more frequent case is that a free library does the same job as widely used non-free libraries. In this case, there is little to gain by limiting the free library to free software only, so we use the Lesser General Public License. In other cases, permission to use a particular library in non-free programs enables a greater number of people to use a large body of free software. For example, permission to use the GNU C Library in non-free programs enables many more people to use the whole GNU operating system, as well as its variant, the GNU/Linux operating system. Although the Lesser General Public License is Less protective of the users' freedom, it does ensure that the user of a program that is linked with the Library has the freedom and the wherewithal to run that program using a modified version of the Library. The precise terms and conditions for copying, distribution and modification follow. Pay close attention to the difference between a "work based on the library" and a "work that uses the library". The former contains code derived from the library, whereas the latter must be combined with the library in order to run. GNU LESSER GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. This License Agreement applies to any software library or other program which contains a notice placed by the copyright holder or other authorized party saying it may be distributed under the terms of this Lesser General Public License (also called "this License"). Each licensee is addressed as "you". A "library" means a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables. The "Library", below, refers to any such software library or work which has been distributed under these terms. A "work based on the Library" means either the Library or any derivative work under copyright law: that is to say, a work containing the Library or a portion of it, either verbatim or with modifications and/or translated straightforwardly into another language. (Hereinafter, translation is included without limitation in the term "modification".) "Source code" for a work means the preferred form of the work for making modifications to it. For a library, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running a program using the Library is not restricted, and output from such a program is covered only if its contents constitute a work based on the Library (independent of the use of the Library in a tool for writing it). Whether that is true depends on what the Library does and what the program that uses the Library does. 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. d) If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful. (For example, a function in a library to compute square roots has a purpose that is entirely well-defined independent of the application. Therefore, Subsection 2d requires that any application-supplied function or table used by this function must be optional: if the application does not supply it, the square root function must still compute square roots.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Library. In addition, mere aggregation of another work not based on the Library with the Library (or with a work based on the Library) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. 4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange. If distribution of object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place satisfies the requirement to distribute the source code, even though third parties are not compelled to copy the source along with the object code. 5. A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License. However, linking a "work that uses the Library" with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a "work that uses the library". The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library. The threshold for this to be true is not precisely defined by law. If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work. (Executables containing this object code plus portions of the Library will still fall under Section 6.) Otherwise, if the work is a derivative of the Library, you may distribute the object code for the work under the terms of Section 6. Any executables containing that work also fall under Section 6, whether or not they are linked directly with the Library itself. 6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things: a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.) b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution. d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy. For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. 7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things: a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above. b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work. 8. You may not copy, modify, sublicense, link with, or distribute the Library except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, link with, or distribute the Library is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 9. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Library or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Library (or any work based on the Library), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Library or works based on it. 10. Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License. 11. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply, and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 12. If the distribution and/or use of the Library is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Library under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 13. The Free Software Foundation may publish revised and/or new versions of the Lesser General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Library specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Library does not specify a license version number, you may choose any version ever published by the Free Software Foundation. 14. If you wish to incorporate parts of the Library into other free programs whose distribution conditions are incompatible with these, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS Zipios-2.3.2/NEWS000066400000000000000000000072421445164132200135010ustar00rootroot00000000000000Release notes for Zipios 2.2.0 -------------------------------- As per [issue #28 on Github](https://github.com/Zipios/Zipios/issues/28), there was a discrepancy in licenses because of the dostime.c and dostime.h files. These two files were removed and replaced by a DOSDateTime class instead. It's all C++ and uses a structure with field to convert the data as required. The license was also updated and copyright file fixed up to match the newer version. Release notes for Zipios 2.1.0 -------------------------------- Moving the header files from /usr/include/zipios++ to /usr/include/zipios which is a more conventional name for a directory. Various fixes such as copyright notices, zipios_tool renamed, manual pages. Release notes for Zipios 2.0.0 -------------------------------- This new release is a big change to make use of modern C++ (c++11 for now) and fix a certain number of bugs in the library. Release notes for Zipios++ 0.1.6 -------------------------------- (PARTIALLY DONE) Test suite converted to CppUnit. (NOT DONE YET) Many more unit tests. RPMs building (donated by Rui Miguel Silva Seabra). Shared library support (donated by Arkadiusz Miskiewicz). (NOT DONE YET) Better Windows support. (NOT DONE YET) Windows installer. HEAD of CVS ----------- New features: - Added gzipoutputstream to write .gz files. - Current time and date written in ZipEntry, so winzip 8.0 does not complain about the written zip files. - Makefiles up to date for Visual C++ 6 - Correction added for Visual C++ 7.1 - Further support for CppUnit. - Makefile.vc5 renamed to Makefile.vc API changes: - ZipInputStream::getNextEntry() must be called before accessing first entry Release notes for Zipios++ 0.1.5 -------------------------------- New features: - Support for Visual C++ 6 - VFS feature finished - Support for writing zip archives (pre-beta!) Bug fixes: - Code reorganized and many minor bug fixes Changes: - flex/lex is no longer required Release notes for Zipios++ 0.1.4 -------------------------------- Bug fixes: - A bug in a code fragment used in all the test programs for copying data from an istream to an ostream has been fixed - A nasty and embarrassing bug in ZipInputStreambuf and InflateInputStreambuf that prevented zip entries containing the character 255 from being correctly decompressed has been fixed Release notes for Zipios++ 0.1.3 -------------------------------- Changes: - Changed the license to GNU Lesser General Public License Release notes for Zipios++ 0.1.2 -------------------------------- New features: - ZipFile can now be used to read zip files embedded in other files. The static method ZipFile::openEmbeddedZipFile() can be used to open zip files embedded in another file with the binary appendzip, which is also part of the Zipios++ distribution Bug fixes: Installation: - Header files are now installed (under (usr/include/)zipios++/) - The library libzipios.a is now installed - The test binaries are no longer installed - Renamed config.h to zipios-config.h to avoid file name collisions Building: - Added a switch --with-std-compliant-iostream (and --without-...) to the configure script, such that the library can be build against the old iostream.h library, even if a newer std compliant iostream implementation is available in iostream Source: - Most functions now throw exceptions (reflected in the documentation) instead of printing error messages to stderr - Fixes to make the library compile and work with gcc 2.95.2 Missing features and known bugs: - DirectoryCollection::entries() end DirectoryCollection::size() are not implemented yet Zipios-2.3.2/README.md000066400000000000000000000135221445164132200142570ustar00rootroot00000000000000# Introduction Zipios is a small C++ library for reading and writing zip files. The structure and public interface are based (somewhat loosely) on the `java.util.zip` package. The streams created to access the individual entries in a zip file are based on the standard iostream library. Zipios also provides a way for an application to support files from multiple sources (e.g. from zip files or from ordinary directories) transparently. The source code is released under the GNU Lesser General Public License (LGPL). # Important Note I renamed the root branch as "main" instead of "master". If you created a fork or wanted to clone the project, make sure to use "main" now. # Dependencies Requires **zlib** ([https://zlib.net](https://zlib.net/)). # Debian/Ubuntu sudo apt-get install zlib-dev # Fedora/RPM based systems sudo dnf install zlib-devel To run the automatic unit test suite you need **Catch** ([https://github.com/catchorg/Catch2](https://github.com/catchorg/Catch2)) # Debian/Ubuntu sudo apt-get install catch # Fedora/RPM based systems sudo dnf install catch-devel The tests also require the *zip* command line tool. # Debian/Ubuntu sudo apt-get install zip # Fedora/RPM based systems sudo dnf install zip To build the projects, we use a C++ compiler (tested with **g++** and **clang**) as well as **cmake**. # Debian/Ubuntu sudo apt-get install g++ sudo apt-get install cmake # Fedora/RPM based systems sudo dnf install gcc-c++ sudo dnf install cmake By default, the CMakeLists.txt knows to skip building the documentation. This happens if `doxygen` and `graphviz` are not both installed. # Debian/Ubuntu sudo apt-get install doxygen graphviz # Fedora/RPM based systems sudo dnf install doxygen graphviz # Installation This version of the software uses `cmake` to generate the necessary make files or solutions and projects under your operating system. The following options are supported: - `BUILD_SHARED_LIBS` (ON by default) - `BUILD_DOCUMENTATION` (ON by default) - `zipios_project_COVERAGE` (OFF by default) - `BUILD_ZIPIOS_TESTS` (ON by default) In order to build Zipios as a static library, specify: -DBUILD_SHARED_LIBS:BOOL=OFF In order to explicitly disable building Doxygen documentation, specify: -DBUILD_DOCUMENTATION:BOOL=OFF In order to build the library with coverage support, use the coverage option and make sure to compile in Debug mode too: -Dzipios_project_COVERAGE=ON -DCMAKE_BUILD_TYPE=Debug By default tests get built if catch.hpp is available. However, you may have catch.hpp installed on your system but want to skip on building the tests (i.e. nightly build). In that case you may turn them off with: -DBUILD_ZIPIOS_TESTS:BOOL=OFF ## Unix Once you have `cmake` installed, you should be able to run the following under Unix: tar xf zipios.tar.gz mkdir BUILD cd BUILD cmake ../zipios make make install _(See the `zipios/dev/build` script for an example script.)_ The project comes with a build script (see `dev/build`) that can be used to run those steps. It will assume that you do not mind to have your `BUILD` directory blown away and rebuilds everything. It also may setup various flags on the command line to build the `DEBUG` version, for example. If you make changes to the source tree, you may re-run the make from the source tree with something like: make -C ../BUILD For details about available installation configurations of cmake packages refer to the CMake documentation online [https://cmake.org/](https://cmake.org/) By default, `make install` installs the Zipios 2.1+ header files under `/usr/include/zipios/` and the library `libzipios.so` under `/usr/lib/`. You can choose another base path than `/usr/` using the following option on the `cmake` command line: -DCMAKE_INSTALL_PREFIX=/home/alexis/zipios The build script actually installs everything under `BUILD/dist` so one can verify the results and package them before shipping. Running `make` also builds one test program. It can be found in the tests directory in your `BUILD` folder. It is one program that actually runs many tests. (It is possible to run one test at a time, see the script under `dev/check` for an example.) ## Windows _**Note:** at the moment we do not support the MS-Windows version. If you have a working version, we can try to incorporate your changes as long as they follow our coding style closely enough._ CMake comes with a graphical tool one can use under MS-Windows to configure and generate a project supporting cmake. You will find more information about cmake on their official website [https://cmake.org/](https://cmake.org). The output of CMake can be projects and a solution for Visual Studio C++ or a set of `nmake` files. cmake also supports other formats such as JOM. Once the cmake output was generated, you can run your build tools and then run the `INSTALL` target. That will install the binary files in one place. It is strongly advise that your define the `CMAKE_INSTALL_PREFIX` variable before you install anything. # Status and Documentation Please refer to the online documentation at [https://zipios.sourceforge.io](https://zipios.sourceforge.io) At this time, we generate the HTML and Latex version of the documentation. It is pretty big, but we'll do our best to offer a .tar.gz of the documentation on SourceForge.io each time we offer a new version of the library. If you have Doxygen installed, then the documentation will automatically be generated. Note that under MS-Windows you may have to specify a path for cmake to find Doxygen and properly generate the output. The setup makes use of dot to generate images showing relationships between classes and files. # Bugs Submit bug reports and patches via [https://github.com/Zipios/Zipios/issues](https://github.com/Zipios/Zipios/issues) Zipios-2.3.2/TODO.md000066400000000000000000000010411445164132200140600ustar00rootroot00000000000000 A few things that contributors can definitively help with: * Find a way to keep the CMakeList.txt version in sync. with the changelog. * Prevent use of ".." in the path of a file added to the zip file. * Update the contrib/zipios++.spec.in so it works with 2.0. * Help with getting the project to work under MS-Windows. * Implement a ZipExtra class to handle the extra buffer. * Implement a VirtualEntry to allow in-memory files. * Add a test for the cmake/FindZipIos.cmake code. * Implement the necessary to support 64 bit zipfiles. Zipios-2.3.2/cmake/000077500000000000000000000000001445164132200140555ustar00rootroot00000000000000Zipios-2.3.2/cmake/CMakeLists.txt000066400000000000000000000020041445164132200166110ustar00rootroot00000000000000# Zipios -- a small C++ library that provides easy access to .zip files. # Copyright (c) 2015-2022 Made to Order Software Corp. All Rights Reserved # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either # version 2.1 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public # License along with this library; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA project(zipios2_cmake) install( FILES ZipIosConfig.cmake DESTINATION share/cmake/ZipIos ) # vim: ts=4 sw=4 et nocindent Zipios-2.3.2/cmake/FindCatch.cmake000066400000000000000000000000001445164132200166700ustar00rootroot00000000000000Zipios-2.3.2/cmake/ZipIosConfig.cmake000066400000000000000000000036511445164132200174270ustar00rootroot00000000000000# - Try to find the Zipios (libzipios.so) # # Once done this will define # # ZIPIOSCC_FOUND - System has Zipios # ZIPIOSCC_INCLUDE_DIR - The zipios include directories # ZIPIOSCC_LIBRARY - The libraries needed to use Zipios (none) # ZIPIOSCC_DEFINITIONS - Compiler switches required for using Zipios (none) # # License: # Zipios -- a small C++ library that provides easy access to .zip files. # Copyright (c) 2015-2022 Made to Order Software Corp. All Rights Reserved # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either # version 2.1 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public # License along with this library; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA # find_path( ZIPIOSCC_INCLUDE_DIR zipios/zipfile.hpp HINTS $ENV{ZIPIOSCC_INCLUDE_DIR} PATH_SUFFIXES zipios ) find_library( ZIPIOSCC_LIBRARY zipios HINTS $ENV{ZIPIOSCC_LIBRARY} ) mark_as_advanced( ZIPIOSCC_INCLUDE_DIR ZIPIOSCC_LIBRARY ) set( ZIPIOSCC_INCLUDE_DIRS ${ZIPIOSCC_INCLUDE_DIR} ) set( ZIPIOSCC_LIBRARIES ${ZIPIOSCC_LIBRARY} ) include( FindPackageHandleStandardArgs ) # handle the QUIETLY and REQUIRED arguments and set ZIPIOSCC_FOUND to TRUE # if all listed variables are TRUE find_package_handle_standard_args( ZipIos DEFAULT_MSG ZIPIOSCC_INCLUDE_DIR ZIPIOSCC_LIBRARY ) # vim: ts=4 sw=4 et Zipios-2.3.2/contrib/000077500000000000000000000000001445164132200144355ustar00rootroot00000000000000Zipios-2.3.2/contrib/zipios.metainfo.xml.in000066400000000000000000000023351445164132200207050ustar00rootroot00000000000000 zipios Zipios Small C++ library for reading and writing zip files

Zipios is a small C++ library for reading and writing zip files. The structure and public interface are based (somewhat loosely) on the java.util.zip package. The streams created to access the individual entries in a zip file are based on the standard iostream library.

Zipios also provides a way for an application to support files from multiple sources (e.g. from zip files or from ordinary directories) transparently.

 CC0-1.0 LGPL-2.1-or-later alexis_AT_m2osw.com https://snapwebsites.org/project/zipios https://github.com/Zipios/Zipios/issues http://zipios.sourceforge.net libzipios.so.@ZIPIOS_VERSION_MAJOR@.@ZIPIOS_VERSION_MINOR@ appendzip dostime zipios Zipios-2.3.2/contrib/zipios.spec.in000066400000000000000000000041151445164132200172340ustar00rootroot00000000000000%define release 2 Name: @PACKAGE@ Version: @ZIPIOS_VERSION_MAJOR@.@ZIPIOS_VERSION_MINOR@.@ZIPIOS_VERSION_PATCH@ Summary: Zipios is a small C++ library for reading zip files Release: %{release} Source: %{name}-%{version}.tar.gz Group: Development/Libraries URL: http://zipios.sourceforge.net./ BuildRoot: %{_tmppath}/%{name}-%{version}-buildroot License: GNU LGPL Prefix: %{_prefix} Packager: "Thomas Sondergaard" Distribution: RedHat 9 Contrib %description Zipios is a small C++ library for reading zip files. The structure and public interface are based (somewhat loosely) on the java.util.zip package. The streams created to access the individual entries in a zip file are based on the standard iostream library. Zipios also provides a way for an application to support files from multiple sources (e.g. from zip files or from ordinary directories) transparently. %package devel Summary: Zipios header files Group: Development/Libraries Requires: %name = %version %description devel Header files and documentation for Zipios development. %prep %__rm -rf $RPM_BUILD_ROOT %setup -q -n %{name}-%{version} %build %configure %__make all doc %install %makeinstall %post -p /sbin/ldconfig %postun -p /sbin/ldconfig %clean [ -n "$RPM_BUILD_ROOT" -a "$RPM_BUILD_ROOT" != / ] && %__rm -rf $RPM_BUILD_ROOT $RPM_BUILD_DIR/%{name}-%{version} %files %defattr(-,root,root,644) %doc AUTHORS README %attr(755,root,root) %{_libdir}/libzipios.so.* %files devel %defattr(-,root,root,644) %{_includedir}/zipios/*.h %doc NEWS ChangeLog %doc %dir doc/html/ %defattr(-,root,root,755) %{_libdir}/libzipios.a %{_libdir}/libzipios.so %{_libdir}/libzipios.la %changelog * Tue May 5 2015 Alexis Wilke - Updated the zipios include file directory name. * Tue Feb 3 2004 Russel Winder - Updated spec file to tidy up properly after a run. Removed use of /usr/local/bin/g++ for compilation in favour of using default. * Tue Jan 7 2003 Ross Burton - Updated spec file to use the RPM macros * Sat Mar 17 2002 Rui M. Silva Seabra - Creation Zipios-2.3.2/debian/000077500000000000000000000000001445164132200142175ustar00rootroot00000000000000Zipios-2.3.2/debian/changelog000066400000000000000000000410531445164132200160740ustar00rootroot00000000000000zipios (2.3.2.0~jammy) jammy; urgency=high * Added support for an std::istream when creating a ZipFile object. * Added support for a StreamEntry when creating a zip file. * Added support -v (verbose) to the ./mk script. * Fixed two `operator = ()` which improperly returned a `const &`. * Replaced additional `new` with `std::make_shared/unique<>()`. * Really auto-init `m_zs`. * Use RAII for all files and directories in the tests. * Fixed test verifying DOS timestamps with +/- 1 hour (ugly but it works). * Bumped version in CMakeLists.txt. * Added the --source-path to the zipios_tests call in mk. * Added the zipdir tool to test creating zip files on the command line. * Removed the -std=c++17 option. I don't need it and it's better without. * Implemented the big endian version of the dosdatetime_convert_t union. * Enhanced a zipfile test which was not testing the output except the CRC32. * Fixed a bug when copying empty files, it would prevent further copying. * Fixed the CRC32 computation. It was not reset between file entries. * Added the snapcatch2 dependency to the control file. * Updated the test main() function to use the snapcatch2 helps. * Added a safe_dir implementation and make sure to cd to the tmp folder. * Enhanced the test of the version (CMakeLists.txt & debian/changelog equal). * Added a test of the library versus test versions. * Fixed loop in the tests where the maximum value changed on each iteration. * Many clean ups. -- Alexis Wilke Wed, 28 Sep 2022 15:35:45 -0700 zipios (2.3.1.1~bionic) bionic; urgency=high * Updated the compat to v10. * Clean up of CMakeLists.txt files. -- Alexis Wilke Mon, 11 Jul 2022 06:46:25 -0700 zipios (2.3.1.0~bionic) bionic; urgency=high * Updated the tests to work with SnapCatch2 v3. -- Alexis Wilke Mon, 31 Jan 2022 18:14:26 -0800 zipios (2.3.0.0~bionic) bionic; urgency=high * Added the clear() and empty() functions to the FilePath class. * Correctly clear the m_checked flag on a change of the FilePath. * Fixed a logical or (`||` instead of `|`). * Use clear() instead of setting string to "". * Replaced many `new ...` with `std::make_shared<>()`. * Fixed a few comments (spelling/grammar, missing/invalid info.). * Fixed missing CRC32 computation as presented in #38. * Added a new test to make sure issue #38 was fixed. * Added a function to compute CRC32 of local disk files. * Made tests delete files upfront too (in case it breaks part way). * Fixed path to BUILD folder in ./mk script. * Added a test for the version (CMakelists.txt vs debian/changelog). * Bumped copyright notice date to 2021. -- Alexis Wilke Tue, 03 Nov 2020 07:16:34 -0800 zipios (2.2.6.0~xenial) xenial; urgency=high * Applied a few fixes to avoid some warnings when compiling in 32 bits. * Commented out tests which verify dates outside of the 32 bit range (i.e. time_t is a 32 bit signed integer on a 32 bit OS). * Fixed the docs Bugs and Links and Issue Sections. * Removed some ++ from Zipios because the name changed and we removed the ++. * Applied most of pull request 30, added the metainfo.xml file. * Applied pull request 34 (https://github.com/Zipios/Zipios/pull/34) (remove path from all filenames) -- Alexis Wilke Tue, 15 Sep 2020 14:40:28 -0700 zipios (2.2.5.0~xenial) xenial; urgency=high * Applied pull request 31 (https://github.com/Zipios/Zipios/pull/31) (corrections to comments as in spelling/grammar errors) -- Alexis Wilke Fri, 16 Aug 2019 17:12:28 -0800 zipios (2.2.4.0~xenial) xenial; urgency=high * Applied fix to some tests so they compile with g++ 8.3.x -- Alexis Wilke Fri, 19 Jul 2019 16:08:48 -0800 zipios (2.2.3.0~xenial) xenial; urgency=high * Added in=C++ to the MAPPING_EXTENSION. * Updated the doxy file to 1.8.11. * Removed one more UTF-8 emdash character. * Made a few changes in link with the website and CVE-2019-13453 in the old zipios library. * Added a favicon for the website. -- Alexis Wilke Tue, 11 Jun 2019 23:58:58 -0800 zipios (2.2.2.0~xenial) xenial; urgency=high * Fixed the FindCatch.cmake, the REQUIRED was not properly tested. -- Alexis Wilke Mon, 10 Jun 2019 16:42:26 -0700 zipios (2.2.1.0~xenial) xenial; urgency=high * Fixed the "DirectoryEntry for a valid directory" test as the FileEntry object saves a Unix timestamp as a time_t and therefore with a full range precision. (#29) -- Alexis Wilke Wed, 24 Apr 2019 13:45:20 -0800 zipios (2.2.0.0~xenial) xenial; urgency=high * Replaced the dostime.h/c with dosdatetime.hpp/cpp to eliminate the GPL dependency. * Updated the tests accordingly. * Fixed the dosdatetime test so it matches the hours properly (I was able to remove the 1h difference test to accomodate standard/saving time periods.) * Made enhancements to the `mk` script so I can use it in zipios or Snap C++. * Updated copyright notices to say 2019. * Fixed the debian/copyright file. * I removed the UTF-8 long dashes and replace them with "--". * I updated the version in the main CMakeFile.txt. * I applied cleanups as detected by the code analyzis tools. -- Alexis Wilke Tue, 9 Apr 2019 19:40:36 -0800 zipios (2.1.7.11~xenial) xenial; urgency=high * Include a fix that allows for catch v2 to be used for our tests. * Fixed version in CMakeLists.txt as well. -- Alexis Wilke Sat, 1 Dec 2018 16:50:51 -0800 zipios (2.1.7.10~xenial) xenial; urgency=high * Bump version to get a recompile on launchpad. -- Alexis Wilke Fri, 27 Jul 2018 00:45:54 -0800 zipios (2.1.7.9~xenial) xenial; urgency=high * Bump version to recompile without the -fsanitizer flags. -- Alexis Wilke Wed, 27 Jun 2018 19:46:10 -0800 zipios (2.1.7.8~xenial) xenial; urgency=high * Bump version to recompile with the -fsanitizer flags. -- Alexis Wilke Tue, 26 Jun 2018 20:03:27 -0800 zipios (2.1.7.7~xenial) xenial; urgency=high * Testing dput from make requires all changelog to have my email address. -- Alexis Wilke Mon, 29 Jan 2018 00:42:44 -0700 zipios (2.1.7.6~xenial) xenial; urgency=high * Fixed packaging to use DEB_HOST_MULTIARCH for library. -- R. Douglas Barbieri Thu, 26 Oct 2017 14:02:00 -0700 zipios (2.1.7.1~xenial) xenial; urgency=high * Packaging: Tests require zip package. * Packaging: Install targets were not correct. * Packaging: Distributing better cmake module in correct area. -- R. Douglas Barbieri Wed, 18 Oct 2017 09:22:57 -0700 zipios (2.1.7.0~xenial) xenial; urgency=high * Packaging now puts all libraries and softlinks in the same folder. -- Doug Barbieri Fri, 23 Jun 2017 18:18:09 -0700 zipios (2.1.6.0~xenial) xenial; urgency=high * SNAP-289: added a couple of try/catch in destructors to avoid potential std::terminate() calls when an error is discovered in a compressed file. -- Alexis Wilke Sun, 19 Mar 2017 22:02:22 -0700 zipios (2.1.5.0~xenial) xenial; urgency=high * Applied fix using lambda for throwing constructors in our tests. (Reference https://github.com/Zipios/Zipios/issues/5) * Updated the README.md to include instructions on how to install each dependency. * Fixed the FindCatch.cmake for Fedora, the catch.hpp is in a sub-folder. -- Alexis Wilke Sun, 19 Feb 2017 22:02:22 -0700 zipios (2.1.4.0~xenial) xenial; urgency=high * Replaced readdir_r() with readdir(). * Removed a throw from a destructor, which g++ now reports with a warning. * Fixed a few more "occurred". * Moved dependencies, one per line. * Fixed position of some vim comments. * Bumped copyright notices to 2017. * Fixed several return false which needed to be return node::pointer_t(). * Fixed a few if(!) which should be != or == nullptr. -- Alexis Wilke Sun, 19 Feb 2017 22:02:22 -0700 zipios (2.1.3.0~xenial) xenial; urgency=high * SNAP-110: Bumped version to get my test system to upgrade properly. -- Alexis Wilke Tue, 13 Sep 2016 11:59:22 -0700 zipios (2.1.1~trusty) trusty; urgency=high * Fixed a couple of classes initializations that were missing. * Fixed a view system() call of which return values were not checked. * Added a BUILD_ZIPIOS_TESTS cmake option flag. * Fixed reference to README as README.md as it is called now. * Allow for ZIPIOS_WINDOWS to compile under MS-Windows. * Added an ssize_t definition for Windows. * Removed the "catch_" prefix from all test names. * Fixed some copyright notices. * Cleaned up the coverage script. * Added the BUILD_SHARED_LIBS and BUILD_DOCUMENTATION options to cmake. * Fixed the FindZipIos.cmake file so it uses the correct names. * Also make the destination directory for FindZipIos.cmake a variable. * Enhanced the installation directory handling in cmake. -- Alexis Wilke Sat, 12 Dec 2015 14:41:42 -0700 zipios (2.1.0~trusty) trusty; urgency=high * Renamed the include directory to remove the '++'. * Renamed the Debian package "zipios". * Added a few scripts to help with publishing a new version of Zipios. * Fixed and added some copyright notices. * Fixed the comments in the cmake/* files. * Fixed name of zipios_tool as just zipios once installed. -- Alexis Wilke Tue, 5 May 2015 14:20:07 -0700 zipios (2.0.2~trusty) trusty; urgency=high * Finished fixing the vim/emacs comments. * Removed some unnecessary code (a try/catch). * Various small fixes to allow FreeBSD to pass all the tests. -- Alexis Wilke Sat, 21 Mar 2015 18:28:33 -0700 zipios (2.0.1~trusty) trusty; urgency=high * Removed the unused tests. * Applied a couple fixes to get cygwin to work as expected. -- Alexis Wilke Sat, 21 Mar 2015 18:28:33 -0700 zipios (2.0.0~trusty) trusty; urgency=high * Moving to the new 2.X version. * Lots of updates and upgrades from Alexis, since he came on as the new lead. * Brand new set of tests with 100% coverage of the core library. -- R. Douglas Barbieri Tue, 3 Mar 2015 08:37:31 -0700 zipios (0.1.5.10m2osw1~saucy) saucy; urgency=high * Added dostime.h/c and new methods that allow for conversion between dostime and unixtime. -- R. Douglas Barbieri Mon, 24 Mar 2014 19:17:19 -0700 zipios (0.1.5.9+cvs.2007.04.28-5.1.m2osw4~saucy) saucy; urgency=high * Control file had the wrong dependency for dev package. -- R. Douglas Barbieri Thu, 20 Mar 2014 09:55:07 -0700 zipios (0.1.5.9+cvs.2007.04.28-5.1.m2osw3~saucy) saucy; urgency=high * Corrected package install specs. * Main package is now renamed. -- R. Douglas Barbieri Thu, 20 Mar 2014 09:18:20 -0700 zipios (0.1.5.9+cvs.2007.04.28-5.1.m2osw2~saucy) saucy; urgency=high * Forgot to include cmake in the build dependencies. -- R. Douglas Barbieri Wed, 19 Mar 2014 19:08:49 -0700 zipios (0.1.5.9+cvs.2007.04.28-5.1.m2osw1~saucy) saucy; urgency=high * Fixed bug with zipfile.cpp, where getNextEntry() is called in the getInputStream() method, which does not need to happen, and in fact, causes the last file in the archive to not be read, and an exception to be thrown. -- R. Douglas Barbieri Wed, 19 Mar 2014 18:28:50 -0700 zipios (0.1.5.9+cvs.2007.04.28-5.1) unstable; urgency=low * Non-maintainer upload. * Fix "zipios++: FTBFS: directory.h:85:12: error: 'ptrdiff_t' does not name a type": apply patch from Ubuntu / Julian Taylor: - debian/patches/03_ptrdiff.dpatch: include cstddef to fix build issue with gcc 4.6 Closes: #625096 LP: #832775 -- gregor herrmann Sat, 08 Oct 2011 14:52:37 +0200 zipios (0.1.5.9+cvs.2007.04.28-5) unstable; urgency=low * Bumped to Standards-Version: 3.8.0. * Use DESTDIR instead of prefix for doc install, thanks Ben Hutchings - closes: #471338 * Better handling of stream reading errors, thanks Fernando Diaz Alonso - closes: #395350 -- Masayuki Hatta (mhatta) Fri, 18 Jul 2008 00:44:54 +0900 zipios (0.1.5.9+cvs.2007.04.28-4) unstable; urgency=low * Added graphicsmagick-imagemagick-compat to Build-Depends. Thanks to Anibal Avelar - closes: #456349 -- Masayuki Hatta (mhatta) Wed, 02 Jan 2008 23:35:44 +0900 zipios (0.1.5.9+cvs.2007.04.28-3) unstable; urgency=low * Bumped to Standards-Version: 3.7.3. * Fixed various lintian warnings. * Now provides libzipios++-doc and manpages in libzipios++-dev - closes: #288863 -- Masayuki Hatta (mhatta) Sun, 09 Dec 2007 06:33:47 +0900 zipios (0.1.5.9+cvs.2007.04.28-2) unstable; urgency=low * Fix for amd64 in -1 was incomplete. Now fixed. * src/zipinputstreambuf.cpp : Backported from the previous revision. The changes made in the upstream breaks enigma's score reading - closes: #421498 -- Masayuki Hatta (mhatta) Mon, 30 Apr 2007 10:21:50 +0900 zipios (0.1.5.9+cvs.2007.04.28-1) unstable; urgency=low * New upstream release (CVS snapshot). * Acknowledged NMU - closes: #372679 * libzipios++-dev now depends on libz-dev - closes: #358721 * Fixed build issue for forthcoming GCC 4.3 - closes: #417788 * Fixed FSF's address. -- Masayuki Hatta (mhatta) Sat, 28 Apr 2007 02:11:43 +0900 zipios (0.1.5.9+cvs.2004.02.07-3.4) unstable; urgency=high * Non-maintainer upload. * Ship an empty zipios-config.h, since it isn't good to have stuff like HAVE_ macros or (more importantly) PACKAGE and VERSION leak into other package's namespaces. Instead, the few #ifdefs in the headers that actually used these macros have been resolved manually in the source, as they are consistent across all Debian systems and not likely to change in the near future. (Closes: #363173) -- Steinar H. Gunderson Sun, 11 Jun 2006 00:46:57 +0200 zipios (0.1.5.9+cvs.2004.02.07-3.3) unstable; urgency=high * Non-maintainer upload. * Rename to libzipios++0c2a for libstdc++ allocator change (Closes: #339280). -- Luk Claes Mon, 2 Jan 2006 19:26:45 +0100 zipios (0.1.5.9+cvs.2004.02.07-3.2) unstable; urgency=medium * Non-maintainer upload. * Build depend on libcppunit-dev. (Closes: #288819). -- Luk Claes Mon, 17 Oct 2005 17:56:52 +0200 zipios (0.1.5.9+cvs.2004.02.07-3.1) unstable; urgency=low * NMU * gcc4 transition, renamed libzipios++0c102 to libzipios++0, not waiting for cppunit to be transitioned, since the tests built with it are not shipped nor executed at build-time. * Fix crash in amd64, closes: #314602 -- Isaac Clerencia Mon, 18 Jul 2005 23:50:27 +0200 zipios (0.1.5.9+cvs.2004.02.07-3) unstable; urgency=low * Added missing zipios-config.h - closes: #232097 -- Masayuki Hatta (mhatta) Wed, 11 Feb 2004 08:59:21 +0900 zipios (0.1.5.9+cvs.2004.02.07-2) unstable; urgency=low * [control] changed Maintainer field. -- Masayuki Hatta (mhatta) Sun, 8 Feb 2004 01:28:47 +0900 zipios (0.1.5.9+cvs.2004.02.07-1) unstable; urgency=low * New upstream release (CVS snapshot). * Bumped Standards-Version to 3.6.1. -- Masayuki Hatta (mhatta) Sat, 7 Feb 2004 16:47:39 +0900 zipios (0.1.5+cvs.2003.03.18-1) unstable; urgency=low * New upstream release (CVS snapshot). * Added Build-Depends: automake1.7 - closes: #178638 -- Masayuki Hatta Tue, 18 Mar 2003 10:51:25 +0900 zipios (0.1.5+cvs.2003.01.14-1) unstable; urgency=low * New upstream release (CVS snapshot). * GCC 3.2 Transition begins. Now it's called libzipios++0c102. * Now can be built with GCC 3.2 (Thanks Ross Burton for notifying me) - closes: #166745 * Prepared source with the latest libtool - closes: #176499 * Bumped Standards-Version to 3.5.8. -- Masayuki Hatta Tue, 14 Jan 2003 16:51:29 +0900 zipios (0.1.5+cvs.2002.11.22-1) unstable; urgency=low * New upstream release (CVS snapshot) * Applied patched from FreeBSD people - closes: #156424, #166741 -- Masayuki Hatta Fri, 22 Nov 2002 11:50:35 +0900 zipios (0.1.5+cvs.2002.08.10-1) unstable; urgency=low * Initial Release - closes: #156131 * Uses CVS snapshot, since the original 0.1.5 doesn't support shared library. -- Masayuki Hatta Sat, 10 Aug 2002 10:01:42 +0900 Zipios-2.3.2/debian/compat000066400000000000000000000000031445164132200154160ustar00rootroot0000000000000010 Zipios-2.3.2/debian/control000066400000000000000000000033621445164132200156260ustar00rootroot00000000000000Source: zipios Section: libs Priority: optional Maintainer: Masayuki Hatta (mhatta) Build-Depends: cmake, debhelper (>> 9), dh-exec (>=0.3), doxygen, graphicsmagick-imagemagick-compat, graphviz, libcppunit-dev, libz-dev, snapcatch2 (>= 2.9.1.0~jammy), zip Standards-Version: 3.9.4 Package: libzipios Section: libs Architecture: any Depends: ${shlibs:Depends}, ${misc:Depends} Description: a small C++ library for reading zip files (library) Zipios is a java.util.zip-like C++ library for reading and writing Zip files. Access to individual entries is provided through standard C++ iostreams. A simple read-only virtual file system that mounts regular directories and zip files is also provided. . This package contains shared library. Package: libzipios-dev Section: libdevel Architecture: any Depends: libzipios (= ${binary:Version}), libz-dev Description: a small C++ library for reading zip files (development) Zipios is a java.util.zip-like C++ library for reading and writing Zip files. Access to individual entries is provided through standard C++ iostreams. A simple read-only virtual file system that mounts regular directories and zip files is also provided. . This package contains files needed for development with Zipios. Package: libzipios-doc Section: doc Architecture: all Suggests: libzipios-dev Description: a small C++ library for reading zip files (documents) Zipios is a java.util.zip-like C++ library for reading and writing Zip files. Access to individual entries is provided through standard C++ iostreams. A simple read-only virtual file system that mounts regular directories and zip files is also provided. . This package contains documentations for development with Zipios. Zipios-2.3.2/debian/copyright000066400000000000000000000037321445164132200161570ustar00rootroot00000000000000Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: zipios Source: https://github.com/Zipios/Zipios Website: https://snapwebsites.org/project/zipios Upstream-Contact: Alexis Wilke Files: * Copyright: Copyright (c) 2000-2007 Thomas Sondergaard, All Rights Reserved. Copyright (c) 2015-2022 Made to Order Software Corp. All Rights Reserved. Disclaimer: At this time this is not part of Debian because we have not had someone who would like to maintain this new version of the library. License: LGPL-2+ This package is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. . This package is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. . You should have received a copy of the GNU Lesser General Public License along with this package; if not, write to the Free Software Foundation, Inc., 51 Franklin St. Fifth Floor, Boston, MA 02110-1301 USA . On Debian GNU/Linux systems, the complete text of the GNU Lesser General Public License can be found in `/usr/share/common-licenses/LGPL'. Files: mk dev/check License: public-domain Comment: Packages of the new version of the library can be found here: https://launchpad.net/~snapcpp/+archive/ubuntu/ppa/+packages . The older version of the library (1.x) was packaged (debianized) by Masayuki Hatta on Sat, 10 Aug 2002 10:01:42 +0900. . The older version was downloaded from http://zipios.sourceforge.net/ . WARNING: versions 2.x up to 2.2.0.0 included a couple of files that were actually license under the GPL. If you do need an LGPL version, make sure to use the latest version instead. Zipios-2.3.2/debian/docs000066400000000000000000000000271445164132200150710ustar00rootroot00000000000000NEWS README.md TODO.md Zipios-2.3.2/debian/libzipios-dev.install000077500000000000000000000003421445164132200203710ustar00rootroot00000000000000#! /usr/bin/dh-exec debian/tmp/usr/include/* usr/include/ debian/tmp/usr/lib/${DEB_HOST_MULTIARCH}/*.so usr/lib/${DEB_HOST_MULTIARCH}/ debian/tmp/usr/share/cmake/ZipIos/* usr/share/cmake/ZipIos/ Zipios-2.3.2/debian/libzipios-doc.install000066400000000000000000000000541445164132200203550ustar00rootroot00000000000000usr/share/doc/zipios/* usr/share/man/man3/* Zipios-2.3.2/debian/libzipios.install000077500000000000000000000002341445164132200176150ustar00rootroot00000000000000#! /usr/bin/dh-exec debian/tmp/usr/lib/${DEB_HOST_MULTIARCH}/*.so.* usr/lib/${DEB_HOST_MULTIARCH}/ debian/tmp/usr/bin usr/bin/ Zipios-2.3.2/debian/rules000077500000000000000000000010231445164132200152730ustar00rootroot00000000000000#!/usr/bin/make -f # -*- makefile -*- # Sample debian/rules that uses debhelper. # This file was originally written by Joey Hess and Craig Small. # As a special exception, when this file is copied by dh-make into a # dh-make output file, you may use that output file without restriction. # This special exception was added by Craig Small in version 0.37 of dh-make. # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 %: dh $@ --parallel override_dh_auto_configure: dh_auto_configure -- -DCMAKE_BUILD_TYPE=Release Zipios-2.3.2/debian/source/000077500000000000000000000000001445164132200155175ustar00rootroot00000000000000Zipios-2.3.2/debian/source/options000066400000000000000000000000471445164132200171360ustar00rootroot00000000000000tar-ignore = "tmp" tar-ignore = ".git" Zipios-2.3.2/dev/000077500000000000000000000000001445164132200135535ustar00rootroot00000000000000Zipios-2.3.2/dev/build000077500000000000000000000033061445164132200146020ustar00rootroot00000000000000#!/bin/sh -e # # Build the entire project using the autogen.sh, configure, make, make install # # Use these script at your own risk! # These are generally for Unix platforms. # Start this script from the source directory. # # License: # Zipios -- a small C++ library that provides easy access to .zip files. # # Copyright (c) 2015-2022 Made to Order Software Corp. All Rights Reserved # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either # version 2.1 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public # License along with this library; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA # SOURCE_PATH=`pwd` # Create output directory cd .. rm -rf BUILD mkdir -p BUILD/dist BUILD/zipios # Run cmake cd BUILD BUILD_PATH=`pwd` cd zipios if test "$1" = "-d" then # Include debug here cmake -DCMAKE_INSTALL_PREFIX:PATH=$BUILD_PATH/dist \ -DCMAKE_BUILD_TYPE=Debug \ ../../zipios else cmake -DCMAKE_INSTALL_PREFIX:PATH=$BUILD_PATH/dist \ ../../zipios fi # Build make # Install make install # Run tests cd $SOURCE_PATH/tests ../../BUILD/zipios/tests/zipios_tests # vim: ts=4 sw=4 et et Zipios-2.3.2/dev/check000077500000000000000000000066071445164132200145670ustar00rootroot00000000000000#!/bin/sh -e # You can consider this file as being in the public domain. # # Run the tests against an existing GNU_BUILD # Run a build first make -C ../BUILD/zipios # Go in the tests directory if test -z "$1" then make -C ../BUILD/zipios run_zipios_tests elif test "$1" = "-o" then # run tests one at a time ../BUILD/zipios/tests/zipios_tests -d yes "Scenario: BackBuffer read a file" ../BUILD/zipios/tests/zipios_tests -d yes "Scenario: CollectionCollection with various tests" ../BUILD/zipios/tests/zipios_tests -d yes "Scenario: Vector append" ../BUILD/zipios/tests/zipios_tests -d yes "Verify the g_separator" ../BUILD/zipios/tests/zipios_tests -d yes "Scenario: Read from file" ../BUILD/zipios/tests/zipios_tests -d yes "Scenario: Read from buffer" ../BUILD/zipios/tests/zipios_tests -d yes "Scenario: Write to file" ../BUILD/zipios/tests/zipios_tests -d yes "Scenario: DirectoryCollection with invalid paths" ../BUILD/zipios/tests/zipios_tests -d yes "DirectoryCollection with a valid file, but not a directory" ../BUILD/zipios/tests/zipios_tests -d yes "DirectoryCollection with valid trees of files" ../BUILD/zipios/tests/zipios_tests -d yes "DirectoryCollection with an existing directory that gets deleted" ../BUILD/zipios/tests/zipios_tests -d yes "DirectoryCollection with an empty directory" ../BUILD/zipios/tests/zipios_tests -d yes "Scenario: DirectoryEntry with invalid paths" ../BUILD/zipios/tests/zipios_tests -d yes "DirectoryEntry with one valid file" ../BUILD/zipios/tests/zipios_tests -d yes "Scenario: DirectoryEntry for a valid directory" ../BUILD/zipios/tests/zipios_tests -d yes "DOS Date & Time Min/Max" ../BUILD/zipios/tests/zipios_tests -d yes "Invalid DOS Date & Time" ../BUILD/zipios/tests/zipios_tests -d yes "Small DOS Date & Time" ../BUILD/zipios/tests/zipios_tests -d yes "Large DOS Date & Time" ../BUILD/zipios/tests/zipios_tests -d yes "Random DOS Date & Time" ../BUILD/zipios/tests/zipios_tests -d yes "Scenario: FilePath that does not represent a file on disk" ../BUILD/zipios/tests/zipios_tests -d yes "Scenario: FilePath against existing files on disk" ../BUILD/zipios/tests/zipios_tests -d yes "Test with regular files of various sizes" ../BUILD/zipios/tests/zipios_tests -d yes "An input filter" ../BUILD/zipios/tests/zipios_tests -d yes "An output filter" ../BUILD/zipios/tests/zipios_tests -d yes "VirtualSeeker tests" ../BUILD/zipios/tests/zipios_tests -d yes "An Empty ZipFile" ../BUILD/zipios/tests/zipios_tests -d yes "A ZipFile with an invalid name" ../BUILD/zipios/tests/zipios_tests -d yes "A ZipFile with an invalid file" ../BUILD/zipios/tests/zipios_tests -d yes "An empty ZipFile" ../BUILD/zipios/tests/zipios_tests -d yes "Scenario: ZipFile with a valid zip archive" ../BUILD/zipios/tests/zipios_tests -d yes "Scenario: use Zipios to create a zip archive" ../BUILD/zipios/tests/zipios_tests -d yes "Scenario: use Zipios to create zip archives with 1 or 3 files each" ../BUILD/zipios/tests/zipios_tests -d yes "Simple Valid and Invalid ZipFile Archives" ../BUILD/zipios/tests/zipios_tests -d yes "Valid and Invalid ZipFile Archives" else if test "$1" = "--seed" then shift seed="--seed $1" shift fi echo "../BUILD/zipios/tests/zipios_tests $*" ../BUILD/zipios/tests/zipios_tests $seed "$*" fi # vim: ts=4 sw=4 et Zipios-2.3.2/dev/coverage000077500000000000000000000141511445164132200152760ustar00rootroot00000000000000#!/bin/bash # # License: # Zipios -- a small C++ library that provides easy access to .zip files. # # Copyright (c) 2015-2022 Made to Order Software Corp. All Rights Reserved # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either # version 2.1 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public License # along with this library; if not, write to the Free Software Foundation, # Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA # set -e if test "$1" = "--help" -o "$1" = "-h" then echo "Usage: $0 [--opt] [test-name]" echo "where --opt is one of:" echo " --all run all tests" echo " --full run all tests and publish to the world" echo echo "to run specific tests, use one of these tags (can be used with --full, but probably should not):" echo " [directoryentry] run the DirectoryEntry class tests" echo " [fileentry] run all the tests that check the FileEntry interface" echo " [filepath] run the FilePath class tests" echo echo "for a complete list of tests use the --list command line option" echo "of the test executable:" echo " zipios_tests --list" exit 1; fi if test "$1" = "--full" then FULL=true shift else FULL=false fi start_date=`date` SOURCE_PATH=`pwd` . dev/version echo "***" echo "*** zipios coverage for version $FULL_VERSION (`date`)" echo "***" mkdir -p ../BUILD/zipios_coverage rm -rf ../BUILD/zipios_coverage/* cd ../BUILD BUILD_PATH=`pwd` cd zipios_coverage # request coverage in this build cmake -DCMAKE_INSTALL_PREFIX:PATH=$BUILD_PATH/dist \ -DCMAKE_BUILD_TYPE=Debug \ -Dzipios_project_COVERAGE:BOOL=ON \ -DCMAKE_MODULE_PATH:PATH=$SOURCE_PATH/cmake \ ../../zipios echo echo "***" echo "*** compile (`date`)" echo "***" VERBOSE=1 make echo echo "***" echo "*** run (`date`)" echo "***" # todo: # Catch does not give us such... we may want to bypass the limitation... # For now I have a catch_version.cpp test at least #if test `tests/zipios_tests --version` != "$FULL_VERSION" #then # echo "the version of zipios_tests (`BUILD/tests/zipios_tests --version`) is not equal to the project version ($FULL_VERSION)" # exit 1; #fi if $FULL then # We test the pipe status on exit to detect whether the test failed echo "Start running the tests on `date`" >test_log.txt echo >>test_log.txt # --success generates way too much output for HTML tests/zipios_tests --source-path "${SOURCE_PATH}" --durations yes 2>&1 | tee -a test_log.txt; test ${PIPESTATUS[0]} -eq 0 echo >>test_log.txt echo "Finished running the tests on `date`" >>test_log.txt else # "brief" test while working on a specific test if test "$1" == "--all" -o -z "$1" then # Do it all, but not published tests/zipios_tests --source-path "${SOURCE_PATH}" else tests/zipios_tests --source-path "${SOURCE_PATH}" $1 fi # just in case, remove the log file if there is one rm -f test_log.txt fi cd .. echo echo "***" echo "*** gcov/lcov (`date`)" echo "***" # The following lcov options can be used under Ubuntu 14.04+ # Use --no-external and --base-directory $SOURCE_PATH # to avoid /usr/include and other unwanted files # (only available in lcov version 1.10+) lcov --capture --no-external --directory zipios_coverage --base-directory $SOURCE_PATH --output-file coverage.info mkdir -p zipios_coverage_html genhtml --legend --demangle-cpp --no-branch-coverage --show-details coverage.info --output-directory zipios_coverage_html end_date=`date` # Statistics echo "zipios $FULL_VERSION statistics" >zipios_coverage_html/statistics.html echo "

Statistics of the zipios $FULL_VERSION code

" >>zipios_coverage_html/statistics.html
cloc $SOURCE_PATH/src/ $SOURCE_PATH/tools/ $SOURCE_PATH/zipios/ >>zipios_coverage_html/statistics.html
echo "

Statistics of the zipios $FULL_VERSION tests

" >>zipios_coverage_html/statistics.html
cloc $SOURCE_PATH/tests/ >>zipios_coverage_html/statistics.html
echo "
" >>zipios_coverage_html/statistics.html # Test output (Logs) echo "zipios $FULL_VERSION test logs

Logs for the zipios $FULL_VERSION tests

Tests started on $start_date and finished on $end_date

" >zipios_coverage_html/test_log.html
if test -f zipios_coverage/test_log.txt
then
    # If test_log.txt does not exist, the user got the logs in the
    # console already
    cat zipios_coverage/test_log.txt >>zipios_coverage_html/test_log.html
fi
echo "
" >>zipios_coverage_html/test_log.html if test -f zipios_coverage/test_log.txt then echo "***" echo "*** publication to ... ($end_date)" echo "***" # For publication, if that directory does not exist, you probably don't # have a website to display this data if test -d /usr/clients/www/alexis.m2osw.com/public_html/zipios then mkdir -p /usr/clients/www/alexis.m2osw.com/public_html/zipios/documentation cp -r zipios_coverage/doc/zipios-doc-*/* /usr/clients/www/alexis.m2osw.com/public_html/zipios/documentation/. cp $SOURCE_PATH/dev/index.php /usr/clients/www/alexis.m2osw.com/public_html/zipios/. mkdir -p /usr/clients/www/alexis.m2osw.com/public_html/zipios/zipios-$FULL_VERSION cp -r zipios_coverage_html/* /usr/clients/www/alexis.m2osw.com/public_html/zipios/zipios-$FULL_VERSION/. cp zipios_coverage_html/statistics.html /usr/clients/www/alexis.m2osw.com/public_html/zipios/zipios-$FULL_VERSION/. fi fi echo "Process started on $start_date" echo "Process finished on $end_date" # vim: ts=4 sw=4 et Zipios-2.3.2/dev/index.php000066400000000000000000000015621445164132200153770ustar00rootroot00000000000000Zipios coverage, statistics, and test log information"; echo "

Zipios coverage

"; echo ""; foreach($dir as $d) { echo ""; echo ""; echo ""; echo ""; echo ""; } echo "
CoverageStatisticsTest Logs
", $d, "", $d, "/statistics.html", $d, "/test_log.html
"; Zipios-2.3.2/dev/pack000077500000000000000000000032421445164132200144200ustar00rootroot00000000000000#!/bin/sh -e # # Build the project, generate the documentation and source tarball # # Use these script at your own risk! # These are generally for Unix platforms. # Start this script from the source directory. # # License: # Zipios -- a small C++ library that provides easy access to .zip files. # # Copyright (c) 2015-2022 Made to Order Software Corp. All Rights Reserved # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either # version 2.1 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public # License along with this library; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA # # Run the standard build process # This include running all the test and if that fails the packing will # also fail dev/build # Generate the package source make -C ../BUILD/zipios package_source # Generate the Doxygen documentation (you must have Doxygen and DOT) make -C ../BUILD/zipios zipios_Documentation # Copy the resulting files to the packages folder . dev/version mkdir -p ../packages cp ../BUILD/zipios/zipios-${FULL_VERSION}.tar.gz ../packages cp ../BUILD/zipios/doc/zipios-doc-${VERSION}.tar.gz ../packages Zipios-2.3.2/dev/spaces.sh000077500000000000000000000026501445164132200153730ustar00rootroot00000000000000#!/bin/sh # # Generally this script is called using make as follow: # # make -C YOUR_BUILD_DIR/zipios/ zipios_code_analysis # # License: # Zipios -- a small C++ library that provides easy access to .zip files. # # Copyright (c) 2011-2022 Made to Order Software Corp. All Rights Reserved # contact@m2osw.com # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either # version 2.1 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public # License along with this library; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA # if test -z "$1" then echo "$0: Usage: $0 " exit 1; fi # List files that have tabs grep -s ' ' */* | grep -v Binary | sed -e 's/:.*//' | sort -u >$1/spaces.txt # List files that have lines ending with spaces grep -s ' $' */* | grep -v Binary | sed -e 's/:.*//' | sort -u >>$1/spaces.txt # vim: ts=4 sw=4 et Zipios-2.3.2/dev/todo.sh000077500000000000000000000035101445164132200150560ustar00rootroot00000000000000#!/bin/sh # # Generally this script is called using make as follow: # # make -C YOUR_BUILD_DIR/zipios/ zipios_code_analysis # # License: # Zipios -- a small C++ library that provides easy access to .zip files. # Copyright (c) 2011-2022 Made to Order Software Corp. All Rights Reserved # contact@m2osw.com # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA # if test -z "$1" then echo "$0: Usage: $0 " exit 1; fi OUTPUT=$1/todo.txt echo "TODO: entries that need to be fixed before release 2.0" >$OUTPUT find . -type f -exec grep TODO {} \; | wc -l >>$OUTPUT echo "FIXME: things that probably need to be fixed (was used by previous owners)" >>$OUTPUT find . -type f -exec grep FIXME {} \; | wc -l >>$OUTPUT echo "XXX: entries that are likely to be addressed quickly" >>$OUTPUT find . -type f -exec grep XXX {} \; | wc -l >>$OUTPUT echo "TBD: questions that need testing to be answered" >>$OUTPUT find . -type f -exec grep TBD {} \; | wc -l >>$OUTPUT echo "todo: long term, nice to have things defined in Doxygen" >>$OUTPUT find . -type f -exec grep "todo:\|\\todo" {} \; | wc -l >>$OUTPUT # vim: ts=4 sw=4 et Zipios-2.3.2/dev/upload-website000077500000000000000000000103121445164132200164220ustar00rootroot00000000000000#!/bin/sh -e # # Upload the website on Sourceforge.net # # You will need to have an account with Sourceforge.net for this script to # work for you. Also, you'll have to change the user name in the scp commands. # # License: # Zipios -- a small C++ library that provides easy access to .zip files. # # Copyright (c) 2015-2022 Made to Order Software Corp. All Rights Reserved # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either # version 2.1 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public # License along with this library; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA # echo "WARNING: I switch from HTTP to HTTPS since sourceforge now offers such." echo " It could be that this script will not work without a few tweaks" echo " once it takes (right now it still works with the HTTP... I'm not" echo " sure whether it takes some time or I'm doing something wrong.)" . dev/version username=alexis_wilke help=false main=false documentation=false coverage=false while test ! -z "$1" do case "$1" in -h|--help) help=true shift ;; -m|--main) main=true shift ;; -d|--documentation) documentation=true shift ;; -c|--coverage) coverage=true shift ;; -u|--username) shift if test -z "$1" then echo "error: the --user command line option expects a parameter" exit 1; fi username=$1 shift ;; *) echo "error: unknown command line option. Try --help." exit 1; esac done if $help then echo "Usage: $0 [-opt]" echo "where -opt is one or more of the following:" echo " -h | --help print out this help screen" echo " -m | --main transmit the main HTML files" echo " -d | --documentation transmit the documentation if available" echo " -c | --coverage transmit the coverage data if available" echo " -u | --username log in to sourceforge using that user name" exit 1; fi # Copy the main files if --main was used if $main then echo "Copy main files ($FULL_VERSION)" scp doc/www/*.* $username@web.sourceforge.net:/home/project-web/zipios/htdocs/ scp -r doc/images $username@web.sourceforge.net:/home/project-web/zipios/htdocs/ else echo "Ignore main" fi # Copy the documentation if --documentation used and docs are available if $documentation then DOCS=../BUILD/dist/share/doc/zipios if test ! -d ${DOCS}/html then DOCS=../../../BUILD/dist/share/doc/zipios fi if test -d ${DOCS}/html then echo "Copy documentation ($VERSION)" # # To keep a copy of each major.minor versions, we first # rename the HTML directory. Once done we restore the # directory name so one can run the process again. # (we should use a trap to make sure to restore the # name but well... this is a sloppy script anyway.) # mv ${DOCS}/html ${DOCS}/zipios-v$VERSION scp -r ${DOCS}/zipios-v$VERSION $username@web.sourceforge.net:/home/project-web/zipios/htdocs/ mv ${DOCS}/zipios-v$VERSION ${DOCS}/html else echo "Documentation not available." fi else echo "Ignore documentation" fi # Copy the coverage data if --coverage used and such is available if $coverage then if test -d ../BUILD/zipios_coverage_html then echo "Copy coverage ($FULL_VERSION)" # Now copy the HTML data # Note that we only keep the last version... mkdir ../BUILD/coverage mv ../BUILD/zipios_coverage_html ../BUILD/coverage/zipios-$FULL_VERSION cp dev/index.php ../BUILD/coverage/. scp -r ../BUILD/coverage $username@web.sourceforge.net:/home/project-web/zipios/htdocs/. mv ../BUILD/coverage/zipios-$FULL_VERSION ../BUILD/zipios_coverage_html rm -rf ../BUILD/coverage else echo "Coverage data not available." fi else echo "Ignore coverage" fi Zipios-2.3.2/dev/version000077500000000000000000000041641445164132200151730ustar00rootroot00000000000000#!/bin/sh -e # # Retrieve the project version from the main CMakeLists.txt file # # License: # Zipios -- a small C++ library that provides easy access to .zip files. # # Copyright (c) 2015-2022 Made to Order Software Corp. All Rights Reserved # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either # version 2.1 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public # License along with this library; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA # if test ! -f CMakeLists.txt -o ! -f debian/changelog then echo "error: can't find CMakeLists.txt or debian/changelog to extract version information." exit 1 fi MAJOR=`grep 'set( ZIPIOS_VERSION_MAJOR ' CMakeLists.txt | sed -e 's/.*ZIPIOS_VERSION_MAJOR //' -e 's/ .*//'` MINOR=`grep 'set( ZIPIOS_VERSION_MINOR ' CMakeLists.txt | sed -e 's/.*ZIPIOS_VERSION_MINOR //' -e 's/ .*//'` PATCH=`grep 'set( ZIPIOS_VERSION_PATCH ' CMakeLists.txt | sed -e 's/.*ZIPIOS_VERSION_PATCH //' -e 's/ .*//'` BUILD=`grep 'set( ZIPIOS_VERSION_BUILD ' CMakeLists.txt | sed -e 's/.*ZIPIOS_VERSION_BUILD //' -e 's/ .*//'` VERSION=${MAJOR}.${MINOR} FULL_VERSION=${MAJOR}.${MINOR}.${PATCH} COMPLETE_VERSION=${MAJOR}.${MINOR}.${PATCH}.${BUILD} # To verify, make sure the version in the changelog matches CHANGELOG_VERSION=`sed -n -e 1p debian/changelog | sed -e 's/.*(//' -e 's/\~.*//'` #echo $FULL_VERSION #echo $COMPLETE_VERSION #echo $CHANGELOG_VERSION if test "$COMPLETE_VERSION" != "$CHANGELOG_VERSION" then echo "error: complete version from CMakeLists.txt is $COMPLETE_VERSION, version in changelog is $CHANGELOG_VERSION" exit 1 fi Zipios-2.3.2/doc/000077500000000000000000000000001445164132200135425ustar00rootroot00000000000000Zipios-2.3.2/doc/CMakeLists.txt000066400000000000000000000117431445164132200163100ustar00rootroot00000000000000# Zipios -- a small C++ library that provides easy access to .zip files. # Copyright (C) 2000-2007 Thomas Sondergaard # Copyright (c) 2015-2022 Made to Order Software Corp. All Rights Reserved # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either # version 2.1 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public # License along with this library; if not, write to the Free Software # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA if(BUILD_DOCUMENTATION) project( zipios_documentation ) ################################################################################ # Copy of the AddDoxygenTarget from the Snap! C++ project # https://sourceforge.net/projects/snapcpp/ # find_package(Doxygen QUIET) function(AddDoxygenTarget TARGET_NAME VERSION_MAJOR VERSION_MINOR VERSION_PATCH) cmake_parse_arguments(PARSE_ARGV 4 ADD_DOXY "QUIET" "" "") project(${TARGET_NAME}_Documentation) set(VERSION "${VERSION_MAJOR}.${VERSION_MINOR}") set(FULL_VERSION "${VERSION}.${VERSION_PATCH}") if(DOXYGEN_FOUND) if(NOT DOXYGEN_DOT_FOUND) message(WARNING "The dot executable was not found. Did you install Graphviz? No graphic output shall be generated in documentation.") endif() configure_file(${CMAKE_CURRENT_SOURCE_DIR}/${TARGET_NAME}.doxy.in ${CMAKE_CURRENT_BINARY_DIR}/${TARGET_NAME}.doxy @ONLY) set(DOCUMENTATION_OUTPUT ${TARGET_NAME}-doc-${VERSION}) if(SUNOS) set(TAR_OPTIONS cEzf) else() set(TAR_OPTIONS czf) endif() add_custom_command( OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${DOCUMENTATION_OUTPUT}.tar.gz ${DOCUMENTATION_OUTPUT} COMMAND ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/${TARGET_NAME}.doxy 1> ${CMAKE_CURRENT_BINARY_DIR}/${TARGET_NAME}-doxy.log 2> ${CMAKE_CURRENT_BINARY_DIR}/${TARGET_NAME}-doxy.err COMMAND echo Compacting as ${DOCUMENTATION_OUTPUT}.tar.gz COMMAND rm -rf ${DOCUMENTATION_OUTPUT} COMMAND mv html ${DOCUMENTATION_OUTPUT} COMMAND tar ${TAR_OPTIONS} ${DOCUMENTATION_OUTPUT}.tar.gz ${DOCUMENTATION_OUTPUT} WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} ) add_custom_target(${TARGET_NAME}_Documentation ALL DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${DOCUMENTATION_OUTPUT}.tar.gz COMMENT "Generating API documentation with Doxygen" VERBATIM ) string(TOLOWER ${TARGET_NAME} LOWER_TARGET_NAME) install( DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/${DOCUMENTATION_OUTPUT}/ DESTINATION ${DATA_INSTALL_DIR}/doc/${LOWER_TARGET_NAME}/html/ ) # The following installs the man3 files, we only install the man # pages of public classes. For more details the user will have to # go to the HTML documentation install( FILES ${CMAKE_CURRENT_BINARY_DIR}/man/man3/zipios.3 ${CMAKE_CURRENT_BINARY_DIR}/man/man3/zipios_CollectionCollection.3 ${CMAKE_CURRENT_BINARY_DIR}/man/man3/zipios_DirectoryCollection.3 ${CMAKE_CURRENT_BINARY_DIR}/man/man3/zipios_DirectoryEntry.3 ${CMAKE_CURRENT_BINARY_DIR}/man/man3/zipios_FileCollection.3 ${CMAKE_CURRENT_BINARY_DIR}/man/man3/zipios_FileEntry.3 ${CMAKE_CURRENT_BINARY_DIR}/man/man3/zipios_FilePath.3 ${CMAKE_CURRENT_BINARY_DIR}/man/man3/zipios_VirtualSeeker.3 ${CMAKE_CURRENT_BINARY_DIR}/man/man3/zipios_ZipFile.3 DESTINATION ${DATA_INSTALL_DIR}/man/man3 ) else() if(NOT ADD_DOXY_QUIET) message( WARNING "You do not seem to have doxygen installed on this system, no documentation will be generated." ) endif() endif() endfunction() configure_file(${CMAKE_SOURCE_DIR}/doc/zipios.doxy.in ${CMAKE_BINARY_DIR}/doc/zipios.doxy) AddDoxygenTarget(zipios ${ZIPIOS_VERSION_MAJOR} ${ZIPIOS_VERSION_MINOR} ${ZIPIOS_VERSION_PATCH} QUIET) else(BUILD_DOCUMENTATION) message("No documentation will be created because you explicitly disabled it.") endif(BUILD_DOCUMENTATION) # Local Variables: # indent-tabs-mode: nil # tab-width: 4 # End: # vim: ts=4 sw=4 et nocindent Zipios-2.3.2/doc/README000066400000000000000000000004371445164132200144260ustar00rootroot00000000000000The documentation for Zipios is generated from the source code using Doxygen. You can use the online documentation at https://zipios.sourceforge.io or download the pdf version from the same URL, or, if you have Doxygen installed, run 'make zipios_Documentation' in your build directory. Zipios-2.3.2/doc/appnote-with-many-extensions.txt000066400000000000000000003142201445164132200220630ustar00rootroot00000000000000[Info-ZIP note, 20011203: this file is based on PKWARE's appnote.txt of 15 February 1996, taking into account PKWARE's revised appnote.txt version 4.5 of 01 November 2001. It has been unofficially corrected and extended by Info-ZIP without explicit permission by PKWARE. Although Info-ZIP believes the information to be accurate and complete, it is provided under a disclaimer similar to the PKWARE disclaimer below, differing only in the substitution of "Info-ZIP" for "PKWARE". In other words, use this information at your own risk, but we think it's correct. Specification info from PKWARE that was obviously wrong has been corrected silently (e.g. missing structure fields, wrong numbers). As of PKZIPW 2.50, two new incompatibilities have been introduced by PKWARE; they are noted below. Note that the "NTFS tag" conflict is currently not real; PKZIPW 2.50 actually tags NTFS files as having come from a FAT file system, too.] Disclaimer ---------- Although PKWARE will attempt to supply current and accurate information relating to its file formats, algorithms, and the subject programs, the possibility of error can not be eliminated. PKWARE therefore expressly disclaims any warranty that the information contained in the associated materials relating to the subject programs and/or the format of the files created or accessed by the subject programs and/or the algorithms used by the subject programs, or any other matter, is current, correct or accurate as delivered. Any risk of damage due to any possible inaccurate information is assumed by the user of the information. Furthermore, the information relating to the subject programs and/or the file formats created or accessed by the subject programs and/or the algorithms used by the subject programs is subject to change without notice. General Format of a .ZIP file ----------------------------- Files stored in arbitrary order. Large .ZIP files can span multiple diskette media or be split into user-defined segment sizes. The minimum user-defined segment size for a split .ZIP file is 64K. Overall .ZIP file format: [local file header 1] [file data 1] [data descriptor 1] . . . [local file header n] [file data n] [data descriptor n] [central directory] [zip64 end of central directory record] [zip64 end of central directory locator] [end of central directory record] A. Local file header: local file header signature 4 bytes (0x04034b50) version needed to extract 2 bytes general purpose bit flag 2 bytes compression method 2 bytes last mod file time 2 bytes last mod file date 2 bytes crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes file name length 2 bytes extra field length 2 bytes file name (variable size) extra field (variable size) B. File data Immediately following the local header for a file is the compressed or stored data for the file. The series of [local file header][file data][data descriptor] repeats for each file in the .ZIP archive. C. Data descriptor: [Info-ZIP discrepancy: The Info-ZIP zip program starts the data descriptor with a 4-byte PK-style signature. Despite the specification, none of the PKWARE programs supports the data descriptor. PKZIP 4.0 -fix function (and PKZIPFIX 2.04) ignores the data descriptor info even when bit 3 of the general purpose bit flag is set. data descriptor signature 4 bytes (0x08074b50) ] crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes This descriptor exists only if bit 3 of the general purpose bit flag is set (see below). It is byte aligned and immediately follows the last byte of compressed data. This descriptor is used only when it was not possible to seek in the output .ZIP file, e.g., when the output .ZIP file was standard output or a non seekable device. For Zip64 format archives, the compressed and uncompressed sizes are 8 bytes each. D. Central directory structure: [file header 1] . . . [file header n] [digital signature] File header: central file header signature 4 bytes (0x02014b50) version made by 2 bytes version needed to extract 2 bytes general purpose bit flag 2 bytes compression method 2 bytes last mod file time 2 bytes last mod file date 2 bytes crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes file name length 2 bytes extra field length 2 bytes file comment length 2 bytes disk number start 2 bytes internal file attributes 2 bytes external file attributes 4 bytes relative offset of local header 4 bytes file name (variable size) extra field (variable size) file comment (variable size) Digital signature: header signature 4 bytes (0x05054b50) size of data 2 bytes signature data (variable size) E. Zip64 end of central directory record zip64 end of central dir signature 4 bytes (0x06064b50) size of zip64 end of central directory record 8 bytes version made by 2 bytes version needed to extract 2 bytes number of this disk 4 bytes number of the disk with the start of the central directory 4 bytes total number of entries in the central directory on this disk 8 bytes total number of entries in the central directory 8 bytes size of the central directory 8 bytes offset of start of central directory with respect to the starting disk number 8 bytes zip64 extensible data sector (variable size) F. Zip64 end of central directory locator zip64 end of central dir locator signature 4 bytes (0x07064b50) number of the disk with the start of the zip64 end of central directory 4 bytes relative offset of the zip64 end of central directory record 8 bytes total number of disks 4 bytes G. End of central directory record: end of central dir signature 4 bytes (0x06054b50) number of this disk 2 bytes number of the disk with the start of the central directory 2 bytes total number of entries in the central directory on this disk 2 bytes total number of entries in the central directory 2 bytes size of the central directory 4 bytes offset of start of central directory with respect to the starting disk number 4 bytes .ZIP file comment length 2 bytes .ZIP file comment (variable size) H. Explanation of fields: version made by (2 bytes) [PKWARE describes "OS made by" now (since 1998) as follows: The upper byte indicates the compatibility of the file attribute information. If the external file attributes are compatible with MS-DOS and can be read by PKZIP for DOS version 2.04g then this value will be zero. If these attributes are not compatible, then this value will identify the host system on which the attributes are compatible.] The upper byte indicates the host system (OS) for the file. Software can use this information to determine the line record format for text files etc. The current mappings are: 0 - FAT file system (DOS, OS/2, NT) + PKWARE 2.50+ VFAT, NTFS 1 - Amiga 2 - OpenVMS 3 - Unix 4 - VM/CMS 5 - Atari ST 6 - HPFS file system (OS/2, NT 3.x) 7 - Macintosh 8 - Z-System 9 - CP/M --------------------------------------------------------------------- PKWARE assignment | Info-ZIP assignment -----------------------------------|--------------------------------- 10 - Windows NTFS | TOPS-20 (since PKZIPW 2.50, but | (assigned Oct-1992, not used by any PKWARE prog) | no longer used) 11 - MVS | NTFS file system (WinNT) | (actively used by Info-ZIP's | Zip for NT since Sep-1993) 12 - VSE | SMS/QDOS --------------------------------------------------------------------- 13 - Acorn RISC OS 14 - VFAT file system (Win95, NT) [Info-ZIP reservation, unused] 15 - MVS [PKWARE describes this assignment as "alternate MVS"] 16 - BeOS (BeBox or PowerMac) 17 - Tandem 18 through 255 - unused The lower byte indicates the version number of the software used to encode the file. The value/10 indicates the major version number, and the value mod 10 is the minor version number. version needed to extract (2 bytes) The minimum software version needed to extract the file, mapped as above. For Zip64 format archives, this value should not be less than 45. general purpose bit flag: (2 bytes) Bit 0: If set, indicates that the file is encrypted. (For Method 6 - Imploding) Bit 1: If the compression method used was type 6, Imploding, then this bit, if set, indicates an 8K sliding dictionary was used. If clear, then a 4K sliding dictionary was used. Bit 2: If the compression method used was type 6, Imploding, then this bit, if set, indicates 3 Shannon-Fano trees were used to encode the sliding dictionary output. If clear, then 2 Shannon-Fano trees were used. (For Methods 8 and 9 - Deflating) Bit 2 Bit 1 0 0 Normal (-en) compression option was used. 0 1 Maximum (-exx/-ex) compression option was used. 1 0 Fast (-ef) compression option was used. 1 1 Super Fast (-es) compression option was used. Note: Bits 1 and 2 are undefined if the compression method is any other. Bit 3: If this bit is set, the fields crc-32, compressed size and uncompressed size are set to zero in the local header. The correct values are put in the data descriptor immediately following the compressed data. (Note: PKZIP version 2.04g for DOS only recognizes this bit for method 8 compression, newer versions of PKZIP recognize this bit for any compression method.) [Info-ZIP note: This bit was introduced by PKZIP 2.04 for DOS. In general, this feature can only be reliably used together with compression methods that allow intrinsic detection of the "end-of-compressed-data" condition. From the set of compression methods described in this Zip archive specification, only "deflate" meets this requirement. Especially, the method STORED does not work! The Info-ZIP tools recognize this bit regardless of the compression method; but, they rely on correctly set "compressed size" information in the central directory entry.] Bit 4: Reserved for use with method 8, for enhanced deflating. Bit 5: If this bit is set, this indicates that the file is compressed patched data. (Note: Requires PKZIP version 2.70 or greater) Bit 6: Currently unused. Bit 7: Currently unused. Bit 8: Currently unused. Bit 9: Currently unused. Bit 10: Currently unused. Bit 11: Currently unused. Bit 12: Reserved by PKWARE for enhanced compression. Bit 13: Reserved by PKWARE. Bit 14: Reserved by PKWARE. Bit 15: Reserved by PKWARE. compression method: (2 bytes) (see accompanying documentation for algorithm descriptions) 0 - The file is stored (no compression) 1 - The file is Shrunk 2 - The file is Reduced with compression factor 1 3 - The file is Reduced with compression factor 2 4 - The file is Reduced with compression factor 3 5 - The file is Reduced with compression factor 4 6 - The file is Imploded 7 - Reserved for Tokenizing compression algorithm 8 - The file is Deflated 9 - Enhanced Deflating using Deflate64(tm) 10 - PKWARE Data Compression Library Imploding date and time fields: (2 bytes each) The date and time are encoded in standard MS-DOS format. If input came from standard input, the date and time are those at which compression was started for this data. CRC-32: (4 bytes) The CRC-32 algorithm was generously contributed by David Schwaderer and can be found in his excellent book "C Programmers Guide to NetBIOS" published by Howard W. Sams & Co. Inc. The 'magic number' for the CRC is 0xdebb20e3. The proper CRC pre and post conditioning is used, meaning that the CRC register is pre-conditioned with all ones (a starting value of 0xffffffff) and the value is post-conditioned by taking the one's complement of the CRC residual. If bit 3 of the general purpose flag is set, this field is set to zero in the local header and the correct value is put in the data descriptor and in the central directory. compressed size: (4 bytes) uncompressed size: (4 bytes) The size of the file compressed and uncompressed, respectively. If bit 3 of the general purpose bit flag is set, these fields are set to zero in the local header and the correct values are put in the data descriptor and in the central directory. If an archive is in zip64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte zip64 extended information extra field. file name length: (2 bytes) extra field length: (2 bytes) file comment length: (2 bytes) The length of the file name, extra field, and comment fields respectively. The combined length of any directory record and these three fields should not generally exceed 65,535 bytes. If input came from standard input, the file name length is set to zero. [Info-ZIP note: This feature is not yet supported by any PKWARE version of ZIP (at least not in PKZIP for DOS and PKZIP for Windows/WinNT). The Info-ZIP programs handle standard input differently: If input came from standard input, the filename is set to "-" (length one).] disk number start: (2 bytes) The number of the disk on which this file begins. If an archive is in zip64 format and the value in this field is 0xFFFF, the size will be in the corresponding 4 byte zip64 extended information extra field. internal file attributes: (2 bytes) The lowest bit of this field indicates, if set, that the file is apparently an ASCII or text file. If not set, that the file apparently contains binary data. The remaining bits are unused in version 1.0. Bits 1 and 2 are reserved for use by PKWARE. external file attributes: (4 bytes) The mapping of the external attributes is host-system dependent (see 'version made by'). For MS-DOS, the low order byte is the MS-DOS directory attribute byte. If input came from standard input, this field is set to zero. relative offset of local header: (4 bytes) This is the offset from the start of the first disk on which this file appears, to where the local header should be found. If an archive is in zip64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte zip64 extended information extra field. file name: (Variable) The name of the file, with optional relative path. The path stored should not contain a drive or device letter, or a leading slash. All slashes should be forward slashes '/' as opposed to backwards slashes '\' for compatibility with Amiga and Unix file systems etc. If input came from standard input, there is no file name field. [Info-ZIP discrepancy: If input came from standard input, the file name is set to "-" (without the quotes). As far as we know, the PKWARE specification for "input from stdin" is not supported by PKZIP/PKUNZIP for DOS, OS/2, Windows Windows NT.] extra field: (Variable) This is for expansion. If additional information needs to be stored for special needs or for specific platforms, it should be stored here. Earlier versions of the software can then safely skip this file, and find the next file or header. This field will be 0 length in version 1.0. In order to allow different programs and different types of information to be stored in the 'extra' field in .ZIP files, the following structure should be used for all programs storing data in this field: header1+data1 + header2+data2 . . . Each header should consist of: Header ID - 2 bytes Data Size - 2 bytes Note: all fields stored in Intel low-byte/high-byte order. The Header ID field indicates the type of data that is in the following data block. Header ID's of 0 through 31 are reserved for use by PKWARE. The remaining ID's can be used by third party vendors for proprietary usage. The current Header ID mappings defined by PKWARE are: 0x0001 ZIP64 extended information extra field 0x0007 AV Info 0x0009 OS/2 extended attributes (also Info-ZIP) 0x000a NTFS (Win9x/WinNT FileTimes) 0x000c OpenVMS (also Info-ZIP) 0x000d Unix 0x000f Patch Descriptor 0x0014 PKCS#7 Store for X.509 Certificates 0x0015 X.509 Certificate ID and Signature for individual file 0x0016 X.509 Certificate ID for Central Directory The Header ID mappings defined by Info-ZIP and third parties are: 0x0065 IBM S/390 attributes - uncompressed 0x0066 IBM S/390 attributes - compressed 0x07c8 Info-ZIP Macintosh (old, J. Lee) 0x2605 ZipIt Macintosh (first version) 0x2705 ZipIt Macintosh v 1.3.5 and newer (w/o full filename) 0x334d Info-ZIP Macintosh (new, D. Haase's 'Mac3' field ) 0x4154 Tandem NSK 0x4341 Acorn/SparkFS (David Pilling) 0x4453 Windows NT security descriptor (binary ACL) 0x4704 VM/CMS 0x470f MVS 0x4854 Theos, old unofficial port 0x4b46 FWKCS MD5 (see below) 0x4c41 OS/2 access control list (text ACL) 0x4d49 Info-ZIP OpenVMS (obsolete) 0x4d63 Macintosh SmartZIP, by Macro Bambini 0x4f4c Xceed original location extra field 0x5356 AOS/VS (binary ACL) 0x5455 extended timestamp 0x5855 Info-ZIP Unix (original; also OS/2, NT, etc.) 0x554e Xceed unicode extra field 0x6542 BeOS (BeBox, PowerMac, etc.) 0x6854 Theos 0x756e ASi Unix 0x7855 Info-ZIP Unix (new) 0xfb4a SMS/QDOS The Data Size field indicates the size of the following data block. Programs can use this value to skip to the next header block, passing over any data blocks that are not of interest. Note: As stated above, the size of the entire .ZIP file header, including the file name, comment, and extra field should not exceed 64K in size. In case two different programs should appropriate the same Header ID value, it is strongly recommended that each program place a unique signature of at least two bytes in size (and preferably 4 bytes or bigger) at the start of each data area. Every program should verify that its unique signature is present, in addition to the Header ID value being correct, before assuming that it is a block of known type. In the following descriptions, note that "Short" means two bytes, "Long" means four bytes, and "Long-Long" means eight bytes, regardless of their native sizes. Unless specifically noted, all integer fields should be interpreted as unsigned (non-negative) numbers. -OS/2 Extended Attributes Extra Field: ==================================== The following is the layout of the OS/2 extended attributes "extra" block. (Last Revision 19960922) Note: all fields stored in Intel low-byte/high-byte order. Local-header version: Value Size Description ----- ---- ----------- (OS/2) 0x0009 Short tag for this extra block type TSize Short total data size for this block BSize Long uncompressed EA data size CType Short compression type EACRC Long CRC value for uncompressed EA data (var.) variable compressed EA data Central-header version: Value Size Description ----- ---- ----------- (OS/2) 0x0009 Short tag for this extra block type TSize Short total data size for this block (4) BSize Long size of uncompressed local EA data The value of CType is interpreted according to the "compression method" section above; i.e., 0 for stored, 8 for deflated, etc. The OS/2 extended attribute structure (FEA2LIST) is compressed and then stored in its entirety within this structure. There will only ever be one block of data in the variable-length field. -OS/2 Access Control List Extra Field: ==================================== The following is the layout of the OS/2 ACL extra block. (Last Revision 19960922) Local-header version: Value Size Description ----- ---- ----------- (ACL) 0x4c41 Short tag for this extra block type ("AL") TSize Short total data size for this block BSize Long uncompressed ACL data size CType Short compression type EACRC Long CRC value for uncompressed ACL data (var.) variable compressed ACL data Central-header version: Value Size Description ----- ---- ----------- (ACL) 0x4c41 Short tag for this extra block type ("AL") TSize Short total data size for this block (4) BSize Long size of uncompressed local ACL data The value of CType is interpreted according to the "compression method" section above; i.e., 0 for stored, 8 for deflated, etc. The uncompressed ACL data consist of a text header of the form "ACL1:%hX,%hd\n", where the first field is the OS/2 ACCINFO acc_attr member and the second is acc_count, followed by acc_count strings of the form "%s,%hx\n", where the first field is acl_ugname (user group name) and the second acl_access. This block type will be extended for other operating systems as needed. -Windows NT Security Descriptor Extra Field: ========================================== The following is the layout of the NT Security Descriptor (another type of ACL) extra block. (Last Revision 19960922) Local-header version: Value Size Description ----- ---- ----------- (SD) 0x4453 Short tag for this extra block type ("SD") TSize Short total data size for this block BSize Long uncompressed SD data size Version Byte version of uncompressed SD data format CType Short compression type EACRC Long CRC value for uncompressed SD data (var.) variable compressed SD data Central-header version: Value Size Description ----- ---- ----------- (SD) 0x4453 Short tag for this extra block type ("SD") TSize Short total data size for this block (4) BSize Long size of uncompressed local SD data The value of CType is interpreted according to the "compression method" section above; i.e., 0 for stored, 8 for deflated, etc. Version specifies how the compressed data are to be interpreted and allows for future expansion of this extra field type. Currently only version 0 is defined. For version 0, the compressed data are to be interpreted as a single valid Windows NT SECURITY_DESCRIPTOR data structure, in self-relative format. -PKWARE Win95/WinNT Extra Field: ============================== The following description covers PKWARE's "NTFS" attributes "extra" block, introduced with the release of PKZIP 2.50 for Windows. (Last Revision 20001118) (Note: At this time the Mtime, Atime and Ctime values may be used on any WIN32 system.) [Info-ZIP note: In the current implementations, this field has a fixed total data size of 32 bytes and is only stored as local extra field.] Value Size Description ----- ---- ----------- (NTFS) 0x000a Short Tag for this "extra" block type TSize Short Total Data Size for this block Reserved Long for future use Tag1 Short NTFS attribute tag value #1 Size1 Short Size of attribute #1, in bytes (var.) SubSize1 Attribute #1 data . . . TagN Short NTFS attribute tag value #N SizeN Short Size of attribute #N, in bytes (var.) SubSize1 Attribute #N data For NTFS, values for Tag1 through TagN are as follows: (currently only one set of attributes is defined for NTFS) Tag Size Description ----- ---- ----------- 0x0001 2 bytes Tag for attribute #1 Size1 2 bytes Size of attribute #1, in bytes (24) Mtime 8 bytes 64-bit NTFS file last modification time Atime 8 bytes 64-bit NTFS file last access time Ctime 8 bytes 64-bit NTFS file creation time The total length for this block is 28 bytes, resulting in a fixed size value of 32 for the TSize field of the NTFS block. The NTFS filetimes are 64-bit unsigned integers, stored in Intel (least significant byte first) byte order. They determine the number of 1.0E-07 seconds (1/10th microseconds!) past WinNT "epoch", which is "01-Jan-1601 00:00:00 UTC". -PKWARE OpenVMS Extra Field: ========================== The following is the layout of PKWARE's OpenVMS attributes "extra" block. (Last Revision 12/17/91) Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (VMS) 0x000c Short Tag for this "extra" block type TSize Short Total Data Size for this block CRC Long 32-bit CRC for remainder of the block Tag1 Short OpenVMS attribute tag value #1 Size1 Short Size of attribute #1, in bytes (var.) Size1 Attribute #1 data . . . TagN Short OpenVMS attribute tag value #N SizeN Short Size of attribute #N, in bytes (var.) SizeN Attribute #N data Rules: 1. There will be one or more of attributes present, which will each be preceded by the above TagX & SizeX values. These values are identical to the ATR$C_XXXX and ATR$S_XXXX constants which are defined in ATR.H under OpenVMS C. Neither of these values will ever be zero. 2. No word alignment or padding is performed. 3. A well-behaved PKZIP/OpenVMS program should never produce more than one sub-block with the same TagX value. Also, there will never be more than one "extra" block of type 0x000c in a particular directory record. -Info-ZIP VMS Extra Field: ======================== The following is the layout of Info-ZIP's VMS attributes extra block for VAX or Alpha AXP. The local-header and central-header versions are identical. (Last Revision 19960922) Value Size Description ----- ---- ----------- (VMS2) 0x4d49 Short tag for this extra block type ("JM") TSize Short total data size for this block ID Long block ID Flags Short info bytes BSize Short uncompressed block size Reserved Long (reserved) (var.) variable compressed VMS file-attributes block The block ID is one of the following unterminated strings: "VFAB" struct FAB "VALL" struct XABALL "VFHC" struct XABFHC "VDAT" struct XABDAT "VRDT" struct XABRDT "VPRO" struct XABPRO "VKEY" struct XABKEY "VMSV" version (e.g., "V6.1"; truncated at hyphen) "VNAM" reserved The lower three bits of Flags indicate the compression method. The currently defined methods are: 0 stored (not compressed) 1 simple "RLE" 2 deflated The "RLE" method simply replaces zero-valued bytes with zero-valued bits and non-zero-valued bytes with a "1" bit followed by the byte value. The variable-length compressed data contains only the data corre- sponding to the indicated structure or string. Typically multiple VMS2 extra fields are present (each with a unique block type). -Info-ZIP Macintosh Extra Field: ============================== The following is the layout of the (old) Info-ZIP resource-fork extra block for Macintosh. The local-header and central-header versions are identical. (Last Revision 19960922) Value Size Description ----- ---- ----------- (Mac) 0x07c8 Short tag for this extra block type TSize Short total data size for this block "JLEE" beLong extra-field signature FInfo 16 bytes Macintosh FInfo structure CrDat beLong HParamBlockRec fileParam.ioFlCrDat MdDat beLong HParamBlockRec fileParam.ioFlMdDat Flags beLong info bits DirID beLong HParamBlockRec fileParam.ioDirID VolName 28 bytes volume name (optional) All fields but the first two are in native Macintosh format (big-endian Motorola order, not little-endian Intel). The least significant bit of Flags is 1 if the file is a data fork, 0 other- wise. In addition, if this extra field is present, the filename has an extra 'd' or 'r' appended to indicate data fork or resource fork. The 28-byte VolName field may be omitted. -ZipIt Macintosh Extra Field (long): ================================== The following is the layout of the ZipIt extra block for Macintosh. The local-header and central-header versions are identical. (Last Revision 19970130) Value Size Description ----- ---- ----------- (Mac2) 0x2605 Short tag for this extra block type TSize Short total data size for this block "ZPIT" beLong extra-field signature FnLen Byte length of FileName FileName variable full Macintosh filename FileType Byte[4] four-byte Mac file type string Creator Byte[4] four-byte Mac creator string -ZipIt Macintosh Extra Field (short): =================================== The following is the layout of a shortened variant of the ZipIt extra block for Macintosh (without "full name" entry). This variant is used by ZipIt 1.3.5 and newer for entries that do not need a "full Mac filename" record. The local-header and central-header versions are identical. (Last Revision 19980903) Value Size Description ----- ---- ----------- (Mac2b) 0x2705 Short tag for this extra block type TSize Short total data size for this block (12) "ZPIT" beLong extra-field signature FileType Byte[4] four-byte Mac file type string Creator Byte[4] four-byte Mac creator string -Info-ZIP Macintosh Extra Field (new): ==================================== The following is the layout of the (new) Info-ZIP extra block for Macintosh, designed by Dirk Haase. All values are in little-endian. (Last Revision 19981005) Local-header version: Value Size Description ----- ---- ----------- (Mac3) 0x334d Short tag for this extra block type ("M3") TSize Short total data size for this block BSize Long uncompressed finder attribute data size Flags Short info bits fdType Byte[4] Type of the File (4-byte string) fdCreator Byte[4] Creator of the File (4-byte string) (CType) Short compression type (CRC) Long CRC value for uncompressed MacOS data Attribs variable finder attribute data (see below) Central-header version: Value Size Description ----- ---- ----------- (Mac3) 0x334d Short tag for this extra block type ("M3") TSize Short total data size for this block BSize Long uncompressed finder attribute data size Flags Short info bits fdType Byte[4] Type of the File (4-byte string) fdCreator Byte[4] Creator of the File (4-byte string) The third bit of Flags in both headers indicates whether the LOCAL extra field is uncompressed (and therefore whether CType and CRC are omitted): Bits of the Flags: bit 0 if set, file is a data fork; otherwise unset bit 1 if set, filename will be not changed bit 2 if set, Attribs is uncompressed (no CType, CRC) bit 3 if set, date and times are in 64 bit if zero date and times are in 32 bit. bit 4 if set, timezone offsets fields for the native Mac times are omitted (UTC support deactivated) bits 5-15 reserved; Attributes: Attribs is a Mac-specific block of data in little-endian format with the following structure (if compressed, uncompress it first): Value Size Description ----- ---- ----------- fdFlags Short Finder Flags fdLocation.v Short Finder Icon Location fdLocation.h Short Finder Icon Location fdFldr Short Folder containing file FXInfo 16 bytes Macintosh FXInfo structure FXInfo-Structure: fdIconID Short fdUnused[3] Short unused but reserved 6 bytes fdScript Byte Script flag and number fdXFlags Byte More flag bits fdComment Short Comment ID fdPutAway Long Home Dir ID FVersNum Byte file version number may be not used by MacOS ACUser Byte directory access rights FlCrDat ULong date and time of creation FlMdDat ULong date and time of last modification FlBkDat ULong date and time of last backup These time numbers are original Mac FileTime values (local time!). Currently, date-time width is 32-bit, but future version may support be 64-bit times (see flags) CrGMTOffs Long(signed!) difference "local Creat. time - UTC" MdGMTOffs Long(signed!) difference "local Modif. time - UTC" BkGMTOffs Long(signed!) difference "local Backup time - UTC" These "local time - UTC" differences (stored in seconds) may be used to support timestamp adjustment after inter-timezone transfer. These fields are optional; bit 4 of the flags word controls their presence. Charset Short TextEncodingBase (Charset) valid for the following two fields FullPath variable Path of the current file. Zero terminated string (C-String) Currently coded in the native Charset. Comment variable Finder Comment of the current file. Zero terminated string (C-String) Currently coded in the native Charset. -SmartZIP Macintosh Extra Field: ==================================== The following is the layout of the SmartZIP extra block for Macintosh, designed by Marco Bambini. Local-header version: Value Size Description ----- ---- ----------- 0x4d63 Short tag for this extra block type ("cM") TSize Short total data size for this block (64) "dZip" beLong extra-field signature fdType Byte[4] Type of the File (4-byte string) fdCreator Byte[4] Creator of the File (4-byte string) fdFlags beShort Finder Flags fdLocation.v beShort Finder Icon Location fdLocation.h beShort Finder Icon Location fdFldr beShort Folder containing file CrDat beLong HParamBlockRec fileParam.ioFlCrDat MdDat beLong HParamBlockRec fileParam.ioFlMdDat frScroll.v Byte vertical pos. of folder's scroll bar fdScript Byte Script flag and number frScroll.h Byte horizontal pos. of folder's scroll bar fdXFlags Byte More flag bits FileName Byte[32] full Macintosh filename (pascal string) All fields but the first two are in native Macintosh format (big-endian Motorola order, not little-endian Intel). The extra field size is fixed to 64 bytes. The local-header and central-header versions are identical. -Acorn SparkFS Extra Field: ========================= The following is the layout of David Pilling's SparkFS extra block for Acorn RISC OS. The local-header and central-header versions are identical. (Last Revision 19960922) Value Size Description ----- ---- ----------- (Acorn) 0x4341 Short tag for this extra block type ("AC") TSize Short total data size for this block (20) "ARC0" Long extra-field signature LoadAddr Long load address or file type ExecAddr Long exec address Attr Long file permissions Zero Long reserved; always zero The following bits of Attr are associated with the given file permissions: bit 0 user-writable ('W') bit 1 user-readable ('R') bit 2 reserved bit 3 locked ('L') bit 4 publicly writable ('w') bit 5 publicly readable ('r') bit 6 reserved bit 7 reserved -VM/CMS Extra Field: ================== The following is the layout of the file-attributes extra block for VM/CMS. The local-header and central-header versions are identical. (Last Revision 19960922) Value Size Description ----- ---- ----------- (VM/CMS) 0x4704 Short tag for this extra block type TSize Short total data size for this block flData variable file attributes data flData is an uncompressed fldata_t struct. -MVS Extra Field: =============== The following is the layout of the file-attributes extra block for MVS. The local-header and central-header versions are identical. (Last Revision 19960922) Value Size Description ----- ---- ----------- (MVS) 0x470f Short tag for this extra block type TSize Short total data size for this block flData variable file attributes data flData is an uncompressed fldata_t struct. -PKWARE Unix Extra Field: ======================== The following is the layout of PKWARE's Unix "extra" block. It was introduced with the release of PKZIP for Unix 2.50. Note: all fields are stored in Intel low-byte/high-byte order. (Last Revision 19980901) This field has a minimum data size of 12 bytes and is only stored as local extra field. Value Size Description ----- ---- ----------- (Unix0) 0x000d Short Tag for this "extra" block type TSize Short Total Data Size for this block AcTime Long time of last access (UTC/GMT) ModTime Long time of last modification (UTC/GMT) UID Short Unix user ID GID Short Unix group ID (var) variable Variable length data field The variable length data field will contain file type specific data. Currently the only values allowed are the original "linked to" file names for hard or symbolic links, and the major and minor device node numbers for character and block device nodes. Since device nodes cannot be either symbolic or hard links, only one set of variable length data is stored. Link files will have the name of the original file stored. This name is NOT NULL terminated. Its size can be determined by checking TSize - 12. Device entries will have eight bytes stored as two 4 byte entries (in little-endian format). The first entry will be the major device number, and the second the minor device number. [Info-ZIP note: The fixed part of this field has the same layout as Info-ZIP's abandoned "Unix1 timestamps & owner ID info" extra field; only the two tag bytes are different.] -PATCH Descriptor Extra Field: ============================ The following is the layout of the Patch Descriptor "extra" block. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (Patch) 0x000f Short Tag for this "extra" block type TSize Short Size of the total "extra" block Version Short Version of the descriptor Flags Long Actions and reactions (see below) OldSize Long Size of the file about to be patched OldCRC Long 32-bit CRC of the file about to be patched NewSize Long Size of the resulting file NewCRC Long 32-bit CRC of the resulting file Actions and reactions Bits Description ---- ---------------- 0 Use for autodetection 1 Treat as selfpatch 2-3 RESERVED 4-5 Action (see below) 6-7 RESERVED 8-9 Reaction (see below) to absent file 10-11 Reaction (see below) to newer file 12-13 Reaction (see below) to unknown file 14-15 RESERVED 16-31 RESERVED Actions Action Value ------ ----- none 0 add 1 delete 2 patch 3 Reactions Reaction Value -------- ----- ask 0 skip 1 ignore 2 fail 3 -PKCS#7 Store for X.509 Certificates: =================================== This field is contains the information about each certificate a file is signed with. This field should only appear in the first central directory record, and will be ignored in any other record. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (Store) 0x0014 2 bytes Tag for this "extra" block type SSize 2 bytes Size of the store data SData (variable) Data about the store SData Value Size Description ----- ---- ----------- Version 2 bytes Version number, 0x0001 for now StoreD (variable) Actual store data The StoreD member is suitable for passing as the pbData member of a CRYPT_DATA_BLOB to the CertOpenStore() function in Microsoft's CryptoAPI. The SSize member above will be cbData + 6, where cbData is the cbData member of the same CRYPT_DATA_BLOB. The encoding type to pass to CertOpenStore() should be PKCS_7_ANS_ENCODING | X509_ASN_ENCODING. -X.509 Certificate ID and Signature for individual file: ====================================================== This field contains the information about which certificate in the PKCS#7 Store was used to sign the particular file. It also contains the signature data. This field can appear multiple times, but can only appear once per certificate. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (CID) 0x0015 2 bytes Tag for this "extra" block type CSize 2 bytes Size of Method Method (variable) Method Value Size Description ----- ---- ----------- Version 2 bytes Version number, for now 0x0001 AlgID 2 bytes Algorithm ID used for signing IDSize 2 bytes Size of Certificate ID data CertID (variable) Certificate ID data SigSize 2 bytes Size of Signature data Sig (variable) Signature data CertID Value Size Description ----- ---- ----------- Size1 4 bytes Size of CertID, should be (IDSize - 4) Size1 4 bytes A bug in version one causes this value to appear twice. IssSize 4 bytes Issuer data size Issuer (variable) Issuer data SerSize 4 bytes Serial Number size Serial (variable) Serial Number data The Issuer and IssSize members are suitable for creating a CRYPT_DATA_BLOB to be the Issuer member of a CERT_INFO struct. The Serial and SerSize members would be the SerialNumber member of the same CERT_INFO struct. This struct would be used to find the certificate in the store the file was signed with. Those structures are from the MS CryptoAPI. Sig and SigSize are the actual signature data and size generated by signing the file with the MS CryptoAPI using a hash created with the given AlgID. -X.509 Certificate ID and Signature for central directory: ======================================================== This field contains the information about which certificate in the PKCS#7 Store was used to sign the central directory. It should only appear with the first central directory record, along with the store. The data structure is the same as the CID, except that SigSize will be 0, and there will be no Sig member. This field is also kept after the last central directory record, as the signature data (ID 0x05054b50, it looks like a central directory record of a different type). This second copy of the data is the Signature Data member of the record, and will have a SigSize that is non-zero, and will have Sig data. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (CDID) 0x0016 2 bytes Tag for this "extra" block type CSize 2 bytes Size of Method Method (variable) -ZIP64 Extended Information Extra Field: ====================================== The following is the layout of the ZIP64 extended information "extra" block. If one of the size or offset fields in the Local or Central directory record is too small to hold the required data, a ZIP64 extended information record is created. The order of the fields in the ZIP64 extended information record is fixed, but the fields will only appear if the corresponding Local or Central directory record field is set to 0xFFFF or 0xFFFFFFFF. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (ZIP64) 0x0001 2 bytes Tag for this "extra" block type Size 2 bytes Size of this "extra" block Original Size 8 bytes Original uncompresseed file size Compressed Size 8 bytes Size of compressed data Relative Header Offset 8 bytes Offset of local header record Disk Start Number 4 bytes Number of the disk on which this file starts This entry in the Local header must include BOTH original and compressed file sizes. -Extended Timestamp Extra Field: ============================== The following is the layout of the extended-timestamp extra block. (Last Revision 19970118) Local-header version: Value Size Description ----- ---- ----------- (time) 0x5455 Short tag for this extra block type ("UT") TSize Short total data size for this block Flags Byte info bits (ModTime) Long time of last modification (UTC/GMT) (AcTime) Long time of last access (UTC/GMT) (CrTime) Long time of original creation (UTC/GMT) Central-header version: Value Size Description ----- ---- ----------- (time) 0x5455 Short tag for this extra block type ("UT") TSize Short total data size for this block Flags Byte info bits (refers to local header!) (ModTime) Long time of last modification (UTC/GMT) The central-header extra field contains the modification time only, or no timestamp at all. TSize is used to flag its presence or absence. But note: If "Flags" indicates that Modtime is present in the local header field, it MUST be present in the central header field, too! This correspondence is required because the modification time value may be used to support trans-timezone freshening and updating operations with zip archives. The time values are in standard Unix signed-long format, indicating the number of seconds since 1 January 1970 00:00:00. The times are relative to Coordinated Universal Time (UTC), also sometimes referred to as Greenwich Mean Time (GMT). To convert to local time, the software must know the local timezone offset from UTC/GMT. The lower three bits of Flags in both headers indicate which time- stamps are present in the LOCAL extra field: bit 0 if set, modification time is present bit 1 if set, access time is present bit 2 if set, creation time is present bits 3-7 reserved for additional timestamps; not set Those times that are present will appear in the order indicated, but any combination of times may be omitted. (Creation time may be present without access time, for example.) TSize should equal (1 + 4*(number of set bits in Flags)), as the block is currently defined. Other timestamps may be added in the future. -Info-ZIP Unix Extra Field (type 1): ================================== The following is the layout of the old Info-ZIP extra block for Unix. It has been replaced by the extended-timestamp extra block (0x5455) and the Unix type 2 extra block (0x7855). (Last Revision 19970118) Local-header version: Value Size Description ----- ---- ----------- (Unix1) 0x5855 Short tag for this extra block type ("UX") TSize Short total data size for this block AcTime Long time of last access (UTC/GMT) ModTime Long time of last modification (UTC/GMT) UID Short Unix user ID (optional) GID Short Unix group ID (optional) Central-header version: Value Size Description ----- ---- ----------- (Unix1) 0x5855 Short tag for this extra block type ("UX") TSize Short total data size for this block AcTime Long time of last access (GMT/UTC) ModTime Long time of last modification (GMT/UTC) The file access and modification times are in standard Unix signed- long format, indicating the number of seconds since 1 January 1970 00:00:00. The times are relative to Coordinated Universal Time (UTC), also sometimes referred to as Greenwich Mean Time (GMT). To convert to local time, the software must know the local timezone offset from UTC/GMT. The modification time may be used by non-Unix systems to support inter-timezone freshening and updating of zip archives. The local-header extra block may optionally contain UID and GID info for the file. The local-header TSize value is the only indication of this. Note that Unix UIDs and GIDs are usually specific to a particular machine, and they generally require root access to restore. This extra field type is obsolete, but it has been in use since mid-1994. Therefore future archiving software should continue to support it. Some guidelines: An archive member should either contain the old "Unix1" extra field block or the new extra field types "time" and/or "Unix2". If both the old "Unix1" block type and one or both of the new block types "time" and "Unix2" are found, the "Unix1" block should be considered invalid and ignored. Unarchiving software should recognize both old and new extra field block types, but the info from new types overrides the old "Unix1" field. Archiving software should recognize "Unix1" extra fields for timestamp comparison but never create it for updated, freshened or new archive members. When copying existing members to a new archive, any "Unix1" extra field blocks should be converted to the new "time" and/or "Unix2" types. -Info-ZIP Unix Extra Field (type 2): ================================== The following is the layout of the new Info-ZIP extra block for Unix. (Last Revision 19960922) Local-header version: Value Size Description ----- ---- ----------- (Unix2) 0x7855 Short tag for this extra block type ("Ux") TSize Short total data size for this block (4) UID Short Unix user ID GID Short Unix group ID Central-header version: Value Size Description ----- ---- ----------- (Unix2) 0x7855 Short tag for this extra block type ("Ux") TSize Short total data size for this block (0) The data size of the central-header version is zero; it is used solely as a flag that UID/GID info is present in the local-header extra field. If additional fields are ever added to the local version, the central version may be extended to indicate this. Note that Unix UIDs and GIDs are usually specific to a particular machine, and they generally require root access to restore. -ASi Unix Extra Field: ==================== The following is the layout of the ASi extra block for Unix. The local-header and central-header versions are identical. (Last Revision 19960916) Value Size Description ----- ---- ----------- (Unix3) 0x756e Short tag for this extra block type ("nu") TSize Short total data size for this block CRC Long CRC-32 of the remaining data Mode Short file permissions SizDev Long symlink'd size OR major/minor dev num UID Short user ID GID Short group ID (var.) variable symbolic link filename Mode is the standard Unix st_mode field from struct stat, containing user/group/other permissions, setuid/setgid and symlink info, etc. If Mode indicates that this file is a symbolic link, SizDev is the size of the file to which the link points. Otherwise, if the file is a device, SizDev contains the standard Unix st_rdev field from struct stat (includes the major and minor numbers of the device). SizDev is undefined in other cases. If Mode indicates that the file is a symbolic link, the final field will be the name of the file to which the link points. The file- name length can be inferred from TSize. [Note that TSize may incorrectly refer to the data size not counting the CRC; i.e., it may be four bytes too small.] -BeOS Extra Field: ================ The following is the layout of the file-attributes extra block for BeOS. (Last Revision 19970531) Local-header version: Value Size Description ----- ---- ----------- (BeOS) 0x6542 Short tag for this extra block type ("Be") TSize Short total data size for this block BSize Long uncompressed file attribute data size Flags Byte info bits (CType) Short compression type (CRC) Long CRC value for uncompressed file attribs Attribs variable file attribute data Central-header version: Value Size Description ----- ---- ----------- (BeOS) 0x6542 Short tag for this extra block type ("Be") TSize Short total data size for this block (5) BSize Long size of uncompr. local EF block data Flags Byte info bits The least significant bit of Flags in both headers indicates whether the LOCAL extra field is uncompressed (and therefore whether CType and CRC are omitted): bit 0 if set, Attribs is uncompressed (no CType, CRC) bits 1-7 reserved; if set, assume error or unknown data Currently the only supported compression types are deflated (type 8) and stored (type 0); the latter is not used by Info-ZIP's Zip but is supported by UnZip. Attribs is a BeOS-specific block of data in big-endian format with the following structure (if compressed, uncompress it first): Value Size Description ----- ---- ----------- Name variable attribute name (null-terminated string) Type Long attribute type (32-bit unsigned integer) Size Long Long data size for this sub-block (64 bits) Data variable attribute data The attribute structure is repeated for every attribute. The Data field may contain anything--text, flags, bitmaps, etc. -SMS/QDOS Extra Field: ==================== The following is the layout of the file-attributes extra block for SMS/QDOS. The local-header and central-header versions are identical. (Last Revision 19960929) Value Size Description ----- ---- ----------- (QDOS) 0xfb4a Short tag for this extra block type TSize Short total data size for this block LongID Long extra-field signature (ExtraID) Long additional signature/flag bytes QDirect 64 bytes qdirect structure LongID may be "QZHD" or "QDOS". In the latter case, ExtraID will be present. Its first three bytes are "02\0"; the last byte is currently undefined. QDirect contains the file's uncompressed directory info (qdirect struct). Its elements are in native (big-endian) format: d_length beLong file length d_access byte file access type d_type byte file type d_datalen beLong data length d_reserved beLong unused d_szname beShort size of filename d_name 36 bytes filename d_update beLong time of last update d_refdate beLong file version number d_backup beLong time of last backup (archive date) -AOS/VS Extra Field: ================== The following is the layout of the extra block for Data General AOS/VS. The local-header and central-header versions are identical. (Last Revision 19961125) Value Size Description ----- ---- ----------- (AOSVS) 0x5356 Short tag for this extra block type ("VS") TSize Short total data size for this block "FCI\0" Long extra-field signature Version Byte version of AOS/VS extra block (10 = 1.0) Fstat variable fstat packet AclBuf variable raw ACL data ($MXACL bytes) Fstat contains the file's uncompressed fstat packet, which is one of the following: normal fstat packet (P_FSTAT struct) DIR/CPD fstat packet (P_FSTAT_DIR struct) unit (device) fstat packet (P_FSTAT_UNIT struct) IPC file fstat packet (P_FSTAT_IPC struct) AclBuf contains the raw ACL data; its length is $MXACL. -Tandem NSK Extra Field: ====================== The following is the layout of the file-attributes extra block for Tandem NSK. The local-header and central-header versions are identical. (Last Revision 19981221) Value Size Description ----- ---- ----------- (TA) 0x4154 Short tag for this extra block type ("TA") TSize Short total data size for this block (20) NSKattrs 20 Bytes NSK attributes -THEOS Extra Field: ================= The following is the layout of the file-attributes extra block for Theos. The local-header and central-header versions are identical. (Last Revision 19990206) Value Size Description ----- ---- ----------- (Theos) 0x6854 Short 'Th' signature size Short size of extra block flags Byte reserved for future use filesize Long file size fileorg Byte type of file (see below) keylen Short key length for indexed and keyed files, data segment size for 16 bits programs reclen Short record length for indexed,keyed and direct, text segment size for 16 bits programs filegrow Byte growing factor for indexed,keyed and direct protect Byte protections (see below) reserved Short reserved for future use File types ========== 0x80 library (keyed access list of files) 0x40 directory 0x10 stream file 0x08 direct file 0x04 keyed file 0x02 indexed file 0x0e reserved 0x01 16 bits real mode program (obsolete) 0x21 16 bits protected mode program 0x41 32 bits protected mode program Protection codes ================ User protection --------------- 0x01 non readable 0x02 non writable 0x04 non executable 0x08 non erasable Other protection ---------------- 0x10 non readable 0x20 non writable 0x40 non executable Theos before 4.0 0x40 modified Theos 4.x 0x80 not hidden -THEOS old unofficial Extra Field: ================================ The following is the layout of an inoffical former version of a Theos file-attributes extra blocks. This layout was never published and is no longer created. However, UnZip can optionally support it when compiling with the option flag OLD_THEOS_EXTRA defined. Both the local-header and central-header versions are identical. (Last Revision 19990206) Value Size Description ----- ---- ----------- (THS0) 0x4854 Short 'TH' signature size Short size of extra block flags Short reserved for future use filesize Long file size reclen Short record length for indexed,keyed and direct, text segment size for 16 bits programs keylen Short key length for indexed and keyed files, data segment size for 16 bits programs filegrow Byte growing factor for indexed,keyed and direct reserved 3 Bytes reserved for future use -FWKCS MD5 Extra Field: ===================== The FWKCS Contents_Signature System, used in automatically identifying files independent of filename, optionally adds and uses an extra field to support the rapid creation of an enhanced contents_signature. There is no local-header version; the following applies only to the central header. (Last Revision 19961207) Central-header version: Value Size Description ----- ---- ----------- (MD5) 0x4b46 Short tag for this extra block type ("FK") TSize Short total data size for this block (19) "MD5" 3 bytes extra-field signature MD5hash 16 bytes 128-bit MD5 hash of uncompressed data (low byte first) When FWKCS revises a .ZIP file central directory to add this extra field for a file, it also replaces the central directory entry for that file's uncompressed file length with a measured value. FWKCS provides an option to strip this extra field, if present, from a .ZIP file central directory. In adding this extra field, FWKCS preserves .ZIP file Authenticity Verification; if stripping this extra field, FWKCS preserves all versions of AV through PKZIP version 2.04g. FWKCS, and FWKCS Contents_Signature System, are trademarks of Frederick W. Kantor. (1) R. Rivest, RFC1321.TXT, MIT Laboratory for Computer Science and RSA Data Security, Inc., April 1992. ll.76-77: "The MD5 algorithm is being placed in the public domain for review and possible adoption as a standard." file comment: (Variable) The comment for this file. number of this disk: (2 bytes) The number of this disk, which contains central directory end record. If an archive is in zip64 format and the value in this field is 0xFFFF, the size will be in the corresponding 4 byte zip64 end of central directory field. number of the disk with the start of the central directory: (2 bytes) The number of the disk on which the central directory starts. If an archive is in zip64 format and the value in this field is 0xFFFF, the size will be in the corresponding 4 byte zip64 end of central directory field. total number of entries in the central dir on this disk: (2 bytes) The number of central directory entries on this disk. If an archive is in zip64 format and the value in this field is 0xFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field. total number of entries in the central dir: (2 bytes) The total number of files in the .ZIP file. If an archive is in zip64 format and the value in this field is 0xFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field. size of the central directory: (4 bytes) The size (in bytes) of the entire central directory. If an archive is in zip64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field. offset of start of central directory with respect to the starting disk number: (4 bytes) Offset of the start of the central directory on the disk on which the central directory starts. If an archive is in zip64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field. .ZIP file comment length: (2 bytes) The length of the comment for this .ZIP file. .ZIP file comment: (Variable) The comment for this .ZIP file. zip64 extensible data sector (variable size) (currently reserved for use by PKWARE) I. General notes: 1) All fields unless otherwise noted are unsigned and stored in Intel low-byte:high-byte, low-word:high-word order. 2) String fields are not null terminated, since the length is given explicitly. 3) Local headers should not span disk boundaries. Also, even though the central directory can span disk boundaries, no single record in the central directory should be split across disks. 4) The entries in the central directory may not necessarily be in the same order that files appear in the .ZIP file. 5) Spanned/Split archives created using PKZIP for Windows (V2.50 or greater), PKZIP Command Line (V2.50 or greater), or PKZIP Explorer will include a special spanning signature as the first 4 bytes of the first segment of the archive. This signature (0x08074b50) will be followed immediately by the local header signature for the first file in the archive. A special spanning marker may also appear in spanned/split archives if the spanning or splitting process starts but only requires one segment. In this case the 0x08074b50 signature will be replaced with the temporary spanning marker signature of 0x30304b50. Spanned/split archives created with this special signature are compatible with all versions of PKZIP from PKWARE. Split archives can only be uncompressed by other versions of PKZIP that know how to create a split archive. 6) If one of the fields in the end of central directory record is too small to hold required data, the field should be set to -1 (0xFFFF or 0xFFFFFFFF) and the Zip64 format record should be created. 7) The end of central directory record and the Zip64 end of central directory locator record must reside on the same disk when splitting or spanning an archive. UnShrinking - Method 1 ---------------------- Shrinking is a Dynamic Ziv-Lempel-Welch compression algorithm with partial clearing. The initial code size is 9 bits, and the maximum code size is 13 bits. Shrinking differs from conventional Dynamic Ziv-Lempel-Welch implementations in several respects: 1) The code size is controlled by the compressor, and is not automatically increased when codes larger than the current code size are created (but not necessarily used). When the decompressor encounters the code sequence 256 (decimal) followed by 1, it should increase the code size read from the input stream to the next bit size. No blocking of the codes is performed, so the next code at the increased size should be read from the input stream immediately after where the previous code at the smaller bit size was read. Again, the decompressor should not increase the code size used until the sequence 256,1 is encountered. 2) When the table becomes full, total clearing is not performed. Rather, when the compressor emits the code sequence 256,2 (decimal), the decompressor should clear all leaf nodes from the Ziv-Lempel tree, and continue to use the current code size. The nodes that are cleared from the Ziv-Lempel tree are then re-used, with the lowest code value re-used first, and the highest code value re-used last. The compressor can emit the sequence 256,2 at any time. Expanding - Methods 2-5 ----------------------- The Reducing algorithm is actually a combination of two distinct algorithms. The first algorithm compresses repeated byte sequences, and the second algorithm takes the compressed stream from the first algorithm and applies a probabilistic compression method. The probabilistic compression stores an array of 'follower sets' S(j), for j=0 to 255, corresponding to each possible ASCII character. Each set contains between 0 and 32 characters, to be denoted as S(j)[0],...,S(j)[m], where m<32. The sets are stored at the beginning of the data area for a Reduced file, in reverse order, with S(255) first, and S(0) last. The sets are encoded as { N(j), S(j)[0],...,S(j)[N(j)-1] }, where N(j) is the size of set S(j). N(j) can be 0, in which case the follower set for S(j) is empty. Each N(j) value is encoded in 6 bits, followed by N(j) eight bit character values corresponding to S(j)[0] to S(j)[N(j)-1] respectively. If N(j) is 0, then no values for S(j) are stored, and the value for N(j-1) immediately follows. Immediately after the follower sets, is the compressed data stream. The compressed data stream can be interpreted for the probabilistic decompression as follows: let Last-Character <- 0. loop until done if the follower set S(Last-Character) is empty then read 8 bits from the input stream, and copy this value to the output stream. otherwise if the follower set S(Last-Character) is non-empty then read 1 bit from the input stream. if this bit is not zero then read 8 bits from the input stream, and copy this value to the output stream. otherwise if this bit is zero then read B(N(Last-Character)) bits from the input stream, and assign this value to I. Copy the value of S(Last-Character)[I] to the output stream. assign the last value placed on the output stream to Last-Character. end loop B(N(j)) is defined as the minimal number of bits required to encode the value N(j)-1. The decompressed stream from above can then be expanded to re-create the original file as follows: let State <- 0. loop until done read 8 bits from the input stream into C. case State of 0: if C is not equal to DLE (144 decimal) then copy C to the output stream. otherwise if C is equal to DLE then let State <- 1. 1: if C is non-zero then let V <- C. let Len <- L(V) let State <- F(Len). otherwise if C is zero then copy the value 144 (decimal) to the output stream. let State <- 0 2: let Len <- Len + C let State <- 3. 3: move backwards D(V,C) bytes in the output stream (if this position is before the start of the output stream, then assume that all the data before the start of the output stream is filled with zeros). copy Len+3 bytes from this position to the output stream. let State <- 0. end case end loop The functions F,L, and D are dependent on the 'compression factor', 1 through 4, and are defined as follows: For compression factor 1: L(X) equals the lower 7 bits of X. F(X) equals 2 if X equals 127 otherwise F(X) equals 3. D(X,Y) equals the (upper 1 bit of X) * 256 + Y + 1. For compression factor 2: L(X) equals the lower 6 bits of X. F(X) equals 2 if X equals 63 otherwise F(X) equals 3. D(X,Y) equals the (upper 2 bits of X) * 256 + Y + 1. For compression factor 3: L(X) equals the lower 5 bits of X. F(X) equals 2 if X equals 31 otherwise F(X) equals 3. D(X,Y) equals the (upper 3 bits of X) * 256 + Y + 1. For compression factor 4: L(X) equals the lower 4 bits of X. F(X) equals 2 if X equals 15 otherwise F(X) equals 3. D(X,Y) equals the (upper 4 bits of X) * 256 + Y + 1. Imploding - Method 6 -------------------- The Imploding algorithm is actually a combination of two distinct algorithms. The first algorithm compresses repeated byte sequences using a sliding dictionary. The second algorithm is used to compress the encoding of the sliding dictionary output, using multiple Shannon-Fano trees. The Imploding algorithm can use a 4K or 8K sliding dictionary size. The dictionary size used can be determined by bit 1 in the general purpose flag word; a 0 bit indicates a 4K dictionary while a 1 bit indicates an 8K dictionary. The Shannon-Fano trees are stored at the start of the compressed file. The number of trees stored is defined by bit 2 in the general purpose flag word; a 0 bit indicates two trees stored, a 1 bit indicates three trees are stored. If 3 trees are stored, the first Shannon-Fano tree represents the encoding of the Literal characters, the second tree represents the encoding of the Length information, the third represents the encoding of the Distance information. When 2 Shannon-Fano trees are stored, the Length tree is stored first, followed by the Distance tree. The Literal Shannon-Fano tree, if present is used to represent the entire ASCII character set, and contains 256 values. This tree is used to compress any data not compressed by the sliding dictionary algorithm. When this tree is present, the Minimum Match Length for the sliding dictionary is 3. If this tree is not present, the Minimum Match Length is 2. The Length Shannon-Fano tree is used to compress the Length part of the (length,distance) pairs from the sliding dictionary output. The Length tree contains 64 values, ranging from the Minimum Match Length, to 63 plus the Minimum Match Length. The Distance Shannon-Fano tree is used to compress the Distance part of the (length,distance) pairs from the sliding dictionary output. The Distance tree contains 64 values, ranging from 0 to 63, representing the upper 6 bits of the distance value. The distance values themselves will be between 0 and the sliding dictionary size, either 4K or 8K. The Shannon-Fano trees themselves are stored in a compressed format. The first byte of the tree data represents the number of bytes of data representing the (compressed) Shannon-Fano tree minus 1. The remaining bytes represent the Shannon-Fano tree data encoded as: High 4 bits: Number of values at this bit length + 1. (1 - 16) Low 4 bits: Bit Length needed to represent value + 1. (1 - 16) The Shannon-Fano codes can be constructed from the bit lengths using the following algorithm: 1) Sort the Bit Lengths in ascending order, while retaining the order of the original lengths stored in the file. 2) Generate the Shannon-Fano trees: Code <- 0 CodeIncrement <- 0 LastBitLength <- 0 i <- number of Shannon-Fano codes - 1 (either 255 or 63) loop while i >= 0 Code = Code + CodeIncrement if BitLength(i) <> LastBitLength then LastBitLength=BitLength(i) CodeIncrement = 1 shifted left (16 - LastBitLength) ShannonCode(i) = Code i <- i - 1 end loop 3) Reverse the order of all the bits in the above ShannonCode() vector, so that the most significant bit becomes the least significant bit. For example, the value 0x1234 (hex) would become 0x2C48 (hex). 4) Restore the order of Shannon-Fano codes as originally stored within the file. Example: This example will show the encoding of a Shannon-Fano tree of size 8. Notice that the actual Shannon-Fano trees used for Imploding are either 64 or 256 entries in size. Example: 0x02, 0x42, 0x01, 0x13 The first byte indicates 3 values in this table. Decoding the bytes: 0x42 = 5 codes of 3 bits long 0x01 = 1 code of 2 bits long 0x13 = 2 codes of 4 bits long This would generate the original bit length array of: (3, 3, 3, 3, 3, 2, 4, 4) There are 8 codes in this table for the values 0 through 7. Using the algorithm to obtain the Shannon-Fano codes produces: Reversed Order Original Val Sorted Constructed Code Value Restored Length --- ------ ----------------- -------- -------- ------ 0: 2 1100000000000000 11 101 3 1: 3 1010000000000000 101 001 3 2: 3 1000000000000000 001 110 3 3: 3 0110000000000000 110 010 3 4: 3 0100000000000000 010 100 3 5: 3 0010000000000000 100 11 2 6: 4 0001000000000000 1000 1000 4 7: 4 0000000000000000 0000 0000 4 The values in the Val, Order Restored and Original Length columns now represent the Shannon-Fano encoding tree that can be used for decoding the Shannon-Fano encoded data. How to parse the variable length Shannon-Fano values from the data stream is beyond the scope of this document. (See the references listed at the end of this document for more information.) However, traditional decoding schemes used for Huffman variable length decoding, such as the Greenlaw algorithm, can be successfully applied. The compressed data stream begins immediately after the compressed Shannon-Fano data. The compressed data stream can be interpreted as follows: loop until done read 1 bit from input stream. if this bit is non-zero then (encoded data is literal data) if Literal Shannon-Fano tree is present read and decode character using Literal Shannon-Fano tree. otherwise read 8 bits from input stream. copy character to the output stream. otherwise (encoded data is sliding dictionary match) if 8K dictionary size read 7 bits for offset Distance (lower 7 bits of offset). otherwise read 6 bits for offset Distance (lower 6 bits of offset). using the Distance Shannon-Fano tree, read and decode the upper 6 bits of the Distance value. using the Length Shannon-Fano tree, read and decode the Length value. Length <- Length + Minimum Match Length if Length = 63 + Minimum Match Length read 8 bits from the input stream, add this value to Length. move backwards Distance+1 bytes in the output stream, and copy Length characters from this position to the output stream. (if this position is before the start of the output stream, then assume that all the data before the start of the output stream is filled with zeros). end loop Tokenizing - Method 7 -------------------- This method is not used by PKZIP. Deflating - Method 8 -------------------- The Deflate algorithm is similar to the Implode algorithm using a sliding dictionary of up to 32K with secondary compression from Huffman/Shannon-Fano codes. The compressed data is stored in blocks with a header describing the block and the Huffman codes used in the data block. The header format is as follows: Bit 0: Last Block bit This bit is set to 1 if this is the last compressed block in the data. Bits 1-2: Block type 00 (0) - Block is stored - All stored data is byte aligned. Skip bits until next byte, then next word = block length, followed by the ones compliment of the block length word. Remaining data in block is the stored data. 01 (1) - Use fixed Huffman codes for literal and distance codes. Lit Code Bits Dist Code Bits --------- ---- --------- ---- 0 - 143 8 0 - 31 5 144 - 255 9 256 - 279 7 280 - 287 8 Literal codes 286-287 and distance codes 30-31 are never used but participate in the huffman construction. 10 (2) - Dynamic Huffman codes. (See expanding Huffman codes) 11 (3) - Reserved - Flag a "Error in compressed data" if seen. Expanding Huffman Codes ----------------------- If the data block is stored with dynamic Huffman codes, the Huffman codes are sent in the following compressed format: 5 Bits: # of Literal codes sent - 257 (257 - 286) All other codes are never sent. 5 Bits: # of Dist codes - 1 (1 - 32) 4 Bits: # of Bit Length codes - 4 (4 - 19) The Huffman codes are sent as bit lengths and the codes are built as described in the implode algorithm. The bit lengths themselves are compressed with Huffman codes. There are 19 bit length codes: 0 - 15: Represent bit lengths of 0 - 15 16: Copy the previous bit length 3 - 6 times. The next 2 bits indicate repeat length (0 = 3, ... ,3 = 6) Example: Codes 8, 16 (+2 bits 11), 16 (+2 bits 10) will expand to 12 bit lengths of 8 (1 + 6 + 5) 17: Repeat a bit length of 0 for 3 - 10 times. (3 bits of length) 18: Repeat a bit length of 0 for 11 - 138 times (7 bits of length) The lengths of the bit length codes are sent packed 3 bits per value (0 - 7) in the following order: 16, 17, 18, 0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15 The Huffman codes should be built as described in the Implode algorithm except codes are assigned starting at the shortest bit length, i.e. the shortest code should be all 0's rather than all 1's. Also, codes with a bit length of zero do not participate in the tree construction. The codes are then used to decode the bit lengths for the literal and distance tables. The bit lengths for the literal tables are sent first with the number of entries sent described by the 5 bits sent earlier. There are up to 286 literal characters; the first 256 represent the respective 8 bit character, code 256 represents the End-Of-Block code, the remaining 29 codes represent copy lengths of 3 through 258. There are up to 30 distance codes representing distances from 1 through 32k as described below. Length Codes ------------ Extra Extra Extra Extra Code Bits Length Code Bits Lengths Code Bits Lengths Code Bits Length(s) ---- ---- ------ ---- ---- ------- ---- ---- ------- ---- ---- --------- 257 0 3 265 1 11,12 273 3 35-42 281 5 131-162 258 0 4 266 1 13,14 274 3 43-50 282 5 163-194 259 0 5 267 1 15,16 275 3 51-58 283 5 195-226 260 0 6 268 1 17,18 276 3 59-66 284 5 227-258 261 0 7 269 2 19-22 277 4 67-82 285 0 258 262 0 8 270 2 23-26 278 4 83-98 263 0 9 271 2 27-30 279 4 99-114 264 0 10 272 2 31-34 280 4 115-130 Distance Codes -------------- Extra Extra Extra Extra Code Bits Dist Code Bits Dist Code Bits Distance Code Bits Distance ---- ---- ---- ---- ---- ------ ---- ---- -------- ---- ---- -------- 0 0 1 8 3 17-24 16 7 257-384 24 11 4097-6144 1 0 2 9 3 25-32 17 7 385-512 25 11 6145-8192 2 0 3 10 4 33-48 18 8 513-768 26 12 8193-12288 3 0 4 11 4 49-64 19 8 769-1024 27 12 12289-16384 4 1 5,6 12 5 65-96 20 9 1025-1536 28 13 16385-24576 5 1 7,8 13 5 97-128 21 9 1537-2048 29 13 24577-32768 6 2 9-12 14 6 129-192 22 10 2049-3072 7 2 13-16 15 6 193-256 23 10 3073-4096 The compressed data stream begins immediately after the compressed header data. The compressed data stream can be interpreted as follows: do read header from input stream. if stored block skip bits until byte aligned read count and 1's compliment of count copy count bytes data block otherwise loop until end of block code sent decode literal character from input stream if literal < 256 copy character to the output stream otherwise if literal = end of block break from loop otherwise decode distance from input stream move backwards distance bytes in the output stream, and copy length characters from this position to the output stream. end loop while not last block if data descriptor exists skip bits until byte aligned check data descriptor signature read crc and sizes endif Deflate64 - Method 9 -------------------- [This description is unofficial. It has been deduced by Info-ZIP from close inspection of PKZIP 4.x Deflate64(tm) compressed output.] The Deflate64 algorithm is almost identical to the normal Deflate algorithm. Differences are: - The sliding window size is 64k. - The previously unused distance codes 30 and 31 are now used to describe match distances from 32k-48k and 48k-64k. Extra Code Bits Distance ---- ---- ----------- .. .. ... 29 13 24577-32768 30 14 32769-49152 31 14 49153-65536 - The semantics of the "maximum match length" code #258 has been changed to allow the specification of arbitrary large match lengths (up to 64k). Extra Code Bits Lengths ---- ---- ------ ... .. ... 284 5 227-258 285 16 3-65538 Whereas the first two modifications fit into the framework of Deflate, this last change breaks compatibility with Deflate method 8. Thus, a Deflate64 decompressor cannot decode normal deflated data. Decryption ---------- The encryption used in PKZIP was generously supplied by Roger Schlafly. PKWARE is grateful to Mr. Schlafly for his expert help and advice in the field of data encryption. PKZIP encrypts the compressed data stream. Encrypted files must be decrypted before they can be extracted. Each encrypted file has an extra 12 bytes stored at the start of the data area defining the encryption header for that file. The encryption header is originally set to random values, and then itself encrypted, using three, 32-bit keys. The key values are initialized using the supplied encryption password. After each byte is encrypted, the keys are then updated using pseudo-random number generation techniques in combination with the same CRC-32 algorithm used in PKZIP and described elsewhere in this document. The following is the basic steps required to decrypt a file: 1) Initialize the three 32-bit keys with the password. 2) Read and decrypt the 12-byte encryption header, further initializing the encryption keys. 3) Read and decrypt the compressed data stream using the encryption keys. Step 1 - Initializing the encryption keys ----------------------------------------- Key(0) <- 305419896 Key(1) <- 591751049 Key(2) <- 878082192 loop for i <- 0 to length(password)-1 update_keys(password(i)) end loop Where update_keys() is defined as: update_keys(char): Key(0) <- crc32(key(0),char) Key(1) <- Key(1) + (Key(0) & 000000ffH) Key(1) <- Key(1) * 134775813 + 1 Key(2) <- crc32(key(2),key(1) >> 24) end update_keys Where crc32(old_crc,char) is a routine that given a CRC value and a character, returns an updated CRC value after applying the CRC-32 algorithm described elsewhere in this document. Step 2 - Decrypting the encryption header ----------------------------------------- The purpose of this step is to further initialize the encryption keys, based on random data, to render a plaintext attack on the data ineffective. Read the 12-byte encryption header into Buffer, in locations Buffer(0) through Buffer(11). loop for i <- 0 to 11 C <- buffer(i) ^ decrypt_byte() update_keys(C) buffer(i) <- C end loop Where decrypt_byte() is defined as: unsigned char decrypt_byte() local unsigned short temp temp <- Key(2) | 2 decrypt_byte <- (temp * (temp ^ 1)) >> 8 end decrypt_byte After the header is decrypted, the last 1 or 2 bytes in Buffer should be the high-order word/byte of the CRC for the file being decrypted, stored in Intel low-byte/high-byte order, or the high-order byte of the file time if bit 3 of the general purpose bit flag is set. Versions of PKZIP prior to 2.0 used a 2 byte CRC check; a 1 byte CRC check is used on versions after 2.0. This can be used to test if the password supplied is correct or not. Step 3 - Decrypting the compressed data stream ---------------------------------------------- The compressed data stream can be decrypted as follows: loop until done read a character into C Temp <- C ^ decrypt_byte() update_keys(temp) output Temp end loop Change Process -------------- In order for the .ZIP file format to remain a viable definition, this specification should be considered as open for periodic review and revision. Although this format was originally designed with a certain level of extensibility, not all changes in technology (present or future) were or will be necessarily considered in its design. If your application requires new definitions to the extensible sections in this format, or if you would like to submit new data structures, please forward your request to zipformat@pkware.com. All submissions will be reviewed by the ZIP File Specification Committee for possible inclusion into future versions of this specification. Periodic revisions to this specification will be published to ensure interoperability. Acknowledgements ---------------- In addition to the above mentioned contributors to PKZIP and PKUNZIP, I would like to extend special thanks to Robert Mahoney for suggesting the extension .ZIP for this software. References: Fiala, Edward R., and Greene, Daniel H., "Data compression with finite windows", Communications of the ACM, Volume 32, Number 4, April 1989, pages 490-505. Held, Gilbert, "Data Compression, Techniques and Applications, Hardware and Software Considerations", John Wiley & Sons, 1987. Huffman, D.A., "A method for the construction of minimum-redundancy codes", Proceedings of the IRE, Volume 40, Number 9, September 1952, pages 1098-1101. Nelson, Mark, "LZW Data Compression", Dr. Dobbs Journal, Volume 14, Number 10, October 1989, pages 29-37. Nelson, Mark, "The Data Compression Book", M&T Books, 1991. Storer, James A., "Data Compression, Methods and Theory", Computer Science Press, 1988 Welch, Terry, "A Technique for High-Performance Data Compression", IEEE Computer, Volume 17, Number 6, June 1984, pages 8-19. Ziv, J. and Lempel, A., "A universal algorithm for sequential data compression", Communications of the ACM, Volume 30, Number 6, June 1987, pages 520-540. Ziv, J. and Lempel, A., "Compression of individual sequences via variable-rate coding", IEEE Transactions on Information Theory, Volume 24, Number 5, September 1978, pages 530-536. Zipios-2.3.2/doc/images/000077500000000000000000000000001445164132200150075ustar00rootroot00000000000000Zipios-2.3.2/doc/images/zipfile.png000066400000000000000000000656061445164132200171740ustar00rootroot00000000000000PNG  IHDR`bKGD IDATxy\LgV)("׾D,!!ɖP."۵^!{d-kBJB\Q0=mJ{j25qoܚj9|/LgΜ3goga| ( r2*WVV… 3i$S((@$''_vmذaD {mdd$e ƍi&#('S9Ee#P@@Q `ΝÇM6m۷Ç7jk⼤҃/BJLLSĶ=<<$beeSRRlvttt$ΔBzY߾}-[Ο?_R-n޼p߾}!!!DF@$(@C]]]MM 瞞...gϞŗ0;v?~GaÇ߼ys֬Y&L8w\\\ǘ1c?冄pm%%%͛7ܹs5R~Ǐ'MTQQ{3/?~4mڴ\.ٳg^^^m۶5113gӧOzZpŋBGA|d|taPyA?>y$44tժUaaaܹٳgϟ|ő#Gϟtر 㯺tR^^ѣGٓr ~t̙3 , -++NU ӧϡCJKK:n:uuuUUU&LpŒ3vڅ/L&mll5_|ill,lk)))7ohhh|!g6ݫW/)|n@,PINNwVTTp{-^+>>^xM'''дi455W!n޼dCCCKKKSN?v옟!BR8ȗ/^8%%eŊǏ^`btsll,~v,݉L&MMM)ϟ?믘]ٖׯ\W\]]~d2_|٫W/_!@>`X,mѢ`>BD"?|GSSB&BJxG---ᶨTjNNNPPرc`_;vSSc-Z۷ҥK'NԩӴi P՟!tݐ~"ر ƒ%K^x`0^|9p> MPyi1NOOL&YXX rss r˖-gjjb2%%%mUWW 8ܼy# \ҧOÇ]Vxj>r޽v蔔~/^zm'D}mh6111;;cǎ{~9?8 ѣG_.FR~_;vlȑl>444???==}ժUmq8.KRl6_aخ]&NaÆ/^<~Xx}rʿPT55ߝcǎyyyeȷ/-ЀbbbvJR{}-######1i3eH\nyy9_Q%K (S;92L1Ism7l'v>ej-:5[7˸"#Z\9,/_ d4p &L&IQQut :5@p l9+*ΜOTEFQ(͛]޻ (P-Yr3giӒ0[= Ñ=@Q[޺ĉ9;!: BǸ'd 2!_L/ϰ={nTe7mٺť'Yc⑚j{":(@=|qٲ fLt֮slMt #pIPiiiο$KŁaظqdrtbL$ Δ)wo ww$iV/2]{Mt p TTY tJTbmm54`s>\A': .8SubϗZΥȑ T9sAD##㈥u8xnNN)YtAQ*gݺˉO׮Yw׈ 2P-=w.ȑzqh4./%:(@%y3I7V":KtfA۶]+/": (@edMv˝;' ZcHe䊊Ӧm 4t6&"G˖˗ =,@>~dOtuV#1<)̬/J2PZ\.Էog(SEFQ(M\&$': 0(@iYs)),,"yvvE)(@9{;"ѣzhKtiٸq|VVS$ 2PB'{{>.Dg" sIt 1PuͪU/wvsKtN۽&A@QJŋ~ 9sYdAKKm͚1g&H\Ǘ/p, EUN80 sqOR\YCc@TxzաU"#H$ҦMϞ}~At *t%VYY=sf(N9y[]FtYͭO@@4&: h.(@q8GT*/꯿e *R\~|> =}1ڬY 7oJthP;w.iv(~T_/\pxzm,)JɤŋGR#$:^xJ帍3e R~ /(d2ݽr˝"# `Bffp(EEȵc WwwoSڴiI\.`a?oР۵r 2__LHZ|||&M$c6v쟚J )P C"lmm۶mKtUXѲ%NWrJJJ8p`ddT[y"sܸ5k̘Rm4*ʔ)DDЧĉ}l9FM 5S@%[7@t(6mZ.Z4;p(9EU`p##;o2N[7OegR]4eeeyyya6}tmmm%ARl~lA~޾ӆ W9`tuu=+A&L={lZZ,GzzX_` vѴg%(..ɉb!eٴ8|~qq1XɃΝxzܶZEEYPhbbb:wlhhW]]-zYYٳ VXQUU޽exxp[vvv"3^^TTakkjӦ \pʕnܸܼu3g,++'mmbn`"[!HgϞҥKVv%ݸ8+++==۷׿k,5gM>?e___ >}j''?&''[YY0sĈ_|a0ݺu `2jjj!!!yyyǎRL&S8O]9k,9~xxxp;wtssb0{^zݻmll ƛ7o bŊ6g"l&M*-- Ecǎ-//|2B_caɓ'Oj|yzzLrHHmUUV1 |+++l6BFEEYYYhR>_QQԕ77Llmm?ٳgΝ%iiiciAD|ЧOjc5ܥˆ*a17 `l߾ҥKjj"fsر#:''G$vvv$ WԵdr8===qgdd/wttkff s.]\]]Jۜ TO+&&&!VkD J޴i­[o߇E(rdzzz:uT BǏxQ(.G勩)/^,))vqq)))ILL?Z&&&"Z~-ggg1N9dgɩƍ2Op(˵ Ν;wСudɒϟ??{lڵӧO,h~~~_~MMM]~'Drrr|ryy9ͦh3~x1W8q5k233 Cf̘nݺEeff֕91L׊ B(,,Ǐ;;OD>,ہBb)#t=aaa/fX}%%%3f766gXEDDtЁN[[[EPDf^fG->r///===}}WVVVUUXĤe˖um9v'HYXBzv~q}[\^[\lxU 02aH$RDDDgnsǎ#ȝߴO?=r=j{mGwߺՍ @t_ҴVsw~Qr!:<_f7F EYqBEɤ͛]=|(i{Ӧj.YTeB_RTTq}:(jӦ…#7p6*(CVZ۶]':Jݻ+jJOO$:?Ԩ695k޽-`aͳNA Ec"':\X|yPP)5i!& 2Y5@Q;~D"|q=S'OGtU}@־=c9չsilc~Q dl2ԽA@VKtUEݾ}-ԉ꤫tcHHׯDgQ9P~ݣG[Sxyw`KtEګWYݻCQwn|(@rrJKJ*LY!wrtٸ1˅e2ׯT2|˧(6mQ%(@^ζ2Р];su,2)O,]꤮Nݳ6ATe ;19wXVuw΢(,gD>_6nBtE4[7S!I[>z-_AQ`dwFM &U<}0/J(فoچ +BCDAQ2c e֦M~sؿ?%UP2P~~QREȫWYt:KSW[rL(-(@F]Mh4 A@r+p") dS7z} ('(@\~j7˧llLMݶZee5Ye >X=`,Xjϟ;DQBP,0ٚΝHe9<(@^ՔBMy̙coizkDQ6|˧|Tͮ7n0~QEH{6S>F ,(@޿cp6ov(:s& 2ׯլ$];oo]n$2:#[732Dt $2:Oik\9)_d@QU]}>r:%1Ptr8<(ʍL&m<ѣϷoEAQUFvDշoqzDpf $*G#{$|˧%P>h„`k뵶[-:C,\@ꌍu,U0,2Yo`M`j Y. IDAT,*a0(+1uuڜ9[FD $Ҳ5N lfjF֮͛zlKԼ&zMH*EEH^v|Iy<Νi4P@i]ťgBo@Qe y\?h#mLl$ t:С˖9!+sEEU^^a e y5fزŕ$@H$yP(dII]X(k۶L&':5whh˓t2e1AQGQ Z DjZ{bu^MQ8e1AQRѾBؖ-55Dg1MHX/m1 |EtKLLӕTh1U D+WJh׮oEvH$ZV\Eh߾ì 76ItFtIڻwoFFD6?p@lMXqqUD;III^E0'O&:h/Jpkp Ч r2( G(H>\mV0 >}p2Pgb3H\ MId;<(+]]iJPtt rssϞ=& 꼭ʒ@ i6 eEb``cǎ=+AqqqNNN, !dnn.|~qq7?|EY~F9?ܹ_uuieeeg600033[bEUUB(66{ꖖmىP{yQQ-BM69ʕ+ W\pZH"Ξ=ۥKVZڵ !T{w577ݻ7}&ڱ⬬o^PF&0a²ezzzׯ_:vD*]֫W/MMMcce]dr0a+VٳgQQ53'&& J"cFADDD|)S|}}1 BǏb9bĈ/_0nݺ0L55cǎQT&)h<?~<<<\8L`;weee1޽{^I&"ko|ԨQݻqㆾ>0̙3666|>vcǖ_|/" ,&OgΜ3g ֕\ Td3 LUjE*!!!UUUX CA+++l6BFEEYYYhR>_QQͭ([[[{YBPBB!ӧ,mӦݻw1 =z;Df>a<Oxk"wW|AEYnJ--Ob6u5kԕP"ݻwL&=x1PWr10|;VB}AFZSWk)Tt_5}K.~!dmm)y<^rrr̆C2lggG"?!u-g2GOOͪk066_׺"LLLB4Y[[#(ĉܹ)re|kdo}('?~K*++cccE^ju?˜NٹO>'O䨑سgφ m6fZ2;(/&y)SSS+࿖B?~ďBIOO勩)/^,))vqq)))ILLqBwյ֭[b700Zzmz=y+WDFFٙ\Y%P"wW]PqҥWGP["}ge5eʔ+W>|"F`!!!.\HHHԵf]evPAQ_ .;wСCZaɒ%?~ڵkO.XN~~zOOOtr6M455)&&fb}Sl6NX7"***/+y0--Ν;^ڳC b)#tvaaa/fX½u%%%3f766gXx:t111mQ(ѣG ~lOKOOO__u-D YN[[6q׳j,qkkk y$v!&&F޽{[jնmÇ{xx oAdr10XN:mܸ51YTE\h}"ծS*eڵӦM} /DR@H꠪] `>eHrss?~y Чttt|||NA'OwΜ9Æ U"wBCwPZitww=pL}H$RDDAjW8S9Ee#P@%qqtt$:Bl5:]FXr4*zr͛7C YT!oJ#k,LL:nJTUQ[N7m#?~qd}}Vk/ZXH~9ʐ!C$uIJe˲%)EђͦtTBtW .()ܱ O:v4ڼyVMԺuQo~^,7o?oavA)?vڵcͫs*>ex<~Xvvn`l6ͩ!b|Wp "o-I$Rnn2B}ׯ/ q N]<*$#h#Gv=sf^N50n™[dl*CqBC̟?E u( 8SV Lf WݑQi)Vdn^^ҩte("D;.k8SVr]|۶땕U65k0FA-}][NL8N#Va0^GNqe~}ԓ'nn}֭kdRfM}2lP,'O&r<-X}~~glKeEFlrrmGwx%马>r$^RY8SV6<ĉ={nh}<Lcl>T۷vmi``ďЕ!Ól0(8ʓ'G}7k݊lII`]sȽ3iE@t֬0W֭[ܻ-VdԌ# wlY; «Ƈx>ԩXYYGweLԪU}`-΢Bƾھz^^٢E#~ACC^FT}}-i)ㄻ2Е!'""ZpA)+9շoǏ-_,?gb# =<2 1N⩨ڰኣcPaaEdoxF"Gdi ]r$2iQN/]c6=ۮsKƏ42?x{yIJ|c ue YzeNNA)˯>88 7o'O@IsHF~2ʐ>ۿ?~„+(ˣY<cG˗v :$lH [[a$ݹ]ӉvLҐ!ۢSV(YEF2?Ҡ1cz@Watɩ[m΢<(ŋ1cYsťWbɓriAW%$OMlٯDQ*Peq44o/'|6z26gA }KD'RT1KnDQ*Pe:t~{r'ujBt(' AWSte4Ç_\.0(2aWPЭy۱Feeڵcg,?Җ%00J%xX_::ff8#ޕ{ӯ1G`dVѕɓď.-$:r3&z.TOGG]S~2'Xx<[}+}hɤ#mN&$_|[ weV88*>~\;mѪ*NT"(')kk,//ڰʯUUqh6zɢP~~#EN2J yp*|}OB[ ':#^̺=t!=phEDBQQ*OHܷ/J%_XKwsq1u_߾ I(ΙcA;|>B!/]|3 3kV؏DQZP'?S(d _Z.Dg˗Ye/_ ^}d#t\WÇd:JX,D25ۢ{ݻ ?5|-\./(}4[4 }曫W_}ZHQ\>BXFwTaKc0rYb7)3iͅ ޿/'I|>F"ZjԈ;cǎÇovJJJzlt3665"«CY̐̍>_ཬ҄qq?~,0o̙bjJ]]ĸfpȐO87jOQh\*^}Y]q9)0щER9 IKK+((hvQ\̺q㋧lγH$СC·o6Zii[tL]J~#>Mww@ˍ2e Qi"##%) Znmc#ܤ5;ʰa\յI۷oU|ҳݻݡ" h@gf :.d2@,\ɲ ZHHZ(DٳIW! ϟ?sIyJPVVaӧOnZJH$RW6r+$$U+SOH(M{V'L{Yw7n`BR%χSQ3<_\\, U&χSHH@Feh5:111;w644󫮮:(++={ي+BݻwWWW nNdˋ444lmmBmڴAuZp8+W\ሌvZ^455.q\\\EFB=vB"?ޥK֭[ر#<<}-[ܰaB+Ϋj޸{y޽*|%!o_ &,[ \]]wu$jWp܍7nz̙eeeTHLL*.f<;LM N AEDD`bSL0ӧOvNNN?~LNN $vvv$ yu-g2GOOO~*26N񣳳s>}Nŋ%%%...%%%o CnrvSdY,֔)SV\rẶv"Wo[XP'O|ʕH;;;333)o2K.]zO>[, IDAT{WdddϾzj֭5#ήrVh胹shje(Ey…sέg%K|ٳgk׮>}`9Fswwkjj===I$˗l6FllNjĉ׬Y`0:$2vuu5ͦ,kƍ |M&Y~h`{(ڱyHXޞn޼yƌ ,NNN7n3g`a]1cƌu= -a$ή'd9oK/ѧjBjt݆YXX,^b w̘1C__ߟbaѡC:nmm#BAx9=z˽ϟ_YY)26a{mժU۶m>ahhp촵BpB$x,rq=vzҧ\DXq^UqaFyy8oG}ʸkkk W{WTUUXĤe˖8h~rEEU׮낂n5g#EH:,cl d_ viӦ싲hxΝ 6ȯǏ?,Jȑ9sut$(HGGG Yٖ7xI߾}̙#d9ΜIb7-$ylhh" ʆ,clKA :T*Α#f϶m@`NTݹsɕ $p^|PPil6С{3f ": @2*'ee?,p :eT 3mm-EuⳒEFa*gHa ո5G[[]:8h!DP\n󷓖VPPT4b*,,|DȌa׮]_o>z۶IK?ݻw/??(͗Zrzҥnj1FO 32ɨsgnZu릧#^$۷nZ"G__Ʀۑ%֔⋊z[hH)M3eٹs0W[>x];i$OG޺ia?rK}ۓɲ,rCl>bb^لefǿ}ENׯKO##edžٻž}Dg5)IQ>|ޞ=?^kdRWM^kpz+){7Ν{ޱXn::tVI zբEFzwɔ( 5k5c”Laa^F"l <{5.k;:89v&#vuf,_8e([^;w.9)i}f=`b wwMHy9k֯w`6r))od料 ڙN`\?4t6Y@(ϝ{"=0>~ҬIjf.0[Ԥ':hBe>stmn/?^;٣Gwf鎏B!ohңQrHJvڵ<RE~A_5% w?nU4e t/A@(\{wܻw7.cI$iz\_mVCvvt6Z~ >M0!86vI>xE9,ۯ?zMesX k޼2t+-Oϣl6E|%MrEESJqB%>ǿ=Սݽ}{z2k̘}/.<؊,@, Vn?09yZ {˖2DR~,ҭf ZDt .E*;-\(ݛcIw7SI[ݼHO/406ť' V8_g!C:KuoN}h]WԱ$$rHS7CCҭ1cbAarFFС;o4mlZT$T\̼wݝ;iwUWsmlLֻw#G>=wĈDg0EyݽsOƒH`Hw\\jA _Jn':h( FQdߦ NzjKMp?~1tˋF}'nDgE#}ƲK_2w% Cǎ!kA-:s͛p(?|ȕ+ }*2DRJK+UTTuť/Au/_ 2s̘Dg&Eðѣ:5A߰a!`H233aìaHl,]z͛ow_Hދի. _ammLTK"AC54hw;ǯv k!;>n\/뢌ׯݟN#<ʎ%=jTwKK-1+VDd޹Ld$Eq%1qIn`̛w2:zq~*=DR~d?z)6U!}R%vv֗,(xZfߢ|Hu-[eXhK ~]]l/2t}'GGGG##)9ݽ?Y@iQ.-80p%K/K"!cV)Z>4%o !޸[73}}mЮ]7~-:|x*GWmhwp(Z*޽w2g4566..=ګEeeuttѣ/]zYLQLLts#{³jVV$)?ǒ%Vӳ9@ř2ó\c$rw?mĉ'Θ1h5ƞ=|ֲ>~<ZZ>l': 鎏Oc0uu5;-TV)` ,-[\9:%%MFbZ8MVtrQ?~>lN1JKnnnn|>Db—/2U6>mr23.d?:HD"Q#><\7B)ʢE PW_<'v(-:wPD\~>|QxHJ*ecqqI$ [ۈ3`q %rQsXN& uӃ&}m7orB5FYe޼E姤dƾy[fj_WܷJqp}^U&&z.%O5=q|>L‹OlOeR[oeV)g& n61%۷ |=.r};{㢀 x<M ag$fVDŽ(M+Q9j5$;43V'ҍyLgۖ{_0;T_\R={WY|?ޛo7JEnp&#Pgs{_Qo o\zG"G~"a7nT/Yrh۶ELW*~=s8lggW.28 `]WBs%EJIyQ'Ƨ^ٱR8UU`fR*oUJDd}toڔuuDSvaߍq8lwwW0 r}}ԩkaY,qgKN'1$v0é_+*\\͚H7xҤJ:^FDކ Ck8cvv<?\QѨ#_~ ~1.\Rs$e^2mژ_jU:~s挏IedRFE}as8l9CvvQ}ƀܿߦ{pX &$FR.7LCwPFL7z{N`RIyq{7~O>47KJT*_͜[BK=յ)*r<Пo~PxjA )X<)WTT @hfos޽~@o/Yd} K6$X$)WUU>;ψ#֭[g0fM5 Z39… >##zY$)$J-%''[b/LYSMgvtrrrG&!hdh25)+-[okooGM>!AiiiAAAGvrrڼy3BXfǚ5k f=t…I&ڎ3&==i^^ѣG5kk.fͺx"u\.Ւ^G-dgg7#>>[O/[')) :j!!!:c蹾eذavvvV9+ճ<{isrr|; Nk~z{ F^T*9x`CCÑ#G8T*Yӹs߼yS/R[[jmmGu\>o@PB`Bْ$7xk:j!,,ݻ|>֭GM ̞=R$M0a֭:f)M{%6@#H㣏.64be`cz];O0$ehWzȵm^s5W+WN6&!L&7W )`mbä̈)}"ml裯X,2HX[RR&޵kKuٲ%2-ZAm2Vu99{hg̞;';:Y|`iM^{-g^vVnݚm]ˁ (d|s۰aEw阒_߲莀%@RJ-)Ro;wbdןinfԻ'HX?ۗ~q㼬ǝ;p֮=es IݫW1ckͰNy9'V)0$e,n۶?Cfxxfd_6oκ͚ e]xرRRb<=-["]]Oc$e,Q~阘isN%{{Cѣi $e,cǝ?00N3?4 IDATbU5j =wߕql'7k>[BBJE 0 2qvömsNMw,[*8Ow,xPkc9w.aʥϾ}9{|UɾtbJw`0II\SKBoĉ> ǻtbP`pl7fA5))Isxzu7_/,;$eiӦs$I݁|3f{Ri7ݱ )`6eeo_]\^ArG;$eŅ;#azyyt-qJEDv;66.,VBnJ%Q/=g2,3P M}g㎎:˱DM<ьg ݝļvjØ20$e`H A )޽{qqqf/ kgI ]ϟ_p_UUU iĈ֭GhM.H` +$[[[ |斜ܧ К\@u…I&ڎ3&==!ꫯRJ-B---Æ ӹŋx {{#GRIMk-999|>yǎl>hoo_lORRRWW2_P(֬YfBtB wwѣG;99m޼v`4 466 BHR6449rHҫW* cƏO-1iii*//W-_رc& ,X HΞ=jii1ћr4gϮD&LغuѦΝ/Jwu=HO_^g[aB$55!-H:d( )I(\nJJJ[[I*JTzyya͛oKqTTX,ַf&.++J*իrIcLЯF\.g,>o)eHD@-N2Eg[aBEEE~> _Y(^vbEeee\rE R** ggg}hݽ{7<<:zhoFi(** m J`` PSS3rH=Rs̩6V!. `@d$I>}Z.8q"""e 888$$GߖWttS""" 13OOO6]UU5jѦP(% Ξ=+Hr9˵G=Jr۶mK.5evvvddBR!-y>xӦMhShYhц jkkE"Qxx -O1̀^oI$}[y.JP >`Ϟ=...}YllHclT߲5_K9211Q&acM5.H✝]]]W\C03gI455Μ9߸qcMMMFFY krfKSGWWW}}}ZZډ'~1e0xSN]|й\)#44T,&+e`H A )}nݺEwVBc.>I01Ḹ^`m7s@O20$e`H Ax@OIENDB`Zipios-2.3.2/doc/images/zipios++.jpg000066400000000000000000000470231445164132200171620ustar00rootroot00000000000000JFIFC    $.' ",#(7),01444'9=82<.342C  2!!22222222222222222222222222222222222222222222222222"G!1AQaq"2#BR3br$4Ccs%d$1!AQ2"aBq ?cx|Ȣ` ȋRAsKEW ;7Gzmm=Z[ oH59GCs[1["EU5鯍њj|pv ׇ%nbJ[1S jJ _RJp}6߅"63,"3MYv*ؙ:/-xrB" """ """ """ """ """ """ """ """ """ """ """ """ """ """ """ """ """ *ҭº~ 灨 ;yiT~)[}ŭ-4KP">tN}O7D fPLE=84dt.|IZ[<<8aϽupnxA E*mj8W;tTK\b'cTAL;%ڀ1\zFpAx1쾧zMVԶ)ݱ-qt$n$7|6BaML/>Gjܴt_[䁗X[&{i}0t~Oc>!~u-qa.e? .5]66-,,ޕߜ Jj*i$֝+K-Y|7}$g?QBh$ڲq-C qce /K w+> J/h% k47kuCuA_K+sf+t6Ji!0h63J>I'>}^`p# n:40tiV])otݤYV2Bj[HQxdÚB" ""1fZ\SpWJ,.{N鲳+^֏i9?@UFٛ3ihguÇ0@Obdu,!ոR`s,06x{\ Hv# Jt Gmjeɭ -@ax'~+nRiz.Buc5@8bGTp.̨Qj:UtX\fk1)ztEj$p}k38sV,M ZNs +{o)mEWՊjܨk*8G`e.4[7.QNV~\(N708@omfBp=WՍMs:ykVFB ˇٟVv[ٕwA&bjQ iaj>UݗcLU98$]?iU2?};1Gx>m -/c!;vcK7սsQ4m U6?d-3vcMaf22>hfZ{a]& 1qይ,hw?k^J|uu#A1^2#w UÌ{H> gRe+ iS)Ft;oj s2ݐc#]~"bVq)Z|H?B:۠ t{7ף.7^qAK?-I#'Sj,תKK^#s@s9GQVh)+rp]2M4?+_ט%Epl`NBxbҵ*{Nr̈ )qm{j&dMcFq%qVHxk KQ*4V8j |Tl)]^C)P#v5p-l]%Cx1'ޚFqC3C P>ڳ%Z<ӳO'^o(2{$-=Tn&`eV=8c>\ZN!{o]珟 gZt1Y4݅^1=쨈ZYW7ȋ֊3#]n]]3^]H}iKUuQD2zϴyQ2Cn.s6R Z($n26;Mx8{[zg+npP:"wW%b*60 rp"#DD@DDD@DDD@DDD@DDD@DDD@DQ-Iim6}qiڝ#vsܓ-nqm}PHE5,uC1(uҴ8荼+bjGSurWTіC咺xMݽZ} %ΑS9Y|=Aٱ e$-V EEtM蛥d@0cDD@P*ymnEPal8Z5wj*708 s]j<ӧ-ZuVF=X%'-tN ,)Oxѓ%oбGRɟsv+J@]! `-AP$:g-#,KˤfXy+Z2YHwM8sT>fLT4i#|R3-Ws(le;cߊkP0V5"SQ%$3;LP<4 n*-U푲j$QMDўgPHk]T-d1ڪ=}oi$i+IKjצS#x\ӐVpATnqWL!~]5;3<hsATةvӨ/"""69pk sp(="} HZeM?C77t48Gᑹc\rccN8{Tк >% *f|yy(`$C]2 %>^6mr8 jȪ"lױ-sNA `2Wt:+q9NFO2Ua;yl?g4:w=>ǴH9j]E;\=aˤMOp!u#ҙhpֳSO\5n3wIm_riVI vi4wmC%Ŏ٠e$I1{e|8ohNunHؤki -ؓ_jbs{pI{.dֽ#[B4zg{ikqeMi=9䇷b0wX+MdKHͱgrRSX Kh]Q6js@qoTƮ.mm"WʒMPFkFg@Έ8X B|ܨk] K.ǎIWIwF8I($t qq-%ǿ+F'C&`O.dƫn,̑rDWҽ*ZqOܼ9c(Qy ¤vLS>"" """ """ *~ݎe<󏢸7u71vuX&#{\vϟrﭓ5^wr]K[ܴ ge˽4<7Pk [ulVMU_nZ#AsvD@DDD@DDD@DDD@DDD@DDD@E is $AWYST%'JtpǼGoz-91xIW`n=׸j9|=۸g?i%+g.'wh `>d&;2 VJ頌O9OyRKmFh9/4hn6JqgZݻc4ڴۄLn@Ɔx ƁbD@DDIf4{?`ñq+㛈mVݝ5Ҹw?IEsv]12ld`;ʏVS6ib~;=swR["Yr4V M3p Rf8^s`&쥱KB="{pu@ vw?@U}JTқJ{!|d)tJ-(+Ysr|d{_ϢT,]#aK:u>j7n:'kdcLJ\Ig q=˔Lْ8;:j+AQZy,=UHŮ jp<9OjSZ>ixo=Ib~\Nh4.iN3uyb26&FYhdz X]=r~ `giܦY^vȆyUsNu˝3g8VG T8@@*Hj*`{UöMMuu9̱- "ƈ ]\4UJؠ{4U_o{/Ni٠ J97~y\# ec wO7S"`l8Ɩ 8,fvY5;<% \4Gz=z;'896$c\u39/OqvH3n~IYR6B d+b8IWVNb`J<3 ZY Z4:hݤCǯa%JXAtSgߪ$8VL>JKSM'%I1=ƍ[R0!lo06FLMLk0C0up[jAtsCa=OsSqSKaC=&O 6}ZE=C$.#8mW w[MM 2pT]rTb>GI$t9:6逷hkec{*BZO-ww}L뤞{93$x> slV\YI-G#d[I+^(1;z1v.7 +8r6:Fr_t7c\+c`뱺B " ""֭Q`3CM4}W9c\vQ{8ΣܫmgOY#g;>IU;FYXzDVvdn؎7>D $^8^Y Ns XdGɹD 1G9wࡻۮM.}ym.sh$TltTל'XosZ\ӾI vwGfK+d37.% viQssgBCH܇ N7Y$<8ݺ4Yge`;huɢ`c;2"%OrƈIZof~.3c՟x &`Z:c\'?P| .mEc68?݌7b{)C%&\c.s¯m-fD\ptx8jWt1AOILd`oܑzȏ'9Y5E[-ʚI65u5QnS<3c䕆Nl$3ΥEƊuEe8nբuufXY;ZNsw|ASB@۶V~X\|Z\h8$s[ĮUœHO J`Z}k9Z_xwܩ# \ҩ;m7h:t ; d n9H-rzi5DDD@DDD@DDE_pѾ:x>C|lM-=Oiqd,^Jy_sCԡMlVCdP53f-MCOĕt+zK804Hxr7k,02&c@dir`n%\ςv5D5S}C\OrܲDvPت*urI14,~WEl|hӆP+pR Sb\۴F#$0 PK* IJ/WGK%xM17p*xq# nsީ෵}-˞ɴ喑?ݫo@a0Z>}R(?e1Cxݝin9]dO )tӲUKYjJ56 ٫QLvTۿ2džpg-Cc2UzUqu) $osr䯧9?sD]yr UҾ16叒vs˧8:y|^[c</ h˜NS C_|s~Gi1wg̕Ѹq$lS$m#eU[[խ|_N[xh$=hlmY1y]FJ`$sHh'_* UͰ6R2 sPk}rɐUz]v5㱀zü*n+ӈc^Ki#rI;VؘC0sFzN.ZmD7yFtrB|0Q8ȥB"J><^vUL 9$'VMci,Qrs (cxɭZKU+qM@NôpkK s=\K= ]~ҧ/y96sgQT\0Q[Y @ҦݺcQX^8hi"\f7(34FWL{qEintΊhȎcl/Ns4厫ãh#3r.+W w T*( $$l5eϮ,:WJ_Biw}O+B9ʦ+LokI/ҹ;w)e%s&=]%|LzマW\R/0YTwk{ svLx~1nxoA'M_$LGv>?۶/\}~9QʺK̨tM9K9181 Mw௷ Ż⮧|SD\2 qگ idOGey/guhe5??nǮZ;}R1`ORzn;Vdeuj*Oa蛉߉D@5|-[8}Gx\SJ9%e{mKUڄMeǗYYMp8'EvDc.Ӿ 7:s-k_͔" bGikaƞ{MIsJ 7av[=ڈhGBZgS~?l(uG ^i R9nr;QՎGJ޺:62tRYS7ÇjK6]WPc-g9YLjUQ ^\n2'\&X'teIG+$JJ9$ n,VӦsûe Ǽh9nig#KիX{g,z=Y t2NZ&0K0;5η[% oF7#f;wZ%̭. kVB_<-VÜJ 1N5֐> G~QDcrlCYhv{!v3QwhlMvY'X/M Vo hp%E9ZN쨷kz62׈٥TGN%dQ0ey >=վeIJw#V8\NYS);$~pOdzysmASz;1ӈ^ #O(\}U5vV*`p>vL\mr^Nl3Oa`]\*otqM^?͗VaB$rJ۬ϐLpҡQFݚ֌7"殝P5֦l`lнcZE%]\8c$C7 z)"G˦zQ$p-V,@i8PHبc&]0[y[4얺C%u]E|ิddr[-Gg4c:Mz(X<.rvRtcؗ5μJkeFa[4]M{Ct ei^nKhַ S7pe2T ^ӌo\v.Yr8t}DX9isѹ$2:˘q<5[-s#k"8ƁĒ6P- ]Xn5_9kdtGhhy4,fǴ v8wo#3=yg.e]%k;6R Ѥ!b =35iG蹳<gce2[77yfmh ~0`BڥsO c}9po߬k|_-{-Sc=U^\)c4c8014a4U;EK{$tɩZs ee bp^F^rq>+5" >gr`\m>sCӂx_INnUYqP8ӏ%fy`4|dds rz,I#l,$~Ӧ@چ =C#+7ֺJ!|gK3)Ac~X] -6ʽ1;~QoJrVՎErM-]UD_֗82IooXxO@>eriJ >OeM|_m_{tPmaLe\ _r]}}ܴ x%,Ge9Q7'vAȏzLJ8ZBDأ( Bv-%ӳ,ȃah轀 Ȉ87K45>9#k ;pUO$$gs?sCwSh槞0ikzږmPXۍԽRJfā_PKJ=Ay`s,~Dss]mt FD^8r8VPFw*bc0. (($S r03wn 5`;:rZ1#~ OIRۧf.H~ ?UVn G$n$ bq#.)b FAsug9%nz;|c0?>یq+՞e%adnUC%4E,3i!2ጫGPt.U CP״sro֐U1v;!:8{ǒٹp 4zx.zlU-[?EƤ4LnB[t~X;.? =Ws_5+ˍ*`=37ZaQ/q[dxoZ8ykE%lfG O:_< UIOIKPn4#e/jGkki?k|9MWJqW=V}|?$lpب\]gd6k$O>]`?p/bJt;F`}Q.<6֗g#>Z8--g?߻ 9(F093HrwzV`p'QnakU;Ic0 >+ Y%Ґu<%ZTfЫ^cSx5EsX \ e=>_M/Pr_T -ttg }^n6{Kv/HM#e?iq 8xrᛶzGrq,+ w[9eXQĀ0K* ݖ;K[<>v x{Cc{W]9#7%Ur7cIjO#)[솱mv^,B͗<1 `BmQ~1 0/jTL_/D>]TAɫi /H|E4<9O=I̒x?S0m!FYKC|kډs]!P6 ~k}Mxwːi#={:(Molq w=:%cEL:\y=mvz]%T;\Orrr˽W_A:Xx>Jao M٬cpl8)}=,v[,a%OK@Ț6[1@ S_EBUNd ꥬ`h^nfK Ә?dޓJS6gqdTt]|f^J>;Bֽ mW%$XA;2~(zN:4ec'=(،=.o;2wc6Em}3!]3ZMHFy8mS(䥪 Ú맣:VJYY9ZsC5кAO^ZӃ3>kZN?O'f .- lF]Ui]R=jûy#t,/s=kW#חVǹh5U{B(p!Y7F8 g.jW7Q vs2UR7tLu?ݭqkY .j$\語YUcJm(qϐ@jZ#NnWHacXPr/&Jڊ;G ?tk穓VKoOXN]3|mu%c]H;!gS5̏)678a1#_7O}ߺ эmџ>쾺vO01V97$|V>Y$ap+,[t,c~Y[+}H[3рӪ2Fv<~xs-N.NH 狳ds0zʹ!x%XX y6>7n3޹*W(k 9l11 g<,19U2K6HCt s 8GdںNe m5 )^A'YZ?,uVcC槶/>.0Z*ÿD.w;Ԏr| 32Aqo;ך˔40TT1v]qA@G.d7@Wp-ӎHIxKx:u\&ЗJݝ9؞ j-Lj<A&9ll1`5(*b[+YRӽŕ.$e\"9_! rk==d ['_ڝݷwNqӡXi!B`VwG Z nf4N?%ϷO2l?BQ|m3o\3~m si( Cl< ̾7=r-Zprr@ϗnU "쵾SIQ^%ήZiݣٌ8}=;lgΘ۾?.X.\gh F9T߃8Z䡬> tOʿ]Yn̉ݭQ:Nv_e|7w(˗lytM.kW\?f5< Vޔtw. w 1_v_¼%EaӧA]/k[ߺ] )@KHgr]cn&zhf o879thվxW #""" """ .\uEQ7 puĐH >[9*vAci z-Gs}ȥftpJXX ?+k䨼ِGW7 Lj d^\nyw]x;DrLUڤG>pyr]/[ZM|muTp0gP7XMsXHCsBҚSL&{ݑ$vX[xӤ?'}(u׈_%5vsyw\Vǧy s%_Tm36&}ᣲmpI@?ٯq]nF.۔% dzdt?qݻBs-t!j6'9חb*JJznGA9%nPF* BV2W6-'s;܅P`hJ]&:-UkK#nZꪐִ.-II5%%ohꙜƸ5u!s)U1vg3)*#:Ap [ tUv6 ;&346rgקZZzi"DuB ӳul?>F wt_v'W [WF6Fhlc;wi2 /8sr?"8%iV ;O(_.uR=Yl-G7Ym/I=r']qko" 갾>b6n~͇X 貎f}ŝ̕ 'Nt-Ûgǚ-,KԴ8xukC4tIh8p7KG=YN ;Ş6qy.6yr\H;-H IsC%3rF$ reuljf}}H|Ls#)Gڢmhhx8;{U.#:v.&[事􈈀D@\ݪn!$2KO_AUW:Q} ̨TFrw{Ɂ\G+튖:НodOspHW in2ao3 p,jFg#'w];-8VBAk?[ktp%MGhd@{!uk:,rX֛ 7}k%qSH(Y6ɮ2})QI;m 3_uVJzcxs˧*oMCXz5I" 9Ӵ“W5,ėAס |"Nk?eOLLUq.Wa`:M]V58\?Wgp_=] ;z;CSWgrv Ao ,~6[ܾMAg F>, U܂: c4mv; }6 8F~ZXw B`w ñͨh>JzXEndoc|flTՙA{lMoDkZ6Y;&/hE5oKsHA.,]v Zn X٪z?·GS|-A>?Fѱt-A5DD@DD# \-vsNKAZzmSR/B6" """ """ "" *a3H!Fkxy*fFWOD* `x:T͠,&@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DD"d>9Ǵ# /7;+cҸAZb~d|q~;\zS)ovܭ҄FYtr<*'XK@vz.$fzd'ⷭoeS"V{_UO5M1ˮW}y7-^l=-{CV" CF7j/{m4DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@DDD@X=,GE,&~!=TY/_'h;䯩 57:B9XhO ZM@z&Ԧ2WR6h r?Zipios-2.3.2/doc/images/zipios.jpg000066400000000000000000000520331445164132200170310ustar00rootroot00000000000000JFIFHHC     C    G 1ьlR09KkyFw1wΚV|v)6̕6t/#]-dE$}j=D|?Z %+#r{WS4dz2p-mmV^WU6p9jI|:(v::|V?Q1* r5[Sk6+R,\ɚ(8dypc@AhċiNm"gw~2jlj1ag$<(0>k:'>݂{YXaRdzD ~l|4B4w>RY$=@ucWƳ3i5oXxq0idn]#kj#W2->؛|xt˲9OklϲBu~N)gJ˷aݖ@Dhm_9jEșF3US5}6sn+M/۲7UȝX6Szzn{9s֙`T-#$}Bm!9m2tc7>a\ H<=;c QX6ǖ\DQnߏoJM@oʴ3ӡˣr^2-YUw8E~D"݂SǫxɿZ[S]jdFlz]6ɉwÛ}}2+A!@-2KM|/4Sjj<>8ޞtZL޺3!Ķ=g.ޛ܇~H5GV7@GMQ_LԤV8̵F\{-M~mۚãSnJ@GN1vB^`d *ΛB^Gl[j<Ƃywv*QW/M^W3>:xvTB>❸Z'~mNXm1Ɯѻyhλv~}\nOI%tLYd$`#tõ;J&MyE L:. ǯDbbOGzlpH'ʦ8Fm]!nK,ӛ:lM٩jgiM{w?D\-]c]6N̶R-p}xj,vm4L y?FQɧ}A_2gЏ!O66Vjol3k[juI[UK4ek*=эGk6ENv>΃Ks!s\}eȲq[)jƚήXo;YFH.eїܵ+nfE&+i^XhŪe Vקܵ-w\h;f, ,5+һ z;??F.i75ȥ/1KE*xo9E 4qMJՁ[v\qF$ƚ[XBc&Ko(鞜~DnMl-iV"zZO14SNKsODQj|qmClbVGavSvR+w_U6\3m?G5-5Rf'g٬!e*ڕ-ޔZuӟ3XZ֚S-r.5:e[MU{syUd֙\[Va1F6ŚӤD4KJGKbe魧YfgmNްSF-~DjuUkz,5-:7{F,dfBmEMQ,ya78Ou%9'omH єxQᒼ$y!{aZ,Sm,E )MI1C$VXRvʮi~'TQ,*v6Pax#9xC8V+ҡ%ΰ@^-kl+#\NMyV@c1h {)% Q>X@K>#~U{\1:<؅*~vw USܬ,YH{;l%>Oe;yOtpDc1% |n]~ (TVWE$.턠9pmE-ow+"2tuf"L< Bs*SZ,ȀS ɲc5 S68\q3gC,Bk n#a&I^NmHb23v?sl6COG%_AaR9]dzHfL<|vDF ߩbͱ.꧴_2j!8ˎ0;r,ycŨ2 {MtJQr$N(djJ&y;X&#N"HĔeNfM3bcQ.-dq̱ueΡ m3zr%z5QY5jɏ g]SIᒦ?x&N$䶂b& llFnlj0ZmKpjD@i~ZB/'>ET73{p1وŬWsb5g=1Zt qs8׃gDC䖻v4MoSX71dE Ƌ2ef&ZSD EŧubϏ,ݎƶE^BE\_1L'%P)߱z1:~b~М`jStj1_ Ȟժv?y~hSI3ѽ]P׹9(kNxBMU<5_@enc"l2782Q6R@V۝QAfk]z'[W c2OZvQ?j.d,vK$R]/VOXSB̎KY9BO]buβmg@mZA٪G7f]wb{pו#m1e?!(ґGKk^D1 D!'D!&Q5/4aQ<1ČK=3`VYO3eƄf @'%rKUeHBTk(m$G! }xVi ̒: ܐnZUd:amҝIwvGrXFzC X6A.Mr_'YU՟h+qr2jؒaZVaJut84,44p$21q '$ʚjRl]ā1fzE\K,Dv9KW\-9| 5azuF Q 3bQUV5A.DSM$ʼYGq. mx$Ai[Hʓ'0R5 V$*D3S&F%fWŔvvDbG\r'fHxVSpGZۿd٨NOuK)B Ozg&ޟӤ4NakÞǞɞǞʼnBIH84ÃR85<Ů:\rWא j5"pL-bYN'ʅnިS8&pLPEŒW=s<Ć8Ξ3gi3LS ge3L&v8&qL㝴b'#S/-+@[[XV(M//~׎G:n$ӹJ*c!㕢Jox}( !10@P"A`Qp?LّK1Kڄɜg39sQ1ȿ[)А dx<H #1wщG 8QŽp(F&&&"t6'8'y(&./"bv}VHSr bٟ(H]}9茳잦3OGBE#h/?Qf?.VNt/"EvՎF\}d5e"1{b]jY?/rr驺11"ąPC"D GӘ oHce":1D5uhQ1 +꟒/vz4{j=]Ģ:U#OR}vE {ǶBD:Ld'ULӡ4YD${'j-DӖ6(m}?dB{T"s"h(lĽDj3=HbM bBd#Dȡ0*,Cxj&+Pº$)|M)P/Euc쭬w/%ilLLv2&;dJf{P?bq#ufFCVm]QEnƺG|B׾FG*9QʎTdddYB^'(Q[Q[gG1̎d~9Lh9 $ČFr1ڊ(쾾O&$mbQ]coQB$bbQE2Q.$$2(#㮷&bqY{Ebbbc]dDuC$j!x28Xؼc="U& !01@PA`"p?tiF6QG㟌>6ę^hGOsd,d&I(=f7o3 fe$)qDc#--HJ8  2/cE Yi%dF"Po(Pt dgOI rKY E63.茏zaf|8D]BZ˗Oн"$DAk)-SP=fFEX81~P.6@zeBz˔]~&Qdȿс˃,ƼKs9WqP"Zczqlj?eJ  =222-1|1/bfQbٺdYƬ;"/LLJ/(YH$졶;#pY9ZQͦle,f6ٶ``ac,cdt^vd;4-r,^vl,baI#pĆv0d6 \"2Q1S$l[gc9k/b:̌!*\l%"7 !vY|QE.7eZܾ?B#87 3333"(222222,/g_7u;Q1 DgP_dOF !1"A #2BQa3Rbq$0@CrPS`c4Ts?spc$3%o~pdm̒(a;vvNinv$pdm.) 09هc;5 '{G4q7:v 7NBf3vcX$d]Qln{8 Ga?Gѳ'☟ɆZJ;W|?+Yt^:=W-jۧW 4^}rrtelqKRv{2_{y\Gdp=3u[&J=7Xs϶ýb45N̳OaA"\oowi2] w2tnrխXC8ZzH}=w1|3\ㇶ0^6?bl;V<\R<o&yį5b+͛{UpWlzmjd%6Zy0I:MEFH,d$>GPif0#nC>EhZ-E2r7z&eM잆|>O0 9wZl6Z:t.+ lCCrX_ VLOoϞd=ÊٛݨKGtcfdq 298z"9oIHBdp{qhV̹ٔ9FhdO56HhyFYq8I:J3({WT aKԭTbѡ,A=Џ(^S1ـ`Jl@5$ab Fi;:. 9B93?2I1To;=bh: ^2pɮW= #~NjGGHy7V?UwjEW*Yэ>Y:rڅa.~"# q.qk-=Vng2VNY>בQegIm'yJf0bK򯉮嶈n lܢ\lkXLSWaS8;2Nwjloy}9ӿWav&q+t-<`u 9 ,I¹wpMFu-9Qx/ޓq5Z顖Hr@f,7[X~%7.vtfs1]pYsw1eY[` }n=ج?R%4pY\ˏu!-cr^7 맅NdM6׸su^MS7pI{l~kn2SL\;.VEntNz:oڱ7@[$2ܯlߐAG՗.xlZqAhFj]ʆ=e5 6sJF2Ž9PR\ey\?zNbI Y%ekX\22G^2;ozd=?⚝=RRN0MK :+`(gIGQ%77rQ~I(ڛ%o݄h2isp Ͷَٗ7Sr.0 +l#{rglw `eUx@m_g9daMD};\wq+$b>ڲJ\lB+Z-93g p(]`pvCSh<;Br?ۑa[^MDVgz94rqiAp{NiF)[60S(Y_Gf+gB0D2tW`Luڬ֜^:+iCHO9; DZc=c7V1Q_k kl?GOGv&.k ÄviYvh'4Ů#tM5 ;|Yyn.2Z-E,{.Qj]' ppvy,'B$HQ0TSY dV ׷Vov@VK~|UZ`nKk\hܰm$V:_vcphr4ƢXoy;b9+]vKl!ɯhu[Zk dSD Dֽaһ戩mN~7I1َ'#}x-j9\_u&3X })M/dMɾ,9]8S8F'FN[X^\*3QliS+bVxI1 f)`8l[دU&<xZ#!+v8,nxqmoH'SSőwo$SӁ-[ +o.G)m2=ݨXm&#W+O;3"bE#w蝔 #Wlh͝5gSfl=V-wv΢k{zi/`8l 8tjuf|0;WONKj>O崨qK6c˵m.Mq;/hZ-hǀ(7 0hlkIzs}C0u2o`[H&nBKpx S?fɶ:џLz#*?Նذ uTI ӳl>SGu[GE68 jU,}Pb~ 7 SE=tCM`[3ͫ'M2fB2>lk"OeW3m4m{ 8ñvwED]6cٝEԞ\O %lvnjU{6Y9Wan|RGhW<˕$07dk;i`2E1k6{Ԑzmimp¯~ /9Xf#pebYn p6Y-`UYѕVdNi0\LqX˶%w!'=ev#E}jhY#74v;mosW d \@oOnݮ>ձ.b+|ve:Y$]1#;ci?D-;A\OG29trȫW ;0#ں\)6y?Ym2:7=-OE%{ v/+A+/b0L޲XDh޳Z-EK}TW'G&4>gEh+8כV - 8> ohhZ-qVވra[ɁtN^EhZ-EhZ-EɫN_p1K+f{P.EiZ-Eit{.yMgP 2+E71p rjjպ0/*[|E1Ǥu H3Ev,Io I!p-o+!1AQaq 0@P`?!ȉLÁ*}MfWJӅX3MÑ܅JUuo, .~4}ؠ`PfЍe+pїPZs{tOptDCrU E :ot+z/WG@YN=8ξjV؊@B^~1ݿC5j`WJ ( NW{[ʺw(#rc2ymF3xԉdiK,Bƕf'e-WR\U6X+z Fvvwuij}˺i^-r>0\BZesC TZ#*=Aۛ-KȒFsuneh^_ FEZ,>oQ r4T5U}Q ?xGcZy ڡ}!5#GѼu^n.5p81u =F.VK&G:'M:iNt;dQTzK}1fQ(A4l^@>!HFHdC0& |c  ;%~ɠ˚7hW`u88W{$h `Q-]<%'XE7hd2=_i uaic̸kh%4Mo}..65hnՕDje¥wZ*u2d]#NqN]&2]ˍ[(KG,m!}tl1 ''Rrz;W4cMd{V#$!N0LwHhi6FoS [?NЃu'Uꑆ6g8b6BVyY.g\J̚Ѧel֜8PK=;+YKc<@ A%Sp,YFC<*ȕlY on5˫+ڗ`FHF*k@]Z7vPUv?X)lo[+Io7Ux_C ޒPM!,+"xXQN̾V %f2)#rK[-[?IO!BF@47P<4)]u׀ah*0{I@K:҃y~:n+U5* iXrhmyJJ-QlV.T5ŧm P}"BfpsuFe'?lDG秏H~,^3b9EVhɆ\wĢ@[Lr]v@6#2ri%NUUCOcR&-]ao5p !iX*2t]b BG!I Xі)SW jٸy9e($E,kH@P_V\.z;[JMV Tġ .iIM?C`ԅff,#@J# #6:EySdUWGA*c/kZKHu+x-<+0Qi|@'b9Ol6sp ۍeB WCJ-¸w32#+Jـi R F%?/"7 Uv|4˸E:b9=-kʰ|7+h!F?d1?H[0}Sw7pw9RY 8reYk h=0h \h0WРj_W̧/!A10tjn^ m^9f$A} JloU_YfM{ +w֫V FO FNpJpXQ߶-+F SEpռ"QjrMw@T\M\pP>#n}05>n$:`"r'9?#Wg  b:/ukƴD}Z@C| 4k]aᢥoE*Qհdf|MIMwB7F\#-7i[l]zDRtwt2B^jjBO+`5Vsnںs3V"Һ&iWB^%<$_N%ihuyhSyKw?1˨*SS^ G///Vݵ%M4~`F?<w~\CtE!ݎ9cF: 8j{łXhh:MXKC h`ULܰb`o2lUS] y2'9W6lҞa-uJ!EЭ+.. Ε h}2}]hq- ZW xI@H4%~4LG!o/FmUGǘpI}ojjuz)UVUQ8밢9Kwh}`Xɔ³Hm$`\[4x?5.}/ږM f:8/DWĭ @x" [&ރ"HؘmT?>zA, z/I!Nعq\ z5EΛX_l X (%)Ӊgik B%dOR'3C{ b%W|zi9`s^54b'*{]nC~νq-M,\^ yI0 7q9X@RQe:S)gGk(]WЦkvn.q+ٴރ.,mqj^Xd)UEs+f諧^Hp67HoQh&&֐ \lJEU4C̳aR;JƱ2CοTU^w,Y12]4|P*9c,t ^x]yv5y+=e,WY\+l*@uqX)RP/.*mr^BMk\e^u WZ| (O͐[f&$J$D_i.I$I$Iʉ^zҤ1>G: HI$I'>@ēZe:XL(I$I44Ćd [I I$HW(I9E$ 2]glƒE I#;dJI`x$KAI,$IKt$)On8$$fC|EO>H'l$H9zK1dqCm2ӭǑ)4A1ǎoJ2eBZ98 Gscn8T?ldDFOegVI 5{(>Fs%$LIB1vI$ s2't$ MI% $A$@A$I$@I I$I$I$I$I$I$I$I$I$I>I$I$I$I$I$I$I$I$I$Ii$I$I$I$I$I$I$I$I$I'$I$I$I$I$I$I$I$I$I$ $I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$!! 10Q@AP`a?J,Ao7)v؟˴*$J$2}slbѳAhB7>-_~!z(.(7D±/A떿 d?OTn Fy%7O:{1JS/ r6s#]K)tًId0o| /fcaWthh0gy} V-Fw tH pyCLQBBL- iEX9:D찑oBQDT t)铺4Q!/ hm*HcDw J|b Uh\ ѻ \, N g?hΡ^| C]PmLW,ƅT,X] C8f3^}5m!Hf4!vN)JM HGIAмHB$4A @nܯBćnJO HSBx%z6NgxovX[/wBBCZtrd=5l2&ЂF°TBs?РаPN]QY¨N |dx!Cf͛^C+o'rGEF0PFA@YYcPBG؈$+1ŚEh2hl٥ED冋bMA)M!D! 8_G'%TWZ+ v(,eYtJABa12ǿAࡺƢ0C5bP7P @,C=K,Z#cZ^M-$(|!NJ(cV4` ;pd67DЁ') r6]EB54CpU sAb&u7!(4!xaއ)1c|'px,6*mec4$dz=t%E>),0[Z +rz)-qg&R XΣmAt8 6!#xMOb6G+ xĠOScC GC#Cc4 7|?R%ĸCAhRiIHa\WأQ‚TbHD𛆡i9вp1?bMr(0$gE- N\PKǭbl$)U Њ61>/cY"f|!7lE&l7ǾES;QLBaE4 L Inec0MbjHMvBc0k "7#t0Q@&{;;2J8EMhR,Jx!#pdLxxA?B`^~Ќ+Žf9!JRa{jED؝{#HeQQ8肍(~-|1EFƅW &*VVWVVW㬬chCa"uv,1 !0@APQaq`p?EhXjW,#r>;MsP$`\HN|` ;{k4\WCeӱT)C9@Di%4#~"S#tXw$#ˮj *9c_8F$zVd% c;{ZTW۫ͮ ?4^=% ԝ,d+d7ى*uQY9(58C|aSx3~U?_[%!] p,6=3f;덈 ֏bC9녎>NJ2//vNDK1N'E َnyܬ;w8zH&9('~RQ[dB%Eo$C)eW :VN]wp`la? pJQ5Nx뀡h$CC y~GsD,".(!kd#ՓũR>.IQ_ۚ<ի)be{o.yrx{(AAeg ;{Ͱh Ai)*uܕ0[%^lDX |ymn4IvHOjtm=ot!lGԞB^sYʛ.`־wa;}ցӧd@#F='ܤI{`U.)+7ݸtn ϕͻU[Ͳ,ǡnY+a m?"[;o iSAAš7o!no^s}8Q'Sn{M=eH+1fG;Ldw@d:p~.!bE#!m16KWN3|ir< 'jx79g).C ɡU6;nZ_4t Ugi쯝uݍw8o抆5oG_si[BzD׻S?O~_^5Ɋ_LH_MݛzH(zcGEf7bus𮮮*2 jo ^m;sC=!10bМQ֩~g}p^kC&^/W,/:=D#'B }wx&˳v{g^0x^6:udD߸r|i~3}z{G؆Tpr]0?hAxU.%*޼6 ˇZipios-2.3.2/doc/images/zipios_square.jpg000066400000000000000000000676061445164132200204250ustar00rootroot00000000000000JFIFHHC     C   ~~ H bd(eHzRw :kv|mH;y5&62 zNsz:NRVDgͺ1'B%[ӆn;ʹMEx/O,\E&r+UroS~TǾ;?gg@T MNΞMn7|kEB5Op[B2۰-8O"k WLy:qѡ)e$tϒJ46&ns-WeNзūm{z.>ѶR:7mz% !oUұqǣtru7@Wm v"ږV'=c۫DǣAH|k돃t3zk8_G4LƲBbK$^e]LI=rϲF3ɮ;]-vj@z @a<.nv@Bk_=xs73PCޮLAV:φebQkY)^/6"O>j9g`$ eS-Oy4ucqm3-eM:j+՛kyЅeB>i:u+W^oYmLOC펡v+hh6C茶x!QfI*L)TU)84[ղikiK4%,R.ZGIۍ'm@R4z*z=|2, !4n`z΅8'zJ(y(G([1LR=JE(T< TRy.Cq#-O@[7艸'=~~wʙ^ŭSNWTNX!L` ?0 01@!"P`$2#A߳,PH3'7{*h]tWv:>PG .Gd+pX] }e]^w7]]oĉH(B.3-URtx*͎lk!c]Cډ"E?X—ډz#jU[C9TS9@df)L>TL`X3z)RU}mfD#QsR9UiY4^M&0Uϓ%ݺ23s J163ѢOcTY4Mw$I$FAH 7Vj} BȝH?T~,&nyny&nyn-{pm\H%ޞ$6]5j oGa+ 7џm%BaTbTQQIU`vKV>Q.c3.{ V O#C' =w.YIX]k`7Z2-"-&؝vʘ=Z*z{u:{][TEqLM]´:e̓lSkV*9=ЪѦ"~^Hr ^ςڻ֠y,͌aqUu ^ڐ P,&XҐ0p"'d--p8V1Jt KTdGN=KGP$daL2l,6FCl3)l&R-m,B]qpWۚ8$,#h.5'j;1 K_"u&vnmTlrϷ eiM 㴪 괋(r!*P^w3\* >ROLesG lIKo! pD6ؼ^t.d0 u9̳T 6mve3Zo1 Jk⯊!q!S:cxRlHn $5#u^Fle4sEdV5wBHkW$GQ6lvZȩ1SmMrէm"qNmW/$r(, 4 _u({[E_#QWzT)+,R1dv7)qӶ}4΋P|H+WF3t5RH'쑇ž7Kۨ,=]c ӃDPӇ['apoGgZ#L"%5ˑ A ,$!\:@z|gJ2DEe\ʶv5H`ӭ35c]0łF3d@ OicSdޙviHvj+k~S |BYEaicSdԦj*]KPiHo#Zb_ ;44OlA-s2MRغLDp,q`e¥q"!큌M6B'RYsۊ.+QR"tqW"8r0l2Ltf}=b(+Nv[; 8ָ|Gɒ¹fΡэLLF"xh촧͈]/%Wc @Ǯe)2fb_[r|̮h$ )љ40?RI2,2& %\-uc"b"F#Dȹ<)KF1NInXm?gHвfEkGѢ-/1բ3 }*F+ԬUb8M=4܆hX}h EsאCcJ4F7ro[-ԁCˑd<Кd@3"5TX0,Fz ڿkH*16ר$+216U᲍3C.+"VCI-Vj:㑬b,{f,mY>K4k%HXH\GXq 3ek\- * jMhaeaO"`uX:, cҪӝXﻹI 9\e4!Kc!(#ح4\|TvTl#fiadEr\\8;iSr^E~c%>l0 Y"@F#FCύ ꄿ=)|M]w^ֳS$rj'Sh˳l+ G0lc"!2LQme;"UP9;d[g Pk#5[䛉 0QƮzc,a-E]ɱ+986 lzō\$- S\RK[g%k)'WXv SY#gpjͻ(wQ7f5Mwl#`dI\&21h* 7-yS9HG(tlq;v{D H/20U-n Y76x"%4'I$$k~X^:((<Jjp5lTؐ-Kj ZZi9}$rzbi=cU*WOBIn6n6n>jF: z $D3or7Պ&\r"^8pL♷FOnz{q #q#b 68&(qcyT&m((H蘌Ds3333333gͽs31IV5R;;$݉ev0[Rύ:܆?/% *ٱfKYmp gGQQ fL0ƫ N)7o* !10@A"2P`QB?ٳ"t1?铓<33<c_BbB~̑:::HLQ鋜F"B<( <(F&&&"t_b|7/;;;;;;(E4_rֿ&!}}YKt)_GALOϲ(Ky"WSWyMz4] b,/vkjYO%GNv%eXӞ.XR5"]Hsm.Rެq!A毄E?[=KdPh.B`QӘ"lB|ܱ'gGRʽɉРF%|\u롪DHekiL\Y/."[bbQGٺfW)vF"娮[$G쟱4I9IL =:$UmD${'}hSLM}&薥~H E?FNvE^'E J/odVߴd83i$Ц)|C.1DĆ2,'e˦G 摂f5*):%;!G␗V׶%o\#Ouu癃vj!>^jcѕlP101HȔG$bb``8,S22eF[W)K1EVk㩩"k##ʏ*<###"̌DWC۳%;QE1G#yL&1E YiK2#*(xF)k.QDXܮ%+Y E6_s.茴mم#=wBZ˔}ĔxC֒VB$(ɈKUܔBfFEX5C)X\lL*2/YrOxb"#ї%dz_9xcqP鎙52X/e(.R-0ǜbEP) 322QlXf7Y}̌Xf"tvE^'! ;(m dJ]*ͩLf6YͶmQ2v;qƫegn6Yf6R;Dܱ,:0d6CF#iKG1Hbl[9Zдtffdd9P+BFc|d^Ecd4KeZܾESߚ7 3332좊+L222222,lt:zOO: Πd1J !1AQa "2BRq#30@br$CPS`4c%s񃒓?BeF*R6Fi :!@y Oss^ޔnͿQt:ܮP{ptg6&}uFS j{EkG`{TOkc^kcl^oJO?٬g@J9PUΎJ| ;K>gtTFydwB'TUB*Mi_7]>h,i^v.h*PK4Yh‰ԑjp5M)YFb]U\C$wGR5ރXZ̧db=Ceu;Nbv18 A4dP^=]2Pjd]ey=?.0qWʻCsEWa*gںGf4dI |'IsuS0?,ÓkyOFcN~t*CcBɫH5BY,K%dY*]yEtЄˣS籽U~%86n>M !FI&kGb6[%OiH{xڃj(Pmmop>'|8D09U ]񺞴(xps{F m|pMdyߋ}A_;% n|Y^h |M&ټ"eӥw y.Pr1]|y!.̜P*8brBTV9t!1ڑwجƌnJ? t`֣56o3Usq}FSꒁ!g٬&zKCrPz3qP(r`O>[曇UʧAk*`ӽE:Sf`)57@C 7*ݣ06wvWw{U"OJ3 c1>;5Om>B XR}Wyzyv68莧,3ލt {e)ƨ> цAuOXp'זi!umR %]$ cEKp ee&67T't3d~!/f1GO_ ,NhD3(r,8_O詂fY|PY,XGG 3 ZS-S^ 9j ,帜%AI ;1ivTb}jx"N+n2EPբoU<׌hY|+FISBIKܬ:>:YTc{psu}Zqm!^ql>yFA6[QͣtjC\ЍD [ZTy?:1^yMmJ0+Bu?P979SYjF(]mX,lTg"ur%\IXmٿV (U5[' qMR}ċG,:XɊL#Ehgg檏mR&{wMߒyq(?v]W`g;We2Z$lM5kd^$A7cfɭ{q8㳶,nY:I}2>iLtvs!{ GWHm|ՔRkMVɞ0 K%d8djz!CZTXpGr6+I;xqٕqj!$-#NnvMsrVNZg8UsOwpCs$e#XhǞ'L:CZ18ylg` !5׊vO*qDZ"tSSBCp%KJ,ţb糯茳FB8ؼ]>Qǂ#<^ly=7+7Ue ?*5b@B:EU*/bo h=mv iYgG %Qg#sb U}:kF DwfV4 x dxE]ΣP> oM}j.sKuS p2=zul-a1m+Z9KXscUZ1k\wVü.dFh,Ym7Os$4\uhB,sDŽ#qsHr1m(nM}y1gQd8Z$BEy PhY}\'{whkQߚkZ={Qy!dY,JX%s㒫[ F7 Bb 0-j#kߋJ7aܯM;X-93wsjj=[9hÂkm:Žfs6>mbG6{Sz`sl p!7džԟ#U-OuI2(JUU3#*K[NRݛ_r{FaT1Y0NfI-t] $¸9t: t{Kj` Jhӻlm2N^EoFs[\tSZ"kbmN0cIݐOW1bWL` J玵Uֱ ƵܪtH8≒VѹWpzZZQ\Uvpc 0UÿՂ\zHFg Jr듛Z.upb"`/Lh.C K&NS Fn_9Qw9oaPqPx"<+#(*f (>}W%d,K%dG fvOE{ dnRdiqV*[Sި+Ud曽k#k4b7Nu[6TT5E#2lcy`uPed-!1AQaq 0@P`?!*亜 ]ijN#<C+M^#LΠ< ~V=烉rh\ρx80`:Q y;2x8Šg\iٮ$Rix0@ 0a4Nu uMyg pӠ;:=b Z䈡)?38&IM .*$/ \J6xB^evI u YYPr%X\]rӰ{ļ 1w1򑮅[`w%Z]G 5W^lJ@c]5V,[9_Yu觢^C/Pߘx~pJ*?rs?ɋ3/iVT\ӜQj Cu4p/>"Vjos$ ~%nh@|E:NvӶ'm;Qr2U ps`@X8~FϧjKe ?u6NN%œ6Q˔YF>x W~M~ ^S 赯^0PqhMu7$w`y\S?xJ9f:y)/i6u\BȚD5P@c%_tǬ{0k,lrk*f(>yn9g^uGdYo{G= c\sUD4Q7]R{!L^_({ y,C6Au %N Xu2 3B{|p8 >@Q[n8 hfYf1DJ|V$*FPco̶ƺ^YjeY!c.X,oS4;DTu\ߥMt-]fZt{q H zj*PŽmlqȚ%jt2ApU=cQ:H!OY2]M'"so+_[[y*w]?TF M(DK.Q \ܢÙCr^=~Rrk k:|syIG>p3WٯJ( %*'}Ck\<:tЁ*}8 Us TU{ WȎ8IGZ>QߴLz^/!J$8fdxH##lMW afJ9\Hlqzڨg]yrco*OY\!n oՊ ':P141>=e sSvkZ[73/)5ӳ[X(Lj!o#k E ;y(<$l˛#P"z0RtysM`*3LWP~ٖ67N=9 ex` ZN( P8"dͯj_ K״:`cq:]u8qga6]^"ηFB㞲s_U@ ;4߀;~Q;F- ~J U6_tHKf](u07\3 ,>+F Y;ʈEt?͎a&c/Pp`W0/?U{Ip0mQQ蓌C:忇 L qGgT@@T?ؽ2O_Qz ´}|?6mGf#,ޓSYu_@|~EK}{6ӃLjUdS}ʙYrPayWꄟ @3 ځ=FK 1>f("h915: Ӂ4~IX0waPsҦ{W#( ؀?`ۦW+rVLe Ym:WHn`*@^j\iV tCnhdcފ9r-xx੟$m8a(}5Ozi[;Ѫr9bŭ?WjƶՁ>׍&۠v8 ɘF 9nrq\|1B^/WU`q_'& EӀpDGOT%V_]P(:S7IsC~H,G[|>M(L}FZ@ b4,((=構M"7×^M5eg>8^vE}V_~Ϥn+/ʨ o Z]^>ǼBм.<<%+):t>bW,=FQ,TiSRSR3snquCk:DUBٝj yK6zE4#m`6qRq;p. >*=$Cpt ?Z6 ICD|HA ($P\H C$@Ca!c@FK:fxb$V֪M1$MGOLR$퇴AQ7j2&dy7V;ړm1ay?$1b+'hI  \|?Y~:4$4̢7.ܱlH&I$tOn HoLI$$H$A$$H6I$I$I$I$I$I$I$I$I$H $I$I$I$I$I$I$I$I$H9$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I nI$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$I$#!1 0A@PQ`a?4⏿RÁ V_* hCq U + u_;GBp)1pѽəc2Vzro &@+>Aep0gm{i'LHBq?! =f_%D / ?gF6^+A]1WLWށ j(L%j>ZC{Pp(U.ʨJL )O^ ф DQhAQm0d!O u9@QXb x3@Y<1d0HH} 'x!3T3%ZquL.a 4y¼E(T6ف R/<P!mDh`G 044F=T6ųSE(bi!=B}ULtp7 H/ ٍOIp|9C5z$4HTAB TKk5a҂aCQz7N5h^EѪU?dGƔ((2? iq!4Ax;  Hr:.SHO&$%`NI>>HK_/<ٰ `3e1:!:u/bư]AZv45%?Tʿ#!1 A0@QP`q?7 /,QLi,#A+%X%PK>g%#S=xBhn} y=|D4(zVoQ_+117Z:&X\ ()*: ~pUF+Q*Zں6JI8xaØU y@%I:h&O;Ō0B% JzclOd0m2|REt גUp$٨Bhُɐߓhi0l7x<дJd3 Pr7rj76AQ | 4$ǁa4(3͉^n-$b2"ҟU1,>KWc؁H͗ 4Pĺ[b?A`1ck߁s[P#[ sy0Q=J% {(ѸA?z@hz#DKĺМ=֢: =N=AۉiRDB]y1ڐTT"KʲcĢ[tQ p\C=bp#'q'B4acA!Tkƈ4DDDDشSH|=&Be" =sMAس C]#,z=.a(HDDDKbb*C%(o*ͣA1] 1n p4/]#x+ R=zi!k ! G댞'ЂHHwv #^ȋPG$4e"co,T֊|biq 5T3¨ XD~H|Ry)j^.^IJo\NWzu$̷ Ss0im `,61+F ?US8,ADiz9c Rx-fRs&/;Gf ȩI 3"ЁNa僶WPJo. Q6!]C@0zAgp?i/Z f$Ih- ueyh:yR?6ۻk%4gUp}?Vdr⒵:z-q^wb1J7_MS٠u@C ݒo:.03oP*ɐҝ|2.GcDM2e"àP #P<t umW1*~5fHEY^AYU/l~z#!e&Nq*qF:awEX%t4ɕ:Y?uw( x oHTXK̭%i/qV4dž@0'۳ԭ`3c\UᆽyQգxoW#%:DZ:UMBV"ԬgzP9JKTG, -+o C6/ 1@y|^a$0QO՛8dqZ>qSfEQұ_p _Kl nٕ/81EskxW0[#?@:_ gU fE*˃#w~0 iHYPBҎ(%cuVYqV9YU{'ߓY)0ױ Ze .L*|fX7/,:D:GެihQ#P墰CujfߋR}020H6x'M H@ A&蚪+qK$|txHʗ_\n`(S_UHv-aY3d͔zl9GIQjWK !-RUҏ.α)PF1ǘԔy l)*:ens]lij^p Vڋ. ܾ /SϢлmA\pT7+T(jj]J۸žx ~!z2hKŠ+U]DQeꄖ !%F,QmrP,㸙 K8O|!tOQD ~Q dbȉ8jx)^7a,w}ڪt+$^oMp|,jEu04E"8A >%2L̶+L 19%B4t^38]?b@ o6,rp4(橃5J7|1ʜü.00>V/L(Ҁ[O˄#hj,ōJbK˜ia S93s")Eg_@U>\;W.s#|b KTg_PA PǢcD_0[ Ԭ7'W7e#4OSdM9|"(h# yx H)e>'ġk\ v2`x?p |f!>hϔ0 ={8(Gu0<\މeHԠz\:_Xeɞ?A=PNE|)7Xݡi*ǒ yfT{G|m}^GkEﮣV4\BnS95@H@ưh t )D#F7K!6B48v68c50dC4kyHK6"8/Lfd\.yv2j2B3^ȯQn2*RQgїH7)ru @PTCk/G^a5~clnR>uDLDuWD{ l=`]j6Sr%犈# H2O\P(-@ (Sx\Rm_)%- Bt"0azk~^ VN]6qEbP9fNal? )UQKIpB6,7s.nL, X33E/>iOvP d^__F]iETXE+/"B& d~eO~ ʊ3.XJeuH$rHeMCˁxLfyw(Wx.w-܋0yK1Q./ekX,8D9GCS*)wn@df L71N\b)p8%fPĀ RZkX`ƆO2e3{4lLEX4O,2Ĩh) 54.bɓg٠:k啭ȁGd"6gтP.m}`HfłfiwTTQiB 4{u8> ¿c/)=T{MܑJ )ls&/(*>|1 \B}LXz<?+VA [ZxL}ԚۜYX:@npqsMuD,J鲟,^'ueϲ2UfͿUqp(ζ 4h|pPȜԂALQƲ83!cP MΌ>ƈ7vd 5PS9\ d VciXA'y 7CEՓu/5öV-SETLT`^\8ztE>f8 ;cNt01'9/1;ĩ\q? GK4`ҾO_1mYGt kW\V $-d1(R[SŁPT ::bHa,~'L4)T@?1w}s2Ea /xH/]PGes.Le5{zb:b*y&) Բ Zipios

We are slowly working on getting a new website going for Zipios. The main idea is that we want to be able to upload some more pages than just the documentation. Not only that, we want to support having more than one version of the documentation.

Binary Packages

We create a Debian compatible package on Launchpad. This can be found here: Zipios and other Snap! C++ packages.

Note: the list of packages includes many others that are used with Snap! C++. Zipios is likely to be the one at the bottom. Click on the name and it should open with a list of packages you can download. You should also be able to install that package repository with APT and then simply use `apt-get install libzipios` and `apt-get install libzipios-dev` as may be required by your environment. The documentation can be retrieved with `apt-get install libzipios-doc`.

Running the unit tests (v2.x)

Testing on various systesm, I determined that to all the unit tests in one go, you need about 50Mb of memory. The fact is that some tests create zip files in memory. The library used by itself would require very little in comparison unless you load a large number of files and keep them in memory.

A computer with 512Mb of RAM is enough to run the tests although I suggest at least 1Gb. One processor is enough since we do not offer a multithreaded version of the tests. However, since we use cmake, you can compile using any number of processors and that will make it a lot faster. (i.e. use the -j command line option with make to compile multiple source files at once, as in make -j16 -C BUILD; it is very fast anyway.)

CVE-2019-13453

Mike Salvadore found a bug in version 0.1.5 where a loop would never check for the end of the file flag or any other I/O error. As a result the loop would become infinite when that happened (which it could if you were to pass an invalid Zip file as input.)

Mike offered a patch, which I ameliorated a bit (a second loop was also affected) and got report CVE-2019-13453 as a result.

The patch info are in file infinite_loop.patch and version 0.1.7 is the new official version with that patch included in it.

WARNING: sourceforge.net does not offer a way to edit the CVS so the newest version is in the GIT repository instead. Make sure to switch to the GIT repository if you are directly using the source. Otherwise, just switch to the newer tarball version (0.1.7).

Zipios-2.3.2/doc/www/snap-favicon.ico000066400000000000000000000025761445164132200174600ustar00rootroot00000000000000h( HI L LMPRSW\#]%a)a*c,d.e0f0m:o=q?q@sBtCtDvFyJyKzL|O}PUVZ\]__bdeghlnsuwy{|}}~¢äĥŧŧŨǩȫɬɮδ϶иѺҺҺӼԾտűŲνTTTTTTTTTTTTTTTTTTTTT '#TTTTTTTTTTSJ3TTTTTTTTTTTTTTTTTTTTTTTy ?Zipios-2.3.2/doc/zip-format.txt000066400000000000000000004733341445164132200164110ustar00rootroot00000000000000File: APPNOTE.TXT - .ZIP File Format Specification Version: 6.3.4 Status: Final - replaces version 6.3.3 Revised: October 1, 2014 Copyright (c) 1989 - 2014 PKWARE Inc., All Rights Reserved. 1.0 Introduction --------------- 1.1 Purpose ----------- 1.1.1 This specification is intended to define a cross-platform, interoperable file storage and transfer format. Since its first publication in 1989, PKWARE, Inc. ("PKWARE") has remained committed to ensuring the interoperability of the .ZIP file format through periodic publication and maintenance of this specification. We trust that all .ZIP compatible vendors and application developers that use and benefit from this format will share and support this commitment to interoperability. 1.2 Scope --------- 1.2.1 ZIP is one of the most widely used compressed file formats. It is universally used to aggregate, compress, and encrypt files into a single interoperable container. No specific use or application need is defined by this format and no specific implementation guidance is provided. This document provides details on the storage format for creating ZIP files. Information is provided on the records and fields that describe what a ZIP file is. 1.3 Trademarks -------------- 1.3.1 PKWARE, PKZIP, SecureZIP, and PKSFX are registered trademarks of PKWARE, Inc. in the United States and elsewhere. PKPatchMaker, Deflate64, and ZIP64 are trademarks of PKWARE, Inc. Other marks referenced within this document appear for identification purposes only and are the property of their respective owners. 1.4 Permitted Use ----------------- 1.4.1 This document, "APPNOTE.TXT - .ZIP File Format Specification" is the exclusive property of PKWARE. Use of the information contained in this document is permitted solely for the purpose of creating products, programs and processes that read and write files in the ZIP format subject to the terms and conditions herein. 1.4.2 Use of the content of this document within other publications is permitted only through reference to this document. Any reproduction or distribution of this document in whole or in part without prior written permission from PKWARE is strictly prohibited. 1.4.3 Certain technological components provided in this document are the patented proprietary technology of PKWARE and as such require a separate, executed license agreement from PKWARE. Applicable components are marked with the following, or similar, statement: 'Refer to the section in this document entitled "Incorporating PKWARE Proprietary Technology into Your Product" for more information'. 1.5 Contacting PKWARE --------------------- 1.5.1 If you have questions on this format, its use, or licensing, or if you wish to report defects, request changes or additions, please contact: PKWARE, Inc. 201 E. Pittsburgh Avenue, Suite 400 Milwaukee, WI 53204 +1-414-289-9788 +1-414-289-9789 FAX zipformat@pkware.com 1.5.2 Information about this format and copies of this document are publicly available at: http://www.pkware.com/appnote 1.6 Disclaimer -------------- 1.6.1 Although PKWARE will attempt to supply current and accurate information relating to its file formats, algorithms, and the subject programs, the possibility of error or omission cannot be eliminated. PKWARE therefore expressly disclaims any warranty that the information contained in the associated materials relating to the subject programs and/or the format of the files created or accessed by the subject programs and/or the algorithms used by the subject programs, or any other matter, is current, correct or accurate as delivered. Any risk of damage due to any possible inaccurate information is assumed by the user of the information. Furthermore, the information relating to the subject programs and/or the file formats created or accessed by the subject programs and/or the algorithms used by the subject programs is subject to change without notice. 2.0 Revisions -------------- 2.1 Document Status -------------------- 2.1.1 If the STATUS of this file is marked as DRAFT, the content defines proposed revisions to this specification which may consist of changes to the ZIP format itself, or that may consist of other content changes to this document. Versions of this document and the format in DRAFT form may be subject to modification prior to publication STATUS of FINAL. DRAFT versions are published periodically to provide notification to the ZIP community of pending changes and to provide opportunity for review and comment. 2.1.2 Versions of this document having a STATUS of FINAL are considered to be in the final form for that version of the document and are not subject to further change until a new, higher version numbered document is published. Newer versions of this format specification are intended to remain interoperable with with all prior versions whenever technically possible. 2.2 Change Log -------------- Version Change Description Date ------- ------------------ ---------- 5.2 -Single Password Symmetric Encryption 07/16/2003 storage 6.1.0 -Smartcard compatibility 01/20/2004 -Documentation on certificate storage 6.2.0 -Introduction of Central Directory 04/26/2004 Encryption for encrypting metadata -Added OS X to Version Made By values 6.2.1 -Added Extra Field placeholder for 04/01/2005 POSZIP using ID 0x4690 -Clarified size field on "zip64 end of central directory record" 6.2.2 -Documented Final Feature Specification 01/06/2006 for Strong Encryption -Clarifications and typographical corrections 6.3.0 -Added tape positioning storage 09/29/2006 parameters -Expanded list of supported hash algorithms -Expanded list of supported compression algorithms -Expanded list of supported encryption algorithms -Added option for Unicode filename storage -Clarifications for consistent use of Data Descriptor records -Added additional "Extra Field" definitions 6.3.1 -Corrected standard hash values for 04/11/2007 SHA-256/384/512 6.3.2 -Added compression method 97 09/28/2007 -Documented InfoZIP "Extra Field" values for UTF-8 file name and file comment storage 6.3.3 -Formatting changes to support 09/01/2012 easier referencing of this APPNOTE from other documents and standards 6.3.4 -Address change 10/01/2014 3.0 Notations ------------- 3.1 Use of the term MUST or SHALL indicates a required element. 3.2 MAY NOT or SHALL NOT indicates an element is prohibited from use. 3.3 SHOULD indicates a RECOMMENDED element. 3.4 SHOULD NOT indicates an element NOT RECOMMENDED for use. 3.5 MAY indicates an OPTIONAL element. 4.0 ZIP Files ------------- 4.1 What is a ZIP file ---------------------- 4.1.1 ZIP files MAY be identified by the standard .ZIP file extension although use of a file extension is not required. Use of the extension .ZIPX is also recognized and MAY be used for ZIP files. Other common file extensions using the ZIP format include .JAR, .WAR, .DOCX, .XLXS, .PPTX, .ODT, .ODS, .ODP and others. Programs reading or writing ZIP files SHOULD rely on internal record signatures described in this document to identify files in this format. 4.1.2 ZIP files SHOULD contain at least one file and MAY contain multiple files. 4.1.3 Data compression MAY be used to reduce the size of files placed into a ZIP file, but is not required. This format supports the use of multiple data compression algorithms. When compression is used, one of the documented compression algorithms MUST be used. Implementors are advised to experiment with their data to determine which of the available algorithms provides the best compression for their needs. Compression method 8 (Deflate) is the method used by default by most ZIP compatible application programs. 4.1.4 Data encryption MAY be used to protect files within a ZIP file. Keying methods supported for encryption within this format include passwords and public/private keys. Either MAY be used individually or in combination. Encryption MAY be applied to individual files. Additional security MAY be used through the encryption of ZIP file metadata stored within the Central Directory. See the section on the Strong Encryption Specification for information. Refer to the section in this document entitled "Incorporating PKWARE Proprietary Technology into Your Product" for more information. 4.1.5 Data integrity MUST be provided for each file using CRC32. 4.1.6 Additional data integrity MAY be included through the use of digital signatures. Individual files MAY be signed with one or more digital signatures. The Central Directory, if signed, MUST use a single signature. 4.1.7 Files MAY be placed within a ZIP file uncompressed or stored. The term "stored" as used in the context of this document means the file is copied into the ZIP file uncompressed. 4.1.8 Each data file placed into a ZIP file MAY be compressed, stored, encrypted or digitally signed independent of how other data files in the same ZIP file are archived. 4.1.9 ZIP files MAY be streamed, split into segments (on fixed or on removable media) or "self-extracting". Self-extracting ZIP files MUST include extraction code for a target platform within the ZIP file. 4.1.10 Extensibility is provided for platform or application specific needs through extra data fields that MAY be defined for custom purposes. Extra data definitions MUST NOT conflict with existing documented record definitions. 4.1.11 Common uses for ZIP MAY also include the use of manifest files. Manifest files store application specific information within a file stored within the ZIP file. This manifest file SHOULD be the first file in the ZIP file. This specification does not provide any information or guidance on the use of manifest files within ZIP files. Refer to the application developer for information on using manifest files and for any additional profile information on using ZIP within an application. 4.1.12 ZIP files MAY be placed within other ZIP files. 4.2 ZIP Metadata ---------------- 4.2.1 ZIP files are identified by metadata consisting of defined record types containing the storage information necessary for maintaining the files placed into a ZIP file. Each record type MUST be identified using a header signature that identifies the record type. Signature values begin with the two byte constant marker of 0x4b50, representing the characters "PK". 4.3 General Format of a .ZIP file --------------------------------- 4.3.1 A ZIP file MUST contain an "end of central directory record". A ZIP file containing only an "end of central directory record" is considered an empty ZIP file. Files may be added or replaced within a ZIP file, or deleted. A ZIP file MUST have only one "end of central directory record". Other records defined in this specification MAY be used as needed to support storage requirements for individual ZIP files. 4.3.2 Each file placed into a ZIP file MUST be preceded by a "local file header" record for that file. Each "local file header" MUST be accompanied by a corresponding "central directory header" record within the central directory section of the ZIP file. 4.3.3 Files MAY be stored in arbitrary order within a ZIP file. A ZIP file MAY span multiple volumes or it MAY be split into user-defined segment sizes. All values MUST be stored in little-endian byte order unless otherwise specified in this document for a specific data element. 4.3.4 Compression MUST NOT be applied to a "local file header", an "encryption header", or an "end of central directory record". Individual "central directory records" must not be compressed, but the aggregate of all central directory records MAY be compressed. 4.3.5 File data MAY be followed by a "data descriptor" for the file. Data descriptors are used to facilitate ZIP file streaming. 4.3.6 Overall .ZIP file format: [local file header 1] [encryption header 1] [file data 1] [data descriptor 1] . . . [local file header n] [encryption header n] [file data n] [data descriptor n] [archive decryption header] [archive extra data record] [central directory header 1] . . . [central directory header n] [zip64 end of central directory record] [zip64 end of central directory locator] [end of central directory record] 4.3.7 Local file header: local file header signature 4 bytes (0x04034b50) version needed to extract 2 bytes general purpose bit flag 2 bytes compression method 2 bytes last mod file time 2 bytes last mod file date 2 bytes crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes file name length 2 bytes extra field length 2 bytes file name (variable size) extra field (variable size) 4.3.8 File data Immediately following the local header for a file SHOULD be placed the compressed or stored data for the file. If the file is encrypted, the encryption header for the file SHOULD be placed after the local header and before the file data. The series of [local file header][encryption header] [file data][data descriptor] repeats for each file in the .ZIP archive. Zero-byte files, directories, and other file types that contain no content MUST not include file data. 4.3.9 Data descriptor: crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes 4.3.9.1 This descriptor MUST exist if bit 3 of the general purpose bit flag is set (see below). It is byte aligned and immediately follows the last byte of compressed data. This descriptor SHOULD be used only when it was not possible to seek in the output .ZIP file, e.g., when the output .ZIP file was standard output or a non-seekable device. For ZIP64(tm) format archives, the compressed and uncompressed sizes are 8 bytes each. 4.3.9.2 When compressing files, compressed and uncompressed sizes should be stored in ZIP64 format (as 8 byte values) when a file's size exceeds 0xFFFFFFFF. However ZIP64 format may be used regardless of the size of a file. When extracting, if the zip64 extended information extra field is present for the file the compressed and uncompressed sizes will be 8 byte values. 4.3.9.3 Although not originally assigned a signature, the value 0x08074b50 has commonly been adopted as a signature value for the data descriptor record. Implementers should be aware that ZIP files may be encountered with or without this signature marking data descriptors and SHOULD account for either case when reading ZIP files to ensure compatibility. 4.3.9.4 When writing ZIP files, implementors SHOULD include the signature value marking the data descriptor record. When the signature is used, the fields currently defined for the data descriptor record will immediately follow the signature. 4.3.9.5 An extensible data descriptor will be released in a future version of this APPNOTE. This new record is intended to resolve conflicts with the use of this record going forward, and to provide better support for streamed file processing. 4.3.9.6 When the Central Directory Encryption method is used, the data descriptor record is not required, but MAY be used. If present, and bit 3 of the general purpose bit field is set to indicate its presence, the values in fields of the data descriptor record MUST be set to binary zeros. See the section on the Strong Encryption Specification for information. Refer to the section in this document entitled "Incorporating PKWARE Proprietary Technology into Your Product" for more information. 4.3.10 Archive decryption header: 4.3.10.1 The Archive Decryption Header is introduced in version 6.2 of the ZIP format specification. This record exists in support of the Central Directory Encryption Feature implemented as part of the Strong Encryption Specification as described in this document. When the Central Directory Structure is encrypted, this decryption header MUST precede the encrypted data segment. 4.3.10.2 The encrypted data segment SHALL consist of the Archive extra data record (if present) and the encrypted Central Directory Structure data. The format of this data record is identical to the Decryption header record preceding compressed file data. If the central directory structure is encrypted, the location of the start of this data record is determined using the Start of Central Directory field in the Zip64 End of Central Directory record. See the section on the Strong Encryption Specification for information on the fields used in the Archive Decryption Header record. Refer to the section in this document entitled "Incorporating PKWARE Proprietary Technology into Your Product" for more information. 4.3.11 Archive extra data record: archive extra data signature 4 bytes (0x08064b50) extra field length 4 bytes extra field data (variable size) 4.3.11.1 The Archive Extra Data Record is introduced in version 6.2 of the ZIP format specification. This record MAY be used in support of the Central Directory Encryption Feature implemented as part of the Strong Encryption Specification as described in this document. When present, this record MUST immediately precede the central directory data structure. 4.3.11.2 The size of this data record SHALL be included in the Size of the Central Directory field in the End of Central Directory record. If the central directory structure is compressed, but not encrypted, the location of the start of this data record is determined using the Start of Central Directory field in the Zip64 End of Central Directory record. Refer to the section in this document entitled "Incorporating PKWARE Proprietary Technology into Your Product" for more information. 4.3.12 Central directory structure: [central directory header 1] . . . [central directory header n] [digital signature] File header: central file header signature 4 bytes (0x02014b50) version made by 2 bytes version needed to extract 2 bytes general purpose bit flag 2 bytes compression method 2 bytes last mod file time 2 bytes last mod file date 2 bytes crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes file name length 2 bytes extra field length 2 bytes file comment length 2 bytes disk number start 2 bytes internal file attributes 2 bytes external file attributes 4 bytes relative offset of local header 4 bytes file name (variable size) extra field (variable size) file comment (variable size) 4.3.13 Digital signature: header signature 4 bytes (0x05054b50) size of data 2 bytes signature data (variable size) With the introduction of the Central Directory Encryption feature in version 6.2 of this specification, the Central Directory Structure MAY be stored both compressed and encrypted. Although not required, it is assumed when encrypting the Central Directory Structure, that it will be compressed for greater storage efficiency. Information on the Central Directory Encryption feature can be found in the section describing the Strong Encryption Specification. The Digital Signature record will be neither compressed nor encrypted. 4.3.14 Zip64 end of central directory record zip64 end of central dir signature 4 bytes (0x06064b50) size of zip64 end of central directory record 8 bytes version made by 2 bytes version needed to extract 2 bytes number of this disk 4 bytes number of the disk with the start of the central directory 4 bytes total number of entries in the central directory on this disk 8 bytes total number of entries in the central directory 8 bytes size of the central directory 8 bytes offset of start of central directory with respect to the starting disk number 8 bytes zip64 extensible data sector (variable size) 4.3.14.1 The value stored into the "size of zip64 end of central directory record" should be the size of the remaining record and should not include the leading 12 bytes. Size = SizeOfFixedFields + SizeOfVariableData - 12. 4.3.14.2 The above record structure defines Version 1 of the zip64 end of central directory record. Version 1 was implemented in versions of this specification preceding 6.2 in support of the ZIP64 large file feature. The introduction of the Central Directory Encryption feature implemented in version 6.2 as part of the Strong Encryption Specification defines Version 2 of this record structure. Refer to the section describing the Strong Encryption Specification for details on the version 2 format for this record. Refer to the section in this document entitled "Incorporating PKWARE Proprietary Technology into Your Product" for more information applicable to use of Version 2 of this record. 4.3.14.3 Special purpose data MAY reside in the zip64 extensible data sector field following either a V1 or V2 version of this record. To ensure identification of this special purpose data it must include an identifying header block consisting of the following: Header ID - 2 bytes Data Size - 4 bytes The Header ID field indicates the type of data that is in the data block that follows. Data Size identifies the number of bytes that follow for this data block type. 4.3.14.4 Multiple special purpose data blocks MAY be present. Each MUST be preceded by a Header ID and Data Size field. Current mappings of Header ID values supported in this field are as defined in APPENDIX C. 4.3.15 Zip64 end of central directory locator zip64 end of central dir locator signature 4 bytes (0x07064b50) number of the disk with the start of the zip64 end of central directory 4 bytes relative offset of the zip64 end of central directory record 8 bytes total number of disks 4 bytes 4.3.16 End of central directory record: end of central dir signature 4 bytes (0x06054b50) number of this disk 2 bytes number of the disk with the start of the central directory 2 bytes total number of entries in the central directory on this disk 2 bytes total number of entries in the central directory 2 bytes size of the central directory 4 bytes offset of start of central directory with respect to the starting disk number 4 bytes .ZIP file comment length 2 bytes .ZIP file comment (variable size) 4.4 Explanation of fields -------------------------- 4.4.1 General notes on fields 4.4.1.1 All fields unless otherwise noted are unsigned and stored in Intel low-byte:high-byte, low-word:high-word order. 4.4.1.2 String fields are not null terminated, since the length is given explicitly. 4.4.1.3 The entries in the central directory may not necessarily be in the same order that files appear in the .ZIP file. 4.4.1.4 If one of the fields in the end of central directory record is too small to hold required data, the field should be set to -1 (0xFFFF or 0xFFFFFFFF) and the ZIP64 format record should be created. 4.4.1.5 The end of central directory record and the Zip64 end of central directory locator record MUST reside on the same disk when splitting or spanning an archive. 4.4.2 version made by (2 bytes) 4.4.2.1 The upper byte indicates the compatibility of the file attribute information. If the external file attributes are compatible with MS-DOS and can be read by PKZIP for DOS version 2.04g then this value will be zero. If these attributes are not compatible, then this value will identify the host system on which the attributes are compatible. Software can use this information to determine the line record format for text files etc. 4.4.2.2 The current mappings are: 0 - MS-DOS and OS/2 (FAT / VFAT / FAT32 file systems) 1 - Amiga 2 - OpenVMS 3 - UNIX 4 - VM/CMS 5 - Atari ST 6 - OS/2 H.P.F.S. 7 - Macintosh 8 - Z-System 9 - CP/M 10 - Windows NTFS 11 - MVS (OS/390 - Z/OS) 12 - VSE 13 - Acorn Risc 14 - VFAT 15 - alternate MVS 16 - BeOS 17 - Tandem 18 - OS/400 19 - OS X (Darwin) 20 through 255 - unused 4.4.2.3 The lower byte indicates the ZIP specification version (the version of this document) supported by the software used to encode the file. The value/10 indicates the major version number, and the value mod 10 is the minor version number. 4.4.3 version needed to extract (2 bytes) 4.4.3.1 The minimum supported ZIP specification version needed to extract the file, mapped as above. This value is based on the specific format features a ZIP program MUST support to be able to extract the file. If multiple features are applied to a file, the minimum version MUST be set to the feature having the highest value. New features or feature changes affecting the published format specification will be implemented using higher version numbers than the last published value to avoid conflict. 4.4.3.2 Current minimum feature versions are as defined below: 1.0 - Default value 1.1 - File is a volume label 2.0 - File is a folder (directory) 2.0 - File is compressed using Deflate compression 2.0 - File is encrypted using traditional PKWARE encryption 2.1 - File is compressed using Deflate64(tm) 2.5 - File is compressed using PKWARE DCL Implode 2.7 - File is a patch data set 4.5 - File uses ZIP64 format extensions 4.6 - File is compressed using BZIP2 compression* 5.0 - File is encrypted using DES 5.0 - File is encrypted using 3DES 5.0 - File is encrypted using original RC2 encryption 5.0 - File is encrypted using RC4 encryption 5.1 - File is encrypted using AES encryption 5.1 - File is encrypted using corrected RC2 encryption** 5.2 - File is encrypted using corrected RC2-64 encryption** 6.1 - File is encrypted using non-OAEP key wrapping*** 6.2 - Central directory encryption 6.3 - File is compressed using LZMA 6.3 - File is compressed using PPMd+ 6.3 - File is encrypted using Blowfish 6.3 - File is encrypted using Twofish 4.4.3.3 Notes on version needed to extract * Early 7.x (pre-7.2) versions of PKZIP incorrectly set the version needed to extract for BZIP2 compression to be 50 when it should have been 46. ** Refer to the section on Strong Encryption Specification for additional information regarding RC2 corrections. *** Certificate encryption using non-OAEP key wrapping is the intended mode of operation for all versions beginning with 6.1. Support for OAEP key wrapping MUST only be used for backward compatibility when sending ZIP files to be opened by versions of PKZIP older than 6.1 (5.0 or 6.0). + Files compressed using PPMd MUST set the version needed to extract field to 6.3, however, not all ZIP programs enforce this and may be unable to decompress data files compressed using PPMd if this value is set. When using ZIP64 extensions, the corresponding value in the zip64 end of central directory record MUST also be set. This field should be set appropriately to indicate whether Version 1 or Version 2 format is in use. 4.4.4 general purpose bit flag: (2 bytes) Bit 0: If set, indicates that the file is encrypted. (For Method 6 - Imploding) Bit 1: If the compression method used was type 6, Imploding, then this bit, if set, indicates an 8K sliding dictionary was used. If clear, then a 4K sliding dictionary was used. Bit 2: If the compression method used was type 6, Imploding, then this bit, if set, indicates 3 Shannon-Fano trees were used to encode the sliding dictionary output. If clear, then 2 Shannon-Fano trees were used. (For Methods 8 and 9 - Deflating) Bit 2 Bit 1 0 0 Normal (-en) compression option was used. 0 1 Maximum (-exx/-ex) compression option was used. 1 0 Fast (-ef) compression option was used. 1 1 Super Fast (-es) compression option was used. (For Method 14 - LZMA) Bit 1: If the compression method used was type 14, LZMA, then this bit, if set, indicates an end-of-stream (EOS) marker is used to mark the end of the compressed data stream. If clear, then an EOS marker is not present and the compressed data size must be known to extract. Note: Bits 1 and 2 are undefined if the compression method is any other. Bit 3: If this bit is set, the fields crc-32, compressed size and uncompressed size are set to zero in the local header. The correct values are put in the data descriptor immediately following the compressed data. (Note: PKZIP version 2.04g for DOS only recognizes this bit for method 8 compression, newer versions of PKZIP recognize this bit for any compression method.) Bit 4: Reserved for use with method 8, for enhanced deflating. Bit 5: If this bit is set, this indicates that the file is compressed patched data. (Note: Requires PKZIP version 2.70 or greater) Bit 6: Strong encryption. If this bit is set, you MUST set the version needed to extract value to at least 50 and you MUST also set bit 0. If AES encryption is used, the version needed to extract value MUST be at least 51. See the section describing the Strong Encryption Specification for details. Refer to the section in this document entitled "Incorporating PKWARE Proprietary Technology into Your Product" for more information. Bit 7: Currently unused. Bit 8: Currently unused. Bit 9: Currently unused. Bit 10: Currently unused. Bit 11: Language encoding flag (EFS). If this bit is set, the filename and comment fields for this file MUST be encoded using UTF-8. (see APPENDIX D) Bit 12: Reserved by PKWARE for enhanced compression. Bit 13: Set when encrypting the Central Directory to indicate selected data values in the Local Header are masked to hide their actual values. See the section describing the Strong Encryption Specification for details. Refer to the section in this document entitled "Incorporating PKWARE Proprietary Technology into Your Product" for more information. Bit 14: Reserved by PKWARE. Bit 15: Reserved by PKWARE. 4.4.5 compression method: (2 bytes) 0 - The file is stored (no compression) 1 - The file is Shrunk 2 - The file is Reduced with compression factor 1 3 - The file is Reduced with compression factor 2 4 - The file is Reduced with compression factor 3 5 - The file is Reduced with compression factor 4 6 - The file is Imploded 7 - Reserved for Tokenizing compression algorithm 8 - The file is Deflated 9 - Enhanced Deflating using Deflate64(tm) 10 - PKWARE Data Compression Library Imploding (old IBM TERSE) 11 - Reserved by PKWARE 12 - File is compressed using BZIP2 algorithm 13 - Reserved by PKWARE 14 - LZMA (EFS) 15 - Reserved by PKWARE 16 - Reserved by PKWARE 17 - Reserved by PKWARE 18 - File is compressed using IBM TERSE (new) 19 - IBM LZ77 z Architecture (PFS) 97 - WavPack compressed data 98 - PPMd version I, Rev 1 4.4.6 date and time fields: (2 bytes each) The date and time are encoded in standard MS-DOS format. If input came from standard input, the date and time are those at which compression was started for this data. If encrypting the central directory and general purpose bit flag 13 is set indicating masking, the value stored in the Local Header will be zero. 4.4.7 CRC-32: (4 bytes) The CRC-32 algorithm was generously contributed by David Schwaderer and can be found in his excellent book "C Programmers Guide to NetBIOS" published by Howard W. Sams & Co. Inc. The 'magic number' for the CRC is 0xdebb20e3. The proper CRC pre and post conditioning is used, meaning that the CRC register is pre-conditioned with all ones (a starting value of 0xffffffff) and the value is post-conditioned by taking the one's complement of the CRC residual. If bit 3 of the general purpose flag is set, this field is set to zero in the local header and the correct value is put in the data descriptor and in the central directory. When encrypting the central directory, if the local header is not in ZIP64 format and general purpose bit flag 13 is set indicating masking, the value stored in the Local Header will be zero. 4.4.8 compressed size: (4 bytes) 4.4.9 uncompressed size: (4 bytes) The size of the file compressed (4.4.8) and uncompressed, (4.4.9) respectively. When a decryption header is present it will be placed in front of the file data and the value of the compressed file size will include the bytes of the decryption header. If bit 3 of the general purpose bit flag is set, these fields are set to zero in the local header and the correct values are put in the data descriptor and in the central directory. If an archive is in ZIP64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte ZIP64 extended information extra field. When encrypting the central directory, if the local header is not in ZIP64 format and general purpose bit flag 13 is set indicating masking, the value stored for the uncompressed size in the Local Header will be zero. 4.4.10 file name length: (2 bytes) 4.4.11 extra field length: (2 bytes) 4.4.12 file comment length: (2 bytes) The length of the file name, extra field, and comment fields respectively. The combined length of any directory record and these three fields should not generally exceed 65,535 bytes. If input came from standard input, the file name length is set to zero. 4.4.13 disk number start: (2 bytes) The number of the disk on which this file begins. If an archive is in ZIP64 format and the value in this field is 0xFFFF, the size will be in the corresponding 4 byte zip64 extended information extra field. 4.4.14 internal file attributes: (2 bytes) Bits 1 and 2 are reserved for use by PKWARE. 4.4.14.1 The lowest bit of this field indicates, if set, that the file is apparently an ASCII or text file. If not set, that the file apparently contains binary data. The remaining bits are unused in version 1.0. 4.4.14.2 The 0x0002 bit of this field indicates, if set, that a 4 byte variable record length control field precedes each logical record indicating the length of the record. The record length control field is stored in little-endian byte order. This flag is independent of text control characters, and if used in conjunction with text data, includes any control characters in the total length of the record. This value is provided for mainframe data transfer support. 4.4.15 external file attributes: (4 bytes) The mapping of the external attributes is host-system dependent (see 'version made by'). For MS-DOS, the low order byte is the MS-DOS directory attribute byte. If input came from standard input, this field is set to zero. 4.4.16 relative offset of local header: (4 bytes) This is the offset from the start of the first disk on which this file appears, to where the local header should be found. If an archive is in ZIP64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte zip64 extended information extra field. 4.4.17 file name: (Variable) 4.4.17.1 The name of the file, with optional relative path. The path stored MUST not contain a drive or device letter, or a leading slash. All slashes MUST be forward slashes '/' as opposed to backwards slashes '\' for compatibility with Amiga and UNIX file systems etc. If input came from standard input, there is no file name field. 4.4.17.2 If using the Central Directory Encryption Feature and general purpose bit flag 13 is set indicating masking, the file name stored in the Local Header will not be the actual file name. A masking value consisting of a unique hexadecimal value will be stored. This value will be sequentially incremented for each file in the archive. See the section on the Strong Encryption Specification for details on retrieving the encrypted file name. Refer to the section in this document entitled "Incorporating PKWARE Proprietary Technology into Your Product" for more information. 4.4.18 file comment: (Variable) The comment for this file. 4.4.19 number of this disk: (2 bytes) The number of this disk, which contains central directory end record. If an archive is in ZIP64 format and the value in this field is 0xFFFF, the size will be in the corresponding 4 byte zip64 end of central directory field. 4.4.20 number of the disk with the start of the central directory: (2 bytes) The number of the disk on which the central directory starts. If an archive is in ZIP64 format and the value in this field is 0xFFFF, the size will be in the corresponding 4 byte zip64 end of central directory field. 4.4.21 total number of entries in the central dir on this disk: (2 bytes) The number of central directory entries on this disk. If an archive is in ZIP64 format and the value in this field is 0xFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field. 4.4.22 total number of entries in the central dir: (2 bytes) The total number of files in the .ZIP file. If an archive is in ZIP64 format and the value in this field is 0xFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field. 4.4.23 size of the central directory: (4 bytes) The size (in bytes) of the entire central directory. If an archive is in ZIP64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field. 4.4.24 offset of start of central directory with respect to the starting disk number: (4 bytes) Offset of the start of the central directory on the disk on which the central directory starts. If an archive is in ZIP64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte zip64 end of central directory field. 4.4.25 .ZIP file comment length: (2 bytes) The length of the comment for this .ZIP file. 4.4.26 .ZIP file comment: (Variable) The comment for this .ZIP file. ZIP file comment data is stored unsecured. No encryption or data authentication is applied to this area at this time. Confidential information should not be stored in this section. 4.4.27 zip64 extensible data sector (variable size) (currently reserved for use by PKWARE) 4.4.28 extra field: (Variable) This SHOULD be used for storage expansion. If additional information needs to be stored within a ZIP file for special application or platform needs, it SHOULD be stored here. Programs supporting earlier versions of this specification can then safely skip the file, and find the next file or header. This field will be 0 length in version 1.0. Existing extra fields are defined in the section Extensible data fields that follows. 4.5 Extensible data fields -------------------------- 4.5.1 In order to allow different programs and different types of information to be stored in the 'extra' field in .ZIP files, the following structure MUST be used for all programs storing data in this field: header1+data1 + header2+data2 . . . Each header should consist of: Header ID - 2 bytes Data Size - 2 bytes Note: all fields stored in Intel low-byte/high-byte order. The Header ID field indicates the type of data that is in the following data block. Header IDs of 0 through 31 are reserved for use by PKWARE. The remaining IDs can be used by third party vendors for proprietary usage. 4.5.2 The current Header ID mappings defined by PKWARE are: 0x0001 Zip64 extended information extra field 0x0007 AV Info 0x0008 Reserved for extended language encoding data (PFS) (see APPENDIX D) 0x0009 OS/2 0x000a NTFS 0x000c OpenVMS 0x000d UNIX 0x000e Reserved for file stream and fork descriptors 0x000f Patch Descriptor 0x0014 PKCS#7 Store for X.509 Certificates 0x0015 X.509 Certificate ID and Signature for individual file 0x0016 X.509 Certificate ID for Central Directory 0x0017 Strong Encryption Header 0x0018 Record Management Controls 0x0019 PKCS#7 Encryption Recipient Certificate List 0x0065 IBM S/390 (Z390), AS/400 (I400) attributes - uncompressed 0x0066 Reserved for IBM S/390 (Z390), AS/400 (I400) attributes - compressed 0x4690 POSZIP 4690 (reserved) 4.5.3 -Zip64 Extended Information Extra Field (0x0001): The following is the layout of the zip64 extended information "extra" block. If one of the size or offset fields in the Local or Central directory record is too small to hold the required data, a Zip64 extended information record is created. The order of the fields in the zip64 extended information record is fixed, but the fields MUST only appear if the corresponding Local or Central directory record field is set to 0xFFFF or 0xFFFFFFFF. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (ZIP64) 0x0001 2 bytes Tag for this "extra" block type Size 2 bytes Size of this "extra" block Original Size 8 bytes Original uncompressed file size Compressed Size 8 bytes Size of compressed data Relative Header Offset 8 bytes Offset of local header record Disk Start Number 4 bytes Number of the disk on which this file starts This entry in the Local header MUST include BOTH original and compressed file size fields. If encrypting the central directory and bit 13 of the general purpose bit flag is set indicating masking, the value stored in the Local Header for the original file size will be zero. 4.5.4 -OS/2 Extra Field (0x0009): The following is the layout of the OS/2 attributes "extra" block. (Last Revision 09/05/95) Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (OS/2) 0x0009 2 bytes Tag for this "extra" block type TSize 2 bytes Size for the following data block BSize 4 bytes Uncompressed Block Size CType 2 bytes Compression type EACRC 4 bytes CRC value for uncompress block (var) variable Compressed block The OS/2 extended attribute structure (FEA2LIST) is compressed and then stored in its entirety within this structure. There will only ever be one "block" of data in VarFields[]. 4.5.5 -NTFS Extra Field (0x000a): The following is the layout of the NTFS attributes "extra" block. (Note: At this time the Mtime, Atime and Ctime values MAY be used on any WIN32 system.) Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (NTFS) 0x000a 2 bytes Tag for this "extra" block type TSize 2 bytes Size of the total "extra" block Reserved 4 bytes Reserved for future use Tag1 2 bytes NTFS attribute tag value #1 Size1 2 bytes Size of attribute #1, in bytes (var) Size1 Attribute #1 data . . . TagN 2 bytes NTFS attribute tag value #N SizeN 2 bytes Size of attribute #N, in bytes (var) SizeN Attribute #N data For NTFS, values for Tag1 through TagN are as follows: (currently only one set of attributes is defined for NTFS) Tag Size Description ----- ---- ----------- 0x0001 2 bytes Tag for attribute #1 Size1 2 bytes Size of attribute #1, in bytes Mtime 8 bytes File last modification time Atime 8 bytes File last access time Ctime 8 bytes File creation time 4.5.6 -OpenVMS Extra Field (0x000c): The following is the layout of the OpenVMS attributes "extra" block. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (VMS) 0x000c 2 bytes Tag for this "extra" block type TSize 2 bytes Size of the total "extra" block CRC 4 bytes 32-bit CRC for remainder of the block Tag1 2 bytes OpenVMS attribute tag value #1 Size1 2 bytes Size of attribute #1, in bytes (var) Size1 Attribute #1 data . . . TagN 2 bytes OpenVMS attribute tag value #N SizeN 2 bytes Size of attribute #N, in bytes (var) SizeN Attribute #N data OpenVMS Extra Field Rules: 4.5.6.1. There will be one or more attributes present, which will each be preceded by the above TagX & SizeX values. These values are identical to the ATR$C_XXXX and ATR$S_XXXX constants which are defined in ATR.H under OpenVMS C. Neither of these values will ever be zero. 4.5.6.2. No word alignment or padding is performed. 4.5.6.3. A well-behaved PKZIP/OpenVMS program should never produce more than one sub-block with the same TagX value. Also, there will never be more than one "extra" block of type 0x000c in a particular directory record. 4.5.7 -UNIX Extra Field (0x000d): The following is the layout of the UNIX "extra" block. Note: all fields are stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (UNIX) 0x000d 2 bytes Tag for this "extra" block type TSize 2 bytes Size for the following data block Atime 4 bytes File last access time Mtime 4 bytes File last modification time Uid 2 bytes File user ID Gid 2 bytes File group ID (var) variable Variable length data field The variable length data field will contain file type specific data. Currently the only values allowed are the original "linked to" file names for hard or symbolic links, and the major and minor device node numbers for character and block device nodes. Since device nodes cannot be either symbolic or hard links, only one set of variable length data is stored. Link files will have the name of the original file stored. This name is NOT NULL terminated. Its size can be determined by checking TSize - 12. Device entries will have eight bytes stored as two 4 byte entries (in little endian format). The first entry will be the major device number, and the second the minor device number. 4.5.8 -PATCH Descriptor Extra Field (0x000f): 4.5.8.1 The following is the layout of the Patch Descriptor "extra" block. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (Patch) 0x000f 2 bytes Tag for this "extra" block type TSize 2 bytes Size of the total "extra" block Version 2 bytes Version of the descriptor Flags 4 bytes Actions and reactions (see below) OldSize 4 bytes Size of the file about to be patched OldCRC 4 bytes 32-bit CRC of the file to be patched NewSize 4 bytes Size of the resulting file NewCRC 4 bytes 32-bit CRC of the resulting file 4.5.8.2 Actions and reactions Bits Description ---- ---------------- 0 Use for auto detection 1 Treat as a self-patch 2-3 RESERVED 4-5 Action (see below) 6-7 RESERVED 8-9 Reaction (see below) to absent file 10-11 Reaction (see below) to newer file 12-13 Reaction (see below) to unknown file 14-15 RESERVED 16-31 RESERVED 4.5.8.2.1 Actions Action Value ------ ----- none 0 add 1 delete 2 patch 3 4.5.8.2.2 Reactions Reaction Value -------- ----- ask 0 skip 1 ignore 2 fail 3 4.5.8.3 Patch support is provided by PKPatchMaker(tm) technology and is covered under U.S. Patents and Patents Pending. The use or implementation in a product of certain technological aspects set forth in the current APPNOTE, including those with regard to strong encryption or patching requires a license from PKWARE. Refer to the section in this document entitled "Incorporating PKWARE Proprietary Technology into Your Product" for more information. 4.5.9 -PKCS#7 Store for X.509 Certificates (0x0014): This field MUST contain information about each of the certificates files may be signed with. When the Central Directory Encryption feature is enabled for a ZIP file, this record will appear in the Archive Extra Data Record, otherwise it will appear in the first central directory record and will be ignored in any other record. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (Store) 0x0014 2 bytes Tag for this "extra" block type TSize 2 bytes Size of the store data TData TSize Data about the store 4.5.10 -X.509 Certificate ID and Signature for individual file (0x0015): This field contains the information about which certificate in the PKCS#7 store was used to sign a particular file. It also contains the signature data. This field can appear multiple times, but can only appear once per certificate. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (CID) 0x0015 2 bytes Tag for this "extra" block type TSize 2 bytes Size of data that follows TData TSize Signature Data 4.5.11 -X.509 Certificate ID and Signature for central directory (0x0016): This field contains the information about which certificate in the PKCS#7 store was used to sign the central directory structure. When the Central Directory Encryption feature is enabled for a ZIP file, this record will appear in the Archive Extra Data Record, otherwise it will appear in the first central directory record. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (CDID) 0x0016 2 bytes Tag for this "extra" block type TSize 2 bytes Size of data that follows TData TSize Data 4.5.12 -Strong Encryption Header (0x0017): Value Size Description ----- ---- ----------- 0x0017 2 bytes Tag for this "extra" block type TSize 2 bytes Size of data that follows Format 2 bytes Format definition for this record AlgID 2 bytes Encryption algorithm identifier Bitlen 2 bytes Bit length of encryption key Flags 2 bytes Processing flags CertData TSize-8 Certificate decryption extra field data (refer to the explanation for CertData in the section describing the Certificate Processing Method under the Strong Encryption Specification) See the section describing the Strong Encryption Specification for details. Refer to the section in this document entitled "Incorporating PKWARE Proprietary Technology into Your Product" for more information. 4.5.13 -Record Management Controls (0x0018): Value Size Description ----- ---- ----------- (Rec-CTL) 0x0018 2 bytes Tag for this "extra" block type CSize 2 bytes Size of total extra block data Tag1 2 bytes Record control attribute 1 Size1 2 bytes Size of attribute 1, in bytes Data1 Size1 Attribute 1 data . . . TagN 2 bytes Record control attribute N SizeN 2 bytes Size of attribute N, in bytes DataN SizeN Attribute N data 4.5.14 -PKCS#7 Encryption Recipient Certificate List (0x0019): This field MAY contain information about each of the certificates used in encryption processing and it can be used to identify who is allowed to decrypt encrypted files. This field should only appear in the archive extra data record. This field is not required and serves only to aid archive modifications by preserving public encryption key data. Individual security requirements may dictate that this data be omitted to deter information exposure. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (CStore) 0x0019 2 bytes Tag for this "extra" block type TSize 2 bytes Size of the store data TData TSize Data about the store TData: Value Size Description ----- ---- ----------- Version 2 bytes Format version number - must 0x0001 at this time CStore (var) PKCS#7 data blob See the section describing the Strong Encryption Specification for details. Refer to the section in this document entitled "Incorporating PKWARE Proprietary Technology into Your Product" for more information. 4.5.15 -MVS Extra Field (0x0065): The following is the layout of the MVS "extra" block. Note: Some fields are stored in Big Endian format. All text is in EBCDIC format unless otherwise specified. Value Size Description ----- ---- ----------- (MVS) 0x0065 2 bytes Tag for this "extra" block type TSize 2 bytes Size for the following data block ID 4 bytes EBCDIC "Z390" 0xE9F3F9F0 or "T4MV" for TargetFour (var) TSize-4 Attribute data (see APPENDIX B) 4.5.16 -OS/400 Extra Field (0x0065): The following is the layout of the OS/400 "extra" block. Note: Some fields are stored in Big Endian format. All text is in EBCDIC format unless otherwise specified. Value Size Description ----- ---- ----------- (OS400) 0x0065 2 bytes Tag for this "extra" block type TSize 2 bytes Size for the following data block ID 4 bytes EBCDIC "I400" 0xC9F4F0F0 or "T4MV" for TargetFour (var) TSize-4 Attribute data (see APPENDIX A) 4.6 Third Party Mappings ------------------------ 4.6.1 Third party mappings commonly used are: 0x07c8 Macintosh 0x2605 ZipIt Macintosh 0x2705 ZipIt Macintosh 1.3.5+ 0x2805 ZipIt Macintosh 1.3.5+ 0x334d Info-ZIP Macintosh 0x4341 Acorn/SparkFS 0x4453 Windows NT security descriptor (binary ACL) 0x4704 VM/CMS 0x470f MVS 0x4b46 FWKCS MD5 (see below) 0x4c41 OS/2 access control list (text ACL) 0x4d49 Info-ZIP OpenVMS 0x4f4c Xceed original location extra field 0x5356 AOS/VS (ACL) 0x5455 extended timestamp 0x554e Xceed unicode extra field 0x5855 Info-ZIP UNIX (original, also OS/2, NT, etc) 0x6375 Info-ZIP Unicode Comment Extra Field 0x6542 BeOS/BeBox 0x7075 Info-ZIP Unicode Path Extra Field 0x756e ASi UNIX 0x7855 Info-ZIP UNIX (new) 0xa220 Microsoft Open Packaging Growth Hint 0xfd4a SMS/QDOS Detailed descriptions of Extra Fields defined by third party mappings will be documented as information on these data structures is made available to PKWARE. PKWARE does not guarantee the accuracy of any published third party data. 4.6.2 Third-party Extra Fields must include a Header ID using the format defined in the section of this document titled Extensible Data Fields (section 4.5). The Data Size field indicates the size of the following data block. Programs can use this value to skip to the next header block, passing over any data blocks that are not of interest. Note: As stated above, the size of the entire .ZIP file header, including the file name, comment, and extra field should not exceed 64K in size. 4.6.3 In case two different programs should appropriate the same Header ID value, it is strongly recommended that each program SHOULD place a unique signature of at least two bytes in size (and preferably 4 bytes or bigger) at the start of each data area. Every program SHOULD verify that its unique signature is present, in addition to the Header ID value being correct, before assuming that it is a block of known type. Third-party Mappings: 4.6.4 -ZipIt Macintosh Extra Field (long) (0x2605): The following is the layout of the ZipIt extra block for Macintosh. The local-header and central-header versions are identical. This block must be present if the file is stored MacBinary-encoded and it should not be used if the file is not stored MacBinary-encoded. Value Size Description ----- ---- ----------- (Mac2) 0x2605 Short tag for this extra block type TSize Short total data size for this block "ZPIT" beLong extra-field signature FnLen Byte length of FileName FileName variable full Macintosh filename FileType Byte[4] four-byte Mac file type string Creator Byte[4] four-byte Mac creator string 4.6.5 -ZipIt Macintosh Extra Field (short, for files) (0x2705): The following is the layout of a shortened variant of the ZipIt extra block for Macintosh (without "full name" entry). This variant is used by ZipIt 1.3.5 and newer for entries of files (not directories) that do not have a MacBinary encoded file. The local-header and central-header versions are identical. Value Size Description ----- ---- ----------- (Mac2b) 0x2705 Short tag for this extra block type TSize Short total data size for this block (12) "ZPIT" beLong extra-field signature FileType Byte[4] four-byte Mac file type string Creator Byte[4] four-byte Mac creator string fdFlags beShort attributes from FInfo.frFlags, may be omitted 0x0000 beShort reserved, may be omitted 4.6.6 -ZipIt Macintosh Extra Field (short, for directories) (0x2805): The following is the layout of a shortened variant of the ZipIt extra block for Macintosh used only for directory entries. This variant is used by ZipIt 1.3.5 and newer to save some optional Mac-specific information about directories. The local-header and central-header versions are identical. Value Size Description ----- ---- ----------- (Mac2c) 0x2805 Short tag for this extra block type TSize Short total data size for this block (12) "ZPIT" beLong extra-field signature frFlags beShort attributes from DInfo.frFlags, may be omitted View beShort ZipIt view flag, may be omitted The View field specifies ZipIt-internal settings as follows: Bits of the Flags: bit 0 if set, the folder is shown expanded (open) when the archive contents are viewed in ZipIt. bits 1-15 reserved, zero; 4.6.7 -FWKCS MD5 Extra Field (0x4b46): The FWKCS Contents_Signature System, used in automatically identifying files independent of file name, optionally adds and uses an extra field to support the rapid creation of an enhanced contents_signature: Header ID = 0x4b46 Data Size = 0x0013 Preface = 'M','D','5' followed by 16 bytes containing the uncompressed file's 128_bit MD5 hash(1), low byte first. When FWKCS revises a .ZIP file central directory to add this extra field for a file, it also replaces the central directory entry for that file's uncompressed file length with a measured value. FWKCS provides an option to strip this extra field, if present, from a .ZIP file central directory. In adding this extra field, FWKCS preserves .ZIP file Authenticity Verification; if stripping this extra field, FWKCS preserves all versions of AV through PKZIP version 2.04g. FWKCS, and FWKCS Contents_Signature System, are trademarks of Frederick W. Kantor. (1) R. Rivest, RFC1321.TXT, MIT Laboratory for Computer Science and RSA Data Security, Inc., April 1992. ll.76-77: "The MD5 algorithm is being placed in the public domain for review and possible adoption as a standard." 4.6.8 -Info-ZIP Unicode Comment Extra Field (0x6375): Stores the UTF-8 version of the file comment as stored in the central directory header. (Last Revision 20070912) Value Size Description ----- ---- ----------- (UCom) 0x6375 Short tag for this extra block type ("uc") TSize Short total data size for this block Version 1 byte version of this extra field, currently 1 ComCRC32 4 bytes Comment Field CRC32 Checksum UnicodeCom Variable UTF-8 version of the entry comment Currently Version is set to the number 1. If there is a need to change this field, the version will be incremented. Changes may not be backward compatible so this extra field should not be used if the version is not recognized. The ComCRC32 is the standard zip CRC32 checksum of the File Comment field in the central directory header. This is used to verify that the comment field has not changed since the Unicode Comment extra field was created. This can happen if a utility changes the File Comment field but does not update the UTF-8 Comment extra field. If the CRC check fails, this Unicode Comment extra field should be ignored and the File Comment field in the header should be used instead. The UnicodeCom field is the UTF-8 version of the File Comment field in the header. As UnicodeCom is defined to be UTF-8, no UTF-8 byte order mark (BOM) is used. The length of this field is determined by subtracting the size of the previous fields from TSize. If both the File Name and Comment fields are UTF-8, the new General Purpose Bit Flag, bit 11 (Language encoding flag (EFS)), can be used to indicate both the header File Name and Comment fields are UTF-8 and, in this case, the Unicode Path and Unicode Comment extra fields are not needed and should not be created. Note that, for backward compatibility, bit 11 should only be used if the native character set of the paths and comments being zipped up are already in UTF-8. It is expected that the same file comment storage method, either general purpose bit 11 or extra fields, be used in both the Local and Central Directory Header for a file. 4.6.9 -Info-ZIP Unicode Path Extra Field (0x7075): Stores the UTF-8 version of the file name field as stored in the local header and central directory header. (Last Revision 20070912) Value Size Description ----- ---- ----------- (UPath) 0x7075 Short tag for this extra block type ("up") TSize Short total data size for this block Version 1 byte version of this extra field, currently 1 NameCRC32 4 bytes File Name Field CRC32 Checksum UnicodeName Variable UTF-8 version of the entry File Name Currently Version is set to the number 1. If there is a need to change this field, the version will be incremented. Changes may not be backward compatible so this extra field should not be used if the version is not recognized. The NameCRC32 is the standard zip CRC32 checksum of the File Name field in the header. This is used to verify that the header File Name field has not changed since the Unicode Path extra field was created. This can happen if a utility renames the File Name but does not update the UTF-8 path extra field. If the CRC check fails, this UTF-8 Path Extra Field should be ignored and the File Name field in the header should be used instead. The UnicodeName is the UTF-8 version of the contents of the File Name field in the header. As UnicodeName is defined to be UTF-8, no UTF-8 byte order mark (BOM) is used. The length of this field is determined by subtracting the size of the previous fields from TSize. If both the File Name and Comment fields are UTF-8, the new General Purpose Bit Flag, bit 11 (Language encoding flag (EFS)), can be used to indicate that both the header File Name and Comment fields are UTF-8 and, in this case, the Unicode Path and Unicode Comment extra fields are not needed and should not be created. Note that, for backward compatibility, bit 11 should only be used if the native character set of the paths and comments being zipped up are already in UTF-8. It is expected that the same file name storage method, either general purpose bit 11 or extra fields, be used in both the Local and Central Directory Header for a file. 4.6.10 -Microsoft Open Packaging Growth Hint (0xa220): Value Size Description ----- ---- ----------- 0xa220 Short tag for this extra block type TSize Short size of Sig + PadVal + Padding Sig Short verification signature (A028) PadVal Short Initial padding value Padding variable filled with NULL characters 4.7 Manifest Files ------------------ 4.7.1 Applications using ZIP files may have a need for additional information that must be included with the files placed into a ZIP file. Application specific information that cannot be stored using the defined ZIP storage records SHOULD be stored using the extensible Extra Field convention defined in this document. However, some applications may use a manifest file as a means for storing additional information. One example is the META-INF/MANIFEST.MF file used in ZIP formatted files having the .JAR extension (JAR files). 4.7.2 A manifest file is a file created for the application process that requires this information. A manifest file MAY be of any file type required by the defining application process. It is placed within the same ZIP file as files to which this information applies. By convention, this file is typically the first file placed into the ZIP file and it may include a defined directory path. 4.7.3 Manifest files may be compressed or encrypted as needed for application processing of the files inside the ZIP files. Manifest files are outside of the scope of this specification. 5.0 Explanation of compression methods -------------------------------------- 5.1 UnShrinking - Method 1 -------------------------- 5.1.1 Shrinking is a Dynamic Ziv-Lempel-Welch compression algorithm with partial clearing. The initial code size is 9 bits, and the maximum code size is 13 bits. Shrinking differs from conventional Dynamic Ziv-Lempel-Welch implementations in several respects: 5.1.2 The code size is controlled by the compressor, and is not automatically increased when codes larger than the current code size are created (but not necessarily used). When the decompressor encounters the code sequence 256 (decimal) followed by 1, it should increase the code size read from the input stream to the next bit size. No blocking of the codes is performed, so the next code at the increased size should be read from the input stream immediately after where the previous code at the smaller bit size was read. Again, the decompressor should not increase the code size used until the sequence 256,1 is encountered. 5.1.3 When the table becomes full, total clearing is not performed. Rather, when the compressor emits the code sequence 256,2 (decimal), the decompressor should clear all leaf nodes from the Ziv-Lempel tree, and continue to use the current code size. The nodes that are cleared from the Ziv-Lempel tree are then re-used, with the lowest code value re-used first, and the highest code value re-used last. The compressor can emit the sequence 256,2 at any time. 5.2 Expanding - Methods 2-5 --------------------------- 5.2.1 The Reducing algorithm is actually a combination of two distinct algorithms. The first algorithm compresses repeated byte sequences, and the second algorithm takes the compressed stream from the first algorithm and applies a probabilistic compression method. 5.2.2 The probabilistic compression stores an array of 'follower sets' S(j), for j=0 to 255, corresponding to each possible ASCII character. Each set contains between 0 and 32 characters, to be denoted as S(j)[0],...,S(j)[m], where m<32. The sets are stored at the beginning of the data area for a Reduced file, in reverse order, with S(255) first, and S(0) last. 5.2.3 The sets are encoded as { N(j), S(j)[0],...,S(j)[N(j)-1] }, where N(j) is the size of set S(j). N(j) can be 0, in which case the follower set for S(j) is empty. Each N(j) value is encoded in 6 bits, followed by N(j) eight bit character values corresponding to S(j)[0] to S(j)[N(j)-1] respectively. If N(j) is 0, then no values for S(j) are stored, and the value for N(j-1) immediately follows. 5.2.4 Immediately after the follower sets, is the compressed data stream. The compressed data stream can be interpreted for the probabilistic decompression as follows: let Last-Character <- 0. loop until done if the follower set S(Last-Character) is empty then read 8 bits from the input stream, and copy this value to the output stream. otherwise if the follower set S(Last-Character) is non-empty then read 1 bit from the input stream. if this bit is not zero then read 8 bits from the input stream, and copy this value to the output stream. otherwise if this bit is zero then read B(N(Last-Character)) bits from the input stream, and assign this value to I. Copy the value of S(Last-Character)[I] to the output stream. assign the last value placed on the output stream to Last-Character. end loop B(N(j)) is defined as the minimal number of bits required to encode the value N(j)-1. 5.2.5 The decompressed stream from above can then be expanded to re-create the original file as follows: let State <- 0. loop until done read 8 bits from the input stream into C. case State of 0: if C is not equal to DLE (144 decimal) then copy C to the output stream. otherwise if C is equal to DLE then let State <- 1. 1: if C is non-zero then let V <- C. let Len <- L(V) let State <- F(Len). otherwise if C is zero then copy the value 144 (decimal) to the output stream. let State <- 0 2: let Len <- Len + C let State <- 3. 3: move backwards D(V,C) bytes in the output stream (if this position is before the start of the output stream, then assume that all the data before the start of the output stream is filled with zeros). copy Len+3 bytes from this position to the output stream. let State <- 0. end case end loop The functions F,L, and D are dependent on the 'compression factor', 1 through 4, and are defined as follows: For compression factor 1: L(X) equals the lower 7 bits of X. F(X) equals 2 if X equals 127 otherwise F(X) equals 3. D(X,Y) equals the (upper 1 bit of X) * 256 + Y + 1. For compression factor 2: L(X) equals the lower 6 bits of X. F(X) equals 2 if X equals 63 otherwise F(X) equals 3. D(X,Y) equals the (upper 2 bits of X) * 256 + Y + 1. For compression factor 3: L(X) equals the lower 5 bits of X. F(X) equals 2 if X equals 31 otherwise F(X) equals 3. D(X,Y) equals the (upper 3 bits of X) * 256 + Y + 1. For compression factor 4: L(X) equals the lower 4 bits of X. F(X) equals 2 if X equals 15 otherwise F(X) equals 3. D(X,Y) equals the (upper 4 bits of X) * 256 + Y + 1. 5.3 Imploding - Method 6 ------------------------ 5.3.1 The Imploding algorithm is actually a combination of two distinct algorithms. The first algorithm compresses repeated byte sequences using a sliding dictionary. The second algorithm is used to compress the encoding of the sliding dictionary output, using multiple Shannon-Fano trees. 5.3.2 The Imploding algorithm can use a 4K or 8K sliding dictionary size. The dictionary size used can be determined by bit 1 in the general purpose flag word; a 0 bit indicates a 4K dictionary while a 1 bit indicates an 8K dictionary. 5.3.3 The Shannon-Fano trees are stored at the start of the compressed file. The number of trees stored is defined by bit 2 in the general purpose flag word; a 0 bit indicates two trees stored, a 1 bit indicates three trees are stored. If 3 trees are stored, the first Shannon-Fano tree represents the encoding of the Literal characters, the second tree represents the encoding of the Length information, the third represents the encoding of the Distance information. When 2 Shannon-Fano trees are stored, the Length tree is stored first, followed by the Distance tree. 5.3.4 The Literal Shannon-Fano tree, if present is used to represent the entire ASCII character set, and contains 256 values. This tree is used to compress any data not compressed by the sliding dictionary algorithm. When this tree is present, the Minimum Match Length for the sliding dictionary is 3. If this tree is not present, the Minimum Match Length is 2. 5.3.5 The Length Shannon-Fano tree is used to compress the Length part of the (length,distance) pairs from the sliding dictionary output. The Length tree contains 64 values, ranging from the Minimum Match Length, to 63 plus the Minimum Match Length. 5.3.6 The Distance Shannon-Fano tree is used to compress the Distance part of the (length,distance) pairs from the sliding dictionary output. The Distance tree contains 64 values, ranging from 0 to 63, representing the upper 6 bits of the distance value. The distance values themselves will be between 0 and the sliding dictionary size, either 4K or 8K. 5.3.7 The Shannon-Fano trees themselves are stored in a compressed format. The first byte of the tree data represents the number of bytes of data representing the (compressed) Shannon-Fano tree minus 1. The remaining bytes represent the Shannon-Fano tree data encoded as: High 4 bits: Number of values at this bit length + 1. (1 - 16) Low 4 bits: Bit Length needed to represent value + 1. (1 - 16) 5.3.8 The Shannon-Fano codes can be constructed from the bit lengths using the following algorithm: 1) Sort the Bit Lengths in ascending order, while retaining the order of the original lengths stored in the file. 2) Generate the Shannon-Fano trees: Code <- 0 CodeIncrement <- 0 LastBitLength <- 0 i <- number of Shannon-Fano codes - 1 (either 255 or 63) loop while i >= 0 Code = Code + CodeIncrement if BitLength(i) <> LastBitLength then LastBitLength=BitLength(i) CodeIncrement = 1 shifted left (16 - LastBitLength) ShannonCode(i) = Code i <- i - 1 end loop 3) Reverse the order of all the bits in the above ShannonCode() vector, so that the most significant bit becomes the least significant bit. For example, the value 0x1234 (hex) would become 0x2C48 (hex). 4) Restore the order of Shannon-Fano codes as originally stored within the file. Example: This example will show the encoding of a Shannon-Fano tree of size 8. Notice that the actual Shannon-Fano trees used for Imploding are either 64 or 256 entries in size. Example: 0x02, 0x42, 0x01, 0x13 The first byte indicates 3 values in this table. Decoding the bytes: 0x42 = 5 codes of 3 bits long 0x01 = 1 code of 2 bits long 0x13 = 2 codes of 4 bits long This would generate the original bit length array of: (3, 3, 3, 3, 3, 2, 4, 4) There are 8 codes in this table for the values 0 through 7. Using the algorithm to obtain the Shannon-Fano codes produces: Reversed Order Original Val Sorted Constructed Code Value Restored Length --- ------ ----------------- -------- -------- ------ 0: 2 1100000000000000 11 101 3 1: 3 1010000000000000 101 001 3 2: 3 1000000000000000 001 110 3 3: 3 0110000000000000 110 010 3 4: 3 0100000000000000 010 100 3 5: 3 0010000000000000 100 11 2 6: 4 0001000000000000 1000 1000 4 7: 4 0000000000000000 0000 0000 4 The values in the Val, Order Restored and Original Length columns now represent the Shannon-Fano encoding tree that can be used for decoding the Shannon-Fano encoded data. How to parse the variable length Shannon-Fano values from the data stream is beyond the scope of this document. (See the references listed at the end of this document for more information.) However, traditional decoding schemes used for Huffman variable length decoding, such as the Greenlaw algorithm, can be successfully applied. 5.3.9 The compressed data stream begins immediately after the compressed Shannon-Fano data. The compressed data stream can be interpreted as follows: loop until done read 1 bit from input stream. if this bit is non-zero then (encoded data is literal data) if Literal Shannon-Fano tree is present read and decode character using Literal Shannon-Fano tree. otherwise read 8 bits from input stream. copy character to the output stream. otherwise (encoded data is sliding dictionary match) if 8K dictionary size read 7 bits for offset Distance (lower 7 bits of offset). otherwise read 6 bits for offset Distance (lower 6 bits of offset). using the Distance Shannon-Fano tree, read and decode the upper 6 bits of the Distance value. using the Length Shannon-Fano tree, read and decode the Length value. Length <- Length + Minimum Match Length if Length = 63 + Minimum Match Length read 8 bits from the input stream, add this value to Length. move backwards Distance+1 bytes in the output stream, and copy Length characters from this position to the output stream. (if this position is before the start of the output stream, then assume that all the data before the start of the output stream is filled with zeros). end loop 5.4 Tokenizing - Method 7 ------------------------- 5.4.1 This method is not used by PKZIP. 5.5 Deflating - Method 8 ------------------------ 5.5.1 The Deflate algorithm is similar to the Implode algorithm using a sliding dictionary of up to 32K with secondary compression from Huffman/Shannon-Fano codes. 5.5.2 The compressed data is stored in blocks with a header describing the block and the Huffman codes used in the data block. The header format is as follows: Bit 0: Last Block bit This bit is set to 1 if this is the last compressed block in the data. Bits 1-2: Block type 00 (0) - Block is stored - All stored data is byte aligned. Skip bits until next byte, then next word = block length, followed by the ones compliment of the block length word. Remaining data in block is the stored data. 01 (1) - Use fixed Huffman codes for literal and distance codes. Lit Code Bits Dist Code Bits --------- ---- --------- ---- 0 - 143 8 0 - 31 5 144 - 255 9 256 - 279 7 280 - 287 8 Literal codes 286-287 and distance codes 30-31 are never used but participate in the huffman construction. 10 (2) - Dynamic Huffman codes. (See expanding Huffman codes) 11 (3) - Reserved - Flag a "Error in compressed data" if seen. 5.5.3 Expanding Huffman Codes If the data block is stored with dynamic Huffman codes, the Huffman codes are sent in the following compressed format: 5 Bits: # of Literal codes sent - 256 (256 - 286) All other codes are never sent. 5 Bits: # of Dist codes - 1 (1 - 32) 4 Bits: # of Bit Length codes - 3 (3 - 19) The Huffman codes are sent as bit lengths and the codes are built as described in the implode algorithm. The bit lengths themselves are compressed with Huffman codes. There are 19 bit length codes: 0 - 15: Represent bit lengths of 0 - 15 16: Copy the previous bit length 3 - 6 times. The next 2 bits indicate repeat length (0 = 3, ... ,3 = 6) Example: Codes 8, 16 (+2 bits 11), 16 (+2 bits 10) will expand to 12 bit lengths of 8 (1 + 6 + 5) 17: Repeat a bit length of 0 for 3 - 10 times. (3 bits of length) 18: Repeat a bit length of 0 for 11 - 138 times (7 bits of length) The lengths of the bit length codes are sent packed 3 bits per value (0 - 7) in the following order: 16, 17, 18, 0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15 The Huffman codes should be built as described in the Implode algorithm except codes are assigned starting at the shortest bit length, i.e. the shortest code should be all 0's rather than all 1's. Also, codes with a bit length of zero do not participate in the tree construction. The codes are then used to decode the bit lengths for the literal and distance tables. The bit lengths for the literal tables are sent first with the number of entries sent described by the 5 bits sent earlier. There are up to 286 literal characters; the first 256 represent the respective 8 bit character, code 256 represents the End-Of-Block code, the remaining 29 codes represent copy lengths of 3 through 258. There are up to 30 distance codes representing distances from 1 through 32k as described below. Length Codes ------------ Extra Extra Extra Extra Code Bits Length Code Bits Lengths Code Bits Lengths Code Bits Length(s) ---- ---- ------ ---- ---- ------- ---- ---- ------- ---- ---- --------- 257 0 3 265 1 11,12 273 3 35-42 281 5 131-162 258 0 4 266 1 13,14 274 3 43-50 282 5 163-194 259 0 5 267 1 15,16 275 3 51-58 283 5 195-226 260 0 6 268 1 17,18 276 3 59-66 284 5 227-257 261 0 7 269 2 19-22 277 4 67-82 285 0 258 262 0 8 270 2 23-26 278 4 83-98 263 0 9 271 2 27-30 279 4 99-114 264 0 10 272 2 31-34 280 4 115-130 Distance Codes -------------- Extra Extra Extra Extra Code Bits Dist Code Bits Dist Code Bits Distance Code Bits Distance ---- ---- ---- ---- ---- ------ ---- ---- -------- ---- ---- -------- 0 0 1 8 3 17-24 16 7 257-384 24 11 4097-6144 1 0 2 9 3 25-32 17 7 385-512 25 11 6145-8192 2 0 3 10 4 33-48 18 8 513-768 26 12 8193-12288 3 0 4 11 4 49-64 19 8 769-1024 27 12 12289-16384 4 1 5,6 12 5 65-96 20 9 1025-1536 28 13 16385-24576 5 1 7,8 13 5 97-128 21 9 1537-2048 29 13 24577-32768 6 2 9-12 14 6 129-192 22 10 2049-3072 7 2 13-16 15 6 193-256 23 10 3073-4096 5.5.4 The compressed data stream begins immediately after the compressed header data. The compressed data stream can be interpreted as follows: do read header from input stream. if stored block skip bits until byte aligned read count and 1's compliment of count copy count bytes data block otherwise loop until end of block code sent decode literal character from input stream if literal < 256 copy character to the output stream otherwise if literal = end of block break from loop otherwise decode distance from input stream move backwards distance bytes in the output stream, and copy length characters from this position to the output stream. end loop while not last block if data descriptor exists skip bits until byte aligned read crc and sizes endif 5.6 Enhanced Deflating - Method 9 --------------------------------- 5.6.1 The Enhanced Deflating algorithm is similar to Deflate but uses a sliding dictionary of up to 64K. Deflate64(tm) is supported by the Deflate extractor. 5.7 BZIP2 - Method 12 --------------------- 5.7.1 BZIP2 is an open-source data compression algorithm developed by Julian Seward. Information and source code for this algorithm can be found on the internet. 5.8 LZMA - Method 14 --------------------- 5.8.1 LZMA is a block-oriented, general purpose data compression algorithm developed and maintained by Igor Pavlov. It is a derivative of LZ77 that utilizes Markov chains and a range coder. Information and source code for this algorithm can be found on the internet. Consult with the author of this algorithm for information on terms or restrictions on use. Support for LZMA within the ZIP format is defined as follows: 5.8.2 The Compression method field within the ZIP Local and Central Header records will be set to the value 14 to indicate data was compressed using LZMA. 5.8.3 The Version needed to extract field within the ZIP Local and Central Header records will be set to 6.3 to indicate the minimum ZIP format version supporting this feature. 5.8.4 File data compressed using the LZMA algorithm must be placed immediately following the Local Header for the file. If a standard ZIP encryption header is required, it will follow the Local Header and will precede the LZMA compressed file data segment. The location of LZMA compressed data segment within the ZIP format will be as shown: [local header file 1] [encryption header file 1] [LZMA compressed data segment for file 1] [data descriptor 1] [local header file 2] 5.8.5 The encryption header and data descriptor records may be conditionally present. The LZMA Compressed Data Segment will consist of an LZMA Properties Header followed by the LZMA Compressed Data as shown: [LZMA properties header for file 1] [LZMA compressed data for file 1] 5.8.6 The LZMA Compressed Data will be stored as provided by the LZMA compression library. Compressed size, uncompressed size and other file characteristics about the file being compressed must be stored in standard ZIP storage format. 5.8.7 The LZMA Properties Header will store specific data required to decompress the LZMA compressed Data. This data is set by the LZMA compression engine using the function WriteCoderProperties() as documented within the LZMA SDK. 5.8.8 Storage fields for the property information within the LZMA Properties Header are as follows: LZMA Version Information 2 bytes LZMA Properties Size 2 bytes LZMA Properties Data variable, defined by "LZMA Properties Size" 5.8.8.1 LZMA Version Information - this field identifies which version of the LZMA SDK was used to compress a file. The first byte will store the major version number of the LZMA SDK and the second byte will store the minor number. 5.8.8.2 LZMA Properties Size - this field defines the size of the remaining property data. Typically this size should be determined by the version of the SDK. This size field is included as a convenience and to help avoid any ambiguity should it arise in the future due to changes in this compression algorithm. 5.8.8.3 LZMA Property Data - this variable sized field records the required values for the decompressor as defined by the LZMA SDK. The data stored in this field should be obtained using the WriteCoderProperties() in the version of the SDK defined by the "LZMA Version Information" field. 5.8.8.4 The layout of the "LZMA Properties Data" field is a function of the LZMA compression algorithm. It is possible that this layout may be changed by the author over time. The data layout in version 4.3 of the LZMA SDK defines a 5 byte array that uses 4 bytes to store the dictionary size in little-endian order. This is preceded by a single packed byte as the first element of the array that contains the following fields: PosStateBits LiteralPosStateBits LiteralContextBits Refer to the LZMA documentation for a more detailed explanation of these fields. 5.8.9 Data compressed with method 14, LZMA, may include an end-of-stream (EOS) marker ending the compressed data stream. This marker is not required, but its use is highly recommended to facilitate processing and implementers should include the EOS marker whenever possible. When the EOS marker is used, general purpose bit 1 must be set. If general purpose bit 1 is not set, the EOS marker is not present. 5.9 WavPack - Method 97 ----------------------- 5.9.1 Information describing the use of compression method 97 is provided by WinZIP International, LLC. This method relies on the open source WavPack audio compression utility developed by David Bryant. Information on WavPack is available at www.wavpack.com. Please consult with the author of this algorithm for information on terms and restrictions on use. 5.9.2 WavPack data for a file begins immediately after the end of the local header data. This data is the output from WavPack compression routines. Within the ZIP file, the use of WavPack compression is indicated by setting the compression method field to a value of 97 in both the local header and the central directory header. The Version needed to extract and version made by fields use the same values as are used for data compressed using the Deflate algorithm. 5.9.3 An implementation note for storing digital sample data when using WavPack compression within ZIP files is that all of the bytes of the sample data should be compressed. This includes any unused bits up to the byte boundary. An example is a 2 byte sample that uses only 12 bits for the sample data with 4 unused bits. If only 12 bits are passed as the sample size to the WavPack routines, the 4 unused bits will be set to 0 on extraction regardless of their original state. To avoid this, the full 16 bits of the sample data size should be provided. 5.10 PPMd - Method 98 --------------------- 5.10.1 PPMd is a data compression algorithm developed by Dmitry Shkarin which includes a carryless rangecoder developed by Dmitry Subbotin. This algorithm is based on predictive phrase matching on multiple order contexts. Information and source code for this algorithm can be found on the internet. Consult with the author of this algorithm for information on terms or restrictions on use. 5.10.2 Support for PPMd within the ZIP format currently is provided only for version I, revision 1 of the algorithm. Storage requirements for using this algorithm are as follows: 5.10.3 Parameters needed to control the algorithm are stored in the two bytes immediately preceding the compressed data. These bytes are used to store the following fields: Model order - sets the maximum model order, default is 8, possible values are from 2 to 16 inclusive Sub-allocator size - sets the size of sub-allocator in MB, default is 50, possible values are from 1MB to 256MB inclusive Model restoration method - sets the method used to restart context model at memory insufficiency, values are: 0 - restarts model from scratch - default 1 - cut off model - decreases performance by as much as 2x 2 - freeze context tree - not recommended 5.10.4 An example for packing these fields into the 2 byte storage field is illustrated below. These values are stored in Intel low-byte/high-byte order. wPPMd = (Model order - 1) + ((Sub-allocator size - 1) << 4) + (Model restoration method << 12) 6.0 Traditional PKWARE Encryption ---------------------------------- 6.0.1 The following information discusses the decryption steps required to support traditional PKWARE encryption. This form of encryption is considered weak by today's standards and its use is recommended only for situations with low security needs or for compatibility with older .ZIP applications. 6.1 Traditional PKWARE Decryption --------------------------------- 6.1.1 PKWARE is grateful to Mr. Roger Schlafly for his expert contribution towards the development of PKWARE's traditional encryption. 6.1.2 PKZIP encrypts the compressed data stream. Encrypted files must be decrypted before they can be extracted to their original form. 6.1.3 Each encrypted file has an extra 12 bytes stored at the start of the data area defining the encryption header for that file. The encryption header is originally set to random values, and then itself encrypted, using three, 32-bit keys. The key values are initialized using the supplied encryption password. After each byte is encrypted, the keys are then updated using pseudo-random number generation techniques in combination with the same CRC-32 algorithm used in PKZIP and described elsewhere in this document. 6.1.4 The following are the basic steps required to decrypt a file: 1) Initialize the three 32-bit keys with the password. 2) Read and decrypt the 12-byte encryption header, further initializing the encryption keys. 3) Read and decrypt the compressed data stream using the encryption keys. 6.1.5 Initializing the encryption keys Key(0) <- 305419896 Key(1) <- 591751049 Key(2) <- 878082192 loop for i <- 0 to length(password)-1 update_keys(password(i)) end loop Where update_keys() is defined as: update_keys(char): Key(0) <- crc32(key(0),char) Key(1) <- Key(1) + (Key(0) & 000000ffH) Key(1) <- Key(1) * 134775813 + 1 Key(2) <- crc32(key(2),key(1) >> 24) end update_keys Where crc32(old_crc,char) is a routine that given a CRC value and a character, returns an updated CRC value after applying the CRC-32 algorithm described elsewhere in this document. 6.1.6 Decrypting the encryption header The purpose of this step is to further initialize the encryption keys, based on random data, to render a plaintext attack on the data ineffective. Read the 12-byte encryption header into Buffer, in locations Buffer(0) through Buffer(11). loop for i <- 0 to 11 C <- buffer(i) ^ decrypt_byte() update_keys(C) buffer(i) <- C end loop Where decrypt_byte() is defined as: unsigned char decrypt_byte() local unsigned short temp temp <- Key(2) | 2 decrypt_byte <- (temp * (temp ^ 1)) >> 8 end decrypt_byte After the header is decrypted, the last 1 or 2 bytes in Buffer should be the high-order word/byte of the CRC for the file being decrypted, stored in Intel low-byte/high-byte order. Versions of PKZIP prior to 2.0 used a 2 byte CRC check; a 1 byte CRC check is used on versions after 2.0. This can be used to test if the password supplied is correct or not. 6.1.7 Decrypting the compressed data stream The compressed data stream can be decrypted as follows: loop until done read a character into C Temp <- C ^ decrypt_byte() update_keys(temp) output Temp end loop 7.0 Strong Encryption Specification ----------------------------------- 7.0.1 Portions of the Strong Encryption technology defined in this specification are covered under patents and pending patent applications. Refer to the section in this document entitled "Incorporating PKWARE Proprietary Technology into Your Product" for more information. 7.1 Strong Encryption Overview ------------------------------ 7.1.1 Version 5.x of this specification introduced support for strong encryption algorithms. These algorithms can be used with either a password or an X.509v3 digital certificate to encrypt each file. This format specification supports either password or certificate based encryption to meet the security needs of today, to enable interoperability between users within both PKI and non-PKI environments, and to ensure interoperability between different computing platforms that are running a ZIP program. 7.1.2 Password based encryption is the most common form of encryption people are familiar with. However, inherent weaknesses with passwords (e.g. susceptibility to dictionary/brute force attack) as well as password management and support issues make certificate based encryption a more secure and scalable option. Industry efforts and support are defining and moving towards more advanced security solutions built around X.509v3 digital certificates and Public Key Infrastructures(PKI) because of the greater scalability, administrative options, and more robust security over traditional password based encryption. 7.1.3 Most standard encryption algorithms are supported with this specification. Reference implementations for many of these algorithms are available from either commercial or open source distributors. Readily available cryptographic toolkits make implementation of the encryption features straight-forward. This document is not intended to provide a treatise on data encryption principles or theory. Its purpose is to document the data structures required for implementing interoperable data encryption within the .ZIP format. It is strongly recommended that you have a good understanding of data encryption before reading further. 7.1.4 The algorithms introduced in Version 5.0 of this specification include: RC2 40 bit, 64 bit, and 128 bit RC4 40 bit, 64 bit, and 128 bit DES 3DES 112 bit and 168 bit Version 5.1 adds support for the following: AES 128 bit, 192 bit, and 256 bit 7.1.5 Version 6.1 introduces encryption data changes to support interoperability with Smartcard and USB Token certificate storage methods which do not support the OAEP strengthening standard. 7.1.6 Version 6.2 introduces support for encrypting metadata by compressing and encrypting the central directory data structure to reduce information leakage. Information leakage can occur in legacy ZIP applications through exposure of information about a file even though that file is stored encrypted. The information exposed consists of file characteristics stored within the records and fields defined by this specification. This includes data such as a file's name, its original size, timestamp and CRC32 value. 7.1.7 Version 6.3 introduces support for encrypting data using the Blowfish and Twofish algorithms. These are symmetric block ciphers developed by Bruce Schneier. Blowfish supports using a variable length key from 32 to 448 bits. Block size is 64 bits. Implementations should use 16 rounds and the only mode supported within ZIP files is CBC. Twofish supports key sizes 128, 192 and 256 bits. Block size is 128 bits. Implementations should use 16 rounds and the only mode supported within ZIP files is CBC. Information and source code for both Blowfish and Twofish algorithms can be found on the internet. Consult with the author of these algorithms for information on terms or restrictions on use. 7.1.8 Central Directory Encryption provides greater protection against information leakage by encrypting the Central Directory structure and by masking key values that are replicated in the unencrypted Local Header. ZIP compatible programs that cannot interpret an encrypted Central Directory structure cannot rely on the data in the corresponding Local Header for decompression information. 7.1.9 Extra Field records that may contain information about a file that should not be exposed should not be stored in the Local Header and should only be written to the Central Directory where they can be encrypted. This design currently does not support streaming. Information in the End of Central Directory record, the Zip64 End of Central Directory Locator, and the Zip64 End of Central Directory records are not encrypted. Access to view data on files within a ZIP file with an encrypted Central Directory requires the appropriate password or private key for decryption prior to viewing any files, or any information about the files, in the archive. 7.1.10 Older ZIP compatible programs not familiar with the Central Directory Encryption feature will no longer be able to recognize the Central Directory and may assume the ZIP file is corrupt. Programs that attempt streaming access using Local Headers will see invalid information for each file. Central Directory Encryption need not be used for every ZIP file. Its use is recommended for greater security. ZIP files not using Central Directory Encryption should operate as in the past. 7.1.11 This strong encryption feature specification is intended to provide for scalable, cross-platform encryption needs ranging from simple password encryption to authenticated public/private key encryption. 7.1.12 Encryption provides data confidentiality and privacy. It is recommended that you combine X.509 digital signing with encryption to add authentication and non-repudiation. 7.2 Single Password Symmetric Encryption Method ----------------------------------------------- 7.2.1 The Single Password Symmetric Encryption Method using strong encryption algorithms operates similarly to the traditional PKWARE encryption defined in this format. Additional data structures are added to support the processing needs of the strong algorithms. The Strong Encryption data structures are: 7.2.2 General Purpose Bits - Bits 0 and 6 of the General Purpose bit flag in both local and central header records. Both bits set indicates strong encryption. Bit 13, when set indicates the Central Directory is encrypted and that selected fields in the Local Header are masked to hide their actual value. 7.2.3 Extra Field 0x0017 in central header only. Fields to consider in this record are: 7.2.3.1 Format - the data format identifier for this record. The only value allowed at this time is the integer value 2. 7.2.3.2 AlgId - integer identifier of the encryption algorithm from the following range 0x6601 - DES 0x6602 - RC2 (version needed to extract < 5.2) 0x6603 - 3DES 168 0x6609 - 3DES 112 0x660E - AES 128 0x660F - AES 192 0x6610 - AES 256 0x6702 - RC2 (version needed to extract >= 5.2) 0x6720 - Blowfish 0x6721 - Twofish 0x6801 - RC4 0xFFFF - Unknown algorithm 7.2.3.3 Bitlen - Explicit bit length of key 32 - 448 bits 7.2.3.4 Flags - Processing flags needed for decryption 0x0001 - Password is required to decrypt 0x0002 - Certificates only 0x0003 - Password or certificate required to decrypt Values > 0x0003 reserved for certificate processing 7.2.4 Decryption header record preceding compressed file data. -Decryption Header: Value Size Description ----- ---- ----------- IVSize 2 bytes Size of initialization vector (IV) IVData IVSize Initialization vector for this file Size 4 bytes Size of remaining decryption header data Format 2 bytes Format definition for this record AlgID 2 bytes Encryption algorithm identifier Bitlen 2 bytes Bit length of encryption key Flags 2 bytes Processing flags ErdSize 2 bytes Size of Encrypted Random Data ErdData ErdSize Encrypted Random Data Reserved1 4 bytes Reserved certificate processing data Reserved2 (var) Reserved for certificate processing data VSize 2 bytes Size of password validation data VData VSize-4 Password validation data VCRC32 4 bytes Standard ZIP CRC32 of password validation data 7.2.4.1 IVData - The size of the IV should match the algorithm block size. The IVData can be completely random data. If the size of the randomly generated data does not match the block size it should be complemented with zero's or truncated as necessary. If IVSize is 0,then IV = CRC32 + Uncompressed File Size (as a 64 bit little-endian, unsigned integer value). 7.2.4.2 Format - the data format identifier for this record. The only value allowed at this time is the integer value 3. 7.2.4.3 AlgId - integer identifier of the encryption algorithm from the following range 0x6601 - DES 0x6602 - RC2 (version needed to extract < 5.2) 0x6603 - 3DES 168 0x6609 - 3DES 112 0x660E - AES 128 0x660F - AES 192 0x6610 - AES 256 0x6702 - RC2 (version needed to extract >= 5.2) 0x6720 - Blowfish 0x6721 - Twofish 0x6801 - RC4 0xFFFF - Unknown algorithm 7.2.4.4 Bitlen - Explicit bit length of key 32 - 448 bits 7.2.4.5 Flags - Processing flags needed for decryption 0x0001 - Password is required to decrypt 0x0002 - Certificates only 0x0003 - Password or certificate required to decrypt Values > 0x0003 reserved for certificate processing 7.2.4.6 ErdData - Encrypted random data is used to store random data that is used to generate a file session key for encrypting each file. SHA1 is used to calculate hash data used to derive keys. File session keys are derived from a master session key generated from the user-supplied password. If the Flags field in the decryption header contains the value 0x4000, then the ErdData field must be decrypted using 3DES. If the value 0x4000 is not set, then the ErdData field must be decrypted using AlgId. 7.2.4.7 Reserved1 - Reserved for certificate processing, if value is zero, then Reserved2 data is absent. See the explanation under the Certificate Processing Method for details on this data structure. 7.2.4.8 Reserved2 - If present, the size of the Reserved2 data structure is located by skipping the first 4 bytes of this field and using the next 2 bytes as the remaining size. See the explanation under the Certificate Processing Method for details on this data structure. 7.2.4.9 VSize - This size value will always include the 4 bytes of the VCRC32 data and will be greater than 4 bytes. 7.2.4.10 VData - Random data for password validation. This data is VSize in length and VSize must be a multiple of the encryption block size. VCRC32 is a checksum value of VData. VData and VCRC32 are stored encrypted and start the stream of encrypted data for a file. 7.2.5 Useful Tips 7.2.5.1 Strong Encryption is always applied to a file after compression. The block oriented algorithms all operate in Cypher Block Chaining (CBC) mode. The block size used for AES encryption is 16. All other block algorithms use a block size of 8. Two IDs are defined for RC2 to account for a discrepancy found in the implementation of the RC2 algorithm in the cryptographic library on Windows XP SP1 and all earlier versions of Windows. It is recommended that zero length files not be encrypted, however programs should be prepared to extract them if they are found within a ZIP file. 7.2.5.2 A pseudo-code representation of the encryption process is as follows: Password = GetUserPassword() MasterSessionKey = DeriveKey(SHA1(Password)) RD = CryptographicStrengthRandomData() For Each File IV = CryptographicStrengthRandomData() VData = CryptographicStrengthRandomData() VCRC32 = CRC32(VData) FileSessionKey = DeriveKey(SHA1(IV + RD) ErdData = Encrypt(RD,MasterSessionKey,IV) Encrypt(VData + VCRC32 + FileData, FileSessionKey,IV) Done 7.2.5.3 The function names and parameter requirements will depend on the choice of the cryptographic toolkit selected. Almost any toolkit supporting the reference implementations for each algorithm can be used. The RSA BSAFE(r), OpenSSL, and Microsoft CryptoAPI libraries are all known to work well. 7.3 Single Password - Central Directory Encryption -------------------------------------------------- 7.3.1 Central Directory Encryption is achieved within the .ZIP format by encrypting the Central Directory structure. This encapsulates the metadata most often used for processing .ZIP files. Additional metadata is stored for redundancy in the Local Header for each file. The process of concealing metadata by encrypting the Central Directory does not protect the data within the Local Header. To avoid information leakage from the exposed metadata in the Local Header, the fields containing information about a file are masked. 7.3.2 Local Header Masking replaces the true content of the fields for a file in the Local Header with false information. When masked, the Local Header is not suitable for streaming access and the options for data recovery of damaged archives is reduced. Extra Data fields that may contain confidential data should not be stored within the Local Header. The value set into the Version needed to extract field should be the correct value needed to extract the file without regard to Central Directory Encryption. The fields within the Local Header targeted for masking when the Central Directory is encrypted are: Field Name Mask Value ------------------ --------------------------- compression method 0 last mod file time 0 last mod file date 0 crc-32 0 compressed size 0 uncompressed size 0 file name (variable size) Base 16 value from the range 1 - 0xFFFFFFFFFFFFFFFF represented as a string whose size will be set into the file name length field The Base 16 value assigned as a masked file name is simply a sequentially incremented value for each file starting with 1 for the first file. Modifications to a ZIP file may cause different values to be stored for each file. For compatibility, the file name field in the Local Header should never be left blank. As of Version 6.2 of this specification, the Compression Method and Compressed Size fields are not yet masked. Fields having a value of 0xFFFF or 0xFFFFFFFF for the ZIP64 format should not be masked. 7.3.3 Encrypting the Central Directory Encryption of the Central Directory does not include encryption of the Central Directory Signature data, the Zip64 End of Central Directory record, the Zip64 End of Central Directory Locator, or the End of Central Directory record. The ZIP file comment data is never encrypted. Before encrypting the Central Directory, it may optionally be compressed. Compression is not required, but for storage efficiency it is assumed this structure will be compressed before encrypting. Similarly, this specification supports compressing the Central Directory without requiring that it also be encrypted. Early implementations of this feature will assume the encryption method applied to files matches the encryption applied to the Central Directory. Encryption of the Central Directory is done in a manner similar to that of file encryption. The encrypted data is preceded by a decryption header. The decryption header is known as the Archive Decryption Header. The fields of this record are identical to the decryption header preceding each encrypted file. The location of the Archive Decryption Header is determined by the value in the Start of the Central Directory field in the Zip64 End of Central Directory record. When the Central Directory is encrypted, the Zip64 End of Central Directory record will always be present. The layout of the Zip64 End of Central Directory record for all versions starting with 6.2 of this specification will follow the Version 2 format. The Version 2 format is as follows: The leading fixed size fields within the Version 1 format for this record remain unchanged. The record signature for both Version 1 and Version 2 will be 0x06064b50. Immediately following the last byte of the field known as the Offset of Start of Central Directory With Respect to the Starting Disk Number will begin the new fields defining Version 2 of this record. 7.3.4 New fields for Version 2 Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- Compression Method 2 bytes Method used to compress the Central Directory Compressed Size 8 bytes Size of the compressed data Original Size 8 bytes Original uncompressed size AlgId 2 bytes Encryption algorithm ID BitLen 2 bytes Encryption key length Flags 2 bytes Encryption flags HashID 2 bytes Hash algorithm identifier Hash Length 2 bytes Length of hash data Hash Data (variable) Hash data The Compression Method accepts the same range of values as the corresponding field in the Central Header. The Compressed Size and Original Size values will not include the data of the Central Directory Signature which is compressed or encrypted. The AlgId, BitLen, and Flags fields accept the same range of values the corresponding fields within the 0x0017 record. Hash ID identifies the algorithm used to hash the Central Directory data. This data does not have to be hashed, in which case the values for both the HashID and Hash Length will be 0. Possible values for HashID are: Value Algorithm ------ --------- 0x0000 none 0x0001 CRC32 0x8003 MD5 0x8004 SHA1 0x8007 RIPEMD160 0x800C SHA256 0x800D SHA384 0x800E SHA512 7.3.5 When the Central Directory data is signed, the same hash algorithm used to hash the Central Directory for signing should be used. This is recommended for processing efficiency, however, it is permissible for any of the above algorithms to be used independent of the signing process. The Hash Data will contain the hash data for the Central Directory. The length of this data will vary depending on the algorithm used. The Version Needed to Extract should be set to 62. The value for the Total Number of Entries on the Current Disk will be 0. These records will no longer support random access when encrypting the Central Directory. 7.3.6 When the Central Directory is compressed and/or encrypted, the End of Central Directory record will store the value 0xFFFFFFFF as the value for the Total Number of Entries in the Central Directory. The value stored in the Total Number of Entries in the Central Directory on this Disk field will be 0. The actual values will be stored in the equivalent fields of the Zip64 End of Central Directory record. 7.3.7 Decrypting and decompressing the Central Directory is accomplished in the same manner as decrypting and decompressing a file. 7.4 Certificate Processing Method --------------------------------- The Certificate Processing Method for ZIP file encryption defines the following additional data fields: 7.4.1 Certificate Flag Values Additional processing flags that can be present in the Flags field of both the 0x0017 field of the central directory Extra Field and the Decryption header record preceding compressed file data are: 0x0007 - reserved for future use 0x000F - reserved for future use 0x0100 - Indicates non-OAEP key wrapping was used. If this this field is set, the version needed to extract must be at least 61. This means OAEP key wrapping is not used when generating a Master Session Key using ErdData. 0x4000 - ErdData must be decrypted using 3DES-168, otherwise use the same algorithm used for encrypting the file contents. 0x8000 - reserved for future use 7.4.2 CertData - Extra Field 0x0017 record certificate data structure The data structure used to store certificate data within the section of the Extra Field defined by the CertData field of the 0x0017 record are as shown: Value Size Description ----- ---- ----------- RCount 4 bytes Number of recipients. HashAlg 2 bytes Hash algorithm identifier HSize 2 bytes Hash size SRList (var) Simple list of recipients hashed public keys RCount This defines the number intended recipients whose public keys were used for encryption. This identifies the number of elements in the SRList. HashAlg This defines the hash algorithm used to calculate the public key hash of each public key used for encryption. This field currently supports only the following value for SHA-1 0x8004 - SHA1 HSize This defines the size of a hashed public key. SRList This is a variable length list of the hashed public keys for each intended recipient. Each element in this list is HSize. The total size of SRList is determined using RCount * HSize. 7.4.3 Reserved1 - Certificate Decryption Header Reserved1 Data Value Size Description ----- ---- ----------- RCount 4 bytes Number of recipients. RCount This defines the number intended recipients whose public keys were used for encryption. This defines the number of elements in the REList field defined below. 7.4.4 Reserved2 - Certificate Decryption Header Reserved2 Data Structures Value Size Description ----- ---- ----------- HashAlg 2 bytes Hash algorithm identifier HSize 2 bytes Hash size REList (var) List of recipient data elements HashAlg This defines the hash algorithm used to calculate the public key hash of each public key used for encryption. This field currently supports only the following value for SHA-1 0x8004 - SHA1 HSize This defines the size of a hashed public key defined in REHData. REList This is a variable length of list of recipient data. Each element in this list consists of a Recipient Element data structure as follows: Recipient Element (REList) Data Structure: Value Size Description ----- ---- ----------- RESize 2 bytes Size of REHData + REKData REHData HSize Hash of recipients public key REKData (var) Simple key blob RESize This defines the size of an individual REList element. This value is the combined size of the REHData field + REKData field. REHData is defined by HSize. REKData is variable and can be calculated for each REList element using RESize and HSize. REHData Hashed public key for this recipient. REKData Simple Key Blob. The format of this data structure is identical to that defined in the Microsoft CryptoAPI and generated using the CryptExportKey() function. The version of the Simple Key Blob supported at this time is 0x02 as defined by Microsoft. 7.5 Certificate Processing - Central Directory Encryption --------------------------------------------------------- 7.5.1 Central Directory Encryption using Digital Certificates will operate in a manner similar to that of Single Password Central Directory Encryption. This record will only be present when there is data to place into it. Currently, data is placed into this record when digital certificates are used for either encrypting or signing the files within a ZIP file. When only password encryption is used with no certificate encryption or digital signing, this record is not currently needed. When present, this record will appear before the start of the actual Central Directory data structure and will be located immediately after the Archive Decryption Header if the Central Directory is encrypted. 7.5.2 The Archive Extra Data record will be used to store the following information. Additional data may be added in future versions. Extra Data Fields: 0x0014 - PKCS#7 Store for X.509 Certificates 0x0016 - X.509 Certificate ID and Signature for central directory 0x0019 - PKCS#7 Encryption Recipient Certificate List The 0x0014 and 0x0016 Extra Data records that otherwise would be located in the first record of the Central Directory for digital certificate processing. When encrypting or compressing the Central Directory, the 0x0014 and 0x0016 records must be located in the Archive Extra Data record and they should not remain in the first Central Directory record. The Archive Extra Data record will also be used to store the 0x0019 data. 7.5.3 When present, the size of the Archive Extra Data record will be included in the size of the Central Directory. The data of the Archive Extra Data record will also be compressed and encrypted along with the Central Directory data structure. 7.6 Certificate Processing Differences -------------------------------------- 7.6.1 The Certificate Processing Method of encryption differs from the Single Password Symmetric Encryption Method as follows. Instead of using a user-defined password to generate a master session key, cryptographically random data is used. The key material is then wrapped using standard key-wrapping techniques. This key material is wrapped using the public key of each recipient that will need to decrypt the file using their corresponding private key. 7.6.2 This specification currently assumes digital certificates will follow the X.509 V3 format for 1024 bit and higher RSA format digital certificates. Implementation of this Certificate Processing Method requires supporting logic for key access and management. This logic is outside the scope of this specification. 7.7 OAEP Processing with Certificate-based Encryption ----------------------------------------------------- 7.7.1 OAEP stands for Optimal Asymmetric Encryption Padding. It is a strengthening technique used for small encoded items such as decryption keys. This is commonly applied in cryptographic key-wrapping techniques and is supported by PKCS #1. Versions 5.0 and 6.0 of this specification were designed to support OAEP key-wrapping for certificate-based decryption keys for additional security. 7.7.2 Support for private keys stored on Smartcards or Tokens introduced a conflict with this OAEP logic. Most card and token products do not support the additional strengthening applied to OAEP key-wrapped data. In order to resolve this conflict, versions 6.1 and above of this specification will no longer support OAEP when encrypting using digital certificates. 7.7.3 Versions of PKZIP available during initial development of the certificate processing method set a value of 61 into the version needed to extract field for a file. This indicates that non-OAEP key wrapping is used. This affects certificate encryption only, and password encryption functions should not be affected by this value. This means values of 61 may be found on files encrypted with certificates only, or on files encrypted with both password encryption and certificate encryption. Files encrypted with both methods can safely be decrypted using the password methods documented. 8.0 Splitting and Spanning ZIP files ------------------------------------- 8.1 Spanned ZIP files 8.1.1 Spanning is the process of segmenting a ZIP file across multiple removable media. This support has typically only been provided for DOS formatted floppy diskettes. 8.2 Split ZIP files 8.2.1 File splitting is a newer derivation of spanning. Splitting follows the same segmentation process as spanning, however, it does not require writing each segment to a unique removable medium and instead supports placing all pieces onto local or non-removable locations such as file systems, local drives, folders, etc. 8.3 File Naming Differences 8.3.1 A key difference between spanned and split ZIP files is that all pieces of a spanned ZIP file have the same name. Since each piece is written to a separate volume, no name collisions occur and each segment can reuse the original .ZIP file name given to the archive. 8.3.2 Sequence ordering for DOS spanned archives uses the DOS volume label to determine segment numbers. Volume labels for each segment are written using the form PKBACK#xxx, where xxx is the segment number written as a decimal value from 001 - nnn. 8.3.3 Split ZIP files are typically written to the same location and are subject to name collisions if the spanned name format is used since each segment will reside on the same drive. To avoid name collisions, split archives are named as follows. Segment 1 = filename.z01 Segment n-1 = filename.z(n-1) Segment n = filename.zip 8.3.4 The .ZIP extension is used on the last segment to support quickly reading the central directory. The segment number n should be a decimal value. 8.4 Spanned Self-extracting ZIP Files 8.4.1 Spanned ZIP files may be PKSFX Self-extracting ZIP files. PKSFX files may also be split, however, in this case the first segment must be named filename.exe. The first segment of a split PKSFX archive must be large enough to include the entire executable program. 8.5 Capacities and Markers 8.5.1 Capacities for split archives are as follows: Maximum number of segments = 4,294,967,295 - 1 Maximum .ZIP segment size = 4,294,967,295 bytes Minimum segment size = 64K Maximum PKSFX segment size = 2,147,483,647 bytes 8.5.2 Segment sizes may be different however by convention, all segment sizes should be the same with the exception of the last, which may be smaller. Local and central directory header records must never be split across a segment boundary. When writing a header record, if the number of bytes remaining within a segment is less than the size of the header record, end the current segment and write the header at the start of the next segment. The central directory may span segment boundaries, but no single record in the central directory should be split across segments. 8.5.3 Spanned/Split archives created using PKZIP for Windows (V2.50 or greater), PKZIP Command Line (V2.50 or greater), or PKZIP Explorer will include a special spanning signature as the first 4 bytes of the first segment of the archive. This signature (0x08074b50) will be followed immediately by the local header signature for the first file in the archive. 8.5.4 A special spanning marker may also appear in spanned/split archives if the spanning or splitting process starts but only requires one segment. In this case the 0x08074b50 signature will be replaced with the temporary spanning marker signature of 0x30304b50. Split archives can only be uncompressed by other versions of PKZIP that know how to create a split archive. 8.5.5 The signature value 0x08074b50 is also used by some ZIP implementations as a marker for the Data Descriptor record. Conflict in this alternate assignment can be avoided by ensuring the position of the signature within the ZIP file to determine the use for which it is intended. 9.0 Change Process ------------------ 9.1 In order for the .ZIP file format to remain a viable technology, this specification should be considered as open for periodic review and revision. Although this format was originally designed with a certain level of extensibility, not all changes in technology (present or future) were or will be necessarily considered in its design. 9.2 If your application requires new definitions to the extensible sections in this format, or if you would like to submit new data structures or new capabilities, please forward your request to zipformat@pkware.com. All submissions will be reviewed by the ZIP File Specification Committee for possible inclusion into future versions of this specification. 9.3 Periodic revisions to this specification will be published as DRAFT or as FINAL status to ensure interoperability. We encourage comments and feedback that may help improve clarity or content. 10.0 Incorporating PKWARE Proprietary Technology into Your Product ------------------------------------------------------------------ 10.1 The Use or Implementation in a product of APPNOTE technological components pertaining to either strong encryption or patching requires a separate, executed license agreement from PKWARE. Please contact PKWARE at zipformat@pkware.com or +1-414-289-9788 with regard to acquiring such a license. 10.2 Additional information regarding PKWARE proprietray technology is available at http://www.pkware.com/appnote. 11.0 Acknowledgements --------------------- In addition to the above mentioned contributors to PKZIP and PKUNZIP, PKWARE would like to extend special thanks to Robert Mahoney for suggesting the extension .ZIP for this software. 12.0 References --------------- Fiala, Edward R., and Greene, Daniel H., "Data compression with finite windows", Communications of the ACM, Volume 32, Number 4, April 1989, pages 490-505. Held, Gilbert, "Data Compression, Techniques and Applications, Hardware and Software Considerations", John Wiley & Sons, 1987. Huffman, D.A., "A method for the construction of minimum-redundancy codes", Proceedings of the IRE, Volume 40, Number 9, September 1952, pages 1098-1101. Nelson, Mark, "LZW Data Compression", Dr. Dobbs Journal, Volume 14, Number 10, October 1989, pages 29-37. Nelson, Mark, "The Data Compression Book", M&T Books, 1991. Storer, James A., "Data Compression, Methods and Theory", Computer Science Press, 1988 Welch, Terry, "A Technique for High-Performance Data Compression", IEEE Computer, Volume 17, Number 6, June 1984, pages 8-19. Ziv, J. and Lempel, A., "A universal algorithm for sequential data compression", Communications of the ACM, Volume 30, Number 6, June 1987, pages 520-540. Ziv, J. and Lempel, A., "Compression of individual sequences via variable-rate coding", IEEE Transactions on Information Theory, Volume 24, Number 5, September 1978, pages 530-536. APPENDIX A - AS/400 Extra Field (0x0065) Attribute Definitions -------------------------------------------------------------- A.1 Field Definition Structure: a. field length including length 2 bytes b. field code 2 bytes c. data x bytes A.2 Field Code Description 4001 Source type i.e. CLP etc 4002 The text description of the library 4003 The text description of the file 4004 The text description of the member 4005 x'F0' or 0 is PF-DTA, x'F1' or 1 is PF_SRC 4007 Database Type Code 1 byte 4008 Database file and fields definition 4009 GZIP file type 2 bytes 400B IFS code page 2 bytes 400C IFS Creation Time 4 bytes 400D IFS Access Time 4 bytes 400E IFS Modification time 4 bytes 005C Length of the records in the file 2 bytes 0068 GZIP two words 8 bytes APPENDIX B - z/OS Extra Field (0x0065) Attribute Definitions ------------------------------------------------------------ B.1 Field Definition Structure: a. field length including length 2 bytes b. field code 2 bytes c. data x bytes B.2 Field Code Description 0001 File Type 2 bytes 0002 NonVSAM Record Format 1 byte 0003 Reserved 0004 NonVSAM Block Size 2 bytes Big Endian 0005 Primary Space Allocation 3 bytes Big Endian 0006 Secondary Space Allocation 3 bytes Big Endian 0007 Space Allocation Type1 byte flag 0008 Modification Date Retired with PKZIP 5.0 + 0009 Expiration Date Retired with PKZIP 5.0 + 000A PDS Directory Block Allocation 3 bytes Big Endian binary value 000B NonVSAM Volume List variable 000C UNIT Reference Retired with PKZIP 5.0 + 000D DF/SMS Management Class 8 bytes EBCDIC Text Value 000E DF/SMS Storage Class 8 bytes EBCDIC Text Value 000F DF/SMS Data Class 8 bytes EBCDIC Text Value 0010 PDS/PDSE Member Info. 30 bytes 0011 VSAM sub-filetype 2 bytes 0012 VSAM LRECL 13 bytes EBCDIC "(num_avg num_max)" 0013 VSAM Cluster Name Retired with PKZIP 5.0 + 0014 VSAM KSDS Key Information 13 bytes EBCDIC "(num_length num_position)" 0015 VSAM Average LRECL 5 bytes EBCDIC num_value padded with blanks 0016 VSAM Maximum LRECL 5 bytes EBCDIC num_value padded with blanks 0017 VSAM KSDS Key Length 5 bytes EBCDIC num_value padded with blanks 0018 VSAM KSDS Key Position 5 bytes EBCDIC num_value padded with blanks 0019 VSAM Data Name 1-44 bytes EBCDIC text string 001A VSAM KSDS Index Name 1-44 bytes EBCDIC text string 001B VSAM Catalog Name 1-44 bytes EBCDIC text string 001C VSAM Data Space Type 9 bytes EBCDIC text string 001D VSAM Data Space Primary 9 bytes EBCDIC num_value left-justified 001E VSAM Data Space Secondary 9 bytes EBCDIC num_value left-justified 001F VSAM Data Volume List variable EBCDIC text list of 6-character Volume IDs 0020 VSAM Data Buffer Space 8 bytes EBCDIC num_value left-justified 0021 VSAM Data CISIZE 5 bytes EBCDIC num_value left-justified 0022 VSAM Erase Flag 1 byte flag 0023 VSAM Free CI % 3 bytes EBCDIC num_value left-justified 0024 VSAM Free CA % 3 bytes EBCDIC num_value left-justified 0025 VSAM Index Volume List variable EBCDIC text list of 6-character Volume IDs 0026 VSAM Ordered Flag 1 byte flag 0027 VSAM REUSE Flag 1 byte flag 0028 VSAM SPANNED Flag 1 byte flag 0029 VSAM Recovery Flag 1 byte flag 002A VSAM WRITECHK Flag 1 byte flag 002B VSAM Cluster/Data SHROPTS 3 bytes EBCDIC "n,y" 002C VSAM Index SHROPTS 3 bytes EBCDIC "n,y" 002D VSAM Index Space Type 9 bytes EBCDIC text string 002E VSAM Index Space Primary 9 bytes EBCDIC num_value left-justified 002F VSAM Index Space Secondary 9 bytes EBCDIC num_value left-justified 0030 VSAM Index CISIZE 5 bytes EBCDIC num_value left-justified 0031 VSAM Index IMBED 1 byte flag 0032 VSAM Index Ordered Flag 1 byte flag 0033 VSAM REPLICATE Flag 1 byte flag 0034 VSAM Index REUSE Flag 1 byte flag 0035 VSAM Index WRITECHK Flag 1 byte flag Retired with PKZIP 5.0 + 0036 VSAM Owner 8 bytes EBCDIC text string 0037 VSAM Index Owner 8 bytes EBCDIC text string 0038 Reserved 0039 Reserved 003A Reserved 003B Reserved 003C Reserved 003D Reserved 003E Reserved 003F Reserved 0040 Reserved 0041 Reserved 0042 Reserved 0043 Reserved 0044 Reserved 0045 Reserved 0046 Reserved 0047 Reserved 0048 Reserved 0049 Reserved 004A Reserved 004B Reserved 004C Reserved 004D Reserved 004E Reserved 004F Reserved 0050 Reserved 0051 Reserved 0052 Reserved 0053 Reserved 0054 Reserved 0055 Reserved 0056 Reserved 0057 Reserved 0058 PDS/PDSE Member TTR Info. 6 bytes Big Endian 0059 PDS 1st LMOD Text TTR 3 bytes Big Endian 005A PDS LMOD EP Rec # 4 bytes Big Endian 005B Reserved 005C Max Length of records 2 bytes Big Endian 005D PDSE Flag 1 byte flag 005E Reserved 005F Reserved 0060 Reserved 0061 Reserved 0062 Reserved 0063 Reserved 0064 Reserved 0065 Last Date Referenced 4 bytes Packed Hex "yyyymmdd" 0066 Date Created 4 bytes Packed Hex "yyyymmdd" 0068 GZIP two words 8 bytes 0071 Extended NOTE Location 12 bytes Big Endian 0072 Archive device UNIT 6 bytes EBCDIC 0073 Archive 1st Volume 6 bytes EBCDIC 0074 Archive 1st VOL File Seq# 2 bytes Binary APPENDIX C - Zip64 Extensible Data Sector Mappings --------------------------------------------------- -Z390 Extra Field: The following is the general layout of the attributes for the ZIP 64 "extra" block for extended tape operations. Note: some fields stored in Big Endian format. All text is in EBCDIC format unless otherwise specified. Value Size Description ----- ---- ----------- (Z390) 0x0065 2 bytes Tag for this "extra" block type Size 4 bytes Size for the following data block Tag 4 bytes EBCDIC "Z390" Length71 2 bytes Big Endian Subcode71 2 bytes Enote type code FMEPos 1 byte Length72 2 bytes Big Endian Subcode72 2 bytes Unit type code Unit 1 byte Unit Length73 2 bytes Big Endian Subcode73 2 bytes Volume1 type code FirstVol 1 byte Volume Length74 2 bytes Big Endian Subcode74 2 bytes FirstVol file sequence FileSeq 2 bytes Sequence APPENDIX D - Language Encoding (EFS) ------------------------------------ D.1 The ZIP format has historically supported only the original IBM PC character encoding set, commonly referred to as IBM Code Page 437. This limits storing file name characters to only those within the original MS-DOS range of values and does not properly support file names in other character encodings, or languages. To address this limitation, this specification will support the following change. D.2 If general purpose bit 11 is unset, the file name and comment should conform to the original ZIP character encoding. If general purpose bit 11 is set, the filename and comment must support The Unicode Standard, Version 4.1.0 or greater using the character encoding form defined by the UTF-8 storage specification. The Unicode Standard is published by the The Unicode Consortium (www.unicode.org). UTF-8 encoded data stored within ZIP files is expected to not include a byte order mark (BOM). D.3 Applications may choose to supplement this file name storage through the use of the 0x0008 Extra Field. Storage for this optional field is currently undefined, however it will be used to allow storing extended information on source or target encoding that may further assist applications with file name, or file content encoding tasks. Please contact PKWARE with any requirements on how this field should be used. D.4 The 0x0008 Extra Field storage may be used with either setting for general purpose bit 11. Examples of the intended usage for this field is to store whether "modified-UTF-8" (JAVA) is used, or UTF-8-MAC. Similarly, other commonly used character encoding (code page) designations can be indicated through this field. Formalized values for use of the 0x0008 record remain undefined at this time. The definition for the layout of the 0x0008 field will be published when available. Use of the 0x0008 Extra Field provides for storing data within a ZIP file in an encoding other than IBM Code Page 437 or UTF-8. D.5 General purpose bit 11 will not imply any encoding of file content or password. Values defining character encoding for file content or password must be stored within the 0x0008 Extended Language Encoding Extra Field. D.6 Ed Gordon of the Info-ZIP group has defined a pair of "extra field" records that can be used to store UTF-8 file name and file comment fields. These records can be used for cases when the general purpose bit 11 method for storing UTF-8 data in the standard file name and comment fields is not desirable. A common case for this alternate method is if backward compatibility with older programs is required. D.7 Definitions for the record structure of these fields are included above in the section on 3rd party mappings for "extra field" records. These records are identified by Header ID's 0x6375 (Info-ZIP Unicode Comment Extra Field) and 0x7075 (Info-ZIP Unicode Path Extra Field). D.8 The choice of which storage method to use when writing a ZIP file is left to the implementation. Developers should expect that a ZIP file may contain either method and should provide support for reading data in either format. Use of general purpose bit 11 reduces storage requirements for file name data by not requiring additional "extra field" data for each file, but can result in older ZIP programs not being able to extract files. Use of the 0x6375 and 0x7075 records will result in a ZIP file that should always be readable by older ZIP programs, but requires more storage per file to write file name and/or file comment fields. Zipios-2.3.2/doc/zipios.doxy.in000066400000000000000000003205431445164132200164000ustar00rootroot00000000000000# Doxyfile 1.8.11 # This file describes the settings to be used by the documentation system # doxygen (www.doxygen.org) for a project. # # All text after a double hash (##) is considered a comment and is placed in # front of the TAG it is preceding. # # All text after a single hash (#) is considered a comment and will be ignored. # The format is: # TAG = value [value, ...] # For lists, items can also be appended using: # TAG += value [value, ...] # Values that contain spaces should be placed between quotes (\" \"). #--------------------------------------------------------------------------- # Project related configuration options #--------------------------------------------------------------------------- # This tag specifies the encoding used for all characters in the config file # that follow. The default is UTF-8 which is also the encoding used for all text # before the first occurrence of this tag. Doxygen uses libiconv (or the iconv # built into libc) for the transcoding. See http://www.gnu.org/software/libiconv # for the list of possible encodings. # The default value is: UTF-8. DOXYFILE_ENCODING = UTF-8 # The PROJECT_NAME tag is a single word (or a sequence of words surrounded by # double-quotes, unless you are using Doxywizard) that should identify the # project for which the documentation is generated. This name is used in the # title of most generated pages and in a few other places. # The default value is: My Project. PROJECT_NAME = "zipios" # The PROJECT_NUMBER tag can be used to enter a project or revision number. This # could be handy for archiving the generated documentation or if some version # control system is used. PROJECT_NUMBER = @FULL_VERSION@ # Using the PROJECT_BRIEF tag one can provide an optional one line description # for a project that appears at the top of each page and should give viewer a # quick idea about the purpose of the project. Keep the description short. PROJECT_BRIEF = "Zipios -- a small C++ library that provides easy access to .zip files." # With the PROJECT_LOGO tag one can specify a logo or an icon that is included # in the documentation. The maximum height of the logo should not exceed 55 # pixels and the maximum width should not exceed 200 pixels. Doxygen will copy # the logo to the output directory. PROJECT_LOGO = # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path # into which the generated documentation will be written. If a relative path is # entered, it will be relative to the location where doxygen was started. If # left blank the current directory will be used. OUTPUT_DIRECTORY = @CMAKE_CURRENT_BINARY_DIR@ # If the CREATE_SUBDIRS tag is set to YES then doxygen will create 4096 sub- # directories (in 2 levels) under the output directory of each output format and # will distribute the generated files over these directories. Enabling this # option can be useful when feeding doxygen a huge amount of source files, where # putting all generated files in the same directory would otherwise causes # performance problems for the file system. # The default value is: NO. CREATE_SUBDIRS = NO # If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII # characters to appear in the names of generated files. If set to NO, non-ASCII # characters will be escaped, for example _xE3_x81_x84 will be used for Unicode # U+3044. # The default value is: NO. ALLOW_UNICODE_NAMES = NO # The OUTPUT_LANGUAGE tag is used to specify the language in which all # documentation generated by doxygen is written. Doxygen will use this # information to generate all constant output in the proper language. # Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese, # Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States), # Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian, # Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages), # Korean, Korean-en (Korean with English messages), Latvian, Lithuanian, # Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian, # Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish, # Ukrainian and Vietnamese. # The default value is: English. OUTPUT_LANGUAGE = English # If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member # descriptions after the members that are listed in the file and class # documentation (similar to Javadoc). Set to NO to disable this. # The default value is: YES. BRIEF_MEMBER_DESC = YES # If the REPEAT_BRIEF tag is set to YES, doxygen will prepend the brief # description of a member or function before the detailed description # # Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the # brief descriptions will be completely suppressed. # The default value is: YES. REPEAT_BRIEF = NO # This tag implements a quasi-intelligent brief description abbreviator that is # used to form the text in various listings. Each string in this list, if found # as the leading text of the brief description, will be stripped from the text # and the result, after processing the whole list, is used as the annotated # text. Otherwise, the brief description is used as-is. If left blank, the # following values are used ($name is automatically replaced with the name of # the entity):The $name class, The $name widget, The $name file, is, provides, # specifies, contains, represents, a, an and the. ABBREVIATE_BRIEF = # If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then # doxygen will generate a detailed section even if there is only a brief # description. # The default value is: NO. ALWAYS_DETAILED_SEC = NO # If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all # inherited members of a class in the documentation of that class as if those # members were ordinary class members. Constructors, destructors and assignment # operators of the base classes will not be shown. # The default value is: NO. INLINE_INHERITED_MEMB = YES # If the FULL_PATH_NAMES tag is set to YES, doxygen will prepend the full path # before files name in the file list and in the header files. If set to NO the # shortest path that makes the file name unique will be used # The default value is: YES. FULL_PATH_NAMES = NO # The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path. # Stripping is only done if one of the specified strings matches the left-hand # part of the path. The tag can be used to show relative paths in the file list. # If left blank the directory from which doxygen is run is used as the path to # strip. # # Note that you can specify absolute paths here, but also relative paths, which # will be relative from the directory where doxygen is started. # This tag requires that the tag FULL_PATH_NAMES is set to YES. STRIP_FROM_PATH = @CMAKE_CURRENT_SOURCE_DIR@ # The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the # path mentioned in the documentation of a class, which tells the reader which # header file to include in order to use a class. If left blank only the name of # the header file containing the class definition is used. Otherwise one should # specify the list of include paths that are normally passed to the compiler # using the -I flag. STRIP_FROM_INC_PATH = # If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but # less readable) file names. This can be useful is your file systems doesn't # support long names like on DOS, Mac, or CD-ROM. # The default value is: NO. SHORT_NAMES = NO # If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the # first line (until the first dot) of a Javadoc-style comment as the brief # description. If set to NO, the Javadoc-style will behave just like regular Qt- # style comments (thus requiring an explicit @brief command for a brief # description.) # The default value is: NO. JAVADOC_AUTOBRIEF = NO # If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first # line (until the first dot) of a Qt-style comment as the brief description. If # set to NO, the Qt-style will behave just like regular Qt-style comments (thus # requiring an explicit \brief command for a brief description.) # The default value is: NO. QT_AUTOBRIEF = NO # The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a # multi-line C++ special comment block (i.e. a block of //! or /// comments) as # a brief description. This used to be the default behavior. The new default is # to treat a multi-line C++ comment block as a detailed description. Set this # tag to YES if you prefer the old behavior instead. # # Note that setting this tag to YES also means that rational rose comments are # not recognized any more. # The default value is: NO. MULTILINE_CPP_IS_BRIEF = NO # If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the # documentation from any documented member that it re-implements. # The default value is: YES. INHERIT_DOCS = YES # If the SEPARATE_MEMBER_PAGES tag is set to YES then doxygen will produce a new # page for each member. If set to NO, the documentation of a member will be part # of the file/class/namespace that contains it. # The default value is: NO. SEPARATE_MEMBER_PAGES = NO # The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen # uses this value to replace tabs by spaces in code fragments. # Minimum value: 1, maximum value: 16, default value: 4. TAB_SIZE = 4 # This tag can be used to specify a number of aliases that act as commands in # the documentation. An alias has the form: # name=value # For example adding # "sideeffect=@par Side Effects:\n" # will allow you to put the command \sideeffect (or @sideeffect) in the # documentation, which will result in a user-defined paragraph with heading # "Side Effects:". You can put \n's in the value part of an alias to insert # newlines. ALIASES = "TODO=@todo" \ "FIXME=@todo" # This tag can be used to specify a number of word-keyword mappings (TCL only). # A mapping has the form "name=value". For example adding "class=itcl::class" # will allow you to use the command class in the itcl::class meaning. TCL_SUBST = # Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources # only. Doxygen will then generate output that is more tailored for C. For # instance, some of the names that are used will be different. The list of all # members will be omitted, etc. # The default value is: NO. OPTIMIZE_OUTPUT_FOR_C = NO # Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or # Python sources only. Doxygen will then generate output that is more tailored # for that language. For instance, namespaces will be presented as packages, # qualified scopes will look different, etc. # The default value is: NO. OPTIMIZE_OUTPUT_JAVA = NO # Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran # sources. Doxygen will then generate output that is tailored for Fortran. # The default value is: NO. OPTIMIZE_FOR_FORTRAN = NO # Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL # sources. Doxygen will then generate output that is tailored for VHDL. # The default value is: NO. OPTIMIZE_OUTPUT_VHDL = NO # Doxygen selects the parser to use depending on the extension of the files it # parses. With this tag you can assign which parser to use for a given # extension. Doxygen has a built-in mapping, but you can override or extend it # using this tag. The format is ext=language, where ext is a file extension, and # language is one of the parsers supported by doxygen: IDL, Java, Javascript, # C#, C, C++, D, PHP, Objective-C, Python, Fortran (fixed format Fortran: # FortranFixed, free formatted Fortran: FortranFree, unknown formatted Fortran: # Fortran. In the later case the parser tries to guess whether the code is fixed # or free formatted code, this is the default for Fortran type files), VHDL. For # instance to make doxygen treat .inc files as Fortran files (default is PHP), # and .f files as C (default is Fortran), use: inc=Fortran f=C. # # Note: For files without extension you can use no_extension as a placeholder. # # Note that for custom extensions you also need to set FILE_PATTERNS otherwise # the files are not read by doxygen. EXTENSION_MAPPING = in=C++ # If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments # according to the Markdown format, which allows for more readable # documentation. See http://daringfireball.net/projects/markdown/ for details. # The output of markdown processing is further processed by doxygen, so you can # mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in # case of backward compatibilities issues. # The default value is: YES. MARKDOWN_SUPPORT = YES # When enabled doxygen tries to link words that correspond to documented # classes, or namespaces to their corresponding documentation. Such a link can # be prevented in individual cases by putting a % sign in front of the word or # globally by setting AUTOLINK_SUPPORT to NO. # The default value is: YES. AUTOLINK_SUPPORT = YES # If you use STL classes (i.e. std::string, std::vector, etc.) but do not want # to include (a tag file for) the STL sources as input, then you should set this # tag to YES in order to let doxygen match functions declarations and # definitions whose arguments contain STL classes (e.g. func(std::string); # versus func(std::string) {}). This also make the inheritance and collaboration # diagrams that involve STL classes more complete and accurate. # The default value is: NO. BUILTIN_STL_SUPPORT = NO # If you use Microsoft's C++/CLI language, you should set this option to YES to # enable parsing support. # The default value is: NO. CPP_CLI_SUPPORT = NO # Set the SIP_SUPPORT tag to YES if your project consists of sip (see: # http://www.riverbankcomputing.co.uk/software/sip/intro) sources only. Doxygen # will parse them like normal C++ but will assume all classes use public instead # of private inheritance when no explicit protection keyword is present. # The default value is: NO. SIP_SUPPORT = NO # For Microsoft's IDL there are propget and propput attributes to indicate # getter and setter methods for a property. Setting this option to YES will make # doxygen to replace the get and set methods by a property in the documentation. # This will only work if the methods are indeed getting or setting a simple # type. If this is not the case, or you want to show the methods anyway, you # should set this option to NO. # The default value is: YES. IDL_PROPERTY_SUPPORT = YES # If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC # tag is set to YES then doxygen will reuse the documentation of the first # member in the group (if any) for the other members of the group. By default # all members of a group must be documented explicitly. # The default value is: NO. DISTRIBUTE_GROUP_DOC = NO # If one adds a struct or class to a group and this option is enabled, then also # any nested class or struct is added to the same group. By default this option # is disabled and one has to add nested compounds explicitly via \ingroup. # The default value is: NO. GROUP_NESTED_COMPOUNDS = NO # Set the SUBGROUPING tag to YES to allow class member groups of the same type # (for instance a group of public functions) to be put as a subgroup of that # type (e.g. under the Public Functions section). Set it to NO to prevent # subgrouping. Alternatively, this can be done per class using the # \nosubgrouping command. # The default value is: YES. SUBGROUPING = YES # When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions # are shown inside the group in which they are included (e.g. using \ingroup) # instead of on a separate page (for HTML and Man pages) or section (for LaTeX # and RTF). # # Note that this feature does not work in combination with # SEPARATE_MEMBER_PAGES. # The default value is: NO. INLINE_GROUPED_CLASSES = NO # When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions # with only public data fields or simple typedef fields will be shown inline in # the documentation of the scope in which they are defined (i.e. file, # namespace, or group documentation), provided this scope is documented. If set # to NO, structs, classes, and unions are shown on a separate page (for HTML and # Man pages) or section (for LaTeX and RTF). # The default value is: NO. INLINE_SIMPLE_STRUCTS = NO # When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or # enum is documented as struct, union, or enum with the name of the typedef. So # typedef struct TypeS {} TypeT, will appear in the documentation as a struct # with name TypeT. When disabled the typedef will appear as a member of a file, # namespace, or class. And the struct will be named TypeS. This can typically be # useful for C code in case the coding convention dictates that all compound # types are typedef'ed and only the typedef is referenced, never the tag name. # The default value is: NO. TYPEDEF_HIDES_STRUCT = NO # The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This # cache is used to resolve symbols given their name and scope. Since this can be # an expensive process and often the same symbol appears multiple times in the # code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small # doxygen will become slower. If the cache is too large, memory is wasted. The # cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range # is 0..9, the default is 0, corresponding to a cache size of 2^16=65536 # symbols. At the end of a run doxygen will report the cache usage and suggest # the optimal cache size from a speed point of view. # Minimum value: 0, maximum value: 9, default value: 0. LOOKUP_CACHE_SIZE = 0 #--------------------------------------------------------------------------- # Build related configuration options #--------------------------------------------------------------------------- # If the EXTRACT_ALL tag is set to YES, doxygen will assume all entities in # documentation are documented, even if no documentation was available. Private # class members and static file members will be hidden unless the # EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES. # Note: This will also disable the warnings about undocumented members that are # normally produced when WARNINGS is set to YES. # The default value is: NO. EXTRACT_ALL = YES # If the EXTRACT_PRIVATE tag is set to YES, all private members of a class will # be included in the documentation. # The default value is: NO. EXTRACT_PRIVATE = YES # If the EXTRACT_PACKAGE tag is set to YES, all members with package or internal # scope will be included in the documentation. # The default value is: NO. EXTRACT_PACKAGE = NO # If the EXTRACT_STATIC tag is set to YES, all static members of a file will be # included in the documentation. # The default value is: NO. EXTRACT_STATIC = YES # If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined # locally in source files will be included in the documentation. If set to NO, # only classes defined in header files are included. Does not have any effect # for Java sources. # The default value is: YES. EXTRACT_LOCAL_CLASSES = YES # This flag is only useful for Objective-C code. If set to YES, local methods, # which are defined in the implementation section but not in the interface are # included in the documentation. If set to NO, only methods in the interface are # included. # The default value is: NO. EXTRACT_LOCAL_METHODS = NO # If this flag is set to YES, the members of anonymous namespaces will be # extracted and appear in the documentation as a namespace called # 'anonymous_namespace{file}', where file will be replaced with the base name of # the file that contains the anonymous namespace. By default anonymous namespace # are hidden. # The default value is: NO. EXTRACT_ANON_NSPACES = YES # If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all # undocumented members inside documented classes or files. If set to NO these # members will be included in the various overviews, but no documentation # section is generated. This option has no effect if EXTRACT_ALL is enabled. # The default value is: NO. HIDE_UNDOC_MEMBERS = NO # If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all # undocumented classes that are normally visible in the class hierarchy. If set # to NO, these classes will be included in the various overviews. This option # has no effect if EXTRACT_ALL is enabled. # The default value is: NO. HIDE_UNDOC_CLASSES = NO # If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend # (class|struct|union) declarations. If set to NO, these declarations will be # included in the documentation. # The default value is: NO. HIDE_FRIEND_COMPOUNDS = NO # If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any # documentation blocks found inside the body of a function. If set to NO, these # blocks will be appended to the function's detailed documentation block. # The default value is: NO. HIDE_IN_BODY_DOCS = NO # The INTERNAL_DOCS tag determines if documentation that is typed after a # \internal command is included. If the tag is set to NO then the documentation # will be excluded. Set it to YES to include the internal documentation. # The default value is: NO. INTERNAL_DOCS = YES # If the CASE_SENSE_NAMES tag is set to NO then doxygen will only generate file # names in lower-case letters. If set to YES, upper-case letters are also # allowed. This is useful if you have classes or files whose names only differ # in case and if your file system supports case sensitive file names. Windows # and Mac users are advised to set this option to NO. # The default value is: system dependent. CASE_SENSE_NAMES = YES # If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with # their full class and namespace scopes in the documentation. If set to YES, the # scope will be hidden. # The default value is: NO. HIDE_SCOPE_NAMES = NO # If the HIDE_COMPOUND_REFERENCE tag is set to NO (default) then doxygen will # append additional text to a page's title, such as Class Reference. If set to # YES the compound reference will be hidden. # The default value is: NO. HIDE_COMPOUND_REFERENCE= NO # If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of # the files that are included by a file in the documentation of that file. # The default value is: YES. SHOW_INCLUDE_FILES = YES # If the SHOW_GROUPED_MEMB_INC tag is set to YES then Doxygen will add for each # grouped member an include statement to the documentation, telling the reader # which file to include in order to use the member. # The default value is: NO. SHOW_GROUPED_MEMB_INC = NO # If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include # files with double quotes in the documentation rather than with sharp brackets. # The default value is: NO. FORCE_LOCAL_INCLUDES = NO # If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the # documentation for inline members. # The default value is: YES. INLINE_INFO = YES # If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the # (detailed) documentation of file and class members alphabetically by member # name. If set to NO, the members will appear in declaration order. # The default value is: YES. SORT_MEMBER_DOCS = YES # If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief # descriptions of file, namespace and class members alphabetically by member # name. If set to NO, the members will appear in declaration order. Note that # this will also influence the order of the classes in the class list. # The default value is: NO. SORT_BRIEF_DOCS = YES # If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the # (brief and detailed) documentation of class members so that constructors and # destructors are listed first. If set to NO the constructors will appear in the # respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS. # Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief # member documentation. # Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting # detailed member documentation. # The default value is: NO. SORT_MEMBERS_CTORS_1ST = YES # If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy # of group names into alphabetical order. If set to NO the group names will # appear in their defined order. # The default value is: NO. SORT_GROUP_NAMES = NO # If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by # fully-qualified names, including namespaces. If set to NO, the class list will # be sorted only by class name, not including the namespace part. # Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. # Note: This option applies only to the class list, not to the alphabetical # list. # The default value is: NO. SORT_BY_SCOPE_NAME = NO # If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper # type resolution of all parameters of a function it will reject a match between # the prototype and the implementation of a member function even if there is # only one candidate or it is obvious which candidate to choose by doing a # simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still # accept a match between prototype and implementation in such cases. # The default value is: NO. STRICT_PROTO_MATCHING = NO # The GENERATE_TODOLIST tag can be used to enable (YES) or disable (NO) the todo # list. This list is created by putting \todo commands in the documentation. # The default value is: YES. GENERATE_TODOLIST = YES # The GENERATE_TESTLIST tag can be used to enable (YES) or disable (NO) the test # list. This list is created by putting \test commands in the documentation. # The default value is: YES. GENERATE_TESTLIST = YES # The GENERATE_BUGLIST tag can be used to enable (YES) or disable (NO) the bug # list. This list is created by putting \bug commands in the documentation. # The default value is: YES. GENERATE_BUGLIST = YES # The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or disable (NO) # the deprecated list. This list is created by putting \deprecated commands in # the documentation. # The default value is: YES. GENERATE_DEPRECATEDLIST= YES # The ENABLED_SECTIONS tag can be used to enable conditional documentation # sections, marked by \if ... \endif and \cond # ... \endcond blocks. ENABLED_SECTIONS = # The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the # initial value of a variable or macro / define can have for it to appear in the # documentation. If the initializer consists of more lines than specified here # it will be hidden. Use a value of 0 to hide initializers completely. The # appearance of the value of individual variables and macros / defines can be # controlled using \showinitializer or \hideinitializer command in the # documentation regardless of this setting. # Minimum value: 0, maximum value: 10000, default value: 30. MAX_INITIALIZER_LINES = 30 # Set the SHOW_USED_FILES tag to NO to disable the list of files generated at # the bottom of the documentation of classes and structs. If set to YES, the # list will mention the files that were used to generate the documentation. # The default value is: YES. SHOW_USED_FILES = YES # Set the SHOW_FILES tag to NO to disable the generation of the Files page. This # will remove the Files entry from the Quick Index and from the Folder Tree View # (if specified). # The default value is: YES. SHOW_FILES = YES # Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces # page. This will remove the Namespaces entry from the Quick Index and from the # Folder Tree View (if specified). # The default value is: YES. SHOW_NAMESPACES = YES # The FILE_VERSION_FILTER tag can be used to specify a program or script that # doxygen should invoke to get the current version for each file (typically from # the version control system). Doxygen will invoke the program by executing (via # popen()) the command command input-file, where command is the value of the # FILE_VERSION_FILTER tag, and input-file is the name of an input file provided # by doxygen. Whatever the program writes to standard output is used as the file # version. For an example see the documentation. FILE_VERSION_FILTER = # The LAYOUT_FILE tag can be used to specify a layout file which will be parsed # by doxygen. The layout file controls the global structure of the generated # output files in an output format independent way. To create the layout file # that represents doxygen's defaults, run doxygen with the -l option. You can # optionally specify a file name after the option, if omitted DoxygenLayout.xml # will be used as the name of the layout file. # # Note that if you run doxygen from a directory containing a file called # DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE # tag is left empty. LAYOUT_FILE = # The CITE_BIB_FILES tag can be used to specify one or more bib files containing # the reference definitions. This must be a list of .bib files. The .bib # extension is automatically appended if omitted. This requires the bibtex tool # to be installed. See also http://en.wikipedia.org/wiki/BibTeX for more info. # For LaTeX the style of the bibliography can be controlled using # LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the # search path. See also \cite for info how to create references. CITE_BIB_FILES = #--------------------------------------------------------------------------- # Configuration options related to warning and progress messages #--------------------------------------------------------------------------- # The QUIET tag can be used to turn on/off the messages that are generated to # standard output by doxygen. If QUIET is set to YES this implies that the # messages are off. # The default value is: NO. QUIET = NO # The WARNINGS tag can be used to turn on/off the warning messages that are # generated to standard error (stderr) by doxygen. If WARNINGS is set to YES # this implies that the warnings are on. # # Tip: Turn warnings on while writing the documentation. # The default value is: YES. WARNINGS = YES # If the WARN_IF_UNDOCUMENTED tag is set to YES then doxygen will generate # warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag # will automatically be disabled. # The default value is: YES. WARN_IF_UNDOCUMENTED = YES # If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for # potential errors in the documentation, such as not documenting some parameters # in a documented function, or documenting parameters that don't exist or using # markup commands wrongly. # The default value is: YES. WARN_IF_DOC_ERROR = YES # This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that # are documented, but have no documentation for their parameters or return # value. If set to NO, doxygen will only warn about wrong or incomplete # parameter documentation, but not about the absence of documentation. # The default value is: NO. WARN_NO_PARAMDOC = YES # If the WARN_AS_ERROR tag is set to YES then doxygen will immediately stop when # a warning is encountered. # The default value is: NO. WARN_AS_ERROR = NO # The WARN_FORMAT tag determines the format of the warning messages that doxygen # can produce. The string should contain the $file, $line, and $text tags, which # will be replaced by the file and line number from which the warning originated # and the warning text. Optionally the format may contain $version, which will # be replaced by the version of the file (if it could be obtained via # FILE_VERSION_FILTER) # The default value is: $file:$line: $text. WARN_FORMAT = "$file:$line: $text" # The WARN_LOGFILE tag can be used to specify a file to which warning and error # messages should be written. If left blank the output is written to standard # error (stderr). WARN_LOGFILE = #--------------------------------------------------------------------------- # Configuration options related to the input files #--------------------------------------------------------------------------- # The INPUT tag is used to specify the files and/or directories that contain # documented source files. You may enter file names like myfile.cpp or # directories like /usr/src/myproject. Separate the files or directories with # spaces. See also FILE_PATTERNS and EXTENSION_MAPPING # Note: If this tag is empty the current directory is searched. INPUT = @zipios_project_SOURCE_DIR@/src \ @zipios_project_SOURCE_DIR@/tools \ @zipios_project_SOURCE_DIR@/zipios \ @zipios_project_BINARY_DIR@/zipios # This tag can be used to specify the character encoding of the source files # that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses # libiconv (or the iconv built into libc) for the transcoding. See the libiconv # documentation (see: http://www.gnu.org/software/libiconv) for the list of # possible encodings. # The default value is: UTF-8. INPUT_ENCODING = UTF-8 # If the value of the INPUT tag contains directories, you can use the # FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and # *.h) to filter out the source-files in the directories. # # Note that for custom extensions or not directly supported extensions you also # need to set EXTENSION_MAPPING for the extension otherwise the files are not # read by doxygen. # # If left blank the following patterns are tested:*.c, *.cc, *.cxx, *.cpp, # *.c++, *.java, *.ii, *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, # *.hh, *.hxx, *.hpp, *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc, # *.m, *.markdown, *.md, *.mm, *.dox, *.py, *.pyw, *.f90, *.f, *.for, *.tcl, # *.vhd, *.vhdl, *.ucf, *.qsf, *.as and *.js. FILE_PATTERNS = *.h \ *.h.in \ *.hpp \ *.hpp.in \ *.cpp \ *.c # The RECURSIVE tag can be used to specify whether or not subdirectories should # be searched for input files as well. # The default value is: NO. RECURSIVE = NO # The EXCLUDE tag can be used to specify files and/or directories that should be # excluded from the INPUT source files. This way you can easily exclude a # subdirectory from a directory tree whose root is specified with the INPUT tag. # # Note that relative paths are relative to the directory from which doxygen is # run. EXCLUDE = # The EXCLUDE_SYMLINKS tag can be used to select whether or not files or # directories that are symbolic links (a Unix file system feature) are excluded # from the input. # The default value is: NO. EXCLUDE_SYMLINKS = NO # If the value of the INPUT tag contains directories, you can use the # EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude # certain files from those directories. # # Note that the wildcards are matched against the file with absolute path, so to # exclude all test directories for example use the pattern */test/* EXCLUDE_PATTERNS = # The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names # (namespaces, classes, functions, etc.) that should be excluded from the # output. The symbol name can be a fully qualified name, a word, or if the # wildcard * is used, a substring. Examples: ANamespace, AClass, # AClass::ANamespace, ANamespace::*Test # # Note that the wildcards are matched against the file with absolute path, so to # exclude all test directories use the pattern */test/* EXCLUDE_SYMBOLS = # The EXAMPLE_PATH tag can be used to specify one or more files or directories # that contain example code fragments that are included (see the \include # command). EXAMPLE_PATH = @zipios_project_SOURCE_DIR@/tools # If the value of the EXAMPLE_PATH tag contains directories, you can use the # EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and # *.h) to filter out the source-files in the directories. If left blank all # files are included. EXAMPLE_PATTERNS = *example*.cpp # If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be # searched for input files to be used with the \include or \dontinclude commands # irrespective of the value of the RECURSIVE tag. # The default value is: NO. EXAMPLE_RECURSIVE = NO # The IMAGE_PATH tag can be used to specify one or more files or directories # that contain images that are to be included in the documentation (see the # \image command). IMAGE_PATH = @CMAKE_CURRENT_SOURCE_DIR@/images # The INPUT_FILTER tag can be used to specify a program that doxygen should # invoke to filter for each input file. Doxygen will invoke the filter program # by executing (via popen()) the command: # # # # where is the value of the INPUT_FILTER tag, and is the # name of an input file. Doxygen will then use the output that the filter # program writes to standard output. If FILTER_PATTERNS is specified, this tag # will be ignored. # # Note that the filter must not add or remove lines; it is applied before the # code is scanned, but not when the output code is generated. If lines are added # or removed, the anchors will not be placed correctly. # # Note that for custom extensions or not directly supported extensions you also # need to set EXTENSION_MAPPING for the extension otherwise the files are not # properly processed by doxygen. INPUT_FILTER = # The FILTER_PATTERNS tag can be used to specify filters on a per file pattern # basis. Doxygen will compare the file name with each pattern and apply the # filter if there is a match. The filters are a list of the form: pattern=filter # (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how # filters are used. If the FILTER_PATTERNS tag is empty or if none of the # patterns match the file name, INPUT_FILTER is applied. # # Note that for custom extensions or not directly supported extensions you also # need to set EXTENSION_MAPPING for the extension otherwise the files are not # properly processed by doxygen. FILTER_PATTERNS = # If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using # INPUT_FILTER) will also be used to filter the input files that are used for # producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES). # The default value is: NO. FILTER_SOURCE_FILES = NO # The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file # pattern. A pattern will override the setting for FILTER_PATTERN (if any) and # it is also possible to disable source filtering for a specific pattern using # *.ext= (so without naming a filter). # This tag requires that the tag FILTER_SOURCE_FILES is set to YES. FILTER_SOURCE_PATTERNS = # If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that # is part of the input, its contents will be placed on the main page # (index.html). This can be useful if you have a project on for instance GitHub # and want to reuse the introduction page also for the doxygen output. USE_MDFILE_AS_MAINPAGE = #--------------------------------------------------------------------------- # Configuration options related to source browsing #--------------------------------------------------------------------------- # If the SOURCE_BROWSER tag is set to YES then a list of source files will be # generated. Documented entities will be cross-referenced with these sources. # # Note: To get rid of all source code in the generated output, make sure that # also VERBATIM_HEADERS is set to NO. # The default value is: NO. SOURCE_BROWSER = YES # Setting the INLINE_SOURCES tag to YES will include the body of functions, # classes and enums directly into the documentation. # The default value is: NO. INLINE_SOURCES = NO # Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any # special comment blocks from generated source code fragments. Normal C, C++ and # Fortran comments will always remain visible. # The default value is: YES. STRIP_CODE_COMMENTS = YES # If the REFERENCED_BY_RELATION tag is set to YES then for each documented # function all documented functions referencing it will be listed. # The default value is: NO. REFERENCED_BY_RELATION = YES # If the REFERENCES_RELATION tag is set to YES then for each documented function # all documented entities called/used by that function will be listed. # The default value is: NO. REFERENCES_RELATION = YES # If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set # to YES then the hyperlinks from functions in REFERENCES_RELATION and # REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will # link to the documentation. # The default value is: YES. REFERENCES_LINK_SOURCE = YES # If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the # source code will show a tooltip with additional information such as prototype, # brief description and links to the definition and documentation. Since this # will make the HTML file larger and loading of large files a bit slower, you # can opt to disable this feature. # The default value is: YES. # This tag requires that the tag SOURCE_BROWSER is set to YES. SOURCE_TOOLTIPS = YES # If the USE_HTAGS tag is set to YES then the references to source code will # point to the HTML generated by the htags(1) tool instead of doxygen built-in # source browser. The htags tool is part of GNU's global source tagging system # (see http://www.gnu.org/software/global/global.html). You will need version # 4.8.6 or higher. # # To use it do the following: # - Install the latest version of global # - Enable SOURCE_BROWSER and USE_HTAGS in the config file # - Make sure the INPUT points to the root of the source tree # - Run doxygen as normal # # Doxygen will invoke htags (and that will in turn invoke gtags), so these # tools must be available from the command line (i.e. in the search path). # # The result: instead of the source browser generated by doxygen, the links to # source code will now point to the output of htags. # The default value is: NO. # This tag requires that the tag SOURCE_BROWSER is set to YES. USE_HTAGS = NO # If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a # verbatim copy of the header file for each class for which an include is # specified. Set to NO to disable this. # See also: Section \class. # The default value is: YES. VERBATIM_HEADERS = YES # If the CLANG_ASSISTED_PARSING tag is set to YES then doxygen will use the # clang parser (see: http://clang.llvm.org/) for more accurate parsing at the # cost of reduced performance. This can be particularly helpful with template # rich C++ code for which doxygen's built-in parser lacks the necessary type # information. # Note: The availability of this option depends on whether or not doxygen was # generated with the -Duse-libclang=ON option for CMake. # The default value is: NO. CLANG_ASSISTED_PARSING = NO # If clang assisted parsing is enabled you can provide the compiler with command # line options that you would normally use when invoking the compiler. Note that # the include paths will already be set by doxygen for the files and directories # specified with INPUT and INCLUDE_PATH. # This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES. CLANG_OPTIONS = #--------------------------------------------------------------------------- # Configuration options related to the alphabetical class index #--------------------------------------------------------------------------- # If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all # compounds will be generated. Enable this if the project contains a lot of # classes, structs, unions or interfaces. # The default value is: YES. ALPHABETICAL_INDEX = YES # The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in # which the alphabetical index list will be split. # Minimum value: 1, maximum value: 20, default value: 5. # This tag requires that the tag ALPHABETICAL_INDEX is set to YES. COLS_IN_ALPHA_INDEX = 5 # In case all classes in a project start with a common prefix, all classes will # be put under the same header in the alphabetical index. The IGNORE_PREFIX tag # can be used to specify a prefix (or a list of prefixes) that should be ignored # while generating the index headers. # This tag requires that the tag ALPHABETICAL_INDEX is set to YES. IGNORE_PREFIX = m_ #--------------------------------------------------------------------------- # Configuration options related to the HTML output #--------------------------------------------------------------------------- # If the GENERATE_HTML tag is set to YES, doxygen will generate HTML output # The default value is: YES. GENERATE_HTML = YES # The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a # relative path is entered the value of OUTPUT_DIRECTORY will be put in front of # it. # The default directory is: html. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_OUTPUT = html # The HTML_FILE_EXTENSION tag can be used to specify the file extension for each # generated HTML page (for example: .htm, .php, .asp). # The default value is: .html. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_FILE_EXTENSION = .html # The HTML_HEADER tag can be used to specify a user-defined HTML header file for # each generated HTML page. If the tag is left blank doxygen will generate a # standard header. # # To get valid HTML the header file that includes any scripts and style sheets # that doxygen needs, which is dependent on the configuration options used (e.g. # the setting GENERATE_TREEVIEW). It is highly recommended to start with a # default header using # doxygen -w html new_header.html new_footer.html new_stylesheet.css # YourConfigFile # and then modify the file new_header.html. See also section "Doxygen usage" # for information on how to generate the default header that doxygen normally # uses. # Note: The header is subject to change so you typically have to regenerate the # default header when upgrading to a newer version of doxygen. For a description # of the possible markers and block names see the documentation. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_HEADER = # The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each # generated HTML page. If the tag is left blank doxygen will generate a standard # footer. See HTML_HEADER for more information on how to generate a default # footer and what special commands can be used inside the footer. See also # section "Doxygen usage" for information on how to generate the default footer # that doxygen normally uses. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_FOOTER = # The HTML_STYLESHEET tag can be used to specify a user-defined cascading style # sheet that is used by each HTML page. It can be used to fine-tune the look of # the HTML output. If left blank doxygen will generate a default style sheet. # See also section "Doxygen usage" for information on how to generate the style # sheet that doxygen normally uses. # Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as # it is more robust and this tag (HTML_STYLESHEET) will in the future become # obsolete. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_STYLESHEET = # The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-defined # cascading style sheets that are included after the standard style sheets # created by doxygen. Using this option one can overrule certain style aspects. # This is preferred over using HTML_STYLESHEET since it does not replace the # standard style sheet and is therefore more robust against future updates. # Doxygen will copy the style sheet files to the output directory. # Note: The order of the extra style sheet files is of importance (e.g. the last # style sheet in the list overrules the setting of the previous ones in the # list). For an example see the documentation. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_EXTRA_STYLESHEET = # The HTML_EXTRA_FILES tag can be used to specify one or more extra images or # other source files which should be copied to the HTML output directory. Note # that these files will be copied to the base HTML output directory. Use the # $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these # files. In the HTML_STYLESHEET file, use the file name only. Also note that the # files will be copied as-is; there are no commands or markers available. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_EXTRA_FILES = # The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen # will adjust the colors in the style sheet and background images according to # this color. Hue is specified as an angle on a colorwheel, see # http://en.wikipedia.org/wiki/Hue for more information. For instance the value # 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300 # purple, and 360 is red again. # Minimum value: 0, maximum value: 359, default value: 220. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE_HUE = 220 # The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors # in the HTML output. For a value of 0 the output will use grayscales only. A # value of 255 will produce the most vivid colors. # Minimum value: 0, maximum value: 255, default value: 100. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE_SAT = 100 # The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the # luminance component of the colors in the HTML output. Values below 100 # gradually make the output lighter, whereas values above 100 make the output # darker. The value divided by 100 is the actual gamma applied, so 80 represents # a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not # change the gamma. # Minimum value: 40, maximum value: 240, default value: 80. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_COLORSTYLE_GAMMA = 80 # If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML # page will contain the date and time when the page was generated. Setting this # to YES can help to show when doxygen was last run and thus if the # documentation is up to date. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_TIMESTAMP = YES # If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML # documentation will contain sections that can be hidden and shown after the # page has loaded. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_DYNAMIC_SECTIONS = NO # With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries # shown in the various tree structured indices initially; the user can expand # and collapse entries dynamically later on. Doxygen will expand the tree to # such a level that at most the specified number of entries are visible (unless # a fully collapsed tree already exceeds this amount). So setting the number of # entries 1 will produce a full collapsed tree by default. 0 is a special value # representing an infinite number of entries and will result in a full expanded # tree by default. # Minimum value: 0, maximum value: 9999, default value: 100. # This tag requires that the tag GENERATE_HTML is set to YES. HTML_INDEX_NUM_ENTRIES = 100 # If the GENERATE_DOCSET tag is set to YES, additional index files will be # generated that can be used as input for Apple's Xcode 3 integrated development # environment (see: http://developer.apple.com/tools/xcode/), introduced with # OSX 10.5 (Leopard). To create a documentation set, doxygen will generate a # Makefile in the HTML output directory. Running make will produce the docset in # that directory and running make install will install the docset in # ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at # startup. See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html # for more information. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_DOCSET = NO # This tag determines the name of the docset feed. A documentation feed provides # an umbrella under which multiple documentation sets from a single provider # (such as a company or product suite) can be grouped. # The default value is: Doxygen generated docs. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_FEEDNAME = "Doxygen generated docs" # This tag specifies a string that should uniquely identify the documentation # set bundle. This should be a reverse domain-name style string, e.g. # com.mycompany.MyDocSet. Doxygen will append .docset to the name. # The default value is: org.doxygen.Project. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_BUNDLE_ID = org.doxygen.Project # The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify # the documentation publisher. This should be a reverse domain-name style # string, e.g. com.mycompany.MyDocSet.documentation. # The default value is: org.doxygen.Publisher. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_PUBLISHER_ID = org.doxygen.Publisher # The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher. # The default value is: Publisher. # This tag requires that the tag GENERATE_DOCSET is set to YES. DOCSET_PUBLISHER_NAME = Publisher # If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three # additional HTML index files: index.hhp, index.hhc, and index.hhk. The # index.hhp is a project file that can be read by Microsoft's HTML Help Workshop # (see: http://www.microsoft.com/en-us/download/details.aspx?id=21138) on # Windows. # # The HTML Help Workshop contains a compiler that can convert all HTML output # generated by doxygen into a single compiled HTML file (.chm). Compiled HTML # files are now used as the Windows 98 help format, and will replace the old # Windows help format (.hlp) on all Windows platforms in the future. Compressed # HTML files also contain an index, a table of contents, and you can search for # words in the documentation. The HTML workshop also contains a viewer for # compressed HTML files. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_HTMLHELP = NO # The CHM_FILE tag can be used to specify the file name of the resulting .chm # file. You can add a path in front of the file if the result should not be # written to the html output directory. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. CHM_FILE = # The HHC_LOCATION tag can be used to specify the location (absolute path # including file name) of the HTML help compiler (hhc.exe). If non-empty, # doxygen will try to run the HTML help compiler on the generated index.hhp. # The file has to be specified with full path. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. HHC_LOCATION = # The GENERATE_CHI flag controls if a separate .chi index file is generated # (YES) or that it should be included in the master .chm file (NO). # The default value is: NO. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. GENERATE_CHI = NO # The CHM_INDEX_ENCODING is used to encode HtmlHelp index (hhk), content (hhc) # and project file content. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. CHM_INDEX_ENCODING = # The BINARY_TOC flag controls whether a binary table of contents is generated # (YES) or a normal table of contents (NO) in the .chm file. Furthermore it # enables the Previous and Next buttons. # The default value is: NO. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. BINARY_TOC = NO # The TOC_EXPAND flag can be set to YES to add extra items for group members to # the table of contents of the HTML help documentation and to the tree view. # The default value is: NO. # This tag requires that the tag GENERATE_HTMLHELP is set to YES. TOC_EXPAND = NO # If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and # QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that # can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help # (.qch) of the generated HTML documentation. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_QHP = NO # If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify # the file name of the resulting .qch file. The path specified is relative to # the HTML output folder. # This tag requires that the tag GENERATE_QHP is set to YES. QCH_FILE = # The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help # Project output. For more information please see Qt Help Project / Namespace # (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace). # The default value is: org.doxygen.Project. # This tag requires that the tag GENERATE_QHP is set to YES. QHP_NAMESPACE = org.doxygen.Project # The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt # Help Project output. For more information please see Qt Help Project / Virtual # Folders (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual- # folders). # The default value is: doc. # This tag requires that the tag GENERATE_QHP is set to YES. QHP_VIRTUAL_FOLDER = doc # If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom # filter to add. For more information please see Qt Help Project / Custom # Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom- # filters). # This tag requires that the tag GENERATE_QHP is set to YES. QHP_CUST_FILTER_NAME = # The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the # custom filter to add. For more information please see Qt Help Project / Custom # Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom- # filters). # This tag requires that the tag GENERATE_QHP is set to YES. QHP_CUST_FILTER_ATTRS = # The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this # project's filter section matches. Qt Help Project / Filter Attributes (see: # http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes). # This tag requires that the tag GENERATE_QHP is set to YES. QHP_SECT_FILTER_ATTRS = # The QHG_LOCATION tag can be used to specify the location of Qt's # qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the # generated .qhp file. # This tag requires that the tag GENERATE_QHP is set to YES. QHG_LOCATION = # If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be # generated, together with the HTML files, they form an Eclipse help plugin. To # install this plugin and make it available under the help contents menu in # Eclipse, the contents of the directory containing the HTML and XML files needs # to be copied into the plugins directory of eclipse. The name of the directory # within the plugins directory should be the same as the ECLIPSE_DOC_ID value. # After copying Eclipse needs to be restarted before the help appears. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_ECLIPSEHELP = NO # A unique identifier for the Eclipse help plugin. When installing the plugin # the directory name containing the HTML and XML files should also have this # name. Each documentation set should have its own identifier. # The default value is: org.doxygen.Project. # This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES. ECLIPSE_DOC_ID = org.doxygen.Project # If you want full control over the layout of the generated HTML pages it might # be necessary to disable the index and replace it with your own. The # DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top # of each HTML page. A value of NO enables the index and the value YES disables # it. Since the tabs in the index contain the same information as the navigation # tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. DISABLE_INDEX = NO # The GENERATE_TREEVIEW tag is used to specify whether a tree-like index # structure should be generated to display hierarchical information. If the tag # value is set to YES, a side panel will be generated containing a tree-like # index structure (just like the one that is generated for HTML Help). For this # to work a browser that supports JavaScript, DHTML, CSS and frames is required # (i.e. any modern browser). Windows users are probably better off using the # HTML help feature. Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can # further fine-tune the look of the index. As an example, the default style # sheet generated by doxygen has an example that shows how to put an image at # the root of the tree instead of the PROJECT_NAME. Since the tree basically has # the same information as the tab index, you could consider setting # DISABLE_INDEX to YES when enabling this option. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. GENERATE_TREEVIEW = NO # The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that # doxygen will group on one line in the generated HTML documentation. # # Note that a value of 0 will completely suppress the enum values from appearing # in the overview section. # Minimum value: 0, maximum value: 20, default value: 4. # This tag requires that the tag GENERATE_HTML is set to YES. ENUM_VALUES_PER_LINE = 1 # If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used # to set the initial width (in pixels) of the frame in which the tree is shown. # Minimum value: 0, maximum value: 1500, default value: 250. # This tag requires that the tag GENERATE_HTML is set to YES. TREEVIEW_WIDTH = 250 # If the EXT_LINKS_IN_WINDOW option is set to YES, doxygen will open links to # external symbols imported via tag files in a separate window. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. EXT_LINKS_IN_WINDOW = NO # Use this tag to change the font size of LaTeX formulas included as images in # the HTML documentation. When you change the font size after a successful # doxygen run you need to manually remove any form_*.png images from the HTML # output directory to force them to be regenerated. # Minimum value: 8, maximum value: 50, default value: 10. # This tag requires that the tag GENERATE_HTML is set to YES. FORMULA_FONTSIZE = 10 # Use the FORMULA_TRANPARENT tag to determine whether or not the images # generated for formulas are transparent PNGs. Transparent PNGs are not # supported properly for IE 6.0, but are supported on all modern browsers. # # Note that when changing this option you need to delete any form_*.png files in # the HTML output directory before the changes have effect. # The default value is: YES. # This tag requires that the tag GENERATE_HTML is set to YES. FORMULA_TRANSPARENT = YES # Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see # http://www.mathjax.org) which uses client side Javascript for the rendering # instead of using pre-rendered bitmaps. Use this if you do not have LaTeX # installed or if you want to formulas look prettier in the HTML output. When # enabled you may also need to install MathJax separately and configure the path # to it using the MATHJAX_RELPATH option. # The default value is: NO. # This tag requires that the tag GENERATE_HTML is set to YES. USE_MATHJAX = YES # When MathJax is enabled you can set the default output format to be used for # the MathJax output. See the MathJax site (see: # http://docs.mathjax.org/en/latest/output.html) for more details. # Possible values are: HTML-CSS (which is slower, but has the best # compatibility), NativeMML (i.e. MathML) and SVG. # The default value is: HTML-CSS. # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_FORMAT = HTML-CSS # When MathJax is enabled you need to specify the location relative to the HTML # output directory using the MATHJAX_RELPATH option. The destination directory # should contain the MathJax.js script. For instance, if the mathjax directory # is located at the same level as the HTML output directory, then # MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax # Content Delivery Network so you can quickly see the result without installing # MathJax. However, it is strongly recommended to install a local copy of # MathJax from http://www.mathjax.org before deployment. # The default value is: http://cdn.mathjax.org/mathjax/latest. # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest # The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax # extension names that should be enabled during MathJax rendering. For example # MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_EXTENSIONS = # The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces # of code that will be used on startup of the MathJax code. See the MathJax site # (see: http://docs.mathjax.org/en/latest/output.html) for more details. For an # example see the documentation. # This tag requires that the tag USE_MATHJAX is set to YES. MATHJAX_CODEFILE = # When the SEARCHENGINE tag is enabled doxygen will generate a search box for # the HTML output. The underlying search engine uses javascript and DHTML and # should work on any modern browser. Note that when using HTML help # (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET) # there is already a search function so this one should typically be disabled. # For large projects the javascript based search engine can be slow, then # enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to # search using the keyboard; to jump to the search box use + S # (what the is depends on the OS and browser, but it is typically # , /