Go version
go version go1.25.5 windows/amd64
Output of go env in your module/workspace:
set AR=ar
set CC=gcc
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_ENABLED=1
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set CXX=g++
set GCCGO=gccgo
set GO111MODULE=
set GOAMD64=v1
set GOARCH=amd64
set GOAUTH=netrc
set GOBIN=
set GOCACHE=C:\Users\gopher\AppData\Local\go-build
set GOCACHEPROG=
set GODEBUG=
set GOENV=C:\Users\gopher\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFIPS140=off
set GOFLAGS=
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\gopher\AppData\Local\Temp\go-build2553874378=/tmp/go-build -gno-record-gcc-switches
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMOD=C:\go\src\issues\zip_issue\go.mod
set GOMODCACHE=C:\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\etc\go1.25.5.windows-amd64\go
set GOSUMDB=sum.golang.org
set GOTELEMETRY=local
set GOTELEMETRYDIR=C:\Users\gopher\AppData\Roaming\go\telemetry
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=C:\etc\go1.25.5.windows-amd64\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.25.5
set GOWORK=
set PKG_CONFIG=pkg-config
What did you do?
Created a ZIP archive containing an entry larger than 4GB using excelize v2.9.0 and attempted to open it with Microsoft Excel:
package main
import (
"fmt"
"strings"
"github.com/xuri/excelize/v2"
)
func main() {
f := excelize.NewFile()
sw, err := f.NewStreamWriter("Sheet1")
if err != nil {
fmt.Println(err)
return
}
for r := range 131 {
rowData := make([]interface{}, 1000)
for c := range 1000 {
rowData[c] = strings.Repeat("c", excelize.TotalCellChars)
}
cell, err := excelize.CoordinatesToCellName(1, r+1)
if err != nil {
fmt.Println(err)
return
}
if err := sw.SetRow(cell, rowData); err != nil {
fmt.Println(err)
return
}
}
if err := sw.Flush(); err != nil {
fmt.Println(err)
return
}
if err := f.SaveAs("TestZip64.xlsx"); err != nil {
fmt.Println(err)
return
}
if err := f.Close(); err != nil {
fmt.Println(err)
}
}What did you see happen?
Microsoft Excel reports the generated workbook "TestZip64.xlsx" is corrupted and cannot be opened. The root cause for this issue was when creating ZIP64 entries (files>4GB), the archive/zip package creates a version mismatch:
| Location |
Version |
Value |
| Local File Header |
ReaderVersion |
20 (ZIP 2.0) |
| Central Directory |
ReaderVersion |
45 (ZIP64 4.5) |
What did you expect to see?
Application using archive/zip to create files > 4GB that can be read by strict ZIP validators.
According to the PKZIP APPNOTE specification, ZIP64 format requires version 4.5 in both headers. The current implementation only updates ReaderVersion to 45 in the Central Directory (in fileWriter.close()), but the Local File Header is written earlier with version 20.
Strict ZIP readers like Microsoft Excel validate this consistency and reject files with mismatched versions. We added a patch function writeZip64LFH to resolve this since excelize v2.9.1. I will create a proposual CL to address this issue in the zip library. Set the ZIP specification version to 4.5 in the Local File Header if ZIP64 is used anywhere with this ZIP entry (Central Directory File Header or Data Descriptor).
Go version
go version go1.25.5 windows/amd64
Output of
go envin your module/workspace:What did you do?
Created a ZIP archive containing an entry larger than 4GB using excelize v2.9.0 and attempted to open it with Microsoft Excel:
What did you see happen?
Microsoft Excel reports the generated workbook "TestZip64.xlsx" is corrupted and cannot be opened. The root cause for this issue was when creating ZIP64 entries (files>4GB), the
archive/zippackage creates a version mismatch:What did you expect to see?
Application using
archive/zipto create files > 4GB that can be read by strict ZIP validators.According to the PKZIP APPNOTE specification, ZIP64 format requires version 4.5 in both headers. The current implementation only updates
ReaderVersionto 45 in the Central Directory (infileWriter.close()), but the Local File Header is written earlier with version 20.Strict ZIP readers like Microsoft Excel validate this consistency and reject files with mismatched versions. We added a patch function
writeZip64LFHto resolve this since excelize v2.9.1. I will create a proposual CL to address this issue in the zip library. Set the ZIP specification version to 4.5 in the Local File Header if ZIP64 is used anywhere with this ZIP entry (Central Directory File Header or Data Descriptor).