Работа с путем к файлу Unicode

Question

Работа с путем к файлу Unicode

1

В моей копии Windows разделитель путей не является обратным слэшем, а знаком валюты Корейского выигрыша, который является символом U20A9 в Unicode.

Однако, когда моя программа ищет этот символ в строке, представляющей путь к файлу, она не находит ее, даже если она отображается как ожидаемая при печати пути.

Моя программа зарегистрирована в Проводнике для отображения в меню правой кнопки мыши для файлов, поэтому он получает путь к файлу из проводника в качестве аргумента командной строки.

Что здесь происходит? Как найти разделители путей в аргументе командной строки?

dare0021 25 май 2014, в 14:46

Источник

0

Смотри мой ответ. Если вы используете правильную кодовую точку, она будет отображаться как Won, но на самом деле это разделитель пути. Какой у вас код, и какое исключение вы получаете, когда пытаетесь открыть файл?
Andy Brown 25 май 2014, в 13:18
0

Прочитав ваше объяснение, я отправился искать другую точку сбоя и обнаружил, что проверка File.exists () всегда возвращала false и вызывала проблему. Это верно для любого файла, независимо от разрешения доступа к файлу, поэтому я не думаю, что это проблема с правами доступа к файлу, хотя я еще не пытался получить доступ к файлу. Обновлюсь после попытки.
dare0021 25 май 2014, в 14:03
0

Да, мой код не может попасть в файл. FileNotFoundException Файл возвращает false для: существует, canRead, canExecute, canWrite
dare0021 25 май 2014, в 14:15
0

@ user2444520: Строго говоря, поскольку вы определили, что ваша проблема не связана с вопросом, вероятно, ее следует закрыть как «вызванную проблемой, которую больше нельзя воспроизвести», но я хотел бы сохранить отличный ответ Энди. Если вы не возражаете, я хотел бы переписать его соответственно?
Harry Johnston 26 май 2014, в 03:41
0

Здесь нет возражений. Взломать
dare0021 27 май 2014, в 04:23
0

Наконец дошли руки до этого! Надеюсь, что это встретит ваше одобрение, но если есть что-то, что вам не нравится, смело меняйте его или просто верните его в исходную версию.
Harry Johnston 24 авг. 2014, в 03:12

Показать ещё 4 комментария

Теги:

java

windows

file-io

unicode

1 ответ

Ещё вопросы

Смотри мой ответ. Если вы используете правильную кодовую точку, она будет отображаться как Won, но на самом деле это разделитель пути. Какой у вас код, и какое исключение вы получаете, когда пытаетесь открыть файл?
Прочитав ваше объяснение, я отправился искать другую точку сбоя и обнаружил, что проверка File.exists () всегда возвращала false и вызывала проблему. Это верно для любого файла, независимо от разрешения доступа к файлу, поэтому я не думаю, что это проблема с правами доступа к файлу, хотя я еще не пытался получить доступ к файлу. Обновлюсь после попытки.
Да, мой код не может попасть в файл. FileNotFoundException Файл возвращает false для: существует, canRead, canExecute, canWrite
@ user2444520: Строго говоря, поскольку вы определили, что ваша проблема не связана с вопросом, вероятно, ее следует закрыть как «вызванную проблемой, которую больше нельзя воспроизвести», но я хотел бы сохранить отличный ответ Энди. Если вы не возражаете, я хотел бы переписать его соответственно?
Наконец дошли руки до этого! Надеюсь, что это встретит ваше одобрение, но если есть что-то, что вам не нравится, смело меняйте его или просто верните его в исходную версию.

Andy Brown · Accepted Answer · 2014-05-25T11-26-00.000Z

Вы используете японскую или корейскую версию Windows? В этом случае символ пути должен по-прежнему быть U+005C, который отображается как (но не тот же код), что и символ местной валюты (например, ₩ и ¥) вместо \. Если вы попытаетесь найти U+005C вместо U+20A9, это сработает?

Но я смущен этим вопросом вашего вопроса:

Java не может открыть файл как объект File, потому что разделитель файлов в моей копии Windows не является обратным слэшем, это знак валюты корейского Won (U20A9).

