+  HandyCache форум
|-+  Главная категория» Общие вопросы» Алгоритм преобразования URL в имя файла в кэше
Имя пользователя:
Пароль:
Страниц: 1 ... 6 7 [8] 9 10 ... 13   Вниз
  Отправить эту тему    Печать  
Автор Тема: Алгоритм преобразования URL в имя файла в кэше  (Прочитано 234144 раз)
0 Пользователей и 1 Гость смотрят эту тему.
v0lt
Beta tester
*****

Репутация: +7/-0
Offline Offline

Сообщений: 127


« Ответ #140 : 29 марта 2007, 20:04:03 »

popkov
Цитировать
Гнилая отговорка!
вот часть кода получения урла из файла:
private string File2URL(string filename)
{
  string s = filename;
  int i;
//.................................
  if (s.IndexOf("`") >= 0)
  {
    s = s.ToLower();
    for (int j = 33; j < 65; j++)
      s = s.Replace('`'+ russian_chars[j], russian_chars[j-32]);
    s = s.Replace("`ё", "Ё");

    for (char j = 'a'; j <= 'z'; j++)
    {
      s = s.Replace('`' + j.ToString(), j.ToString().ToUpper());
    }
  }
  if (checkBox_unicode_rus.Checked) s = escape_unicode_rus(s);
  if (checkBox_Win1251.Checked) s = escape_Win1251_rus(s);

  return s;
}

если в имени файла появятся `` будет сложнее и медленнее...

по поводу опонентов ты прав, маловато...
тогда поступим так, что mai62 по поводу "(%22) скажет:
- не декодируем
- кодируем как #'
- кодируем как ``
то и сделаем (мне лично нравятся два первых варианта)

По поводу < (%3c) > (%3e) -> #{ #} или #( #) - аналогично

Цитировать
То есть можно и под и под FAT и под NTFS декодировать полный набор символов Юникода?
нельзя, на фате на каждый сивол выделяется 1 байт, поэтому если на русской винде ты нормально увидешь только кирилицу (кодировка где-то прописывается в настройках), на компе с другой локализацией теже файлы будут записаны каракулями

Сергей
Цитировать
можно даже добавить декодировку всех кодов национальных символов закодированных в UTF-8, но такое будет работать только на NTFS.
Ты проверял?
нет еще, но файлы с именами из японских иероглифов создаются Улыбка

popkov
Цитировать
Самовольное кодирование любых символов через знак #, таким образом, будет иногда приводить к потере и самого символа, и всего, что идёт после него.
Не стоит вообще самовольно кодировать через #. Символ # является служебным для HC. обычный пользователь не знает какие коды используются, какие появятся в будущем, такое использование символа # может привести к нарушению структуры кеша.
Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621



« Ответ #141 : 29 марта 2007, 20:15:09 »

Я не понял. Можно или нельзя? Если иероглифы сохраняются, значит можно?
Сообщить модератору   Записан
v0lt
Beta tester
*****

Репутация: +7/-0
Offline Offline

Сообщений: 127


« Ответ #142 : 29 марта 2007, 20:28:45 »

Цитата: Сергей
Я не понял. Можно или нельзя? Если иероглифы сохраняются, значит можно?
я произвольно переименовывал в тотале, работает, алгоритм еще не писал...

Поэтому остаются вопросы:
- есть ли символы (кроме первых 256) которые нельзя использовать в именах файлов
- где-нибудь описаны границы "виндового" уникода
- что будет если из %xx%xx или %xx%xx%xx (иероглифы) я получу символ которого нет или не знает винда
Сообщить модератору   Записан
v0lt
Beta tester
*****

Репутация: +7/-0
Offline Offline

Сообщений: 127


« Ответ #143 : 29 марта 2007, 20:39:09 »

нашел немного
http://ru.wikipedia.org/wiki/Символы,_представленные_в_Юникоде
попытаюсь разобраться... Поиск
Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621



« Ответ #144 : 29 марта 2007, 21:51:38 »

Windows знает все символы, т.к. она понимает юникод.
Проблемы возникают со старыми программами, которые его не понимают. Например, FAR.
HC к ним не относится Улыбка
Сообщить модератору   Записан
popkov
Beta tester
*****

Репутация: +3/-0
Offline Offline

Сообщений: 349


« Ответ #145 : 29 марта 2007, 22:24:44 »

