HandyCache форум

В документации не хватает подробного описания алгоритма преобразования URL2File.
Со всеми ньюансами, типа работы с дополнительными папками кэша.

Ну вот что экспериментально нашёл:

:     !
/     #%
//    #%~
\     #~
|     #i
*     #x
?     #^

DenZzz


Не соглашусь. Способ хранения кэша ключевой момент программы отличающий ее от конкурентов.

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

Как говорится :)

Сергей


К сожалению, не владею полной информацией по этому вопросу...
Если кто может точно описать этот алгоритм словами - давайте.
Помнится, V0lt с ру-борда разбирался в коде и даже конвертор кэша написал...

Сергей
Смотри вложение

Сергей (aka Сергей Кузнецов, ака COUSIN)

Цитата из ToDo: (http://handycache.ru/component/option,com_smf/Itemid,10/topic,20.0/)

Судя по URLToCache.pas, это предложение уже реализовано!  ;)  ! заменяется на #I

Как мы уже заметили в смежной теме (http://handycache.ru/component/option,com_smf/Itemid,10/topic,69.0/), в действующем алгоритме символы: " < > - никак не преобразуются в имя файла, т.е. файл на диске просто не создается! Хорошо бы это поправить.
Еще надо решить, на что их заменять...  ;)

А кто помнит, почему некоторые "небезопасные" символы было решено заменять не на их код %хх , а на комбинацию: #y  ?

Кусок из моего...

Но конечно выбор символа - дело автора.
Мне больше нравится § (критерий выбора - почти не встречается в урл, а также одинаково выглядит в  ANSI и OEM)

Хм. А нельзя ли вынести правило преобразования "URL - имя файла в кеше" в файл настроек?

Я уже предлагал такое.
Алгоритм слишком сложный, чтобы его через файл настроек описать.
И медленно будет работать тогда.

2 Сергей
Немного странно. Собственно список "Преобразование URL" можно заставить делать практически то же самое.

Там не просто замена в URL некоторых символов.
Еще много других операций. Без обращения к диску никак не обойтись.
Например может оказаться что имя файла совпадает с именем каталога.
Еще есть две папки кэша, переадресация, докачка ....

Для получения относительного пути файла в кеше регулярные выражения вполне подойдут.
Ну а разрешение коллизий конечно лучше всего программное.

Кирилл
И будет полная анархия, несовместимость кэшей и куча вопросов почему у меня что-то не кэшируется.

2 mai62
Ну для полной анархии при кривых руках и текущих настроек хватит ;)
Собственно список "Преобразование URL" обладает тем же ресурсом для "Cache hell"

popkov
Однобайтовые коды неоднозначны. Одной и той же букве могут соответствовать разные коды, в зависимости от того, какую кодовою таблицу мы подразумеваем Win, koi-8, dos ...
Юникод решает эту проблему. Двухбайтовые коды, в данном случае, это UTF-8

Вот цитата с http://ru.wikipedia.org/wiki/Юникод

Но всё равно непонятно - почему тогда сервер вернул двухбайтовый код, запросто сделав его из однобайтового? Он воспользовался информацией о языке вэб-страницы для этого?

По моему решение так и не было принято. Это личная инициатива автора.
Мне больше нравится вариант %xx для таких символов.

Сервер увидел неправильные коды и попытался восстановить их, предположив, что это WIN.

Вот я наконец-то на этом форуме :)

кхм, оно конечно более совместимо, но больше нравился вариант когда ! не трогается, а меняется ":" на "#I"

для надежности и упрошения. в разных частях урла можно использовать разные комбинации символов. Например после "?" не обязательно кодировать символы запрешенные в host или path. К тому же в урле после "?" можно либо все закодировать, либо то что необходимо, и по сути получив два разных урла...

двойные кавычки и <> в урле не могут исползоваться поэтому они кодируются браузером (%22 %3C %3E) и следовательно HC такие урлы нормально сохранит (можете проверить)

Тот что длинный %xx%xx, это как я понял UTF-16. Причем первый %xx должен быть больше %7F иначе будет распознан как ASCII символ.
Запрещеные символы ASCII (первые 128) кодируся как %xx, где xx - 16-ричный номер символа.

Короткий способ - это глюк (?) Firefox. Там вообще хх - это номер в cp1251. Я могу лишь предположить, что сервер wiki самостоятельно переводит к нормальному виду:
- браузер сообщяет желаемую кодировку и сервер это учитывает (очень сомнительно);
- сайт на русском, и урлы как правило на русском, следовательно програмисты движка сайта режили облегчить жизнь обычным пользователям

Ну это надо для всех браузеров ещё проверить... мало ли, какой криворукий вэб-"мастер" создаст скрипт, генерирующий URL с такими символами, и какой-нибудь FireFox или Opera в этой ситуации "забудут" его закодировать.
А главное, что, даже если такие символы всегда будут закодированы браузером, надо всё же принять решение, в каком виде их сохранять на диск - ведь мы хотим сделать кэш читабельным, а "%22", "%3C" и "%3E" не очень-то приятны для глаз... Нужно придумать систему кодирования, которая будет максимально интуитивно понятна, и не будет требовать разучивания большого числа кодов.

Задачу именно так и надо ставить - придумать, как максимально прозрачным образом закодировать все те символы, которые в кэш непосредственно записаны быть не могут.

Символов таких не так уж много: это символы \/|:*?"<>

И отдельно следует закодировать две их чрезвычайно часто встречающиеся комбинации:
"://" и "//" (внутри кавычек).
Что касается отдельного символа "/", то я сильно сомневаюсь, что его стоит вообще кодировать - проще создать подпапку.
А сомвол "\" можно кодировать как последовательность "#/", т.е. имя папки заканчивается на "#" (а остальная часть URL пишется в эту папку как файл - или как папка, если дальше также есть один из символов \ или /).
Символ "|" я предлагаю кодировать тремя символами: "#!/". То есть именем папки, заканчивающимя на "#!". Мне кажется, такой способ кодирования символов \/ и |, основанный на очевидном родстве между ними тремя и знаком "!" (все они - чёрточки: наклонные и вертикальная) наиболее легко по имени файла в кэше позволяет догадаться, каков был изначальный URL. Причём такое преобразование однозначно - ведь символ "#" не может встретиться в URL в чистом виде вовсе (уж он-то точно будет отброшен браузером, в соответствии со спецификацией URL!).
Соответственно, теперь возникает вопрос: если в URL есть закодированный в виде "%23" символ "#", как его записать в кэше, чтобы не возникло неоднозначности в интерпретации вышеописанных кодовых последовательностей (в смысле, если оставить как "#", то случайно за ним может оказаться симовол "!" или "/", и тогда обратное преобразование (которое нужно, например, hc.historian) будет неоднозначно)? Здесь мне как наиболее очевидное приходит в готову только удвоение этого символа: запись каждого "#" в кэш в виде "##". Думаю, это не слишком затруднит чтение кэша, и при этом - прозрачнее некуда!
Что касается одиночного символа двоеточия ":", то для полной однозначности мне представляется логичной запись "#=". Равно и двоеточие имеют некое интуитивное (и лингвистическое) родство. Кроме того, сочетание "#=" некоторым будет напоминать ":=" (оператор присваивания в Pascal). Конечно, это субъективно - но как сделать прозрачнее?
Знако вопроса уже вполне прозрачно кодируется "#^".
Звёздочку можно по-прежнему кодировать как "#x". Это не супер-прозрачно, поскольку букву интуитивно хочется произнести про себя, а не связывать с предшествующим служебным символом, но намного лучшее решение мне тоже придумать непросто. В качестве альтернативы могу предложить "#&". Два служебных символа легче связать друг с другом, чем букву со служебным символом - ведь при чтении текста все небуквенные символы воспринимаются как скобки!
Двойные кавычки можно кодировать как "#''" - три символа, но зато очень ясно.
А символы больше-меньше - как предложил Дем: больше - "#)", меньше - "#(". Надо запомнить только сходство между ">" и ")" и между "<" и "(".
Осталось ещё придумать, как кодировать два слэша: "//".

Но, к сожалению, так работают не все браузеры!

Попробуй для примера в IE (Макстоне) загрузить URL вида h++p://www.yandex.ru/yandsearch?text="привет"  - он передается на сервер в неизменном виде и успешно грузится, а вот в кэш не идет, т.к. баг не дает! Проверь сам...  ;)

Юникод бывает разный UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE.
В URL принято использовать первый вариант, в силу обратной совместимости с ASCII

Так уже было раньше! Потом было решено "/", идущий после знака "?", кодировать сочетанием "#%".
Как сказал, mai62: "вложенных каталогов стало меньше, а это экономия ресурсов и времени на сохранение таких файлов"!
Не вижу оснований теперь менять все назад...

Тоже касается и символов "\" и "|" - создавать лишнюю папку "не экономно"... ;)

И вообще, я думаю, что не стоит сейчас менять коды замены тех спецсимволов, которые уже кодируются HC, т.к.:

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

а-а-а, для кого стандарты написаны :( не выполняют через одного

"Читабельность/Прозрачность" может сильно усложнить алгоритм. Декодировать кирилицу imho стоит, остальное надо посмотреть (тут выгоды НЕочевидны)

imho не стоит :) без этого уже много заморочек

дальше ты пишешь вещи, от которых мы с mai62 пытались уйти, если соберусь с мыслями попробую растолковать, почему некоторые вещи сделаны так, а не иначе

Тут я с тобой солидарен, кодировать ":" надо :)

Три это много, больше проверок - скорость упадет. Я даже за правило себе взял: "#x" - служебный символ, где x - код.

сейчас до знака "?" (до query (параметров) см. RFC 2068) имеем:
/ -> \
после знака "?" получается:
/ -> #%

Я предлагаю обединить эти два правила и в результате получается:
до знака "?":
// -> \#%
после знака "?":
// -> #%#%

для 3 и более получим соответственно
/// -> \#%#%
/// -> #%#%#%

Основной критерий, которого я придерживался - это однозначность преобразований.

Чтобы как то направить процесс, предлагаю следующий план работ, связанных с изменениями формата кеша:

1. Доработка преобразования URL<->filename (убираем глюки, добавляем кирилицу)
2. Доработка преобразования длинных URL (об этом позже)
3. Добавление в алгоритм сортировки (думаю юзеры уже созрели, но об этом позже)
4. Написание алгоритма и проверка его на различных урлах
5. Написание конвектора кеша (я могу этим занятся)
6. Написание новой версии НandyCache (это к mai62)

Пункты 1..4 естественно придется согласовывать с mai62 ;)

сегодня вечером напишу ситуацию по первому пункту

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

Сергей
Сделать можно, только есть одна заковырка. Создали мы некое правило, ввели в его конвертер, преобразовали кеш. Упс! Правило неправильное, хотим другое или просто хочется его отключить. А уже всё, поезд уехал. В обратную сторону конвертер не сработает. Даже если специально написать еще одно правило, данных может не хватить...

Преобразования URL<->filename

Cейчас имеется:

символ	до "?"	после "?"
/	\	#%
//	\~	#%~
*	#x
\	#~
|	#i
!	#I
:	!
?	^\	#^
редирект и решение проблем
редирект	редирект#m
путь\	путь\#_

Сильно удивило ! -> #I, которое по сути идентично | -> #i. Многие I/O-функции не различают регистр, будут разночтения.

Возможный вариант:

символ	до "?"	после "?"
/	\	#%
//	\#%	#%#%
*	#x
\	#~
|	#i
!	!
:	#!
?	^\	#^
лечим глюки
"	%22
<	%3C
>	%3E
редирект и решение проблем
.\	.#n\
редирект	редирект#m
путь\	путь\#_
путь\.	путь\.#_
красивости
%D1%8F	я

.\ -> .#n\ и путь\. -> путь\.#_ нужны чтобы можно было создать адекватные файлы и папки, если в конце имени получается точка.

По поводу ? -> ^\ . Вариант вполне нормальный и работает вроде как без проблем, но DenZzz показал на пофигизм IE (хотя по поводу символа "^" сказать, что прав Firefox тоже не могу, инфы нет), поэтому есть теоретическая вероятность разночтений. Поэтому правило не менял, только выделил. Можно заменять так - ? -> #\ .

Я уже писал выше, что символ "#" для однозначности обратного преобразования следует удваивать:
"#" -> "##"
(иначе за ним случайно может, например, оказаться символ "x" - и всё вместе превратится в звёздочку при обратном преобразовании)
Что касается двоеточия, то, мне кажется, куда удачнее его кодировать как "#=". Я уже рассказывал о интуитивно-лингвистическом родстве двоеточия и равно - если уж мы меняем правило его преобразования, то зачем заменять менее понятным "#!", который гораздо удачнее подошёл бы для обратного слэша:
"\" -> "#!"
"|" -> "#i"
(ну разве это не легко запоминающаяся и красивая комбинация правил?)
"/" -> "#%" (по крайней мере, в символе процента есть наклонная черта, так что тоже нетрудно запомнить).

Это способно создать новые глюки при обратном преобразовании: что произойдёт, если после симовла "#" окажется "%22"? Даже если все символы # удваивать - тут нужен грамотный программист, чтобы при обратном преобразовании "##%22" заменять на "#"" (или, на худой конец, "#%22"), а не на "#/22".
Хотя, в принципе, учитывать это при обратном преобразовании программыми методами нетрудно, возможно, следует всё же придумать двухсимовльные коды для этих символов. Или же следует также изменить способ кодирования простого слэша, чтобы не было неоднозначности. Например, простой слэш можно кодировать как #[. Но лучше - кодировать эти три знака:
">" -> "#}"
"<" -> "#{"
кавычка -> "#'"
В конце концов, если уж мы их кодируем, то зачем делать это непрозрачным образом? Впрочем, на этих трёх символах я не сильно настаиваю.

Но вот двоеточие - нет никаких причин кодировать менее понятным образом, чем запись "#=", которая у любого, кто изучал Pascal в школе, сама преобразуется в ":=". А запись "#!" у кого будет ассоциироваться с двоеточием? Восклицательный знак - это остановка, конец предложения, а не продолжение речи. Двоеточие - продолжение речи, равно - продолжение уравнения, а восклицательный знак - конец речи. Какой смысл символ продолжения речи кодировать концом предложения?

Любой браузер при запросе урла с сервера всегда отбрасывает "#" и все что за ним идет (можешь глануть в монитор). По сути символ "#" и строка идущая за ним не является частью урла. Это просто метка для навигации по странице. По этой причине символ # используется для кодирования.
Если вебмастеру требуется передать #, то его придется закодировать в виде %23.

Кодирование с использованием "#" всегда парное, за символом "#" всегда появляется еще один. Ошибок не будет.

Может и лучше, но это надо продумать в последнем разделе "красивости" (см. ниже). Но все-таки попробую обяснить почему %xx. В любом браузере символы "<>` всегда должны кодироваться в виде %xx - это СТАНДАРТ. А IE почему-то этим пренебрегает, вот мы и исправляем чужие недоделки. В принципе такое иправление можно зашить в "Переадресацию"...
(Кстати, символы <> не получится использовать в урлах в HTML-странице, будет противоречие с тегами. Возможно это глюк лишь адресной строки IE.)

Сама не сама, но вариант хороший :) впишу в таблицу
(но я все еще сомневаюсь, что mai62 согласиться менять кодирование ":")

Теперь о красивостях, а точнее о преобразованиях из %xx во что-нибудь удобочитаемое.

