Why do accented or Chinese product names turn into strange characters after import?

Preserve the exact approved specimen

Use this fictional specimen: “Mira Café — 青瓷杯.” Keep it in an approved plain-text record before exporting. The accents, dash and Chinese characters are intentional parts of the example. Replacing them with basic Latin letters would conceal the symptom while changing the approved name.

Make three comparison points: the writing source, the saved file reopened with the intended encoding, and the destination’s retained text. A problem that appears at the second point occurred before the store import. If all three retain the intended characters but the display looks wrong, investigate typography separately.

Locate where the characters changed

For the fictional cup, a reviewer marks whether é and each Chinese character match the approved specimen. Do not treat a file extension or an editor’s encoding label as the whole test. The actual decoded text should agree with the source before an authorized pilot update is submitted.

Use an inspectable comparison record for the fictional Mira Café — 青瓷杯: approved text version, exact saved filename, export/decoding choice, reopened value and retained destination value. Check the accent, dash, Chinese characters and record identifier. A UTF-8 label on a file that already contains substitute question marks does not restore the missing characters.

Export, reopen and compare

1. Return to the preserved correct source text.
2. Save a working CSV with the destination’s required UTF-8 encoding.
3. Close and reopen that actual saved file with the intended decoding.
4. Inspect the specimen and relevant record identifiers before importing.

If a colleague received a damaged file, send a newly verified export rather than asking them to guess replacement characters. Keep the exact encoding choice in the handoff note. Also check that the file still has the expected parsed fields; solving character encoding does not independently verify delimiters or update behavior.

Start the new export from the trusted correct specimen. Reopen the bytes you actually saved or sent, not a still-open spreadsheet that may retain the original text in memory. If the recipient received a different attachment, verify that attachment before blaming the importer. Keep the destination-required comma delimiter and the correct parsed field boundaries while changing encoding.

Approve content and display independently

Inspect the imported product record and shopper-facing page. In this exercise, the approved name should remain intact in both, with no unexpected question marks or substitute wording. Record the source version and the observed comparison; no private customer information is needed in a public example.

This workflow is a manual product-copy check, not an automatic character-repair feature in CartVisual. It also cannot repair a missing font glyph merely by changing CSV encoding. Keep an external typography review when stored text is correct but rendering differs. Completion means the approved characters survive the complete publishing handoff, not merely that the import returned success.

Keep a correction scoped to the affected fields and current record. An older correctly encoded catalog can contain obsolete stock, prices or unrelated copy; do not overwrite it wholesale as an encoding repair. Coordinate a narrowly reviewed update with the store owner. Use CSV quoting checks for syntax and the separate font guide when correct stored text renders badly. No external importer or automatic recovery was run here.