多字节字符集中的换行控制字符答案

【问题标题】：Newline control characters in multi-byte character sets多字节字符集中的换行控制字符
【发布时间】：2010-10-17 23:27:48
【问题描述】：

我有一些 Perl 代码可以将换行符和换行符转换为规范化形式。输入文字是日文，所以会有多字节字符。

是否仍然可以逐字节地进行这种转换（我认为目前是这样），还是我必须检测字符集并启用 Unicode 支持？换句话说，流行的编码（Shift-JIS、EUC-JP、UTF-8、ISO-2022-JP）是否使用字节作为其字符集的一部分，可能会被误认为是 ASCII 控制字符？

我只需要 CR 和 LF 就可以工作。

更新：添加了 ISO-2022-JP。这就是它的时髦转义序列看起来最麻烦的一个......

【问题讨论】：

标签： unicode character-encoding newline cjk

【解决方案1】：

这里是 UTF-8 编码的（规范）细节：«[...] 值 0x00..0x7F 不会出现在任何字节中，以表示任何其他 Unicode 代码点 [...]。» — 来自«Unicode® 标准 — 版本 11.0 – 核心规范» — 2018 年 6 月 — https://www.unicode.org/versions/Unicode11.0.0/UnicodeStandard-11.0.pdf

【讨论】：

【解决方案2】：

您提到的 4 种编码（Shift-JIS、UTF-8、EUC-JP、ISO-2022-JP）均未在日文字符中使用 CR 或 LF 字符。对于 UTF-8 和 EUC-JP，低 ascii 字符和日语字符中的字节之间没有任何重叠。但是，对于 Shift-JIS 和 ISO-2022-JP，存在重叠，但不在您找到 CR 和 LF 的范围内。

For ISO-2022-JP,
First-byte range: 0x21 - 0x7E
Second-byte range: 0x21 - 0x7E

以及在各种字符集之间来回切换的转义序列字符是：

0x1B, 0x28, 0x24, 0x40, 0x42, and 0x4A

如您所见，ISO-2022-JP 中用于对日文字符进行编码的字符没有一个与 CR 或 LF 重叠。

For Shift-JIS,
First-byte range: 0x81 - 0x9F, 0xE0 - 0xEF
Second-byte range: 0x40 - 0x7E, 0x80 - 0xFC
Half-width katakana: 0xA1 - 0xDF

同样，CR 和 LF 没有重叠。

【讨论】：

【解决方案3】：

ISO-2022-JP 使用 Shift-In/Shift-Out 为 94 个可打印的 ASCII 字符分配不同的含义，使包括 CR 和 LF 在内的控制字符保持不变。

【讨论】：

【解决方案4】：

对于前 128 个代码点，所有这些字符集都与 ASCII 相同——也就是说，它们只使用一个字节来编码 ASCII 字符，包括 CR (0x0D) 和 LF (0x0A)。你应该没有任何问题。

【讨论】：

我担心即使 ASCII 保持不变，多字节字符的第二个字节也可能看起来像 ASCII。还是额外的字节都来自“上半部分”？
至少对于 UTF-8，似乎是这样：每个“第二”字节看起来像 '10xx xxxx'。
在 Shift-JIS 中，第二个字节不一定会设置高位，但看起来它可以拥有的最小值是 0x40。在 EUC-JP 中，第二个和第三个字节将始终为 0x80 或更高。
谁对我投了反对票？如果是因为 ISO-2022-JP，那么当我回答它时，这不是问题的一部分，但是（正如其他两位响应者指出的那样）它与其他编码相比没有问题。
没关系，每个人群中都有一个匿名的反对者 :-( 实际上，在 EBCDIC（IBM 大型计算机）世界之外，CR 或 LF 在我所知道的任何编码上都没有问题 - - 你不想去那里:-) ISO-2022-JP 在 JIS 字符集和 ASCII 之间愉快地切换，CR/LF 绝对没有问题。