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

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

Сообщений: 349


« Ответ #160 : 01 апреля 2007, 21:50:52 »

Сам не проверял, но полагаю такое может быть для совместимостью с первыми версиями HC
В том-то и дело, что лезет! Я выше писал об этом:
Тем не менее, даже при наличии файла ezsavemht#_ HC по запросу
http://www.goupsoft.com/ezsavemht
лезет в ezsavemht/#_
а не выдаёт имеющийся файл ezsavemht#_
Это - ещё один глюк!
И предложил способ решения проблемы!
В результате работы алгоритма URL2File есть ли у нас и почему гарантия, что два URL с различным содержимым не отобразятся в кэше на один файл?
В новой версии гарантия будет (если не брать в счет "Преобразование URL" и косяки IE).
Гарантия будет, только если разберёмся с глюками!
В текущей реализации алгоритмя URL:
http://www.goupsoft.com/ezsavemht
http://www.goupsoft.com/ezsavemht/
отображаются в один и тот же файл
.../ezsavemht/#_
что не только не есть good, но противоречие всякой логике и явный глюк!
Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #161 : 01 апреля 2007, 23:06:57 »

Цитата: popkov
что не только не есть good, но противоречие всякой логике и явный глюк!
А я и не говорил что это правильно, просто когда в прошлый раз чуток менялось структура кеше у людей некоторые страницы в офлайне вообще не отображались, это "глюк" вроде как помогал...

вообщем это к mai62

PS: за нахождение фала вроде отвечает функция ExistsCacheFileNameDo
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #162 : 02 апреля 2007, 01:34:43 »

PS: за нахождение фала вроде отвечает функция ExistsCacheFileNameDo
Конечно, хотелось бы избежать лишних запросов к винчестеру. В идеале должно быть так: запрашиваем файл - получаем ответ, что файла нет, но есть папка. Тогда запрашиваем файл с суффиксом #_, не залезая в папку.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #163 : 03 апреля 2007, 00:09:28 »

volt
1. Если символы основной части кодирования представлены в URL в виде кодов %XX, то получим вместо ожидаемых вариантов декодирования следующие:
%2'F (%2f) вместо ожидаемого #!
%2'F%2'F (%2f/52f) - #!#!
%2'A (%2a) - #x
и т.д.
Кроме этого прочие представленные в URL кодами спецсимволы типа ~ @ $ ^ и т.п. также примут вид %X'X вместо ожидаемого %XX.
Думаю, так не задумывалось, и надо попробовать подкорректировать. Улыбка

2. Почему обрубаем длинный URL на ближайшем слэше, а не на "полуслове"? Поясни, плиз.
« Последнее редактирование: 03 апреля 2007, 00:14:44 от Михаил » Сообщить модератору   Записан
Сергей
Beta tester
*****

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

Сообщений: 621



« Ответ #164 : 03 апреля 2007, 10:10:32 »

Цитировать
Почему обрубаем длинный URL на ближайшем слэше, а не на "полуслове"?
Чтобы в разных папках кэша или у разных пользователей обрезанный файл назывался одинаково.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #165 : 03 апреля 2007, 17:48:54 »

volt
Кроме этого прочие представленные в URL кодами спецсимволы типа ~ @ $ ^ и т.п. также примут вид %X'X вместо ожидаемого %XX.
Поправлюсь: Кроме этого прочие представленные в URL кодами спецсимволы типа ~ @ $ ^ и т.п. также примут вид %X'X вместо ожидаемого их естественного вида (либо %XX в сдучае, когда символ запрещен в имени файла).
Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #166 : 03 апреля 2007, 19:52:57 »

