https://github.com/jaredreisinger/iffdump
https://github.com/jaredreisinger/iffdump
Last synced: about 1 year ago
JSON representation
- Host: GitHub
- URL: https://github.com/jaredreisinger/iffdump
- Owner: JaredReisinger
- Created: 2018-03-05T21:59:51.000Z (over 8 years ago)
- Default Branch: master
- Last Pushed: 2018-03-05T22:00:08.000Z (over 8 years ago)
- Last Synced: 2025-02-10T05:26:10.140Z (over 1 year ago)
- Language: Go
- Size: 690 KB
- Stars: 0
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# iffdump
Tools to dump IFF-formatted files.
## design
There are some different approaches to understanding an IFF file:
* Run through start-to-finish, dealing with chunks as they are encountered
* unmarshal into strongly-typed structure.
While the former seems like a reasonable first approach, it makes it much harder
to *do* anything with the data... for example, in attempting to understand a
Quetzal save file, we really do need to understand the IFZS, IFhd, CMem, UMem,
Stks, and IntD chunks.
So... let's look/compare the JSON decode (and other unmarshal) logic. Here, a
very generic IFF-chunk reader *is* useful, as a utility. Really, we just want
something that, given an io.Reader (or iff.ReadAtSeeker), can give us a series
of chunks. Then, each chunk has its own unmarshalling, which may use the
"series of chunks" logic again.
So, we could create something that acts like a BinaryUnmarshaler, but that
interface reads from a `[]byte`... which we may not want to assume! (That
said, `json.NewDecoder()` takes an `io.Reader`... so go figure!)
In order to successfully unmarshal/decode, the decoder needs hooks for every
chunk type, so it can call them to handle the data... Unlike `json.Decode()`,
we can't provide the typed struct first... we have to read a little bit in order
to determine the struct needed. Thus, the instead of decoding *into* a struct,
the decoders must *create* the struct/data.