Комментарии 25
Байтов 18, потому что начиная с Java 9 если символ помещается в однобайтовый промежуток, он будет весить 1 байт, плюс по два на символы в «Привет».
В данном случае не поэтому, а потому, что попросили байты в кодировке UTF-8. Так будет на любой джаве.
Минус один аргумент между .net vs java 🙂
.NET с выходом Core 2.0
разве в .NET Framework под капотом не с самого начала был UTF-16?
С самого.
String как был UTF-16 с первой версии, таким и остался.
Источник: String Class (System) | Microsoft Learn
Под капотом действительно UTF-16. Что мне понравилось, ровно как и в Java, методы класса System.IO.File по умолчанию вне зависимости от системы выдадут UTF-8. А вот Encoding.Default, которым пользуются остальные для определения кодировки по умолчанию, в .NET Framework смотрит на систему, и на винде выдаст что-то ANSI-подобное – в отличие от .NET Core.
Вот, например, официальная документация к Framework говорит об этой разнице. Или хорошо это подмечено тут
лучше использовать рабочую
https://web.archive.org/web/20201027153639/https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4163515
Вообще проблема выглядит несколько надуманной, чтобы ради неё писать целый jep и целую статью. Если на машине не настроена правильная кодировка, то винавата не джава, а пользователь. В питоне, например, надо указывать кодировку при перекодировании str в bytes и никто не кашляет.
Да, при этом в тексте упоминается как проблема вызов Files.write(path, str.getBytes()) и Files.readString(path). Конечно же в String.getBytes() и Files.readString() можно передать Charset.
Да-да, давайте ради Java перенастраивать все локализованные установки windows! Притом ломая совместимость с другими программами...
Я считаю, что появление Console.charset() только в 2022м году — это позор для языка, который делался как кроссплатформенный.
В смысле? У нас есть система, в ней установлена кодировка по умолчанию, джава использует кодировку по умолчанию. Всё правильно и логично. Если нужна другая кодировка она явно указывается. Опять всё правильно и логично. Так было раньше. Теперь же есть система, в ней установлена кодировка по умолчанию, но джава использует UTF-8. Как-будто не очень логично.
Вот только оказалось, что большинство файлов должны писаться в переносимой кодировке, а не в кодировке по умолчанию. Ну и зачем в итоге нужны такая умолчания, которое в большинстве случаев переопределяются?
И про Console.charset() не забывайте.
Если приложению нужно писать в определённой кодировке, то оно должно указывать кодировку. Если приложению нужно взаимодействовать с "неопределённым кругом" приложений на этой же машине, оно должно использовать кодировку установленную на этой машине. Если в первом случае разработчик не указал кодировку, ожидая этого от пользователя, то виноват разработчик, а не джава. Если во втором случае пользователь настроил не ту кодировку, то виноват пользователь, а не джава. Должна ли джава думать за пользователя или разработчика в этом случае? Думаю, нет.
Проблема еще в том, что Windows уже давно использует Unicode. System locale используется для программ, которые не поддерживают Unicode. Это прямо написано при установки кодировки
Не понятно зачем Java на это ориентировалась.
UTF-8 использует переменное количество байт на один символ — от 1 до 6.Только до четырёх.
В ноябре 2003 года стандарт RFC 3629 запретил использование пятого и шестого байтов, а диапазон кодируемых символов был ограничен символом U+10FFFF. Это было сделано для обеспечения совместимости с UTF-16.
Т.е. Java осталась без иероглифов или как?
Автор смешивает таблицу символов Unicode и стандарты её кодирования UTF-8, UTF-16 и т. д.
.NET Framework поддерживает Unicode с первой версии, кодируя текст в своих классах в UTF-16 (как и весь текстовый API Windows). Encoding.UTF8 поддерживается как минимум с версии 1.1 (источник Encoding.UTF8 Property (System.Text) | Microsoft Learn)
По заголовку статьи сразу видно, что закодировали русские буквы как UTF8, а прочитали как cp1251.
Write once, run anywhere...
... except Windows of course.
JEP-400 или UTF-8 РєРѕРґРёСЂРѕРІРєР° РїРѕ умолчанию