Здравствуйте, CreatorCray, Вы писали:

П>>В линупсе ты любое говно можешь использовать в качестве имени файла. И что это значит?
CC>Что там по сути то же самое. Нету там полноценной поддержки Unicode, и не особо надо ибо это только дополнительный гемор вызывает.

Это я к тому, что пример, приведённый netch80, ни о чем не говорит

Надо смотреть, как работают виндовые функции конвертации текста — ToWide, ToAnsi; корректно ли производятся сравнения текста; корректно ли производятся всякие compisite/precompose конвертации; корректно ли UTF-16 строки выводятся функциями отрисовки текста, и тд и тп.

Здравствуйте, пффф, Вы писали:

П>>>Это вроде было как раз в начале, сейчас уже давно UTF-16

N>>Запретит ли Windows создавать файл с названием, например, "\ud800\ud800" (два кодпункта)?

N>>Я проверил (на десятке 22H2). Создаёт, FAR и Windows Explorer видят, читают, Notepad редактирует.

N>>Значит, это не UTF-16.


П>В линупсе ты любое говно можешь использовать в качестве имени файла. И что это значит?

Это значит, что в юниксах (всех что я видел) нет обязательств использовать для имён файлов UTF-8, KOI8-R, UTF-7 или что угодно. Даже правило что 0x2f это делитель пути может относиться к любой кодировке. Никто не заявляет, что там должен быть юникод или что-то ещё.

А в Windows — заявляют, и тогда должны за это заявление отвечать.

Здравствуйте, CreatorCray, Вы писали:

N>>Запретит ли Windows создавать файл с названием, например, "\ud800\ud800" (два кодпункта)?
N>>Я проверил (на десятке 22H2). Создаёт, FAR и Windows Explorer видят, читают, Notepad редактирует.
CC>И это кстати ожидаемое поведение.

N>>Значит, это не UTF-16.
CC>Ядро системы имена файлов вообще никак не нормализирует и не проверяет на соответствие Unicode стандарту, тупо zero terminated bag of UCS2 characters.

UCS-2 это тоже не соответствует. Если бы соответствовало — то суррогатные коды не допускались бы.
А это действительно нечто среднее между UCS-2 и UTF-16, потому и названо WTF-16
И если бы это просто открыто признали — никто бы не пострадал и было бы лучше.

Кстати, про zero terminated bag — а нахрена собственно?

Здравствуйте, netch80, Вы писали:


N>Это значит, что в юниксах (всех что я видел) нет обязательств использовать для имён файлов UTF-8, KOI8-R, UTF-7 или что угодно. Даже правило что 0x2f это делитель пути может относиться к любой кодировке. Никто не заявляет, что там должен быть юникод или что-то ещё.

N>А в Windows — заявляют, и тогда должны за это заявление отвечать.

1) Где конкретно и что конкретно заявляют?
2) Хорошо, допустим, заявляют, и что конкретно должно было быть сделано, по твоему мнению, и почему?

3) По поводу 0x2f не совсем понял. 0x2f во всех кодировках на базе ASCII означает одно и то же. А если EBCDIC?
В юниксах кодировка имён зависит от файловой системы. Так и в винде также. Я хз, что будет, если попытаться создать на FAT'е файл с именем, содержащим русские и, испанские или немецкие, например, символы. Думаю, что создаст хоть как-то

Здравствуйте, netch80, Вы писали:

n> Это значит, что в юниксах (всех что я видел) нет обязательств использовать для имён файлов UTF-8, KOI8-R, UTF-7 или что угодно. Даже правило что 0x2f это делитель пути может относиться к любой кодировке. Никто не заявляет, что там должен быть юникод или что-то ещё.

n> А в Windows — заявляют, и тогда должны за это заявление отвечать.

Ты выбрал какой-то странный критерий для оценки. Логичнее, проверить, например, отрисовку supplementary unicode. Берем эмоджи "🤨" (U+1F928, UTF-16LE: 3E D8 28 DD):

Слева W2K (UCS-2), справа W7 (UTF-16) (квадратики из-за отсутствующих глифов в шрифтах)

Здравствуйте, пффф, Вы писали:

