Почему «Файл10» раньше «Файл2»: естественная сортировка

«Файл10» оказывается раньше «Файл2», когда названия сравниваются как обычный текст без учёта числовых частей. Для ожидаемого порядка «Файл1, Файл2, Файл10» можно использовать Intl.Collator с numeric: true и выбранной локалью. Но сначала определите, что сортируется: названия, числовые значения или бизнес-справочник со своим порядком.

Одинаковый внешний симптом скрывает разные правила

Число в поле «Количество» и цифры внутри названия файла не нужно обрабатывать одним способом. В первом случае требуется числовое значение. Во втором остаётся строка, внутри которой человек ожидает понятного порядка числовых частей. Условие «привести всё к числу» не описывает, что делать с буквенной частью имени.

Есть и третий случай: справочник, где позиции намеренно расположены вручную. Если руководитель поставил «Этап10» перед «Этап2» по своему рабочему процессу, автоматическое исправление текста нарушит договорённость. Поэтому вопрос разработчику начинается с примера нужного порядка, а не с названия функции сортировки.

Что делает обычный sort

MDN описывает Array sort без функции сравнения как строковую сортировку по единицам UTF-16. Элементы предварительно сравниваются в строковом представлении. Поэтому и массив чисел без подходящего сравнения не обязан получить ожидаемый числовой порядок.

Для учебных значений 1, 10, 2 обычный sort оставил порядок 1, 10, 2, а числовое сравнение дало 1, 2, 10. Для подписей «Файл10, Файл2, Файл1» нужен уже другой смысл сравнения: сохранить название, учитывая цифры внутри него. Это не повод менять идентификатор записи или его тип хранения.

Настройка numeric относится к сравнению строк

В описании Intl.Collator параметр numeric включает числовой порядок частей; по умолчанию он выключен. Для сортировки выбирают соответствующее назначение сравнения и нужную локаль. Локаль стоит фиксировать явно, если продукт обещает один согласованный порядок.

Сравнение должно возвращать отрицательное значение, ноль или положительное в зависимости от отношения двух элементов. Не привязывайте собственную логику к обязательному точному числу −1 или 1. Если дополнительное правило запускается только при одном конкретном значении, часть результатов сравнения можно обработать неверно.

Таблица выбора по смыслу поля

Это собственная матрица требований, а не универсальный алгоритм для любых цифр. Первые примеры проверены небольшим скриптом в Node.js с ICU и локалью ru. Другие среды и настройки нужно проверять отдельно на согласованном наборе.

Равное сравнение не означает одинаковую запись

В проверенном учебном примере Collator с numeric: true сравнил «Файл2» и «Файл02» как равные. Это результат выбранного сравнения в конкретной среде, а не разрешение объединить файлы. Пользователь может намеренно хранить обе записи с разным содержимым или назначением.

Для воспроизводимого порядка при равенстве основного критерия задайте дополнительный: например, согласованное сравнение точного имени, затем устойчивый идентификатор. Выберите его явно и одинаково применяйте там, где нужен одинаковый список. Дополнительный порядок не должен становиться скрытой проверкой уникальности.

Почему нельзя одним компаратором разобрать версии и цены

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

В интернет-магазине цена должна оставаться числовым значением с согласованной денежной моделью, а артикул — идентификатором с собственным смыслом. Не извлекайте произвольное первое число из подписи и не объявляйте его ключом для всех товаров. Сначала определите тип конкретного столбца.

Как избежать разных списков в интерфейсе и экспорте

Если веб-приложение сортирует данные на сервере, а отдельный экран повторно сортирует их в браузере, сравните правила. Одинаковая надпись «По названию» не гарантирует одинаковую локаль, обработку цифр и дополнительный критерий. Пользователь увидит расхождение даже при исправной передаче всех записей.

Проверяйте общий набор до выдачи отдельных частей списка. Порядок только внутри загруженной страницы не подтверждает порядок всего результата. Для API-интеграции сохраните смысл сортировки в договоре и покажите партнёру конкретные контрольные значения вместо слова «естественная» без пояснений.

Набор приёмки для названий с цифрами

1. Соберите примеры реальных типов подписей без закрытых данных. Отделите числовые поля от названий и ручного бизнес-порядка.
2. Запишите ожидаемую последовательность для маленького учебного набора, включая имена с 1, 2 и 10.
3. Добавьте ведущие нули, различия регистра и значения, равные по основному сравнению. Согласуйте дополнительное правило.
4. Сверьте интерфейс, серверный ответ и экспорт на одних данных. Не принимайте один экран за подтверждение всех путей.
5. Проверьте, что сортировка не меняет идентификаторы, не удаляет равные по сравнению записи и не теряет пользовательский выбор.
6. После изменения runtime или правил повторите тот же набор. Зафиксируйте параметры сравнения вместе с ожидаемым результатом.

Если пользователь всё равно считает список неправильным, попросите показать соседние записи и желаемую последовательность. Возможно, он ожидает сортировку по дате, ручному приоритету или номеру другой сущности. Задача решена, когда порядок соответствует назначению списка, а не просто отличается от прежнего.