/
AppNote.iz.txt
3686 lines (2917 loc) · 162 KB
/
AppNote.iz.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
[Info-ZIP note, 20040528: this file is based on PKWARE's appnote.txt of
15 February 1996, taking into account PKWARE's revised appnote.txt
version 6.2.0 of 26 April 2004. 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.]
File: APPNOTE.TXT - .ZIP File Format Specification
Version: 6.2.0 - NOTIFICATION OF CHANGE
Revised: 04/26/2004 [2004-05-28 Info-ZIP]
Copyright (c) 1989 - 2004 PKWARE Inc., All Rights Reserved.
I. Purpose
----------
This specification is intended to define a cross-platform,
interoperable file format. Since its first publication
in 1989, PKWARE has remained committed to ensuring the
interoperability of the .ZIP file format through this
specification. We trust that all .ZIP compatible vendors
and application developers that have adopted this format
will share and support this commitment.
II. 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 or omission 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.
If the version of this file is marked as a NOTIFICATION OF CHANGE,
the content defines an Early Feature Specification (EFS) change
to the .ZIP file format that may be subject to modification prior
to publication of the Final Feature Specification (FFS). This
document may also contain information on Planned Feature
Specifications (PFS) defining recognized future extensions.
III. Change Log
---------------
Version Change Description Date
------- ------------------ ----------
5.2 -Single Password Symmetric Encryption 06/02/2003
storage
6.1.0 -Smart Card 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
IV. 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.
(removed by PKWare 2003-06-01)]
Overall .ZIP file format:
[local file header 1]
[file data 1]
[data descriptor 1]
.
.
.
[local file header n]
[file data n]
[data descriptor n]
[archive decryption header] (EFS)
[archive extra data record] (EFS)
[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. Archive decryption header: (EFS)
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 will precede the encrypted data segment. The encrypted
data segment will 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. Refer to the
section on the Strong Encryption Specification for information
on the fields used in the Archive Decryption Header record.
E. Archive extra data record: (EFS)
archive extra data signature 4 bytes (0x08064b50)
extra field length 4 bytes
extra field data (variable size)
The Archive Extra Data Record 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 present, this record immediately precedes the central
directory data structure. The size of this data record will 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.
F. 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)
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.
G. 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)
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(tm) 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.
H. 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
I. 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)
J. 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 - OS/400 (IBM) | THEOS
19 - OS/X (Darwin)
20 thru 29 - unused
30 - AtheOS/Syllable
31 thru 255 - unused
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.
version needed to extract (2 bytes)
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 should 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.
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
* 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 should 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).
When using ZIP64 extensions, the corresponding value in the
Zip64 end of central directory record should also be set.
This field currently supports only the value 45 to indicate
ZIP64 extensions are present.
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" and "bzip2" fulfill 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: Strong encryption. If this bit is set, you should
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.
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: Used 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.
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
11 - Reserved by PKWARE
12 - File is compressed using BZIP2 algorithm
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.
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. 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.
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. If encrypting the central directory and general
purpose bit flag 13 is set indicating masking, the value stored
for the uncompressed size in the Local Header will be zero.
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)
Bits 1 and 2 are reserved for use by PKWARE.
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.
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. 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.
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. If encrypting
the central directory 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.
[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 thru 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
0x0008 Reserved for future Unicode file name data (PFS)
0x0009 OS/2 extended attributes (also Info-ZIP)
0x000a NTFS (Win9x/WinNT FileTimes)
0x000c OpenVMS (also Info-ZIP)
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
The Header ID mappings defined by Info-ZIP and third parties are:
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)
0x2805 ZipIt Macintosh 1.3.5+
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 inofficial 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
0x554e Xceed unicode extra field
0x5855 Info-ZIP Unix (original; also OS/2, NT, etc.)
0x6542 BeOS (BeBox, PowerMac, etc.)
0x6854 Theos
0x7441 AtheOS (AtheOS/Syllable attributes)
0x756e ASi Unix
0x7855 Info-ZIP Unix (new)
0xfb4a 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.
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.
-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 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 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 sizes.
-OS/2 Extended Attributes Extra Field (0x0009):
=============================================
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 (0x4453):
===================================================
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 (0x000a):
=======================================
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.) SubSizeN 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 (0x000c):
===================================
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 tage 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