Big5 Big5 (Traditional Chinese) Legacy & Platform-Specific
The dominant legacy Traditional Chinese encoding, used in Taiwan, Hong Kong, and Macau — not compatible with GB-family Simplified Chinese encodings.
What it is
Big5 is a variable-width encoding for Traditional Chinese characters, historically dominant in Taiwan, Hong Kong, and Macau — regions that use Traditional rather than Simplified Chinese characters. It developed independently from the GB-family encodings (GB2312, GBK, GB18030) used in mainland China, and the two lineages are not byte-compatible with each other despite both encoding Chinese text.
Byte structure
| Byte pattern | Length | Content |
|---|---|---|
| 0x00–0x7F | 1 byte | ASCII-compatible range |
| Two high-bit-set bytes | 2 bytes | Traditional Chinese characters |
Why your text is garbled (symptom → cause)
| Symptom | Likely cause |
|---|---|
| Traditional Chinese text shows as unrelated symbols | Big5/UTF-8 double-decode mismatch, or confusion with a GB-family encoding |
| Text correct in Taiwan/Hong Kong-originated software, garbled in mainland China-originated tooling | GB-family (Simplified) vs. Big5 (Traditional) encoding mismatch — these represent genuinely different character sets, not just different byte layouts for the same characters |
| Some characters correct, others garbled within the same document | Possible mixing of Big5 with a GB-family encoding somewhere in the pipeline, or a Big5 variant/extension mismatch (several extended Big5 variants exist with vendor-specific additions) |
Compatibility & gotchas
- Not compatible with GB2312/GBK/GB18030 — these are two genuinely separate encoding lineages (Traditional vs. Simplified Chinese), not just different byte assignments for the same character repertoire. Converting between them requires actual character-set conversion, not just re-encoding.
- Several extended Big5 variants exist (Big5-HKSCS being a notable one, adding characters needed for Hong Kong-specific usage) with vendor and region-specific additions — "Big5" as a label doesn't always guarantee identical behavior across systems.
- Largely superseded by UTF-8 in current software, though legacy Big5 data remains common in older Traditional-Chinese-region systems, particularly Taiwan and Hong Kong.
Fixing it
- Command-line conversion:
iconv -f BIG5 -t UTF-8 input.txt -o output.txt(tryBIG5HKSCSif standard Big5 fails to decode certain Hong Kong-specific characters) - Converting between Big5 and GB-family encodings: this requires going through UTF-8 as an intermediate step and, in some cases, actual Traditional-to-Simplified character conversion (a linguistic conversion, not just an encoding one) if the target system expects Simplified characters specifically.
Comparison
| Encoding | Key difference from Big5 |
|---|---|
| GB18030 / GBK / GB2312 | Cover Simplified Chinese characters, a genuinely different (though related) character repertoire, used primarily in mainland China |
| UTF-8 | Full Unicode coverage including both Traditional and Simplified Chinese, the modern default |
FAQ
Is Big5 compatible with GB2312 or GBK?
No — they're separate encoding lineages covering different character sets (Traditional vs. Simplified Chinese). Converting between them requires actual character-set translation, not just re-encoding the same underlying characters.
Where is Big5 still used?
Historically dominant in Taiwan, Hong Kong, and Macau; legacy Big5 data still appears in older software and documents from those regions, though UTF-8 is now the standard choice for new development.
What's Big5-HKSCS?
An extended Big5 variant (Hong Kong Supplementary Character Set) adding characters specifically needed for Hong Kong usage that standard Big5 doesn't cover — relevant when working with Hong Kong-originated legacy text specifically.
Fun fact
Despite "Traditional" and "Simplified" Chinese sounding like they might just be stylistic variants of the same characters, many characters differ enough structurally that Big5 and the GB-family encodings needed to assign genuinely different byte sequences to represent them — the encoding-level incompatibility mirrors a real linguistic/orthographic divide between the two writing conventions, not just an arbitrary technical choice.