binary-data-catalogue

JPWS Binary Data Catalog

JPWS Binary Data Catalog, Version 1.2, Description (12.09.2016)
This format, stored in record field 66, was introduced with JPasswords 0-8-0 and follows the guidelines of the IFF data format definition by Electronic Arts. JPWS does not seek data interchange on field 66 but this may change in the future. The language used for the definition is a variant of the Backus-Naur-Form , the JPWS Data-Definition-Language. The following definition breaks down the data format into character literals and a presupposed understanding of "<byte>" as atomic 8-bit data constituent.</byte>

<catalog> := 'CAT ' <length> {<FORM-element>}
<FORM-element> := <rear> | <comp>
<comp> := 'FORM' <length> 'COMP' [<ZIP-data>]
<rear> := 'FORM' <length> 'REAR' {<rear-chunk>}

<rear-chunk> := <chunk-type> <length> <chunk-name> [<chunk-data>]
<chunk-type> := 'PROP' | 'PTEX' | 'BLOB' | 'JPEG' | 'UNIT'
<chunk-name> := <byte>:4 -- random binary
<chunk-data> := <binary-data>

<length> := <byte>:4 -- signed integer in BIG-ENDIAN (MSB first)
<ZIP-data> := <binary-data>
<binary-data> := {<byte>}

---

Annotations + Semantic Rules:

1. <byte> : the bit-order of a Byte is unspecified by this format definition. The bit-order normally does not require attention on the program level of computer systems.</byte>
2. <length> : a 4 byte signed integer value in BIG-ENDIAN byte order (most significant first)</length>
3. <catalog> : <length> denotes length in bytes of <catalog> minus 8.</catalog></length></catalog>
4. <comp> : compressed FORM data; <length> denotes length in bytes of <comp> minus 8;
   length of <zip-data> == <length> minus 4. </length></zip-data></comp></length></comp>
5. <zip-data> : contains standard ZIP compression data translated from a <form-element>.</form-element></zip-data>
6. <rear> : record archive data, a collection of archive-chunks; <length> denotes length in
   bytes of <rear> minus 8.</rear></length></rear>
7. <rear-chunk>: <length> denotes length in bytes of <rear-chunk> minus 8; <chunk-name>
   may appear only once with type PROP and only once within all other types.</chunk-name></rear-chunk></length></rear-chunk>
8. <chunk-type> : 'PTEX' = plain text, 'PROP' = properties map (text), 'BLOB' = binary large object, 'JPEG' = JPEG image data, 'UNIT' = properties map (text) as a document script.</chunk-type>
9. <chunk-name>: the chunk name has to be unique for a data entry in the catalogue; it is recommended to use random byte values. A data entry can have two parts in the catalogue: PROP and one of the rest of the types. This is saying that PROP is an additional type to any occurring other data type; it represents a Properties map (text) related to a data entry. There is no formal rule about the conjunction of both parts, i.e. any one can stand alone although an alone-standing PROP does not define or declare a typed data entry and hence may be ignored in a reading interface. The type UNIT is a properties map by itself and does not relate to a PROP entry, hence a PROP entry related to a UNIT is correct but meaningless.</chunk-name>
10. <chunk-data>: for the types PROP, PTEX and UNIT this is an UTF-8 serialisation of a text string;
    for type JPEG this is a valid JPEG compressed image format; for BLOB this is a format free block of binary data (opaque).</chunk-data>

---

Sources: IFF Format (Electronic Arts), https://en.wikipedia.org/wiki/Interchange_File_Format
"EA IFF 85" Standard for Interchange Format Files, http://www.martinreddy.net/gfx/2d/IFF.txt