Lỗi thêm byte khi giải nén tệp

Khi tôi nhập unzip ../founation-latest.zip, nó xuất kết quả này:

cảnh báo [../foundation-latest.zip]: 248 byte bổ sung khi bắt đầu hoặc trong zipfile (cố gắng xử lý bằng mọi cách)

Tập tin là 138KB. Nó giải nén chính xác, nhưng tại sao tôi lại gặp lỗi này?

Vấn đề của tôi là vì tôi đã cố gắng sử dụng "giải nén" trên MAC OSX mà không thể xử lý những thứ được nén bằng PKZIP.

Tôi đã có thể brew install p7zipvà giải nén bằng lệnh 7za x some_file.zip.

Ban đầu tôi đã tìm thấy giải pháp trong bài viết này: Need-pk-compat-v4-5-can-do-v2-1

Tôi tìm thấy chủ đề này có một vấn đề tương tự. Báo cáo lỗi có tiêu đề: giải nén không thành công trên 5,4 GB ZIP với "byte bổ sung khi bắt đầu hoặc trong zipfile" . Một trong những sửa lỗi được đề xuất là sử dụng lệnh này trên .ziptệp.

$ zip -FFv foo.zip --out fixed.zip

Chạy ví dụ

$ zip -FFv foo.zip --out fixed.zip
Fix archive (-FF) - salvage what can
 Found end record (EOCDR) - says expect single disk archive
Scanning for entries...
 Local ( 1      0): copying: d1/f1   (651734 bytes)
 Local ( 1 651817): copying: d1/d2/  (0 bytes)
 Local ( 1 651905): copying: d1/d2/f3   (80 bytes)
 Local ( 1 652083): copying: d1/f23   (891 bytes)
 Local ( 1 653021): copying: d1/f27   (8764 bytes)
 Local ( 1 661837): copying: d1/f24   (14818 bytes)
 Local ( 1 676709): copying: d1/f25   (17295 bytes)
...
 Cen   ( 1 5488799949): updating: d1/f13
 Cen   ( 1 5488800052): updating: d1/f14
Zip64 EOCDR found ( 1 5488800155)...
Zip64 EOCDL found ( 1 5488800211)...
EOCDR found ( 1 5488800231)...
$ echo $?
0

công tắc -FF của zip

đoạn trích từ trang zip man

       -FF
       --fixfix
              Fix the zip archive. The -F option can be used if some 
              portions of the archive are missing, but requires a reasonably 
              intact central directory.   The  input  archive is scanned as 
              usual, but zip will ignore some problems.  The resulting 
              archive should be valid, but any inconsistent entries will be 
              left out.

              When doubled as in -FF, the archive is scanned from the 
              beginning and zip scans  for  special  signatures  to  
              identify  the  limits between the archive members. The single 
              -F is more reliable if the archive is not too much damaged, so 
              try this option first.

              If  the archive is too damaged or the end has been truncated, 
              you must use -FF.  This is a change from zip 2.32, where the 
              -F option is able to read a truncated archive.  The -F option 
              now more reliably fixes archives with minor damage and the -FF 
              option is  needed to fix archives where -F might have been 
              sufficient before.
              ...

Tôi đã thấy loại lỗi này trước đây khi kho lưu trữ zip được chuyển qua dịch vụ web đang gặp sự cố. Khi kiểm tra trực tiếp tệp zip, tôi thấy một thông báo lỗi từ dịch vụ web đã được gửi trước tệp zip.

Bạn có thể thử kiểm tra tệp zip dưới dạng văn bản và xem có gì thú vị xuất hiện ở phía trước không.

Chỉ cần có cảnh báo này, quá. Trong trường hợp của tôi, nguyên nhân là do tải xuống bằng 'curl -i', nguyên nhân khiến các tiêu đề http xuất hiện ở đầu tệp zip. tôi ngớ ngẩn quá. Chắc chắn điều này sẽ không phải là nguyên nhân / giải pháp trong mọi trường hợp, nhưng có lẽ nó giúp được ai đó ...

Nó có thể là một kho lưu trữ tự giải nén (windows .exe) hoặc đã được đệm vì một số lý do.

Tôi cũng có vấn đề tương tự. Tôi đã quan sát vấn đề khi tôi sao chép các tệp từ Windows sang máy chủ Unix mà không sử dụng chế độ bin. Cách tốt nhất để giải quyết vấn đề là chuyển các tệp ở chế độ bin.

Tôi gặp vấn đề tương tự trên Linux với một .ziptệp lớn hơn 4GB, bị only DEFLATED entries can have EXT descriptorlỗi.

Lệnh đã 7z xgiải quyết tất cả các vấn đề của tôi mặc dù.

Hãy cẩn thận, lệnh 7z xsẽ trích xuất tất cả các tệp có đường dẫn bắt nguồn từ thư mục hiện tại. Tùy chọn -ocho phép chỉ định một thư mục đầu ra.