- По поводу кирилицы почти разногласий нет (%D1%8F -> я). Глюки firefox надеюсь не трогаем?
- Что делать с %20 стоит ли переводить в пробел? Тут есть свои заморочки.
- %3E -> #}, %3C -> #{, %22 -> #', %23 -> ##, %60 -> #, Оно действительно надо?

старые посты почему-то не правяться, придется писать по новой

Преобразования URL<->filename

Cейчас имеется:

символ	до "?"	после "?"
/	\	#%
//	\~	#%~
*	#x
\	#~
|	#i
!	#I
:	!
?	^\	#^
редирект и решение проблем
редирект	редирект#m
путь\	путь\#_

Возможный вариант:

символ	до "?"	после "?"
/	\	#%
//	\#%	#%#%
*	#x
\	#~
|	#i
!	!
:	#! или #=
?	^\	#^
лечим глюки
(можно реализовать через
вшитую переадресацию)
"	%22
<	%3C
>	%3E
`	%60
редирект и решение проблем
.\	.#n\
редирект	редирект#m
путь\	путь\#_
путь.	путь.#_
красивости
%D1%8F	я

Это НЕ стандарт, а побочный эффект невозможности использовать их в HTML-файле.  Но если загрузка идёт иным способом, скажем AJAХ-скриптом по динамически формируемому урлу - оно может и произойти.
(собственно, кто мешает какому-нибудь "талантливому" программеру запихнуть XML-запрос в GET (а не POST)-переменную?)
Но для читабельности кеша лучше перевести его назад.
Да. Желательно хранить базу "исходный урл = файл на диске"

ЗЫ: И мы ещё не коснулись того, что на типичных для инета серверах имена файлов регистрочуствительны и в одной папке запросто могут лежать file.jpg и File.jpg :)

Вот это правильное понимание! Так и надо!
Полностью согласен! Мои правила (http://forum.ru-board.com/topic.cgi?forum=5&topic=21354&start=1848&limit=1&m=1#1) декодируют все символы, которые могут быть закодированы (перечень взял со страницы http://ru.wikipedia.org/wiki/URL ). Я считаю, что нечитаемых кодов в кэше не должно быть! А символ "#", если он встретится в закодированном виде, надо декодировать в удвоенном виде для однозначности: "##".

спорить не буду, можете почитать http://www.lib.ru/WEBMASTER/rfc2068/rfc2068rus.txt

хорошо, только не мог бы ты свой список написать в виде
%xx - @
чтобы сразу было видно, что было в урле и что мы получим в файле

PS: я тут немного поразмыслил и теперь мне кажется, что коды в диапазоне %01...%7f вообще не стоит декодировать :( Когда будет список, поясню...

Похоже, перед раздумьями ты не ознакомился с таблицей кодирования символов (которая написана как раз в интересующем тебя формате):
http://i-technica.com/whitestuff/urlencodechart.html
Из неё становится ясно, что в указанном тобой диапазоне содержатся такие символы, как:
space, !"#$%&')*/<>\|
Обсуждению декодирования этих символов и посвящена большая часть этой темы...

popkov
ладно, сам напишу...

Код	Символ	Замена
%20	пробел
%22	"	#'
%23	#	##
%24	$
%25	%
%26	&
%27	'
%2a	*	#x
%2c	,
%2f	/	#%
%3a	:	#=
%3b	;
%3c	<	#)
%3e	>	#(
%3f	?	#^
%5b	[
%5d	]
%5e	^
%5с	\	#~
%60	`
%7b	{
%7c	|	#i
%7d	}

примерно так?

Только с символами <> ты напутал немного. Я (и, видимо, Дем, придумавший этот способ кодирования) подразумевал, что между символом ">" и символом ")" есть очевидное сходство: они выпуклы в одну сторону. То же касается символов "<" и "(" - именно на этом сходстве и были основаны правила. Я последнее время пришёл к выводу, что ещё яснее для них будут такие коды:
для ">" - комбинация "#}",
для "<" - комбинация "#{".
Это не что иное, как доработка правил Дем'а для ещё большей прозрачности. Поэтому предлагаю кодировать их именно так.
Ну, и ещё я уже неоднократно говорил, что для обратного слэша "\" я считаю гораздо более удачным код "#!", который содержит в себе чёрточку и при этом "комплементарен" коду для символа вертикальной черты "|" - "#i". По-моему, такое сочетание кодов очень изящное и легко запоминающееся.
С остальным в твоей таблице я согласен.

Ладно, это не принципиально.

Тут основная проблема - это преобразования URL->FileName->URL. Я считаю, что алгоритм должен быть такой, что зная полное имя файла, я мог бы получить исходный урл. Это основное требование. Преобразования кодов %xx в "прозрачные" символы в большинстве случаях противоречит такому требованию.
Завтра постараюсь все растолковать с примерами (сегодня спать хочется...)

Здесь ты заблуждаешься. Все символы кодируются двухбуквенными кодами, начинающимися со знака "#". Сам этот знак (если он встретился в URL в виде кода "%23" - а сам по себе он встретиться не может) кодируется в виде "##". Поэтому всё однозначно: если встретился в кэше файл с символом "#" - у нас есть только один способ правильно декодировать. Алгоритм декодирования простой:
"##" -> "#" (а строго говоря, "%23", поскольку ни один реальный URL, отправленный браузером, не может содержать незакодированный символ "#".  Тем не менее, для визуального представления в таких программах, как hc.historian, удобнее код "%23" представлять как "#", но браузеру при открытии страницы отправлять, естественно, в виде "%23")
"#"+символ кроме # -> надо интерпретировать как кодовую последовательность. Ситуация, когда эта кодовая последовательность неизвестна - заведомо исключена, поскольку одиночный символ "#" случайно появиться не может.
Так что твоё основное требование выполняется. Проблем нет. ;)
В конце концов, это дело разработчиков программ обратного декодирования - как представлять код "%23" в декодированном URL - как код "%23" или как символ "#". Но описанный алгоритм однозначно, ясно и коротко позволяет кодировать/декодировать любой символ.

Сегодня запустил поиск в логах HandyCache, и, к своему удивлению, нашёл в этих логах аж 9 URL, в которых символ "#" не отброшен (а всего там около 280000 URL). Это оказались:

_http://forum.ru-board.com/topic.cgi?forum=5&bm=1&topic=20528&start=1520#lt

_http://forum.ru-board.com/topic.cgi?forum=5&bm=1&topic=20528&start=1520#lt

_http://popunder.adsrevenue.net/links.php?data=rSe_2/ю/,-0#-+($S\\7Vq^Ye^jV]lюq_ZcY;%20+-,6уlcY;ю)1\'6{1/&1&id=astakiller&subid=63378&tid=1172829513&clater=&m=75&o=1&c=4096&a=65535&q=6&s=<=&ah=10&al=0&l=english&campaign=&rurl=&serverfile=paypopup&ref=http://asta-killer.com/&os=W1&bs=I1&isframe=false&bk=1&serverfile=popnetwork

_http://popunder.adsrevenue.net/links.php?data=rSe_2/ю/,-0#-+($S\\7Vq^Ye^jV]lюq_ZcY;%20+-,6уlcY;ю)1\'6{1/&1&id=astakiller&subid=63378&tid=1172829513&clater=&m=75&o=1&c=4096&a=65535&q=6&s=<=&ah=10&al=0&l=english&campaign=&rurl=&serverfile=paypopup&ref=http://asta-killer.com/&os=W1&bs=I1&isframe=false&bk=1&serverfile=popnetwork

_http://forum.kaspersky.com/index.php?s=8f31675557ec91eadc7d17cff9e7d132&showtopic=17353&st=0&p=143302&#entry143302

_http://forum.kaspersky.com/index.php?s=8f31675557ec91eadc7d17cff9e7d132&showtopic=17353&st=0&p=143302&#entry143302

_http://imho.ws/showthread.php?p=1265969#post1265969]http://imho.ws/showthread.php?p=1265969#post1265969


Выходит, что редко, но всё же происходит глюк, когда браузер отправляет URL с незакодированным символом "#". Это надо просто учитывать - вот и всё!

Интересный вопрос к mai62: в таких случаях, насколько я понимаю, HandyCache не отбрасывает символ "#" вместе со всем, что идёт за ним при записи на диск? Наверное, стоит ещё такое правило ввести, но работать оно должно до всех списков, преобразующих и переадресующих URL.

проверил у себя, в мониторе # нет (IE, Firefox)

На всякий случай отбрасывает (см. исходники).

А теперь как обещал...

Вот примеры нормальных урлов (согласно стандарту)
http://site/page?test_$_%24
http://site/page?test_%_%25
http://site/page?test_&_%26
http://site/page?test_'_%27
http://site/page?test_*_%2a
http://site/page?test_,_%2c
http://site/page?test_/_%2f
http://site/page?test_:_%3a
http://site/page?test_;_%3b
http://site/page?test_?_%3f
http://site/page?test_[_%5b
http://site/page?test_]_%5d
http://site/page?test_^_%5e
http://site/page?test_\_%5c
http://site/page?test_{_%7b
http://site/page?test_|_%7c
http://site/page?test_}_%7d
в точно же таком виде они отсылаются серверу в любом браузере.
А что будет если мы проделаем преобразование URL->filename->URL? Правильно, потеряем либо явно заданный символ, либо код. Потому что мы не знаем, был ли закодирован символ изначально.

Теперь более опасные вещи. Символы "/" и "?" несут специальные функции.
Имеем - http://site/page%2f.htm
после URL->filename - ..\site\page#%.htm
затем filename->URL - http://site/page/.htm - это уже серьезно, появилась новая "папка"

аналогично http://site/page%3f.htm?topic=5
URL->filename - ..\site\page#^.htm^\topic=5
filename->URL - http://site/page?.htm?topic=5  - изменились путь и строка параметров
URL->filename - ..\site\page^\.htm#^topic=5 - "^\" и "#^" поменялись местами

PS: HC использует лишь функцию URL->filename
Функция filename->URL требуется для просмотщиков кеша (например hc.Historian)
Функция filename->URL->filename требуется для преобразователей/конвертеров кеша

Остались %20, %22, %23, %3c, %3e, %60 - коды, соответствующие символам (пробел"#<>`), которые по стандарту вообще не могут использоваться в урле в явном виде. Причем "#<> придется кодировать как #', ##, #), #( - не очень наглядно. Остаются `(обратная ковычка) и "пробел".
Имхо из этих 6 символов стоит заморачиваться лишь не пробеле...

Блестящий анализ. Насчёт кодов %2f и %3f - согласен, что декодировать их не нужно.

А вот здесь не вполне согласен. Раз уж мы не декодируем %2f (слэш "/"), то вполне логично не декодировать и %23 (символ "#"). Это так. Обратная кавычка вряд ли может нести серьёзную синтаксическую нагрузку, и встречается редко (у меня 19 раз, и все - в параметрах баннерных скриптов). Но символ двойной кавычки несёт серьёзную смысловую и синтаксическую нагрузку, и регулярно встречается в параметрах поисковых запросов. Поэтому, для облегчения чтения последних я всё же считаю нужным его декодировать максимально прозрачно. Раз уж мы не декодируем %23, то освобождается супер-удобный код "##", который я и предлагаю теперь использовать для декодирования символа двойной кавычки. Символы <> тоже могут иногда помочь пониманию, и предложенный мной способ их кодирования:
для ">" - код "#}"
для "<" - код "#{"
мне кажется достаточно прозрачным (и даже очень прозрачным - сходство между "<" и "{" бросается в глаза), так что такое кодирование себя оправдывает.

По сути, благодаря отказу от декодирования %23 у нас появилась возможность максимально прозрачно закодировать именно тот символ, который несёт действительно большую смысловую нагрузку - двойную кавычку. И код "##" для неё, по-моему, очень подходит - он легко выделяется глазами внутри имени файла благодаря своей форме и легко запоминается.

Как мне кажется, преобразование filename->URL не должно восстанавливать исходный URL (это всё равно зачастую невозможно) - а должно давать URL, по которому будет выдан нужный файл в кеше.
Поэтому абсолютно всё равно, в каком виде в нём будут символы - %2a или *

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

Имелся в виду, конечно же, именно URL - вопрос поставлен о том, нужно ли его однозначно восстанавливать из имени файла.
В общем-то, восстановление рабочего исходного URL всё же желательно: что будет, если ты захочешь увидеть обновлённую версию вэб-странички, которую отобразил Историк из кэша? Даблкликнешь по ней в списке Историка, и он передаст браузеру восстановленный URL. Конечно, хотелось бы, чтобы в такой ситуации нужная страница была всё-таки открыта.
Другое дело, что нужен именно рабочий URL, а вовсе не абсолютно совпадающий с изначальным. И тут следует обсудить, в каких ситуациях и для каких именно символов декодировка их внутри URL может привести ко глюкам, а в каких - нет.
С символами "/" и "?" - уже всё ясно, лучше их и правда оставить в покое.
Двойные кавычки, пробел и <>, думаю, тоже стоит декодировать для читабельности кэша - они всегда закодированы в URL, и неоднозначности не возникает.
Думаю, ни при каких обстоятельствах декодировка закодированного символа процента ("%25" -> "%") к глюкам привести не может, поскольку символ процента в обоих ситуациях присутствует в явном виде всё равно. Откровенно говоря, у меня большие непонятки, зачем вообще символ "%" зачастую оказывается закодирован в виде "%25"? Например, пробел при этом оказывается закодирован не "%20", а "%2520". И эта ситуация - частое явление (у меня 27887 строк, содержащих такие URL). Это приводит к неслабому удлинению имени файла.
 

А если реальное имя файла на сервере его содержит? Например в исходном имени - пробел, а после загрузки на сервер уже %20 (а в урле уже %2520)
А вот в кеше некоторым хотелось бы иметь именно исходное имя...

В востановленном УРЛ. В принципе, в нём можно дать даже #х (в смысле %23х), а не заниматься обратным преобразованием.

В моих логах я не нашёл ни одного примера под твоё замечание. Может, подкинешь пример такого URL?

Закодированный символ процента встречается в моих логах часто (27887 таких символов, и чаще всего в одном и том же URL их может оказаться хоть полсотни - все закодированные русские буквы, слэши, пробелы, знаки вопроса - повторно закодированы). Однако в 100% случаев закодированный знак процента в моих логах встречается не в имени файла или папки, а именно в параметрах скрипта. Практически всегда - когда параметром скрипта идёт URL (Referer), и в нём все слэши, знаки вопроса, двоеточия, тильды и русские буквы для безопасности закодированы, причём ещё и по два раза. В таких случаях, видимо, однократное декодирование знака процента никакой опасности представлять не может. Большинство таких ссылок являются баннерными.
Хотя я помню редкие случаи, когда какой-то ничинающий сайтостроитель выкладывал у себя на сайте файлы и папки с пробелами и русскими буквами в именах. Но эти символы там не были закодированы! А если бы и были - тут уже встаёт вопрос о том, какой алгоритм использует сервер при поиске файла по URL - сразу декодирует или вначале сравнивает?

Надо найти реальную ссылку на файл, имя которого закодировано на сервере, и протестировать!
Да и бывают ли такие файлы? Можешь привести пример программы, которая при закачке по FTP файла с пробелами или русскими буквами будет создавать в целевой папке файл с закодированным пробелом или русскими буквами? Все FTP-клиенты, с которыми я работал, такой ерундой не занимались.

Только что специально зашёл на FTP-сервер с литературой нашей локальной сети. Там полно файлов с длинными именами, в которых одни русские буквы и пробелы. Я специально закачал на один из них ещё один такой файл с именем "Тест с пробелами.doc", используя в качестве FTP-клиента Internet Explorer. Никакого искажения имени "Тест с пробелами.doc" не произошло! Тем не менее, когда я открыл этот файл в FTP-папке, Internet Explorer в адресной строке представил ссылку на него следующим образом:
_ftp://172.16.38.140/Upload/%D2%E5%F1%F2%20%F1%20%EF%F0%EE%E1%E5%EB%E0%EC%E8.doc
Правда, с открытием этой ссылки у IE возникли проблемы, хотя скопировать из этой папки данный файл он позволяет без труда.
Обрати внимание, что служебный символ процента "%" здесь не подвергнут повторному кодированию в виде %25!
А вот когда я закачал на сервер файл "Тест % %.doc", неслужебные символы процента оказались закодированы в URL, сформированном Internet Explorer:
_ftp://172.16.38.140/Upload/%D2%E5%F1%F2%20%25%20%25.doc

Провёл эксперимент с программой Wget.
Заставил её скачать несколько URL:
wget "ftp://172.16.38.140/Books and Documents/%25.html"
wget "ftp://172.16.38.140/Books%20and%20Documents/%25.html"
wget ftp://172.16.38.140/Books%20and%20Documents/%25.html
wget ftp://172.16.38.140/Books%20and%20Documents/%.html
Во всех этих случаях результат был одинаков: Wget открывает папку Books and Documents,
затем запрашивает файл с именем "%.html".
А вот в следующем примере:
wget ftp://172.16.38.140/Books%20and%20Documents/%2525.html
программа искала уже файл с именем "%25.html".
А если закодировать проценты в имени папки:
wget ftp://172.16.38.140/Books%2520and%2520Documents/%25.html
программа ищет уже несуществующую папку "Books%20and%20Documents" и не находит...

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

А примеры можно, когда это имеет значение?
В спецификации URL действительно указано, что строчные и прописные буквы не равнозначны?

http://ru.wikipedia.org/wiki/gps википедия перенаправит нас на http://ru.wikipedia.org/wiki/Gps и скажет что такой статьи нет.
Потом когда мы введем правильное название http://ru.wikipedia.org/wiki/GPS, то HC увидит что такой файл уже есть в кэше и может отказаться его обновлять.
В принципе могут существовать разные статьи с именами различающимися только регистрами букв. Если бы HC работал под Linux и хранил кэш в его файловой системе, то этой проблемы бы не возникало.

Так и происходит! Печально...  ???
А вот Internet Explorer - хоть, вроде, и тупой ослик, а этот момент не упускает - у меня поначалу ссылки
http://ru.wikipedia.org/wiki/Gps
и
http://ru.wikipedia.org/wiki/GPS
действительно открывали разные страницы - одна бралась из кэша IE (ответ HC, что не изменилась), а вторая - из кэша HC! Забавно, но поначалу всё работало правильно, пока я не почистил кэш IE...
Впрочем, сама эта проблема уже не кажется мне забавной... Хоть, как в RegExp, вводи метки, указывающие, что следующие буквы становятся прописными или заглавными. Но это не выход...

Да, Microsoft даже здесь умудрился сделать подставу!

Могу предложить ставить перед заглавными буквами символ ударения (обратную кавычку) "`". Этот символ не может встречаться в URL в явном виде - только в виде кода %60. Причём этот код, если поискать в кэше, встречается только в параметрах счётчиков и баннерных скриптов, да и то - редко (у меня 10 вхождений среди 300000 URL в логах).
Причём, для повышения удобочитаемости содержимого кэша и укорочения имён файлов, предлагаю - в случае, если идёт несколько заглавных букв подряд - ставить символ ударения, а за ним - количество заглавных букв, идущих подряд (цифра). Такое кодирование будет однозначным: символ ударения в имени файла случайно появиться не может, а значит, кодирование/декодирование будет носить однозначный характер.
И вместе с тем, символы ударения не будут загромождать экран и бросаться в глаза.
Во многих случаях регистр букв точно не может иметь значения: это имя сайта, а также внутри кодов %2F (которые мы не декодируем) и т.п., поэтому для них стоит сделать исключение.

А сейчас мне пришла ещё более удачная мысль:вместо символа ударения можно использовать неразрывный пробел!
Его можно ввести, набрав при нажатой клавише ALT на цифровой клавиатуре код 0160 (или просто нажать в Word Ctrl+Shift+Пробел). Имя файла или папки в Windows может состоять даже из одного - единственного символа неразрывного пробела!
Вот этот символ: " ".
Остерегайтесь, правда, копировать его из Word - по какой-то причине он при вставке в имя файла превращается в обычный пробел. Но если скопировать из EmEditor или Блокнота (набрав его там Alt+0160) - всё в порядке! Удобнее всего делать это в TotalCommander - переименуйте любой файл, оставив в качестве его имени только символ " ". Работает - проверено! ;)