Он все равно должен работать, пока вы сами не вводите тестовые пути и не используете "неправильную" версию символа валюты (и пока нет никаких других проблем с файлом). Это может помочь, если мы увидим ваш код.

Почему разные дисплеи для одного и того же кода/символа?

Причина - это страницы кода, используемые для отображения. У Каплана было сообщение в блоге об этом на MSDN, но оно исчезло. Он в основном сказал: "Японская кодовая страница 932: 0x005C - это YEN SIGN. Корейская кодовая страница 949: 0x005C - ЗВУК".

См. MSDN: соображения безопасности: международные функции (соображения безопасности для наборов символов в именах файлов).

Кодовая страница Windows и OEM-наборы символов, используемые в системах на японском языке, содержат символ Йены (¥) вместо обратного слэша (\).... При отображении Unicode на кодовую страницу на японском языке функции преобразования отображают как обратную косую черту (U + 005C), так и обычный символ Юникод Йен (U + 00A5) для этого же символа.

В соответствии с этой ссылкой выше обратите внимание, что если вы попытаетесь использовать фактические символы Won и Yen (U+00A5 и U+20A9) в качестве разделителей путей, вы не можете не отображать/сопоставлять их с U+005C.

Релевантные мелочи

Я не могу вспомнить, где я это прочитал, но это помогает понять, почему все это происходит, и почему / работает в пути к файлу.

По-видимому, причина, по которой окна используют \ вместо * nix /, - это потому, что (когда родилась DOS) кто-то, кто сделал много программ DOS в MS/IBM, использовал / как символ "switch" для DOS-программ? Это было решение, которое, ~~возможно,~~ произошло ~~даже до DOS~~ CP/M, через QDOS, до MSDOS. DOS не поддерживала каталоги, поэтому столкновение с * nix не имело значения. К тому времени, когда DOS 2.0 появился вместе с файлами и файловыми путями, они хотели создать систему имен имен файлов типа * nix, но не могли использовать "DOS-переключатель" /, поэтому вместо этого использовали \.

НО - они закодировали DOS, чтобы принять оба \ и /, поскольку они действительно предпочли бы использовать стиль * nix. (Они также добавили механизм OS для изменения символа переключателя, который я не помню, но мир Windows никогда полностью не "переключился" на стиль * nix путей и переключателей).

РЕДАКТИРОВАТЬ

Найдено: линия Shebang в Windows:

Дэйв Анхель давеа на davea.name

Вт Фев 26 03:23:58 CET 2013

Фактически причина, по которой MSDOS использовала обратную косую черту, заключалась в том, что она уже использовала косую черту для символа-переключателя. Затем для версии 2, когда жесткие диски поддерживаются в первый раз, вместо этого они использовали обратную косую черту. В то время я говорил им в поддержку вызова "switchchar", чтобы перейти к использованию тире для символа переключения и косой чертой для подкаталогов.

Повторяю мелочи - вы, вероятно, читали это здесь и / или в блоге, на который он ссылается.
Я слышал слух, что до SO была жизнь;) Я думаю, что это было в блоге Майкла Каплана, когда-то около того, когда я спрашивал его о локализации на валлийском языке. Все его сообщения, кажется, исчезли, досадно. Это хороший пост суперпользователя, хотя, по крайней мере, знания не потеряны навсегда!
@HarryJohnston И вы правы, вероятно, это было также на Остермана "Почему персонаж пути DOS" \ "? - Спасибо, что помогли мне найти его снова!
Я просто перефразировал вопрос (с одобрения ОП), чтобы лучше отразить аспект по теме и избежать путаницы, вызванной не связанной проблемой. Вы можете (или не можете) изменить свой ответ соответствующим образом.
Следует также отметить, что, хотя DOS полностью поддерживает как обратную, так и обратную косую черту, поддержка Windows для прямой косой черты немного нерешительна. Ядро его вообще не поддерживает. Большинство функций Win32 в большинстве случаев преобразуют прямую и обратную косую черту, но я не думаю, что поддержка полностью всеобъемлющая. Командная строка принимает это только иногда. :-)