Ваша проблема немного расплывчата. Вы упомянули, что -Dfile.encoding
решил вашу проблему с Linux, но фактически он используется только для информирования Sun (!) JVM, какую кодировку использовать для управления именами файлов / путями в локальной файловой системе диска. И ... это не вписывается в описание проблемы, которое вы дали буквально: «преобразование символов в байты и обратно в символы не удалось». Я не вижу, что -Dfile.encoding
имеет к этому отношение. Там должно быть больше в истории. Как вы пришли к выводу, что это не удалось? Вы читали / записывали эти символы из / в путь / имя файла или около того? Или вы печатали на стандартный вывод? Использовал ли stdout правильную кодировку?
Тем не менее, почему вы хотите преобразовать символы вперед и назад в / из байтов? Я не вижу каких-либо полезных деловых целей для этого.
(извините, это не вписалось в комментарий, но я обновлю его ответом, если вы предоставите больше информации о фактическом функциональном требовании ).
Обновление: согласно комментариям: вам просто нужно настроить stdout / cmd, чтобы он использовал правильную кодировку для отображения этих символов. В Windows вы можете сделать это с помощью команды chcp
, но есть одно важное предостережение: стандартные шрифты, используемые в Windows cmd, не имеют надлежащих глифов (фактических изображений шрифтов) для символов вне ISO-8859. кодировок. Вы можете взломать тот или другой в реестре , чтобы добавить правильные шрифты. Никаких формулировок о Linux, потому что я не делаю это широко, но похоже, что -Dfile.encoding
- это какой-то путь. В конце концов ... я думаю, что лучше заменить cmd инструментом кроссплатформенного интерфейса для отображения символов так, как вы хотите, например Swing .