N>>Это значит, что в юниксах (всех что я видел) нет обязательств использовать для имён файлов UTF-8, KOI8-R, UTF-7 или что угодно. Даже правило что 0x2f это делитель пути может относиться к любой кодировке. Никто не заявляет, что там должен быть юникод или что-то ещё.
N>>А в Windows — заявляют, и тогда должны за это заявление отвечать.
П>1) Где конкретно и что конкретно заявляют?

Тык.

Windows natively supports Unicode strings for UI elements, file names, and so forth. Windows represents Unicode characters using UTF-16 encoding, in which each character is encoded as one or two 16-bit values.

(Кстати, уже враньё. Должно быть "in which each codepoint is encoded as one or two 16-bit values". Здесь такое упрощение недопустимо.)

П>2) Хорошо, допустим, заявляют, и что конкретно должно было быть сделано, по твоему мнению, и почему?

1. Чётко описать в документации, что именно реализуется.
2. Предоставить средства проверки корректности строк согласно настоящему UTF-16 (которое как минимум не допускает порванные суррогатные пары). Дальше хорошо бы ещё и давать проверить корректность на уровне уже символов, а не кодпунктов — типа, U+0300 не может быть в начале строки или после непечатного кода. Тут уже разные уровни, но я думаю, что вогнать в систему что-то вроде ICU было бы вполне полезно.

П>3) По поводу 0x2f не совсем понял. 0x2f во всех кодировках на базе ASCII означает одно и то же. А если EBCDIC?

Дзинь.
Да, требуются хотя бы IA5-based (а лучше ASCII-based) кодировки. Но фактически это сводится к позициям трёх символов — NUL, '.' и '/'.

П>В юниксах кодировка имён зависит от файловой системы.

Нет. По крайней мере в родных FS такой зависимости нет и никогда не было. Для чужих типа VFAT или CIFS — да, есть связь, но на то они и чужие, чтобы давать что-то нестандартное.
Зависимость есть от локали процесса, и то его внутренними средствами.

П> Так и в винде также. Я хз, что будет, если попытаться создать на FAT'е файл с именем, содержащим русские и, испанские или немецкие, например, символы. Думаю, что создаст хоть как-то

Кодировка FAT (не VFAT) зависит от системной локали ОС, и при отсутствии 8-битной таблицы, что их всех содержит, создать просто не получится.

Здравствуйте, rudzuk, Вы писали:

n>> А в Windows — заявляют, и тогда должны за это заявление отвечать.
R>Ты выбрал какой-то странный критерий для оценки. Логичнее, проверить, например, отрисовку supplementary unicode. Берем эмоджи "🤨" (U+1F928, UTF-16LE: 3E D8 28 DD):

И это тоже.

R>Image: bUhT7JU.png
R>Слева W2K (UCS-2), справа W7 (UTF-16) (квадратики из-за отсутствующих глифов в шрифтах)

Ну да, так и написано, что после W2K был совершён переход от просто UCS-2 к тому самому смесовому варианту.

Здравствуйте, netch80, Вы писали:

N>Кстати, про zero terminated bag — а нахрена собственно?
Sanity и backward compatibility.

Здравствуйте, netch80, Вы писали:

N>2. Предоставить средства проверки корректности строк согласно настоящему UTF-16 (которое как минимум не допускает порванные суррогатные пары).
Хехе. Это всё теория, а дальше начинается суровая реальность.
Вот есть у тебя уже файлы с такими порванными парами, что с ними делать прикажете?
Пользователи очень плохо реагируют на ситуации когда что то раньше работало а теперь перестало. И особенно плохо когда теряется доступ к данным.

Здравствуйте, rudzuk, Вы писали:

R>Берем эмоджи "??" (U+1F928, UTF-16LE: 3E D8 28 DD):
RSDN Janus под W10 нарисовал мне тут два квадратика

R>Слева W2K (UCS-2), справа W7 (UTF-16)
Получается в W10 снова UCS-2?

Здравствуйте, CreatorCray, Вы писали:

CC> R>Берем эмоджи "??" (U+1F928, UTF-16LE: 3E D8 28 DD):

CC> RSDN Janus под W10 нарисовал мне тут два квадратика

Проблемы Януса (клиента или сервиса).

Здравствуйте, CreatorCray, Вы писали:

