UTF-16, UTF-8 и прочие кодировки применительно к путям в файловых системах

2useven10 · Post by **2useven10** » Mon 27 Jul, 2026 22:26

SEt wrote: Mon 27 Jul, 2026 21:22 UTF-16, так как, к сожалению, в UTF-8 не всё можно передать без потерь

Очень интересное утверждение. Пространства же идентичны (без привязки к farmanager). Можно пример?

Website · Post by **John Doe** » Tue 28 Jul, 2026 00:36

Имена в utf16 могут содержать невалидные для unicode последовательности - непарные суррогаты.
И это будет валидным именем в файловой системе.

2useven10 · Post by **2useven10** » Tue 28 Jul, 2026 03:52

Такое да возможно, но это некорректный юникод.
Неправильные utf-8 символы в такое вроде преобразуются, чтобы обратная перекодировка работала.
Файлы с такими именами это скорее баг окошек.

Website · Post by **John Doe** » Tue 28 Jul, 2026 07:30

2useven10 wrote: Tue 28 Jul, 2026 03:52 Неправильные utf-8 символы в такое вроде преобразуются,

нет, поэтому для решения этой проблемы придумали wtf-8.

Файлы с такими именами это скорее баг окошек.

Это вряд ли.
На линуксе вроде как ещё свободнее с именами обходятся - это байтовые последовательности не привязанные к кодировке.

2useven10 · Post by **2useven10** » Tue 28 Jul, 2026 10:07

John Doe wrote: Tue 28 Jul, 2026 07:30нет,

Тем не менее - Да. (0xDC80 | Char) это вторая часть суррогатной пары без первой.

John Doe wrote: Tue 28 Jul, 2026 07:30 На линуксе вроде как ещё свободнее с именами обходятся

В файловой системе да, последовательность байт. В ОС Linux, скорее уже предполагается UTF-8.

2useven10 · Post by **2useven10** » Tue 28 Jul, 2026 10:13

2useven10 wrote: Tue 28 Jul, 2026 03:52 Неправильные utf-8 символы

Правильнее некорректные байты в utf-8 последовательности.

Website · Post by **John Doe** » Tue 28 Jul, 2026 12:08

2useven10 wrote: Tue 28 Jul, 2026 10:07 Тем не менее - Да. (0xDC80 | Char) это вторая часть суррогатной пары без первой.

И с её помощью получится валидный utf-8?

2useven10 wrote: Tue 28 Jul, 2026 10:07 В файловой системе да, последовательность байт. В ОС Linux, скорее уже предполагается UTF-8.

В Windows в этом плане ещё строже - штатные функции не дадут создать такое, если не использовать \\?\

Я немного о другом: и там и там в дикой природе могут встретиться имена допустимые с точки зрения fs, но создающие проблемы на прикладном уровне.

2useven10 · Post by **2useven10** » Tue 28 Jul, 2026 13:59

John Doe wrote: Tue 28 Jul, 2026 12:08 И с её помощью получится валидный utf-8?

Какой-то разговор слепого с глухим получается...
Речь изначально об обратном преобразовании. Из некорректного utf8 в неправильные суррогатные пары (только 2-я половина, для ошибок). Чтобы при обратном преобразовании (с учетом отдельной обработки неправильных) получить исходный некорректный utf8.

Website · Post by **John Doe** » Tue 28 Jul, 2026 15:43

2useven10 wrote: Tue 28 Jul, 2026 10:13 Из некорректного utf8

Полагаю со слухом и зрением у собеседников проблем нет, а вот в понятиях не сошлись пока.

Я исхожу из того, что с utf-8 может быть только валидным, и никаким системным преобразованием непарный суррогат в него не положить.

Что вовсе не исключает возможности сделать свой наколенный конвертер (или специальную библиотечку подключить), решающую обозначенную задачу не выходя за пределы 8бит.
Подозреваю, автор именно это и сделал.
Но в результате получилось wtf-8 или что-то подобное. Не utf-8.

Post by **SEt** » Tue 28 Jul, 2026 15:51

Как правильно написал John Doe, имена файлов, по крайней мере под Windows, это вовсе не UTF-16, а можно сказать UCS-2.

Преобразование UCS-2 -> UTF-8 -> UCS-2, конечно, можно сделать без потерь, но это не будет стандартное UTF-16<->UTF-8. Специфицировать же нестандартное преобразование в интерфейсе плагинов, по-моему, совершенно лишние сложности.

WideCharToMultiByte/MultiByteToWideChar, кстати, до висты, вроде бы, работали как раз в режиме "без потерь", а потом стали работать по стандарту.

2useven10 · Post by **2useven10** » Wed 29 Jul, 2026 09:33

Да я согласен, есть нюансы. Причём у меня даже нет чёткого понимания как надо делать правильно.
И проблема (изменение поведения) с переходом на висту+ скорее как раз в обработке правильных суррогатов,
которые стали преобразовываться как UTF16 а не 2 кода UCS2.

forum.farmanager.com