What the inspector checks
- Byte-order marks for UTF-8, UTF-16 LE/BE and UTF-32 (UTF-32 is detected but not supported, and says so).
- UTF-16 without a BOM, from the pattern of zero bytes.
- Whether every non-ASCII byte forms valid UTF-8. A file that is pure ASCII reads the same in every ASCII-compatible encoding, and the inspector says that instead of claiming certainty.
- For legacy single-byte encodings, which bytes decode to control characters. Windows-1252, ISO-8859-2, Windows-1251 and Mac Roman cannot be told apart reliably from bytes alone, so previews are shown side by side for you to judge.
The example
The file above was saved as Windows-1252. Read as UTF-8, “José Núñez” contains bytes that are not valid UTF-8; the inspector lists each one with its byte offset and record. Switch to Windows-1252 and the names, “€” signs and “ß” decode cleanly. The original bytes are never rewritten.
Questions
What is a BOM and should I keep it?
A byte-order mark is an invisible prefix (EF BB BF for UTF-8) that some spreadsheet apps write. ParseCSV excludes it from the first header name by default and accounts for its bytes in the ledger. You can turn that off to see it as data.
Why not just replace invalid bytes?
Replacement characters hide data loss. ParseCSV shows them, counts them and lists their positions, so you can choose the right encoding or fix the source.
Can I export in the original encoding?
Exports are UTF-8 (optionally with a BOM). Re-encoding to legacy encodings is not offered yet.