EUC-JP EUC-JP (Extended Unix Code, Japanese) Legacy & Platform-Specific
The Unix-world counterpart to Shift-JIS for Japanese text — historically dominant on Unix/Linux systems while Shift-JIS ruled Windows.
What it is
EUC-JP (Extended Unix Code, Japanese variant) is a variable-width Japanese text encoding that was historically dominant on Unix and Linux systems, mirroring the role Shift-JIS played on Windows. The two encodings competed directly for Japanese text for years, and — like the Shift-JIS/EUC-JP split for Korean (EUC-KR vs. other options) — this platform-driven encoding fragmentation was a major real-world source of Japanese text mojibake before UTF-8 unified things.
Byte structure
| Byte pattern | Length | Content |
|---|---|---|
| 0x00–0x7F | 1 byte | ASCII-compatible range |
| 0x8E + trail byte | 2 bytes | Half-width katakana |
| Two high-bit-set bytes | 2 bytes | Kanji and other standard Japanese characters (JIS X 0208) |
| 0x8F + two more bytes | 3 bytes | Supplementary/less common characters (JIS X 0212) |
Why your text is garbled (symptom → cause)
| Symptom | Likely cause |
|---|---|
| Japanese text shows as unrelated kanji/scattered symbols | Classic EUC-JP/Shift-JIS/UTF-8 three-way mismatch |
| Text correct in Unix/Linux-originated files, garbled when opened on Windows-originated tooling | Platform-driven encoding split — files created in Unix contexts historically defaulted to EUC-JP, Windows contexts to Shift-JIS |
Compatibility & gotchas
- The platform divide (Unix → EUC-JP, Windows → Shift-JIS) is largely historical but still explains a lot of legacy data inconsistency — files from older Unix-originated systems and Windows-originated systems may use different Japanese encodings even within the same organization's archives.
- Distinct byte structure from Shift-JIS — no shortcut for guessing; testing decode results against expected readable Japanese text (or using automated charset detection) is the practical approach for unlabeled legacy files.
- Largely superseded by UTF-8 in current Japanese-language software development, resolving the platform-driven fragmentation that made this encoding pair such a persistent mojibake source.
Fixing it
- Command-line conversion:
iconv -f EUC-JP -t UTF-8 input.txt -o output.txt - If unsure whether text is EUC-JP or Shift-JIS: try both conversions and check which produces coherent Japanese output, or use an automated charset-detection library.
Comparison
| Encoding | Key difference from EUC-JP |
|---|---|
| Shift-JIS | The historically competing Japanese encoding, more common on Windows systems, different byte layout |
| UTF-8 | Full Unicode coverage, the modern unifying default |
FAQ
Why did Unix and Windows use different Japanese encodings?
Largely historical platform-specific conventions that developed somewhat independently before internet-scale interoperability made the inconsistency a bigger practical problem — Unix-world software gravitated toward EUC-JP, Windows-world software toward Shift-JIS, and the split persisted for years before UTF-8 became the practical unifying choice.
How do I tell if a file is EUC-JP or Shift-JIS?
Without an explicit label, it usually requires trial and error (attempting to decode with each and checking for coherent output) or an automated charset-detection library, since the byte structures are different enough that most malformed decodes produce obviously garbled results.
Fun fact
The "Extended Unix Code" naming convention EUC-JP belongs to was actually a general framework applied to multiple East Asian languages — EUC-KR (Korean) and EUC-CN (an older Chinese variant, predecessor to GB2312-based approaches) followed the same basic structural pattern, adapted for their respective character sets.