Программа обработки файлов: как проверить имена выгрузки для Windows

Программа выгружает документы из кабинета в папки на компьютере. В исходной системе есть Report.pdf и report.PDF, документ с именем CON.txt и запись archive, рядом с которой нужно создать archive/scan.pdf. До выгрузки всё выглядит как обычный список строк. При записи возникают разные проблемы: совпадение имён, особое имя устройства и конфликт файла с каталогом. Разработка обработки файлов должна учитывать их до первой операции сохранения.

Сохраните связь документа с будущим путём

Начните не с массового переименования, а с манифеста: идентификатор исходного документа и предполагаемый относительный путь внутри одной выгрузки. Это позволяет проверить весь набор, показать спорные записи и согласовать исправления. Идентификатор должен сохраняться, даже если имя или папка изменятся; иначе после замены названий будет трудно объяснить, какой документ куда попал.

Манифест описывает целевую структуру, а не расположение файлов на сервере. Абсолютные пути, ссылки на родительский каталог и специальные префиксы в нашем учебном формате не принимаются. Это ограничение выбранной схемы экспорта, а не утверждение, что Windows вообще не поддерживает такие обозначения.

Проверяйте компоненты, а не только расширение

В документации Microsoft описаны зарезервированные символы и имена, включая CON, PRN, AUX, NUL, COM1–COM9 и LPT1–LPT9. Добавление расширения не превращает NUL.txt в обычное безопасное имя. Указанные правила относятся и к каталогам. Для обычного пользовательского сценария также нужно учитывать завершающие пробелы и точки.

Форма ниже проверяет этот перечисленный набор, надстрочные варианты цифр ¹, ², ³ для COM и LPT и запрещённые ею символы. Полного анализатора всех пространств имён Windows здесь нет. Точка или двоеточие в другой позиции не должны исправляться случайной заменой: точка может быть частью допустимого имени, а двоеточие в нашем формате запрещено.

Повторный прогон после исправления: разбор двух документов

Имя стало допустимым, но совпало с другим — что покажет проверка?

Возьмём отдельный вымышленный фрагмент: E с путём docs/CON.txt и J с путём docs/CON-2.txt. Сначала у E отмечается зарезервированное имя. Если предложить для E уже занятое docs/CON-2.txt, ошибка компонента исчезнет, но документы начнут претендовать на один путь. Число локальных ошибок уменьшилось, а задача выгрузки не решена.

Три проверки одного фрагмента; реальные файлы не меняются

Прогон	Путь E	Путь J	Наблюдение модели
Исходный	docs/CON.txt	docs/CON-2.txt	Одна строка с ошибкой имени
Неудачная замена	docs/CON-2.txt	docs/CON-2.txt	Локальных ошибок нет, коллизия E и J
Новый вариант для проверки	docs/doc_E.txt	docs/CON-2.txt	В этом фрагменте перечисленных проблем нет; полная совместимость всё ещё не подтверждается

Идентификаторы E и J сохраняются во всех прогонах. Калькулятор сам не предлагает эти имена и не изменяет файлы: подставьте варианты в копию манифеста и сравните отчёты. Отсутствие коллизии между двумя строками не снимает замечания к остальной выгрузке.

Не выбирайте политику «последний файл побеждает» без явного требования. Если программа добавляет ID к имени, определите формат и проверьте устойчивость при повторной выгрузке. Сохраните исходный путь, согласованный вариант и причину изменения — тогда результат можно сверить без догадок.

Почему совпадение регистра требует отдельной модели

Microsoft предупреждает, что чувствительность к регистру нельзя предполагать по умолчанию. При этом настройки и файловые системы различаются. В учебной проверке латинские ASCII-буквы A–Z приводятся к a–z только для сравнения; сами предложенные имена не переписываются.

Это не полная таблица сравнения Unicode, не нормализация имён и не воспроизведение поведения конкретного тома NTFS. Путь с кириллицей, диакритикой или другими не-ASCII символами получает отметку о ручной проверке. Такие символы сами по себе не запрещены. Нельзя ни молча признать все эти пути различными, ни обещать, что один вызов lowerCase точно моделирует целевую систему.

Проверьте длину в реальном месте выгрузки

Короткий относительный путь может стать длинным после добавления корневой папки. В документации Microsoft по длинным путям описаны условия поддержки со стороны Windows и приложения, включая longPathAware для соответствующего сценария. Одного общего утверждения «Windows поддерживает длинные имена» недостаточно для проверки конкретной программы.

Форма показывает длину строки в кодовых единицах UTF-16 и отдельно отмечает длинные относительные пути и компоненты для проверки. Она не знает абсолютного корня, выбранного API, упаковщика архива, настроек системы или файловой системы. Отсутствие замечаний не является подтверждением полной совместимости выгрузки.

Что включить в приёмку разработки

1. Два исходных документа с именами, отличающимися только ASCII-регистром.
2. Файл, имя которого требуется также как каталог для другого файла.
3. Зарезервированное имя с расширением и пробел или точку в конце компонента.
4. Кириллические имена, длинный целевой корень и повторный запуск выгрузки.

Добавьте правило остановки и отчёт по необработанным документам. Пользователь должен видеть, что сохранено, что требует решения и как результат связан с исходными ID. Испытания выполняйте в отдельной тестовой папке на нужных версиях среды, а не на единственной рабочей копии документов.

Для заказа программы обработки документов полезно передать небольшой обезличенный манифест вместе с ожидаемой структурой папок. Он дополняет требования к распознаванию, шаблонам имён и пакетным операциям. Учебный инструмент помогает обсудить часть этих правил, но не проверяет содержимое документов, целостность архива, права доступа или поведение готовой программы.