Цитата: Михаил
Поправлюсь: Кроме этого прочие представленные в URL кодами спецсимволы типа ~ @ $ ^ и т.п. также примут вид %X'X вместо ожидаемого их естественного вида (либо %XX в сдучае, когда символ запрещен в имени файла).
Если ты хочешь сказать по глюк из-за пометки заглавных букв символом `, то да, такое имеется Грустный спасибо  Благодарю
теперь буду думать как его обойти (в текущей реализации это криво получается...)

PS: на этой неделе времени почти нет... , до дельфи доберусь только на следущей...
« Последнее редактирование: 03 апреля 2007, 20:05:41 от v0lt » Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #167 : 03 апреля 2007, 20:07:00 »

Если ты хочешь сказать по глюк из-за пометки заглавных букв символом `...
Да, про него. Хочу сказать также, что, может, надо пытаться декодировать не только буквы кириллицы, но и символы.
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #168 : 03 апреля 2007, 23:17:28 »

Юникод и win-1251 могут изображаться и маленькими буквами. Например, %cd, %e8 и т.п. Имхо, надо учесть (т.е. не учитывать регистр).
Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #169 : 03 апреля 2007, 23:26:23 »

Новая версия алгоритма:
измения v1.3 beta 2:
-добавлены варианты декодирования %22 ("), %3C (<) и %3E (>);
-обнаружен баг в пометке заглавных латинских букв силволом ` в кодах вида #XX. Решения пока нет (баг нашел Михаил)

Михаил
Цитировать
1. Если символы основной части кодирования представлены в URL в виде кодов %XX, то получим вместо ожидаемых вариантов декодирования следующие:
%2'F (%2f) вместо ожидаемого #!
...
по поводу ожидаемого #! и других подобных вещей
В урле многие символы можно записать как явно, так и через %XX (символы, которые должны записываться только через %XX, здесь уже разбирали). Например урлы site/page?-%2F и site/page?-/ - это разные урлы и на них могут прийти разные данные. И если символ был закодирован, но этого делать было необязательно, значит это кому-то было нужно...

Цитировать
Хочу сказать также, что, может, надо пытаться декодировать не только буквы кириллицы, но и символы.
с кирилицой проще её можно записать только через коды %XX
про символы с возможным двойным обозначением я выше написал...

Цитировать
Юникод и win-1251 могут изображаться и маленькими буквами. Например, %cd, %e8 и т.п. Имхо, надо учесть (т.е. не учитывать регистр).
Спасибо поправлю.
Но урл получаемый из имени файла получится в верхнем регистре. Сойдет?

* URL2filename_ver1_3beta2.zip (21.24 Кб - загружено 32 раз.)
Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #170 : 03 апреля 2007, 23:38:07 »

Например урлы site/page?-%2F и site/page?-/ - это разные урлы и на них могут прийти разные данные. И если символ был закодирован, но этого делать было необязательно, значит это кому-то было нужно...
Сам никогда не встречал таких (или просто не обращал внимания). Если не сложно, приведи пример, плиз.
В свою очередь, знаю, что в сети полно URL подобного, к примеру, рода:
site.ru/...?...&url=http%3A%2F%2F...%2F...
Или, скажем, в поисковике задан запрос с символами () или любыми другими специальными.
Цитировать
Но урл получаемый из имени файла получится в верхнем регистре. Сойдет?
1. Это должна понять процедура сравнения фиксенного исходного URL и URL, получаемого из имени файла.
2. Думаю, сойдет. Мне, по крайней мере, не йдет на ум пример, когда это может отрицательно повлиять Улыбка
« Последнее редактирование: 03 апреля 2007, 23:55:24 от Михаил » Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #171 : 04 апреля 2007, 01:36:02 »

При формировании исправленного URI должно, имхо, также  делаться следующее:
  - переводить коды в верхний регистр (о чем говорили выше);
  - коды %41-%5A, %61-%7A, %30-%39, %2D, %2E, %5F, %7E преобразовывать в соответствующие им символы;
  - http://site.ru:
    http://site.ru:/
    http://site.ru:80
    http://site.ru:80/
    приводить к виду site.ru/ (так же как сейчас приводится к этому виду http://site.ru).
По моему мнению, давно необходимо избавиться от опции "Удалять ссылку на порт 80 из имени файла в кэше" в Настройках/Кэш/Управление и удалять ссылку на порт 80 всегда.
Все эти варианты регламентируются в качестве тождественных URI.
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #172 : 04 апреля 2007, 01:43:36 »

В свою очередь, знаю, что в сети полно URL подобного, к примеру, рода:
site.ru/...?...&url=http%3A%2F%2F...%2F...
После длительного обсуждения решено было не декодировать код http%3A%2F%2F по двум причинам:
1) Декодирование слэша "/" может приводить к серьёзным глюкам в виде неоднозначности декодирования/кодирования (причём одновременно!) - и к тому же создаёт слишком много подпапок, что заведомо снизит эффективность работы с винчестером и скорость работы HC.
2) http:// представляют в виде http%3A%2F%2F не просто так! Обычно это имеет место, когда Referer или сайт, куда производится перенаправление нужно передать скрипту сайта в виде параметра. Причём синтаксис параметров скрипта подразумевает использование в качестве разделителей символов ;:/=& - и декодирование любого из них может привести к неправильной работе скрипта (а они в качестве разделителей, естественно, используются в незакодированном виде, так что мы не будем знать, был данный символ закодирован или нет, если будем всё подряд декодировать).
« Последнее редактирование: 04 апреля 2007, 02:08:12 от popkov » Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #173 : 04 апреля 2007, 01:57:33 »

При формировании исправленного URI должно, имхо, также  делаться следующее:
<....>
  - коды %41-%5A, %61-%7A, %30-%39, %2D, %2E, %5F, %7E преобразовывать в соответствующие им символы;
Оно верно, вопрос только возникает: зачем эти символы вообще кодируют? Кому это надо? Провёл небольшое исследование на эту тему.

Часто используют символы :;=&/ в качестве синтаксических в параметрах сайтовых скриптов.
Символы ~.-' к таковым не относятся, так что их декодирование безопасно.

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

Апостроф ' иногда используют в именах файлов, а также в поисковых запросах может использоваться. Правда, и то, и другое - редкость (у меня в логах нашлось только 2 небаннерных URL  с закодированным таким символом). Однако нет полной уверенности, что он никогда не используется как разделитель параметров скриптов. Хоть баннерная ссылка и не аргумент, но сомнения внушил такой URL:
http://counter.yadro.ru/hit?r'%20+%20escape(document.referrer)%20+%20((typeof(screen)=='undefined')?'':';s'+screen.width+'*'+screen.height+'*'+(screen.colorDepth?screen.colorDepth:screen.pixelDepth))%20+%20';'%20+%20Math.random()%20+%20'
Так что с апострофом спешить, наверное, не следует.

Короткое исследование логов на тему кодирования точки дало интересный результат! Оказывается, некоторы баннерные сайты кодируют её, чтобы обойти наши правила типа
banner.*\.gif
Это правило не сработает, если точка закодирована! И интересно, что все простые (нескриптовые) URL в моих логах с закодированной точкой оказались именно баннерными!
Как разделитель параметров скрипта она явно не может использоваться. Так что декодировать её следует всегда!

Дефис "-" редко кодируется - только в параметрах баннерных скриптов, да и то мало вхождений. Но для разделения параметров скрипта он не используется, так что его имеет смысл декодировать хотя бы для сокращения длины файла на диске - только польза!
« Последнее редактирование: 04 апреля 2007, 02:46:23 от popkov » Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #174 : 04 апреля 2007, 09:09:46 »

Цитировать
коды %41-%5A, %61-%7A, %30-%39
Оно верно, вопрос только возникает: зачем эти символы вообще кодируют? Кому это надо?
Кодируют. Это факт. Например, делают это в параметре &login=. Но не только, есть еще много примеров.
На мой взгляд, процедура FixURL должна выполняться сразу, до проверки любого списка, а не после "Преобразования URL". Тогда и наши правила супостатам обойти не удастся  Показывает язык
« Последнее редактирование: 04 апреля 2007, 09:14:12 от Михаил » Сообщить модератору   Записан
Михаил
Gold beta tester
*****

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

Сообщений: 5513



« Ответ #175 : 04 апреля 2007, 10:15:28 »

После длительного обсуждения решено было не декодировать код http%3A%2F%2F по двум причинам:
1) Декодирование слэша "/" может приводить к серьёзным глюкам в виде неоднозначности декодирования/кодирования (причём одновременно!) - и к тому же создаёт слишком много подпапок, что заведомо снизит эффективность работы с винчестером и скорость работы HC.
2) http:// представляют в виде http%3A%2F%2F не просто так! Обычно это имеет место, когда Referer или сайт, куда производится перенаправление нужно передать скрипту сайта в виде параметра. Причём синтаксис параметров скрипта подразумевает использование в качестве разделителей символов ;:/=& - и декодирование любого из них может привести к неправильной работе скрипта (а они в качестве разделителей, естественно, используются в незакодированном виде, так что мы не будем знать, был данный символ закодирован или нет, если будем всё подряд декодировать).
Пожалуй, логично. Удручает следующее. Заменяя спецсимволы на сочетания типа #x и др., хотим, чтоб пользователю не надо было запоминать коды (не беру пока слэш, у которого есть и другая функция - обозначить папку). С другой стороны, если эти символы изначально представлены в URL в виде кодов, мы их так и оставляем. Т.о., пользователю один хрен придется эти коды учить, только еще плюс к этому придется учить и введенные нами альтернативные обозначения.  :Улыбка Есть ли достойный выход?
Апостроф ' иногда используют в именах файлов, а также в поисковых запросах может использоваться. Правда, и то, и другое - редкость (у меня в логах нашлось только 2 небаннерных URL  с закодированным таким символом). Однако нет полной уверенности, что он никогда не используется как разделитель параметров скриптов. Хоть баннерная ссылка и не аргумент, но сомнения внушил такой URL:
http://counter.yadro.ru/hit?r'%20+%20escape(document.referrer)%20+%20((typeof(screen)=='undefined')?'':';s'+screen.width+'*'+screen.height+'*'+(screen.colorDepth?screen.colorDepth:screen.pixelDepth))%20+%20';'%20+%20Math.random()%20+%20'
Так что с апострофом спешить, наверное, не следует.
В приведенном примере апостроф используется для обозначения строки, не в качестве разделителя параметров скрипта. Он, как и ~.- относится к т.н. незарезервированным в стандарте URI. И при его раскодировании всегда получим URL, эквивалентный исходному.
« Последнее редактирование: 04 апреля 2007, 11:11:51 от Михаил » Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #176 : 04 апреля 2007, 15:56:54 »

В приведенном примере апостроф используется для обозначения строки, не в качестве разделителя параметров скрипта. Он, как и ~.- относится к т.н. незарезервированным в стандарте URI. И при его раскодировании всегда получим URL, эквивалентный исходному.
Все символы из списка :;=&/ относятся к зарезервированым?
С другой стороны, если эти символы изначально представлены в URL в виде кодов, мы их так и оставляем. Т.о., пользователю один хрен придется эти коды учить, только еще плюс к этому придется учить и введенные нами альтернативные обозначения.  :Улыбка Есть ли достойный выход?
Кодируем кодами #x только те символы, которые не могут быть использованы непосредственно в именах файлов! Причём если символы "<> в URL представлены в закодированном виде, мне кажется, следует их раскодировать - они заведомо не должны присутствовать в URL в явном виде (поэтому неоднозначности декодирования не возникает) - и при этом не могут присутствовать в именах файлов. Поэтому их тоже следует всегда декодировать, но записывать в кэш в виде кодов ``, #{ и #} соответственно (эти коды интуитивно понятны и легко запоминаются - внешне они схожи с исходными символами). Так что в данном случае запоминать придётся только эти простые коды! Кстати, ты согласен, что они понятнее и проще, чем соотв. #', #( и #) - у нас с V0lt был длинный спор - стоит ли их декодировать и в каком виде.

А вот что касается символов *|\ - не уверен, что их имеет смысл декодировать. Насколько я понимаю, синтаксической информации они не несут, да и в виде кодов они вряд ли будут вполне прозрачны. Так что их можно не трогать (если они закодированы). Хотя при большом желании символ * можно кодировать как #x, если он был закодирован в URL и как #X - если не был!.. Да и другие символы тоже! Вообще, все удобства и красивости можно реализовать, лишь бы мы были единогласны! По-моему, для этого мы здесь и собрались, в конце концов! Жаль, что немного нас пока... но всё впереди!

Символы / и ? мы решили не декодировать во избежание глюков.
« Последнее редактирование: 04 апреля 2007, 16:38:39 от popkov » Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #177 : 04 апреля 2007, 16:13:31 »

Если ты хочешь сказать по глюк из-за пометки заглавных букв символом `, то да, такое имеется Грустный спасибо  Благодарю
теперь буду думать как его обойти (в текущей реализации это криво получается...)

PS: на этой неделе времени почти нет... , до дельфи доберусь только на следущей...
Самое тупое решение этого бага - и не требующее каких-то сложных ухищрений - перед обработкой прописных и строчных букв перевести все последовательности (правило записал в RegExp, регистр имеет значение - так что в соотв. функции это надо указать)
%[A-F\d]{2}
в нижний регистр! Тогда проблема отпадает сама собой.
Но при этом эти коды станут менее читабельны - записанные заглавными буквами, они воспринимаются намного лучше! Так что можно их перевести обратно в верхний регистр после обработки прописных/строчных букв!
« Последнее редактирование: 04 апреля 2007, 17:02:07 от popkov » Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #178 : 04 апреля 2007, 16:57:37 »

На мой взгляд, процедура FixURL должна выполняться сразу, до проверки любого списка, а не после "Преобразования URL". Тогда и наши правила супостатам обойти не удастся  Показывает язык
Интересная мысль! Однако требует тщательного анализа на предмет возникновения ситуаций, когда 2 разных URL окажутся в итоге одинаковыми! Этого необходимо избежать со 100%-ной гарантией, тогда эту функцию и правда лучше будет поместить до всех списков!

А пока у меня в Переадресации есть 2 правила:
Цитировать
#5#~#True#~#%25(?=[a-f\d]{2})#~#%#~#True#~#True
#5#~#True#~#%2e#~#.#~#True#~#True
Первое из них позволяет избежать повторного кодирования символа %, используемого при кодировании символов (часто встречаются URL с двойным кодированием, например символ ` оказывается записан как %2560, а не как %60 - бесполезное удлинение URL, на мой взгляд - и невозможность в некоторых случаях "отловить" баннерные ссылки). Делается проверка, что в данном случае речь идёт именно о повторном кодировании, а не просто о закодированном символе %, декодирование которого иногда может оказаться нежелательным (насколько я понимаю - хотя хотелось бы выяснить это точнее).
Кстати, кто-нибудь знает, есть ли какие-либо стандарты на повторное кодирование символов в URL? На каком этапе какие символы кодируются? Насколько я понимаю, бывает и 3 и 4 перекодирования - но символ % в кодах символов кодируется именно при втором кодировании, и кодов %252525 в логах не встречается, хотя %2525 - обычное дело!
Второе я написал недавно - это фикс кодированной точки!
« Последнее редактирование: 04 апреля 2007, 17:19:40 от popkov » Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #179 : 04 апреля 2007, 21:18:19 »

popkov
Цитировать
Самое тупое решение этого бага - и не требующее каких-то сложных ухищрений - перед  обработкой прописных и строчных букв перевести все последовательности (правило записал в RegExp, регистр имеет значение - так что в соотв. функции это надо указать)
%[A-F\d]{2}
в нижний регистр! Тогда проблема отпадает сама собой.
Ну дык, только у меня пока нелады с регулярными выражениями в C#. Мутно как-то все реализовано, замена непонятно как работает...

А в Дельфи я вообще не нашел стандартной библиотеки по регулярным выражениям Грустный
Спрошу у mai62...
Сообщить модератору   Записан
Страниц: 1 ... 7 8 [9] 10 11 ... 13   Вверх
  Отправить эту тему    Печать  

 
Перейти в: