zlibについてよくある質問 ここに質問がない場合は、zlibホームページ https://zlib.net/を確認してください。より新しい情報があるかもしれません。 最新版のzlib FAQはhttps://zlib.net/zlib_faq.htmlにあります。

はい。zlibは日付を扱いません。

zlibのソースは、変更せずにコンパイルしてDLLを作成できます。 zlib配布物内のwin32/DLL_FAQ.txtを参照してください。

次を参照してください： * https://zlib.net/nelson/ * zlib配布物内のwin32/DLL_FAQ.txt

compress()を呼び出す前に、圧縮データ用バッファーの長さが0ではなく、 そのバッファーの利用可能なサイズと等しくなっていることを確認してください。 Visual Basicでは、この引数を値渡し（「as long」）ではなく、 参照渡し（「as any」）にしていることを確認してください。

呼び出す前に、avail_inとavail_outが0でないことを確認してください。 flush引数をZ_FINISHに設定するときは、保留中の入力をすべて処理できるだけの avail_outがあることも確認してください。Z_BUF_ERRORは致命的ではありません。 入力や出力領域を増やして、deflate()またはinflate()を再度呼び出せます。 strm.avail_outが0になって返ったとき、まだ出力が保留されているかどうかは判断できないため、 使い方によってはZ_BUF_ERRORを避けられない場合もあります。 詳しい注釈付きの例はhttps://zlib.net/zlib_how.htmlを参照してください。

zlib.hにあります。zlibの使用例はtest/example.cとtest/minigzip.cにあり、 examples/にも別の例があります。

zlibを、とても小さく単純なパッケージのままにしておきたいからです。 zlibはかなり移植性が高く、多くの設定を必要としません。

こうした問題の多くは、zlibの使い方が正しくないことが原因です。 小さなプログラムで問題を再現し、そのソースを[email protected]へ送ってください。 事前の合意なく数メガバイトものデータファイルを送らないでください。

