Structure and encoding are different problems
A DBF may have perfectly valid records while names and descriptions display incorrectly. Legacy DBF text stores bytes, not universal Unicode characters. Software needs a code page to map each byte to a character. CP437, CP850, CP1252 and regional Windows or DOS encodings assign different characters to some of the same byte values.
Mojibake provides clues. Text such as André often means UTF-8 bytes were interpreted as a single-byte encoding. A box-drawing character where an accent should appear can suggest a DOS/Windows mismatch. Question marks or replacement diamonds can mean that an earlier conversion already discarded the original byte value.
Use several pieces of evidence
- Read the language-driver byte. The DBF header can declare a code-page mark, but real applications sometimes leave it unset or copy an incorrect value.
- Identify the source environment. A DOS Clipper application from Western Europe is more likely to use an OEM encoding such as CP850; a Windows application may use CP1252. This is context, not proof.
- Find known words. Names, cities and product descriptions with accents are strong comparison samples.
- Compare multiple candidate decodings. The right choice should improve the whole sample, not only one character.
- Inspect every text field. Data imported from another system may use a different history from locally entered records.
| Candidate | Common context | Useful distinction |
|---|---|---|
| CP850 | Western European DOS/xBase systems | Accented letters occupy positions that CP1252 may show as symbols. |
| CP437 | US DOS and early PC data | Similar to CP850 but differs for several international characters. |
| CP1252 | Western European Windows applications | Includes typographic quotes and euro-era characters in the 0x80–0x9F range. |
| ISO-8859-1 | Older interchange and Unix contexts | Often confused with CP1252, particularly for punctuation. |
Build a controlled decoding sample
Work from the untouched bytes. Select records containing plain ASCII plus expected accented characters. Decode the same sample with each plausible code page and save the comparison. Reject a candidate when it turns common letters into control characters or produces implausible vocabulary elsewhere.
Do not repeatedly open and save the DBF in programs with different defaults. Each save risks turning a display problem into irreversible byte replacement. DBF Viewer Pro attempts to identify known language-driver marks; when detection is uncertain, treat the result as a hypothesis and verify it with domain knowledge.
Convert once, then validate UTF-8
After choosing the source encoding, export to UTF-8 and retain the unmodified DBF. Check accented values in a plain-text editor and in the destination application. Count replacement characters, compare known names and retain the chosen source code page in the migration log.
CSV consumers can still misinterpret a correct UTF-8 file. Import it explicitly rather than double-clicking when possible. See private DBF-to-CSV conversion and preparing DBF data for Excel for the next steps.