[ { "Id": "430468", "ThreadId": "209184", "Html": "

Hi. I'd like to know if it's possible to and how to manipulate the extra fields on zip entries. Specifically, I need to make one have a length of 0.

\r\n

The situation:

\r\n

I'm writing an ePub creation tool for fun and personal use, and using DotNetZip to make the zip container. When I use the "epubcheck" validation tool, it always returns an error like "extra field length for first filename must be 0, but was 36". This 'first file' is some special file called "mimetype" containing the mime-type data for epub. The code that (likely) produces this error message in the epubcheck tool is (particularly important parts in bold):

\r\n

 

\r\n
\r\n
FileInputStream epubIn = new FileInputStream(epubFile);

byte[] header = new byte[58];

if (epubIn.read(header) != header.length) {
report.error(null, 0, "cannot read header");
} else {

  int fnsize = getIntFromBytes(header, 26);
  int extsize = getIntFromBytes(header, 28);

  if (header[0] != 'P' && header[1] != 'K') {
    report.error(null, 0, "corrupted ZIP header");
  } else if (fnsize != 8) {
    report.error(null, 0, "length of first filename in archive must be 8, but was " + fnsize);

  } else if (extsize != 0) {
    report.error(null, 0,"extra field length for first filename must be 0, but was " + extsize);

  } else if (!CheckUtil.checkString(header, 30, "mimetype")) {
    report.error(null, 0, "mimetype entry missing or not the first in archive");

  } else if (!CheckUtil.checkString(header, 38, "application/epub+zip")) {
    report.error(null, 0, "mimetype contains wrong type (application/epub+zip expected)");

  }
}
\r\n
\r\n

 

\r\n

The code I use to write the zip file is:

\r\n

\r\n

\r\n
ZipFile output = new ZipFile(Encoding.UTF8); //use utf-8 file names\r\noutput.UseUnicodeAsNecessary = true; //ensure the file names use unicode names?\r\noutput.Encryption = EncryptionAlgorithm.None; //the file cannot be encrypted\r\noutput.CompressionLevel = CompressionLevel.None; //the file cannot be compressed\r\noutput.AddEntry("mimetype", data.Mimetype, Encoding.ASCII); //file in ascii(ansi) encoding\r\n
\r\n
\r\n

\r\n

Any hits or suggestions? Thank you.

\r\n

 

", "PostedDate": "2010-04-13T07:25:27.5-07:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "430527", "ThreadId": "209184", "Html": "

yes, you can work around this.

\r\n

The "extra field" in a zip entry contains high-resolution timestamp information, potentially encryption information, other stuff.  

\r\n

By default DotNetZip produces zip files that include NTFS timestamp information in that extra field.  The size of that time information is 36 bytes: a 4 byte signature followed by 12 bytes each for the created, modified, and accessed times for the file.  To exclude that timestamp you can set ZipFile.EmitTimesInWindowsFormatWhenSaving to false, in the same way (and right after) you set UseUnicodeAsNecessary to true. You will still get the low-resolution timestamp on the zip entry.  This should give you an "extra field" of zero bytes in length.

\r\n

ps: it seems unnecessarily rigid for ePub to require that the extra field length for the entry be zero.  The extra field is optional, it need not be handled by the reading application.  If the app doesn't want or need the extra field, it can ignore it.  No need to report an error. 

\r\n

 

\r\n

 

\r\n

 

", "PostedDate": "2010-04-13T09:11:33.713-07:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "430697", "ThreadId": "209184", "Html": "

Thank you so much! I can finally output a "valid" (according to epubcheck) epub.

\r\n
Cheeso wrote:
\r\n

ps: it seems unnecessarily rigid for ePub to require that the extra field length for the entry be zero.  The extra field is optional, it need not be handled by the reading application.  If the app doesn't want or need the extra field, it can ignore it.  No need to report an error. 

\r\n
\r\n

I agree that the requirements for the frankly useless "mimetype" file are overly strict and a bit difficult to follow. I'd imagine most reading systems skip it anyway. My Sony Reader read my "invalid" epub just fine. But... since you can never be sure who will enforce what, we have to try to pass the only 'validation' tool available for epub.

", "PostedDate": "2010-04-13T16:46:00.683-07:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "433736", "ThreadId": "209184", "Html": "

Glad it worked for you!

\r\n

 

", "PostedDate": "2010-04-21T09:14:27.127-07:00", "UserRole": null, "MarkedAsAnswerDate": null }, { "Id": "485721", "ThreadId": "209184", "Html": "

My thanks too!

\r\n

For what it's worth, the point behind this restriction is that the mime type is at an exact binary offest from the start of the file.  This makes it easier for low powered devices to check what sort of file it is and so on.  However, I do agree that this seems overkill these days.

\r\n

Now for the rest of the errors :(

\r\n

Iain

", "PostedDate": "2010-08-27T08:46:12.183-07:00", "UserRole": null, "MarkedAsAnswerDate": null } ]