Crates.io | ruzstd |
lib.rs | ruzstd |
version | 0.7.3 |
source | src |
created_at | 2019-11-04 10:57:24.512851 |
updated_at | 2024-11-28 10:18:25.148617 |
description | A decoder for the zstd compression format |
homepage | https://github.com/KillingSpark/zstd-rs |
repository | https://github.com/KillingSpark/zstd-rs |
max_upload_size | |
id | 177994 |
size | 311,360 |
A feature-complete decoder for the zstd compression format as defined in: This document.
It is NOT a compressor. I don't plan on implementing that part either, at least not in the near future. (If someone is motivated enough I will of course accept a pull-request!)
This crate might look like it is not active, this is because there isn't really anything to do anymore, unless a bug is found or a new API feature is requested. I will of course respond to and look into issues!
Feature complete on the decoder side. In terms of speed it is still behind the original C implementation which has a rust binding located here.
Actively maintained but no new features currently planned. If you have suggestions please open an issue and I'll consider it.
Measuring with the 'time' utility the original zstd and my decoder both decoding the same enwik9.zst file from aramfs, my decoder is about 3.5 times slower. Enwik9 is highly compressible, for less compressible data (like a ubuntu installation .iso) my decoder comes close to only being 1.4 times slower.
zstd -c -d
dropin replacementThis decoder is pretty much feature complete. If there are any wishes for new APIs or bug reports please file an issue, I will gladly take a look!
Tests take two forms.
Fuzzing has been done with cargo fuzz. Each time it crashes the decoder I fixed the issue and added the offending input as a test. It's checked into the repo in the fuzz/artifacts/fuzz_target_1 directory. Those get tested in the fuzz_regressions.rs test. At the time of writing the fuzzer was able to run for over 12 hours on the random input without finding new crashes. Obviously this doesn't mean there are no bugs but the common ones are probably fixed.
Fuzzing has been done on
Use cargo +nightly fuzz run decode
to run the fuzzer. It is seeded with files created with decodecorpus.
If (when) the fuzzer finds a crash it will be saved to the artifacts dir by the fuzzer. Run cargo test artifacts
to run the artifacts tests.
This will tell you where the decoder panics exactly. If you are able to fix the issue please feel free to do a pull request. If not please still submit the offending input and I will see how to fix it myself.
Additionally to the descriptions and the docs you can have a look at the zstd / zstd_streaming binaries. They showcase how this library can be used.
The easiest is to wrap the io::Read into a StreamingDecoder which itself implements io::Read. It will decode blocks as necessary to fulfill the read requests
let mut f = File::open(path).unwrap();
let mut decoder = StreamingDecoder::new(&mut f).unwrap();
let mut result = Vec::new();
decoder.read_to_end(&mut result).unwrap();
This might be a problem if you are accepting user provided data. Frames can be REALLY big when decoded. If this is the case you should either check how big the frame actually is or use the memory efficient approach described below.
If memory is a concern you can decode frames partially. There are two ways to do this:
Use the StreamingDecoder and use a while loop to fill your buffer (see src/bin/zstd_stream.rs for an example). This is the recommended approach.
For an example see the src/bin/zstd.rs file. Basically you can decode the frame until either a given block count has been decoded or the decodebuffer has reached a certain size. Then you can collect no longer needed bytes from the buffer and do something with them, discard them and resume decoding the frame in a loop until the frame has been decoded completely.
Contributions will be published under the same MIT license as this project. Please make an entry in the Changelog.md file when you make a PR.