ISO-8859-6 ISO-8859-6 (Arabic) ISO-8859
An Arabic-script encoding — complicated in practice by Arabic's contextual letter shaping and right-to-left text direction, neither of which single-byte encoding addresses.
What it is
ISO-8859-6 provides basic Arabic letter encoding within the single-byte ISO-8859 framework. It's worth noting upfront that Arabic text has requirements a simple single-byte character encoding doesn't fully address on its own — contextual letter shaping (Arabic letters change form based on their position within a word) and right-to-left text direction are handled by separate rendering and text-layout logic, not by the character encoding itself. ISO-8859-6 only maps byte values to base Arabic characters.
Byte structure
| Byte range | Content |
|---|---|
| 0x00–0x7F | Identical to ASCII |
| 0xA0–0xFF | Arabic letters and symbols, with several positions left unassigned |
Why your text is garbled (symptom → cause)
| Symptom | Likely cause |
|---|---|
| Arabic text completely unreadable | Encoding mismatch — text is Windows-1256 (more common in practice on Windows) being misread as ISO-8859-6, or vice versa |
| Letters display correctly but not connected/shaped properly | This is a text-rendering/shaping issue, not an encoding issue — the encoding only identifies which base characters are present, not how they should be visually joined |
| Text displays left-to-right instead of right-to-left | A bidirectional text (bidi) rendering issue, separate from character encoding — needs proper bidi-aware text layout support in the rendering context |
Compatibility & gotchas
- Windows-1256 saw wider real-world adoption than ISO-8859-6 on Windows systems specifically, similar to the pattern seen with other regional ISO-8859 variants being displaced by Windows-native code pages.
- Encoding and rendering are separate concerns for Arabic — correctly decoding the bytes into the right base characters (what the encoding handles) doesn't automatically produce correctly shaped, right-to-left rendered text (which requires separate bidi and shaping-aware rendering support).
- UTF-8 handles both concerns better in practice — not because Unicode changes text-shaping/bidi requirements, but because modern UTF-8-based rendering stacks are far more likely to have proper Arabic shaping and bidi support built in than legacy ISO-8859-6-era tooling did.
Fixing it
- Command-line conversion:
iconv -f ISO-8859-6 -t UTF-8 input.txt -o output.txt - Rendering issues after correct decoding: if the encoding is confirmed correct but text still displays wrong (unshaped letters, wrong direction), the fix is in the rendering/display layer, not the encoding conversion.
Comparison
| Encoding | Key difference from ISO-8859-6 |
|---|---|
| Windows-1256 | More commonly used in practice on Windows systems for Arabic text |
| UTF-8 | Full Unicode coverage; modern UTF-8-aware rendering stacks generally have better Arabic shaping/bidi support than legacy tooling |
FAQ
Does ISO-8859-6 handle Arabic letter shaping automatically?
No — character encoding only identifies which base letters are present in the text. Contextual letter shaping (how Arabic letters visually connect based on position in a word) is handled by separate text-rendering/shaping logic, regardless of which encoding is used.
Why does my correctly-decoded Arabic text still display wrong?
If decoding is confirmed correct but the text still looks wrong (unconnected letters, wrong reading direction), the issue is in text rendering/layout, not encoding — check for proper bidirectional text and Arabic shaping support in whatever is displaying the text.
Fun fact
Arabic text processing is a commonly cited example in internationalization (i18n) education of why "correct encoding" and "correct display" are genuinely separate problems — a text can be flawlessly decoded byte-for-byte and still render completely wrong if the rendering layer lacks proper bidirectional and contextual shaping support.