zlibを使わなくてはならなくなった。
名前はよく聞く・・・。
リンクするときに「-lz」と短く済むので、印象に残っている。
よく使われているので、使い方も難しくは無いだろう。
WSLのUbuntu 16.04で試す。
sudo apt install zlib1g-dev
zlibのマニュアルは、こちら。
zlib 1.2.11 Manual https://zlib.net/manual.html
ただ・・・圧縮と解凍さえ分かればよいので、使い方だけ見ておこう。
やりたいのは、ファイルではなくRAMで持っているデータなので、そこは読み替えていく。
zlib Usage Example https://zlib.net/zlib_how.html
https://zlib.net/zpipe.c
まず、テストデータを作ろう。
xxdというコマンドを使うと、ファイルをC言語の配列形式にしてくれる。
便利だ・・・。
xxd -i hirokuma.png > hirokuma.h
Exampleでは、CHUNKサイズのバッファin[]とout[]を準備している。
def()が圧縮、inf()が展開。
どちらも、二重のdo-while()になっている。
まず、def()から。
外側のdo-while()は、ファイルをCHUNKずつ読み取るためのループ。
内側のdo-while()は、deflate()を実行して、avail_outが0になっている間はループする。
「keeps calling deflate() until it is done producing output」と書いてあるので、avail_outが0ということは処理が継続しているという意味なのだろう。
圧縮中、deflate()の引数はZ_NO_FLUSHで、最後だけZ_FINISHにする。
ストリーミングで圧縮するから、ある程度データが揃うまで吐き出さないのだろうね。
簡単なサンプルを作った。
圧縮のみで、圧縮しているデータは、うちのアイコン(PNG)だ。
PNG画像もzlibで圧縮されているようだが、気にするまい。
https://gist.github.com/hirokuma/0f038adc04c1ec38ba6c01f8b2db4fb5/4b920d2c12d7893c23a93343cd74d116de731077
まあ、データは何でもよいのだが、内側のdo-while()がどういう周り方をするのかが気になった。
$ gcc -o tst zlib_comp.c -lz
$ ./tst
p=0x6010a0
avail_out=1022
p=0x6014a0
p=0x6014a0
avail_out=1024
p=0x6018a0
p=0x6018a0
avail_out=1024
p=0x601ca0
p=0x601ca0
avail_out=1024
p=0x6020a0
p=0x6020a0
avail_out=1024
p=0x6024a0
p=0x6024a0
avail_out=1024
p=0x6028a0
p=0x6028a0
avail_out=1024
p=0x602ca0
p=0x602ca0
avail_out=0
avail_out=0
avail_out=0
avail_out=0
avail_out=0
avail_out=0
avail_out=0
avail_out=103
p=0x603030
next_inは自動的に進むようだから、全データがRAM上にあるなら、初期化だけしておけばよさそうだ。
内側のループが回ったのは、最後だけだ。
何かルールがあるのだろうか？
もし最後だけなら、通常は内側のdo-while無しでもよいのかもしれんが、これだけじゃわからんな。
というわけで、マニュアルを見てみよう。
けっこう、見づらい・・・。
https://zlib.net/manual.html#Basic
If deflate returns with avail_out == 0, this function must be called again with the same value of the flush parameter and more output space (updated avail_out), until the flush is complete (deflate returns with non-zero avail_out).
In the case of a Z_FULL_FLUSH or Z_SYNC_FLUSH, make sure that avail_out is greater than six to avoid repeated flush markers due to avail_out == 0 on return.
avail_outが0の場合は、flushオプションを同じ状態で呼び続けなくてはならん。
ということは、Z_FINISHの場合だけではないということか。
"more output space (updated avail_out)"と書いてあるが、サンプルではavail_outを再設定しているだけで、out[]のサイズは同じだな。
そもそも、fwirte()するサイズは「CHUNK - strm.avail_out」だから、8KBくらいのデータでは外側のループで回っているときはout[]がほぼ出力されず、最後にZ_FINISHしたときに書き込まれていることになる。
flushオプションもいくつか種類があるようだが、圧縮したデータそのものがほしい場合はサンプル通りにやっておけばよいんじゃ無かろうかね。
展開する方も、同じようにやった。
https://gist.github.com/hirokuma/0f038adc04c1ec38ba6c01f8b2db4fb5/2ae53cdeb15bc6e79ed4c65474040a3327b5dbad
$ ./tst
exec: comp
retval=1
exec: decomp
retval=-5
retval=-5
retval=-5
retval=-5
retval=-5
retval=-5
retval=1
追加したのは、decomp()。
-5は、Z_BUF_ERROR。
サンプルではエラー処理していないし、最後に1(Z_STREAM_END)が出るところから見ると、普通なんだろう。
Z_BUF_ERROR if no progress was possible or if there was not enough room in the output buffer when Z_FINISH is used.
Note that Z_BUF_ERROR is not fatal, and inflate() can be called again with more input and more output space to continue decompressing.
APIに何があるのか読みづらかったので、こちらの解説記事の方がよさそう。
http://s-yata.jp/docs/zlib/
compress()なんてあったのか・・・。
https://zlib.net/manual.html#Utility
