Before reading anything else, please take time to read the original thread.

A quick simple overview: A .xfdl file is a is a gzipped .xml file which has then been encoded in base64. I wish to de-encode the .xfdl into xml which I can then modify and then re-encode back into a .xfdl file.

xfdl > xml.gz > xml > xml.gz > xfdl

I have been able to take a .xfdl file and de-encode it from base64 using uudeview:

uudeview -i yourform.xfdl

Then decommpressed it using gunzip

gunzip -S "" < UNKNOWN.001 > yourform-unpacked.xml

The xml produced is 100% readable and looks wonderful. Without modifying the xml then, i should be able to re-compress it using gzip:

gzip yourform-unpacked.xml

Then re-encoded in base-64:

base64 -e yourform-unpacked.xml.gz yourform_reencoded.xfdl

If my thinking is correct, the original file and the re-encoded file should be equal. If I put yourform.xfdl and yourform_reencoded.xfdl into beyond compare, however, they do not match up. Also, the original file can be viewed in an .xfdl viewer. The viewer says that the re-encoded xfdl is unreadable.

I have also tried uuenview to re-encode in base64, it also produces the same results. Any help would be appreciated.

If you want to try it, Click Here to download a sample .xfdl file.


Different implementations of the gzip algorithm will always produce slightly different but still correct files, also the compression level of the original file may be different then what you are running it at.

John Downey

Any idea how to find out the compression level? And if so, can this be specified on the command line? Something along the way is screwing up the file.

+1  A: 

As far as I know you cannot find the compression level of an already compressed file. When you are compressing the file you can specify the compression level with -# where the # is from 1 to 9 (1 being the fastest compression and 9 being the most compressed file). In practice you should never compare a compressed file with one that has been extracted and recompressed, slight variations can easily crop up. In your case I would compare the base64 encoded versions instead of the gzip'd versions.

John Downey

Interesting, I'll give it a shot. The variations aren't slight, however. The newly encoded file is longer and when comparing the binary of the before and after, the data hardly matches up at all.

Before (the first three lines)

H4sIAAAAAAAAC+19eZOiyNb3/34K3r4RT/WEU40ssvTtrhuIuKK44Bo3YoJdFAFZ3D79C6hVVhUq dsnUVN/qmIkSOLlwlt/JPCfJ/PGf9dwAlorj6pb58wv0LfcFUEzJknVT+/ml2uXuCSJP3kNf/vOQ +TEsFVkgoDfdn18mnmd/B8HVavWt5TsKI2vKN8magyENiH3Lf9kRfpd817PmF+jpiOhQRFZcXTMV

After (the first three lines):

H4sICJ/YnEgAAzEyNDQ2LTExNjk2NzUueGZkbC54bWwA7D1pU+JK19/9FV2+H5wpByEhJMRH uRUgCMom4DBYt2oqkAZyDQlmQZ1f/3YSNqGzKT3oDH6RdE4vOXuf08vFP88TFcygYSq6dnlM naWOAdQGuqxoo8vjSruRyGYzfII6/id3dPGjVKwCBK+Zl8djy5qeJ5NPT09nTduAojyCZwN9

As you can see 'H4SI' match up, then after that it's pandemonium.


You'll need to put the following line at the beginning of the XFDL file:

application/vnd.xfdl; content-encoding="base64-gzip"

After you've generated the base64-encoded file, open it in a text editor and paste the line above on the first line. Ensure that the base64'ed block starts at the beginning of the second line.

Save it and try it in the Viewer! If it still does not work, it may be that the changes that were made to the XML made it non-compliant in some manner. In this case, after the XML has been modified, but before it has been gzipped and base64 encoded, save it with an .xfdl file extension and try opening it with the Viewer tool. The viewer should be able to parse and display the uncompressed / unencoded file if it is in a valid XFDL format.


gzip will put the filename in the header of file, so that a gzipped file vary in length depending on the filename of the uncompressed file.

If gzip acts on a stream, the filename is omitted and the file is a bit shorter, so the following should work:

gzip yourform-unpacked.xml.gz

Then re-encoded in base-64: base64 -e yourform-unpacked.xml.gz yourform_reencoded.xfdl

maybe this will produce a file of the same length

Alex Lehmann