in, or (unlikely) the sizein-1 to impose noin, or (unlikely) the sizein
The returned value has a bit set for every check type that is present.
For example, if CRC64 and SHA-256 were used, the return value is
(1 << XZ.CHECK_CRC64)
.
| (1 << XZ.CHECK_SHA256)
blockNumber < 0 or
blockNumber >= getBlockCount().
blockNumber < 0 or
blockNumber >= getBlockCount().
blockNumber < 0 or
blockNumber >= getBlockCount().
blockNumber < 0 or
blockNumber >= getBlockCount().
blockNumber < 0 or
blockNumber >= getBlockCount().
pos < 0 or
pos >= length().
-1in
If len is zero, no bytes are read and 0
is returned. Otherwise this will try to decompress len
bytes of uncompressed data. Less than len bytes may
be read only in the following situations:
len bytes have already been successfully
len
buf
-1 to indicate
in
CorruptedInputException may getin.close().in.close()read is called
Seeking past the end of the stream is possible. In that case
read will return -1 to indicate
the end of the stream.
@param pos new uncompressed read position
@throws XZIOException
if pos is negative, or
if stream has been closed
blockNumber < 0 or
blockNumber >= getBlockCount(),
This supports decompressing concatenated .xz files.
Each .xz file consist of one or more Streams. Each Stream consist of zero
or more Blocks. Each Stream contains an Index of Streams' Blocks.
The Indexes from all Streams are loaded in RAM by a constructor of this
class. A typical .xz file has only one Stream, and parsing its Index will
need only three or four seeks.
To make random access possible, the data in a .xz file must be splitted
into multiple Blocks of reasonable size. Decompression can only start at
a Block boundary. When seeking to an uncompressed position that is not at
a Block boundary, decompression starts at the beginning of the Block and
throws away data until the target position is reached. Thus, smaller Blocks
mean faster seeks to arbitrary uncompressed positions. On the other hand,
smaller Blocks mean worse compression. So one has to make a compromise
between random access speed and compression ratio.
Implementation note: This class uses linear search to locate the correct
Stream from the data structures in RAM. It was the simplest to implement
and should be fine as long as there aren't too many Streams. The correct
Block inside a Stream is located using binary search and thus is fast
even with a huge number of Blocks.
Memory usage
The amount of memory needed for the Indexes is taken into account when
checking the memory usage limit. Each Stream is calculated to need at
least 1 KiB of memory and each Block 16 bytes of memory, rounded up
to the next kibibyte. So unless the file has a huge number of Streams or
Blocks, these don't take significant amount of memory.
Creating random-accessible .xz files
When using {@link XZOutputStream}, a new Block can be started by calling
its {@link XZOutputStream#endBlock() endBlock} method. If you know
that the decompressor will only need to seek to certain uncompressed
positions, it can be a good idea to start a new Block at (some of) these
positions (and only at these positions to get better compression ratio).
liblzma in XZ Utils supports starting a new Block with
LZMA_FULL_FLUSH. XZ Utils 5.1.1alpha added threadedcompression which creates multi-Block .xz files. XZ Utils 5.1.1alpha
also added the option
--block-size=SIZEto the xz commandline tool. XZ Utils 5.1.2alpha added a partial implementation of
--block-list=SIZESwhich allows specifying sizes ofindividual Blocks.
@see SeekableFileInputStream
@see XZInputStream
@see XZOutputStream