4
edits
Difference between revisions of "ZIM file format"
Jump to navigation
Jump to search
m
Minor typos
(Enhance explanations around URLs encoding in ZIM / HTML document) |
m (Minor typos) |
||
| (3 intermediate revisions by one other user not shown) | |||
| Line 26: | Line 26: | ||
| clusterCount || integer || 28 || 4 || total number of clusters | | clusterCount || integer || 28 || 4 || total number of clusters | ||
|- | |- | ||
| | | pathPtrPos || integer || 32 || 8 || position of the directory pointerlist ordered by Path | ||
|- | |- | ||
| titlePtrPos || integer || 40 || 8 || position of the directory pointerlist ordered by Title | | titlePtrPos || integer || 40 || 8 || position of the directory pointerlist ordered by Title | ||
| Line 72: | Line 72: | ||
|- | |- | ||
| colspan="2" | 5 || yes || Introduces: | | colspan="2" | 5 || yes || Introduces: | ||
- | - Path index (was only title indexed before) | ||
- MimeList Pos | - MimeList Pos | ||
| Line 113: | Line 113: | ||
|} | |} | ||
== | == Path Pointer List (pathPtrPos) == | ||
The | The Path pointer list is a list of 8 byte offsets to the directory entries. | ||
The directory entries are always ordered by "full" | The directory entries are always ordered by "full" path (<code><namespace><path></code>). Ordering is simply done by comparing the path strings (utf8 encoded) | ||
Since directory entries have variable sizes this is needed for random access. | Since directory entries have variable sizes this is needed for random access. | ||
| Line 123: | Line 123: | ||
! Field Name !! Type !!Offset!!Length!! Description | ! Field Name !! Type !!Offset!!Length!! Description | ||
|- | |- | ||
| <1st | | <1st path> || integer || 0 || 8 || pointer to the directory entry of <1st path> | ||
|- | |- | ||
| <2nd | | <2nd path> || integer || 8 || 8 || pointer to the directory entry of <2nd path> | ||
|- | |- | ||
| <nth | | <nth path> || integer ||(n-1)*8|| 8 || pointer to the directory entry of <nth path> | ||
|- | |- | ||
| ... || integer || ... || 8 || ... | | ... || integer || ... || 8 || ... | ||
|} | |} | ||
Libzim caches directory entries and references the cached entries via the | Libzim caches directory entries and references the cached entries via the path pointers. | ||
== Title Pointer List (titlePtrPos) == | == Title Pointer List (titlePtrPos) == | ||
The title pointer list is a list of entry indices ordered by title (<code><namespace><title></code>). The title pointer list actually points to entries in the | The title pointer list is a list of entry indices ordered by title (<code><namespace><title></code>). The title pointer list actually points to entries in the path pointer list. | ||
Note that the title pointers are only 4 bytes. They are not offsets in the file but entry numbers. | Note that the title pointers are only 4 bytes. They are not offsets in the file but entry numbers. | ||
To get the offset of an entry from the title pointer list, you have to look it up in the | To get the offset of an entry from the title pointer list, you have to look it up in the path pointer list. | ||
{| class="sortable" style="border-width:1px; border-style:solid; border-color:#888888; background-color:#eeeeee; border-collapse:collapse; empty-cells:show" cellspacing="0" cellpadding="4" {{Prettytable}} | {| class="sortable" style="border-width:1px; border-style:solid; border-color:#888888; background-color:#eeeeee; border-collapse:collapse; empty-cells:show" cellspacing="0" cellpadding="4" {{Prettytable}} | ||
! Field Name !! Type !!Offset!!Length!! Description | ! Field Name !! Type !!Offset!!Length!! Description | ||
|- | |- | ||
| <1st Title> || integer || 0 || 4 || pointer to the | | <1st Title> || integer || 0 || 4 || pointer to the path pointer of <1st Title> | ||
|- | |- | ||
| <2nd Title> || integer || 4 || 4 || pointer to the | | <2nd Title> || integer || 4 || 4 || pointer to the path pointer of <2nd Title> | ||
|- | |- | ||
| <nth Title> || integer ||(n-1)*4|| 4 || pointer to the | | <nth Title> || integer ||(n-1)*4|| 4 || pointer to the path pointer of <nth Title> | ||
|- | |- | ||
| ... || integer || ... || 4 || ... | | ... || integer || ... || 4 || ... | ||
|} | |} | ||
The indirection from titles via | The indirection from titles via Paths to directory entries has two reasons: | ||
* the pointer list is only half in size as 4 bytes are enough for each entry | * the pointer list is only half in size as 4 bytes are enough for each entry | ||
* accessing directory entries by title also makes use of cached directory entries which are referenced by the | * accessing directory entries by title also makes use of cached directory entries which are referenced by the path pointers, as implemented in libzim. | ||
== Directory Entries == | == Directory Entries == | ||
| Line 178: | Line 178: | ||
| blob number || integer || 12 || 4 || blob number inside the compressed cluster where the contents are stored | | blob number || integer || 12 || 4 || blob number inside the compressed cluster where the contents are stored | ||
|- | |- | ||
| | | path || string || 16 ||zero terminated|| string with the path as referred in the path pointer list | ||
|- | |- | ||
| title || string || n/a ||zero terminated|| string with an title as | | title || string || n/a ||zero terminated|| string with an title as referred in the Title pointer list or empty; in case it is empty, the path is used as title | ||
|- | |- | ||
| parameter || data || ||see parameter len|| (not used) extra parameters | | parameter || data || ||see parameter len|| (not used) extra parameters | ||
| Line 199: | Line 199: | ||
| redirect index || integer || 8 || 4 || pointer to the directory entry of the redirect target | | redirect index || integer || 8 || 4 || pointer to the directory entry of the redirect target | ||
|- | |- | ||
| | | path || string || 12 ||zero terminated|| string with the path as referred in the path pointer list | ||
|- | |- | ||
| title || string || n/a ||zero terminated|| string with an title as | | title || string || n/a ||zero terminated|| string with an title as referred in the Title pointer list or empty; in case it is empty, the path is used as title | ||
|- | |- | ||
| parameter || data || ||see parameter len|| (not used) extra parameters | | parameter || data || ||see parameter len|| (not used) extra parameters | ||
| Line 276: | Line 276: | ||
== Namespaces == | == Namespaces == | ||
Namespaces separate different types of directory entries - which might have the same title or | Namespaces separate different types of directory entries - which might have the same title or path - stored in the ZIM archive Format. | ||
The new namespace usage put a strong semantics on the namespaces. The libzim uses this semantics and provide different kind of API to access the different kind of entries. | The new namespace usage put a strong semantics on the namespaces. The libzim uses this semantics and provide different kind of API to access the different kind of entries. | ||
| Line 296: | Line 296: | ||
|} | |} | ||
== | == Paths == | ||
=== | === Path Encoding in the ZIM === | ||
The | The Path in the PathPointerlist are encoded in utf-8 and are '''not''' url encoded. | ||
For instance, if you store in the ZIM an HTML document with a href pointing to `characters%20%C3%A9ncoding.html`, you have to store the corresponding ZIM entry at `characters éncoding.html` | For instance, if you store in the ZIM an HTML document with a href pointing to `characters%20%C3%A9ncoding.html`, you have to store the corresponding ZIM entry at `characters éncoding.html` Path. | ||
Or if you want to store a ZIM entry at `index.html?param=value`, the HTML document pointing to it will have to use the `index.html%3Fparam%3Dvalue` href. | Or if you want to store a ZIM entry at `index.html?param=value`, the HTML document pointing to it will have to use the `index.html%3Fparam%3Dvalue` href. | ||
| Line 307: | Line 307: | ||
The reason behind it is that libzim is agnostic of which kind of content and which kind of readers will be used. Everything around URL encoding is purely linked to HTTP / HTML / Web standards. | The reason behind it is that libzim is agnostic of which kind of content and which kind of readers will be used. Everything around URL encoding is purely linked to HTTP / HTML / Web standards. | ||
When serving web content (which is usually the case), some readers process the requests and already do the url decoding internally, whereas most readers will handle the | When serving web content (which is usually the case), some readers process the requests and already do the url decoding internally, whereas most readers will handle the paths directly. | ||
The same applies to querystring which might be absorbed by some webservers and not passed to the libzim. | The same applies to querystring which might be absorbed by some webservers and not passed to the libzim. | ||
| Line 328: | Line 328: | ||
== Encodings == | == Encodings == | ||
=== Character Encoding === | === Character Encoding === | ||
The standard encoding for ZIM archive content is UTF-8. So both article data and | The standard encoding for ZIM archive content is UTF-8. So both article data and Path should be handled accordingly. | ||
=== Integer Encoding === | === Integer Encoding === | ||
| Line 339: | Line 339: | ||
== Split ZIM files == | == Split ZIM files == | ||
ZIM archives can be split in multiple files. This is necessary to be able to store big (over 4GB for example) ZIM archives to limited file systems (like FAT32). That said, the files can be of any size, but the naming is really important. The ZIM files should be named like following (the file name extensions matter): ''foobar.zimaa, foobar.zimab, foobar.zimac''... | ZIM archives can be split in multiple files. This is necessary to be able to store big (over 4GB for example) ZIM archives to limited file systems (like FAT32). That said, the files can be of any size, but the naming is really important. The ZIM files should be named like following (the file name extensions matter): ''foobar.zimaa, foobar.zimab, foobar.zimac''... | ||
== Other == | |||
<code>pathPtrPos</code> was initially called <code>urlPtrPos</code> (and <code>path</code> in dirent structure was called <code>url</code>). In April 2024, we changed the wording from <code>url</code> to <code>path</code> as it better conveys the fact that we are storing a path for the entry and not a full url (with scheme, host...). Note that this is just a wording change and the semantic has not changed at all. Implementations do not need to change anything (except a potential renaming of variables to better follow the spec). | |||
== See also == | == See also == | ||