Комментарии 299
Такое ощущение, что они настолько обожают древнюю файловую систему FAT, что не могут не попытаться её воссоздать
...и ничего не сказал про "древние" NTFS и ReFS под Windows.
Старый Линус просто жаждет ещё большей маргинализации Linux.
Думаю тут посыл был в том, что у разрабов "синдром утёнка" - нежная любовь к регистронезависимости впитанная с первой используемой ФС.
Да Линус просто порвался.
мне кликбейт сразу пробил дальнии кэши:
❝ Сказочный dolboёb(.org)... Зачем его только из
больницыfinland выпустили? ❞ - мем из фильма «Даун Хаус» (2001), фраза, обозначающая крайнюю степень тупости оппонента.
про
❝ Нет, спасибо, меня и так прёт. Наяву. Без всякого компота. ❞ © князь Мышкин
— это хаусlinux
уже вот так всё от него воспринимается
Справедливости ради, NTFS регистрозависимая.
https://stackoverflow.com/questions/33998669/windows-ntfs-and-case-sensitivity/34000339#34000339
Это для хомячков её обычно превращают в регистронезависимую, а в суровых энтерпрайзах включают режим POSIX-совместимости (что иногда приводит к неожиданным последствиям).
Не тольке в суровых энтерпрайзах. Также регистрозависимость в NTFS может быть включена для отдельных каталогов - например, для лучшей интеграции конкретных дистрибутивов Linux при работе оных в WSL. Однако, это, имхо, слабо влияет на общую картину.
Ни разу не видел, чтобы хоть где-то отключали для NTFS регистронезависимость. Даже в официальных учебниках по Microsoft этот вопрос никогда не поднимался.
Суровые энтерпрайзы отлично работают с NTFS и её регистронезависимостью, т.е. настройкой по умолчанию.
Включу режим душнилы:
https://learn.microsoft.com/en-us/previous-versions/tn-archive/bb463214(v=technet.10)#:~:text=Because of security,explicitly enabling it.
Возможно, что в современных учебниках этот вопрос и не поднимался, а в более ранних — вполне себе да, ибо для военных контрактов MSFT, собственно, и впиливали POSIX-совместимость.
В Server 2003 даже в настройках была где-то галочка, включающая режим регистрозависимости как минимум для WIN_PATH, о чём я случайно узнал на своём горьком опыте создания и удаления симлинков (junction points), чтобы обойти ограничения доступа 32битных приложений к 64битным библиотекам/утилитам в System32 (и не быть перенаправленным в SysWOW64).
О, расскажите про какие суровые энтерпрайзы речь? Я писал пару драйверов ФС под винду в своём FAANG+, и ниразу в жизни не видел включенную регистрозависимость NTFS.
...и ничего не сказал про "древние" NTFS
Вы так говорите, как будто NTFS - это новейшая и современнейшая файловая система. А она, тем временем, практически ровесница ext2 и всего на два года "моложе" первого зарелиженного ядра линукса.
и ReFS
Вы так говорите, как будто она не тянет тяжкий грех совместимости с древнючей NTFS, которая тоже регистронезависима исключительно для совместимости всё с той же FAT.
Старый Линус просто жаждет ещё большей маргинализации Linux.
В мире, где микросовт вынуждена была сделать WSL это звучит забавно ))
Майкрософт, имхо, впендюрила WSL для разработчиков, чтобы они и при разработке под Linux оставались в Windows. Да они и сами об этом пишут:
WSL предназначен для обеспечения простого и продуктивного взаимодействия для разработчиков, которые хотят одновременно использовать Windows и Linux.
Всё же, MSVS очень удобна для работы.
Очевидно, что разработчики в MS впиндюрили WSL в основном для себя, поэтому эта подсистема так хорошо работает, и, в целом, достаточно удобна. Те вещи, которые они делают для других, чудовищны по эргономике.
WSLv1 был сделан по принципу "ля чё могу", кстати с помощью всё той же подсистемы POSIX-совместимости.
Зато v2 уже "ничотак".
Там такая фигня с трансляцией файлов, что работать невозможно с node_modules к примеру, или с компиляцией c++, так как есть какое то константное время чтения любого файла и просмотра каталога, вне зависимости от его размера.
Все проблемы с которым обходятся обычной виртуалкой, инновационный круг замкнулся.
Должен признаться, что я в итоге отказался от wsl в пользу работы с "живым" Lunux, либо на удаленной физической машине, либо на виртуалке; работаю в Windows, в привычной мне MSVS, а линуксовый вариант кода компилю и отлаживаю удаленно. C WSL постоянно какие-то косяки вылезали, которые, в итоге, в основном фиксились, но в какой-то момент появилась мысль "Какого чёрта?" и просто вернулся к привычной схеме работы. Да и виртмашина, с её снимками состояний, часто просто очень удобна.
Иметь возможность создать два имени файла, которые не отличаются "на глаз", но при этом разные - это круто. Специалисты по компьютерной безопасности будут довольны.
2 достаточно длинные строки вы глазами не сравните, даже без игр с Unicode.
Сеошники еще кормятся на этом.
Регистрозависимость не является источником этой проблемы.
Даже не играясь с регистром без проблем можно понасписывать слов, вглядящих одинаково, но составленных на самом деле из разных символов.
Вот к примеру слово 'Регистрозависимость', можно написать 32 разными способами просто подменяя кирилические буквы 'o' и 'c'.
кaк будтo в этом ecть что-то плохое
как будто в этом есть что-то плохое
:-)
Да, и в windows и в Linux такое возможно, но это вряд ли устранимо в принципе. Люди слишком невнимательны.
Какую проблему решает регистронезависимость?
Совместимость с самыми распространенными серверными и десктопными ОС - проблемой не считаем?
Теперь проблема есть. Зачем они (разработчики этих ОС/ФС) её создали? Какая изначально ожидалась польза от регистронезависимости?
Старики бают, что "на заре" требовалась совместимость с файловой системой OS RT-11 и RSX-11, в которых для имен файлов использовалась кодировка RADIX-50.
В этой кодировке было всего 40 символов (латинские буквы, цифры, пробел, точка, знак доллара и один резервный). Да, 40 - это 50 в модной тогда восьмеричной системе, отсюда и число в названии. В итоге, три символа RADIX-50 хитрым образом помещались в одном 16-битном слове, примерно по 5.322 бита на символ.
Схожим образом выглядит кодировка SQUOZE в некоторых ОС IBM машин.
Память экономили, шельмецы.
Добавлю, оттуда же имена файлов формата 8.3 - это 12 символов или 8 байт в RADIX,
Если три символа помещались в одном слове, то на выходе должны было быть 9.3 - четыре слова. Откуда 8.3?
Ещё точка же
зачем хранить точку?
8.3 - читайте как до8 плюс точка плюс до3
зачем хранить точку? если имя короче, лишнее знакоместо занимается пустым символом, точка не нужна
В FAT16 нет точки. Имя не может быть пустым. Расширение может.
Возникает своего рода неопределённость.
"FILE" и "FILE." это одно и тоже.
Любое количество точек, необязательно 0/1.
PS. В FAT12/16/32 точка вообще недопустима - ни в имени, ни в расширении. Вы же говорите о VFAT.
Я про command.com. Там только 0/1.
Да, вы правы. Если речь именно об интерфейсе COMMAND.COM, то там две точки приводят к ошибке file not found. Обращение к тому же command.com из оболочки Windows (95..ME) пока проверить не могу, сделаю позже. А вот CMD.EXE уже переваривает любое количество точек.
В то же время в собственно файловой системе (элементе каталога с именем файла) никаких точек нет.
Бывает, что имя файла короче, чем 8.3, например: "X.Y" - как тут без точки?
3 слова на имя + 1 на расширение. Итого 12 значащих символов. Тратить символ на точку тогда было бы слишком расточительно.
если имя короче, лишнее знакоместо занимается пустым символом, точка не нужна
Значит, становится нужным пустой символ, а не точка.
Этот пустой символ занимает те же места, что 8+3
Да, но требует место в таблице символов, которая ограничена 40 штуками.
Если в RSX-11, то 64. А если в MSDOS, то там обычныая 8-битная кодировка и в ней обычные пробелы.
Да, но требует место в таблице символов, которая ограничена 40 штуками.
Да, вопрос, чем пожертвовали, символом в таблице или возможностью сделать имена файлов на целый символ длиннее. Судя по 8+3, таки длиной имени файла.
X_______Y__
Добавлю, оттуда же имена файлов формата 8.3 - это 12 символов или 8 байт в RADIX,
В RSX формат имени файла 6.3.
Directory DB3:[200,1]
31-OCT-76 11:12
GSA.MAC;1 19. 03-JAN-90 17:07
SEARCH.MAC;1 10. 03-JAN-90 17:07
RENAME.MAC;1 12. 03-JAN-90 17:078.3 это MSDOS
на счёт серверных ОС в наше время звучит сомнительно. Десктоп - да.
Однако, каковы шансы впихнуть Bcachefs в Windows?.. Есть ли смысл заморачиваться совместимостью с виндовыми UX в этой связи?
А наоборот - так виндовые FS в Линукс впихнуть можно.
У МакОСа файловая система регистрозависимая. МакОС - это UNIX такой.
Сервера в интернете/в облаках чуть менее, чем все, имеют Linux внутри.
И никто в этом гетерогенном мире на это не жалуется. Так что нет, не проблема.
По умолчанию ФС в macOS регистронезависимая.
У маков регистрозависимость настраивается, но переключение происходит, если память не подводит, с полным форматированием диска.
Я так на одном проекте опытным путём выяснил, что клонирование репозитория на Linux проходит нормально, а на MacOS репа просто ломается, из-за того, что в одном из коммитов несколько файлов поменяли регистр.
Естественную для человека идентификацию файлов. Так-то и по номеру иноды можно было бы файлы различать, и никаких проблем с именованием.
Спасибо, вадим.
Уфф, а я думал, что никто не скажет. Замечаю, что некоторые программисты делают упор на формальную логику, вместо того чтобы подумать головой. Мой любимый пример отмена операции в Far по Esc, типа копирования. Стандартная логика
нажал Esc
вывалился диалог с подтверждением
подтвердил
операция прервалась
Что могло пойти не так? Две вещи
между Esc и диалогом может пройти много времени (секунды, даже десятки, достаточно для нетерпеливых людей)
диалог тоже закрывается по Esc
Что происходит на самом деле, пользователь хочет прервать операцию, жмёт Esc, ничего не происходит, жмёт ещё раз и ещё, и ещё, в результате когда наконец диалог показывается он закрывается по Esc и операция продолжается. Логично? Да. Хотел ли этого пользователь? Нет.
Так и с регистр зависимостью - логично и просто для программиста, но пользователю от этого не легче.
Хотел ли этого пользователь?
Пользователь far на связи. Да, именно этого и хотел.
С вашего позволения, прямая аналогия:
– работаем в ворде
– нажимаем alt+f4
– получаем модалку: "файл изменен, сохранить? да | нет | не знаю
– нажимаем esc
– ворд закрывается.
А что, мы же именно этого хотели нажимая alt+f4?
Операции в far могут и, как правило, есть намного более длительны, чем реакция с модалкой на esc.
Соответственно, потерять результаты выполнения операции от случайного прожмяка эскейпа – намного хуже, чем не отменить операцию.
Не вижу я тут аналогии. IMHO в описанном мной примере самым простым решением было просто игнорировать все что пользователь нажал между первым esc и показом диалога и всё.
У меня есть гипотеза, что если диалог не появился сразу, то значит где-то в неожиданном месте встала колом блокирующая операция, и приложение не слишком решает как себя вести.
Соответственно, если решать эту проблему – то блокируюшие операции нужно огораживать. Если огородить блокирующую операцию, то ВНЕЗАПНО окажется, что ничего не мешает диалогу рисоваться сразу. То есть ваше решение не "самое простое", а "самое бессмысленное".
Собственно, я не помню, когда в последний раз видел ситуацию задержки диалога отмены. Возможно, потому, что давненько не ходил фаром на сетевые ресурсы – на локальных поиске/копировании диалог появляется моментально.
Как минимум два тривиальных решения: 1) Чистить очередь событий клавиатуры перед показом диалога 2) Отмену операции и закрытие диалога повесить на разные клавиши
Чистить очередь событий клавиатуры перед показом диалога
Очередь событий клавиатуры обычно бывает в месте сильно отличном от места вызова диалога. И предполагаю, что давать доступ к очереди клавиатурных событий любому месту, которое показыавет диалоги, чревато сильно интересными последтсвиями. Но если вы думаете, что это тривиально, то можете попробовать форкнуть и показать всем, как надо.
Отмену операции и закрытие диалога повесить на разные клавиши
Позвольте уточнить: вы предлагаете, чтобы по эскейпу не вызывался диалог отмены? Или чтобы он не закрывался? Если честно, сомневаюсь, что многие пользователи обрадуются такому нововведению. Но если лично вам такая идея нравится, почему нет?
Суньте примерно такое содержимое:
Macro {
description="";
area="Dialog"; key="Esc";
flags="";
code="";
}
примерно сюда %USERPROFILE%\AppData\Roaming\Far Manager\Profile\Macros\internal\Dialog_Esc.lua (ну или где там у вас профиль фара) и назначьте любую другую кнопку по своему вкусу.
А если дождаться открытия окна, сбросить в пустоту весь буфер клавиатуры и ждать ввода, тоже сложно?
Если рандомные места будут свободно сбрасывать очередь событий клавиатуры, то рано или поздно учеловека, который быстро печатает или имеет медленный компьютер будут появлятся файлы eadme.tx или что похуже.
Дело не в сбросе событий. Грубо говоря, все, что вы нажали пока фокус в фаре принадлежит фару. Значит это его право после сразу отображения окошка все нажатия что в него влетят отправить в помойку и только после этого начать ждать ввода управляющих инструкций.
Кажется в свое время этим NT от 95 отличались. В первой можно влупить 10 клавиш пока окошко открывается и все они выполнятся (в ворде я чтоли позиционировался куда-то, не помню уже), а в 95 такой фокус не проходил. Дождись пока кнопка отрисуется, потом жми ее горячую клавишу.
Какую проблему решает регистронезависимость?
Совместимость с древним софтом, у которого его же собственные файлы в коде и на файловой системе могут оказаться разного регистра
Какую проблему решает регистронезависимость?
Говнокодить удобнее. В одном месте маленькими буквами имя написал, в другом большими - да пофиг, и так сойдет.
в реальном мире просто регистронезависимость повсеместно. "Иванов" и "иванов" это одна и таже фамилия (пусть и с ошибкой) для любого нормального человека от самого Иванова, до пограничника на границе. Тоже самое и с адресами. Хотите чтобы улица Наро-Фоминская, Наро-фоминская и наро-фоминская - это были три разных улицы????????
Ну а мир компьютеров он в целом не может далеко оторваться от реальности. Даже я бы сказал наоборот.
Хотите чтобы улица Наро-Фоминская, Наро-фоминская и наро-фоминская - это были три разных улицы????????
Всего три? Там еще можно пяток разных дефисов-тире использовать с разными сочетаниями строчных и заглавных. Эти варианции тоже признаем годными?
В реальном мире "McDonald", "MacDonald", "M'Donald" и "Macdonald" -- это одна и та же фамилия, причём без ошибок. Должны ли файлы с этими именами считаться одним файлом?
Прямо одна и та же? Не "несущая тот же исторический смысл"?
Вот придёт Macdonald жену из роддома забирать - а там ребёнку M'Donald написали, и всё в норме?
В роддоме напишут "как в паспорте", там и "иванова" с маленькой буквы не будет. Но, скажем, при алфавитной сортировке фамилий (в каталогах, в списках избирателей, и так далее) "Mc-", "M'-" и "Mac-" сортируются как если бы они все были "Mac-", так что "MacDonald, Ronald" следует после "McDonald, Ralf". И исторически носители таких фамилий писали их в разных вариантах.
"Иванов" и "иванов" это одна и таже фамилия (пусть и с ошибкой)
Ну не знаю. "начальник Козлов" и "начальник козлов" не совсем одно и то же.
Скрытый текст
Вернулся Козлов с работы домой и с женой делится:
– Вот, говорят, новые русские одни только хамы. Неправда всё это. Я тут сейчас дорогу в неположенном месте перебегал и один из них на мерсе меня чуть не сбил. Так такой вежливый мужчина оказался. Он меня даже на «Вы» назвал!
– Да ну. Как это?!
– Клянусь! Остановился и крикнул:
– Здесь люди ездят, а для Вас, Козлов, специально подземный переход построили!!!
Подумал Козлов немного и добавил:
– Вот только не пойму, откуда он мою фамилию знает…?
Вот ещё мне нравится мемасик:
"Иванов" и "иванов" это одна и таже фамилия (пусть и с ошибкой) для любого нормального человека
«яблоко», «яблочко», «apple» — один и тот же смысл для любого нормального человека.
Хотите чтобы улица Наро-Фоминская, Наро-фоминская и наро-фоминская - это были три разных улицы????????
Проблема грязных данных — не проблема ФС.
Тоже самое и с адресами. Хотите чтобы улица Наро-Фоминская, Наро-фоминская и наро-фоминская - это были три разных улицы????????
Для этого индекс должен указывать на конкретный дом, как сделано в некоторых странах. Очень удобно, на самом деле, ввели индекс и весь адрес автоматом заполнился (кроме номера квартиры, если вы в многоквартирном доме живёте).
В качестве гипотезы: чтобы пользователи не путались в своих папках Documents, documents, DOcuments и т.д. Как показывают опросы, свинарник в названиях и структуре — правило, а не исключение.
И да, можно это делать на уровне файлового менеджера, однако, как я подозреваю, сюрпризы от этого станут реже, но злее.
(Лично мне и case sensitive норм).
А в результате, если случайно назвал папку DOcuments, то регистронезависимая фс не дает ее потом в Documents переименовать
Включи галочку в фаре "папки большими буквами" и ты даже не узнаешь, что вторая и правда большая :)
Детский сад чес слово, 100500 раз я решал эту задачу элементарным способом - 1. добавь символ в название 2. переименуй и одновременно удали добавленный символ.
С чего бы вдруг? В macOS всё работает.
Более того, даже просто mv f f является корректной выполняющей реальную работу командой.
Такие упрощения поднимают рост умственной деградация новым поколениям. Новое поколение будет считать одинаковыми слова Documents Dcuments Docs.
Удобство пользователя
Какую проблему решает регистронезависимость?
В основном обратная совместимость.
Кому надо регистрозависимость ФС просто её включит молча.
Какую проблему решает регистронезависимость?
Мне кажется, вы смотрите не с той стороны.
Первые файловые системы оперировали ограниченным набором символов. В частности, в структуре FAT (ведь основные возмущения по теме статьи направлены главным образом в сторону FAT/NTFS, хоть поводом в самой статье послужил и совсем другой материал) имя файла в обязательном порядке записывалось большими буквами.
Регистронезависимость в интерфейсе MS-DOS - это уже user-friendly фича интерфейса. То есть она не "решала проблему". Она создавала удобство. Ну а то, что хорошее вроде бы дело привело к проблемам - так это сплошь и рядом. Хотели же как лучше...
Человек, который фильтрует пути в целях безопасности - долбодятел, а Линус перекладывает проблему с больной головы на здоровую. Безопасность должна обеспечиваться не за счёт obscurity.
Тут не в этом дело. Не в безопасности, а в прозрачности модели, в качестве абстракции — если мы работаем не только с LATIN-1, то понятия «верхний регистр» и «нижний регистр» становятся нескольно неопределёнными. Вот, к примеру, у буквы ы должен быть верхний регистр? С учётом того, что это изначально две буквы (диграф)? И это практически родная сестра латиницы, а уже пошло веселье.
Если же мы перейдём ко всяким деванагари, хираганы, хангыли — вот там что такое регистры? В результате мы видим, что абстракция «регистронезависимая строка Unicode» представляет из себя говно. Соответственно, не надо ей пользоваться, о чём и пишет Линус.
Естественно, у буквы Ы должен быть верхний регистр, и, более того, в русском языке есть слова (собственные имена и заимствования), начинающиеся с Ы. В русской Википедии есть статья Ысыах. С учётом того, что это диграф, она потенциально могла бы кодироваться одной или друмя позициями (на самом деле Ы всегда кодируется одной, но Ё может по-разному). И мы обязаны это учитывать, коль скоро поддерживаем русский язык.
По поводу азиатских языков никак не могу прокомментировать, так как ими не владею, но в целом абстракция-то очень простая. Одна и та же буква может в различных контекстах иметь разное начертание. Так устроена человеческая письменность у большинства людей. И это объективный факт, от которого невозможно отмахнуться. Используя имя файла как ключ поиска в файловой системе (а никакого другого штатного назначения у имени файла нет), я в общем случае не могу предсказать регистр. Поэтому файлы и их имена находится в отношении один-ко-многим (и это принципиально ничего не меняет при уже имеющейся концепции линков).
А Линус, если хочет, может называть файлы на китайском, где регистров нет (но есть много других проблем).
абстракция «регистронезависимая строка Unicode» представляет из себя говно
А речь идёт о другой абстракции, "имя файла в Unicode в конкретном языковом окружении".
А речь идёт о другой абстракции, "имя файла в Unicode в конкретном языковом окружении".
Это не то, чем должен заморачиваться автор ФС — это, очевидно, за пределами его компетенции + решение должно быть одно на ОС или даже несколько ОС.
По поводу азиатских языков никак не могу прокомментировать, так как ими не владею, но в целом абстракция-то очень простая.
Ага, ага, простая... Особенно для людей, образованных от английского до английского. Это называется синдром имени денди Крюгера, да?
Это не то, чем должен заморачиваться автор ФС — это, очевидно, за его пределам компетенции + решение должно быть одно на ОС или даже несколько ОС.
Согласен, поэтому регистрозависимые ФС, как бесполезный частный случай регистронезависимых, не должны были бы существовать. Но уж что имеем. А решение - это стандарт Unicode и collating sequences вместо тупых сравнений. Оно одно.
Оно одно.
Оно не одно, оно эволюционирует со временем.
Ну так и язык, и вся культура эволюционируют со временем. Такова жизнь. 10000 лет назад петроглифы рисовали, а теперь имена файлов с сердечками. Нет решений раз и навсегда.
Юникод эволюционирует здесь и сейчас, примерно раз в год новая версия. Ну это мы не говорим о том, что есть и другие кодировки, которые никто не отменял.
Ну вы хоть примерно понимаете, что такое ответственность перед пользователями? Или вы из уеба?
Другие кодировки как раз давно пора отменить.
А в чём вы видите ответственность перед пользователями в данном случае?
Другие кодировки как раз давно пора отменить.
Если бы не обратная совместимость...
Да как-то в том же линуксе это ведь сделали без потери обратной совместимости.
В том же линуксе поддержка других кодировок никуда не делась. И опции монтирофания фс с другой кодировкой вполне себе работают, и локаль с каким-нибудь кои8-р завсегда включить можно.
Можно, но зачем?
Для обратной совместимости, однако.
Есть старые приложения, которые не умеют выдавать текст в кодировке, отличной от забитой намертво. При этом они вполне нормально работают под современными версиям ОС, просто выдают козявки вместо текста при неправильно настроенной кодировке (это и под виндой поймать можно). И никто их вам никогда не перепишет (утраченные технологии, жаба и прочие трудности). Вот тут-то и включаем сначала в терминале нужную локаль, а потом запускаем.
Попадаются старые диски, которые нужно подключить и прочитать (например, из сдохшего старого компьютера или просто из сейфа), а там имена файлов в особенной кодировке в ФС. Тут опции монтирования соответствующие помогают.
Ну так и язык, и вся культура эволюционируют со временем.
Имя файла в Линукс - это последовательность байт. Не букв, не Юникодовых codepoints, а байт. Делать регистронезависимость на этом уровне - это означает, что по неким правилам две разные последовательности байт иногда считаются равными. А иногда не считаются. И правила меняются каждый год. Это безумие. Кому такого хочется, может реализовывать сам на уровне приложения, и сам потом отвечать перед пользователями, когда их через это хакнут, заставив запустить не то приложение. Можно иметь альтернативные имена, которые хранятся в расширеных атрибутах. Но имя у файла ровно одно, и у него один хэш, и при обращении по имени файла программа должна читать один и тот же файл не смотря на дату в календаре.
Ещё, вы как собрались сравнивать регистронезависимые строки по их хэшам?
Имя файла в Линукс - это последовательность байт. Не букв, не Юникодовых codepoints, а байт.
...и тому, кто это придумал - я с удовольствием забил бы гвоздь в голову.
В том числе за ограничение в 255 байт на имя файла.
Расскажите, как надо было сделать. Только напомню исторический контекст, когда это всё дизайнилось:
Юникода нет даже в планах.
Совершенно нормально иметь по кодировке на каждый язык, у некоторых языков по несколько конкурирующих кодировок, некоторые кодировки переменной длинны. Некоторые кодировки регистронезависимы, кстати.
В самых популярных на тот момент файловых системах не предусмотрено свободных метаданных.
Юникода нет даже в планах.
"Стандарт предложен в 1991 году некоммерческой организацией Unicode Consortium".
Т.е. как минимум в планах оно уже было.
Совершенно нормально иметь по кодировке на каждый язык
Было бы не менее нормально при разработке новой ФС с нуля (допустим, той же ext2 и последующих) как-то подумать о поле "кодировка" в заголовке ФС.
И откуда следует, что неюникодная кодировка непременно должна быть однобайтовой?
А, ну да, за пределами наглоязычных стран жизни же нет, как я мог забыть...
В самых популярных на тот момент файловых системах не предусмотрено свободных метаданных.
О чём вы? Что такое "свободные метаданные"? А так - сходу вспомнилась полуось, умевшая в некие "расширенные атрибуты", которые, кстати, она могла хранить как в соотв. потрохах HPFS, так и на FAT.
Ладно, версии Linux <1.0 Торвальдс пилил just for fun и т.п., но потом-то кто мешал по нормальному переделать? Раз начались претензии на тему "сделаем наконец нормальную ОС, а не как у остальных" - чего б не подумать о будущем заранее, а не когда жареный петух клюнет?
"Стандарт предложен в 1991 году некоммерческой организацией Unicode Consortium".
А стандарт POSIX, откуда это всё - в 1988.
Было бы не менее нормально при разработке новой ФС с нуля (допустим, той же ext2 и последующих) как-то подумать о поле "кодировка" в заголовке ФС.
Можно. А дальше что делать? В папке лежит файл "А" в кодировке ,где А = 63, пользователь хочет скопировать файл "B" в кодировке где B = 63. Дальше что?
Давайте считать кодировку частью имени файла? В папке лежат Ёж, Ёж, и Ёж. В разных кодировках. С разным содержимым. Программа спрашивает: точно удалить файл "Еж"? Дальше что?
как в соотв. потрохах HPFS, так и на FAT.
Точно в потрохах, а не в скрытом файлике? Признаюсь, тут уже забыл. может быть.
Раз начались претензии на тему "сделаем наконец нормальную ОС, а не как у остальных"
Вообще-то идея была сделать систему, совместимую с POSIX и доступную всем.
а не когда жареный петух клюнет?
А что случилось-то?
Можно. А дальше что делать? В папке лежит файл "А" в кодировке ,где А = 63, пользователь хочет скопировать файл "B" в кодировке где B = 63. Дальше что?
А вот передёргивать не надо. Речь шла о кодировке имён файлов и каталогов в ФС. Что там внутри файлов - саму ФС колыхать не должно.
И, (не)кстати - вот мне приносят внешний носитель из-под винды, с NTFS. С длинными юникодными именами (напоминаю, у клятой винды не помню с какой версии NTFS под капотом юникод, а всякие 8-битные слоем выше, ЕМНИМС). И эти имена не влазиют на мою идеологически правильную ext4. Что делать в ситуации "100500 файлов, и все с длинными именами"? Несколько файлов я руками переименую, а несколько десятков/сотен? А если там куча вложенных подкаталогов, и у всех тоже имена длинные?
Пример из реальной жизни - библиотека ГОСТов.
Давайте считать кодировку частью имени файла?
Зачем?
В папке лежат Ёж, Ёж, и Ёж. В разных кодировках. С разным содержимым.
А с какого перепугу у вас имена в разных кодировках? Кто-то переставлял диск в разные машины с разной локалью?
Точно в потрохах, а не в скрытом файлике?
Скрытые файлики на FAT были. По два на каталог.
Вообще-то идея была сделать систему, совместимую с POSIX и доступную всем.
А совместимость с POSIX исключает возможность сделать нормально? А зачем такая совместимость? И если очень уж надо - не стоит ли её делать отдельной подсистемой?
Юникод ещё не изобрели. Если бы все имена файлов были в одной многобайтовой кодировке, и её придумывали бы тогда программисты, то система поддерживала бы от силы 10 популярных языков, и то с ошибками.
А зачем такая совместимость?
Для совместимости с ПО, уже написанным под POSIX. Людям работать надо было, а не файлики переименовывать.
А вот если из системы с более длинными именами файлов нужно перенести файлы в систему с короткими - то это Ж. Ж, не имеющая отношения к регистрозависимости.
Юникод ещё не изобрели. Если бы все имена файлов были в одной многобайтовой кодировке, и её придумывали бы тогда программисты, то система поддерживала бы от силы 10 популярных языков, и то с ошибками.
На самом деле хранить кодировку вместе со строкой (названием файла) - не такая уж и плохая идея и решила бы много проблем, может и без юникода бы обошлись...
А с какого перепугу у вас имена в разных кодировках? Кто-то переставлял диск в разные машины с разной локалью?
Вот как раз на такое разок наткнулся. Когда была у меня ОС Linux, и я понятия не имел, в какой кодировке там файловая система. /home на отдельном разделе. И вот решил поставить новее дистрибутив, и файлы стали кракозябрами. Оказалось, что стало теперь модно ФС в utf8, а у меня была кои8. Решилось в принципе не сложно, convmv справился. Но если бы стала похожая но чуть другая кодировка - полагаю, проблемы бы вылезли самые разные.
Давайте считать кодировку частью имени файла? В папке лежат Ёж, Ёж, и Ёж. В разных кодировках. С разным содержимым. Программа спрашивает: точно удалить файл "Еж"? Дальше что?
Вот, я, кстати, считаю это очень правильно, сделать кодировку частью описания строки (и не только для файлов).
Проблема с одинаковым начертанием стара как мир и возникает даже в пределах одной кодировки, например внутри koi8 есть русская А и латинская A. Да даже в самом ASCII латинская l весьма похожа на заглавную латинскую I и иногда на цифру 1. Эта проблема существовала всегда и это проблема иного рода. Надо ли её как-то решать? Ну, наверное было бы неплохо (показывать inode или содержимое или чексуму), но никто не спешит и как-то с этим все мирятся.
Так что пусть Торвальдс сначала придумает как отличать l, I и 1
Надо ли её как-то решать? Ну, наверное было бы неплохо (показывать inode или содержимое или чексуму), но никто не спешит и как-то с этим все мирятся.
Решается выбором шрифта. В старых консолях (где O от 0 еще и черточной для надёжности отличались) с отличием I от 1 и l было всё чОтко, а вот когда какой-то дизайнер слишком буквально избавился от засечек в шрифте - вот и получилось...
не решается эта проблема так, потому что шрифты разные и даже если в каком-то они отличаются, всё равно их можно перепутать, потому что похожи и потому что есть ещё куча других примеров помимо l и I
Если у вас правильно подобран шрифт, то не спутаете. А 100500 шрифтов в интерфейсе не нужны, максимум два (т.к. один из них - моноширинный; так что пользователь привыкнет к начертаниями и не путается), остальные нужны для дизайна того, что в этом интерфейсе делают.
С чем реально есть проблема - это с буквами одинакового начертания из разных алфавитов в одному шрифте. Но это уже "несколько другая" проблема, в том числе и потому, что эти буквы и должны выглядеть одинаково.
Но ведь это проблема шрифта, а не кодировки. В кодировке эти символы имеют различные коды и термин "похожесть" к ним не применим.
голову отрывать тем, у кого имена файлов больше 8.3 и кодировка отличная от latin1
Что бы поучаствовать, у вас нет ни сил, ни знаний, ни инициативы. Зато на насилие (пусть образное), вы легко готовы.
Но имя у файла ровно одно, и у него один хэш
Вас кто-то обманул. Поинтересуйтесь про хардлинки.
Поинтересовался. Они хранятся как отдельные сущности.
Хакнут-то ладно. Веселее, когда стандарт Юникода обновляется, и два разных имени двух файлов на диске с архивом становятся одним и тем же именем.
Согласен, поэтому регистрозависимые ФС, как бесполезный частный случай регистронезависимых, не должны были бы существовать.
Вы всё перепутали, не должны существовать именно регистронезависимые ФС.
collating sequences вместо тупых сравнений
То есть на компьютере в России файлы istanbul.txt и Istanbul.txt будут одинаковыми, а в Турции — разными?
Думаю, что в Турции это тоже одинаковые буквы, но ход мысли верный. А что вас смущает?
Так в том и дело, что в Турции — это разные буквы. В Турции uppercase("i") == "İ", а lowercase("I") == "ı".
Проблема же в том, что работы ссылки на файл, сделанной в другом регистре, будет зависеть от системной локали, что рано или поздно приведёт к проблемам.
Ну всю жизнь работа с идентификаторами зависит от локали, в том числе и с файлами. Ничего в этом невероятного нет. Бывают и с одинаковыми именами файлы рядом. Попробуйте, например, две флешки воткнуть с одинаковыми метками. Тоже мне фокус.
Потенциально это может стать еще более интересным.
Локаль - задается на уровне пользователя а не системы(ну и всякие докер-контейнеры есть). Получаем что ответ еще и зависит от того кто кто к файлу обращается.
Локаль - задается на уровне пользователя
Все не настолько плохо, как вам кажется. Все намного хуже.
Локаль может быть своя у приложения, причем как настраиваемая, так и прибитая гвоздями.
Локаль в линуксе (и не только) можно изменить только для конкретного приложения перед его вызовом (если оно не устанавливает локаль для себя само после вызова).
Это Вы про эффект Даннинга-Крюгера?
Используя имя файла как ключ поиска в файловой системе (а никакого другого штатного назначения у имени файла нет)
Чушь какая-то. Тут перемешаны собственно поиск и обращение по имени. Чтобы обратиться к файлу по имени, его надо знать. Посмотреть его в каталоге например. И здесь никакая независимость не нужна - что увидел, то и написал.
Поиск же вида "вроде как-то так назывался", который заведомо может вернуть больше одного имени, это совсем другая, внешняя по отношению к реализации ФС задача. В которой можно реализовать и независимость, и созвучие и что угодно ещё. Посмотрев результаты этого поиска, можно найти нужный файл, и обратиться к нему по имени. Регистрозависимому.
В русской Википедии есть статья Ысыах
Оно фактически да, но это не русское слово по сущности своей, оно просто напечатано кириллицей. Учитывая современные тенденции, когда создатель слова Ысыах - народ саха - использует для самоназвания слово Saqa на латинице, недалёк тот век, когда мы, наконец, избавимся от оков кириллицы.
Ждите. Это будет скоро)
Не нравится пример с кирилической Ы - вот вам чисто латинский диграф: https://ru.wikipedia.org/wiki/IJ
В Юникоде есть отдельные символы U+0132 IJ latin capital ligature ij, U+0133 ij latin small ligature ij, однако в подавляющем большинстве нидерландских электронных текстов используются сочетания обычных латинских букв I+J и i+j.
Если нидерландское слово должно начинаться с заглавной буквы, то ij становится заглавным целиком: IJsselmeer, IJmuiden. Однако во Фландрии встречаются написания, нарушающие это правило (например, Ijzer).
Вот и решайте, как должно выглядеть имя папки независимым от регистра но с первой заглавной: IJsselmeer, IJselmeer или Ijsselmeer.
А ведь латиницей ещё пользуются французы, итальянцы и румыны, все германские языки (немецкий, нидерландский, норвежский и т.д.), все балтийские славяне (сербы и хорваты например, DŽ у них отдельная буква алфавита и да это три символа в юникоде: DŽ, Dž и dž и какой из них выбрать в регистронезависимой ФС ? ) и вариант nightmare - поляки (всё далее - это диграфы, кодирующиеся в юникоде одним символом: DZ, Dz и dz, сколько шансов отличить этот диграф от DZ ? ).
И это речь ещё не про кирилицу или азиатские языки, а только про саму латиницу в одном единственном шаге от английского варианта.
Так в чем проблема? нам же для регистронезависимости привести все буквы к одному регистру и сравнить результат. С большой буквы писать требования нет. Беда только отличить диграф от двух букв, но эта беда с регистром не связана.
Для регистрозависимой - тем более проблем нет. Эти все ДЗ будут семью разными файлами включая не диграф, а две буквы.
Какой uppercase у буквы i?
Ну так и преобразовывать регистр только для тех знаков, которые входят в нужный диапазон, а остальные не трогать. В чем проблема-то. И дело не в разработчиках, "которые впитали с молоком", а в пользователях, которые тоже "впитали с молоком".
Какой диапазон считается нужным?
Тот, в котором преобразование регистра имеет смысл.
ค ง ēt໐๓ Şlน¢hคē - ຖē i๓ēēt.
Это называется «сепульки, см. сепулькарий».
ค ง ēt໐๓ Şlน¢hคē - ຖē i๓ēēt.
Ⱄ ⱍⰵⰳⱁ ⰲⱏⰹ ⰲⰸⱑⰾⰺ, ⱍⱅⱁ ⱀⰵ ⰺⰿⰵⰵⱅ?
Ну, если разработчики не понимают, когда возможно произвести преобразование регистра, а когда не надо и пытаться, то тады ой.
Преобразование регистра это должно быть где-то на уровне юникода вшито, это не вопрос разработчиков FS.
+1
Абсолютно очевидное разделение обязанностей между разными слоями программной архитектуры. Ощущение, коллега, что мы с какими-то мороженщиками тут общаемся, а не с программистами.
Вам в техподдержке надо поработать.
Вы ещё скажите, что в языке программирования идентификаторы должны быть регистрозависимыми.
Тут по-разному бывает.
Конечно, регистрозависимыми. Пару лет назад я DSL для латеха в Common Lisp делал. Пришлось костылями обкладывать, потому что reader терял регистр, а при модификации readtable пришлось бы всю остальную программу капсом писать
Это вам не попадались ObjectId, ObjectID, OBJECTID, objectid и objectId в одной функции
Это "вшито" на уровне письменности на конкретных языках, в которых строчные и прописные буквы различаются. А если в иероглифах они не различаются, то не надо и пытаться преобразовать их регистр. Как это вообще может выглядеть? Они пытались подобрать похожие иероглифы, только маленькие? )
Вам не нужно преобразовывать регистр в тех языках, в которых его нет. Кроме того, регистров (хотя бы умозрительно) может быть несколько.
Ну в общем да, для тех языков, в которых регистра нет, нет и соответствующих диапазонов юникода. Так что возможность преобразования регистра зашита в юникоде, логично там смотреть, да.
Ну в общем да, для тех языков, в которых регистра нет, нет и соответствующих диапазонов юникода.
Переведите на русский, пожалуйста. Чего и где нет?
Ну кстати, да, может быть смешаный "Şlนчай". Как в этом случае выкручивается NTFS?
Скорее всего, в NTFS будет разное поведение в зависимости от локализации ОС.
Подозреваю, что в ntfs оно решается системным вызовом (обращением к подсистеме работы с кодировками), который осуществляет либо преобразование регистра, либо регистронезависимое сравнение.
Скорее всего, в NTFS будет разное поведение в зависимости от локализации ОС.
Не, от локализации не зависит. А вот от версии системы (соответственно версии юникода актуальной на тот момент), которой этот NTFS раздел был создан - зависит.
А у транскрипции тоже регистры? По идее это же аналог звука, а у звука нет регистров
В результате мы видим, что абстракция «регистронезависимая строка Unicode» представляет из себя говно.
Ох, нахватаю я сейчас минусов… но давайте зрить в корень: абстракция «Unicode» представляет собой говно. Один лишь факт, что в ней есть нормализация, делает её технически малопригодной для многих областей, например, для проектирования ФС. И если ещё попытаться поверх навертеть абстракций типа регистронезависимости, получится совсем уж печально. О чём в письме и речь.
Ну а то, что ни одна кодировка, даже UTF-32, не позволяет рассчитать смещение адреса по индексу символа, показывает всю альтернативность одарённости дизайнеров. И делает UTF-32 скорее не кодировкой Юникода, а агитационным материалом для тех, кто не любит UTF-8: смотри, мол, брат, насколько всё может быть хуже.
Ну не смешите людей. Всегда можно ограничиться регистронезависимостью чисто в латинице. Для программеров и вообще как для основного международного языка. А остальное просто как есть.
Вот, к примеру, у буквы ы должен быть верхний регистр?
Внезапно вспоминается :)
-Сертификат? - равнодушно спросил глава комиссии у стоящего перед длинным столом подростка. Еще один нищий... Еще один день прошел...
-Вот, - Ылша положил на стол перед комиссаром свои документы. Он старался не смотреть в глаза чиновника - от того буквально разило чернухой. За годы в приюте парень хорошо научился чувствовать подкрадывающуюся угрозу и уходить от нее. "Мне сейчас проблемы не нужны, - уговаривал он себя. - Мне бы только его проскочить..."
-Сирота с границы? - желчно улыбнулся комиссар. Многие люди на Новее не любили беженцев. - Что у тебя за имя такое?
-Как назвали, - потухшим голосом ответил парень - подначки были привычны. Местные редко придумывали что-то новое. Сейчас главное получить направление в учебку.
-Ха-ха, шутники назвали! - развеселился чиновник. Хоть какое развлечение за день!
А вот с Ё - ловили недавно баг когда вообщем в одних места Ё = Е а в других нет, в результате пользователь то клиент то не клиент.
Угу, и при сортировке периодически "ёж" раньше чем "ель" оказывается
В том случае что у нас - все хуже было, в той ситуации это автоотказ клиенту в услуге, область при этом регулирование и как минимум придется отписки сочинять причастным и на запросы клиентов таких через поддержку (включая на внешних ресурсах) и на запросы из регулирующих органов куда клиенты могут пожаловаться. И даже отписка - тратит не так мало времени тех кто замешан, а его и так мало.
И это притом что в данном случае - даже на малые языки России например - можно забить тупо (а там наверно свои аналоги ё/е есть) а про иностранцев с их языками - есть тупо возможность ответить что мы поддерживаем русский, все. А если бы не было такой возможности?
Человек, который фильтрует пути в целях безопасности - долбодятел
Так и запишем, создатели/пользователи apparmor долбодятлы. Только не понятно при чем тут obscurity.
Как пример - в правилах на писано "ты можешь читать только из этой директории". Делаем манипуляции с юникодом и читаем из другой. Не знаю насколько он реален, но думаю речь о чем то подобном.
Долбодятлы, конечно. Мандаты должны быть привязаны к мандатным меткам, а не к именам файлов. Именно поэтому AppArmor не имеет сертификации как способ защиты информации, то есть заведомо дыряв.
А obscurity здесь - скрытие имени файла вместо ограничения доступа к содержащимся в нём данным.
Мандаты должны быть привязаны к мандатным меткам, а не к именам файлов
В чем различие меток от скажем каталога на файловой системе ? Учитывая что файлы в этом каталоге должны лежать именно в этом каталоге, а в другом не будут иметь смысла ?
У вас какое то все бинарное. Безопасность - это системник в залитым бетоном сейфе с airgap, да ? А что иногда ползунок "удобство <===> безопасность" можно подвинуть в левую сторону без особого ущерба, вам не приходило в голову ?
А obscurity здесь - скрытие имени файла
Почему скрытие, какое скрытие ? Имя файла может быть известно злоумышленнику изначально (скажем "~/.ssh/id_rsa")
В чем различие меток от скажем каталога на файловой системе ? Учитывая что файлы в этом каталоге должны лежать именно в этом каталоге, а в другом не будут иметь смысла ?
В том, что объектом защиты является информация из файлов либо целостность программной среды, а не сами файлы.
У вас какое то все бинарное. Безопасность - это системник в залитым бетоном сейфе с airgap, да ? А что иногда ползунок "удобство <===> безопасность" можно подвинуть в левую сторону без особого ущерба, вам не приходило в голову ?
Нет никакого ползунка. Есть модель угроз и система защиты, которая либо достаточна для предотвращения этих угроз, либо недостаточна. Всё бинарно. Вы чуть-чуть сдвинули ваш ползунок, и вас тут же через образовавшуюся маленькую щёлочку хакнут на 100%, а не чуть-чуть.
Какой у вас интересный взгляд на безопастность. Если вы работаете над каким-то продуктом, подскажите, что бы им не пользоваться.
А почему каждая файловая система, и каждая программа фильтрующая пути, делает это по своему? Может иметь общие библиотеки, чтобы работали согласованно, и не создавать описанных проблем?
Его слова выглядит как истерия от нежелания принять реальность. Как разраб, да, я с ним согласен - проще оперировать с регистрозависимостью без каких либо преобразований и упрощений. Но как конечный пользователь я не хочу чтобы у меня были папка и Папка на диске, метка и мЕтка в моей CMS, или возможность создать двух пользователей с одинаковыми логинами отличающихся регистром. Ровно как не хочу видеть две папки с одинаковыми но разными сердечками в названиях - видя их, хочется удалить обе.
Вот и получается классика жанра - разраб ругается из-за того что нужно делать то, что ему не нравится, но чего хотят пользователи
как конечный пользователь я не хочу чтобы у меня были папка и Папка на диске
Как конечный пользователь вы можете у себя назвать папку хоть первым вариантом, хоть вторым, хоть каким-либо еще. И вполне в вашей власти больше не создавать у себя папок с таким-же именем в другом регистре.
А вот другой конечный пользователь может зачем-то захотеть несколько папок с одинаковым именем и разными регистрами. И если файловая система ему этого не позволит, вы тоже скажете, что это из-за негодного разраба, который не захотел делать так, как хотят пользователи? :)
Мотивация архитектурных решений не должна сводиться к
зачем-то
Я вам даже могу вернуть ваш мяч и сказать, что пользователь может зачем-то захотеть несколько папок с полностью одинаковыми именами (причём это гораздо более реалистичный сценарий).
А в этом реалистичном случае различать он их как будет?
Например, по дате. Или по содержимому. Или вообще ему не надо их различать.
А использовать сразу правильный не сильно заглядывая внутрь как?
Так то ясно, что есть куча абстракций, где пользователи вообще файлов не видят практически, и чем дальше - тем больше. Просто входят в приложение и работают с его абстракциями.
(гори в аду андроид с одной стороны и госуслуги с другой, "мы принимаем файлы типа jpg, а вы jpeg подсунуть пытаетесь", или наоборот, не помню точно.)
Одна в левой части рабочего стола, другая в правой.
Этот другой пользователь может просто поставить файловую систему чувствительную к регистру, и не лезть со своими желаниями к тем кто использует файловые системы регистр игнорирующие. Все довольны.
Но как конечный пользователь я не хочу чтобы у меня были папка и Папка на диске, метка и мЕтка в моей CMS, или возможность создать двух пользователей с одинаковыми логинами отличающихся регистром.
Это, очевидно, задача следующего архитектурного уровня, а не драйвера конкретной ФС. Потому, что она должна быть решена для ext2/3/4, ReiserFS, xfs, btrfs, zfs, ntfs и прочих одинаково + решатель должен знать что-то о языках и алфавитах.
А в чём вы видите концептуальное назначение архитектурного уровня имени файла в FS?
Для меня, например, очевидно, что это не очень удачная (по ограниченности ресурсов в прошлом веке) попытка создать именно тот уровень, о котором Вы написали выше.
Я много времени провёл, пользуясь системой, в которой файлы (наборы данных) вообще не имели имён, и ничего страшного в этом нет. Кстати, очень близка к этому Java, где весь праздник происходит внутри jar.
Линус конкретно разносит драйвер определённой ФС. Это не тот архитектурный уровень, на котором нужно решать вопросы регистра, алфавита и т.д. файлов. В идеале, для драйвера имя файла должно быть просто набором байт определённой длины.
Это называется inode number.
Нет.
Чем inode number не подходит под ваше определение?
С архитектурной точки зрения, имя файла в FS - это начальный шаг написания Finder поверх таблицы inode. Программам оно архитектурно нафиг не нужно, только конечным пользователям.
Хотя исторически многие привыкли к имени файла как к атрибуту файлового API. Но это просто архитектурный рудимент.
Для меня, например, очевидно, что это не очень удачная (по ограниченности ресурсов в прошлом веке) попытка создать именно тот уровень, о котором Вы написали выше.
Как же я рад, что хоть кому-то это очевидно.
Я вообще мечтаю о том, что в один прекрасный день всё это говно мамонта, придуманное до моего рождения, заменят, наконец, ФС, спроектированные с нуля. В которых примонтированный раздел будет представлять собой иерархическую реляционную базу, data stream'ы — БЛОБы, программное обращение к которым будет осуществляться строго по id, а созданную по умолчанию колонку «Имя» (имя файла) пользователь при желании сможет вообще удалить.
Потому что: ну вот, примонтировали раздел для хранения фоток — и зачем там нужны имена файлов? Фотке нужны колонки «Дата съёмки», «Модель камеры» или «Жанр» (enum [Портрет, Пейзаж, Макро]). Но имя совершенно не нужно. По факту, туда, в общем-то, и пихают дубли даты или ещё чего-нибудь.
Фотке нужны колонки «Дата съёмки», «Модель камеры»
А название фотке не нужно? А комментарий?
или «Жанр» (enum [Портрет, Пейзаж, Макро])
Тогда уж множество тэгов, а не одно enum.
Возможно, вы не понимаете. С этой гипотетической системой я бы, поскольку мне название фоток не нужно, колонку «Имя» удалил, а вы бы, если оно вам нужно, оставили бы. И каждый был бы счастлив.
Приложения, поддерживающие такую ФС (например, камера), либо имели бы констрейнты к схеме (требовали наличия заданного набора полей), либо поддерживали настройку записи метаданных (в какое поле что писать). Первые — для тех, кому надо, чтоб просто работало. Вторые — тем, кому надо гибкие настройки. Как, собственно, и сейчас происходит.
Аналогично с «Жанром». Если вам надо теги — делайте колонку «Жанр» со строкой плоского текста и пишите через разделитель. Или сделайте мультистрочную колонку. Или ссылку на справочник с множественным выбором. (Надеюсь, не надо рассказывать, как это выглядело бы на уровне UI файлового менеджера? И что юзеру даже не надо было бы напрягать бедную головушку и разбираться, что такое «справочник»). А меня в качестве поля «Жанр» вполне устроил бы скромный выбор из трёх перечисленных вариантов с возможностью не выбирать. Или нет. И тогда, если передумал бы, я бы всегда мог сделать теги.
Я вообще мечтаю о том, что в один прекрасный день всё это говно мамонта, придуманное до моего рождения, заменят
Опыт показывает, что решения в IT обладают ужасной положительной обратной связью — ни одна из новых ОС не выдержала конкуренции с legacy UNIX от 1969 года. Заметьте, ни VM/370 (виртуальная машина на каждый процесс), ни Plan 9 (правильная абстракция "всё есть файл"), ни даже NT (одно ядро и разные подсистемы поверх — WSL/1 проиграл WSL/2).
Так что тут, увы, царит пессимизм. Может только после новых Средних веков, но мы этого не увидим.
Я просто не видел ни одного продукта, где бы описанное было реализовано. И поэтому, мне кажется, нельзя заранее сказать, примут его юзеры или нет.
Есть, например, Шаропоинт, который реализует некоторые из этих идей. И когда юзеры его видят, они очень скоро начинают говорить: о-о-о, круто, хотим такое же на компьютере. Но хотеть не вредно, а в формате Windows Explorer им эти плюшки никто не предлагает. В общем, слоны-то, может, и съели бы…
Как пользователь я хочу переименовать "папка" в "Папка" без плясок с бубном из-за того, что фс считает оба имени одинаковыми и ничего не делает.
Странно, но у меня все переименовалось без проблем.
Нормальная ОС без проблем переименовывает даже "папка" в "папка". Это вообще не дело файлового API - думать, одинаковый результат или неодинаковый. Тем более что результат в любом случае неодинаковый и заключается как минимум в изменении времени модификации текущего каталога.
Эта история напоминает убогие редакторы, отказывающиеся пересохранять файл без изменений.
А в какой момент остановиться? " метка" (пробелы), "метkа" (латинская k), "мтека" (опечатка), "label" (другой язык), "мeткa" (латинские e, a), "метка" (unicode zero-width space). На мой взгляд будет лучше прикладному приложению рекомендовать (например с помощью autocomplete) пользователю использовать уже существующее похожее имя, чем требовать от системы считать какие-то разные имена одинаковыми.
Различать строчные и прописные буквы учат еще в раннем детстве. Не понимаю проблемы пользователя увидеть это и переименовать как нужно.
Ограничить создание подобных имён не сложно реализовать на уровень выше файловой системы. Можно даже по смыслу - если есть "метка", то запретить "меточка" или "мeтка" (с английской e или даже "metka”
Зачем это должна решать именно файловая система? Просто фильтр при создании файлов намного уместнее. Можно и сердечки запретить.
Любой фильтр, не растущий от самых корней, можно обойти, если результат фильтрации сам по себе валиден. И вы можете получить после случайного (или злонамеренного) ввода управляющей последовательности актуальное имя, которое запрещено фильтром и которое непонятно как воспроизвести. Именно эта проблема обеспокоила Линуса.
Давайте разделим безопастность и удобство. Линуса беспокоила безопасность. Система должна быть спроектирована так, что бы обеспечить безопастность было легче. Регистрозависимые, с его точки зрения лучше для достижения этой цели.
«управляющие последовательности» должны быть однозначны и их должно быть очень мало. Всё остальное система должна фильтровать/экранировать сама/отдавать ошибку.
Удобство- вопрос прикладного софта. Пользователю удобно, что бы софт помогал ему с именами? Пусть помогает. Главное, что бы прикладной софт помнил, что это лишь удобство и позволял удалять, например, с учетом псевдодубликатов.
Давайте разделим. Всё, что пишет Линус про безопасность - полная фигня. Он хороший программист, но темой безопасности не владеет вообще. Вся встроенная безопасность ядра Линукса и традиционная дискреционная система Unix с наследованием атрибутов по дереву каталогов - полная фигня. Для того, чтобы Линукс обеспечивал требования безопасности, ему устанавливают нестандартное ядро, всякие примочки для мандатного контроля доступа, контроля целостности и т.д., и ещё аппаратные примочки к оборудованию PC для доверенной загрузки. Примерно так же, как и в случае Windows. И это не имеет вообще никакого отношения к регистрозависимости имён файлов, потому что имя файла само по себе не является атрибутом безопасности.
Безопасные на базовом уровне архитектуры системы - это мейнфреймы и iSeries (по случайному совпадению имеющие регистронезависмые ФС). Или можно смотреть на защищённые дистрибутивы Линукса.
А что делает Линус? Он справедливо замечает, что регистронезависимость создаёт проблемы в фильтрации имён. Ну так это не единственные проблемы фильтрации, сам способ порочен. Это всё равно что бумажный секретный документ разрешать читать по принципу совпадения названия (с учётом регистра, хе-хе). Тогда как в реальности на нём прежде всего стоит гриф "секретно".
А если бы Линус честно написал как есть: "неудобно выполнять доморощенные проверки в такой-то софтине", то был бы сразу понятен и ответ: "вот свою софтину и ставьте на регистрозависимый раздел".
Это всё равно что бумажный секретный документ разрешать читать по принципу совпадения названия (с учётом регистра, хе-хе). Тогда как в реальности на нём прежде всего стоит гриф "секретно".
В реальности для секретного документа будет и совпадение наименования (обязательно с учетом регистра) и гриф, и наличие пациента в списках допущенных (тоже с учетом регистра в документах). И все это вместе одновременно будет "прежде всего". Для удобства поиска регистр может игнорироваться, но при окончательной проверке он обязателен.
Сабака лает, караван идёт. (с)
Напомнило вечные страдания с датами в Excel...
Прежде чем углубляться в работу с датами и временем, важно понять, как Excel обрабатывает эти данные.
В Excel даты хранятся как последовательные числа, начиная с 1 января 1900 года.
Это позволяет выполнять математические операции с датами, что делает Excel мощным инструментом для анализа временных данных.
Excel сохраняет время, используя тот же формат порядковой нумерации, что и для дат. День у Excel «начинается», как и у нас с вами в полночь.
Если время указано без даты, например, 9:00, Excel сохраняет его, как 9:00 0 января 1900 года. Это может затруднить выполнение математических расчетов для значений времени (без даты), поскольку вычитание 6:00 из 3:00 станет отрицательным и будет считаться ошибкой, так как 0,125 – 0,25 = -0,125 , что будет отображаться как #########.
Если же время указано вместе с датой, то проблем не возникнет.
остальное в региональных настройках только может пострадать а причина им обычно отсутствие обновлений
сами даты тоже глючные особенно расчётные по календарю тк на земле одномоментно может быть три разные даты и стабилен только день недели тк каждый день последний - месяц не прошёл как был последний спор по дате
Принцип "Все является файлом" однажды всё-таки должен быть заменен на "Все является элементом структуры", где для каждого элемента присваивается совокупность идентификаторов и имён, например
{id int, code case_sensitive string, full_name case_insensitiv string}, где:
id - индекс внутри среды исполнения
code - человеко-ориентированный регистрозависимый идентификатор, не меняющийся при копировании между средами (системами) исполнения (хранения)
full_name - регистронезависимое отображаемое для пользователя имя элемента
Командная строка, пути к файлам с такими структурами может усложниться превратившись в подобие json. Конечно, в этом случае ОС с клавиатуры админить напрямую не получиться. Но ведь появился ИИ, который любой текст при наличии словаря легко преобразует в json, командная строка легко возродится в новом качестве.
Забавный пример уязвимости из-за сабжа
А чего так возбуждаться - то? Линус - это, конечно, фигура. Но он - это один из совсем немногих, кто настолько погружен в эту тему, он имеет свое мнение. А теперь давайте задумаемся - настолько ли важно наличие или отсутствие заглавных букв в именах файлов для каких-нибудь домохозяек, студентов, клерков... Сколько разных файлов нужно им в процессе использования компьютера в быту? Особенно если учитывать возможность давать файлам длинные имена. Слава Богу, эпоха 8.3 вообще говоря осталась позади...
Это - мое сугубо личное мнение, и я не претендую на его обсуждение.
О, привет язык Nim, который пошёл еще дальше, к регистронезависимости ещё и знак подчёркивания добавили. Например идентификатор notin равен идентификатору notIn и это тоже самое что и NOT_IN Очень оттолкнуло в своё время.
notin = notIn = NOT_IN
https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
Вот такие "помощники" которые решают за программиста и вводят неявные правила, которые надо держать в голове - только ухудшают ситуацию.
Лучше бы он наконец избавился от файлов в исходниках ядра, отличающихся только регистром.
Ругайся не ругайся, а костыли городить приходится. Типичная ситуация - файл хранится на сервере с Linux, при этом синхронизируются с машинами пользователей под Windows и Mac. С регистро[не]зависимостью ещё худо-бедно научились справляться в софте, а вот пробелы в конце имени файла и кавычки в имени, которые легальны на Mac и Linux и недопустимы под Win - вечная головная боль.
А файл с именем con в винде уже разрешили создавать?
md \\.\C:\con
Для понимания, стоит изучить эту статью: https://habr.com/ru/articles/731628/
на win защита от дураков технологичнее: пароли и логины тоже не начинаются и/или не заканчиваются на пробелы ... кому сильно надо всегда был 0xFF да суй куда хочешь ничего не ломая
А зачем в имени файла пробелы и кавычки?
А зачем в именах файлов кириллица? И вообще 8.3 хватит всем.
Но если оставить сарказм, то могу сказать за себя: мне гораздо комфортнее видеть файл "Обыкновенное чудо (Захаров).mkv", чем "Obyknovennoe_chudo_Zakharov.mkv". Туда же книги, музыка. А за ними уже и остальное тоже приходит.
Да, мне кажется странной идея тащить пробелы (как и многое другое) в имена исходников кода, но возможно когда-то и это никого не будет удивлять.
Пробелы создают проблемы только когда они последний символ имени. Очень часто такое появляется у пользователей Маков. Подозреваю, они название файла/папки откуда-то копируют (из текста документа и пр.), при этом автоматически выделяется и копируется не только слово, но и пробел за ним. Маководам-то всё равно, серверу на Линуксе тоже, а вот коллегам с Виндой при попытке это скопировать/открыть ошибки прилетают.
С кавычками аналогично, куча документов с названиями всяких юрлиц. Пользователи Маков эти названия вместе с кавычками невозбранно пихают в имена файлов, ну а у кого Винда - см. выше.
только планироващики в винде и линуксе оставляют желать лучшего,...... )
где мой 129 ядерный пк чтобы уж наверняка покрылись нагрузки )) (шутка)
Не понимаю тех, кто голосует за регистронезависимость. Может еще пароли регистронезависимыми делать, для удобства? И буквы одинакового написания сводить к одному символу?
С буквами есть проблема, что некоторые из них имеют одинаковое написание в одном регистре и разное в другом (например, У и Y). Если б не это, то действительно было бы удобно. На ЕС ЭВМ так и было (кодировка ДКОИ).
А я понимаю, что должны означать файлы README и readme? Регистр придуман для читаемости, очевидно что исходная проблема вообще не касается регистра, а касается того, что Unicode превратили в помойку.
Наконец-то срач на Хабре! Сколько лет уже ничего подобного не было.
А по теме - думаю ошибка заложена гораздо глубже, в том что вообще в кодировки ввели понятие "регистр" (хотя по смыслу это всего лишь вариант написания, такой же как "bold", "italic" или "underline"). А потом усугубили это в Юникоде всякими символами, которые можно составить разными способами, невидимыми символами и т.п. Юникод вообще по хорошему нужно полностью переделать с нуля, с тотальным нарушением обратной совместимости, но это явно тема отдельной статьи.
Но если уж всё это есть, то думаю Линус прав - всякие нетривиальные сравнения всегда содержат потенциальные ошибки и уязвимости. Проще относиться к именам файлов как к байтам и тупо сравнивать побайтово. А если кому-то надо то пускай делают слои верхнего уровня над ФС, где и реализуют регистронезависимость, игнорирование невидимых символов и прочее.
Юникод вообще по хорошему нужно полностью переделать с нуля, с тотальным нарушением обратной совместимости
Юникод вообще нужно полностью удалить, и пользоваться ascii. Мало того, что всякой абракадабры напридумывали, так она еще места в 4 раза больше жрет
Юникод вообще по хорошему нужно полностью переделать с нуля
1. Выкинуть кодепоинты на помойку, как не оправдавшую себя абстракцию. Положить в основу системы символы. Составить список всех символов, каждый символ должен иметь строго уникальный код.
2. Сделать две кодировки: 8-битную и 32-битную (64 бита оставить про запас).
2a. 8-битная кодировка должна быть обратно совместимо с ASCII (как UTF-8), но, в отличие от UTF-8, кодировать символы, а не кодепоинты. Кроме того, её ёмкость изначально должна быть потенциально бесконечной (N байтов при N > 6 (скажем, N = 10) могут кодировать один особо редкий символ).
2b. 32-битная кодировка должна иметь фиксированную ширину. Что будет, когда мы исчерпаем 4 миллиарда символов? А что будет, когда Солнце превратится в красного гиганта? Когда-нибудь, наверно, придётся об этом подумать, но нескоро. Кроме того, даже когда этот вопрос станет актуальным, 32-битную кодировку можно будет продолжать использовать как подмножество бесконечного множества 8-битной.
3. Группы символов строим, соблюдая баланс между запасом индексов для будущих символов в группе и оптимальностью хранения (чтобы как можно чаще влезать в 2 байта). Приоритет отдаём реально часто пополняемым группам. Запас под смайлики должен быть >> размера группы верхне-древне-пышминского алфавита (тот может идти несколькими группами и требовать хоть шесть байт на символ).
3a. DEI-символы изначально ставим вразброс, чтобы добавление смайлика с новым оттенком кожи, идущего не подряд, не несло намёка на сегрегацию.
3b. То, что рано или поздно произойдёт переполнение каких-то групп, изначально считаем неизбежностью и не паникуем.
4. Преобразования регистра делаем внешней таблицей. Она должна быть строго однозначной. Это решит все проблемы, описанные в письме Линуса. Если понадобятся иные языковые преобразования, так же делаем их строго однозначными внешними таблицами.
5. Начертания (weight'ы, измеряемые в сотнях, курсивы, small caps'ы) в общем случае оставляем шрифтовикам. В частном же случае, при включении их в группы символов, считаем это языковыми преобразованиями и делаем внешней таблицей (см. 4). То есть, преобразование Cats are nice → ᴄᴀᴛꜱ ᴀʀᴇ ɴɪᴄᴇ должно универсально и однозначно работать для любого языка. В отличие от Юникода, такие апдейты таблицы символов должны происходить одновременно для всех алфавитов (а то для латиницы всё всегда есть, а для кириллицы или греческого small caps'ов, например, некомплект).
Добавляйте свои пункты.
2b. 32-битная кодировка должна иметь фиксированную ширину.
Поздравляю, вы только что изобрели UTF-32
3а. Это сейчас проблема с сегрегацией. Потом будет запрос на командный дух и придётся делать новую кодировку, где смайлики вместе. Или запрос культурную независимость и все смайлики нужно разбить на соотвествующие группы.
Всю возможную политику заранее в код не запихнешь.
3a. DEI-символы изначально ставим вразброс, чтобы добавление смайлика с новым оттенком кожи, идущего не подряд, не несло намёка на сегрегацию.
Всей этой [censored] вообще быть не должно.
А по-моему, в каждой идее есть здравое зерно, и есть злоупотребления.
Когда профессор жалуется, что для организации международной конференции ему приходится спрашивать приглашаемых, как часто они ****** в **** (реальное положение дел в прошлом году, между прочим! Т-Инвариант рассказывал) — это злоупотребление.
А когда кто-то хочет иметь смайлики для своего оттенка кожи и не хочет, чтобы они чем-то выделялись даже технически — это здравое зерно. Потому что слишком часто это заканчивается отдельной комнатой.
Я понимаю, что DEI-дураки всех достали, но и в расизм скатываться тоже считаю неправильным.
Я бы убрал из Юникода смайлики вообще. Пусть для них будет какой-то свой отдельный Смайликод или что угодно, но их добавление в Юникод ломает всю идею.
Количество символов в национальных алфавитах и в существенной степени - спецсимволов (научных, знаков валют и пр.) задано нам извне, более или менее известно и крайне редко меняется.
Смайликов же можно придумать бесконечное множество, плодятся они буквально на глазах, никакого историко-культурного контекста, позволяющего определить, какие включать в стандарт, а какие нет, у нас нет.
+1
Смайлы цветные, поэтому ломают абстракцию текста, который можно написать любым цветом.
По-моему, это попытка заменить исходную трудную задачу своей, более лёгкой. Поддерживать прогресс (появление новых символов) так или иначе надо, Юникод с этим справляется, значит и любой альтернативной системе придётся.
Почему надо? А как быть с символом ₽, например? Который появился значительно позже Юникода (официальное утверждение произошло 11 декабря 2013 года). Механизм пополнения должен быть. А если есть механизм, то почему его не использовать для смайликов?
Это инженерный взгляд. А есть ещё юзерски-потребительский: система без смайликов просто будет мертворождённой.
Символы рубля, евро, какие-то новые научные обозначения, новые буквы языков (тоже бывает, скажем, при смене письменности) возникают не в Юникоде. Они возникают извне, а Юникод только инкорпорирует эти объективно произошедшие изменения, и это правильно. По поводу необходимости включения или невключения этих символов нет сомнения, есть официальный источник. И эти изменения достаточно значимые и достаточно редкие.
В случае же со смайликами Юникод превращается из системы кодирования данных нам во внешних источниках символов в систему добавления новых. Причём добавления произвольного, частого и непредсказуемого. Нет никакой внешней причины или источника, почему смайлик с ромашкой надо включить в стандарт, а с гладиолусом - не надо (пример условный, не проверял, какие там цветочки есть на самом деле :)
система без смайликов просто будет мертворождённой.
Как-то Юникод все те годы, когда в нём не было смайликов, прожил. Пользователь вообще ни про какой Юникод не в курсе. Он хочет, чтобы смайлики между разными мессенджерами копировались. Ну так сделайте для них свой стандарт, зачем с этим сиюминутным баловством лезть в серьёзный стандарт.
Идея хорошая, но есть вопросы.
1 Турецкий язык с его I и i. Выносим в отдельную страницу? Туда же и другие языки, использующие расширенную латиницу (всякие закорючки у букв сверху, снизу и прямо на буквах), но по разному (разная сортировка алфавитов, разное преобразование регистров). Но тогда получается, что с точки зрения "нового юникода" каждый такой язык получит собственную уникальную письменность. Но, учитывая число таких языков, получим адскую избыточность.
Для одноязычных текстов оно таки решаемо внешними таблицами, завязанными на локаль. А как быть с многоязычными? Применять при преобразованиях словарный контроль? А как быть с инициалами? Делать локаль признаком строки или даже отдельного символа в тексте? Как по мне - неоправданное усложнение для большинства случаев.
2 Языки с хитрой письменностью, начертание символов которой зависит от соседних символов (плюс рукописные шрифты).
Тут непонятно, как действовать. С одной стороны, каждый символ должен иметь один код, независимый от начертания, а вариативность начертаний оставить шрифтам и/или системам отображения текстов. Но иногда нужно выводить символы по одному, причем в нехарактерном окружении (например, для демонстрации вариантов написания при обучении). Использовать картинку? Предварять символ модификатором, определяющим начертание независимо от соседей? Заставлять использовать отдельный шрифт для каждого варианта?
Я не знаю, в чём замутка конкретно с турецким языком, но как инженер рассуждаю так. Если символ национального алфавита следует ВСЕМ правилам латиницы, включая инверсию капитализации — значит, это символ латиницы. Если же у него есть какие-то особенности — значит, это уже новый символ, произошедший от латиницы. Иными словами, если «адская избыточность» нужна чтобы устранить неоднозначность — это никакая не избыточность.
Об этом не думал, но, по-моему, место этой логике именно в шрифтах / системах вывода. Сейчас вон есть программерские шрифты, которые выводят
<=и>=лигатурами (как в учебниках математики). Баловство, конечно, но если бы для меня было важно такое отображение, я бы поставил именно шрифт, а не ожидал новых языков программирования. Соответственно, и для родного языка придерживался бы такой же логики.
В турецком есть i, которая в верхнем регистре İ, и ı, которая в верхнем регистре I. В принципе, можно считать это двумя нелатинскими буквами, да.
ВСЕМ правилам латиницы
Давайте заслушаем от вас полный список правил латиницы...
Для начала, давайте вы просто напишете, какие буквы по вашему мнению входят в латиницу. А потом укажете, с какого примерно века.
Давайте начнём с того, что выше я критикую Юникод как инженер, а не как лингвист. Критикую, причём, в порядке чисто душу отвести, потому что хоть это и плохо продуманная хрень, малопригодная для проектирования регистронезависимых ФС (это ведь становится проблемой именно из-за Юникода, а не потому, что регистронезависимые ФС в принципе плохая идея), но она с нами, увы, надолго. Я не представляю, что должно случиться, чтобы на этом этапе кто-то реально сломал весь имеющийся софт и библиотеки. Поэтому и надо было семь раз отмерять на стадии дизайна.
Так вот, почему с меня вы спрашиваете «полный список правил латиницы»? Я написал, что все языковые преобразования (смена регистра, например) должны быть внешними таблицами [символ, символ]. Полный комплект этих таблиц применительно к символам латиницы и даст нам, как вы его назвали, «полный список правил латиницы».
На практике это означает, что ответ на вопрос, считать ли турецкую i латиницей, зависит от возможности однозначного преобразования через эту внешнюю таблицу.
я критикую Юникод как инженер
Как инженер-плюс-программист, вы обязаны знать про то, что есть невычислимые задачи. Грубо говоря, не всё можно алгоритмизировать по тем или иным причинам.
Так вот, почему с меня вы спрашиваете «полный список правил латиницы»?
Составление этого списка — невычислимая задача. Потому, что латиница во всех её применениях меняется быстрее, чем это можно формализовать. Даже быстрее, чем это можно задокументировать.
На практике это означает, что ответ на вопрос, считать ли турецкую i латиницей, зависит от возможности однозначного преобразования через эту внешнюю таблицу.
Вы ставите всё с ног на голову. Есть реальный мир с реальными людьми, а мир програзма — это отражение реального мира. Соответственно, это не люди должны подстраиваться под таблицу, а наоборот.
Составление этого списка — невычислимая задача. Потому, что латиница во всех её применениях меняется быстрее, чем это можно формализовать.
А можно пример такого быстрого изменения?
Допустим, для начала у нас есть преобразования из нижнего регистра в верхний и наоборот. Ещё допустим, что small caps из начертания надо будет превратить в символы, и потребуются преобразования обычный текст → small caps и наоборот.
Какое изменение произошло недавно и его нельзя было бы оформить только дополнительной внешней таблицей? То есть, пришлось бы ещё и вводить новый символ в основную таблицу? (Это было бы проблемой: старые тексты не поддерживали бы новые преобразования, а среди новых текстов не работал бы поиск у старых программ).
А можно пример такого быстрого изменения?
Вам уже выдали пример с турками. Возьмите какой-нибудь Вьетнамский язык, там тоже груда веселухи.
Вы, кажется, преувеличиваете свои возможности в лингвистике. Это известный эффект какого-то Крогера, Шрюгера, или как его там.
Какое изменение произошло недавно и его нельзя было бы оформить только дополнительной внешней таблицей?
Вот ответ на этот вопрос и является прекрасной темой для докторской диссертации в лингвистике. Или вы выступаете как мудрый филин из анекдота №1030800007? Стратегией занимаетесь?
нельзя было бы оформить только дополнительной внешней таблицей?
Даже текущее состояние не всегда оформится дополнительной таблицей.
Немецкий язык. Строчный ß (эсцет) переводится в прописные SS. При этом, в зависимости от слова прописные SS могут переводиться как в строчные ss, так и в ß.
DAS FLOSS -> das Floß, но DIE FLOSSE -> die Flosse.
В 2017 официально ввели лигатуру ẞ, стало гораздо проще.
Греческий язык. Строчные σ, ς переводятся в Σ, а обратный перевод зависит от положения буквы в слове.
Для начала, давайте вы просто напишете, какие буквы по вашему мнению входят в латиницу. А потом укажете, с какого примерно века.
Воаросине мне, но все же.
Логичным мне представляется считаль латиницей таки латинский алфавит, который можно зпфиксировать в любом составе (для времени произвольное назначение начального момента прокатывает, почему тут не должно?), включая или не включая диграфы и всякие модифицированные символы (со всякими там умляутами, циркумфлексами и т.п.) ро своему произволу. Ну и состав правил для латиницы можно сфопмировать также произвольно.
Турецкий язык используется в качестве показательного примера, в котором верхний регистр для i, внезапно, İ. Т.е. как раз особенное поведение для символа латиницы. Вроде бы логично выбрать именно для этого символа особый код для турецкого языка. Кроме того, для уменьшения избыточности логично часть набора кириллицы заменить идентичными символами латиницы (поведение при преобразовании регистра у них тоже должно быть идентичным, а потому русское и латинское к логично считать одним символом, а русское и латинское Т - разными). Но тут мы упираемся в ряд проблем. Первая - все та же политика и традиции. Согласятся ли турки считать свою i не латинским символом? Вторая - возможное наличие символов с разными кодами и идентичным начертанием с сохранением смысла символов (тут просто не вижу однозначно беспроблемного решения). Третья - привычка сортировать символы по кодам (не знаю, как оно в турецком, и каково место для i в их алфавите, но в русском это часто делают).
А эти лигатуры занимают одно знакоместо или два? В первом случае проблемы будут у любителей моноширинных шрифтов и выравнивания кода пробелами. Во втором будет неочевидное поведение курсора в случае все того же моноширинного шрифта. Хотя тут все же логично принять, что если мешает, просто не используй такой шрифт.
часть набора кириллицы заменить идентичными символами латиницы
В смысле, считать одним символом кириллическую и латинскую «а» только на основании схожести? Вот уж на чём точно лучше не экономить. Хотя бы потому, что при поиске смешанного русско-английского текста мне лишние вхождения не нужны.
А эти лигатуры занимают одно знакоместо или два? … если мешает, просто не используй такой шрифт.
А вот, например (с картинками):
https://github.com/tonsky/FiraCode
Там и три есть (для ===). Мне НЕ нравится, и я не пользуюсь. Если бы мне нравились лигатуры, я бы, возможно, стал математиком, а не программистом. Но я никогда не любил эти их формульные рисунки, предпочитая код в plain text.
Как вы себе представляете слой верхнего уровня, реализующий регистро[не]зависимость? Если у вас физически в ФС рядом лежат file и FILE?
Слой, реализующий регистронезависимость, как раз не должен допускать таких ситуаций. А если они созданы извне, разрешать их модификацией имен или добавлением дополнительного различающего признака (но в этом случае операция открытия файла должна обеспечивать задание этого признака и выбор по умолчанию, если признак не задан).
В обратную сторону (регистрозависимость) проблем нет.
Тем временем в Линуксе команда -r (recursive) может задаваться только большой R, может задаваться только маленькой r, а может пошел ты нахрен.
обидеть финна может каждый... каждый символ unicode
Линус Торвальдс жёстко разнёс регистронезависимые ФС