2009-11-24 9 views
1

У нас есть клиентское приложение C# .Net, которое отправляет некоторые команды через REST через HTTP. Сервер находится на машине Linux, написанной на Perl.C# Client - Perl server - Чувствительность к файлу - путь к файлу

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

Как мы можем получить правильный корпус?

У нас есть 2 возможных решения:

  • Используйте WinAPI вызов на клиенте, чтобы установить путь правильно обсаженных. (Эти файлы видимые в общей папке на компьютере клиентов)

  • Используйте некоторый PERL код на сервере, чтобы найти файл с регистронезависимым путем в качестве входных данных

Есть предложения? Мы хотели бы, чтобы это работало на всех клиентских машинах, которые являются Windows XP SP2 и выше.

ОБНОВЛЕНИЕ: Мы решили, что на стороне клиента должна быть установлена ​​фиксированная сторона, в редком случае есть несоответствие корпуса.

Мы запускаем это, если мы получим ошибку «файл не найден» в каталоге файла. Кто-то должен был бы изменить это, чтобы работать для файлов, а также, но в нашем случае имя файла не может быть неправильно (я бы предпочел не объяснять, почему):

 string FixDirectory(string fullpath) 
     { 
      return fullpath 
       .Split(Path.DirectorySeparatorChar) 
       .Skip(1) 
       .Select(path => 
        { 
         string[] split = fullpath.Split(new string[] { path }, StringSplitOptions.None); 
         string tempDir = split[0]; 
         string[] dirs = Directory.GetDirectories(tempDir, path); 
         fullpath = fullpath.Replace(Path.Combine(tempDir, path), dirs[0]); 
         return fullpath; 
        }) 
       .Last(); 
     } 
+0

Если кто-нибудь увидит какие-либо улучшения, которые могут быть сделаны с вышеуказанной функцией, дайте мне знать. – jonathanpeppers

ответ

2

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

Использование поиска по регистро-регистровому регистру на сервере, чувствительном к регистру, может быть только последним. Как вы упомянули в своем последующем комментарии, существуют различные краевые случаи, которые раздражают вас, поэтому было бы лучше всего избежать этого сценария.

+1

Мы заставляем клиента быстро найти каталог, чтобы устранить проблему, если есть редкое несоответствие корпуса, я опубликую на своем редактировании. – jonathanpeppers

1

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

+0

Но что, если на сервере есть файл с именем MyFile.txt, а также имена файлов myfile.txt. Как предотвратить перекрытие? – jonathanpeppers

+0

@Jonathan - вы можете совпадение на чувствительности к регистру сначала, а затем на нечувствительном к регистру совпадении, если первое не удается. Помимо этого, рассмотрите другую схему именования или структуру каталогов. –

+0

Да: Что делать, если сервер имеет MyFile.txt, myfile.txt и Myfile.txt и пользователь переходит в Myfile.txt. Серверу придется решить, что делать. Что вы хотите сделать? – McKay

1

Можете ли вы нормализовать случаи символов на своем сервере? Например, чтобы все имена каталогов и файлов были строчными.

Если это так, то ваш серверный процесс легко конвертирует запросы для My/FILE.XLS и my/file.XLS в my/file.xls.

Нормализация позволяет избежать сложной логики поиска и предотвращает столкновения между похожими именами файлов.