Правила именования файлов: полное руководство для команд

Роскомнадзор при проверках часто обнаруживает файлы с персональными данными, хаотично разбросанные по дискам без системы — это первый признак неудовлетворительного режима защиты данных по 152-ФЗ. Правильная система именования файлов — это не только производительность команды, но и доказательство того, что вы контролируете, где хранятся данные. Соглашение об именовании файлов, выдерживающее столкновение с реальностью, использует следующий формат: ГГГГ-ММ-ДД_КодПроекта_ТипДокумента_Описание_vNN.расш. Всегда даты ISO 8601 (они сортируются правильно), короткие коды проекта (3–10 символов), контролируемый словарь для типа документа, описания в kebab-case, двузначные номера версий (v02, а не v2) и строчные буквы там, где это не важно. Формат важен меньше, чем последовательность — выберите один, запишите и внедряйте при онбординге и во время еженедельных чисток.

Почему дата в начале лучше, чем дата в любом другом месте

Даты ISO 8601 (ГГГГ-ММ-ДД) в начале имени файла решают проблему сортировки. 2026-06-12_отчёт.pdf стоит рядом с 2026-06-13_отчёт.pdf в любой файловой системе, любом облачном диске, любом инструменте. Перенесите дату в конец — потеряете это; перенесите в середину — сортировка станет случайной.

Используйте именно ISO 8601, а не US (ММ/ДД/ГГГГ), UK (ДД/ММ/ГГГГ) или без пунктуации (ГГГГММДД). ISO — единственный формат, который:

Сортируется правильно как текст
Однозначно парсится в разных локалях (06/05/2026 — это 6 мая или 5 июня?)
Соответствует международному стандарту, используемому журналами всех крупных технологических компаний

Для чувствительных ко времени файлов добавьте время: 2026-06-12T1430Z_заметки-встречи.md использует UTC. Полезно для мультитайм-зональных команд, где «когда это было создано» важно для ясности передачи.

Коды проекта, масштабируемые в будущее

Короткий код проекта на второй позиции делает файлы ищущимися по проекту без зависимости от структуры папок. Правила, которые работают:

3–10 символов, все заглавные, дефисы допустимы
Первые 3–4 символа идентифицируют клиента или внутреннее подразделение
Опциональный суффикс идентифицирует тип или фазу проекта

Примеры: АЛФА-РБ (ребрендинг Альфа), ВНУТР-ОНБРД (внутренний онбординг), ФИНОПС-Q2 (финансовые операции Q2), АЛФА-ПОДД-001 (проект поддержки Альфа №1).

Ведите реестр кодов проектов в Notion, Confluence или общей таблице. Когда кто-то создаёт новый проект, он регистрирует код. Занимает 30 секунд. Предотвращает ситуацию, когда через три месяца один называет файл АЛФАребрендинг, другой — Альфа-РБ, и оба файла существуют одновременно.

Контролируемый словарь для типа документа

Слот типа документа требует фиксированного списка. Без него вы получаете отчёт, Отчёт, ОТЧЁТ, отч, отчт, сводка, сводный-отчёт и финальный-отчёт — все означающие одно и то же.

Начальный словарь:

бриф — начальные брифы проектов, творческие брифы
спецификация — технические или дизайнерские спецификации
договор — юридические соглашения, SOW, NDA
счёт — расчётные документы
предложение — коммерческие предложения и тендерные заявки
отчёт — периодические или разовые отчёты
презентация — слайды, все-руку встречи
дизайн — дизайн-активы и материалы
видео — сырые или финальные видеоматериалы
аудио — подкасты, закадровые голоса, исходное аудио
датасет — файлы данных CSV, Excel, JSON
заметка — заметки встречи, рабочие докладные
шаблон — многоразовые отправные точки

Держите список коротким. Если кто-то хочет добавить белая-книга, спросите — отличается ли это реально от отчёт. Дисциплина на уровне списка окупается с нарастающим эффектом.

Нумерация версий, которая действительно работает

v1, v2, v3 работает, пока не достигнете v10, которая сортируется перед v2. Используйте двузначные номера версий с самого начала: v01, v02, v03, ..., v10, v11.

Для длинных проектов, которые могут превысить 99 версий, начинайте с трёх цифр: v001.