Так вот, предлагаю теперь перед каждой заглавной буквой просто ставить этот неразрывный пробел - теперь всё будет совсем читабельно и однозначно! Проще некуда!
Ну а если этот символ встретится в исходном URL (у меня нашлось всего 3 вхождения (среди 300000 URL) в параметрах баннерных скриптов в явном виде) - надо его закодировать (например, кодом "# " - решёточка с неразрывным пробелом).

Как вам такое? Тупой ослик отдыхает... ;)

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

Как вариант решения, сделать сие опционально, добавить правило "Кодировать заглавные буквы" по подобию "Сохранять www. ..." или "Не загружать большие файлы"

Подведем предварительные итоги первой части (см. ниже). Пора узнать мнение Главного раработчика :)

Преобразования URL<->filename (измениния/дополнения выделены жирным)

Лечим глюки IE (приводим урл к стандарту)

символ	до "?"	после "?"
URL#строка	URL
"	%22
<	%3C
>	%3E
`	%60
^	%5E	^ (не кодируем)

PS: Последний пункт нужен для правильного декодирования первой строки "^\".

Основная часть кодирования

символ	до "?"	после "?"
/	\	#%
//	\#%	#%#%
*	#x
\	#~
|	#i
!	! (не кодируем)
:	#= или #!
?	^\	#^

С двоеточием пора определиться. mai62 ты где?

Красивости

строка	замена
%D1%8F	я (кирилица)
%20	пробел

Тут сразу вопросы. Реализовывать "Красивости" намертво или опционально? Понимают ли UNIX-овые файловые системы пробел?

Опциональное кодирование регистра (под вопросом: стоит ли?)

строка	замена
W	`w

imho эту фичу пока не стоит вводить. Поповоду неразрывного пробела, надо проверять, как он поведет себя на FAT, на unix-овых ФС.

Редирект и решение проблем

строка	замена
редирект	редирект#m
.\	.#n\
пробел\	пробел#n\
путь\	путь\#_
путь.	путь.#_
путьпробел	путьпробел#_

Добавилось следующее: если папка или файл заканчиваются точкой или пробелом, то соответственно добавляем #n и #_

Красивости II (нужно ли?)

строка	замена
%22	#'
%3C	#( или #}
%3E	#) или #}

imho эти коды не стоит трогать, на наглядность они не сильно влияют. По поводу %22->## я тем более против.

PS: Кто в курсе какие символы запрещены в unix-овых файловых системах? Киньте сюда информацию.

PPS: Если будет время, то на следующей неделе напишу конвертор URL->filename->URL (будем наглядно видеть что у нас получается)

В файловой системе Unix запрещены два символа - "/" (обозначает папки в пути) и "\000" (то есть нулл символ, обозначающий конец имени файла). Все остальные символы - разрешены.

v0lt
Спасибо за проделанную работу по обобщению предложений. Добавь, пожалуйста, в табличках колонку, отображающую нынешнее поведение НС. Мне представляется важным по возможности сохранить совместимость с прежними версиями НС.

На FAT ведёт себя нормально - проверено неоднократно мной! У меня папка "Ссылки" IE уже не первый год на FAT переименована в неразрывный пробел! И никаких глюков ни разу не было! И простые файлы тоже нормально создаются и обрабатываются! Проверял!
А где аргументация? Чем тебе не нравится такой прозрачный и легкочитаемый способ кодирования?

HandyCache у тебя выдала ту самую ошибку, о которой говорил Зайди на http://ru.wikipedia.org/wiki/GPS
 - но отключив чтение из кэша! Тебе откроется вовсе не пустая страница...
(если всё же откроется пустая - это IE виноват! Обнови страницу при выключенном чтении из кэша!)

Спасибо, а как там с уникодом?

Не знаю чего сказать, ну не нравиться мне %22->##. Если бы уж очень понадобилось %23->##, я может и согласился (по другому тут глупо кодировать). В принципе обратное преобразовние в URL особо не усложняется (всего то поставить s:=StringReplace(s,'##','%22',[rfReplaceAll]) в самое начало функции), но только из-за прозрачности, не знаю, не знаю... внуть кеша не каждый полезет, проще в Историке найти нужное (обычно)
Разобрался, пришлось почистить кеш Firefox... :(
Значит кодируем опционально и в стандартные настройки для примера вбиваем "wikipedia.org"

Всегда пожалуйста.
Сейчас дополню табличку...
PS: маленькая просьба. Сразу новую версию не выпускай. Еще остались пара вопросов и конвертера нет.

В современных юниксах, насколько я знаю, с уникодом все в порядке.

для mai62

Преобразования URL<->filename (измениния/дополнения выделены жирным)

Лечим глюки IE (приводим урл к стандарту)

символ	0.98b1	до "?"	после "?"
URL#строка	URL	URL
"		%22
<		%3C
>		%3E
`		%60
^		%5E	^ (не кодируем)

Основная часть кодирования

символ	0.98b1	до "?"	после "?"
/	\	\	#%
//	\~	\#%	#%#%
*	#x	#x
\	#~	#~
|	#i	#i
!	#I	! (не кодируем)
:	!	#= или #!
?	^\  #^	^\	#^

Красивости (новое)

строка	замена
%D1%8F	я (кирилица)
%20	пробел

Можно сделать опционально. В будущем можно добавить другие кодировки.

Опциональное кодирование регистра (новое)

строка	замена
W	`w или `W

`w или `W не принципиально.
2popkov По поводу неразвывного пробела (символ 0160). Напрягает, то что его номер больше 127, поэтому на некоторых системах он может выглядеть по другому, для спец кода это плохо. Еще возможно путаница (выглядит как пробел) и есть проблемы ручного редактирования. Обратная ковычка поудобнее будет.

Редирект и решение проблем

строка	0.98b1	замена
редирект	редирект#m	редирект#m
.\		.#n\
пробел\		пробел#n\
путь\	путь\#_	путь\#_
путь.		путь.#_
путьпробел		путьпробел#_

Добавилось следующее: если папка или файл заканчиваются точкой или пробелом, то соответственно добавляем #n и #_

Остальное на предыдущей странице...

v0lt

В первых двух твоих таблицах колонка "после "?" не заполнена, хотя, на мой взгляд, она должна совпадать с колонкой "до "?". Или так и задумывалось, а движок форума тебя не понял? ;)

В таблице "Красивости (новое)" сейчас только одна буква "я" и пробел. Может, сразу расписать кодировку всех символов в верхнем и нижнем регистре?

Собственно, можешь приаттачить к посту файл в формате Excel или Word, чтобы не мучаться с таблицами в BB-коде...

Если ячейка отсутствует - смотри левее. Или я не умею объеденять ячейки или движок...

шутишь их там 66 :)

угу, когда очищу от BB-шек

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

DenZzz
выкладываю таблицу (http://handycache.ru/component/option,com_smf/Itemid,10/action,dlattach/topic,78.0/attach,162/), там основная часть и декодирование кирилицы (см. лист 2)
(коды #' #) #( #} #{ пока не вносил)

Сергей
В принципе возможно, но муторно и медленно.

Тогда предлагаю вариант получше - кодировать двойную кавычку двумя символами ударения, идущими подряд: "``".
Вариант, по-моему, более чем удачный. Конфликтов с кодированием заглавных букв не будет - там не может идти подряд два символа ударения.
В каких системах он выглядит иначе? Есть ли вообще такие системы? Уверен, под всеми версиями Win он выглядит одинаково - как пробел.
Может быть. Но тогда предлагаю в разделе "Решение проблем" решать их не с помощью комбинации "#n" - а с помощью куда более подходящего для этих случаем символа неразрывного пробела!
То есть, я предлагаю следующее:
Редирект и решение проблем

строка	0.98b1	замена
редирект	редирект#m	редирект#m
".\"		". \"
"пробел\"		" \"
"путь\"	путь\#_	"путь\#_" или "путь\ "
"путь."		"путь. "
"путьпробел"		"путь "

Во всех этих случаях я предлагаю обходить ограничения на использование пробелов и точек в именах файлов через неразрывный пробел, на который они не распространяются! Все видимые пробелы в таблице - это неразрывные пробелы! Согласитесь, что такое представление не только короче, но и гораздо нагляднее и более удобочитаемо!
По-моему, неразрывный пробел для наших целей чрезвычайно удобен. Давайте, что ли, протестируем, может ли он создавать какие-то глюки вообще? Я сомневаюсь. Единственный недостаток, который я заметил при работе с ним - если его скопировать в буфер обмена "в формате RTF" (например, из Word) или "в виде HTML" (с вэб-страницы), то при конвертации в Plain Text винда зачем-то заменяет его на простой пробел. Этого не происходит, если с самого начала копировать как Plain Text (например, из Блокнота или, редактируя имя файла в Проводнике, содержащее неразрывный пробел - можно копировать и вставлять сколько угодно, никаких проблем я не заметил).

О.К. Только колонка "после "?" опять не везде была заполнена - подправил. ;)

Еще добавил в декодирование кириллицы кодировку Win-1251.
Например, URL:  http://www.yandex.ru/yandsearch?text=%CF%F0%E8%EC%E5%F0
корректно открывается во всех браузерах и хотелось бы в кэше видеть "прозрачную" кириллицу, а не коды...

Мы же собираемся ради "красивости" декодировать UTF-8, типа:
http://www.yandex.ru/yandsearch?text=%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80
Чем Win-1251 хуже? ;)

Грамотно! (http://i.ru-board.com/s/up.gif)     

---

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

Ну и насчёт двойной кавычки  - всё же считаю нужным кодировать её максимально прозрачно как два символа ударения: "``".

Да и символы "<>" можно бы попроще записать как "#{" и "#}" соответственно. А можно - и того проще, записать их как " {" и " }" (неразрывный пробел + {}), соответственно. :)

Ничего не имею против - это не помеха для обратного преобразования filename -> URL.

Единственная заметка, что перекодировать придется не только сами "<> в URL-ах IE, но и их коды в других браузерах, чтобы не плодить в кэше одинаковые файлы с разными именами.


А вот использовать "неразрывный пробел" мне не очень нравится!
Во-первых, потому что визуально он ничем не отличается от обычного, что может создать неудобство для пользователя, который захочет открыть файл в сторонней программе, набрав вручную его имя. Естественно, он вряд ли сам догадается, что там используется "неразрывный пробел".
Во-вторых, как ты уже озвучил, его очень не просто ввести с клавиатуры (надо помнить код) и нельзя скопировать из наглядного в этом плане Word-а.
В общем, использование "неразрывного пробела" затруднит ручную правку имен файлов и ручной ввод их в сторонних программах!

popkov
все лучше и лучше :) вспомним с чего все начиналось
%22 -> #' -> ## -> ``
Последний вариант конечно наглядный, но мне и %22 никак не мешает :) Но ближе к теме, #' - очень логичный и удобный код для программирования. ## - растут сомнения (а зачем?), но сделать можно.
Теперь о "``". У меня даже сомнения стали возникать, стоит ли использовать символ ` как специальный (см. кодирование регистра), почти наравне с великим # :)
Этот символ входит в "группу" символов (пробел"#<>`), которые нельзя использовать в урле явно, но при этом имеются на любой клавиатуре (во как :)). И вдруг найдется такой же настырный человек, который будет лобировать %60 -> ` И тут даже возразить нечего, как и "пробел" его не требуется кодировать, чтобы создать такой файл.
Ладно посмотрим, что другие форумчане скажут.

Попробую возразить вашей же читатой - "под всеми версиями Win он выглядит одинаково - как пробел."

Я тут попробовал насоздавать папки файлы состоящие только из неразрывных пробелов. Зрелище страшное ;D (можно прикалываться над бедными чайниками) Есть подозрение, что спецы из мелкосовта когда писали ограничение на обычный пробел, забыли про неразрывной. Попробуй в командной строке через команду DIR узнать сколько неразрывных пробелов стоит в конце имени папки/файла. А если в имени намешать оба типа пробела, то ваще пипец...

Что-то мне припоминается глюк в каком-то продукте MS связанный как раз с неразрывном пробелом

PS: Разделение кода #_ и #n для файлов и папок я вводил не просто так. Я попробую проработать вариант без #n, потом отпишусь для чего это надо...

DenZzz
не стандарт, а глюк фокса
нельзя однозначно написать алгоритм декодирубщий одновременно и уникод и Win-1251.

Я не про глюк Фокса! Зайди на http://www.yandex.ru/ в Опере, набери в поле ввода русский текст и нажми "Найти" - получишь URL с кодами символов в Win-1251, который сервер понимает и возвращает результаты поиска!

Собственно, также без проблем сервер понимает и тот же самый текст, но в UTF-8 - примеры приводил выше!

А раз сервер смог без проблем опознать кодировку, то HC можно попробовать этому обучить!
Видимо, придется сделать допущение, что в URL может находиться одновременно только одна кодировка, и исходя из этого, декодировать символы по той или иной таблице.
Также, видимо, следует сохранять в имени файла признак кодировки кириллицы для возможности обратного преобразования filename -> URL...

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

DenZzz
Тем, что мы не знаем наверняка, какая там кодировка на самом деле. Мы что, создаем прокси только для русских? Вдруг буржуи тоже захотят пользоваться этой программой. Не навязывать же всем WIN. Да и в россии может встретиться сайт с KOI-8.

Если и делать преобразование, то в имени файла обязательно надо сохранить информацию о кодировке. Например так #?KOI8-R?Пример

Это тебе повезло, что Яндекс понимает и WIN и UTF-8
А попробуй такой URL
http://forum.ru-board.com/forum.cgi?action=filter&forum=35&filterby=topictitle&word=Пример
Браузер добросовестно закодирует в юникод
http://forum.ru-board.com/forum.cgi?action=filter&forum=35&filterby=topictitle&word=%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80
а сервер этого не поймет.

popkov
Неразрывный пробел это символ Юникода с кодом 00A0. Я категорически против его использования. Юниксовые файловые системы у нас, кстати, по умолчанию, монтируются в кодировке KOI-8 и такого символа там нет ;)
FAR понимает неразрывный пробел? У него плохо с поддержкой Юникода. Зачем лишние проблемы создавать?

Не знал... Что ж, тогда спорить не о чем.

Можно попытаться это определить! Наглядный пример - сервер Яндекса, который сам определяет кодировку в запросе!
Коды символов в UTF-8 всегда "двойные" и начинаются с %D0 или %D1 - это можно использовать для определения кодировки в URL-е...


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

Еще не стоит забывать, что HC работает под Windows и свой WIN есть в каждой локализованной Винде!

На счет KOI-8 - можешь привести реальный рабочий URL, где используется кодировка KOI-8 без явного на то указания в самом URL-е?


Во-первых, не каждый браузер перекодирует эту строку в Юникод! Мой отправляет в неизменном виде и получает правильный ответ! ;)

