- Specification URI:
- https://zarr-specs.readthedocs.io/en/latest/v3/stores/zipfile/v1.0.html
- Corresponding ZEP:
- ZEP0001 — Zarr specification version 3
- Issue tracking:
- GitHub issues
- Suggest an edit for this spec:
- GitHub editor
Copyright 2024-Present Zarr core development team. This work is licensed under a Creative Commons Attribution 3.0 Unported License.
The ZIP file store provides a way to store Zarr arrays and metadata in a single, compressed ZIP archive. This specification defines the organization and structure of the ZIP file to ensure compatibility across implementations.
This is a working draft.
The ZIP file store is designed for simplicity and easy conversion to and from the filesystem stores. The ability to ZIP a file system store using standard command line tools (e.g. zip) is a key virtue of the design below.
Conformance requirements are expressed with a combination of descriptive assertions and [RFC2119] terminology. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in [RFC2119]. However, for readability, these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. Examples in this specification are introduced with the words "for example".
Here we consider a ZIP file to be a standard ZIP archive, where:
- Each key has a name (sequence of characters) and contents (sequence of bytes).
- Each directory has a name (sequence of characters) and children (set of zero or more files and/or directories).
- Each file or directory can be addressed by a path, comprised of its name and the names of all ancestor directories, which uniquely identifies it within the file system.
… and where the following native operations are supported:
- Create a file.
- Write the contents of a file.
- Read the contents of a file.
- Create a directory.
- List the children of a directory, returning the name and type (file or directory) of each child.
… Note that the following operations may not be supported by ZIP file stores:
- Delete a file.
- Delete a directory.
The Zarr store interface is defined in terms of keys and values, where a key is a sequence of characters and a value is a sequence of bytes. A ZIP file store represents keys as paths within a ZIP archive. No further translation of keys is required.
The section below defines an implementation of the Zarr :ref:`abstract-store-interface` in terms of the native operations of this storage system.
get(key) -> value: Read and return the contents of the object at within the archive at pathkey.set(key, value): Writevalueas the contents of the file at into the archive at path ``key .list(): List all keys in the archive.list_prefix(prefix): List all keys within the archive that begin withprefix.list_dir(prefix): List all keys within a directory within the archive.
The canonical URI format for this store follows the file URI scheme of the archive itself, as defined in [RFC8089]. For a Windows base directory path "c:\my data.zip" the canonical URI would be "file:///c:/my%20data.zip", for a Posix base directory "/my data.zip" it would be"file:///my%20data.zip".
The following limitations for this store are know:
- ZIP file stores may not implement delete or rename operations
| [RFC2119] | (1, 2) S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119 |
| [RFC8089] | M. Kerwin. The "file" URI Scheme. February 2017. Proposed Standard. URL: https://tools.ietf.org/html/rfc8089 |
@@TODO