GZIP ライターの終了を延期するとデータ損失が発生する
Go では、defer を使用して gzip.Writer を閉じると、予期しない EOF エラーが発生する可能性があります。 zip データからの読み取り。この問題を解決するには、問題の詳細を詳しく調べ、別の解決策を提供しましょう。
問題の理解:
gzip.Writer の Close メソッドは 2 つのタスクを実行します。 : 書き込まれていないデータを基礎となるライターにフラッシュし、GZIP フッターを書き込みます。ただし、提供されているコードでは:
<code class="go">func zipData(originData []byte) ([]byte, error) { // ... defer gw.Close() // ... }</code>
defer ステートメントは、周囲の関数 zipData が返されるまで gw.Close() の実行を遅延させます。したがって、zipData が終了して戻ると、フッターは保存されていないバッファに書き込まれ、返されたバイト配列には含まれません。これにより、圧縮されたデータから読み取ろうとしたときに予期しない EOF エラーが発生します。
代替解決策:
この問題を解決するには、ファイルを返す前にライターを閉じることをお勧めします。 zip データ:
<code class="go">func zipData(originData []byte) ([]byte, error) { // ... if _, err := gw.Write(originData); err != nil { return nil, err } if err := gw.Flush(); err != nil { return nil, err } gw.Close() // ... }</code>
戻る前にライターを明示的に閉じることで、GZIP フッターが保存されたバッファに書き込まれ、返されるバイト配列に確実に含まれるようになります。これにより、予期しない EOF エラーが防止され、圧縮されたデータの整合性が保証されます。
以上がGZIP ライターの終了を延期すると Go でデータ損失が発生するのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。