А во-вторых, тот сервер ру-борда не понимает Юникод, но зато прекрасно понимает WIN:
http://forum.ru-board.com/forum.cgi?action=filter&forum=35&filterby=topictitle&word=%CF%F0%E8%EC%E5%F0
Именно в таком виде страница ру-борда отправляет запрос на свой сервер, когда ты фильтруешь там темы в списке!

Кодировка WIN применяется во многих URL и на многих сайтах! Так почему же не хранить подобные URL-ы на диске в "прозрачном", читабельном виде?!

DenZzz
русская буква "Р" - код D0h
русская буква "С" - код D1h :(
серверу легче, если получается два варианта, то он может глянуть какая из страниц у него есть.

тут еще проще, сервер на поисковые запросы уже ожидает Win-1251, который генерируется скриптом страницы

Можно попробовать сделать опционалное правило для сайтов в урлах которых используется Win-1251.

HC тоже может глянуть, какая страница в кэше уже есть...

Это да, но можно пропарсить весь URL, откинув коды спецсимволов, и посмотреть, а не является ли каждый нечетный код D0 или D1. Если является, то проверить "пары" на вхождение в таблицу UTF-8. Так мы с большой степенью вероятности сможем правильно отличить UTF-8 от Win-1251. В общем, это возможно... :)


Не всегда у сервера есть эта страница, чтобы сверить! Пример с Яндексом я уже приводил:
http://www.yandex.ru/yandsearch?text=%CF%F0%E8%EC%E5%F0
http://www.yandex.ru/yandsearch?text=%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80

Оба запроса выводят одинаковый результат поиска, хотя сервер не знал ничего о кодировке критерия поиска! Значит у него есть алгоритм выяснения правильной кодировки!


Можно и так, если не получится прикрутить автораспознание кодировок.

---

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

Структура перекодировочного файла видится мне примерно такой:


Таким образом, каждый сможет сам править коды символов, добавлять свои кодировочные таблицы (полезно для иностранцев) и задавать сайты, для которых будет применяться та или иная перекодировка.

Я имел в виду WIN и KOI. Однобайтовую кодировку от юникода отличить легко, разумеется.

Возможно и так.

Ты случайно не кликнул на этой ссылке? Надо было скопировать строку вручную. Форумный движок сам заменил русские буквы на коды.

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

Не могу сейчас припомнить. Но совершенно точно есть сайты с кодировкой отличной от WIN.

Возможно стоит вытаскивать кодовую страницу из заголовков ответа сервера.

пишу алгоритм... дошел до декодирования уникода (%xx%xx) и пробела (%20)
обнаружил неприятность в алгоритме:

Согласно алгоритму после символа "?" имеем / -> #%
если имеем урл вида - site.com/page.htm?100/20=5
то получим - site.com\page.htm^\100#%20=5
Если за основными преобразованиями последует декодирование кодов вида %xx, то получим глюки. Придется его ставить в начале :(
Если сделаем конвертер кеша, который будет преобразовывать %xx согласно поддерживаемым в НС кодировкам, то надо будет не забыть проверку на наличие символа # перед %. Вот такие заморочки...

Еще вариант не использовать #% (совместимость пострадает). Взамен остались #; #, #z или #! (если : -> #=)

В общем-то, для кодирования слэша "/" комбинация "#!" прозрачнее, чем "#%". Так что поддерживаю! К тому же, для конвертера кэша заменить все вхождения "#%" на "#!" не так уж сложно...

Сделал первый вариант кодирования (пока не все фичи)
измения v1.1:
/ -> #!
// -> \#! -?- #!#!
: -> #=
файлы прилагаются
внутри архива таблица "что и как" и конвертор (нужен dotNetFX 2, идет с некоторыми крупными прогами и игрушками)
Конвектор работает очень просто, вводите урл и видите как он будет выглядеть на диске и как он востанавливается обратно...

Опять остались пустые ячейки в столбце "после "?" !


Помнится, раньше ты делал конвертер, работающий без .NET ...
Если менять существующий алгоритм URLToCache, то понадобится конвертер, работающий на всех системах (даже на Win98) и без установленного .NET !

DenZzz
ну понятно же... (поправил у себя) :)

DenZzz
было такое, но там был конвертор работающий с самим кешем...
когда дойдет до настоящего конвертора переведу код на Дельфи (наверно за основу возьму предыдущий вариант). сейчас пишу на C#, мне так проще...

PS: Есть Turbo Delphi (BDS2006) на нем можно безпроблемно написать для Win98 или нужен Delphi 7 ?

Не важно на чем писать - важно какие функции используются.

Чем тебе .Net не угодил? Он и под Win98 ставится. Я бы и сам HC под Net не отказался использовать. С совместимостью было-бы намного лучше.

1. Тем, что не у всех он есть, а качать только ради конвертера кэша 23 метра Microsoft .NET Framework 2.0/1.1 или даже 50 метров v3.0 тем, кто не имеет безлимитной выделенки и считает каждый МБ, пользуясь HandyCaсhe, - похоже на неудачную шутку...  ;)

2. Надо предусмотреть возможность интеграции конвертера в сам HC, если mai62 сочтет нужным, т.к. это облегчит пользователям переход на новую версию HC, которая написана на Дельфи и самодостаточно работает с любой версией Windows, не имеющей .NET !



Совместимостью с чем и для чего?

Rick
ну я бы не сказал, например C# вообще без dotNET не напишешь
был Delphi 8 - это вообще непонятно что, старые проекты не компилятся
Сейчас стоит Turbo Delphi 10 (Borland Developer Studio 2006) вроде нормально, проекты из Delphi 7 запускаются

Всем
Не беспокойтесь, будет конвертор без .NET. Сделаю когда отладим алгоритм и mai62 дасть добро...

v0lt
Ты спрашивал про D7 и D10 - я про них и отвечал. С# и дотнетовские версии Delphi в вопросе не фигурировали.

Абсолютно верно. Причем еще нужен ручной конвертор. Без него пока сложно использовать список Преобразование URL без потери имеющихся в кэше данных.

С Windows Mobile. Чтобы иметь возможность использовать HC и на коммуникаторе.

Доработал алгоритм:
измения v1.2:
-Пометка заглавных букв
-Поддержка win-1251
файлы прилагаются

Так, думаю стоит обсудить проблему длинных урлов.
Эту тему я как-то обсуждал с mai62, но в тот момент революция не планировалось, поэтому этот ворпрос был отложен...

Сейчас алгоритм работает так:
  На последнем этапе преобразования урла в имя файла проверяется длина имени (относительно папки кеша). Если она больше 200, то мы находим последний символ "\" в пределах первых 192 символов. Строку до символа "\" оставляем, а оставшееся кодируем хешем CRC32:

[путь<192]\[CRC32(путь>192)]


Я предлагаю:
- высчитывать CRC32 на основе URL, а не имени файла. Так будет более однозначный результат и меньше вероятнось потерь при преобразованиях.
(урл брать уже пофиксеный, без багов IE)
- помечать строку хеша. Так будет стразу понятно, что это урл был длинным.
- сделать опцию типа "Для длинных URL сохранять *.url". Возможно кому-то может понадобиться узнать реальный урл.

Алгоритм такой:
 Проверяем длину имени (относительно папки кеша). Если она больше 200, то мы находим последний символ "\" в пределах первых 190 символов. Строку до символа "\" оставляем, плюс добавляем помеченный хеш урла без хоста. Помечать предлагаю кодом #- :

[путь<190]\#-[CRC32(урл_без_хоста)]   

 IMHO Хост кодить не надо. Причины: В зависимости от настроек .www может как отбрасываться, так и нет. Иногда сайты меняют хостинг, оставляя структуру, и чтобы ничего не пропало, юзер может просто переименовать соответствующую папку.
+ очень легко реализуемо
+ на CRC практически ничего не влияет

v0lt

Как быть с длинными URL, которые сейчас уже сохранены в кэше?
Переконвертировать их по новому алгоритму не получится, т.к. исходный URL мы восстановить не можем!

Все логично. Осталось уточнить, откуда взялись числа 200 и 190.

Удалить? Их не много.

Вообще-то не очень хорошо получится. Надо будет еще учитывать знак ? в  URL. И прогонять через Преобразование URL перед вычислением CRC32.
Лучше оставить как есть, но дополнить алгоритм этими пунктами.

DenZzz
как правило там мусор, ничего полезного...

Сергей
Полная длина пути ограничена примерно 250 символами (кто-то высчитывал точнее, не помню). 50 символов мы оставляем на имя корневой папки кеша, остальные 200 используем на свое усмотрение.
#-12345678 - код+CRC32 - итого 10 символов
200-10=190
...
Хотя если быть более точным, то теоретически может понадобиться 202 символа для редиректа. И 204 символа для .url и .new
Тогда есть вариант: 195 и 185 - тут мы точно за предел в 200 символов не вылезем...

да про знак я забыл... поправлю...
тут я ошибся знак "?" не важен

а прогонять ничего не надо(опять ошибка, см. следующий пост), кодить будем именно кусок урла
урл http://handycache.ru/component/option,com_smf/Itemid,10/topic,78.100/
файл handycache.ru\component\option,com_smf\#-A30935E6
где A30935E6 = CRC32(component/option,com_smf/Itemid,10/topic,78.100/) для 50 и 40

Нет, здесь ты забываешь о множестве способов попасть на одну и ту же страницу, даже на данном форуме! Преобразование URL для того и нужно, чтобы для одной и той же страницы создавался только один файл, хотя URL'ов для неё может быть несколько...

popkov
сорри, я перепутал список Преобразование URL с алгоритмом url2filename :)

Вообщем Преобразование URL итак идет до получения имени файла (до url2filename) и оно никуда не денется.
т.е. логика остается почти такой же
...->Запись в кеш->Преобразование URL->fix_URL->URL2filename->Кеш
(выделено новое/измененное)

Расскажи, плиз, когда появляется .url? Не встречался мне никогда, а знать хочется.

Михаил
никогда :), в текущеq версии не предусмотренно
есть только предложение создавать такой файл для очень длинных урлов

Выкладываю новую версию алгоритма:
измения v1.21:
-Добавлено кодирование длинных урлов
(для упрощения тестирования ввел доп. ограничения длины в 50, 100 и 150 символов)
-Улучшен интерфейс :)

PS: Кто знает как firefox фиксит урл (полная версия)?
PPS: У кого-нибудь есть исходники для функции unescape?

Должен сделать важное замечание: оказывается, в URL'ах встречается не так уж мало символов, которые невозможно ввести с клавиатуры...
Выполнил ради интереса поиск с помощью PowerGrep в своих логах по RegExp шаблону [^\w\s].
Шаблон простой, а результаты удивили (сгруппированы по возрастанию количества совпадений, первая цифра - это число найденных символов):