вот часть кода получения урла из файла:
если в имени файла появятся `` будет сложнее и медленнее...
Да не такой уж громоздкий код, чёрт побери! Ничего сложного! уж наверное и с `` этот код будет работать отнюдь не медленнее, чем Чёрный список HC с сотней правил, среди которых встречаются и такие:
Цитировать
^([^/]+?\.)?([\w\-]+\.\w+)(:\d+)?/.*[^:]http(%3a|:)?(//|%2f%2f)([^/]+?\.)?(?!\2)([\w\-]+\.\w+)(:\d+)?[^\w\.]
Просто при обратном преобразовании надо вначале заменять все коды `` на %22 - и только потом обрабатывать прописные и строчные буквы! Никаких проблем я здесь не вижу - и об усложнении кода говорить просто смешно! Так что это была и в самом деле гнилая отговорка!

popkovНе стоит вообще самовольно кодировать через #. Символ # является служебным для HC. обычный пользователь не знает какие коды используются, какие появятся в будущем, такое использование символа # может привести к нарушению структуры кеша.
Ну я же не обычный пользователь...  Подмигивающий
А вот насчёт того, что обычный пользователь не знает, какие коды используются - это зря! Обычному пользователю, если только он хоть иногда заглядывает непосредственно в свой кэш - просто необходимо знать, какие коды там используются, чтобы понять, что к чему. Это должно стать общедоступной информацией, и присутствовать в документации.
Что скажешь об этом, DenZzz?

Кстати, v0lt, я очень надеюсь, что в алгоритме URL2File ты при кодировании заглавных букв не превращаешь их в строчные? Это была бы лишняя работа процессора, смысл которой - только сделать менее читабельным кэш!
« Последнее редактирование: 29 марта 2007, 22:38:51 от popkov » Сообщить модератору   Записан
popkov
Beta tester
*****

Репутация: +3/-0
Offline Offline

Сообщений: 349


« Ответ #146 : 29 марта 2007, 22:39:39 »

Кстати, обнаружил, похоже, 1 ошибку и 1 глюк в текущей реализации алгоритма URL2File.
Глюк очень простой: HC почему-то игнорирут переадресацию (файл #m), когда получает от браузера запрос. Вот пример:
Зайдите по ссылке:
http://www.goupsoft.com/ezsavemht
Если заходите в первый раз, то сервер переадресует на
http://www.goupsoft.com/ezsavemht/
и страница отобразится правильно.
Теперь, ключив, например Автономный режим (или режим Не обновлять ".*"), попробуйте зайти по первой ссылке снова - HC не переадресует, как это делал сервер, и перед вами откроется страница с неправильным URL http://www.goupsoft.com/ezsavemht на которой будет отсутствовать часть картинок!
А отсутствовать они будут потому, что внутри кода страницы ссылки на них оформлены так:
Цитировать
<img src="image/ez_save_mht_screenshot_1.gif" width="328" height="201">
И если в адресной строке URL правильный (то есть http://www.goupsoft.com/ezsavemht/), то результирующая ссылка будет такой:
http://www.goupsoft.com/ezsavemht/image/ez_save_mht_screenshot_1.gif
А если URL неправильный ( то есть http://www.goupsoft.com/ezsavemht), то ссылка получится такой:
http://www.goupsoft.com/image/ez_save_mht_screenshot_1.gif
Последняя ссылка никуда не ведёт, такого файла нет ни в кэше HC, ни на сервере!

Так вот, причиной этого глюка является то, что HC игнорирует лежащий в кэше файл
...\ezsavemht\#m
и вместо него сразу выдаёт файл
...\ezsavemht\#_
- и вэб-страница отображается неверно, поскольку относительные ссылки генерируются неверно, исходя из неверного URL.

Это был глюк. А теперь вопрос: а может быть сервер, у которого по адресам
http://www.goupsoft.com/ezsavemht/
и
http://www.goupsoft.com/ezsavemht
на самом деле лежат два разных файла? В этом случае HC, как я понимаю, будет оба этих URL писать в кэше в один и тот же файл - в файл
...\ezsavemht\#_
То есть возникает неоднозначность обратного декодирования. Если это так, то это - ошибка!
Сообщить модератору   Записан
v0lt
Beta tester
*****

Репутация: +7/-0
Offline Offline

Сообщений: 127


« Ответ #147 : 29 марта 2007, 23:15:30 »

popkov
Цитировать
Просто при обратном преобразовании надо вначале заменять все коды `` на %22 - и только потом обрабатывать прописные и строчные буквы!
принемается, отговорка была не очень... устал наверное...

Цитировать
Кстати, v0lt, я очень надеюсь, что в алгоритме URL2File ты при кодировании заглавных букв не превращаешь их в строчные?
Нет помеченные буквы регистр не изменяют.
PS: в функции FixURL временно стоит сброс имени хоста в нижний регистр - так браузеры делают потому как регистр в имени хоста ничего не значит. В конечном варианте хост можно не трогать, т.к. IE и Firefox это и без нас делают.

Цитировать
Так вот, причиной этого глюка является то, что HC игнорирует лежащий в кэше файл
...\ezsavemht\#m
и вместо него сразу выдаёт файл
...\ezsavemht\#_
- и вэб-страница отображается неверно, поскольку относительные ссылки генерируются неверно, исходя из неверного URL.
Есть такое, но это к функции записи кеша. Т.е. если мы создаем #_, то нужно удалить #m если таковой имеется, и наоборот.
+
Или к функции чтения кеша. Выдаем файл который позже создан.
+
Или вообще, можно выдать страницу с вопросом: "Есть два файла, один с чем-то, а другой ведет куда-то, вам какой?" Веселый

Цитировать
Это был глюк. А теперь вопрос: а может быть сервер, у которого по адресам
http://www.goupsoft.com/ezsavemht/
и
http://www.goupsoft.com/ezsavemht
на самом деле лежат два разных файла? В этом случае HC, как я понимаю, будет оба этих URL писать в кэше в один и тот же файл - в файл
...\ezsavemht\#_
То есть возникает неоднозначность обратного декодирования. Если это так, то это - ошибка!
Немного не так
../ezsavemht/ -> ..\ezsavemht\#_ - получалось пустое имя файла, добавили #_
../ezsavemht -> ..\ezsavemht  - файл без расширения
Проблема в том, что нельзя создать папку и файл с одинаковыми именами, но способ обхода глюка уж очень извращенный получается, радует что такое почти не встречается...

PS: вот тут когда-то все начиналось - http://forum.ru-board.com/topic.cgi?forum=31&topic=9261 Улыбка
« Последнее редактирование: 29 марта 2007, 23:32:54 от v0lt » Сообщить модератору   Записан
popkov
Beta tester
*****

Репутация: +3/-0
Offline Offline

Сообщений: 349


« Ответ #148 : 30 марта 2007, 00:41:23 »

Есть такое, но это к функции записи кеша. Т.е. если мы создаем #_, то нужно удалить #m если таковой имеется, и наоборот.
Похоже, ты и правда устал. Иногда и отдых нужен.
А вот #m удалять не нужно - как раз наоборот, его нужно искать в первую очередь, чтобы была хоть какая-то возможность быть переадресованным на нужный URL - иначе страница будет неправильно отображаться (см. мой детальный пример ). Это связано с относительными ссылками на картинки в коде страницы - такая относительность является обычным делом! Исключением скорее являются сайты, где ссылки в коде страницы абсолютные!
И поэтому наличие или отсутствие знака "/" в конце URL отображаемой страницы оказывается принципиальным моментом в том, откуда будет пытаться браузер загрузить картинки, содержащиеся в коде страницы.
А причина, почему это до сих пор не всплывало - редко бывают неправильные ссылки на страницу, в конце которых опущен символ "/". Однако именно неправильную ссылку я встретил на другой странице того же сайта, которая и привела меня к обнаружению сего глюка!
+
Или к функции чтения кеша. Выдаем файл который позже создан.
Надо просто в первую очередь выдавать файл с переадресацией - файл #m!
Цитировать
Проблема в том, что нельзя создать папку и файл с одинаковыми именами, но способ обхода глюка уж очень извращенный получается, радует что такое почти не встречается...
Неужели ничего нельзя придумать?

А как, кстати, будет вести себя HC если надо записать в кэш URL
http://www.goupsoft.com/ezsavemht/
а там уже записан URL
http://www.goupsoft.com/ezsavemht
(оказался записан раньше каким-то чудом - теоретически это возможно)
Что HC будет делать, если нужно создать папку ezsavemht, а уже есть файл с таким именем?

Проверил: HC переименовывает файл ezsavemht в ezsavemht#_, и далее создаёт папку ezsavemht. Интересно!
« Последнее редактирование: 30 марта 2007, 00:45:39 от popkov » Сообщить модератору   Записан
popkov
Beta tester
*****

Репутация: +3/-0
Offline Offline

Сообщений: 349


« Ответ #149 : 30 марта 2007, 00:56:32 »

И ещё один важный момент: HC ведёт себя по-разному, в зависимости от того, какой URL будет загружаться первым из этих двух (а какой - вторым):
URL1 http://www.goupsoft.com/ezsavemht
URL2 http://www.goupsoft.com/ezsavemht/
Если мы вначале загружаем URL1, HC создаёт вначале файл переадресации ezsavemht#m, затем создаёт папку ezsavemht, а в ней уже - файл #_
Если мы вначале загружаем URL2, а затем URL1, то HC создаёт вначале папку ezsavemht, в ней уже - файл #_, а затем в этой папке ещё создаёт файл #m (но только если не включён режим "Не обновлять .*").

К сожалению, в обоих случаях имеет место один и тот же глюк - HC не выдаёт файлы переадресации, и страница, открытая по ссылке http://www.goupsoft.com/ezsavemht - отображается и работает неправильно!
 Плачущий
« Последнее редактирование: 30 марта 2007, 01:01:42 от popkov » Сообщить модератору   Записан
popkov
Beta tester
*****

Репутация: +3/-0
Offline Offline

Сообщений: 349


« Ответ #150 : 30 марта 2007, 01:10:27 »

Проверил: HC переименовывает файл ezsavemht в ezsavemht#_, и далее создаёт папку ezsavemht. Интересно!
Проблема в том, что нельзя создать папку и файл с одинаковыми именами, но способ обхода глюка уж очень извращенный получается, радует что такое почти не встречается...
Выходит, автор HC уже и без нас наполовину решил описанную проблему - а мы даже и не догадывались!
mai62 Respect! 
И ничего "извращенского" в таком решении я не вижу - вполне логичное и простое решение!
« Последнее редактирование: 30 марта 2007, 01:16:50 от popkov » Сообщить модератору   Записан
popkov
Beta tester
*****

Репутация: +3/-0
Offline Offline

Сообщений: 349


« Ответ #151 : 30 марта 2007, 01:23:49 »

Думаю, по запросу
http://www.goupsoft.com/ezsavemht
HC должен искать в кэше файл ezsavemht, затем - файл ezsavemht#_. И если нет ни того, ни другого - должен сообщать, что нет такого файла в кэше, даже если там есть папка с именем ezsavemht! А при запросе в Интернет HC получит переадресацию на правильный URL:
http://www.goupsoft.com/ezsavemht/
- и тогда должен создать файл ezsavemht#m в корневом каталоге, а не в подкаталоге ezsavemht! А если вместо переадресации HC получит другой файл - то он должен создать файл ezsavemht#_! Вот и всё решение этого глюка! Подмигивающий
Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621



« Ответ #152 : 30 марта 2007, 01:48:13 »

Кто-то может и не догадывался. Подмигивающий А на руборде этот вопрос обсуждался точно.

Мне кажется запись файла редиректа в папку при запросе http://www.goupsoft.com/ezsavemht
является ошибкой. Даже если папка есть, надо записывать в файл ezsavemht#m а не в ezsavemht\#m

Эти тонкости тоже являются частью обсуждаемого алгоритма.
Сообщить модератору   Записан
popkov
Beta tester
*****

Репутация: +3/-0
Offline Offline

Сообщений: 349


« Ответ #153 : 30 марта 2007, 02:22:46 »

Кто-то может и не догадывался. Подмигивающий А на руборде этот вопрос обсуждался точно.
Ну я и v0lt - точно!
Мне кажется запись файла редиректа в папку при запросе http://www.goupsoft.com/ezsavemht
является ошибкой. Даже если папка есть, надо записывать в файл ezsavemht#m а не в ezsavemht\#m

Эти тонкости тоже являются частью обсуждаемого алгоритма.
Полностью согласен!
Сообщить модератору   Записан
DenZzz
Модератор
*****

Репутация: +179/-11
Offline Offline

Сообщений: 5589



« Ответ #154 : 30 марта 2007, 09:24:05 »

Надо просто в первую очередь выдавать файл с переадресацией - файл #m!

Это не выход! Файл #m может быть старым, а #_ - новым, тогда в автономном режиме будешь постоянно попадать на старую переадресацию!
Правильней действовать, как озвучил v0lt:

Цитировать
Т.е. если мы создаем #_, то нужно удалить #m если таковой имеется, и наоборот.
Сообщить модератору   Записан
Сергей
Beta tester
*****

Репутация: +9/-2
Offline Offline

Сообщений: 621



« Ответ #155 : 30 марта 2007, 10:10:46 »

Подведем черту:
1. Файл переадресации недопустимо записывать в подкаталог.
2. В одной папке не может находится одновременно индексный файл #_ и переадресация #m
Сообщить модератору   Записан
popkov
Beta tester
*****

Репутация: +3/-0
Offline Offline

Сообщений: 349


« Ответ #156 : 30 марта 2007, 13:36:26 »

Подведем черту:
1. Файл переадресации недопустимо записывать в подкаталог.
2. В одной папке не может находится одновременно индексный файл #_ и переадресация #m
Согласен с этим решением.
Теперь неплохо озвучить уже реализованный в текущей версии HC способ обхода ситуации с файлом и папкой, имеющими одинаковые имена. Сейчас HC при создании папки ведёт себя так:
HC переименовывает файл ezsavemht в ezsavemht#_, и далее создаёт папку ezsavemht.
Тем не менее, даже при наличии файла ezsavemht#_ HC по запросу
http://www.goupsoft.com/ezsavemht
лезет в ezsavemht/#_
а не выдаёт имеющийся файл ezsavemht#_
Это - ещё один глюк!

Вылечить его можно так: HC никогда не должен залезать в подкаталог большей вложенности, чем тот, который подразумевается в URL! Если вместо файла HC обнаружил в кэше поддиректорию, HC должен искать файл с суффиксом #_, не залезая в эту поддиректорию!

Насколько я понимаю (хотя глубоко не вникал в это), для файловой системы (во всяком случае, NTFS) файл и папка - одно и то же. Поэтому запрос о наличии какого-то пути (не оканчивающемся на "/") даст положительный результат, независимо от того, файл найден или папка. Но наверняка информация о том, что найдено, будет предоставлена файловой системой! Поэтому дальнейшие действия будут ясны:

Если найден файл - выдаём его
Если найдена папка - ищем (не залезая в неё!) файл с суффиксом #_ (в нашем случае это ezsavemht#_) и выдаём его
Если ни того, ни другого не найдено - выдаём сообщение, что файла нет в кэше!
« Последнее редактирование: 30 марта 2007, 14:22:05 от popkov » Сообщить модератору   Записан
Михаил
Gold beta tester
*****

Репутация: +337/-14
Offline Offline

Сообщений: 5513



« Ответ #157 : 31 марта 2007, 18:19:27 »

В результате работы алгоритма URL2File есть ли у нас и почему гарантия, что два URL с различным содержимым не отобразятся в кэше на один файл?
Сообщить модератору   Записан
Дем
Постоялец
***

Репутация: +6/-3
Offline Offline

Сообщений: 167



« Ответ #158 : 01 апреля 2007, 11:21:58 »

Цитировать
2. В одной папке не может находится одновременно индексный файл #_ и переадресация #m
На самом деле всё ещё интереснее. При входе например на ЖЖ происходит переадресация на некий файл, проводящий авторизацию и потом с него назад. И с нужными куками по тому же адресу происходит уже не переадресация, а выдача контента.
Т.е. в этом случае оптимальным было бы #m в кеш не писать вообще (но в браузер выдать)
Сообщить модератору   Записан
v0lt
Beta tester
*****

Репутация: +7/-0
Offline Offline

Сообщений: 127


« Ответ #159 : 01 апреля 2007, 11:49:02 »

Цитата: Дем
И с нужными куками по тому же адресу происходит уже не переадресация, а выдача контента.
Т.е. в этом случае оптимальным было бы #m в кеш не писать вообще (но в браузер выдать)
обычный файл будет новее редиректа, если HC будет проверять время (или удалять старый), то проблемы быть не должно.
(естественно такой урл не должен попадать в списки "Не обновлять" и "Только из кеша")

Цитата: Михаил
В результате работы алгоритма URL2File есть ли у нас и почему гарантия, что два URL с различным содержимым не отобразятся в кэше на один файл?
В новой версии гарантия будет (если не брать в счет "Преобразование URL" и косяки IE).

Цитата: popkov
HC никогда не должен залезать в подкаталог большей вложенности, чем тот, который подразумевается в URL!
Сам не проверял, но полагаю такое может быть для совместимостью с первыми версиями HC
« Последнее редактирование: 01 апреля 2007, 11:54:08 от v0lt » Сообщить модератору   Записан
Страниц: 1 ... 6 7 [8] 9 10 ... 13   Вверх
  Отправить эту тему    Печать  

 
Перейти в: