Сравнение имен файлов Win32

Кто-нибудь знает, какие настройки культуры используются Win32 при работе с именами имен без учета регистра?

Это что-то, что зависит от культуры пользователя, или правила оболочки, которые Win32 использует инвариант культуры?

Ответ 1

Примерный ответ на Правильное совмещение имен файлов Unicode.

В принципе, рекомендация состоит в том, чтобы заглавные обе строки (используя CharUpper, CharUpperBuff или LCMapString), затем сравните с помощью двоичного сравнения (например, memcmp или wmemcmp, а не CompareString с инвариантной локалью). Файловая система не выполняет нормализацию Unicode, и правила case не зависят от настроек локали.

Есть несчастные двусмысленные случаи, когда вы имеете дело с символами, правила корпуса которых изменились в разных версиях Unicode, но это так же хорошо, как вы можете.

Ответ 2

Сравнение имен файлов в собственном коде и Не сравнивать filenames - это пара хороших сообщений в блоге по этой теме. Первый имеет код C/С++ для OrdinalIgnoreCaseCompareStrings, а второй сообщает вам, как это не всегда работает для имен файлов и что делать, чтобы уменьшить это.

Тогда есть проблемы Unicode. Хотя эти новые алгоритмы сравнения строк OrdinalIgnoreCase отлично подходят для вашего локального диска NTFS, они могут не дать правильный ответ на вашем диске FAT или сетевом ресурсе.

Так какой ответ? Когда это возможно, сообщите файловой системе. CreateFile может сказать вам, существует ли данное имя файла. Просто выберите правильное расположение. Если вам нужно сравнить с ручками, вы можете часто использовать GetFileInformationByHandle; посмотрите dwVolumeSerialNumber/nFileIndexHigh/nFileIndexLow.

Ответ 3

Если вы используете .NET, официальная рекомендация Microsoft заключается в использовании StringComparison.OrdinalIgnoreCase для сравнения и ToUpperInvariant для нормализации (для более позднего сравнения с использованием сравнения Ordinal). Это также относится к ключам и значениям реестра, переменным среды и т.д.

Подробнее см. Новые рекомендации по использованию строк в Microsoft.NET 2.0.

Обратите внимание, что, хотя он надежный в NTFS, он может завершиться неудачей с использованием сетевых ресурсов, например. См. Ответ @SteveSteiner и ссылки в его сообщении для решений.