Вы платите свои деньги, и вы берете свой выбор: Да, нет, может быть.
Это сводится к вашему определению «расширение».
- Действительно ли это «что-нибудь после последней точки в названии»? Если это так, эти файлы не имеют имени и все являются расширением.
- Это «что-нибудь после точки, которая не является первым символом в названии»? Если это так, эти файлы не имеют расширения.
- Если вы используете какое-то другое определение, ответ должен быть соответствующим образом скорректирован.
Помните, что SCCS файлов используется префикс s. (среди других, вы бы увидели p. файлы тоже - и там было много переходных имен файлов с другими приставками). У файла SCCS s.something есть расширение или префикс? (С s.source.c, это достаточно прямолинейно, есть префикс, имя и расширение или суффикс, или вы можете игнорировать префикс в качестве специального случая, а имя - s.source, а расширение - .c.) Что относительно исполняемого по умолчанию имя, a.out? Как насчет такого имени, как ..dot; у него есть расширение, и если да, то что это?
Обратите внимание, что ответ на DOS был более формализован. Там файловая система использовалась для принудительного исполнения (один раз в другое тысячелетие или около того) имена с 8.3, и расширение было ощутимым. Но это ушедшая эпоха по большей части (и мало кто ее пропустит).
Anthony Arnold и paxdiablo оба отметили, что имена, заканчивающиеся на .tar.gz, существуют - в чем расширение на такие файлы?
Если вы относитесь к расширению somecode-8.76.tar.gz как к чему-либо, кроме .gz, вы открываете себя до мешковины. Файл содержит somecode-8.76.tar; что само по себе можно утверждать, что имеет расширение .tar. Определение расширения всего gzipped tar-файла, как .tar.gz, ставит вопрос о «почему это не .76.tar.gz», а также означает, что вам нужно пересмотреть соглашение об именах файлов SCCS. Впитывая часть .76 имени в .76.tar.gz или .76.tar, как суффикс делает жизненный комплекс действительно. Это правильный вопрос, но ничего, кроме «расширения, является строкой от последней точки до конца имени», действительно чревато или требует интерпретации значения расширения и попадает в другую сложную область, в которой обычно лучше избегать.
Обратите внимание, что Unix на уровне O/S или файловой системы не заботится о расширении файлов.Программы могут решить, что они заботятся о расширениях, но это зависит от программы. Расширение является индикатором типа файла; это не является окончательным. Вот почему существует программа file для идентификации содержимого файлов. Он просматривает содержимое файла для идентификации содержимого; он не обращает внимания на расширение файла (так что ему не нужно решать, что такое расширение).
Очень интересно. Ну, учитывая, что они оба трактуют dotfiles по-разному, кажется разумным предположить, что они оба работают с разными стандартами (независимо от того, существует ли в этом случае «истинный» стандарт). Мысли? –
Интересно. [Boost.Filesystem] (http://www.boost.org/doc/libs/1_59_0/libs/filesystem/doc/reference.html#path-extension), например, считает, что это расширение файла без имя файла. "path extension (const path & p) const;' ... if p.filename() содержит точку, но не состоит только из одной или двух точек, возвращает подстроку p.filename(), начиная с самой правой точки и заканчивается в конце пути. В противном случае возвращает пустой объект пути. " – Anthony
@JoshBeam, PHP имеет тенденцию идти в такт другому барабанщику, а затем выпасть из шага и взять пару неправильных поворотов от этого другого барабанщика. Посмотрите, как он обрабатывает строки запроса или любую из его стандартной библиотеки. Тем не менее, я всегда рассматривал dotfiles как файлы с расширением, не имеющие имени файла, поэтому я был удивлен, что узел будет считать, что у них нет расширения. – zzzzBov