Как найти путь к файлу в кодировке текста, используемой PosteRazor?

Обновление: Следующая команда может быть использована:

xclip -out -selection clipboard -target STRING | iconv - из кода ISO-8859-15 - в код UTF-8 | Буфер обмена xclip -in -selection 

Для объяснения прочитайте полный ответ.

---

Чтобы полностью понять ответ, вы должны понимать кодовые точки Unicode и кодировку Unicode.

Ниже приведены краткие определения и объяснения необходимых терминов, но я рекомендую вам прочитать о них из источников, упомянутых в конце ответа.

• Unicode Code Space: диапазон целых чисел от 0 до 10FFFF ₁₆.

• Кодовые точки Unicode: любое значение в кодовом пространстве Unicode. Кодовая точка соответствует символу, хотя не все кодовые точки назначаются кодированным символам.

• UTF-8: UTF-8 (8-битный формат преобразования UCS) - это кодирование с переменной шириной, которое может представлять каждый символ в наборе символов Unicode. UCS обозначает универсальный набор символов.

  Первые 128 символов (US-ASCII) требуют одного байта. Следующим 1920 символам нужно два байта для кодирования. Это охватывает почти все алфавиты латинского происхождения, а также алфавиты греческого, кириллического, коптского, армянского, иврита, арабского, сирийского и танского, а также сочетания диакритических знаков.

  Это указывает на то, что персонаж é что вызывает проблемы занимает два байта для кодирования в UTF-8. Мы проверим это с помощью некоторых команд.

• ISO / IEC 8859-15: 8-битные однобайтовые наборы кодированных графических символов.

---

Чтобы проверить, я сделал каталог /home/green/Pictures/café/,

После копирования местоположения из nautilus , выходные данные команд были следующими:

Команда № 1:

Буфер обмена $ xclip -out -selection -target STRING | hexdump -C
00000000  2f 68 6f 6d 65 2f 67 72  65 65 6e 2f 50 69 63 74  |/home/green/Pict|
00000010  75 72 65 73 2f 63 61 66  e9 2f                    |ures/caf./|
0000001a

Обратите внимание, что кодировка café является 63 61 66 e9, что хорошо, так как кодовая точка Unicode U+00E9 представляет {LATIN SMALL LETTER E WITH ACUTE} или же é,

Команда № 2:

Буфер обмена $ xclip -out -selection -ttarget UTF8_STRING | hexdump -C
00000000  2f 68 6f 6d 65 2f 67 72  65 65 6e 2f 50 69 63 74  |/home/green/Pict|
00000010  75 72 65 73 2f 63 61 66  c3 a9 2f                 |ures/caf../|
0000001b

В приведенном выше выводе, café кодируется как 63 61 66 c3 a9, Это тоже хорошо, потому что кодировка UTF-8 кодовой точки U+00E9 (соответствует é) является \xC3\xA9 (\x используется для представления того, что следующие символы являются шестнадцатеричными числами).

\xC3 представляет 1 байт и так \xA9, Таким образом, UTF-8 нужно 2 байта для представления é,

После копирования того же текста из PosteRazor выходы команд были:

Команда № 1:

Буфер обмена $ xclip -out -selection -target STRING | hexdump -C
00000000  2f 68 6f 6d 65 2f 67 72  65 65 6e 2f 50 69 63 74  |/home/green/Pict|
00000010  75 72 65 73 2f 63 61 66  c3 a9 2f                 |ures/caf../|
0000001b

Очевидно, что кодовые точки Unicode перепутаны. Теперь у нас есть две кодовые точки (c3 а также a9) где должен быть только один (e9).

Неудивительно, что две кодовые точки, т.е. U+00C3 а также U+00A9 стоять за {LATIN CAPITAL LETTER A WITH TILDE} А ТАКЖЕ {COPYRIGHT SIGN} что мы видели в PosteRazor,

Команда № 2:

Буфер обмена $ xclip -out -selection -ttarget UTF8_STRING | hexdump -C
00000000  2f 68 6f 6d 65 2f 67 72  65 65 6e 2f 50 69 63 74  |/home/green/Pict|
00000010  75 72 65 73 2f 63 61 66  c3 a9 2f                 |ures/caf../|
0000001b

Вывод этой команды, похоже, остался неизменным, но есть небольшая разница.

В предыдущем выводе \xc3\xa9 образуется один символ, тогда как сейчас \xc3 формирует одного персонажа самостоятельно и \xa9 образует другого персонажа (которые Ã а также © соответственно).

---

Теперь мы знаем, что происходит, но как это происходит? Чтобы смоделировать то же самое, мы будем использовать Python. Я использую Python 3.3.0 здесь.

>>> импорт unicodedata
>>> a = u'/home/green/Pictures/cafe'
>>> а
"/ Дом / зеленый / Фотографии / кафе"
>>> a = a.encode('utf-8')
>>> а
б '/ дом / зеленый / Фотографии / кафе \xc3\xA9'
>>> a = a.decode('iso-8859-15')
>>> а
'/ Дом / зеленый / Фотография / Каф ©'
>>> a = a.encode('utf-8')
>>> а
б '/ дом / зеленый / Фотографии / кафе \xc3\x83\xc2\xA9'

Вы можете видеть, что если мы сначала закодируем строку, используя UTF-8, а затем декодируем, используя ISO-8859-15, то мы получим ту же строку, которую мы получаем при использовании PosteRazor,

Теперь обратите внимание на следующий код. Здесь мы также скопировали и вставили местоположение из nautilus:

>>> z = u '/ home / green / Pictures / cafe'
>>> з
"/ Дом / зеленый / Фотографии / кафе"
>>> z = z.encode('iso-8859-15')
>>> з
б '/ дом / зеленый / Фотографии / кафе \ xE9'
>>> z = z.decode('iso-8859-15')
>>> з
"/ Дом / зеленый / Фотографии / кафе"

Если бы мы изначально закодировали строку с использованием ISO-8859-15, мы бы получили идеальный результат.

Обратите внимание, что \xe9 это кодировка для é в ISO-8859-15, который, по-видимому, нуждается в одном байте. Это то же самое, что и кодовая точка Unicode U+00E9, которая при кодировании в UTF-8 требует 2 байта и представлена \xc3\xa9,

Теперь, когда мы знаем, что и как все происходит, как мы можем это исправить? Ну, вы можете либо преобразовать пути в набор символов ISO-8859-15, либо вы можете просто использовать графический интерфейс для выбора файлов.

---

Источники и дополнительная информация:

• Unicode 6.2.0 PDF - часть 3.4: символы и кодировка
• Юникод Глоссарий
• Википедия - UTF-8
• * Википедия - Список символов Юникода
• UTF-8 Полный список персонажей
• Википедия - ИСО / МЭК 8859-15
• Полный список символов ISO 8859-15
• StackOverflow - Ответ на "php to rtf, é становится Ã ©"
• * StackOverflow - Расшифровка двойного кодирования utf8 в Python