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

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

PS: за нахождение фала вроде отвечает функция ExistsCacheFileNameDo

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

2. Почему обрубаем длинный URL на ближайшем слэше, а не на "полуслове"? Поясни, плиз.

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

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

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

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

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

Спасибо поправлю.
Но урл получаемый из имени файла получится в верхнем регистре. Сойдет?

При формировании исправленного 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.

Оно верно, вопрос только возникает: зачем эти символы вообще кодируют? Кому это надо? Провёл небольшое исследование на эту тему.

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

Кроме того, на серверах бесплатного хостинга часто используют символ ~ вначале названия папки конкретного пользователя. И в этих случаях декодирование его просто необходимо, даже просто для того, чтобы не создавать две папки в кэше - одну с закодированным символом ~, другую с декодированным (поскольку в 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 в моих логах с закодированной точкой оказались именно баннерными!
Как разделитель параметров скрипта она явно не может использоваться. Так что декодировать её следует всегда!

Дефис "-" редко кодируется - только в параметрах баннерных скриптов, да и то мало вхождений. Но для разделения параметров скрипта он не используется, так что его имеет смысл декодировать хотя бы для сокращения длины файла на диске - только польза!

Пожалуй, логично. Удручает следующее. Заменяя спецсимволы на сочетания типа #x и др., хотим, чтоб пользователю не надо было запоминать коды (не беру пока слэш, у которого есть и другая функция - обозначить папку). С другой стороны, если эти символы изначально представлены в URL в виде кодов, мы их так и оставляем. Т.о., пользователю один хрен придется эти коды учить, только еще плюс к этому придется учить и введенные нами альтернативные обозначения.  : Есть ли достойный выход?
В приведенном примере апостроф используется для обозначения строки, не в качестве разделителя параметров скрипта. Он, как и ~.- относится к т.н. незарезервированным в стандарте URI. И при его раскодировании всегда получим URL, эквивалентный исходному.

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

popkov
Ну дык, только у меня пока нелады с регулярными выражениями в C#. Мутно как-то все реализовано, замена непонятно как работает...

А в Дельфи я вообще не нашел стандартной библиотеки по регулярным выражениям
Спрошу у mai62...