Zip Unicode Filename 3

ZIP File Format Specification
Changelog
6.3.0 -Added option for Unicode filename storage
General purpose bit flag 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)

6.3.2 -Documented InfoZIP "Extra Field" values for UTF-8 file name and file comment storage

APPENDIX D - Language Encoding (EFS)
------------------------------------

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.

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).

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.

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.

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.

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.

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).

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.