Цитата dark_barker @
ну вообще, опять же, он возвращает file.encoding. а если её нету, то UTF-8, емнип.
"А если её нету, то" НЕ UTF-8 он вернет
и не мечтай... | Версия для печати
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум на Исходниках.RU > Java > Почему не Unicode? |
| Автор: Keepun 09.04.14, 18:10 |
| Продолжаю натыкаться на Явовские пережитки прошлого. 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 везде? |
| Автор: kopilov 10.04.14, 18:49 |
| Во-первых, String в UTF-16, а для ввода-вывода обычно используется UTF-8. Переходите на Linux: там UTF-8 везде и всюду. А Java честно берёт по умолчанию системную кодировку. Так что это не явовские пережитки, а виндовые. |
| Автор: Keepun 11.04.14, 03:10 |
| Цитата kopilov @ А Java честно берёт по умолчанию системную кодировку. Так что это не явовские пережитки, а виндовые. Не системную кодировку она берет! В .НЕТ тоже Unicode по умолчанию. И, судя по багу, на Маке Ява тоже кодировку путает. Так что это явовские пережитки, а не виндовые. Добавлено То, что берет Ява, осталось из-за совместимости с Виндами 9х. |
| Автор: dark_barker 12.04.14, 15:54 |
| Цитата с чего вы взяли? очень даже системную. Не системную кодировку она берет! и по ссылке просто сказано что на макоси конкретно sun.jnu.encoding берётся как file.encoding по дефолту, но предлагается насильно использовать utf-8, это уже подразумевает, что проблема тогда бывает, когда file.encoding не utf-8 Добавлено Ну и вообще вопрос странный. Во внутреннем предствлении всегда изначально было "в юникоде" (строки в utf-16 конкретно, но это к делу не относится, т.к. смысла эта информация не имеет), другое дело, что для внешних операций тех или иных указываются отдельно кодировки, которые исторически берутся по-разному. раз в windows она 1251 то значит так и есть, чего поделать то. В винде внутри строки тоже всю жизнь "в юникоде", но это тоже к делу не относится. |
| Автор: Keepun 12.04.14, 21:55 |
| Это указатель на предпочтительную однобайтовую кодировку при конвертации из 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() может любой бред вернуть... |
| Автор: dark_barker 13.04.14, 08:16 |
| Поясните что вы называете системной кодировкой винды НТ? Какой ещё указатель? При конвертации из UCS-2 откуда и куда? Про что вы вообще говорите? А при работе с файлами и так по-хорошему нужно явно указывать кодировку, т.к. "кодировка файлов" это то, что относится исключительно к их содержимому, чисто пользовательская область, и к ОС вообще никакого отношения не имеет. Ну да, если кодировку для ридера/стрима не указать явно, и если не указать в лаунчере через file.encoding явно и в разных прочих переменных [окружения] если не указать явно, то в некоторых системах по дефолту откроет не в UTF-8. В этом суть вашей проблемы? Очень как-то надумано как по мне. Мало того, думаю, если убрать дефолтные поведения для неуказанной кодировки, то местами будет может даже правильнее. Т.к. это последнее время utf-8 стал для этого вроде как стандартом де-факто, а совсем недавно такое поведение непонятное было абсолютным злом. Не говоря уж о начале 90х, когда ява проектировалась. Потому не очень понятно: 1. суть претензий; 2. в чём именно проблема в данный момент у вас. Добавлено К чему вы сказали про usc-2? Если речь про внутреннее представление строк в ядре и api, то какое это вообще отношение имеет к дефолтной кодировке при открытии файлов? Добавлено Цитата В Яве же Charset.defaultCharset() может любой бред вернуть... ну вообще, опять же, он возвращает file.encoding. а если её нету, то UTF-8, емнип. какой он бред может вернуть то? |
| Автор: Keepun 13.04.14, 18:03 |
| Цитата dark_barker @ ну вообще, опять же, он возвращает file.encoding. а если её нету, то UTF-8, емнип. "А если её нету, то" НЕ UTF-8 он вернет и не мечтай... |
| Автор: kopilov 23.03.22, 12:27 |
| Keepun, радуйся: Цитата Из новшеств Java 18 можно отметить: По умолчанию задействована кодировка UTF-8. Java API, обрабатывающие текстовые данные с учётом кодировки символов, теперь будут по умолчанию использовать UTF-8 на всех платформах, независимо от системных настроек и выставленной локали. Для возвращения старого поведения, в котором кодировка выбирается с учётом системной локали, можно использовать параметр "-Dfile.encoding=COMPAT". |