Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[98.80.143.34] |
|
Сообщ.
#1
,
|
|
|
Продолжаю натыкаться на Явовские пережитки прошлого.
String в Unicode. Я думал, что пути к файлам и их содержимое по умолчанию в Unicode, но... оказывается IDE сам его ставит! Запуск в Eclipse: sun.jnu.encoding=Cp1251 file.encoding=UTF-8 Запуск через java -jar: sun.jnu.encoding=Cp1251 file.encoding=Cp1251 Даже http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8003228 висит. Почему не включили Unicode везде? |
Сообщ.
#2
,
|
|
|
Во-первых, String в UTF-16, а для ввода-вывода обычно используется UTF-8. Переходите на Linux: там UTF-8 везде и всюду.
А Java честно берёт по умолчанию системную кодировку. Так что это не явовские пережитки, а виндовые. |
Сообщ.
#3
,
|
|
|
Цитата kopilov @ А Java честно берёт по умолчанию системную кодировку. Так что это не явовские пережитки, а виндовые. Не системную кодировку она берет! В .НЕТ тоже Unicode по умолчанию. И, судя по багу, на Маке Ява тоже кодировку путает. Так что это явовские пережитки, а не виндовые. Добавлено То, что берет Ява, осталось из-за совместимости с Виндами 9х. |
Сообщ.
#4
,
|
|
|
Цитата с чего вы взяли? очень даже системную. Не системную кодировку она берет! и по ссылке просто сказано что на макоси конкретно sun.jnu.encoding берётся как file.encoding по дефолту, но предлагается насильно использовать utf-8, это уже подразумевает, что проблема тогда бывает, когда file.encoding не utf-8 Добавлено Цитата Keepun @ Почему не включили Unicode везде? Ну и вообще вопрос странный. Во внутреннем предствлении всегда изначально было "в юникоде" (строки в utf-16 конкретно, но это к делу не относится, т.к. смысла эта информация не имеет), другое дело, что для внешних операций тех или иных указываются отдельно кодировки, которые исторически берутся по-разному. раз в windows она 1251 то значит так и есть, чего поделать то. В винде внутри строки тоже всю жизнь "в юникоде", но это тоже к делу не относится. |
Сообщ.
#5
,
|
|
|
Цитата dark_barker @ с чего вы взяли? очень даже системную. Это указатель на предпочтительную однобайтовую кодировку при конвертации из UCS-2. UCS-2 - вот системная кодировка Винды НТ. В C# Encoding.Default возвращает только однобайтовую кодировку: Цитата For these two reasons, using the default encoding is generally not recommended. To ensure that encoded bytes are decoded properly, your application should use a Unicode encoding, such as UTF8Encoding or UnicodeEncoding, with a preamble. А файлы по умолчанию открываются в Encoding.UTF8 всегда. В Яве же Charset.defaultCharset() может любой бред вернуть... |
Сообщ.
#6
,
|
|
|
Поясните что вы называете системной кодировкой винды НТ? Какой ещё указатель? При конвертации из UCS-2 откуда и куда? Про что вы вообще говорите?
А при работе с файлами и так по-хорошему нужно явно указывать кодировку, т.к. "кодировка файлов" это то, что относится исключительно к их содержимому, чисто пользовательская область, и к ОС вообще никакого отношения не имеет. Ну да, если кодировку для ридера/стрима не указать явно, и если не указать в лаунчере через file.encoding явно и в разных прочих переменных [окружения] если не указать явно, то в некоторых системах по дефолту откроет не в UTF-8. В этом суть вашей проблемы? Очень как-то надумано как по мне. Мало того, думаю, если убрать дефолтные поведения для неуказанной кодировки, то местами будет может даже правильнее. Т.к. это последнее время utf-8 стал для этого вроде как стандартом де-факто, а совсем недавно такое поведение непонятное было абсолютным злом. Не говоря уж о начале 90х, когда ява проектировалась. Потому не очень понятно: 1. суть претензий; 2. в чём именно проблема в данный момент у вас. Добавлено К чему вы сказали про usc-2? Если речь про внутреннее представление строк в ядре и api, то какое это вообще отношение имеет к дефолтной кодировке при открытии файлов? Добавлено Цитата В Яве же Charset.defaultCharset() может любой бред вернуть... ну вообще, опять же, он возвращает file.encoding. а если её нету, то UTF-8, емнип. какой он бред может вернуть то? |
Сообщ.
#7
,
|
|
|
Цитата dark_barker @ ну вообще, опять же, он возвращает file.encoding. а если её нету, то UTF-8, емнип. "А если её нету, то" НЕ UTF-8 он вернет и не мечтай... |
Сообщ.
#8
,
|
|
|
Keepun, радуйся:
Цитата Из новшеств Java 18 можно отметить: По умолчанию задействована кодировка UTF-8. Java API, обрабатывающие текстовые данные с учётом кодировки символов, теперь будут по умолчанию использовать UTF-8 на всех платформах, независимо от системных настроек и выставленной локали. Для возвращения старого поведения, в котором кодировка выбирается с учётом системной локали, можно использовать параметр "-Dfile.encoding=COMPAT". |