N>>2. Предоставить средства проверки корректности строк согласно настоящему UTF-16 (которое как минимум не допускает порванные суррогатные пары).
CC>Хехе. Это всё теория, а дальше начинается суровая реальность.
CC>Вот есть у тебя уже файлы с такими порванными парами, что с ними делать прикажете?
CC>Пользователи очень плохо реагируют на ситуации когда что то раньше работало а теперь перестало. И особенно плохо когда теряется доступ к данным.

Вот а почему ты решил, что речь сразу об отказе доступа по таким именам?
Я не предполагал и даже не намекал на такое, это ты сам что-то себе домыслил, вполне в стиле MS
А вот помечать особым образом, предупреждать при использовании таких имён... вот на это, да, желательны как минимум стандартные хелперы, рекомендации по их использованию.

Здравствуйте, Pauel, Вы писали:

N>>Я вижу только одно преимущество времён до восьмёрки — они сами тестили по максимуму, а не испытывали на юзерах.

P>Это нынче эпидемия практически везде — автоматическое тестирование вытесняет ручное и вместе с этим выбрасывается exploratory тестирование. И как результат видим баги то тут, то там, зато happy path обычно работает.

В случае MS начиная с 8ки — нет признаков того, что именно автоматическое тестирование вытеснило ручное. Скорее ручное вообще сократили без замены ;(

Здравствуйте, netch80, Вы писали:


N>Вот а почему ты решил, что речь сразу об отказе доступа по таким именам?
N>Я не предполагал и даже не намекал на такое, это ты сам что-то себе домыслил, вполне в стиле MS
N>А вот помечать особым образом, предупреждать при использовании таких имён... вот на это, да, желательны как минимум стандартные хелперы, рекомендации по их использованию.

Не очень понятно, как ты себе это видишь? CreateFile не возвращает ошибку, создаёт файл, но выводится MessageBox, что у файла плохое имя, а отключить этот MessageBox можно через SetErrorMode? Или как?

Здравствуйте, netch80, Вы писали:

N>Вот а почему ты решил, что речь сразу об отказе доступа по таким именам?
Да потому что я такое уже видел: как только начинаем проверки на невалидный UTF то и передать его от аппы до FS становится быть низзя.

N>Я не предполагал и даже не намекал на такое, это ты сам что-то себе домыслил, вполне в стиле MS
Это называется опыт.

N>А вот помечать особым образом, предупреждать при использовании таких имён.
Ни в одном FS API нет даже концепции "предупредить". Либо можно либо нет.

N> вот на это, да, желательны как минимум стандартные хелперы, рекомендации по их использованию.
Ты вот щас мне ну очень одного теоретика-фантазёра напоминаешь.

Здравствуйте, netch80, Вы писали:

P>>Это нынче эпидемия практически везде — автоматическое тестирование вытесняет ручное и вместе с этим выбрасывается exploratory тестирование. И как результат видим баги то тут, то там, зато happy path обычно работает.

N>В случае MS начиная с 8ки — нет признаков того, что именно автоматическое тестирование вытеснило ручное. Скорее ручное вообще сократили без замены ;(

Так оно и выглядит, когда exploratory убрали оставив автоматическое. То есть новые баги продолжают появляться с некоторой скоростью, их количество растет, но автоматические тесты их не обнаруживают. Ручной смоук тест тоже мало чего находит.

Автоматическое тестирование по своей сути принципиально дырявое — обнаруживается исключительно фиксированый набор багов по фиксированым путям. Есть варианты с рандомизацией поведения, скриншоты, итд — это пока что работает так себе. Возможно AI поможет — научится делать exploratory.

Здравствуйте, CreatorCray, Вы писали:

N>>А вот помечать особым образом, предупреждать при использовании таких имён.
CC>Ни в одном FS API нет даже концепции "предупредить". Либо можно либо нет.

Откуда домыслы про FS API?

N>> вот на это, да, желательны как минимум стандартные хелперы, рекомендации по их использованию.
CC>Ты вот щас мне ну очень одного теоретика-фантазёра напоминаешь.

Зеркало тебя ждёт, коллега. См. выше.

N>>Я не предполагал и даже не намекал на такое, это ты сам что-то себе домыслил, вполне в стиле MS
CC>Это называется опыт.

Это называется — ты высосал из пальца гору фантазий и зачем-то назвал это опытом.

Мне такое неинтересно.

Здравствуйте, пффф, Вы писали:

N>>Вот а почему ты решил, что речь сразу об отказе доступа по таким именам?
N>>Я не предполагал и даже не намекал на такое, это ты сам что-то себе домыслил, вполне в стиле MS
N>>А вот помечать особым образом, предупреждать при использовании таких имён... вот на это, да, желательны как минимум стандартные хелперы, рекомендации по их использованию.

П>Не очень понятно, как ты себе это видишь? CreateFile не возвращает ошибку, создаёт файл, но выводится MessageBox, что у файла плохое имя, а отключить этот MessageBox можно через SetErrorMode? Или как?

(крайне редко употребляю этот знак, но тут сейчас он как раз в тему)

Твоё мышление непоправимо изуродовано гуями, если вообще делаешь такие предположения. Какой нафиг MessageBox? А если мы говорим о сервисе, который где-то в фоне?

По-нормальному так: ограничения или накладываются средствами FS, на уровне целой FS или каталога, или проверяются приложением добровольно в юзерленде.
Первое — так же как сейчас на стандартном виндовом разделе нельзя создать файл ABC если есть файл abc.
Второе — дать функции для этого и пометить, какую в каком случае использовать. В первую очередь проверка должна идти на имена из непроверенных источников (от вредного пользователя и до входа из сети), а уже дело приложения различить ситуации "мы не должны такое создавать" от "оно уже сделано и надо дать с ним работать".
Да, и вписать в хелпы где уместно — рекомендации посмотреть туда и применять.

Вот это — нормальный путь, а не безумные фантазии про MessageBox

Здравствуйте, karbofos42, Вы писали:

SP>>тут вроде раньше писали: "с такими амбициями, GC — это приговор". Если хочется простоты, уже можно смотреть в сторону того же zig.
K>Так он мог бы конкурировать с C# и Java

У него, как и у Golang, не было ничего над ними, кроме АОТ. Golang имхо без мегакорп бы не взлетел.

Здравствуйте, netch80, Вы писали:

N>Твоё мышление непоправимо изуродовано гуями, если вообще делаешь такие предположения.

Ну почитай уже, не изуродованный ты наш — https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-seterrormode


N>Какой нафиг MessageBox? А если мы говорим о сервисе, который где-то в фоне?

Если сервис — то просто молча падает.



N>По-нормальному так: ограничения или накладываются средствами FS, на уровне целой FS или каталога, или проверяются приложением добровольно в юзерленде.
N>Первое — так же как сейчас на стандартном виндовом разделе нельзя создать файл ABC если есть файл abc.

Это ожидаемое поведение. Оно сто лет не меняется, и не собирается меняться (без приседаний)


N>Второе — дать функции для этого и пометить, какую в каком случае использовать. В первую очередь проверка должна идти на имена из непроверенных источников (от вредного пользователя и до входа из сети), а уже дело приложения различить ситуации "мы не должны такое создавать" от "оно уже сделано и надо дать с ним работать".

Никто не будет переписывать софт, даже если есть такая возможность


N>Да, и вписать в хелпы где уместно — рекомендации посмотреть туда и применять.

Или просто ничего не делать, что MS и сделала. Самое оптимальное.


N>Вот это — нормальный путь, а не безумные фантазии про MessageBox

Окей, а теперь — как мне открыть файл, который уже содержит косяки в имени? Я 30 лет использую CreateFile, и всё работало, а тут возвращает ошибку. Думаешь, много людей догадаются перечитать все примечания мелким шрифтом в описании CreateFile?

Вообще-то, если ты пользуешься виндовыми функциями для работы с текстом, то такой ситуации и не возникнет — оно раньше сфейлится (или строка обрежется). Причем, раньше такая ситуация бы могла возникнуть, а современной винде — нет. И для этого не нужно делать ровным счетом ничего.

А если ты сам кривыми ручонками лазаешь в массивы WCHARов — то бесполезно давать какие-то новые функции и что-то писать в хелпах — такие люди их не читают всё равно.

Прикрутить ICU и парсить имена в любом системном вызове, который принимает их на вход — у тебя что, винда слишком быстро работает?

ICU в десятке, вроде как, уже есть, кстати. Но никто её в системные вызовы не засовывает, до такого маразма ещё не дошли