在中文/日文的情况下，代码页如何工作？
它无法在一个字节的限制内对这些语言的所有字母字符进行编码，那么它是如何工作的呢？
请注意，我正在考虑Unicode之前的时间。
我最熟悉日语，但一般来说，对于任何需要比单个字节容纳更多的字符的语言，策略都是相同的 - 您使用可变宽度的多字节编码，其中某些字节被识别为开始"宽"字符，而 ASCII 被单独保留。
在早期，所谓的"ASCII-safe"编码是有用的。它们仅使用七位（高位始终为 0），因此它们与各种系统（包括硬件）一起工作，这些系统只期望控制字符在任何字节中设置高位。ISO-2022-JP 就是其中之一，并且仍然经常在电子邮件中使用（主要是在功能手机上）。
如果您不对其进行解码，以下是 ISO-2022-JP 的外观：
echo "日本語" | iconv -f utf8 -t iso2022jp | cat -v
^[$BF|K8l^[(B
请注意，"test"保持不变，所有其他字符都是有效的 ASCII; ^[ 是 ASCII 转义字符。（ISO-2022 也有 8 位版本，但 7 位是最常用的版本。
后来的可变宽度编码，如 EUC、Shift-JIS 和 UTF-8，都遵循相同的原理，只是它们使用二进制（非 ASCII）转义，因此任何多字节字符的第一个字符都设置了高位（即，无符号字节值为>128）。维基百科关于 UTF-8 的文章有一个很好的表格来解释 UTF 如何处理这个问题。就像较旧的 ASCII 安全编码一样，这些编码使 ASCII 字符串保持不变。
也存在固定宽度的多字节编码，但它们相对不常见。有人试图推广一种只使用两个字节的编码，称为"UCS-2"，但它最终没有足够的空间容纳足够的字符，并且在 1990 年代主要被可变宽度的 UTF-16 取代。 UTF-16（实际上）是 Java 和 Javascript 中使用的内部编码，但由于 UCS-2 的历史，有时字符串长度之类的东西会以奇怪的方式工作。
技术上固定宽度的 UTF-32 存在，但它没有被广泛使用，我个人从未在野外遇到过它。