go 建议：归档/压缩文件：扩展countWriter的可见性,

zlhcx6iw 于 6个月前发布在 Go

关注(0)|答案(2)|浏览(53)

提案详情

我们目前正在使用一个自定义构建的zip写入器来"刷新"zip头部和EOCD页脚，这在90%的情况下看起来与writer.go中的相同。这个自定义zip写入器的用途是在不需要实际文件数据的情况下"准备一个zip文件",从而允许zip文件的流式传输。
我们目前无法使用标准的golang zip库，因为我们无法手动将countWriter的位置向前移动。理想情况下，我们应该能够在不受限于预先写入数据的情况下设置w.cw.count(因此不幸的是，SetOffset()不能被使用)。
这里的建议是添加以下辅助函数或类似的功能，以便在不受SetOffset()限制的情况下传递w.cw.count变量，并使用以下公共函数读取其值：

// pseudo code:
func (w *Writer) AdvanceOffset(n int64) {
	w.cw.count += n
}

func (w *Writer) GetOffset() int64 {
	w.cw.count
}

这将使标准golang zip库对我们的使用场景有用。我们将使用现有的Flush()函数来获取中间头部和EOCD页脚。

来源：https://github.com/golang/go/issues/65569

2条答案

按热度按时间

jyztefdp1#

这似乎是一个非常特殊的目的。我很难想象其他人会如何使用这个功能。它真的值得添加到标准库中吗？
在我看来，你可以通过调用 Write 方法并传入适当大小的切片来增加偏移量。如果需要，底层写入器可以丢弃数据。

赞(0）回复(0）举报 6个月前

eoigrqb62#

感谢快速回复！
在我看来，你可以通过调用具有适当大小的切片的Write方法来增加偏移量。
是的，这也可以用来解决这个特定的用例。缺点是，在zip元素之间压缩的文件(由于没有更好的描述)在我们的具体情况下可能会变得相当大，在某些情况下我们很容易谈论> 500 GB。举一个极端但并不罕见的例子，为1 TiB文件做这项工作将导致以下代码片段：

package main

import (
	"archive/zip"
	"bytes"
	"fmt"
	"time"
)

func main() {
	fileSize := uint64(1024 * 1024 * 1024 * 1024)
	io := new(bytes.Buffer)
	zipWriter := zip.NewWriter(io)
	w, err := zipWriter.CreateHeader(&zip.FileHeader{
		Name:               "test.mov",
		Modified:           time.Now(),
		CRC32:              25,
		CompressedSize64:   fileSize,
		UncompressedSize64: fileSize,
	})
	if err != nil {
		panic(err)
	}
	// Flush out the header:
	zipWriter.Flush()
	fmt.Printf("Header: %x\n", io.Bytes())
	io.Reset()
	// Flush out the bytes:
	w.Write(make([]byte, fileSize))
	zipWriter.Flush()
	fmt.Printf("Flushed: %d\n", len(io.Bytes()))
	io.Reset()
	zipWriter.Close()
	fmt.Printf("EOCD footer: %x\n", io.Bytes())
}

这非常慢且内存密集。不必这样做：

w.Write(make([]byte, fileSize))

...会使我们的生活轻松很多😅。

赞(0）回复(0）举报 6个月前

我来回答

go 建议：归档/压缩文件：扩展countWriter的可见性,

提案详情

2条答案

相关问题

热门标签

最新问答