TOTAL:    8320744 matches in 47 groups in 391 files
       1  ’
       1  ¤
       3  ?
       4  ”
       4  †
       5  …
       8  ‡
      10  #
      10  ¦
      26  ‹
      27  \
      27  ¶
      35  „
      50  №
      52  <
      54  ±
      69  ·
      74  }
      78  {
      80  !
     103  »
     106  ‚
     138  >
     171  °
     176  |
     217  ^
     218  $
     287  [
     289  ]
     290  ~
    1156  '
    1166  @
   10035  +
   24378  *
   75837  ;
   97087  (
   97138  )
  102882  ?
  169410  -
  216965  ,
  238311  &
  342741  =
  591334  %
  724050  "
 1107050  :
 2130843  /
 2387748  .

А могут это быть ошибки? Например когда у меня на интернет-сервере сбойная планка памяти была - там при анализе в логах тоже случайные пользователи/урлы появлялись с разными нечитаемыми символами

Большинство этих символов можно ввести с клавиатуры! А те, которые нельзя ввести, встретились в твоих логах крайне редко! Да и вообще, непонятно, как они там оказались! Если следовать стандартам, то их не должно быть в URL в чистом виде - только в виде кодов!

У меня большинство из них оказались в параметрах запросов на сайт
http://m.webtrends.com
Попробуй поискать все URL, начинающиеся на http://m.webtrends.com
- а затем посмотри, есть ли там такие "ненормальные" символы.
Я согласен, что это-баннерный сайт, однако наличие таких URL говорит о том, что возможны и другие сайты, при просмотре которых генерируются URL с незакодированными такими символами.
Тем более, что у меня нашлось несколько таких URL, имеющих отношение к программе Windows Update - оказывается, она иногда тоже генерирует URL c незакодированными символами. Вот какой нашёлся:
http://office.microsoft.com/officeupdate/error.aspx?Code=3&Error=Объект%20не%20поддерживает%20это%20свойство%20или%20метод

Я провёл поиск по более частному шаблону: [^!-~\w\s]
Результат:

TOTAL:    687 matches in 17 groups in 12 files
       1  ’
       1  ¤
       3  ?
       4  ”
       4  †
       5  …
       8  ‡
      10  ¦
      26  ‹
      28  ¶
      35  „
      51  №
      55  ±
      69  ·
     104  »
     111  ‚
     172  °

Количество URL в логах у меня около 300000.

(687 / 8320744) *100% = 0,008% - вероятность встретить такие символы в URL по данным твоих логов!

Не пойму, что ты предлагаешь?

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

Поэтому и было предложено отказаться от использования "неразрывного пробела" в пользу другого символа "`", который есть на клаве, различим визуально и даже отсутствует в твоих логах! Какие проблемы? :)

Да никаких :)
Просто для ясности отметил 2 момента:
1) Могут появляться файлы в кэше, имена которых нельзя ввести с клавиатуры
2) Есть вероятность (не уверен), что некоторые сторонние программы могут отказаться обрабатывать файлы с такими именами. Но EmEditor открывает - а мне на остальные по фигу... :)

Но проблемы здесь особой не вижу, т.к. это - большая редкость (хоть и чаще, чем ты посчитал: надо скорее 687 делить на 300000 URL). :)

Не! У тебя не может быть в логах 687 разных URL с этими символами! Вот смотри, только в одном твоем примере:
http://office.microsoft.com/officeupdate/error.aspx?Code=3&Error=Объект%20не%20поддерживает%20это%20свойство%20или%20метод
я насчитал 10 символов из твоих 687 ! :)

ввел в Firefox-е этот урл, лис его естественно поправил
IE ничего не делал, так и оставил
в обоих случаях получил редирект на нормальный урл

повторю вопрос: кто смотрел исходники фокса, дайте функцию исправления URL. Или там что-то готовое используется?

Люди, как все-таки лучше проверять длину имени файла?
Смотреть чтобы имя файла было меньше 200 или 195?
Первый вариант лучше нагляднее запоминается, но на самом деле файл может получиться из 204 символов.
Вариант 195 на вид не очень, но в результате получим гарантированно не более 200.


Пора поговорить о втроенной сортировке...
Мне кажется вопрос уже для многих актуален. У себя я сделал простейшую сортировку по имени домена.

Пример: файлы с handycache.ru лежат в \_h_\handycache.ru\
файлы с forum.ru-board.com лежат в _r_\forum.ru-board.com\
домены начинающиеся на цифры лежать в _0_\

Это примитывный вариант, я сделал через преобразование URL. В результате в корневой папке всего 27 папок, а в каждой в среднем во столько же раз меньше хостов, чем раньше. Открыть такую папку куда быстрее. К тому же структура кеша осталось почти такой же.

Не понимаю, чем он лучше? Надо просто решить, сколько символов оставлять для пути к папке Cache. 45 или 50 - по-моему, неважно - в любом случае, вряд ли кто-то будет делать для неё большую вложенность каталогов.
Я уже поднимал этот вопрос на RU-Board, но меня не поняли. Для себя я сделал иначе: у меня просто создаются в кэше только папки для доменов второго уровня. Например, forum.ru-board.com у меня лежит в папке:
.\Cache\ru-board..com\forum\
А сайт ru-board.com у меня хранится в папке
.\Cache\ru-board..com\_NULL_\
Аналогично для всех остальных сайтов.
По-моему, это очень удобно, потому что всё, что относится к конкретному серверу (в данном случае ru-board.com) лежит в одной папке, а не разбросано по разным каталогам.
Для того, чтобы сохранить функционал Историка, мне пришлось написать также правила для Переадресации, которые переделывают имена сайтов обратно. В качестве признака, что это - запрос от Историка, я использовал присутствие двух точек подряд, отделяющих имя домена первого от имени домена второго уровня (вместо одной точки).
К сожалению, в Историке нет функции, позволяющей задать структуру кэша (то есть указать правило, по которому путь к файлу на диске должен преобразовываться в URL). По-моему, отсутствие такой возможности - серьёзная недоработка Историка. Именно из-за отсутствия такой возможности мне пришлось вместо одной точки ставить две между именами доменов 1 и 2-го уровней.

popkov
Есть такое...
Но такой вариант может усложнить приведение кеша к стандартному виду (без спец. утилит). Поэтому я подобное не делал, да и лень было :)

еще можно расмотреть такие варианты:
(r)\ru-board.com(forum)\
_R_\ru-board.com[forum]\
R\ru-board.com[forum]\
R\ru-board.com,forum\
но, как я понимаю, скобки не очень удобны для регулярных выражений...

ИМХО, без разницы.


Чем открыть такую папку быстрее? Сторонней программой для ручного просмотра кэша?

Более полезным мне кажется предложение из ToDo о сортировке параметров:

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

DenZzz
да, любой сторонней программой. Например мне нужно поковырять в handycache.ru, то я сразу выбираю папку с соответствующей буквой где лежит несколько сотен сайтов, вместо того чтобы ждать пока откроется папка с тысячами сайтами.

Кстати если в Историке открыть "браузер кеша", то в первый раз он довольно надолго задумывался, сейчас, с сортировакой, открывается секунды за две...

Подчеркивание тут лишнее. Давно пора сделать так. В CoolProxy это называлось компактным режимом, кажется.