「make test」で、たとえば次のように表示される場合： example.o(.text+0x154): undefined reference to `gzputc' /usr/lib、/usr/local/lib、/usr/X11R6/libに古いlibz.*ファイルがないことを確認してください。 古い版を削除してから「make install」を実行してください。

zlib配布物内のcontrib/delphiディレクトリを参照してください。

zlib単体では扱えません。zlib配布物内のcontrib/minizipディレクトリを参照してください。

残念ながら扱えません。uncompressまたはgunzipを子プロセスとして起動するか、 uncompressのコードを自分で適合させる必要があります。

Unixでは、デフォルトで共有ライブラリと静的ライブラリをビルドします。したがって： make distclean ./configure make

上記の後に、次を実行します： make install ただし、多くのUnixにはzlibの共有ライブラリがすでにインストールされています。 zlibの共有版をコンパイルし、インストールしようとする前に、すでにあるか確認するとよいでしょう。 #include <zlib.h>ができれば、そこにあります。-lzオプションでおそらくリンクできます。 版はzlib.hの先頭、またはzlib.hに定義されたZLIB_VERSIONで確認できます。

私たちはOttoPDFの著作者ではありません。実際の著作者はOttoPDFのウェブサイトに記載されています： Joel Hainley、[email protected]。

はい。https://www.pdflib.com/を参照してください。PDFフォームを変更する場合は、 https://sourceforge.net/projects/acroformtool/を参照してください。

Solaris 2.6にzlib 1.1.4をインストールした後、zlibを使うアプリケーションを実行すると、 次のようなエラーが発生します： ld.so.1: rpm: fatal: relocation error: file /usr/local/lib/libz.so: symbol __register_frame_info: referenced symbol not found __register_frame_infoはzlibの一部ではなく、Cコンパイラー（ccまたはgcc）が生成するシンボルです。 この問題があるzlib使用アプリケーションを再コンパイルしなければなりません。 この問題はSolarisに固有です。Solaris版のzlibとzlib使用アプリケーションについては、 http://www.sunfreeware.comを参照してください。

compressとdeflate関数が生成するのはzlib形式のデータで、gzip形式とは異なり、互換性がありません。 一方、zlibのgz*関数はgzip形式を使用します。zlib形式とgzip形式は内部では同じ圧縮データ形式を使いますが、 圧縮データの前後に付くヘッダーとトレーラーが異なります。

gzip形式は、単一のファイルの名前や最終更新日などのディレクトリ情報を保持するために設計されました。 一方、zlib形式はメモリ上や通信チャネルでの用途向けに設計され、ヘッダーとトレーラーがはるかに小さく、 gzipより高速な整合性検査を使います。

deflateInit2()を使えば、deflateにzlib形式ではなくgzip形式を書き出すよう要求できます。 inflateInit2()を使えば、inflateにgzip形式を展開するよう要求することもできます。 詳細はzlib.hを読んでください。

はい。ただし、zlibが使うライブラリルーチンと、アプリケーションが提供するメモリ確保ルーチンも、 スレッドセーフでなければなりません。zlibのgz*関数はstdioのルーチンを使用し、 zlibの大半の関数はデフォルトでライブラリのメモリ確保ルーチンを使用します。 zlibの*Init*関数では、アプリケーション独自のメモリ確保ルーチンを提供できます。 アトミック操作がないシステム（C11より前など）で、デフォルトではないBUILDFIXEDまたは DYNAMIC_CRC_TABLEを定義すると、inflate()とcrc32()はスレッドセーフではなくなります。 もちろん、同じzlibまたはgzipストリームを一度に操作するのは1つのスレッドだけにしてください。

はい。zlib.hのライセンスを読んでください。

いいえ。zlib.hのライセンスを読んでください。

zlib.hの#defineであるZLIB_VERSIONとZLIB_VERNUMを変更する必要があります。 特に、最後の版番号を「f」に変更し、ZLIB_VERSIONに識別文字列を付けるべきです。 x.x.x.fという版番号は、zlibの保守担当者以外による改変のために予約されています。 たとえば、改変元のzlibが「1.2.3.4」であれば、zlib.hでZLIB_VERNUMを0x123fに、 ZLIB_VERSIONを「1.2.3.f-zachary-mods-v3」のように変更するべきです。 deflate.cとinftrees.cの版文字列も更新できます。 改変したソースを配布する場合は、zlib.h、ChangeLog、READMEに、変更の出所と内容、 変更日も記載するべきです。出所には少なくとも氏名（または会社名）と、 ライブラリの支援や問題について連絡するためのメールアドレスを含めるべきです。 コンパイル済みのzlibライブラリをzlib.hとzconf.hとともに配布する場合も、 ソースの配布に当たります。そのため、ソース全体を配布するときと同様に、 ZLIB_VERSIONとZLIB_VERNUMを変更し、zlib.hに変更の出所と内容を記載するべきです。

どちらもできます。

はい。64ビットマシンでテスト済みで、どのデータ型についても長さが32ビットに制限されることには依存しません。 問題があれば、完全な問題報告を[email protected]へ送ってください。

いいえ。PKWare DCLは、PKZIPやzlibとはまったく異なる圧縮データ形式を使用します。 ただし、問題の解決策として使える可能性があるので、zlibのcontrib/blastディレクトリを見てください。

準備なしではできません。圧縮中に定期的にZ_FULL_FLUSHを使い、その時点の保留データを すべて確実に書き出し、その位置の索引を保持しておけば、その位置から展開を開始できます。 ただし、圧縮率が大きく悪化することがあるため、Z_FULL_FLUSHを頻繁に使いすぎないよう注意が必要です。 別の方法として、deflateストリームを一度走査して索引を生成し、それをランダムアクセスに使うこともできます。 examples/zran.cを参照してください。

過去には動作しましたが、最近の実績は聞いていません。MVSに移植して動作したzlib 1.1.4がありましたが、 そのリンクはもう使えません。これらのOSで最近zlibを使って成功した例をご存じなら、教えてください。 ありがとうございます。

まずRFC 1951を読んでください。次に、答えは「はい」です。zlibのcontrib/puffディレクトリを見てください。

私たちが知る限りでは、侵害していません。実際、それが当初zlibを作る目的のすべてでした。 詳しい情報は次を参照してください： https://web.archive.org/web/20180729212847/http://www.gzip.org/#faq11

はい。inflate()とdeflate()は、どれだけの量のデータでも正しく処理します。 inflate()またはdeflate()の各呼び出しで扱う入力・出力のチャンクは、 コンパイラーの「unsigned int」型に格納できる最大値に制限されますが、チャンクの数に制限はありません。 ただし、strm.total_inとstrm_total_outのカウンターは4 GBに制限される場合があります。 これらは便宜のために提供され、inflate()やdeflate()の内部では使いません。 アプリケーションは、inflate()またはdeflate()の各呼び出しの後に更新する独自のカウンターを 簡単に設けて、4 GBを超えて数えることができます。 compress()とuncompress()は1回の呼び出しで処理するため、4 GBに制限される場合があります。 gzseek()とgztell()も、zlibのコンパイル方法によっては4 GBに制限される場合があります。 zlib.hにあるzlibCompileFlags()関数を参照してください。 上で「場合があります」を何度も使ったのは、4 GBの制限があるのはコンパイラーの「long」型が 32ビットの場合だけだからです。「long」型が64ビットであれば、上限は16エクサバイトです。

私たちが把握している唯一のものは、gzprintf()にある可能性です。 zlibがsprintf()またはvsprintf()を使うようにコンパイルされている場合 （そのためにはZLIB_INSECUREを定義する必要があります）、 gzprintf()の呼び出し側が出力を8K以内に収めることを保証する以外には、 8Kの文字列領域（またはgzbuffer()で設定した別の値）のバッファーオーバーフローを防ぐ手段がありません。 一方、通常そうあるべきようにsnprintf()またはvsnprintf()を使ってコンパイルされていれば、脆弱性はありません。 ./configureスクリプトは、gzprintf()が安全でないsprintf()の変種を使う場合、警告を表示します。 また、zlibCompileFlags()関数は、gzprintf()が使うsprintf()の種類に関する情報を返します。 snprintf()やvsnprintf()がなく、必要であれば、ここにあるstb_sprintf.hに移植性の高い実装があります： https://github.com/nothings/stb zlibの最新版を使うべきであることに注意してください。1.1.3以前の版には二重解放の脆弱性があり、 1.2.1と1.2.2では不正な圧縮データの展開時にアクセス例外が発生していました。

おそらく、必要なのはJavaからzlibを使うことでしょう。zlibはすでにJava SDKの java.util.zipパッケージに含まれています。本当にJava言語で書かれたzlibが必要であれば、 zlibホームページでリンクを探してください：https://zlib.net/。

何年も前に、世界中のすべてのコンパイラーで警告を避けようとするのをやめました。 時間の無駄になり、一部のコンパイラーはまったくばかげたうえに互いに矛盾していたからです。 今では、コードが常に動作することだけを確認しています。

いいえ。性能のために意図して行っており、deflateの出力には影響しません。 これが最近報告されるようになったのは、zlib 1.2.xがデフォルトのメモリ確保にmalloc()を使う一方、 以前の版は確保したメモリを0で埋めるcalloc()を使っていたためです。 コードは正しかったのですが、1.2.4以降では、これらの検査ツールが反応しないよう変更しました。

おそらく読めません。さまざまな形式と関連ソフトウェアへの案内は、comp.compression FAQを見てください。

zlibは暗号化に対応していません。元のPKZIPの暗号化は非常に弱く、 自由に入手できるプログラムで破ることができます。強い暗号化を使うには、 すでにzlibによる圧縮を含むGnuPG（https://www.gnupg.org/）を使ってください。 PKZIPと互換性のある「暗号化」については、https://infozip.sourceforge.net/を見てください。

「gzip」はgzip形式、「deflate」はzlib形式です。生のdeflate圧縮データ形式との混同を避けるため、 後者を「zlib」と呼ぶべきだったのでしょう。HTTP 1.1のRFC 2616は「deflate」転送エンコーディングについて RFC 1950のzlib仕様を正しく参照していますが、サーバーやブラウザーが、特にMicrosoftのものが、 RFC 1951のdeflate仕様に従った生のdeflateデータを誤って生成したり期待したりするとの報告がありました。 そのため、zlib形式の「deflate」転送エンコーディングの方が効率的な方法であり （実際、まさにそのためにzlib形式を設計しました）、それでもHTTP 1.1の著作者による 不幸な命名のため、「gzip」転送エンコーディングを使う方がおそらく信頼できます。 結論：HTTP 1.1のエンコーディングにはgzip形式を使ってください。

いいえ。PKWareは以前の圧縮形式のように文書化していないため、この形式を独自仕様のままにすることに 決めたようです。いずれにしても、より新しい他の手法と比べて圧縮率の改善はとても小さく、 実装する労力に見合いません。

zlibにはzip関数はありません。おそらく、zlibのcontribディレクトリにあるGiles Vollantのminizipを 使っているのでしょう。それはzlibの一部ではありません。実際、contrib内のものは何もzlibの一部ではありません。 そこにあるファイルはzlibの著作者によるサポートの対象外です。 助けが必要な場合は、それぞれの提供物の著作者へ連絡しなければなりません。

いいえ。contribのファイルはzlibの一部ではありません。他の著作者が提供し、 利用者の便宜のためにzlib配布物に含めています。contribの各項目にはそれぞれのライセンスがあります。

zlibは輸出規制の対象ではなく、EAR99に分類されます。

いいえ。お帰りください。しっしっ。