Управляющие символы новой строки в многобайтовых наборах символов

Question

У меня есть некоторый код Perl, который переводит новые строки и переводы строк в нормализованную форму. Вводимый текст - японский, поэтому в нем будут многобайтовые символы.

Возможно ли по-прежнему выполнять это преобразование на побайтовой основе (что, по-моему, в настоящее время делает), или мне нужно определить набор символов и включить поддержку Unicode? Другими словами, используются ли популярные кодировки (Shift-JIS, EUC-JP, UTF-8, ISO-2022-JP) байтами как частью их набора символов, который можно принять за управляющие символы ASCII?

Мне нужны только CR и LF для работы.

Обновление: Добавлен ISO-2022-JP. И это тот, который выглядит наиболее проблематичным с его броскими последовательностями побега ...

Answer 1

Ни одна из 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

И символы escape-последовательности для переключения между различными наборами символов:

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.

Answer 2

Все эти наборы символов идентичны ASCII для первых 128 кодовых точек - то есть они используют только один байт для кодирования символов ASCII, включая CR (0x0D) и LF (0x0A). У вас не должно быть никаких проблем.

Answer 3

ISO-2022-JP использует Shift-In / Shift-Out для назначения различных значений 94 печатным символам ASCII, оставляя управляющие символы, включая CR и LF, без изменений.

Answer 4

Вот (нормативная) деталь в кодировке UTF-8: «[…] значения 0x00..0x7F не появляются ни в одном байте для представления любой другой кодовой точки Unicode […].» Стандарт Unicode® - Версия 11.0 - Основные характеристики »- июнь 2018 года - https://www.unicode.org/versions/Unicode11.0.0/UnicodeStandard-11.0.pdf