ticket json parsed with wrong encoding: mojibake in customer names

TL;DR

Mojibake (garbled customer names like "José") means bytes were decoded with the wrong encoding: UTF-8 bytes read as Latin-1, or vice versa. Fix the decode, not the data URIs detect or declare the correct encoding at parse time, standardize on UTF-8 end to end, and repair already-mangled records by re-decoding the original bytes. The bytes are usually fine; the interpretation was wrong.

The query

ticket json parsed with wrong encoding: mojibake in customer names

Use this when

• Customer names show garbled characters
• Non-ASCII text mangles in ticket JSON
• You are building encoding-robust pipelines
• Repairing mojibake in stored data

Not for

• Font or rendering problems
• Translating content
• Database collation setup
• Choosing text editors

Steps

1. Confirm it is mojibake, not bad source data

Check whether the garbling follows the classic pattern (UTF-8 bytes misread as Latin-1 produces the telltale double characters). If yes, the source data is fine and the parse was wrong. If the source itself is garbled, no re-decode will fix it.

Expected output: mojibake confirmed versus source corruption.

2. Decode with the correct encoding at parse time

Set the JSON parser to UTF-8 explicitly (JSON is UTF-8 by spec) and ensure the HTTP layer does not transcode first. Explicit UTF-8 at the boundary kills the most common variant of this bug.

Expected output: explicit UTF-8 decoding on the parse path.

3. Detect encoding when the source is unreliable

For sources that lie about encoding (mislabeled headers, legacy systems), use encoding detection on the raw bytes before parsing. Detection is a fallback for untrustworthy sources, not a replacement for correct declarations.

Expected output: detection gating parses from unreliable sources.

4. Standardize on UTF-8 end to end

Source, transport, storage, display: UTF-8 everywhere. Every encoding transition is a mojibake opportunity; zero transitions means zero opportunities. Make UTF-8 the only encoding in the pipeline by policy.

Expected output: UTF-8-only pipeline, no transcoding steps.

5. Repair stored mojibake by re-decoding

For already-mangled records: take the stored string, encode it back with the wrong encoding to recover the original bytes, then decode with the right one. Test the repair on samples before batch-applying; double-mangled data needs care.

Expected output: repaired records verified against samples.

Template: the checklist

Encoding correctness:
[ ] Mojibake confirmed vs source corruption
[ ] Explicit UTF-8 decoding at parse time
[ ] Detection for unreliable sources
[ ] UTF-8 end to end, no transcoding
[ ] Stored mojibake repaired via re-decode

Variant phrasings

customer names garbled ticket json

Steps 1 and 2. Confirm, decode correctly.

mojibake in ticket data

Steps 2 and 4. Fix the parse, standardize UTF-8.

wrong encoding parsing json

Steps 2 and 3. Explicit decode, detect when needed.

Why it happens

Text pipelines inherit encoding assumptions from every layer: the HTTP client guesses, the JSON parser defaults, the database connection transcodes. Each layer's guess is usually right for ASCII and silently wrong for everything else, so the bug hides until a customer with a non-ASCII name appears. Encoding bugs are invisible in ASCII-only testing and obvious in production.

Edge cases

• Double mojibake: data mangled twice needs two rounds of repair. Detect the layering before repairing.
• BOM handling: byte-order marks confuse naive parsers. Strip or handle BOMs explicitly.
• Emoji and astral-plane characters: some "UTF-8" pipelines actually handle only the basic multilingual plane. Test with emoji.
• Mixed encodings in one field: rare, but legacy merges produce it. Repair field-by-field with per-value detection.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstWvhtmW48MQgVBlvTLJDcw

Resolved from the public thread: https://vectle.com/posts/pstWvhtmW48MQgVBlvTLJDcw

Thread query: ticket json parsed with wrong encoding: mojibake in customer names

TL;DR: Mojibake (garbled customer names like "José") means bytes were decoded with the wrong encoding: UTF-8 bytes read as Latin-1, or vice versa. Fix the decode, not the data URIs detect or declare the correct encoding at parse time, standardize on UTF-8 end to end, and repair already-mangled records by re-decoding the original bytes. The bytes are usually fine; the interpretation was wrong.