К сожалению, file.encoding свойство должно быть указано при запуске JVM; к моменту ввода вашего основного метода кодировка символов, используемая String.getBytes(), и конструкторы по умолчанию InputStreamReader и OutputStreamWriter были постоянно кэшированы.
Как указывает другой пользователь, в таком особом случае, как этот, переменная среды JAVA_TOOL_OPTIONSможет использоваться для указания этого свойства, но обычно это делается следующим образом:
java -Dfile.encoding=UTF-8 … com.x.Main
Charset.defaultCharset() отразит изменения в свойстве file.encoding, но большая часть кода в основных библиотеках Java, которым необходимо определять кодировку символов по умолчанию, не использует этот механизм.
При кодировании или декодировании вы можете запросить file.encoding свойство or Charset.defaultCharset(), чтобы найти текущую кодировку по умолчанию, и использовать соответствующий метод или перегрузку конструктора, чтобы указать ее.
Поскольку к командной строке не всегда можно получить доступ или изменить, например, во встроенных виртуальных машинах или просто виртуальных машинах, запускаемых глубоко в скриптах, JAVA_TOOL_OPTIONS предусмотрена переменная, позволяющая запускать агенты в этих случаях.
При установке переменной окружения (Windows) JAVA_TOOL_OPTIONS в -Dfile.encoding=UTF8, свойство (Java) System будет устанавливаться автоматически при каждом запуске JVM. Вы будете знать, что параметр выбран, потому что следующее сообщение будет отправлено на System.err:
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF8
Ответ 3
У меня есть хакерский способ, который определенно работает!!
Таким образом, вы собираетесь обмануть JVM, которая будет думать, что кодировка не установлена, и заставите ее снова установить ее в UTF-8 во время выполнения!
Ответ 4
Я думаю, что лучшим подходом, чем установка набора символов платформы по умолчанию, тем более что у вас, похоже, есть ограничения на влияние на развертывание приложения, не говоря уже о платформе, является вызов гораздо более безопасного String.getBytes("charsetName"). Таким образом, ваше приложение не зависит от факторов, находящихся вне его контроля.
Я лично считаю, что String.getBytes() должно быть устаревшим, поскольку это вызывало серьезные проблемы в ряде случаев, которые я видел, когда разработчик не учитывал возможное изменение кодировки по умолчанию.