DigiKitApp
🇹🇷 TRQuick Access

Where Do Those Weird "ç" Characters Come From?

Seeing ç instead of ç when you open a file is annoying, but there's actually a pretty logical reason for it.

Summary

This kind of corruption is called mojibake, it's not a bug, it's two different character encodings getting mixed up.

Step by step

  1. When a text file is saved, each character gets converted into a sequence of bytes according to some encoding standard. For Turkish characters, the most common one today is UTF-8.
  2. Here's where it goes wrong: the file was saved as UTF-8, but another program tries to read it using a different encoding (usually Windows-1254 or Latin-1). In UTF-8, "ç" is represented with 2 bytes, and the wrong encoding interprets those 2 bytes as 2 separate characters, that's how ç shows up.
  3. The most common triggers: opening a CSV file in Excel, text copied from an old email client, or a website's source missing a charset declaration.
  4. The most reliable fix is reopening the file with the correct encoding, if that's an option. But if all you have is the already-garbled text, the common corruption patterns (ç→ç, ü→ü, ı→ı, etc.) are fixed, known mappings, so reversing them usually works.
  5. For a permanent fix: if you're writing code, explicitly declare UTF-8 everywhere, database connections, HTML meta tags, file saves. It doesn't just "fix itself" one day, encoding consistency is something you have to enforce by hand.

Why it matters

Garbled characters look like a display glitch at first, but the real damage is to your data. Search a customer list where names were saved broken and you won't find anyone called 'Çelik'. Once corrupted text lands in a database and new records keep piling on top, cleaning it up gets harder every day. On an invoice, a shipping label or an official letter, a mangled name simply looks careless.

The opposite problem: question marks and boxes

Patterns like ç come from a UTF-8 file being read with an older encoding. It also happens the other way around. A file saved in Windows-1254, the legacy Turkish encoding on Windows, opened as UTF-8 shows a diamond with a question mark, or empty boxes, where the Turkish letters should be. This one is worse. If you save the file in that state, the original letters are gone for good. When you see that symbol, close the file without saving and reopen it with the right encoding.

Common mistakes

  • Fixing the same text more than once. Running the conversion again on text that's already been repaired creates a new kind of mess.
  • Opening a CSV in Excel by double-clicking it. Using the import option under the Data tab and choosing UTF-8 is much more reliable.
  • Saving a CSV meant for Excel without a BOM. Excel often only recognizes UTF-8 if the file is saved as 'CSV UTF-8' with a byte order mark.
  • Confusing an encoding problem with a case problem. Turkish has separate dotted and dotless i. Uppercasing without the right locale can turn 'istanbul' into 'ISTANBUL' instead of 'İSTANBUL'. That's a different bug entirely.

A realistic scenario

An online store exports its orders as CSV. The accounting team opens the file in Excel and every address is full of things like ü and ş. The first instinct is to fix it by hand. The lasting fix is to switch the export to UTF-8 with BOM, or to show the accounting team how to use the import wizard. For older files, the team makes a backup, runs a batch conversion with a character repair tool and compares a few sample records against the original.

Back up before you fix anything

Don't overwrite the original until you're sure which conversion is correct. Work on a copy, check several different rows and only replace the real file once the result looks right everywhere.