For information about the dBase III (.dbf) file format, see:
- http://web.tiscali.it/SilvioPitti/ ([local copy](./xbase-file-format-description.html))
- https://en.wikipedia.org/wiki/.dbf
- http://www.dbf2002.com/dbf-file-format.html
- http://www.dbase.com/KnowledgeBase/int/db7_file_fmt.htm
- http://www.independent-software.com/dbase-dbf-dbt-file-format.html
- https://docs.microsoft.com/en-us/previous-versions/visualstudio/foxpro/8599s21w(v=vs.80)
- https://docs.microsoft.com/en-us/previous-versions/visualstudio/foxpro/st4a0s68(v=vs.80)

For test files, see:
- https://github.com/infused/dbf/tree/master/spec/fixtures

For details about Visual FoxPro 9 memo fields with block size 1, see [this article](./vfp9-bs1.pdf)

For details about Clipper/FoxPro character fields longer than 255 bytes, see:
- CA-Clipper stores such lengths as a 16-bit value split across field descriptor bytes 16 and 17:
  `FIELD_DEC := int(nLength / 256)` and `FIELD_LEN := (nLength % 256)`, recovered as
  `iif(FIELD_TYPE == "C", FIELD_DEC * 256 + FIELD_LEN, FIELD_LEN)`
  ([CA-Clipper 5.3 DBCREATE()/structure-extended docs](https://vivaclipper.wordpress.com/tag/dbcreate/))
- Harbour (the open-source CA-Clipper compiler) writes and reads this unconditionally for `C` fields -
  see `hb_dbfCreate`/`hb_dbfOpen` in [src/rdd/dbf1.c](https://github.com/harbour/core/blob/master/src/rdd/dbf1.c)
  (`bLen = uiLen; bDec = uiLen >> 8` on create, `uiLen = bLen + bDec * 256` on open)
- dbfread does the same on read - see [dbfread/dbf.py](https://github.com/olemb/dbfread/blob/master/dbfread/dbf.py)
  (`field.length |= field.decimal_count << 8`)
- shapelib implemented this and later *disabled* it, because for some producers byte 17 is a formatting
  hint rather than a length high byte - see the `bug 1202` comment in
  [dbfopen.c](https://postgis.net/docs/doxygen/3.3/dd/d29/dbfopen_8c_source.html). SocialExplorer/FastDBF hit the
  same problem and worked around it by falling back when the record length doesn't reconcile
  ([FastDBF#5](https://github.com/SocialExplorer/FastDBF/issues/5)). This is why DBFFile only applies the 16-bit
  interpretation when it exactly reconciles with the record length declared in the header.

The three `clipper_*.dbf` fixtures are generated by Harbour 3.2.0 from
[clipper_fixtures.prg](../test/fixtures/clipper_fixtures.prg):

- `clipper_long_char.dbf` - two character fields longer than 255 bytes. Cross-checked against dbfread 2.0.7,
  which reports the same field sizes and the same record values.
- `clipper_decimals_not_length.dbf` - short character fields only, with byte 17 of one descriptor overwritten
  with a non-zero value. The declared record length still reconciles with the standard interpretation, so the
  field sizes must be left alone. Note that dbfread and Harbour both misread this file, because they apply the
  16-bit interpretation unconditionally.
- `clipper_long_char_corrupt.dbf` - as `clipper_long_char.dbf`, but with byte 17 of one descriptor corrupted so
  that neither interpretation reconciles. Must be rejected rather than guessed at.