ISO-8859-9 ISO-8859-9 (Latin-5, Turkish) ISO-8859
Latin-1 with six characters swapped out for Turkish-specific letters — the encoding Turkish actually settled on, rather than Latin-3.
What it is
ISO-8859-9, also called Latin-5, is essentially ISO-8859-1 with six code points swapped out for Turkish-specific characters (İ, ı, Ğ, ğ, Ş, ş) in place of a handful of rarely-used Icelandic letters that Latin-1 included. This made it the practical, adopted encoding for Turkish text — rather than ISO-8859-3, which had originally attempted (with limited success) to cover Turkish alongside Maltese and Esperanto.
Byte structure
| Byte range | Content |
|---|---|
| 0x00–0x7F | Identical to ASCII |
| 0xA0–0xFF | Identical to ISO-8859-1 except for six positions replaced with Turkish-specific letters |
Why your text is garbled (symptom → cause)
| Symptom | Likely cause |
|---|---|
| Turkish İ/ı or Ş/ş/Ğ/ğ characters display as unrelated Icelandic letters | Text is Latin-5 but read as Latin-1 (or vice versa) — the two are identical except for exactly those six swapped positions |
| Programmatic uppercase/lowercase conversion breaks Turkish text | The famous "Turkish I problem" — Turkish has both dotted (İ/i) and dotless (I/ı) versions of the letter I, and standard ASCII-based case-conversion logic in many programming languages incorrectly assumes English's single dotted-I convention, producing wrong results for Turkish text regardless of the underlying encoding |
Compatibility & gotchas
- Nearly identical to Latin-1 — only six byte positions differ, which makes silent mislabeling between the two encodings an easy, low-visibility mistake since most text will still look correct.
- The "Turkish I problem" is a case-conversion bug, not an encoding bug, but it's closely associated with Turkish text handling and worth knowing about separately — languages/frameworks that don't apply Turkish-specific (locale-aware) case-folding rules will incorrectly convert dotless ı to dotted I (or vice versa) when uppercasing/lowercasing Turkish strings.
- Modern Turkish content overwhelmingly uses UTF-8 rather than Latin-5, but legacy Turkish-language databases, documents, and software from before full Unicode adoption may still use it.
Fixing it
- Command-line conversion:
iconv -f ISO-8859-9 -t UTF-8 input.txt -o output.txt - Turkish case-conversion issues: use locale-aware case conversion functions (e.g., specifying a Turkish locale explicitly) rather than default ASCII-based uppercase/lowercase logic, which is a separate fix from any encoding conversion.
Comparison
| Encoding | Key difference from ISO-8859-9 |
|---|---|
| ISO-8859-1 | Identical except for six swapped positions covering Icelandic vs. Turkish-specific letters |
| ISO-8859-3 | The earlier, less-adopted attempt at Turkish coverage |
| UTF-8 | Full Unicode coverage, the modern default |
FAQ
What's different between ISO-8859-9 and ISO-8859-1?
Exactly six code points — Latin-5 replaces a handful of Icelandic letters that Latin-1 includes with Turkish-specific characters (İ, ı, Ğ, ğ, Ş, ş) instead. Everything else is identical.
What is the "Turkish I problem"?
A well-known software bug pattern where standard ASCII-based uppercase/lowercase conversion logic doesn't correctly handle Turkish's distinction between dotted İ/i and dotless I/ı — converting Turkish text with the wrong locale rules produces incorrect results. It's a case-conversion issue, separate from character encoding itself, but frequently discussed alongside Turkish text handling generally.
Fun fact
The "Turkish I problem" is famous enough in software engineering circles to have become a standard example in programming language documentation and interviews about locale-aware string handling — Microsoft, Oracle, and other major vendors have all published specific guidance about it precisely because it's such a common and easy-to-miss bug.