About XFDL

When an XFDL file indicates asci-gzip (sometimes spelled asc-gzip), it can be misleading:

What it actually means in XFDL practice

  • asci → ASCII-encoded (almost always Base64)
  • gzip → historical / generic label, not always literal GZIP format

In many real-world XFDL files:

  • The data is Base64-encoded
  • The compressed payload is raw DEFLATE, not a full GZIP file

So the pipeline is often:

XML
  ↓ (deflate compression — raw, no gzip header)
compressed bytes
  ↓ (Base64 encoding)
ASCII text (asci-gzip)

Why the confusion exists

  • Early tooling and specs loosely used “gzip” to refer to the deflate algorithm
  • True GZIP format includes:
    • Header
    • Optional filename/comment
    • CRC/footer
  • Many XFDL files omit the GZIP container and use deflate only

Practical implication

  • If you try to treat asci-gzip as a real .gz file, it may fail
  • You often need:
    1. Base64 decode
    2. Inflate (deflate decompression) — not gunzip

How this relates to Chilkat

  • XfdlToXml handles this automatically
  • If doing manually, you’d typically use:
    • Decode → Base64 → bytes
    • InflateStringENC or equivalent → deflate decompress

Key takeaway

In XFDL, “asci-gzip” often means Base64 + raw deflate, not a true GZIP file format.

That naming inconsistency is historical and unfortunately pretty common in XFDL ecosystems.