Short answer
What you need to know
Check three things. A byte-order mark (U+FEFF) at the start of the file can become part of the first column name, so the import cannot find that column. Text saved in one encoding and read in another turns é into é. Windows (CRLF) and Unix (LF) line endings mixed in one file can leave a stray carriage return at the end of values. Remove the mark, save the file as UTF-8, and make the line endings match.
The byte-order mark
A byte-order mark is the character U+FEFF placed at the very start of a file to say which encoding it uses. Some spreadsheet programs add it when they save a CSV as UTF-8.
Many importers do not expect it and read it as part of the first value. The first column, say id, becomes a column named id with an invisible character in front, so a mapping to id fails with "column not found" even though you can see id in the file.
The fix is to remove the mark, which changes nothing else in the file. Data Check reports it as Byte-order mark at the start and removes it if you choose.
Text encoding
An encoding is the rule that turns bytes into letters. UTF-8 is the standard today, but older systems save files as Windows-1252 or other code pages. Plain English letters look the same in all of them; accented letters and symbols do not.
When UTF-8 is read as Windows-1252, é becomes é, a curly apostrophe becomes ’, and a no-break space becomes  followed by a space. When it happens the other way round, the letters that cannot be read are replaced by �, and the original letter is lost.
Data Check reads files as UTF-8, and a file that is not valid UTF-8 is read as Windows-1252 and says so. It reports garbled accents and offers to repair them when the bytes still decode correctly, and it reports � characters, which cannot be repaired. The cleaned copy is always saved as UTF-8.
Line endings
Windows ends a line with two characters, carriage return and line feed (CRLF). Unix, Linux, and macOS use line feed alone (LF). A file edited on both kinds of system can end up with a mixture.
An importer told to expect LF reads the carriage return in a CRLF line as part of the last value, so the last column holds 42 followed by an invisible character, and a number column rejects it. An importer expecting CRLF may treat a file of LF lines as one enormous row.
Choose one ending for the whole file and make every row match. Data Check reports mixed endings with a count of each kind and changes them all to the one you pick, leaving line breaks inside quoted values alone.
A worked example
An import into a products table fails with a message that column sku does not exist. The file's first line reads sku,name,price. Data Check reports a byte-order mark at the start and 140 Windows line endings mixed with 3 Unix ones.
Removing the mark makes the first column sku again, and changing all endings to Windows (CRLF) makes every row end the same way. The cleaned copy imports without errors.
Settings to check in the import itself
Tell the import tool the encoding (UTF-8), the separator, the quote character, and whether the first row is a header. PostgreSQL's COPY and MySQL's LOAD DATA both take these as options, and a mismatch between the settings and the file causes most failed imports.
Important limitation
Verify important findings
Repairing garbled accents only works when the original bytes are still there. A file that was already converted with question marks or � in place of letters cannot be repaired from the file alone; go back to the source system and export it again as UTF-8.
Check a file for a byte-order mark and line endings Review the methodology
Further reading
Authoritative references
These primary sources support the concepts and reference information in this guide. Their inclusion does not imply endorsement of Hidden Word Scanner.