The AHED chunk must appear FIRST. It contains:
| Significance | Size | Description |
|---|---|---|
| Major version | 1-byte | Major version of PNA |
| Minor version | 1-byte | Minor version of PNA |
| General purpose bit flag | 2-byte | Bit flags |
| Archive number | 4-byte | Archive number |
Currently, only 0 is defined. It may be changed if there is a change in the structure of each chunk that makes up PNA.
Currently, only 0 is defined. It may be changed when there is a change in the type of chunks that make up PNA.
Bit0 ~ Bit15 currently does not used. reserve for the future.
Contains the number of the archive when the archive is split.
Archive number is start with 0.
This chunk must appear last. This signals the end of PNA data stream. The chunk data area is empty. Decoders should not load more than this chunk.
Indicates that the archive is split and the following file exists.
The Archive number field of the AHED chunk of the next file will be the value of the Archive number field of the AHED chunk of the current file incremented by 1.
The chunk data area is empty.
Basic information about each entry is stored.
| Significance | Size | Description |
|---|---|---|
| Major version | 1-byte | Major version |
| Minor version | 1-byte | Minor version |
| Entry kind | 1-byte | Entry kind |
| Compression method | 1-byte | Compression method |
| Encryption method | 1-byte | Encryption method |
| Cipher mode | 1-byte | Cipher mode |
| Path | n-byte | File path |
The entry kind is recorded. 0 is regular file 1 is directory 2 is symbolic link 3 is hard link 4 is a file that has previously appeared in the archive
The compression method is recorded. 0 is not compression 1 is deflate 2 is zstandard 4 is lzma
The encryption method is recorded. 0 is not encryption 1 is AES 2 is Camellia
When this field value is 0, PHSF chunk is not required.
Cipher mode of encryption. 0 is cbc mode 1 is ctr mode
Not interested in the value of this field, if Encryption method filed value is 0.
The path of entry is encoded by UTF-8. The / is used as a path separator. Paths should not contain / at the leading or trailing. Decoders should ignore them even if they contain a leading or trailing /.
The information about the key derivation function when encrypting a file.
This chunk appeared after FHAD chunk and before FDAT chunk.
If the value of encryption method field of FHAD chunk is not 0, this chunk is required.
| size | description |
|---|---|
| n-byte | PHC string format |
About PHC string format
The actual data of the file is recorded. Multiple of these chunks are permitted for a single entry.
This signals the end of the entry data stream. The chunk data area is empty.
Basic information of Solid mode archive is stored.
| significance | size | description |
|---|---|---|
| Major version | 1-byte | Major version |
| Minor version | 1-byte | Minor version |
| Compression method | 1-byte | Compression method |
| Encryption method | 1-byte | Encryption method |
| Cipher mode | 1-byte | Cipher mode |
Solid mode archive data. Contains chunks representing entries.
This signals the end of the solid data stream.
The chunk data area is empty.
All Auxiliary Chunks must appear before the AEND chunk.
The creation datetime is recorded in Unix time.
When this chunk appears after the FHAD chunk and before the FEND chunk, it indicates the creation datetime of the entry.
| size | description |
|---|---|
| 8byte | Unix timestamp |
The last modified datetime is recorded in Unix time.
When this chunk appears after the FHAD chunk and before the FEND chunk, it indicates the last modified datetime of the entry.
| size | description |
|---|---|
| 8byte | Unix timestamp |
The last accessed datetime is recorded in Unix time.
When this chunk appears after the FHAD chunk and before the FEND chunk, it indicates the last accessed datetime of the entry.
| size | description |
|---|---|
| 8byte | Unix timestamp |
File permissions are recorded.
This chunk appeared after FHAD chunk and before FEND chunk.
| significance | size | description |
|---|---|---|
| uid | 8-byte | user ID |
| uname length | 1-byte | length of uname |
| uname | n-byte | Unix user name |
| gid | 8-byte | group ID |
| gname length | 1-byte | length of gname |
| gname | n-byte | Unix group name |
| permissions | 2-byte | file permission bytes |
An extended attribute are recorded.
this chunk appeared after FHAD chunk and before FEND chunk. this chunk can appear many times.
| significance | size | description |
|---|---|---|
| name length | 4-byte | length of name |
| name | n-byte | attribute name |
| body length | 4-byte | length of body |
| body | n-byte | attribute value |
This table summarizes some properties of the standard chunk types.
Critical chunks
| Name | Multiple | Optional | Ordering constraints |
|---|---|---|---|
| AHED | No | No | Must be first |
| FHED | Yes | Yes | |
| PHSF | Yes | Yes | Before FDAT or SDAT |
| FDAT | Yes | Yes | Multiple FDATs must be consecutive |
| FEND | Yes | Yes | |
| SHED | Yes | Yes | |
| SDAT | Yes | Yes | Multiple SDATs must be consecutive |
| SEND | Yes | Yes | |
| ANXT | No | Yes | |
| AEND | No | No | Must be last |
Additional public PNG chunk types are defined in the document “Extensions to the PNG 1.2 Specification, Version 1.2.0” [PNG-EXTENSIONS]. Chunks described there are expected to be less widely supported than those defined in this specification. However, application authors are encouraged to use those chunk types whenever appropriate for their applications. Additional chunk types can be proposed for inclusion in that list by contacting the PNG specification maintainers at png-info@uunet.uu.net or at png-group@w3.org.
New public chunks will be registered only if they are of use to others and do not violate the design philosophy of PNG. Chunk registration is not automatic, although it is the intent of the authors that it be straightforward when a new chunk of potentially wide application is needed. Note that the creation of new critical chunk types is discouraged unless absolutely necessary.
Applications can also use private chunk types to carry data that is not of interest to other applications. See Recommendations for Encoders: Use of private chunks.
Decoders must be prepared to encounter unrecognized public or private chunk-type codes. Unrecognized chunk types must be handled as described in Chunk naming conventions.