Какую последовательность символов разве я не должен позволять в имени файла?
Я узнал после тестирования, что Linux позволяет любой символ в имени файла за исключением / и пустой указатель (\0). Таким образом, какую последовательность разве я не должен позволять в имени файла? Я слышал продвижение - может перепутать некоторые программы командной строки, который не имеет значения для меня, однако это может побеспокоить других людей, если они решают собрать набор файлов и отфильтровать его с некоторыми программами GNU.
Было предложено мне удалить продвижение и конечные пробелы, и я планирую к тому, только потому, что обычно пользователь не означает иметь продвижение/конечный пробел.
Чем могла бы там быть проблематичная последовательность и какую последовательность я должен рассмотреть не разрешением? Я также считаю не позволяющие символы недопустимыми в окнах только для удобства. Я думаю, что не могу позволить тире вначале (тире является легальным символом окна),
6 ответов
Ваш вопрос несколько сбивает с толку, так как вы подробно говорите о Linux, но затем в комментарии к другому ответу вы говорите, что генерируете имена файлов для загрузки , что, по-видимому, означает, что у вас нет абсолютно никакого контроля над файловой системой и операционной системой, в которой будут храниться файлы, что делает Linux совершенно неактуальным.
Для этого ответа я предполагаю, что ваш вопрос неправильный, а ваш комментарий правильный.
Подавляющее большинство используемых сегодня операционных систем и файловых систем можно разделить примерно на три категории: POSIX, Windows и MacOS.
В спецификации POSIX очень четко указано, как выглядит имя файла, которое гарантированно переносится между всеми системами POSIX. Символы, которые вы можете использовать, определены в разделе Раздел 3.276 (Переносимый набор символов имени файла) базовой спецификации Open Group как:
ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz 0123456789._-Максимальная длина имени файла, на которую вы можете полагаться, определена в разделе 13.23.3.5 (
Минимальные значения) как 14. (Соответствующая константа - _POSIX_NAME_MAX.)
Таким образом, имя файла длиной до 14 символов, содержащее только 65 символов, перечисленных выше, безопасно для использования во всех POSIX-совместимых системах, что дает вам 24407335764928225040435790 комбинаций ( или примерно 84 бит).
Если вы не хотите раздражать пользователей, вам следует добавить еще два ограничения: не начинайте имя файла с тире или точки. Имена файлов, начинающиеся с точки, обычно интерпретируются как «скрытые» файлы и не отображаются в списках каталогов без явного запроса. Имена файлов, начинающиеся с тире, могут интерпретироваться как опция многими командами. (Примечание: удивительно, сколько пользователей не знают о трюках rm ./-rf или rm - -rf .)
Остается 23656340818315048885345458 комбинаций. (все еще 84 бита).
Windows добавляет к этому несколько новых ограничений: имена файлов не могут заканчиваться точкой, а имена файлов не чувствительны к регистру. Это сокращает набор символов с 65 до 39 символов (37 для первого символа, 38 для последнего символа). Он не добавляет никаких ограничений по длине, Windows отлично справляется с 14 символами.
Это сокращает возможные комбинации до 17866587696996781449603 (73 бита).
Еще одно ограничение заключается в том, что Windows обрабатывает все, что находится после последней точки, как расширение имени файла, которое обозначает тип файла. Если вы хотите избежать возможной путаницы (скажем, если вы создаете имя файла вроде abc.mp3 для текстового файла), вам следует вообще избегать точек.
У вас все еще есть 13090925539866773438463 комбинации (73 бита).
Если вам нужно беспокоиться о DOS, то применяются дополнительные ограничения: имя файла состоит из одной или двух частей (разделенных точкой), где ни одна из двух частей не может содержать точку. Первая часть имеет максимальную длину 8, вторая - 3 символа. Опять же, вторая часть обычно зарезервирована для указания типа файла, что оставляет вам только 8 символов.
Теперь у вас есть 4347792138495 возможных имен файлов или 41 бит.
Хорошая новость заключается в том, что вы можете использовать трехсимвольное расширение, чтобы на самом деле правильно указать тип файла, не нарушая ограничения имени файла POSIX (8 + 3 + 1 = 12 <14).
Если вы хотите, чтобы ваши пользователи могли записывать файлы на CD-R, отформатированный в соответствии с ISO9660 уровня 1, то вы должны запретить перенос дефисов в любом месте, а не только в качестве первого символа. Теперь оставшийся набор символов выглядит как
ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789_, что дает вам 3512479453921 комбинацию (41 бит).
Поскольку вы, похоже, в первую очередь заинтересованы в Linux, следует избегать символов, которые (типичная) оболочка будет пытаться интерпретировать, например, как подстановочный знак. Вы можете создать файл с именем «*», если будете настаивать, но у вас могут быть некоторые пользователи, которым это не очень нравится.
urlencode все строки, которые будут использоваться в качестве имен файлов, и вам придется беспокоиться только о длине. Этот ответ , возможно, стоит прочитать.
Не ясно из вопроса, используете ли вы веб-формы или MVC. В любом случае вы хотите использовать какой-то менеджер сценариев.
Для MVC я нашел, что это исследование во многом та же проблема: Simple StartManager for ASP.NET MVC
Для Webforms, э-э, не уверен, я должен пойти сделать домашнее задание снова
-121--4950386-Если вы хотите, чтобы люди могли запустить ваш код (а если нет, то почему вы написали его в первую очередь?), то их ЦП должен иметь возможность выполнить ваш код. Для выполнения кода ЦП должен иметь возможность понимать код.
Поскольку ЦП являются тупыми, а люди - нет, это означает, что люди также могут понимать код.
Существует только один способ убедиться, что ваши пользователи не получают ваш код: не давать им свой код.
Это может быть достигнуто двумя способами: Программное обеспечение как услуга (SaaS), то есть вы запускаете программное обеспечение на сервере и разрешаете пользователям только удаленный доступ к нему. Это модель, которую использует, например, переполнение стека. Я уверен, что Stack Overflow не запутывает их код, но вы не можете декомпилировать его.
Другим способом является модель устройства: вместо того, чтобы давать пользователям код, вы даете им компьютер, содержащий код. Это модель, которую используют игровые консоли, большинство мобильных телефонов и TiVo . Обратите внимание, что это работает только в том случае, если вы «владеете» всем путем выполнения: вам нужно построить свой собственный CPU, свой компьютер, написать свою собственную операционную систему и собственную CLI реализацию. Затем и только тогда можно защитить код. (Но обратите внимание, что даже крошечная ошибка сделает бесполезными все ваши средства защиты. Microsoft, Apple, Sony, музыкальная индустрия и киноиндустрия могут подтвердить это.)
Или вы можете просто ничего не делать, что означает, что ваш код будет автоматически защищен законом об авторском праве.
-121--1799648-Рекомендуется использовать набор символов белого списка. В общем, символы в именах файлов будут раздражать людей.
Всеми способами разрешить людям использовать символы a-z 0-9 и юникод > 0x80, но не разрешать произвольные символы, такие как & и, вызовет много досады, а также фуллстопы в неподходящих местах.
Я думаю, что символы ASCII, которые можно разрешить, это: полный знак подчеркивания дефис
Разрешение любых ДРУГИХ символов ascii в имени файла требует проблем.
Имя файла не должно начинаться с символа ascii. Политика в отношении мест в именах файлов является сложной, поскольку пользователи могут ожидать их использования, но некоторые имена файлов явно глупы (например, те, которые НАЧИНАЮТСЯ с местами)
Я бы оставил определение того, что "допустимо", на усмотрение ОС и драйвера файловой системы. Позвольте пользователю ввести все, что он хочет, и передать его дальше. Обрабатывайте ошибки ОС соответствующим образом. Исключением является то, что я считаю разумным убрать начальные и конечные пробелы. Если люди хотят создавать имена файлов со встроенными пробелами, дефисами в начале или вопросительными знаками, а выбранная ими файловая система позволяет это, не вам следует пытаться предотвратить их.
Можно монтировать разные файловые системы в разных точках монтирования (или на дисках в Windows), которые имеют разные правила в отношении допустимых символов в имени файла. Обработка такого рода вещей внутри вашего приложения потребует гораздо больше работы, чем необходимо, потому что ОС уже сделает это за вас.
Вы разрабатываете приложение, в котором вы должны просить пользователя создавать файлы самостоятельно? Если это то, что вы делаете, вы можете установить правила в своем приложении. (например, разрешить только [a-zA-Z0-9_.] и отклонить остальные специальные символы.) это намного проще обеспечить.