//non-utf source file encoding
char ch = 'ё'; // some number within 0..65535 is stored in char.
System.out.println(ch); // the same number output to
"внутренняя кодировка Java — UTF16". Где он осмысленно играет в этом?
Кроме того, я могу идеально поместить в char один кодовый модуль utf16 из суррогатного диапазона (скажем, '���'), что сделает этот char абсолютно недействительным Unicode. И давайте останемся в BMP, чтобы не думать, что у нас может быть 2 символа (codeunit) для дополнительного символа (думать, что таким образом звучит для меня, что «char внутренне использует utf16» — полная ерунда). Но может быть, "char внутренне использует utf16" имеет смысл в BMP?
Я мог бы понять это, если бы было так: мой файл исходного кода находится в кодировке Windows-1251, литерал char преобразуется в число в соответствии с кодировкой Windows-1251 (что на самом деле происходит), затем это число автоматически преобразуется в другое число (из Windows -1251 номер в номер utf-16) - чего НЕ происходит (я прав?! это я мог понять как «внутренне использует UTF-16»). И затем этот сохраненный номер записывается (на самом деле он записывается как заданный, как из win-1251, никакого моего «воображаемого преобразования из внутренней utf16 в кодировку вывода\консоли» не происходит), консоль показывает, что это преобразование из числа в глиф с помощью консоли кодирование (что происходит на самом деле)
Таким образом, эта «внутренняя кодировка UTF16» НИКОГДА НЕ ИСПОЛЬЗУЕТСЯ ??? char просто хранит любое число (в [0..65535]), и, кроме определенного диапазона и «без знака», НЕ ОТЛИЧАЕТСЯ ОТ int (конечно, в рамках моего примера)???
P.S. Экспериментально код выше с кодировкой UTF-8 исходного файла и выводов консоли
й
1081
с кодировкой исходного файла win-1251 и UTF-8 в выводе консоли
�
65533
Тот же вывод, если мы используем String вместо char...
String s = "й";
System.out.println(s);
В API все методы, принимающие char в качестве аргумента, обычно никогда не принимают в качестве аргумента кодировку. Но методы, принимающие byte[] в качестве аргумента, часто принимают кодировку в качестве другого аргумента. Подразумевается, что с char нам не нужна кодировка (это означает, что мы точно знаем эту кодировку). Но **как мы узнаем, в какой кодировке что-то было помещено в char???
Если char — это просто хранилище для числа, нам нужно понять, из какой кодировки исходно получено это число?**
Итак, char vs byte — это всего лишь то, что char имеет два байта чего-то с кодировкой UNKNOWN (вместо одного байта НЕИЗВЕСТНАЯ кодировка байта). Учитывая некоторую инициализированную переменную char, мы не знаем, какую кодировку использовать для ее правильного отображения (чтобы выбрать правильную кодировку консоли для вывода), мы не можем сказать, какая была кодировка исходного файла, где он был инициализирован литералом char (не считая случаев совместимости различных кодировок и utf).
Я прав, или я большой идиот? Извините за вопрос в последнем случае :)))
Исследование SO не дает прямого ответа на мой вопрос:
