Das zip-Dateiformat endet mit einem zentralen Verzeichnisabschnitt, der dann auf die einzelnen zip-Einträge in der Datei verweist. Dies scheint zu ermöglichen, dass Zip-Einträge irgendwo innerhalb der Zip-Datei selbst auftreten. In der Tat sind selbstextrahierende Zip-Dateien ein gutes Beispiel: Sie beginnen mit einer ausführbaren Datei, und alle ZIP-Einträge treten nach den ausführbaren Bytes auf.Können ZIP-Dateien spärlich/nicht zusammenhängend sein?
Die Frage ist: erlaubt das Zip-Dateiformat wirklich spärliche oder nicht zusammenhängende zip-Einträge? z.B. Wenn zwischen den Zip-Einträgen leere oder anderweitig nicht erfasste Bytes vorhanden sind? Sowohl der endgültige PK-Hinweis als auch der Wikipedia-Artikel scheinen dies zu ermöglichen. Funktionieren alle/die meisten typischen Zip-Dienstprogramme mit solchen spärlichen Zip-Dateien?
Der Anwendungsfall ist dies: Ich möchte Zip-Einträge in einer Zip-Datei löschen oder ersetzen können. Um dies zu tun, möchten die typischen Minizip-Bibliotheken, dass Sie die gesamte Zip-Datei kopieren, während Sie die gelöschte oder ersetzte Zip-Datei nicht kopieren, was verschwenderisch und langsam erscheint.
Wäre es nicht besser zu überzuordnen, sagen 1,5x der Speicher für einen Eintrag, dann wenn Sie einen Eintrag löschen oder ersetzen, könnten Sie herausfinden, wo die nicht zugeordneten Bytes waren und diese direkt verwenden? Wenn der ZIP-Eintrag linear anwächst, bedeutet dies, dass die Neuzuweisung bei Verwendung von 1,5x linear erfolgen sollte. Es wäre ähnlich der Dateisystemblockzuweisung, obwohl es wahrscheinlich nicht so ausgefeilt ist.
Dies hilft auch mit vielen der zip-basierten Dateiformate da draußen. Anstatt ein temporäres Verzeichnis irgendwo (oder sogar im Speicher) mit den temporär entpackten Dateien zum Editieren/Ändern zu haben und dann das Los wieder in das Dateiformat zu zippen, würde dies die Notwendigkeit, Teile der Zip wieder zu öffnen und neu zu schreiben, verringern Datei.
Gibt es irgendwelche C/C++ - Bibliotheken, die das tun?
Überschüssiger Speicher verhindert nicht den Zweck der Komprimierung? –
zip-Datei ist nicht das beste Medium für die dynamische Speicherverwaltung. es ist Archiv. Zip Ihre Daten zusammen und fertig. –
Einige Daten z.B. Englischer Text oder XML, könnte bis zu 10x komprimiert werden. Eine Überallokalisierung von nur 0,5x zusätzlichem Speicherplatz würde sich immer noch lohnen, wenn die gesamte Zip-Datei nicht neu geschrieben werden könnte. Diese Überbelegung könnte auf einer API-Ebene bestimmt werden, so dass z.B. Einträge, von denen bekannt ist, dass sie nicht in ihrer Größe zunehmen, können gerade genug Platz zugewiesen werden. –