Binary formats
A plan of record and zero shipped code; rated on the substrate and the BN0 to BN5 roadmap.
0 Strong · 0 Solid · 1 Partial · 9 Emerging
Measured against: Kaitai Struct · construct · 010 Editor · Folders: base/binary(opens in a new tab) · For programmers: this area's reference
Rethought from first principles
What Softanza kept from what works, and what it rethought, as the library wrote it down in its design documents and narrations.
The Softanza wayA binary file is a table the bytes forgot to show: write its layout down once, as data, and the bytes become rows and columns.
Kept from the best practice
- A layout is declared as data, not written as parsing code. Kaitai Struct and COBOL copybooks showed this works; a copybook becomes one input format among others. source(opens in a new tab)
- The COBOL picture rules are adopted, done right: text, binary, zoned and packed decimal, with scale and sign. source(opens in a new tab)
- The classic hex view is kept: offset, hexadecimal bytes and readable text side by side, now with each field's span named. source(opens in a new tab)
Rethought
- A decoded file lands as a live table, where summaries, statistics, plots and export already wait, so exploring it takes zero extra steps. (planned) source(opens in a new tab)
- The same schema also writes files. A crafter narrates each field and its bytes, teaching layout to beginners and producing test files. (planned) source(opens in a new tab)
- Damaged records return verdicts, never crashes, because an old file will contain garbage and a tool that stops at the first bad record is useless. (planned) source(opens in a new tab)
- Schemas are declared, never guessed from the bytes. Format inference is refused as a different, research-grade product. (planned) source(opens in a new tab)
The one pilot page that rates a plan, not a product: the binary plane is 607 lines of design and zero shipped code -- no classes, no decode engine, no tests, no phase has run. The bet is to treat a binary file as 'a table the bytes forgot to show', decoded in one engine crossing into the stzTable analysis stack that already exists, with zero new DLLs; the substrate is real, everything above it is named, sequenced (BN0-BN5) and unbuilt.
What a crafter does with it, and what stands out
- A declarative data schema decoded in one engine crossing, not a generated parser (vs Kaitai's compiler model)
- Decoded bytes land in stzTable, the same analysis stack as every other Softanza source
- Round-trip: the same schema vocabulary reads and writes, which most binary parsers cannot do
- Zero new DLLs: extend the stz_bytes engine rather than vendor Kaitai
What is owed
- Repair the byte-bridge truncation (fixed [4096]/[8192] return buffers)
- The schema + decode-records engine (BN1)
- Endian readers + EBCDIC CP037, then wire decode into stzTable
- COBOL copybook compiler (BN2), tied to the RINGBOL commercial gate
No example run on this page. This group is a plan of record with no shipped code; there is nothing to run, and the page says so rather than showing an example from elsewhere.
The lanes, one by one
Lanes and their notes are quoted as they were read at the source, on Read from the source on 2026-09-16 -- base/binary holds one file, SOFTANZA_BINARY_PLAN.md (607 lines, 2026-08-16); no test/binary exists.