CSV with mixed encodings: how to fix supplier data
Spot corrupted supplier names, tell mixed encoding from a wrong import setting, and rebuild a clean UTF-8 CSV without damaging good rows before upload.
A supplier catalog can look fine in one spreadsheet app but show names like José or strange symbols in another. If only some rows are affected, the file may contain text from different encodings, or a particular import step may have read the bytes incorrectly.
First identify which case you have. The CSV Editor can help you inspect and edit entries in your browser. It does not establish which encoding created the file, so compare questionable values with a trusted source before changing them.
Check the CSV before changing it
- Make a copy of the original supplier catalog and keep it untouched. Open the copy in the CSV Editor and locate a few names or product descriptions with accented letters or symbols.
- Compare those entries with the supplier's original file, website, or another reliable record. Note which rows are correct and which are damaged. Check that the text has not simply shifted into the wrong columns.
- Look for a pattern. If every accented name is damaged in the same way, the whole file may have been read using the wrong encoding. If one supplier's rows look different from another supplier's rows, the files may have been combined before their encodings were made consistent.
- Choose a repair based on the pattern. When source files are available, import each one using its correct encoding and save each as UTF-8 before combining them. If just a few values need correction, restore those values from a trusted source and edit them in the CSV Editor.
Do not repeatedly open and save the only copy while testing settings. Each incorrect save can make the original characters harder to recover.
What the damaged text means
Names show patterns such as José
This often means UTF-8 text was interpreted as a different encoding, such as Windows-1252. The original letter may still be represented in the file, but the program is displaying the bytes incorrectly. Reopening the original file with the correct encoding may restore it.
Only certain suppliers or sections look wrong
The catalog may have been assembled from files that used different encodings. A single CSV file normally has one encoding for the entire file, not a separate encoding for each row. When sources were combined without first converting them consistently, some entries can become unreadable.
You see a replacement diamond or question mark
A replacement character can mean the original program could not decode a byte and substituted a placeholder. If the file was saved after that substitution, the original character may be gone. Check the supplier's source or request a fresh export instead of guessing.
Values appear in the wrong columns
This may be a; quoting problem, not an encoding problem. A comma inside a supplier description needs to be handled as part of a quoted field. Check whether rows still have the expected columns bef; e trying to convert text.
How to fix the encoding
- Return to an untouched source. If the text became c; rupted after opening; saving the CSV, start again from the supplier's original download or a backup. Changing the encoding of an already damaged copy may not restore the lost characters.
- Import each source with its actual encoding. Use the import options in the application that reads the supplier file, rather than relying on automatic detection. UTF-8 is a good choice for new exports, but do not assume it is the source encoding unless the supplier confirms it. Use another encoding only when the supplier or original system identifies it.
- Save clean source files as UTF-8. Convert each supplier file separately, then inspect names with accents and symbols in the saved copies. Confirm that the values match the source before combining records.
- Combine the normalized files. Add the rows only after the separate files use the same encoding and column layout. Keep one header row, and check that quoted descriptions and commas remain in their intended fields.
- Repair a small number of known values. If you cannot re-export the source, use a reliable supplier record to restore each affected value. The CSV Editor can help you find and edit those entries. Avoid broad find-and-replace rules that might alter valid names elsewhere.
- Test the repaired catalog in its destination. Check a small copy first, including accented names, symbols, commas in descriptions, and any product codes that begin with zero. Confirm that the destination reads the columns and text correctly before replacing the working catalog.
Why one conversion may not fix every row
Encoding is a way to represent text as bytes. UTF-8 can represent characters from many writing systems, while older encodings cover smaller character sets. If one file is incorrectly decoded, selecting a different encoding during a later import can sometimes reverse the mistake. But if the wrong text was saved over the original, or several incompatible files were combined, there may be no single setting that repairs everything.
That is why source-by-source recovery is safer than converting the whole catalog repeatedly. Preserve the originals, check the encoding used for each supplier export, and make one consistent UTF-8 copy for the final combined catalog.
The CSV Editor works in your browser, and the catalog file stays on your device.