Еще раз (http://forum.ru-board.com/topic.cgi?forum=5&topic=18348&start=1620#4) по поводу длины.

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

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

Тогда можно так:
h\handycache.ru\
r\ru-board.com,forum\
m\mail.ru,img.photo\

Юникод функции нам не нужны. Даже если они заработают, то будут проблемы с внешними программами типа Архивариуса. Лучше решить какая длина пути для нас максимум.

С запятой это интересная идея!
А последнюю строку как рассшифровать?

Сергей
img.photo.mail.ru  ->  m\mail.ru,img.photo\
ну типа всё что до домена (img.photo) не меняем местами, добавляем как есть.

ну тогда и вот еще...
site.com:80  ->  s\site.com#=81\
forum.site.com:80  ->  s\site.com#=81,forum\
12monkeys.com  ->  0\12monkeys.com\  (нолик устраивает?)
122.344.566.788 -> 0\122.344.566.788\  (туда же где "циферные" домены?)

Нормально.

А как к таким преобазованиям отнесется Историк?

Ты прав.
Поиск в логах по шаблону (любой URL):
(?<= )http://\S*
дал результат:
TOTAL:    368734 matches in 31266 groups in 396 files
То есть уникальных URL в моём кэше 31266, а всего их 368734

А поиск по шаблону URL, содержащих символы, которые нельзя ввести с клавиатуры:
(?<= )http://\S*[^№!-~\w\s]\S*
дал результат:
51 matches in 46 groups in 13 files

То есть процент URL, содержащих невводимые с клавиатуры символы, равен:
46/31266*100%= 0.15%
Действительно, немного...

Сергей
Сам Историк такое переваривает нормально (историю естественно придется обновить).
Но т.к. URL выдается неправильный, то некоторые сайты (форум хобота) во втроенном браузере отображаются с ошибками.

Поэтому чтобы не было проблем, придется чуток дорабатывать Историк. Хотя если алгоритм поменяется, дорабатывать придется все равно...

Новая версия алгоритма:
измения v1.3beta:
-теперь относительная длина имени файла никогда не превышает 200 символов;
-добавлена сортировка по домену (используется префикс "_");
-если домен начинается не на символы 0..9,a..z, то он не сортируется (лазейка чтобы создавать папки в корне кеша);
-добавлена опция, благодаря которой имя домена будет всегда спереди (хосты состоящие только из цифр, точки и двоеточия игнорируются, предполагается что это ip-адрес);

Примечания:
- с префиксом удобнее работать, т.к. вроде возможны имена хостов состоящие из одной буквы (в стандарте я не нашел ограничений на минимальную длину). Если кто-нибудь знает больше или сможет создать такой сервер у себя в локалке, пишите сюда...
- если не нравится префикс "_" можно другой, продлагайте (кроме # и `)
- функция получения URL из имени файла оказалась достаточно универсальной, например необязательно знать отсортирован хост или нет. Вероятно проблемы могут быть, если изначально неизвестно как декодировались русские буквы, т.к. их придется кодировать хотя бы в UTF-8. Но и в этом случает проблем быть не должно, все-таки эта функция требуется лишь для автономного режима.

IMHO вроде основная часть сделана, осталось окончательно определиться будут ли встроенная сортировка, опциональные win-1251 и пометка заглавных букв.
Потом начну переводить код на Дельфи.

Встроенная сортировка может быть только опциональной! Меня, например, вполне устраивает придуманная мной структура кэша (http://handycache.ru/component/option,com_smf/Itemid,10/topic,78.msg3204/#msg3204), и менять её я не хочу!

Опциональность win-1251 (возможность выбора кодировки или задания правил)  нужна для иностранных пользователей.

И хотелось бы, всё-таки, чтобы двойная кавычка кодировалась предложенным мной понятным способом: ``

popkov
даже не знаю, как такое сделать чтобы у других меньше вопросов было...
хотя в приципе, если у тебя в хосте получается две точки подряд (.\Cache\ru-board..com\forum\), то тут новая сортировка не должна сработать.

это больше к mai62, ему придется писать интерфейс. Кстати какие кодировки иностранцы используют в урлах (желательно с примерами), может они все уже перешли на уникод? :)
ЗЫ: как я помню, на FAT-е файлы могут быть только на английском и на языке совпадающей с локализацией винды

можно даже добавить декодировку всех кодов национальных символов закодированных в UTF-8, но такое будет работать только на NTFS.

это мне не нравится: код усложняется, это нужно только тебе (как мне кажется) и думается mai62 будет против...

Гнилая отговорка! Не так код усложняется, как упрощается чтение кэша! А mai62 пока ничего не говорил! Так что не решай за него, пожалуйста! То, что только я об этом говорю - следствие того, что в этой теме вообще не так уж много активных пользователей! Я думаю, впоследствии те, кто часто работает с кэшем напрямую - будут мне благодарны за проделанную работу по убеждению незаинтересованных в том, что некоторым действительно нужно, чтобы соответствие
URL <> FileName
было максимально прозрачно для любого начинающего пользователя, а не только изучившего RFS!
Ты хочешь навязать всем свою версию структуры кэша! При этом пользователи лишатся возможности самостоятельно реализовывать ту структуру кэша, которая больше соответствует потребностям конкретного пользователя! Ты и здесь скажешь, что я - единственный, у кого есть собственные предпочтения относительно структуры своего кэша, не совпадающие с твоими? Пока и в этом вопросе в данной теме я - твой единственный оппонент. То, что другие не возражают - возможно, следствие недостаточно высокой популярности данной темы! А эта недостаточная популярность как раз с тем и связана, что в том, как реализована структура кэша в текущей версии HC, большинство пользователей всё устраивает - ведь текущая версия предоставляет полную свободу пользователю относительно того, какую структуру должен иметь его кэш (и не только в этом)! Чего же ещё желать?

Лично я принципиально ратую за сохраниение  (и преумножение!) той свободы (не только в плане структуры кэша), которую изначально предоставил HandyCache пользователю, и которая сохраняется и в текущей версии HandyCache - и которая является главным преимуществом HC над другими аналогичными программами и главной причиной такой большой заинтересованности пользователей в HC, что на форуме RU-Board тема про HC  - самая быстрорастущая!

Я даже думаю, что, раз уж мы решили дать возможность пользователю самому составлять файл с правилами декодирования символов его языка, то некотрые символы (в том числе двойную кавычку и знаки <>) следует также внести в этот файл - чтобы, в конце концов, такие упрямцы как ты могли кодировать её так, как им хочется!

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

В текущей версии HC я через правила "Преобразования URL" кодирую символы "<> так, как считаю нужным:
символ " (и %22) как ``
символ < (и %3c) как #{
символ > (и %3e) как #}

Ты, похоже, хочешь отнять у меня свободу кодировать (пока, как я понял, только двойную кавычку) так, как мне кажется оптимальным. Зачем? Если бы усложнение кода можно было считать аргументом - тогда зачем вообще написан HandyCache? Лучше было просто пользоваться IE и не "усложнять код".

А с двойной кавычкой - речь идёт о совершенной мелочи. Разве тут можно говорить об усложнении кода в масштабах того, что уже сделал mai62?

Что касается структуры кэша - надо оставить пользователю те права и возможности, которыми он обладает сейчас, а не стремиться их у него отнять! Твои персональные предпочтения относительно структуры кэша - пускай остаются твоими, мои - моими, а кого-то третьего - его собственными. Не надо навязывать другим свои вкусы в том, что по своей сути является вопросом вкуса. Пускай каждый делает так, как ему удобнее, а по умолчанию, мне кажется, лучше оставить всё, как есть.

И вообще, я не понимаю, почему тебе так не нужна прозрачная двойная кавычка??? Я набираю в Google поиск по точной фразе: "hydrogen bonding of methanol". В результате генерируется на диске файл:
hl=ru&q=``hydrogen+bonding+of+methanol``&btnG=Поиск+в+Google&lr=
Причём исходный URL был куда менее понятен. А тут - всё ясно, как божий день! И не только к google это относится, но и к любым другим посковикам на любых сайтах! Двойная кавычка - общепринятый морфологический признак задания точного вхождения! Она несёт большую смысловую нагрузку, зачем её оставлять нечитабельной???

Нет там никакого языка. Есть только байты. Система сама решает - как их интерпретировать. Это задается кодовой страницей.
Раньше использовался однобайтовый код. По умолчанию, CP437. Мы его можем увидеть на синем экране смерти у русской Windows. В локализованных DOS вручную подключалась кодовая страница CP866. Именно ее мы тут называем кодировкой DOS. Именно она используется для кодирования русских букв в имени файла. Начиная с DOS 7.0 в FAT, для каждого файла в каталоге пишется две записи. Одна для короткого имени в формате 8.3. Другая для длинного имени. И тут уже символы кодируюся двумя байтами кодировки UTF-16LE. В NTFS Юникод имеет приоритет и короткое имя иногда вообще не сохраняется.

Ты проверял?

Не бойся. Алгоритм URL2Cache работает уже после срабатывания списка Преобразование URL. Так-что ты ничего не потеряешь. Хочешь двойную кавычу - используй.

Дело в том, что мы решили не декодировать символ ударения `, а если он случайно встретился - превращать его в код %60. Это имеет основания под собой, но, если я попытаюсь кодировать двойную кавычку двумя символами ударения, оба они превратятся в коды %60 - в соответствии с новыми правилами. Именно поэтому я так настаиваю на двойной кавычке и не обращаю внимания на символы <>, которые я тоже хочу прозрачно кодировать, но новые правила мне нисколько в этом не мешают.

Интересно, на синем экране смерти и в последних версиях NT (2000 и XP) тоже используется эта кодировка? Вот почему он всегда нечитабельный...
То есть можно и под и под FAT и под NTFS декодировать полный набор символов Юникода? А под Linux это будет работать (тут есть энтузиасты, использующие HC под Linux)?

Теперь у меня уже возникли сомнения, что не мешают. Предложенный мной способ кодирования:
символ < (и %3c) как #{
символ > (и %3e) как #}
может взаимодействовать с отбрасыванием всего, что идёт после символа #, которое в самом начале Алгоритма URL2Cache выполняется на всякий случай. Самовольное кодирование любых символов через знак #, таким образом, будет иногда приводить к потере и самого символа, и всего, что идёт после него. Такое поведение, видимо, было и раньше. Было бы желательно "на всякий случай" отбрасывать всё, что идёт после символа # - ещё до Преобразования URL, а не после...

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

Получается что так. Но надо проверить.

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

Серьёзно? Ну слава богу... а то я уж решил, что и здесь подстава... Не так всё плохо, так что настаиваю по-прежнему только на кодировании двойной кавычки, поскольку её закодировать наиудачнейшим способом через "Преобразование URL" при новых правилах уже не получится, а очень бы хотелось... Да и зачем вообще делать что-то непрозрачно, если можно сделать просто и ясно???

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) -> #{ #} или #( #) - аналогично

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

Сергей
нет еще, но файлы с именами из японских иероглифов создаются :)

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

Я не понял. Можно или нельзя? Если иероглифы сохраняются, значит можно?

я произвольно переименовывал в тотале, работает, алгоритм еще не писал...

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

нашел немного
http://ru.wikipedia.org/wiki/Символы,_представленные_в_Юникоде
попытаюсь разобраться... :search:

Windows знает все символы, т.к. она понимает юникод.
Проблемы возникают со старыми программами, которые его не понимают. Например, FAR.
HC к ним не относится :)

Да не такой уж громоздкий код, чёрт побери! Ничего сложного! уж наверное и с `` этот код будет работать отнюдь не медленнее, чем Чёрный список HC с сотней правил, среди которых встречаются и такие:Просто при обратном преобразовании надо вначале заменять все коды `` на %22 - и только потом обрабатывать прописные и строчные буквы! Никаких проблем я здесь не вижу - и об усложнении кода говорить просто смешно! Так что это была и в самом деле гнилая отговорка!

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

Кстати, v0lt, я очень надеюсь, что в алгоритме URL2File ты при кодировании заглавных букв не превращаешь их в строчные? Это была бы лишняя работа процессора, смысл которой - только сделать менее читабельным кэш!

Кстати, обнаружил, похоже, 1 ошибку и 1 глюк в текущей реализации алгоритма URL2File.
Глюк очень простой: HC почему-то игнорирут переадресацию (файл #m), когда получает от браузера запрос. Вот пример:
Зайдите по ссылке:
http://www.goupsoft.com/ezsavemht
Если заходите в первый раз, то сервер переадресует на
http://www.goupsoft.com/ezsavemht/
и страница отобразится правильно.
Теперь, ключив, например Автономный режим (или режим Не обновлять ".*"), попробуйте зайти по первой ссылке снова - HC не переадресует, как это делал сервер, и перед вами откроется страница с неправильным URL http://www.goupsoft.com/ezsavemht на которой будет отсутствовать часть картинок!
А отсутствовать они будут потому, что внутри кода страницы ссылки на них оформлены так:
И если в адресной строке 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\#_
То есть возникает неоднозначность обратного декодирования. Если это так, то это - ошибка!

popkov
принемается, отговорка была не очень... устал наверное...

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

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

Немного не так
../ezsavemht/ -> ..\ezsavemht\#_ - получалось пустое имя файла, добавили #_
../ezsavemht -> ..\ezsavemht  - файл без расширения
Проблема в том, что нельзя создать папку и файл с одинаковыми именами, но способ обхода глюка уж очень извращенный получается, радует что такое почти не встречается...

PS: вот тут когда-то все начиналось - http://forum.ru-board.com/topic.cgi?forum=31&topic=9261 :)

Похоже, ты и правда устал. Иногда и отдых нужен.
А вот #m удалять не нужно - как раз наоборот, его нужно искать в первую очередь, чтобы была хоть какая-то возможность быть переадресованным на нужный URL - иначе страница будет неправильно отображаться (см. мой детальный пример  (http://handycache.ru/component/option,com_smf/Itemid,10/topic,78.140/#msg3403)). Это связано с относительными ссылками на картинки в коде страницы - такая относительность является обычным делом! Исключением скорее являются сайты, где ссылки в коде страницы абсолютные!
И поэтому наличие или отсутствие знака "/" в конце URL отображаемой страницы оказывается принципиальным моментом в том, откуда будет пытаться браузер загрузить картинки, содержащиеся в коде страницы.
А причина, почему это до сих пор не всплывало - редко бывают неправильные ссылки на страницу, в конце которых опущен символ "/". Однако именно неправильную ссылку я встретил на другой странице того же сайта, которая и привела меня к обнаружению сего глюка!
Надо просто в первую очередь выдавать файл с переадресацией - файл #m!
Неужели ничего нельзя придумать?

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

Проверил: HC переименовывает файл ezsavemht в ezsavemht#_, и далее создаёт папку ezsavemht. Интересно!

И ещё один важный момент: 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 - отображается и работает неправильно!
 :'(

Выходит, автор HC уже и без нас наполовину решил описанную проблему - а мы даже и не догадывались!
mai62 Respect!  (http://i.ru-board.com/s/applause.gif)
И ничего "извращенского" в таком решении я не вижу - вполне логичное и простое решение!

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

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

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

Эти тонкости тоже являются частью обсуждаемого алгоритма.

Ну я и v0lt - точно!
Полностью согласен!

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

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

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

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

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

Если найден файл - выдаём его
Если найдена папка - ищем (не залезая в неё!) файл с суффиксом #_ (в нашем случае это ezsavemht#_) и выдаём его
Если ни того, ни другого не найдено - выдаём сообщение, что файла нет в кэше!

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

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

обычный файл будет новее редиректа, если HC будет проверять время (или удалять старый), то проблемы быть не должно.
(естественно такой урл не должен попадать в списки "Не обновлять" и "Только из кеша")

В новой версии гарантия будет (если не брать в счет "Преобразование URL" и косяки IE).

Сам не проверял, но полагаю такое может быть для совместимостью с первыми версиями HC

В том-то и дело, что лезет! Я выше писал об этом:
И предложил способ решения проблемы!
Гарантия будет, только если разберёмся с глюками!
В текущей реализации алгоритмя URL:
http://www.goupsoft.com/ezsavemht
http://www.goupsoft.com/ezsavemht/
отображаются в один и тот же файл
.../ezsavemht/#_
что не только не есть good, но противоречие всякой логике и явный глюк!

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

вообщем это к 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 в сдучае, когда символ запрещен в имени файла).

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

PS: на этой неделе времени почти нет... , до дельфи доберусь только на следущей...

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

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

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

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

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

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

Сам никогда не встречал таких (или просто не обращал внимания). Если не сложно, приведи пример, плиз.
В свою очередь, знаю, что в сети полно URL подобного, к примеру, рода:
site.ru/...?...&url=http%3A%2F%2F...%2F...
Или, скажем, в поисковике задан запрос с символами () или любыми другими специальными.
1. Это должна понять процедура сравнения фиксенного исходного URL и URL, получаемого из имени файла.
2. Думаю, сойдет. Мне, по крайней мере, не йдет на ум пример, когда это может отрицательно повлиять :)

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

После длительного обсуждения решено было не декодировать код http%3A%2F%2F по двум причинам:
1) Декодирование слэша "/" может приводить к серьёзным глюкам в виде неоднозначности декодирования/кодирования (причём одновременно!)  (http://handycache.ru/component/option,com_smf/Itemid,10/topic,78.msg2692/#msg2692) - и к тому же создаёт слишком много подпапок, что заведомо снизит эффективность работы с винчестером и скорость работы HC.
2) http:// представляют в виде http%3A%2F%2F не просто так! Обычно это имеет место, когда Referer или сайт, куда производится перенаправление нужно передать скрипту сайта в виде параметра. Причём синтаксис параметров скрипта подразумевает использование в качестве разделителей символов ;:/=& - и декодирование любого из них может привести к неправильной работе скрипта (а они в качестве разделителей, естественно, используются в незакодированном виде, так что мы не будем знать, был данный символ закодирован или нет, если будем всё подряд декодировать).

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

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

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

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

Кодируют. Это факт. Например, делают это в параметре &login=. Но не только, есть еще много примеров.
На мой взгляд, процедура FixURL должна выполняться сразу, до проверки любого списка, а не после "Преобразования URL" (http://handycache.ru/component/option,com_smf/Itemid,10/topic,78.msg3096/#msg3096). Тогда и наши правила супостатам обойти не удастся  :P

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

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

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

Символы / и ? мы решили не декодировать во избежание глюков (http://handycache.ru/component/option,com_smf/Itemid,10/topic,78.msg2692/#msg2692).

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

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

А пока у меня в Переадресации есть 2 правила:Первое из них позволяет избежать повторного кодирования символа %, используемого при кодировании символов (часто встречаются URL с двойным кодированием, например символ ` оказывается записан как %2560, а не как %60 - бесполезное удлинение URL, на мой взгляд - и невозможность в некоторых случаях "отловить" баннерные ссылки). Делается проверка, что в данном случае речь идёт именно о повторном кодировании, а не просто о закодированном символе %, декодирование которого иногда может оказаться нежелательным (насколько я понимаю - хотя хотелось бы выяснить это точнее).
Кстати, кто-нибудь знает, есть ли какие-либо стандарты на повторное кодирование символов в URL? На каком этапе какие символы кодируются? Насколько я понимаю, бывает и 3 и 4 перекодирования - но символ % в кодах символов кодируется именно при втором кодировании, и кодов %252525 в логах не встречается, хотя %2525 - обычное дело!
Второе я написал недавно - это фикс кодированной точки!

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

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

Да, Microsoft в отношении мутности - впереди планеты всей!
Впрочем, я думаю, в данной ситуации можно и без RegExp обойтись! Первый символ - знак %, далее может идти только символ из диапазона 0-9 или A-F. Далее - то же самое, только надо всю найденую последовательность загнать в соотв. переменную - и далее последовательно для каждого символа из этих трёх выполнить преобразование регистра (как я понял, в Delfi есть соотв. ф-ция). Если бы я программировал на Delfi - просто написал бы соотв. код. Но программирую я на совсем другом языке, так что консультировать не могу. Хотя RegExp, тем более компилированный, на Delfi работает очень быстро (пример - HC) - так что разницу в производительности никто не заметит.

Полный перечень зарезервированных символов (все они могут выступать в качестве разделителей):
:/?#[]@!$&'()*+,;=
Эти символы нельзя заменять на их коды и наоборот, иначе можем получить совершенно другой URL.
Кстати, кто-нибудь знает, есть ли какие-либо стандарты на повторное кодирование символов в URL?
Повторное кодирование не допускается. Выражение типа %2525 может иметь место, если задать, к примеру в Яндексе поиск строки "%25". Здесь тоже кодирование одно и не "наслаивается".

Ты уверен? А почему тогда это так часто встречается?
Вот результаты поиска в логах по шаблону
%25[a-f\d]{2}

TOTAL:    33060 matches in 131 groups in 112 files
    8605  %25D0
    3052  %25D1
    1643  %252F
    1260  %2520
    1083  %25BE
    1064  %25BD
    1011  %25B5
     978  %253D
     956  %25B8
     785  %2526
     763  %25B0
     716  %2580
<... skipped ...>

Примеры:

http://www.google.ru/search?hl=ru&newwindow=1&q=%25C2%25A0&lr=

http://ru.wikipedia.org/wiki/%25D0%25AD%25D0%25BC%25D0%25B8%25D1%2580_%25D0%259A%25D1%2583%25D1%2581%25D1%2582%25D1%2583%25D1%2580%25D0%25B8%25D1%2586%25D0%25B0

http://c.microsoft.com/trans_pixel.asp?source=msdn&TYPE=PV&p=workshop_components_offline&URI=%2flibrary%2ftoolbar%2f3.0%2fasp.aspx%3fmode%3dhead%26c%3d%2fnonlibraryshell.config%26h%3dmsdn%252Emicrosoft%252Ecom%26u%3d%252Fworkshop%252Fcomponents%252Foffline%252Foffline%252Easp%26r%3dhttp%253A%252F%252Fmsdn%252Emicrosoft%252Ecom%252Fworkshop%252Fdelivery%252Foffline%252Flinkrel%252Easp%253Fframe%253Dtrue&GUID=1F4FC18C-F71E-47FB-8FC9-612F8EE59C61&r=http%3a%2f%2fmsdn.microsoft.com%2fworkshop%2fdelivery%2foffline%2flinkrel.asp%3fframe%3dtrue

http://support.microsoft.com/LTS/default.aspx?SSID=1&SiteLCID=1049&EventCollectionID=1&URL=%2fdefault.aspx&ContentType=kb&ContentLCID=1049&ContentID=910337&BrowserWidth=1024&BrowserHeight=580&BrandID=1&RefURL=kb%7c1049%7c842309%7cundefined%7cundefined%7chttp%3a%2f%2fwww.google.ru%2fsearch%3fhs%3dvb5%26hl%3dru%26client%3dfirefox-a%26rls%3dorg.mozilla%253Aru%253Aofficial%26q%3d%25D1%2584%25D0%25BE%25D0%25BD%25D0%25BE%25D0%25B2%25D0%25B0%25D1%258F%2b%25D0%25B8%25D0%25BD%25D1%2582%25D0%25B5%25D0%25BB%25D0%25BB%25D0%25B5%25D0%25BA%25D1%2582%25D1%2583%25D0%25B0%25D0%25BB%25D1%258C%25D0%25BD%25D0%25B0%25D1%258F%2b%25D1%2581%25D0%25BB%25D1%2583%25D0%25B6%25D0%25B1%25D0%25B0%2b%25D0%25BF%25D0%25B5%25D1%2580%25D0%25B5%25D0%25B4%25D0%25B0%25D1%2587%25D0%25B8%2b%25D0%25B7%25D0%25B0%25D0%25B3%25D1%2580%25D1%2583%25D0%25B7%25D0%25BA%25D0%25B0%2b%25D0%25BE%25D0%25B1%25D0%25BD%25D0%25BE%25D0%25B2%25D0%25BB%25D0%25B5%25D0%25BD%25D0%25B8%25D0%25B9%26btnG%3d%25D0%259F%25D0%25BE%25D0%25B8%25D1%2581%25D0%25BA%26lr%3d&OptionCollectionId=0&EventSeqNo=6&FlexID=&FlexValue1=&FlexValue2=&FlexValue3=&FlexValue4=mozilla%2f5.0%20%28windows%3b%20u%3b%20windows%20nt%205.0%3b%20ru%3b%20rv%3a1.8.1%29%20gecko%2f20061010%20firefox%2f2.0&FlexValue5=

Если задать  в google поисковую строку "%C2%A0", то получим первый из указанных URL. Здесь %C2%A0 совершенно справедливо воспринимается как строка, а не как закодированные данные.
Остальные URL-ы нерабочие (по крайней мере у меня в Опере).

Михаил
Дело в том, что я не пишу URL в логи - их туда пишет HC!
И если теперь уже по запросу
 http://\S*%25[a-f\d]{2}\S*
в моих логах нашлось 1407 уникальных URL - это о чём-то говорит!

А насчёт нерабочих - вот рабочие (проверил!):

http://tbn0.google.com/images?q=tbn:P4qJidTTzOytPM:http://www.gg2.net/upload/Bill%2520Gates.jpg

http://tbn0.google.com/images?q=tbn:lLWcsYS6Mny9wM:http://www.bobbyworks.com/images/mug%2520shot%2520bill%2520gates.jpg

http://tbn0.google.com/images?q=tbn:zaDHv3KYcikJrM:http://e-consultancy.lemonfoundation.com/people/bill%2520gates,%2520dude.jpg

http://login.live.com/login.srf?lc=1033&id=1929&ru=http%3A%2F%2Fwww%2Emsnusers%2Ecom%2FDAV%5FLoginReturn%2Emsnw&tw=43200&kv=9&ct=1173608778&cb=wsredir%3Dhttp%253A%252F%252Fwww%252Emsnusers%252Ecom%252Fdav%252Emsnw%253Furi%253D%252F%252F&ems=1&kpp=1&ver=2.1.6000.1&rn=eWxErFnD&tpf=68e5347da98a85393cf5d57e6a146172

http://pics.imho.ru/Intel/Pro_Brand_apr-dec2006/04.12.06-18.12.06/200x350_lineup.swf?fdomain=citforum.ru&link1=http//body.imho.ru/event.ng/Type=click&FlightID=24294&AdID=29774&TargetID=18001&Segments=18371&Targets=18001&Values=25%2C30%2C46%2C50%2C60%2C72%2C82%2C92%2C100%2C110%2C150%2C254%2C1157%2C3842%2C4917%2C4919%2C4925%2C6649%2C7496%2C8086&RawValues=USERID%252C5113500c-2109-1164712039-1%252CGIPCOUNTRY%252CRU%252CGIPCITY%252CMoscow%252CGIPREGION%252C48&Redirect=http%3A//www.intel.com/business/enterprise/emea/rus/vpro/index.htm%253Fppc_cid%253DmrmRU2F

http://top.list.ru/counter?id=66377;t=56;js=13;r=http%3A//www.google.ru/search%3Fhl%3Dru%26q%3Dhp+ipaq+hx2410%26btnG%3D%25D0%259F%25D0%25BE%25D0%25B8%25D1%2581%25D0%25BA+%25D0%25B2+Google%26lr%3Dlang_ru;j=true;s=1024*768;d=32;rand=0.7943153505349431

http://pics.rbc.ru/rbcmill/img/cddvnpahs/fegbhbkgfusj/170-200_3.swf?link1=http%3A//banner.rbc.ru/banredir.cgi%3Fsid%3Dfirstpage_left2.20070215115319.46171%26lid%3Dfirstpage_left2%26id%3D46171%26code%3D%21http%253A%252F%252Fwww.rt.ru%252Fcorporate%252F&seed=56280

http://love.mail.ru/tips/?tip=WinkLogined&tcurl=http%3A%2F%2Flove.mail.ru%2Fmy%2Fmessage.phtml%3Faction%3DWink%26oid%3D6950733%26tcurl%3Dhttp%253A%252F%252Flove.mail.ru%252Fkc_20%253F1%253D1%2526sold%253DEqHZFC6IdPHBig8aqSGaRJ-2M__YhTdx%2526afolder%253Dself%2526winked%253D1&tburl=http%3A%2F%2Flove.mail.ru%2Fkc_20%3F1%3D1%26sold%3DEqHZFC6IdPHBig8aqSGaRJ-2M__YhTdx%26afolder%3Dself

Список можно продолжать...

Всех их объединяет одно - кодируется текстовый параметр (строка). Попробуй зайти на URL http://www.gg2.net/upload/Bill%2520Gates.jpg из первого примера - не получится. Когда речь идет о строке, обработчик воспринимает %20 не как код, а как осмысленное сочетание символов. В свою очередь, если любой URL из приведенных будет передаваться в качестве текстового параметра скрипта еще кому-нибудь, получим значения типа %252520.
А вот происхождение в твоем кэше URL
http://ru.wikipedia.org/wiki/%25D0%25AD%25D0%25BC%25D0%25B8%25D1%2580_%25D0%259A%25D1%2583%25D1%2581%25D1%2582%25D1%2583%25D1%2580%25D0%25B8%25D1%2586%25D0%25B0
интересно. Могу предположить, что он образовался также из текстового параметра скрипта при помощи списка "Переадресация" путем отсечения "вызывающего" URL.
С учетом всего этого, правило, преобразующее код типа %2525 в %25, на мой взгляд, лучше не использовать.

Обе ссылки нерабочие :(

Тут ты немного нарушил логику: из того, что закодированный повторно URL обрабатывается неправильно не следует, что противоположная ситуация - когда декодированный URL находится в виде параметра скрипта на месте закодированного - тоже будет обрабатываться неверно!
Попробуй зайти по ссылке:
http://tbn0.google.com/images?q=tbn:P4qJidTTzOytPM:http://www.gg2.net/upload/Bill%20Gates.jpg
- она обрабатывается сервером нормально, хоть я и декодировал знак процента!

Следует, что иногда он будет обрабатываться неверно. А этого, имхо, достаточно, чтоб такие правила не вводить. Рассмотрим пример, когда в поисковике надо найти строку "xyz%45". Поисковик сформирует URL с параметром xyz%2545. Если затем мы обрежем "25", то получим "xyz%45" и с таким URL в следующий раз попадем совершенно на другую страницу - на результаты поиска строки "xyzE".

PS У меня в списке "Переадресация" есть правило .+(url|go)=http заменять на http. В свете нашего общения начинаю склоняться к мысли, что для правильной его работы необходимо добавить в белый список правило (url|go)=http.*%25 с запретом переадресации.

С примером согласен, но не слишком ли он искусственен? Кому придёт в голову искать "%45" - тем более, что при таком поиске Google отбрасывает знак % - и ищет вхождения "45"? Не единственный ли это случай, когда такое может происходить?
Думаю, здесь ты прав! На RU-Board как-то обсуждалась ситуация, когда это правило неправильно работало, если знак двоеточия закодирован. В той ситуации оно всё же должно было сработать, поэтому я доработал это правило так:
#5#~#True#~#.+&(url|go)=http(:|%3a)//#~#http://#~#False#~#True
#5#~#True#~#.+/go.php\?http(:|%3a)//#~#http://#~#False#~#True
Такие правила правильно сработают в описанной тобой ситуации. Хотя, если честно, они кажутся мне наименее полезными и наиболее сомнительными из всех правил по умолчанию. Пока глюков не замечал - поэтому держу их включёнными! Попаданий довольно мало.

На мой взгляд, мы немного ушли в сторону :)
Краткое резюме по функции fixURL.
Итак, при формировании исправленного URL (процедура FixURL) делаем следующее (в указанном порядке):
  - отсекаем "http://", а при включении соотв. опции - и "www."
  - переводим буквы в кодах в верхний регистр;
  - коды %41-%5A, %61-%7A, %30-%39, %2D, %2E, %5F, %7E преобразовываем в соответствующие им символы;
  - переводим все символы имени хоста в нижний регистр;
  - site.ru:XXXX<конец> заменяем на site.ru:XXXX/
  - (www.)site.ru<конец>
    site.ru:<конец>
    site.ru:/
    site.ru:80/
заменяем на site.ru/.

Все это делаем до начала проверки списков.

Кроме этого, убираем опцию "Удалять ссылку на порт 80 из имени файла в кэше" в Настройках/Кэш/Управление, т.к. в ходе работы удаляем ссылку на порт 80 всегда.

Отлично! Со всем согласен, только не совсем понял, какой бывает <конец>  в
site.ru:XXXX<конец>
(www.)site.ru<конец>
site.ru:<конец>

Имел в виду, что URL site.ru:8787 преобразуется в site.ru:8787/
site.ru - в site.ru/
site.ru: - в site.ru/
Под тэгом <конец> имел в виду, что на этом URL заканчивается, далее ничего нет (т.е. что это полный URL, а не начало другого более обширного URL). Сорри, если не совсем понятно получилось. Проще будет так:
  - site.ru
    site.ru:
    site.ru:/
    site.ru:80
    site.ru:80/
заменяем на site.ru/.
 - site.ru:XXXX заменяем на site.ru:XXXX/

Теперь понятно. Только обнаружил одно НО: отбрасывать http:// надо после Переадресации, чтобы сохранялась возможность переадресовывать на другой протокол (например, FTP://) Насколько я понимаю, именно для этого автор и не стал отбрасывать http:// в Переадресации.
Хотя можно и иначе: отбрасывать ДО Переадресации, но, чтобы можно было перенаправить на другой протокол, в Переадресации (в обоих полях: Правило и Замена) делать проверку на наличие отличного от HHTP протокола (чтобы не быть ошибочно переадресованным на http://ftp://site.ru). Например, можно легко отловить название протокола правилом (RegExp):
^\w+://
При условии, что FixURL уже применён, такое простое правило безошибочно отловит все ссылки на другой протокол! И не поймает ничего лишнего!
Думаю, второй вариант даже предпочтительнее первого (который реализован в текущей версии HC).

Да, забыл про отсечение фрагментов. Итого FixURL:
  - отсекаем все, начиная с первого "#"
  - отсекаем "http://", а при включении соотв. опции - и "www."
  - переводим буквы в кодах в верхний регистр;
  - коды %41-%5A, %61-%7A, %30-%39, %2D, %2E, %5F, %7E преобразовываем в соответствующие им символы;
  - переводим все символы имени хоста в нижний регистр;
  - site.ru
    site.ru:
    site.ru:/
    site.ru:80
    site.ru:80/
заменяем на site.ru/.
  - site.ru:X заменяем на site.ru:X/

Только после Переадресации... См. мой предыдущий пост... Причём всё, что там написано, относится и к www. перед именем хоста! Иногда важно переадресовывать ссылки с www. на адреса без него! И наоборот! Это действительно важно! Иногда сайт существует в двух видах: c www. и без него! И когда залогинивешься на сайте без www., оказывается, что на его варианте с www. ты не залогинен! Единственный способ обойти этот глюк - использовать Переадресацию! Что я и делаю! Поэтому ДО Переадресации нельзя отбрасывать ни то, ни другое! Ни в коем случае!

....С остальным полностью согласен!

В моих глазах `` однозначно лучше #', а остальные одинаково приемлемы.

Наконец-то в этой теме слышу высказывание в пользу ясности и здорового вкуса! (http://i.ru-board.com/s/jump.gif)

Спасибо! (http://i.ru-board.com/s/smile.gif)

Михаил
popkov
В моем алгоритме "http://" отбрасывается для удобства (неважно какой введен урл с "http://" или без) и для последующего сравнения результата.

Если после Fix_URL() будет "Переадресация", то естественно отбрасывать не следует. Хотя и не факт стоит ли вообще Fix_URL ставить до Переадресации.

Поясню. Если мы сильно исправим урл (Михаил: - коды %41-%5A, %61-%7A, %30-%39, %2D, %2E, %5F, %7E преобразовываем в...) и у нас сработает Переадресация, то браузер запросить у сервера такой урл, который тот не найдет у себя.
(вышеприведенные коды допустимы и сервер может ждать именно их, а не соответствующие символы).

Новая версия алгоритма:
измения v1.3 beta 3:
- в коде появились регулярные веражения  ::)
fix_URL:
- коды вида %XX всегда в верхнем регистре
- после имени хоста отбрасывается ":80" и ":" (пустой порт)
URL2File:
- заглавные буквы (A..F) в кодах %XX не помечаются
File2URL:
- коды вида %XX переводятся в верхний регистр

Это те символы, которые как ни меняй их на коды и обратно - получим полностью эквивалентный URL, и запрос будет гарантированно отправлен туда же и с теми же параметрами и так же понят сервером. Потому и в FixURL гарантированно можно заменять коды только этих символов, а все остальное будет при необходимости заменять URL2FileName.
А если правило в Переадресации прописывать криво, то и сейчас не попадем по желанному адресу (но я не думаю, что ты это имел ввиду).
Если же я чего не так понял, приведи, плиз, пример.

Теперь про хттп://. Если я правильно представляю, оно отбрасывается и сейчас при проверке любого списка, кроме Переадресации. Хотя на практике с такой необходимостью я не встречался, но смысл оставления http:// для Переадресации теоретически может иметь место. Пусть так все и останется в отношении отрезания http://. Т.е. до проверки всех списков нормализуем URL с помощью процедуры FixURL без отрезания http://. "Переадресации" отдаем этот нормализованный URL, а остальным спискам - его же без ведущего http://.

Только вот непонятно при всем этом еще одно: если список "Переадресация" чувствителен к http://, то как может быть нечувствителен к нему Белый список, в котором мы прописываем исключения для "Переадресации"? Имхо, это недоработка.

набри в гугле HandyCache%41 получишь в ответе страницы со строками "HandyCache" и "41", и нигде не увидешь выделенное значение кода %41

Пусть мы имеем урл
http://site.com/r?http://www.google.ru/search?hl=ru&q=HandyCache%41&btnG=Поиск&lr=
и Переадресацию убирающую http://site.com/r?
тогда если мы трогаем эти коды, мы получим http://www.google.ru/search?hl=ru&q=HandyCacheA&btnG=Поиск&lr=
... другую страницу

Мы говорим не о строке поиска Google, а об URL. А он будет содержать параметр не HandyCache%41, а HandyCache%2541.
Проверь на практике - получим ту же самую!
Посмотри rfc3986 п.2.3:

Михаил
Клянусь :D
зашел на http://www.google.ru/ig?hl=ru
ввел HandyCacheA, а гугл меня спрашивает "Возможно, вы имели в виду: Handycache"
А я ему HandyCache%41 и надо же, нашел!
Если надо скриншоты сделаю :)

PS: Если заходить по ссылкам, то HandyCache%41 превращается в HandyCacheA, а вот если прямо на странице вводить, тогда результат разный получается.

Написано логично, но не все его читали :(

При чем тут строка google, никак не пойму. URL-ы при этом совершенно разные. Разные URL-ы (разные, заметь, не различием А - %41) - разные результаты. Имхо, один из нас путается. ;)

Можно просто привести две эти ссылки:
Поиск в Google строки "HandyCache%41" (http://www.google.ru/search?hl=ru&newwindow=1&q=HandyCache%2541&lr=)
Поиск в Google строки "HandyCacheA" (http://www.google.ru/search?hl=ru&newwindow=1&q=HandyCacheA&lr=)
Совершенно очевидна правота Михаила. В первом случае предлагаемый им FixURL ничего не изменит в URL, во втором - тоже. Они останутся такими, какие есть, если не декодировать код %25.

Насчёт того, что Internet Explorer в строке состояния отображает первую ссылку в декодированном виде (символ процента не закодирован %25) - это просто свойство IE - он для удобства пользователя декодирует коды символов! Это, кстати, очень удобно! Только он почему-то "не догадывается" в строке состояния о существовании кодироваки Win-1251 - все русские буквы в строке состояния декодирует кракозябрами... Очередной глюк IE.

volt
В URL->FileName для чего кодируем знак "?" не везде одинаково, а двумя разными вариантами - "^\" и "#^"?

Первый знак вопроса указывает что дальше пойдут т.н. параметры. Поэтому мы их отделяем в отдельную папочку с помощью "\" (сочетание "^\" сложилось историчеки).

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

Volt
Спасибо. Т.е. кодируем "^\" только первый знак вопроса, сколько бы этих знаков вопроса ни было. Просто в xls-файле не очень понятно вышло насчет кодирования знака "?" до и после знака "?", потому и вопрос возник. Фу ты каламбур какой-то  :)

В процессе перелопачивания кода HC_Explorer-а, решил чуток изменить алгоритм.

Новая версия алгоритма:
измения v1.3 beta 4:
- Теперь папки, в которых сортируются домеы, помечаются точкой вместо символа подчеркивания.
Например: ".a" вместо "_a".
Это сделано для лучшей совместимости старых приложений работающих через движок IE. Причина в том что IE не работает с неправильными урлами вида _s/site.com/, он просто не посылает соответствующий запрос прокси-серверу. С урлами вида .s/site.com/ такой проблемы нет.
Что бы HC автоматически переходил с .s/site.com/ на site.com/ в переадресацию следует прописать след. правило:
#5#~#True#~#^http://\.\w/#~#http://#~#False#~#True"

PS: Для тех у кого опера. Проверте пожалуста в каком виде она отсылает урл http://.s/site.com/ , что отображается в мониторе HC?

файлики к посту выше...

У меня exe выпадает с ошибкой, не запускаясь: "Ошибка при инициализации приложения (0хс00000135). Для выхода из приложения нажмите кнопку "ОК".

Михаил
странно, я в коде поменял только символ "_" на "." в двух местах
завтра проверю на работе...

Volt
А на другом компе запускается без проблем. Непонятно.

Если предыдущая версия работает, то можешь тестить её (разница там лишь в первом символе при сортировке по домену).

Если вообще никакая версия не работаетб капай в сторону .NET v2.0 (сравни версии). У меня все нормльно...

Глюк взаимодействия с файловой системой обнаружил...
Если имя папки с точками на конце (например Other...) - то винда такую папку не создаёт...

Она и не создаст :) А если особыми методами создать - то и удалить не получится. Ну глючит ФС винды на точках :)

Хорошо бы учесть этот баг Винды с точками в будущем алгоритме преобразования URL...

Дем
DenZzz
проблема решаема аналогично "\" на конце
путь\ -> путь\#_
путь. -> путь.#_
путь  -> путь #_ (для случая если %20 был заменен на пробел)

PS: описано в URL2filename_ver1_3beta4.xls, базовая часть, решение проблем. В новом алгоритме тоже реализовано.

Преобразование путь. -> путь.#_ в принципе и в текущую версию можно внедрить, проблем быть не должно.

Где лежит этот файлик?

Прикреплен к одному из постов v0lt-а выше.

Спасибо. А то я сунулся в поиск по сайту и ничего не нашел :-)

1. Иногда вместо домена в папке сохраняется IP.
2. Как можно сделать так, чтобы кэш-файлы с определенных сайтов сохранялись в отдельной папке.

Да, и в чем вопрос? Если URL запроса содержал IP, то и в кэш он запишется в папку IP.


С помощью списка "Преобразование URL".

С помощью преобразование УРЛ не выходит.

Например:
+*.сайт.ру
заменить на
папка\папка\сайт.ру

В результате программа создает папку с именем "папка\папка\сайт.ру".

Во-первых, файловая система не позволит создать одну папку с "\" в имени! Поэтому HC их автоматически преобразует в "#~".


Во-вторых, если тебе нужны подкаталоги в кэше, то не надо было коверкать слеши!
В "Замене" должно было быть так:
папка/папка/сайт.ру

P.S. Если интересуют подробности, как HC преобразует URL в путь к файлу, то читай тему: "Алгоритм преобразования URL в имя файла в кэше" (http://handycache.ru/component/option,com_smf/Itemid,10/topic,78.0/).

Спасибо. А в не кэша хранить кэш-файлы нельзя?

Можно. Это делается с помощью конструкции  "../" в начале замены. Количество элементов зависит от глубины вложенности папки кэша.
Если у тебя кэш находится в папке  C:\Program Files\HandyCache\Cache, то в начале замены надо вставить конструкцию:  ../../../ для возврата в корень диска C:\ , а следом уже пойдет новый путь к файлу.

Пока кэш небольшой, и его еще не очень сложно поправить, хотелось бы более точно знать алгоритм
преобразования и выяснить некоторые вопросы, косвенно касающиеся этой темы.

Не нашел описание применения файлов с расширением *.cnk, или оно больше не используется ?

URL во время загрузки записывается во временный файл с расширением .new, при успешной загрузке
или обрыве связи (если конечный размер файла не известен) расширение .new отбрасывается, а при
неудачной загрузке файл удаляется ?
При загрузке адрес-d/имя-f.new запишется во временный  файл адрес-d/имя-f.new.new, а после
загрузки будет переименован в адрес-d/имя-f.new, но удален не будет ?
Если по адресу адрес-d/имя-f находится другой файл, то во время загрузки он перезапишет
адрес-d/имя-f.new и затем будет переименован в адрес-d/имя-f ?

Cоздаваемые папки имеют приоритет перед существующими файлами ?:
Если HC при создании папки обнаружит что уже есть файл с таким же именем, то файл будет
переименован в имя#_ , и доступ к нему будет утрачен?
Если при создании файла с именем #m или #_ , HC обнаружит папку с таким именем, то файл
создаваться не будет?

Записал алгоритм v0.98b1 для себя (см.ниже) - подскажите где наврал.
Вышло уже несколько новых версий HC, в "ToDo" эта тема не фигурирует - возможно алгоритм уже
изменился, если да то как?
Правильно ли указана очередность по пунктам и всем их подпунктам?
При необходимости, или по глупости, можно создать правила, которые позволят обойти
встроенные в HC преобразования?

---

1. Преобразование заголовков запроса URL:
1.1. Используя серверы-посредники (скрипты LUA - luaR.lst).
1.2. Используя список "Переадресация":
1.2.1. [%25]  ->  [%]
1.2.2. [%26]  ->  [&]
1.2.3. [%2f]   ->  [/]
1.2.4. [%3a]  ->  [:]
1.2.5. [%3d]  ->  [=]
1.2.6. [%3f]   ->  [?]

2. Преобразование URL в имя файла в кэше:
2.1. Используя серверы-посредники (скрипты LUA - lua.lst).
2.2. Через чик "Удалять ссылку на порт 80 из имени файла" в настройках кэша:
       [host:80/]  ->  [host/]
2.3. Через список "Преобразование URL":
2.2.1. ["]   ->  [%22]
2.2.2. [<]  ->  [%3C]
2.2.3. [>]  ->  [%3E]
2.4. Встроенное в HC:
2.4.01. [Редирект] -> [Редирект\#m] (файл)
2.4.02. [URL\] (страница) -> [URL\#_] (файл)
2.4.03. [/]    ->   [\]      (до "?")         ->  [#%]         (после "?")
2.4.04. [//]   ->   [\~]    (до "?")         ->  [#%~]       (после "?")
2.4.05. [///]  ->   [\~\]   (до "?")        ->  [#%~#%]   (после "?")
2.4.06. [?]    ->   [^\]    (первый "?")  ->  [#^]          (следующие "?")
2.4.07. [*]    ->   [#x]
2.4.08. [\]    ->   [#~]
2.4.09. [|]    ->   [#i]
2.4.10. [!]    ->   [#I]
2.4.11. [:]    ->   [!]
2.4.12. На последнем этапе преобразования URL проверяется длина имени (относительно папки кеша).
Если она больше 200, то ищется последний символ [\] в пределах первых 192 символов.
Строка до символа [\] остается, а оставшееся кодируется хешем CRC32:
При длинне URL до 200 -> Папка кэша\URL
При длинне URL свыше 200 -> Папка кэша\[URL до 192]\[CRC32 остатка]

Больше не используется. Раньше в такой файл временно писались файлы, полученные методом "Transfer-Encoding: chunked". Со сборки 1.0.0.103 "куски" склеиваются на лету.


"Да" три раза.


Переименован будет. Доступ сохранится.


Откуда в кэше возьмется папка с именем #m или #_ ? Это невозможно.


В этой теме выкладывали файл с таблицей преобразований и исходники самой процедуры - проверь по ним.


Нет, с версии 0.98 алгоритм преобразований не менялся.


пп. 1.2.х - очередность зависит от порядка правил в списке Переадресация.
п. 2.1. - удали. Скрипты не вмешиваются на этом этапе.
п. 2.2 и 2.3 поменяй местами.
пп. 2.3.х - очередность зависит от порядка правил в списке Преобразование URL.
пп. 2.4.01 - перенеси в самый конец.


Некоторые можно, некоторые нет. Тебе для чего все это?

Жаль что свои посты нельзя редактировать.
Чтобы исключить разночтение (я некорректно задал некоторые вопросы) прошу подтвердить ответы.

Т.е. первого файла адрес-d/имя-f.new в кэше не будет?

Т.е. доступ HC к нему сохранится?

При использовании правила:
#5#~#True#~#^([^/]+)\.([^./]+\.[^./\d]+)/#~#\2/#\1/#~#False#~#True
при переходе по адресу m.site.ru будет создана подпапка #m.
За основу было взято правило из темы "Имя домена как имя папки? (http://handycache.ru/component/option,com_smf/Itemid,10/topic,980.msg8007/#msg8007)".
Изменения были внесены чтобы не возникла каша если на сайте уже есть одноименная папка.
Кандидат для таких замен искался среди всех доступных для файловой системы символов, и лучшим
оказался символ # (применяемый только для навигации по странице) и его сочетания.

Из таблиц и собирал, но там не все так однозначно как у меня, поэтому и хотел чтобы проверил
знаток HC. В исходниках не разбираюсь.

1.1. Используя серверы-посредники:
1.1.1. Скрипты LUA - luaR.lst.
1.1.2. Скрипты LUA - lua.lst.
1.2. Используя список "Переадресация"
Так правильно?

Какие можно, и как?

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

Пример того, что об этом нельзя забывать и надо помнить что встроенные в HC преобразования
не отображаются в мониторе попался буквально вчера - решил попробовать правило из FAQ
"Если вместо одних картинок вы хотите видеть другие... (http://handycache.ru/component/option,com_simplefaq/task,display/Itemid,3/catid,6/#FAQ30)".
В тренажере все в порядке, а в мониторе:Долго не мог понять в чем дело, хотел уже в форуме спросить, а потом вспомнил про встроенные
в HC преобразования:
[!] -> [#I]
[:] -> [!]
Правило стало работать когда переименовал папку в #i_null_#I.
Чтобы использовать папку !_null_! внес в правило следующие изменения:
Правило: .*/smilies/.*\.gif$  Замена: :_null_:/nullgif.gif

Не будет. Он затрется временным файлом, а потом будет переименован в файл без ".new" .


Доступ к нем будет зависеть от URL запроса. Если URL запроса будет заканчиваться не на "/", то HC будет первым искать в кэше файл "имя#_" , иначе "имя\#_" .


Не желательно использовать спец.символ HC "#" для своих собственных правил. Могут возникнуть конфликты. В частности, папку "#m" HC не сможет перезаписать таким файлом, временный файл "#m.new" осядет в кэше.


Нет. Скрипты ответов (lua.lst) не работают на этапе "1. Преобразование заголовков запроса URL", они работают уже после получения ответа сервера.
Вообще, процедура URLToCache вызывается всякий раз, когда HC обращается к дисковому кэшу. Это может происходить на самых разных этапах.


Откуда взялось "#i" ? В замене не было символа "|".

Лучше вообще не использовать в своих правилах символы, которые подлежат принудительной замене. Правило в ФАКе старое и было написано еще тогда, когда HC не трогал символ "!". Поправил ФАК.

А для кэширования иконок с разных форумов в одну папку лучше использовать правило вроде этого:
#5#~#True#~#.+/((style_)?emoticons|icons?/forum|s|smili?ey?s\d*)/(.*/)?(icon_)?(.+\.(gif|png))$#~#_Smileys/\5#~#False#~#True

Не совсем то имелось ввиду. Это когда правило оставил без изменений:
Правило: .*/smilies/.*\.gif$  Замена: !_null_!/nullgif.gif
хотел показать что регистр в имени самой папки значения не имеет, т.е. папка может называться:
#I_null_#I
#i_null_#i
#i_null_#I
или
#I_null_#i

Упустил один важный вопрос.
Под каким пунктом в моей схеме (http://handycache.ru/component/option,com_smf/Itemid,10/topic,78.msg15389/#msg15389) должно производится удаление лидирующих http:// и www. ?

Перед проверкой списка "Преобразование URL".

Куда сохраняются загрузки , если в мониторе выбрать Url и выбрать " Загрузить в кэш " ? После загрузки выбираю " Открыть каталог " , а он пустой . А загрузка то была . Порылся , где только можно , но её нет . И так всегда при выборе " Загрузить в кэш " . Какое то чудесное исчезновение .

Наведи указатель мыши на URL, должно появиться имя файла с путем.

Я это и делал . В этой папке пусто . А загрузка была .

Добрый день! Ситуация следующая:
Имеется форум вида example.ru/services/forum.do;jsessionid=E84737692F2482327AFD750221EA00BE?groupId=1372 (c динамической сессией)
Как у меня сейчас: в папке с кешем создаются папки example.ru\services\forum.do;jsessionid=E84737692F2482327AFD750221EA00BE^ , затем в последней создаётся файл groupId=1372
Что необходимо: обрезать сессию, получив в кеше вид папок example.ru\services\forum.do
В общем сессия меняется динамически, а файл в кеше должен быть всегда по одному пути, лишних папок с именами сессий не должно создаваться
Подскажите пожалуйста, как это можно реализовать?

Это можно сделать с помощью списка Преобразование URL. Посмотри эту тему http://handycache.ru/component/option,com_smf/Itemid,10/topic,337.1060/, думаю, там можно найти решение похожей задачи.

В процессе объединения двух кэшей, созданных независимо на разных компах, столкнулся с проблемой: встречаются ситуации, когда в одном кэше имеется файл с определенным именем, а в другом - папка с файлами, имеющая то же имя. Файловая система NTFS не допускает наличия на одном уровне файла и директории с одинаковыми именами. Соответственно, вопрос: как HC решает подобные противоречия:
1) Уже есть директория "name", созданная из URL http://server/name/file (http://server/name/file). Далее запрашивается URL http://server/name (http://server/name). Какой файл будет создан в такой ситуации?
2) Наоборот: есть файл "name", созданный из URL http://server/name (http://server/name). Далее запрашивается http://server/name/file (http://server/name/file). Как поведет себя HC в этом случае? Будет ли конечный результат идентичен в обеих ситуациях?

И как объединить два кэша, если в одном есть каталоги "name", созданные из http://server/name/file (http://server/name/file), а в другом - файлы "name", созданные из URL http://server/name (http://server/name)?

Файл, поступивший с URL http://server/name, получит имя cache\server\name\#_

Понятно, а во второй ситуации как?

И можно ли потом объединить два кэша: в одном есть директория "name", а в другом - лишь папка "name"? Вероятно, здесь нужен специфический алгоритм переименования файлов?

Файл "name" будет переименован в "name#_", потом будет создана папка "name".

Все это уже обсуждалось! Ищи в этой теме. Тут есть даже кусок кода HC, который делает подобные преобразования.

mai62
Можете выложить актуальную версию юнита UrlToCache?