Различайте основные версии и черновики:

v01 означает первую зафиксированную версию
v01.1, v01.2 означают незначительные черновики в рамках основной
Основная версия увеличивается при существенных изменениях, требующих нового просмотра

Не используйте семантическое версирование (v1.2.3) для деловых документов. Оно подходит для ПО и API, но не для договоров или презентаций.

Ловушка «финала»: никогда не используйте слово «финал» в имени файла. Это гарантирует появление финал, финал-финал, финал-финал-НАСТОЯЩИЙ и финал-используй-это. Используйте v02 для того, что вы имеете в виду под «финалом», и доверяйте нумерации версий.

Описания в kebab-case

Слот описания — единственная свободная часть. Держите его:

Строчными буквами
В kebab-case (слова разделяются дефисами)
Коротким: 2–5 слов
Достаточно конкретным для беглого просмотра: прогноз-выручки-q2 лучше, чем прогноз

основное-соглашение-об-услугах — хорошо. ОсновноеСоглашениеОбУслугах.pdf — плохо, потому что поиск без учёта регистра даёт непоследовательные результаты. основное соглашение об услугах — плохо, потому что пробелы в именах файлов ломают командные строки и кодирование URL.

Внедрение без полицейского государства

Нельзя вручную контролировать именование каждого файла в организации из 200 человек. Но можно:

Онбординг: 15 минут в первую неделю на соглашение об именовании с примерами
Шаблоны: предварительно названные файлы шаблонов в /Знания/Шаблоны/, чтобы люди начинали с правильной формы
Исправление во время проверок: при проверке работы переименовывайте неправильно названные файлы на месте с лёгким комментарием
Еженедельная чистка: 10 минут от ротирующегося владельца для исправления дрейфа
Автоматические боты переименования: для папок с высоким объёмом — скрипты, отслеживающие новые файлы и переименовывающие их на основе метаданных. Python + watchdog + os.rename — это полдня работы

Для репозиториев записей — договоры, счета, подписанные документы — рассмотрите более строгое применение: библиотеки документов SharePoint могут требовать поля метаданных перед сохранением. Метки Google Drive на Workspace Business Plus можно сделать обязательными для конкретных папок.

Расширения, специфичные для форматов

Расширение важнее, чем думают люди:

.pdf для финальных документов, которые не должны редактироваться
.docx и .xlsx для редактируемых файлов Office; избегайте .doc и .xls (устаревшие форматы с проблемами безопасности)
.pptx для презентаций; .key только если вы полностью на Mac
.md для технических заметок и внутренних вики — сортируется, имеет diff в Git, читается вечно
.csv для обмена данными; .xlsx для финального анализа с форматированием
.mp4 для видео с H.264 или H.265 кодированием; избегайте .mov, если только вам реально не нужен ProRes для монтажа
.psd, .ai, .indd для исходников Adobe; .fig для источников Figma

В случае сомнений выбирайте формат, который будет читаться через 10 лет без специализированного ПО. PDF и Markdown почти всегда выигрывают это пари.

Спецсимволы и ограничения длины

Определённые символы ломают файловые системы или облачные инструменты:

Избегайте: / \ : * ? " < > | — некоторые ломают Windows, некоторые macOS
Избегайте пробелов в именах файлов — они ломают командные строки, URL и некоторые инструменты
Избегайте не-ASCII символов, если ваша команда не работает последовательно на нескольких языках
Держите полные пути короче 255 символов — некоторые инструменты Windows по-прежнему падают за этим пределом

Миграция без разрыва истории

При принятии нового соглашения поверх существующего беспорядка не переименовывайте исторические файлы. Вы сломаете существующие ссылки, закладки и отсылки. Вместо этого:

Принимайте новое соглашение для всех новых файлов, начиная с конкретной даты
Переименовывайте только файлы, затрагиваемые в текущей работе
Позвольте архиву естественно устаревать в течение 2–3 лет

Полное ретроактивное переименование диска с 10 000 файлами — это 40-часовой проект, который обычно не стоит затрат. Дисциплина вперёд лучше, чем очистка назад.

Попробуйте HexaTransfer на https://hexatransfer.com — бесплатно, без регистрации, до 10 ГБ.