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 (Rijndael) 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 Compression method, Encryption method, and Cipher mode fields in the FHED chunk must be set to the following PNA method codes (integer values):
| Field | Value | Algorithm/Mode | Note |
|---|---|---|---|
| Compression method | 0 | No compression | |
| 1 | Deflate | zlib compatible | |
| 2 | Zstandard | ||
| 4 | LZMA | xz | |
| Encryption method | 0 | No encryption | |
| 1 | AES (Rijndael) | 256-bit key | |
| 2 | Camellia | 256-bit key | |
| Cipher mode | 0 | CBC | Cipher Block Chaining |
| 1 | CTR | Counter Mode |
Note:
The information about the key derivation function when encrypting a file.
This chunk appeared after FHED chunk and before FDAT chunk.
If the value of the Encryption method field of FHED 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.
In solid mode archives, the SDAT chunk contains a continuous stream of data representing multiple entries.
Unlike per-entry mode where each entry is composed of discrete FHED through FEND chunks within the archive, the SDAT chunk serializes these chunks together within its own data stream.
The following structural rules apply to the contents of an SDAT chunk:
SDAT chunk MUST contain a sequence of standard entry structures, each beginning with a FHED chunk and ending with a corresponding FEND chunk.SDAT chunk must conform to the same structure, layout, and constraints as defined for individual entries in per-entry mode.cTIM, fPRM, xATR) may appear between FHED and FEND, following the same rules as in regular entry mode.Each entry in solid mode is not stored as an independent top-level chunk sequence in the file but is instead embedded within the data field of the SDAT chunk.
Decoders must parse the contents of SDAT as a logical concatenation of standard entry structures.
The use of solid mode is intended to improve compression efficiency by processing similar files together as a single compression/encryption unit.
Example structure of SDAT content (conceptual):
[ FHED | Ancillary* | FDAT* | FEND ]
[ FHED | Ancillary* | FDAT* | FEND ]
...
The outer SDAT chunk may be followed by additional SDAT chunks if the solid data stream is split. These must be interpreted as a single contiguous logical stream, terminated by the SEND chunk.
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 FHED 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 FHED 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 FHED chunk and before the FEND chunk, it indicates the last accessed datetime of the entry.
| size | description |
|---|---|
| 8byte | Unix timestamp |
Provides the nanosecond portion of the file creation time, to be used in conjunction with the cTIM chunk.
FHED chunk and before the FEND chunk.cTIM is also present.cTIM seconds + (cTNS / 1_000_000_000.0)| Size | Description |
|---|---|
| 4-byte | Unsigned integer (u32), nanoseconds |
Valid values are in the range 0 <= value < 1,000,000,000.
Provides the nanosecond portion of the last modified time, to be used in conjunction with the mTIM chunk.
FHED chunk and before the FEND chunk.mTIM is also present.mTIM seconds + (mTNS / 1_000_000_000.0)| Size | Description |
|---|---|
| 4-byte | Unsigned integer (u32), nanoseconds |
Valid values are in the range 0 <= value < 1,000,000,000.
Provides the nanosecond portion of the last accessed time, to be used in conjunction with the aTIM chunk.
FHED chunk and before the FEND chunk.aTIM is also present.aTIM seconds + (aTNS / 1_000_000_000.0)| Size | Description |
|---|---|
| 4-byte | Unsigned integer (u32), nanoseconds |
Valid values are in the range 0 <= value < 1,000,000,000.
Decoder Notes:
*TNS chunk is present without its corresponding *TIM chunk, it must be ignored.[0, 999_999_999] are invalid and must cause a decoder error.*TNS chunks unless sub-second precision is explicitly needed.File permissions are recorded.
This chunk appeared after FHED 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 FHED 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 in Archive | Multiple in Entry | Optional | Ordering constraints |
|---|---|---|---|---|
| AHED | No | N/A | No | Must be first |
| FHED | Yes | No | Yes | Must start an entry |
| PHSF | Yes | No | Yes | Before FDAT or SDAT if used |
| FDAT | Yes | Yes | Yes | Multiple FDATs must be consecutive |
| FEND | Yes | No | Yes | Must end an entry |
| SHED | Yes | No | Yes | Must start an Solid mode data |
| SDAT | Yes | Yes | Yes | Multiple SDATs must be consecutive |
| SEND | Yes | No | Yes | Must end an Solid mode data |
| ANXT | No | N/A | Yes | |
| AEND | No | N/A | No | Must be last |
Ancillary chunks
| Name | Multiple in Archive | Multiple in Entry | Optional | Ordering constraints |
|---|---|---|---|---|
| cTIM | Yes | No | Yes | Between FHED and FEND |
| mTIM | Yes | No | Yes | Between FHED and FEND |
| aTIM | Yes | No | Yes | Between FHED and FEND |
| cTNS | Yes | No | Yes | Must accompany cTIM, between FHED–FEND |
| mTNS | Yes | No | Yes | Must accompany mTIM, between FHED–FEND |
| aTNS | Yes | No | Yes | Must accompany aTIM, between FHED–FEND |
| fPRM | Yes | No | Yes | Between FHED and FEND |
| xATR | Yes | Yes | Yes | Between FHED and FEND |
Additional public PNA chunk types are defined in the document “Extensions to the PNA 0.0 Specification, Version 0.0.0” [PNA-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 PNA specification maintainers at @Portable-Network-Archive on GitHub.
New public chunks will be registered only if they are of use to others and do not violate the design philosophy of PNA. 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.