HandyCache форум

Главная категория => Общие вопросы => Тема начата: Сергей от 12 января 2007, 15:39:16



Название: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 12 января 2007, 15:39:16
В документации не хватает подробного описания алгоритма преобразования URL2File.
Со всеми ньюансами, типа работы с дополнительными папками кэша.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Дем от 12 января 2007, 16:31:32
В документации не хватает подробного описания алгоритма преобразования URL2File.
Со всеми ньюансами, типа работы с дополнительными папками кэша.
Ну вот что экспериментально нашёл:

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 13 января 2007, 14:07:56
DenZzz

Цитировать
но это уже частность...

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

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

Как говорится :)
Цитировать
Лучше один раз сделать правильно, чем потом переделывать.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 13 января 2007, 14:30:39
Сергей

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: mai62 от 13 января 2007, 22:51:57
Сергей
Цитировать
Поэтому я просил выложить в паблик алгоритм преобразования чтобы всем вместе его обсудить, найти недоработки и исправить их до финала.
Смотри вложение


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 14 января 2007, 01:37:10
Сергей (aka Сергей Кузнецов, ака COUSIN)

Цитата из ToDo: (http://handycache.ru/component/option,com_smf/Itemid,10/topic,20.0/)
Цитировать
Предлагаю тогда "!" тоже заменять на что-нибудь другое. Чтобы устранить неоднозначности. (C0USIN)

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


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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Дем от 14 января 2007, 17:54:07
Кусок из моего...
Код:
    Private Function URL2FName(ByVal Url As String) As String
        Dim s As String
        If Url.EndsWith("/") Then Url &= DefFName
        URL2FName = Url.Replace("?", "^/").Replace("%3f", "^/").Replace("<", "#(").Replace(">", "#)").Replace("""", "#'").Replace("*", "#x").Replace("!", "#I").Replace(":", "!").Replace("|", "#i")
        If (MenuRepSl.Checked) Then
            Dim iq As Integer = URL2FName.IndexOf("^/") + 2
            If (iq >= 2 And URL2FName.Length > iq) Then
                URL2FName = URL2FName.Substring(0, iq) & URL2FName.Substring(iq).Replace("^/", "#^").Replace("//", "#%~").Replace("/", "#%").Replace("\", "#~")
            End If
        End If
    End Function

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Кирилл от 16 января 2007, 14:46:50
Хм. А нельзя ли вынести правило преобразования "URL - имя файла в кеше" в файл настроек?


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 16 января 2007, 15:13:13
Я уже предлагал такое.
Алгоритм слишком сложный, чтобы его через файл настроек описать.
И медленно будет работать тогда.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Кирилл от 16 января 2007, 15:26:36
2 Сергей
Цитировать
Я уже предлагал такое.
Алгоритм слишком сложный, чтобы его через файл настроек описать.
И медленно будет работать тогда.
Немного странно. Собственно список "Преобразование URL" можно заставить делать практически то же самое.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 16 января 2007, 15:39:51
Там не просто замена в URL некоторых символов.
Еще много других операций. Без обращения к диску никак не обойтись.
Например может оказаться что имя файла совпадает с именем каталога.
Еще есть две папки кэша, переадресация, докачка ....


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Кирилл от 19 января 2007, 09:37:22
Для получения относительного пути файла в кеше регулярные выражения вполне подойдут.
Ну а разрешение коллизий конечно лучше всего программное.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: mai62 от 19 января 2007, 12:15:46
Кирилл
Цитировать
А нельзя ли вынести правило преобразования "URL - имя файла в кеше" в файл настроек?
И будет полная анархия, несовместимость кэшей и куча вопросов почему у меня что-то не кэшируется.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Кирилл от 19 января 2007, 12:21:26
2 mai62
Ну для полной анархии при кривых руках и текущих настроек хватит ;)
Собственно список "Преобразование URL" обладает тем же ресурсом для "Cache hell"


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 27 февраля 2007, 23:47:46
popkov
Цитировать
никак не уясню, почему один символ кодируется двумя кодами с "%", идущими подряд?
И ещё более непонятно, почему тогда можно то же закодировать одним кодом с "%", и это всё равно будет правильно обработано и будет означать то же самое (я имею в виду описанные мной выше два способа кодирования, один из которых в два раза короче другого)?
Однобайтовые коды неоднозначны. Одной и той же букве могут соответствовать разные коды, в зависимости от того, какую кодовою таблицу мы подразумеваем Win, koi-8, dos ...
Юникод решает эту проблему. Двухбайтовые коды, в данном случае, это UTF-8

Вот цитата с http://ru.wikipedia.org/wiki/Юникод
Цитировать
UTF-8 — это представление Юникода, обеспечивающее наилучшую совместимость со старыми системами, использовавшими 8-битные символы. Текст, состоящий только из символов с номером меньше 128, при записи в UTF-8 превращается в обычный текст ASCII. И наоборот, в тексте UTF-8 любой байт со значением меньше 128 изображает символ ASCII с тем же кодом. Остальные символы Юникода изображаются последовательностями длиной от 2 до 6 байтов (на деле, только до 4 байт, поскольку использование кодов больше 221 не планируется), в которых первый байт всегда имеет вид 11xxxxxx, а остальные — 10xxxxxx.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 27 февраля 2007, 23:59:53
popkovОднобайтовые коды неоднозначны. Одной и той же букве могут соответствовать разные коды, в зависимости от того, какую кодовою таблицу мы подразумеваем Win, koi-8, dos ...
Юникод решает эту проблему. Двухбайтовые коды, в данном случае, это UTF-8

Вот цитата с http://ru.wikipedia.org/wiki/Юникод
Но всё равно непонятно - почему тогда сервер вернул двухбайтовый код, запросто сделав его из однобайтового? Он воспользовался информацией о языке вэб-страницы для этого?


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 28 февраля 2007, 00:05:11
Цитировать
А кто помнит, почему некоторые "небезопасные" символы было решено заменять не на их код %хх , а на комбинацию: #y  ?

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 28 февраля 2007, 00:17:41
Но всё равно непонятно - почему тогда сервер вернул двухбайтовый код, запросто сделав его из однобайтового? Он воспользовался информацией о языке вэб-страницы для этого?

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 28 февраля 2007, 19:11:14
Вот я наконец-то на этом форуме :)

Судя по URLToCache.pas, это предложение уже реализовано!  ;)  ! заменяется на #I
кхм, оно конечно более совместимо, но больше нравился вариант когда ! не трогается, а меняется ":" на "#I"

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

Цитата: popkov
пост с руборда:
Кстати, хотелось бы всё-таки узнать, что сейчас происходит с символами кавычек и <> при записи их на диск - они просто отбрасываются? И что будет с этой ситуацией в дальнейшем? Есть ли ещё такие символы?
Цитата: DenZzz
пост с руборда:
Нет, когда есть эти символы, то файл на диск не пишется совсем! Это баг...
двойные кавычки и <> в урле не могут исползоваться поэтому они кодируются браузером (%22 %3C %3E) и следовательно HC такие урлы нормально сохранит (можете проверить)

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

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



Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 28 февраля 2007, 21:02:20
двойные кавычки и <> в урле не могут исползоваться поэтому они кодируются браузером (%22 %3C %3E) и следовательно HC такие урлы нормально сохранит (можете проверить)
Ну это надо для всех браузеров ещё проверить... мало ли, какой криворукий вэб-"мастер" создаст скрипт, генерирующий URL с такими символами, и какой-нибудь FireFox или Opera в этой ситуации "забудут" его закодировать.
А главное, что, даже если такие символы всегда будут закодированы браузером, надо всё же принять решение, в каком виде их сохранять на диск - ведь мы хотим сделать кэш читабельным, а "%22", "%3C" и "%3E" не очень-то приятны для глаз... Нужно придумать систему кодирования, которая будет максимально интуитивно понятна, и не будет требовать разучивания большого числа кодов.

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 28 февраля 2007, 21:13:22
двойные кавычки и <> в урле не могут исползоваться поэтому они кодируются браузером (%22 %3C %3E) и следовательно HC такие урлы нормально сохранит (можете проверить)

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 28 февраля 2007, 21:28:44
Юникод бывает разный UTF-8, UTF-16BE, UTF-16LE, UTF-32BE, UTF-32LE.
В URL принято использовать первый вариант, в силу обратной совместимости с ASCII


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 28 февраля 2007, 22:03:18
Что касается отдельного символа "/", то я сильно сомневаюсь, что его стоит вообще кодировать - проще создать подпапку.

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 28 февраля 2007, 22:59:26
Попробуй для примера в IE (Макстоне) загрузить URL вида h++p://www.yandex.ru/yandsearch?text="привет"
а-а-а, для кого стандарты написаны :( не выполняют через одного

Цитата: popkov
А главное, что, даже если такие символы всегда будут закодированы браузером, надо всё же принять решение, в каком виде их сохранять на диск - ведь мы хотим сделать кэш читабельным,
"Читабельность/Прозрачность" может сильно усложнить алгоритм. Декодировать кирилицу imho стоит, остальное надо посмотреть (тут выгоды НЕочевидны)

Цитата: popkov
И отдельно следует закодировать две их чрезвычайно часто встречающиеся комбинации:
"://" и "//" (внутри кавычек).
imho не стоит :) без этого уже много заморочек

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

Цитата: popkov
Что касается одиночного символа двоеточия ":", то для полной однозначности мне представляется логичной запись "#=".
Тут я с тобой солидарен, кодировать ":" надо :)

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

Цитата: popkov
Осталось ещё придумать, как кодировать два слэша: "//".
сейчас до знака "?" (до query (параметров) см. RFC 2068) имеем:
/ -> \
после знака "?" получается:
/ -> #%

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 01 марта 2007, 07:04:30
Чтобы как то направить процесс, предлагаю следующий план работ, связанных с изменениями формата кеша:

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 01 марта 2007, 07:34:04
5. Написание конвектора кеша (я могу этим занятся)
Нужен универсальный конвертор исправляющий файлы и папки в кэше после редактирования списка Преобразование URL.
Обычные утилиты пакетного переименования тут не катят, т.к. работают только с именами файлов и не в состоянии обработать полное имя включаящее папки.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 01 марта 2007, 21:14:27
Сергей
Цитировать
Нужен универсальный конвертор исправляющий файлы и папки в кэше после редактирования списка Преобразование URL.
Сделать можно, только есть одна заковырка. Создали мы некое правило, ввели в его конвертер, преобразовали кеш. Упс! Правило неправильное, хотим другое или просто хочется его отключить. А уже всё, поезд уехал. В обратную сторону конвертер не сработает. Даже если специально написать еще одно правило, данных может не хватить...


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 01 марта 2007, 21:18:41
Преобразования URL<->filename

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

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

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 02 марта 2007, 11:15:17
Преобразования URL<->filename
Возможный вариант:
Я уже писал выше, что символ "#" для однозначности обратного преобразования следует удваивать:
"#" -> "##"
(иначе за ним случайно может, например, оказаться символ "x" - и всё вместе превратится в звёздочку при обратном преобразовании)
Что касается двоеточия, то, мне кажется, куда удачнее его кодировать как "#=". Я уже рассказывал о интуитивно-лингвистическом родстве двоеточия и равно - если уж мы меняем правило его преобразования, то зачем заменять менее понятным "#!", который гораздо удачнее подошёл бы для обратного слэша:
"\" -> "#!"
"|" -> "#i"
(ну разве это не легко запоминающаяся и красивая комбинация правил?)
"/" -> "#%" (по крайней мере, в символе процента есть наклонная черта, так что тоже нетрудно запомнить).


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 02 марта 2007, 11:38:20
Преобразования URL<->filename
Возможный вариант:
лечим глюки
"%22
<%3C
>%3E
Это способно создать новые глюки при обратном преобразовании: что произойдёт, если после симовла "#" окажется "%22"? Даже если все символы # удваивать - тут нужен грамотный программист, чтобы при обратном преобразовании "##%22" заменять на "#"" (или, на худой конец, "#%22"), а не на "#/22".
Хотя, в принципе, учитывать это при обратном преобразовании программыми методами нетрудно, возможно, следует всё же придумать двухсимовльные коды для этих символов. Или же следует также изменить способ кодирования простого слэша, чтобы не было неоднозначности. Например, простой слэш можно кодировать как #[. Но лучше - кодировать эти три знака:
">" -> "#}"
"<" -> "#{"
кавычка -> "#'"
В конце концов, если уж мы их кодируем, то зачем делать это непрозрачным образом? Впрочем, на этих трёх символах я не сильно настаиваю.

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 02 марта 2007, 20:00:43
Я уже писал выше, что символ "#" для однозначности обратного преобразования следует удваивать: "#" -> "##"
Любой браузер при запросе урла с сервера всегда отбрасывает "#" и все что за ним идет (можешь глануть в монитор). По сути символ "#" и строка идущая за ним не является частью урла. Это просто метка для навигации по странице. По этой причине символ # используется для кодирования.
Если вебмастеру требуется передать #, то его придется закодировать в виде %23.

Цитировать
Это способно создать новые глюки при обратном преобразовании: что произойдёт, если после симовла "#" окажется "%22"?
Кодирование с использованием "#" всегда парное, за символом "#" всегда появляется еще один. Ошибок не будет.

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

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 02 марта 2007, 20:10:25
старые посты почему-то не правяться, придется писать по новой

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Дем от 03 марта 2007, 14:26:30
Цитировать
Может и лучше, но это надо продумать в последнем разделе "красивости" (см. ниже). Но все-таки попробую обяснить почему %xx. В любом браузере символы "<>` всегда должны кодироваться в виде %xx - это СТАНДАРТ.
Это НЕ стандарт, а побочный эффект невозможности использовать их в HTML-файле.  Но если загрузка идёт иным способом, скажем AJAХ-скриптом по динамически формируемому урлу - оно может и произойти.
(собственно, кто мешает какому-нибудь "талантливому" программеру запихнуть XML-запрос в GET (а не POST)-переменную?)
Цитировать
Если вебмастеру требуется передать #, то его придется закодировать в виде %23.
Но для читабельности кеша лучше перевести его назад.
Цитировать
Сделать можно, только есть одна заковырка. Создали мы некое правило, ввели в его конвертер, преобразовали кеш. Упс! Правило неправильное, хотим другое или просто хочется его отключить. А уже всё, поезд уехал. В обратную сторону конвертер не сработает. Даже если специально написать еще одно правило, данных может не хватить...
Да. Желательно хранить базу "исходный урл = файл на диске"

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


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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 03 марта 2007, 22:19:06
Это НЕ стандарт, а побочный эффект невозможности использовать их в HTML-файле.
спорить не буду, можете почитать http://www.lib.ru/WEBMASTER/rfc2068/rfc2068rus.txt

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 04 марта 2007, 13:53:46
хорошо, только не мог бы ты свой список написать в виде
%xx - @
чтобы сразу было видно, что было в урле и что мы получим в файле

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 04 марта 2007, 17:09:28
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}
примерно так?


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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 05 марта 2007, 22:14:26
Только с символами <> ты напутал немного...
Ладно, это не принципиально.

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


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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 06 марта 2007, 12:20:58
Сегодня запустил поиск в логах 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.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 06 марта 2007, 19:59:54
Сегодня запустил поиск в логах HandyCache, и, к своему удивлению, нашёл в этих логах аж 9 URL, в которых символ "#" не отброшен (а всего там около 280000 URL). Это оказались:
проверил у себя, в мониторе # нет (IE, Firefox)

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 06 марта 2007, 20:03:17
А теперь как обещал...

Вот примеры нормальных урлов (согласно стандарту)
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 символов стоит заморачиваться лишь не пробеле...


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 07 марта 2007, 02:50:43
Теперь более опасные вещи. Символы "/" и "?" несут специальные функции.
Имеем - 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 - "^\" и "#^" поменялись местами

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

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Дем от 08 марта 2007, 01:16:40
Как мне кажется, преобразование filename->URL не должно восстанавливать исходный URL (это всё равно зачастую невозможно) - а должно давать URL, по которому будет выдан нужный файл в кеше.
Поэтому абсолютно всё равно, в каком виде в нём будут символы - %2a или *


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: cepera_ang от 08 марта 2007, 11:11:49
Как мне кажется, преобразование filename->URL не должно восстанавливать исходный URL (это всё равно зачастую невозможно) - а должно давать URL, по которому будет выдан нужный файл в кеше.
Поэтому абсолютно всё равно, в каком виде в нём будут символы - %2a или *
В чем в нем? В имени файла? Звездочка там не может быть, как некоторые другие символы.


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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Дем от 08 марта 2007, 13:12:25
Цитировать
Откровенно говоря, у меня большие непонятки, зачем вообще символ "%" зачастую оказывается закодирован в виде "%25"? Например, пробел при этом оказывается закодирован не "%20", а "%2520".
А если реальное имя файла на сервере его содержит? Например в исходном имени - пробел, а после загрузки на сервер уже %20 (а в урле уже %2520)
А вот в кеше некоторым хотелось бы иметь именно исходное имя...

Цитировать
В чем в нем? В имени файла? Звездочка там не может быть, как некоторые другие символы.
В востановленном УРЛ. В принципе, в нём можно дать даже (в смысле %23х), а не заниматься обратным преобразованием.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 08 марта 2007, 15:06:00
А если реальное имя файла на сервере его содержит? Например в исходном имени - пробел, а после загрузки на сервер уже %20 (а в урле уже %2520)
В моих логах я не нашёл ни одного примера под твоё замечание. Может, подкинешь пример такого 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" и не находит...


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 08 марта 2007, 16:02:35
Еще бы подумать как кодировать в именах файлов заглавные буквы встречающиеся в URL.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 08 марта 2007, 16:07:00
Еще бы подумать как кодировать в именах файлов заглавные буквы встречающиеся в URL.
А примеры можно, когда это имеет значение?
В спецификации URL действительно указано, что строчные и прописные буквы не равнозначны?


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


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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 08 марта 2007, 16:59:38
Если бы HC работал под Linux и хранил кэш в его файловой системе, то этой проблемы бы не возникало.
Да, Microsoft даже здесь умудрился сделать подставу!


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


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

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

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


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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 11 марта 2007, 13:05:03
Подведем предварительные итоги первой части (см. ниже). Пора узнать мнение Главного раработчика :)

Преобразования 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 (будем наглядно видеть что у нас получается)


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: cepera_ang от 11 марта 2007, 13:34:11

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: mai62 от 11 марта 2007, 13:36:10
v0lt
Цитировать
Пора узнать мнение Главного раработчика
Спасибо за проделанную работу по обобщению предложений. Добавь, пожалуйста, в табличках колонку, отображающую нынешнее поведение НС. Мне представляется важным по возможности сохранить совместимость с прежними версиями НС.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 11 марта 2007, 18:01:02
Поповоду неразрывного пробела, надо проверять, как он поведет себя на FAT, на unix-овых ФС.
На FAT ведёт себя нормально - проверено неоднократно мной! У меня папка "Ссылки" IE уже не первый год на FAT переименована в неразрывный пробел! И никаких глюков ни разу не было! И простые файлы тоже нормально создаются и обрабатываются! Проверял!
По поводу %22->## я тем более против.
А где аргументация? Чем тебе не нравится такой прозрачный и легкочитаемый способ кодирования?


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 11 марта 2007, 18:10:08
я не вижу проблемы выше приведенные урлы с "GPS/Gps" по сути ведут на одну и туже пустую страницу. Приведите более серьезные аргументы :)
HandyCache у тебя выдала ту самую ошибку, о которой говорил
Потом когда мы введем правильное название http://ru.wikipedia.org/wiki/GPS, то HC увидит что такой файл уже есть в кэше и может отказаться его обновлять.
Зайди на http://ru.wikipedia.org/wiki/GPS
 - но отключив чтение из кэша! Тебе откроется вовсе не пустая страница...
(если всё же откроется пустая - это IE виноват! Обнови страницу при выключенном чтении из кэша!)


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 11 марта 2007, 20:14:37
Цитата: cepera_ang
В файловой системе Unix запрещены два символа - "/" (обозначает папки в пути) и "\000" (то есть нулл символ, обозначающий конец имени файла). Все остальные символы - разрешены.
Спасибо, а как там с уникодом?

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: cepera_ang от 11 марта 2007, 20:21:50
Спасибо, а как там с уникодом?
В современных юниксах, насколько я знаю, с уникодом все в порядке.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 11 марта 2007, 20:24:13
для mai62

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

Лечим глюки IE (приводим урл к стандарту)
символ0.98b1до "?"после "?"
URL#строкаURLURL
"%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 и #_

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 11 марта 2007, 21:17:42
v0lt

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 11 марта 2007, 22:46:48
Цитата: DenZzz
В первых двух твоих таблицах колонка "после "?" не заполнена, хотя, на мой взгляд, она должна совпадать с колонкой "до "?". Или так и задумывалось, а движок форума тебя не понял? ;)
Если ячейка отсутствует - смотри левее. Или я не умею объеденять ячейки или движок...

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

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


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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 12 марта 2007, 19:32:17
DenZzz
выкладываю таблицу (http://handycache.ru/component/option,com_smf/Itemid,10/action,dlattach/topic,78.0/attach,162/), там основная часть и декодирование кирилицы (см. лист 2)
(коды #' #) #( #} #{ пока не вносил)

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 12 марта 2007, 21:15:52
Не знаю чего сказать, ну не нравиться мне %22->##. Если бы уж очень понадобилось %23->##, я может и согласился (по другому тут глупо кодировать). В принципе обратное преобразовние в URL особо не усложняется (всего то поставить s:=StringReplace(s,'##','%22',[rfReplaceAll]) в самое начало функции), но только из-за прозрачности, не знаю, не знаю... внуть кеша не каждый полезет, проще в Историке найти нужное (обычно)
Тогда предлагаю вариант получше - кодировать двойную кавычку двумя символами ударения, идущими подряд: "``".
Вариант, по-моему, более чем удачный. Конфликтов с кодированием заглавных букв не будет - там не может идти подряд два символа ударения.
2popkov По поводу неразвывного пробела (символ 0160). Напрягает, то что его номер больше 127, поэтому на некоторых системах он может выглядеть по другому, для спец кода это плохо.
В каких системах он выглядит иначе? Есть ли вообще такие системы? Уверен, под всеми версиями Win он выглядит одинаково - как пробел.
Еще возможно путаница (выглядит как пробел) и есть проблемы ручного редактирования. Обратная ковычка поудобнее будет.
Может быть. Но тогда предлагаю в разделе "Решение проблем" решать их не с помощью комбинации "#n" - а с помощью куда более подходящего для этих случаем символа неразрывного пробела!
То есть, я предлагаю следующее:
Редирект и решение проблем
строка0.98b1замена
редиректредирект#mредирект#m
".\"". \"
"пробел\"" \"
"путь\"путь\#_"путь\#_" или "путь\ "
"путь.""путь. "
"путьпробел""путь "
Во всех этих случаях я предлагаю обходить ограничения на использование пробелов и точек в именах файлов через неразрывный пробел, на который они не распространяются! Все видимые пробелы в таблице - это неразрывные пробелы! Согласитесь, что такое представление не только короче, но и гораздо нагляднее и более удобочитаемо!
По-моему, неразрывный пробел для наших целей чрезвычайно удобен. Давайте, что ли, протестируем, может ли он создавать какие-то глюки вообще? Я сомневаюсь. Единственный недостаток, который я заметил при работе с ним - если его скопировать в буфер обмена "в формате RTF" (например, из Word) или "в виде HTML" (с вэб-страницы), то при конвертации в Plain Text винда зачем-то заменяет его на простой пробел. Этого не происходит, если с самого начала копировать как Plain Text (например, из Блокнота или, редактируя имя файла в Проводнике, содержащее неразрывный пробел - можно копировать и вставлять сколько угодно, никаких проблем я не заметил).


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 12 марта 2007, 23:22:41
выкладываю таблицу (http://handycache.ru/component/option,com_smf/Itemid,10/action,dlattach/topic,78.0/attach,162/), там основная часть и декодирование кирилицы (см. лист 2)

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

Еще добавил в декодирование кириллицы кодировку 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 хуже? ;)


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 12 марта 2007, 23:41:00
Еще добавил в декодирование кириллицы кодировку Win-1251.
Например, URL:  http://www.yandex.ru/yandsearch?text=%CF%F0%E8%EC%E5%F0
корректно открывается во всех браузерах и хотелось бы в кэше видеть "прозрачную" кириллицу, а не коды...
Грамотно! (http://i.ru-board.com/s/up.gif)     


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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 13 марта 2007, 00:31:30
Только при кодировании заглавных букв, я думаю, не стоит менять их регистр - пускай остаются заглавными!
Ну и насчёт кавычки  - всё же считаю нужным кодировать её максимально прозрачно как два символа ударения: "``".
Да и символы "<>" можно бы попроще записать как "#{" и "#}" соответственно.

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

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

Цитировать
По-моему, неразрывный пробел для наших целей чрезвычайно удобен.

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


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

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

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 13 марта 2007, 07:05:42
DenZzz
Цитировать
Чем Win-1251 хуже?
не стандарт, а глюк фокса
нельзя однозначно написать алгоритм декодирубщий одновременно и уникод и Win-1251.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 13 марта 2007, 07:50:10
Цитировать
Чем Win-1251 хуже?
не стандарт, а глюк фокса
нельзя однозначно написать алгоритм декодирубщий одновременно и уникод и Win-1251.

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэ
Отправлено: popkov от 13 марта 2007, 07:57:42
Во-вторых, как ты уже озвучил, его очень не просто ввести с клавиатуры (надо помнить код) и нельзя скопировать из наглядного в этом плане Word-а.
В общем, использование "неразрывного пробела" затруднит ручную правку имен файлов и ручной ввод их в сторонних программах!
Ручной ввод имени файла - сделает крайне неудобным, это правда. Другое дело, что мне это никогда не было нужно (поэтому даже в голову не пришло). Мало кому это может быть нужно, но для универсальности можно и правда тогда ограничиться символом ударения для кодирования заглавных букв.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 13 марта 2007, 12:05:44
DenZzz
Цитировать
Чем Win-1251 хуже?
Тем, что мы не знаем наверняка, какая там кодировка на самом деле. Мы что, создаем прокси только для русских? Вдруг буржуи тоже захотят пользоваться этой программой. Не навязывать же всем 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 понимает неразрывный пробел? У него плохо с поддержкой Юникода. Зачем лишние проблемы создавать?


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 13 марта 2007, 14:17:43
Юниксовые файловые системы у нас, кстати, по умолчанию, монтируются в кодировке KOI-8 и такого символа там нет ;)
Не знал... Что ж, тогда спорить не о чем.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 13 марта 2007, 15:55:53
Тем, что мы не знаем наверняка, какая там кодировка на самом деле.

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

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

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

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

На счет KOI-8 - можешь привести реальный рабочий URL, где используется кодировка KOI-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
а сервер этого не поймет.

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 13 марта 2007, 19:13:45
DenZzz
Цитировать
Коды символов в UTF-8 всегда "двойные" и начинаются с %D0 или %D1 - это можно использовать для определения кодировки в URL-е...
русская буква "Р" - код D0h
русская буква "С" - код D1h :(
серверу легче, если получается два варианта, то он может глянуть какая из страниц у него есть.

Цитировать
А во-вторых, тот сервер ру-борда не понимает Юникод, но зато прекрасно понимает WIN:
тут еще проще, сервер на поисковые запросы уже ожидает Win-1251, который генерируется скриптом страницы

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 13 марта 2007, 20:56:31
серверу легче, если получается два варианта, то он может глянуть какая из страниц у него есть.
HC тоже может глянуть, какая страница в кэше уже есть...


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 13 марта 2007, 21:09:12
русская буква "Р" - код D0h
русская буква "С" - код D1h :(

Это да, но можно пропарсить весь 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-1251.

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



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

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

Код:
[UTF-8]
%D0%90 А
...
%D1%8F я
URL=ru\.wikipedia\.org/
URL=...

[WIN-1251]
%C0 А
...
%FF я
URL=+yandex.ru
URL=...

[KOI8-R]
и т.д.

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 14 марта 2007, 09:02:19
Можно попытаться это определить! Наглядный пример - сервер Яндекса, который сам определяет кодировку в запросе!
Я имел в виду WIN и KOI. Однобайтовую кодировку от юникода отличить легко, разумеется.

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 14 марта 2007, 11:03:46
Цитировать
можешь привести реальный рабочий URL, где используется кодировка KOI-8 без явного на то указания в самом URL-е?
Не могу сейчас припомнить. Но совершенно точно есть сайты с кодировкой отличной от WIN.

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 14 марта 2007, 20:18:57
пишу алгоритм... дошел до декодирования уникода (%xx%xx) и пробела (%20)
обнаружил неприятность в алгоритме:

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 14 марта 2007, 20:26:52
Еще вариант не использовать #% (совместимость пострадает). Взамен остались #; #, #z или #! (если : -> #=)
В общем-то, для кодирования слэша "/" комбинация "#!" прозрачнее, чем "#%". Так что поддерживаю! К тому же, для конвертера кэша заменить все вхождения "#%" на "#!" не так уж сложно...


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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 14 марта 2007, 23:09:23
файлы прилагаются

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

Цитировать
внутри архива таблица "что и как" и конвертор (нужен dotNetFX 2, идет с некоторыми крупными прогами и игрушками)

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 15 марта 2007, 07:01:16
DenZzz
Цитировать
Опять остались пустые ячейки в столбце "после "?" !
ну понятно же... (поправил у себя) :)

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Rick от 15 марта 2007, 07:47:23
PS: Есть Turbo Delphi (BDS2006) на нем можно безпроблемно написать для Win98 или нужен Delphi 7 ?
Не важно на чем писать - важно какие функции используются.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 15 марта 2007, 14:55:07
Если менять существующий алгоритм URLToCache, то понадобится конвертер, работающий на всех системах (даже на Win98) и без установленного .NET !
Чем тебе .Net не угодил? Он и под Win98 ставится. Я бы и сам HC под Net не отказался использовать. С совместимостью было-бы намного лучше.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 15 марта 2007, 18:12:34
Чем тебе .Net не угодил? Он и под Win98 ставится.

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

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


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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 15 марта 2007, 20:09:28
Rick
Цитировать
Не важно на чем писать - важно какие функции используются.
ну я бы не сказал, например C# вообще без dotNET не напишешь
был Delphi 8 - это вообще непонятно что, старые проекты не компилятся
Сейчас стоит Turbo Delphi 10 (Borland Developer Studio 2006) вроде нормально, проекты из Delphi 7 запускаются

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Rick от 15 марта 2007, 20:25:07
v0lt
Ты спрашивал про D7 и D10 - я про них и отвечал. С# и дотнетовские версии Delphi в вопросе не фигурировали.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 16 марта 2007, 11:02:12
2. Надо предусмотреть возможность интеграции конвертера в сам HC
Абсолютно верно. Причем еще нужен ручной конвертор. Без него пока сложно использовать список Преобразование URL без потери имеющихся в кэше данных.

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 18 марта 2007, 10:13:31
Доработал алгоритм:
измения v1.2:
-Пометка заглавных букв
-Поддержка win-1251
файлы прилагаются


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 19 марта 2007, 07:05:35
Так, думаю стоит обсудить проблему длинных урлов.
Эту тему я как-то обсуждал с mai62, но в тот момент революция не планировалось, поэтому этот ворпрос был отложен...

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

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


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

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

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

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




Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 19 марта 2007, 07:22:49
v0lt

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 19 марта 2007, 07:36:40
Все логично. Осталось уточнить, откуда взялись числа 200 и 190.

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 19 марта 2007, 09:45:34
Цитировать
- высчитывать CRC32 на основе URL, а не имени файла. Так будет более однозначный результат и меньше вероятнось потерь при преобразованиях.
Вообще-то не очень хорошо получится. Надо будет еще учитывать знак ? в  URL. И прогонять через Преобразование URL перед вычислением CRC32.
Лучше оставить как есть, но дополнить алгоритм этими пунктами.
Цитировать
- помечать строку хеша. Так будет стразу понятно, что это урл был длинным.
- сделать опцию типа "Для длинных URL сохранять *.url". Возможно кому-то может понадобиться узнать реальный урл.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 19 марта 2007, 21:50:35
DenZzz
Цитировать
Как быть с длинными URL, которые сейчас уже сохранены в кэше?
как правило там мусор, ничего полезного...

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

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

а прогонять ничего не надо(опять ошибка, см. следующий пост), кодить будем именно кусок урла
урл 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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 19 марта 2007, 22:02:06
а прогонять ничего не надо, кодить будем именно кусок урла
урл 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'ов для неё может быть несколько...


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 19 марта 2007, 22:51:05
popkov
Цитировать
Нет, здесь ты забываешь о множестве способов попасть на одну и ту же страницу, даже на данном форуме! Преобразование URL для того и нужно, чтобы для одной и той же страницы создавался только один файл, хотя URL'ов для неё может быть несколько...
сорри, я перепутал список Преобразование URL с алгоритмом url2filename :)

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 19 марта 2007, 23:01:51
И 204 символа для .url и .new
Расскажи, плиз, когда появляется .url? Не встречался мне никогда, а знать хочется.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 19 марта 2007, 23:20:42
Михаил
Цитировать
Расскажи, плиз, когда появляется .url? Не встречался мне никогда, а знать хочется.
никогда :), в текущеq версии не предусмотренно
есть только предложение создавать такой файл для очень длинных урлов

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 20 марта 2007, 00:40:08
А вот использовать "неразрывный пробел" мне не очень нравится!
Во-первых, потому что визуально он ничем не отличается от обычного, что может создать неудобство для пользователя, который захочет открыть файл в сторонней программе, набрав вручную его имя. Естественно, он вряд ли сам догадается, что там используется "неразрывный пробел".
Во-вторых, как ты уже озвучил, его очень не просто ввести с клавиатуры (надо помнить код) и нельзя скопировать из наглядного в этом плане Word-а.
В общем, использование "неразрывного пробела" затруднит ручную правку имен файлов и ручной ввод их в сторонних программах!
Должен сделать важное замечание: оказывается, в 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  .


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: cepera_ang от 20 марта 2007, 02:23:58
А могут это быть ошибки? Например когда у меня на интернет-сервере сбойная планка памяти была - там при анализе в логах тоже случайные пользователи/урлы появлялись с разными нечитаемыми символами


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 20 марта 2007, 08:32:08
Должен сделать важное замечание: оказывается, в URL'ах встречается не так уж мало символов, которые невозможно ввести с клавиатуры...

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 20 марта 2007, 14:05:45
Да и вообще, непонятно, как они там оказались!
У меня большинство из них оказались в параметрах запросов на сайт
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.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 20 марта 2007, 16:37:54
Я согласен, что это-баннерный сайт, однако наличие таких URL говорит о том, что возможны и другие сайты, при просмотре которых генерируются URL с незакодированными такими символами.

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

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 20 марта 2007, 19:45:24
Какие проблемы? :)
Да никаких :)
Просто для ясности отметил 2 момента:
1) Могут появляться файлы в кэше, имена которых нельзя ввести с клавиатуры
2) Есть вероятность (не уверен), что некоторые сторонние программы могут отказаться обрабатывать файлы с такими именами. Но EmEditor открывает - а мне на остальные по фигу... :)

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 20 марта 2007, 22:22:31
хоть и чаще, чем ты посчитал: надо скорее 687 делить на 300000 URL. :)

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 20 марта 2007, 23:06:55
ввел в Firefox-е этот урл, лис его естественно поправил
IE ничего не делал, так и оставил
в обоих случаях получил редирект на нормальный урл

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 21 марта 2007, 19:01:57
Люди, как все-таки лучше проверять длину имени файла?
Смотреть чтобы имя файла было меньше 200 или 195?
Первый вариант лучше нагляднее запоминается, но на самом деле файл может получиться из 204 символов.
Вариант 195 на вид не очень, но в результате получим гарантированно не более 200.


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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэ
Отправлено: popkov от 21 марта 2007, 19:32:02
Первый вариант лучше нагляднее запоминается
Не понимаю, чем он лучше? Надо просто решить, сколько символов оставлять для пути к папке Cache. 45 или 50 - по-моему, неважно - в любом случае, вряд ли кто-то будет делать для неё большую вложенность каталогов.
Пора поговорить о втроенной сортировке...
Мне кажется вопрос уже для многих актуален. У себя я сделал простейшую сортировку по имени домена.

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

Это примитывный вариант, я сделал через преобразование URL. В результате в корневой папке всего 27 папок, а в каждой в среднем во столько же раз меньше хостов, чем раньше. Открыть такую папку куда быстрее. К тому же структура кеша осталось почти такой же.
Я уже поднимал этот вопрос на 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-го уровней.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 21 марта 2007, 20:57:43
popkov
Цитировать
По-моему, это очень удобно, потому что всё, что относится к конкретному серверу (в данном случае ru-board.com) лежит в одной папке, а не разбросано по разным каталогам.
Есть такое...
Но такой вариант может усложнить приведение кеша к стандартному виду (без спец. утилит). Поэтому я подобное не делал, да и лень было :)

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 21 марта 2007, 21:05:49
Люди, как все-таки лучше проверять длину имени файла?
Смотреть чтобы имя файла было меньше 200 или 195?

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

Цитировать
Пора поговорить о втроенной сортировке...
...
Открыть такую папку куда быстрее. К тому же структура кеша осталось почти такой же.

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

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

Цитировать
  • Сортировка параметров в URL, чтобы image.php?num=1&size=large и image.php?size=large&num=1 ссылались на один и тот же файл в кеше; (Линк (http://forum.ru-board.com/topic.cgi?forum=5&topic=20528&start=1980#21))


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Дем от 22 марта 2007, 03:46:59
Цитировать
Открыть такую папку куда быстрее. К тому же структура кеша осталось почти такой же.
У меня сделано иначе - отдельная папка, в которую прилинкованы "любимые" каталоги из кеша - порядка десятка штук.
А в общую лазаю редко, так что могу и подождать.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 22 марта 2007, 07:00:27
DenZzz
Цитировать
Чем открыть такую папку быстрее? Сторонней программой для ручного просмотра кэша?
да, любой сторонней программой. Например мне нужно поковырять в handycache.ru, то я сразу выбираю папку с соответствующей буквой где лежит несколько сотен сайтов, вместо того чтобы ждать пока откроется папка с тысячами сайтами.

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 22 марта 2007, 07:16:32
Пример: файлы с handycache.ru лежат в \_h_\handycache.ru\
файлы с forum.ru-board.com лежат в _r_\forum.ru-board.com\
домены начинающиеся на цифры лежать в _0_\
Подчеркивание тут лишнее. Давно пора сделать так. В CoolProxy это называлось компактным режимом, кажется.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 22 марта 2007, 07:47:39
Еще раз (http://forum.ru-board.com/topic.cgi?forum=5&topic=18348&start=1620#4) по поводу длины.
Цитировать
...имея дело с файлами, всегда необходимо помнить об ограничении длины полного имени файла, накладываемого операционной системой. Для ANSI-версий функций (единственно доступных для ОС Windows 95/98), выполняющих файловые операции, максимальная длина буфера, содержащего полный путь к файлу (включая ноль-терминатор) равна MAX_PATH (что составляет 260 для PC-архитектуры и 256 для MAC). Для Windows NT/2000 доступны UNICODE-версии функций, которые способны расширить этот предел вплоть до 32767 UNICODE символов. В последнем случае UNICODE-строка, содержащая полный путь к файлу, должна начинаться символами "\\?\". Для более полной информации см. раздел "File Name Conventions" в MSDN.
Цитировать
На самом деле это ограничение в 260 символов есть только в Windows API. В самой файловой системе (FAT32 или NTFS) максимальная длина имени файла ограничена 255 символами, но максимальная длина пути может быть гораздо больше, чем поддерживает WinAPI.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 22 марта 2007, 18:30:19
Сергей
Цитировать
Для Windows NT/2000 доступны UNICODE-версии функций, которые способны расширить этот предел вплоть до 32767 UNICODE символов.
Это хорошо, только на практике толком не работает. Я даже сам пытался вызвать уникод-функции, не получилось, мутно все описано...

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 22 марта 2007, 20:02:49
Юникод функции нам не нужны. Даже если они заработают, то будут проблемы с внешними программами типа Архивариуса. Лучше решить какая длина пути для нас максимум.

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 23 марта 2007, 07:03:56
Сергей
Цитировать
А последнюю строку как рассшифровать?
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\  (туда же где "циферные" домены?)


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 23 марта 2007, 12:31:27
Нормально.

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 23 марта 2007, 22:07:28
Не! У тебя не может быть в логах 687 разных URL с этими символами!
Ты прав.
Поиск в логах по шаблону (любой 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%
Действительно, немного...


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 24 марта 2007, 09:19:50
Сергей
Цитировать
А как к таким преобазованиям отнесется Историк?
Сам Историк такое переваривает нормально (историю естественно придется обновить).
Но т.к. URL выдается неправильный, то некоторые сайты (форум хобота) во втроенном браузере отображаются с ошибками.

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


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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 27 марта 2007, 23:52:54
-добавлена сортировка по домену (используется префикс "_");

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

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 28 марта 2007, 21:47:12
popkov
Цитировать
Встроенная сортировка может быть только опциональной! Меня, например, вполне устраивает придуманная мной структура кэша, и менять её я не хочу
даже не знаю, как такое сделать чтобы у других меньше вопросов было...
хотя в приципе, если у тебя в хосте получается две точки подряд (.\Cache\ru-board..com\forum\), то тут новая сортировка не должна сработать.

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 29 марта 2007, 02:07:27
это мне не нравится: код усложняется, это нужно только тебе (как мне кажется) и думается mai62 будет против...
Гнилая отговорка! Не так код усложняется, как упрощается чтение кэша! А mai62 пока ничего не говорил! Так что не решай за него, пожалуйста! То, что только я об этом говорю - следствие того, что в этой теме вообще не так уж много активных пользователей! Я думаю, впоследствии те, кто часто работает с кэшем напрямую - будут мне благодарны за проделанную работу по убеждению незаинтересованных в том, что некоторым действительно нужно, чтобы соответствие
URL <> FileName
было максимально прозрачно для любого начинающего пользователя
, а не только изучившего RFS!
popkovдаже не знаю, как такое сделать чтобы у других меньше вопросов было...
хотя в приципе, если у тебя в хосте получается две точки подряд (.\Cache\ru-board..com\forum\), то тут новая сортировка не должна сработать.
Ты хочешь навязать всем свою версию структуры кэша! При этом пользователи лишатся возможности самостоятельно реализовывать ту структуру кэша, которая больше соответствует потребностям конкретного пользователя! Ты и здесь скажешь, что я - единственный, у кого есть собственные предпочтения относительно структуры своего кэша, не совпадающие с твоими? Пока и в этом вопросе в данной теме я - твой единственный оппонент. То, что другие не возражают - возможно, следствие недостаточно высокой популярности данной темы! А эта недостаточная популярность как раз с тем и связана, что в том, как реализована структура кэша в текущей версии HC, большинство пользователей всё устраивает - ведь текущая версия предоставляет полную свободу пользователю относительно того, какую структуру должен иметь его кэш (и не только в этом)! Чего же ещё желать?

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 29 марта 2007, 02:38:48
В текущей версии 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 это относится, но и к любым другим посковикам на любых сайтах! Двойная кавычка - общепринятый морфологический признак задания точного вхождения! Она несёт большую смысловую нагрузку, зачем её оставлять нечитабельной???


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 29 марта 2007, 10:07:59
ЗЫ: как я помню, на FAT-е файлы могут быть только на английском и на языке совпадающей с локализацией винды

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 29 марта 2007, 10:24:13
Ты, похоже, хочешь отнять у меня свободу кодировать (пока, как я понял, только двойную кавычку) так, как мне кажется оптимальным. Зачем?
Не бойся. Алгоритм URL2Cache работает уже после срабатывания списка Преобразование URL. Так-что ты ничего не потеряешь. Хочешь двойную кавычу - используй.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 29 марта 2007, 12:39:19
Не бойся. Алгоритм URL2Cache работает уже после срабатывания списка Преобразование URL. Так-что ты ничего не потеряешь. Хочешь двойную кавычу - используй.
Дело в том, что мы решили не декодировать символ ударения `, а если он случайно встретился - превращать его в код %60. Это имеет основания под собой, но, если я попытаюсь кодировать двойную кавычку двумя символами ударения, оба они превратятся в коды %60 - в соответствии с новыми правилами. Именно поэтому я так настаиваю на двойной кавычке и не обращаю внимания на символы <>, которые я тоже хочу прозрачно кодировать, но новые правила мне нисколько в этом не мешают.

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


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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 29 марта 2007, 19:27:38
Интересно, на синем экране смерти и в последних версиях NT (2000 и XP) тоже используется эта кодировка? Вот почему он всегда нечитабельный...
Руки бы поотрывать тому, кто догадался локализовать экран смерти. Русификатор там не срабатывает и шрифты берутся те, что зашиты в видеокарте. Разумеется, что там нет русских букв.

Цитировать
То есть можно и под и под FAT и под NTFS декодировать полный набор символов Юникода?
Получается что так. Но надо проверить.

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 29 марта 2007, 19:36:22
Этого не может случиться, т.к. # отбрасывается до обработки списка Преобразование URL.
Серьёзно? Ну слава богу... а то я уж решил, что и здесь подстава... Не так всё плохо, так что настаиваю по-прежнему только на кодировании двойной кавычки, поскольку её закодировать наиудачнейшим способом через "Преобразование URL" при новых правилах уже не получится, а очень бы хотелось... Да и зачем вообще делать что-то непрозрачно, если можно сделать просто и ясно???


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

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

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

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

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

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 29 марта 2007, 20:15:09
Я не понял. Можно или нельзя? Если иероглифы сохраняются, значит можно?


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 29 марта 2007, 20:28:45
Цитата: Сергей
Я не понял. Можно или нельзя? Если иероглифы сохраняются, значит можно?
я произвольно переименовывал в тотале, работает, алгоритм еще не писал...

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 29 марта 2007, 20:39:09
нашел немного
http://ru.wikipedia.org/wiki/Символы,_представленные_в_Юникоде
попытаюсь разобраться... :search:


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 29 марта 2007, 21:51:38
Windows знает все символы, т.к. она понимает юникод.
Проблемы возникают со старыми программами, которые его не понимают. Например, FAR.
HC к ним не относится :)


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

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

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


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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 29 марта 2007, 23:15:30
popkov
Цитировать
Просто при обратном преобразовании надо вначале заменять все коды `` на %22 - и только потом обрабатывать прописные и строчные буквы!
принемается, отговорка была не очень... устал наверное...

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

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 30 марта 2007, 00:41:23
Есть такое, но это к функции записи кеша. Т.е. если мы создаем #_, то нужно удалить #m если таковой имеется, и наоборот.
Похоже, ты и правда устал. Иногда и отдых нужен.
А вот #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. Интересно!


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

К сожалению, в обоих случаях имеет место один и тот же глюк - HC не выдаёт файлы переадресации, и страница, открытая по ссылке http://www.goupsoft.com/ezsavemht - отображается и работает неправильно!
 :'(


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 30 марта 2007, 01:10:27
Проверил: HC переименовывает файл ezsavemht в ezsavemht#_, и далее создаёт папку ezsavemht. Интересно!
Проблема в том, что нельзя создать папку и файл с одинаковыми именами, но способ обхода глюка уж очень извращенный получается, радует что такое почти не встречается...
Выходит, автор HC уже и без нас наполовину решил описанную проблему - а мы даже и не догадывались!
mai62 Respect!  (http://i.ru-board.com/s/applause.gif)
И ничего "извращенского" в таком решении я не вижу - вполне логичное и простое решение!


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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 30 марта 2007, 01:48:13
Кто-то может и не догадывался. ;) А на руборде этот вопрос обсуждался точно.

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 30 марта 2007, 02:22:46
Кто-то может и не догадывался. ;) А на руборде этот вопрос обсуждался точно.
Ну я и v0lt - точно!
Мне кажется запись файла редиректа в папку при запросе http://www.goupsoft.com/ezsavemht
является ошибкой. Даже если папка есть, надо записывать в файл ezsavemht#m а не в ezsavemht\#m

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 30 марта 2007, 09:24:05
Надо просто в первую очередь выдавать файл с переадресацией - файл #m!

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

Цитировать
Т.е. если мы создаем #_, то нужно удалить #m если таковой имеется, и наоборот.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 30 марта 2007, 10:10:46
Подведем черту:
1. Файл переадресации недопустимо записывать в подкаталог.
2. В одной папке не может находится одновременно индексный файл #_ и переадресация #m


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

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 31 марта 2007, 18:19:27
В результате работы алгоритма URL2File есть ли у нас и почему гарантия, что два URL с различным содержимым не отобразятся в кэше на один файл?


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Дем от 01 апреля 2007, 11:21:58
Цитировать
2. В одной папке не может находится одновременно индексный файл #_ и переадресация #m
На самом деле всё ещё интереснее. При входе например на ЖЖ происходит переадресация на некий файл, проводящий авторизацию и потом с него назад. И с нужными куками по тому же адресу происходит уже не переадресация, а выдача контента.
Т.е. в этом случае оптимальным было бы #m в кеш не писать вообще (но в браузер выдать)


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 01 апреля 2007, 11:49:02
Цитата: Дем
И с нужными куками по тому же адресу происходит уже не переадресация, а выдача контента.
Т.е. в этом случае оптимальным было бы #m в кеш не писать вообще (но в браузер выдать)
обычный файл будет новее редиректа, если HC будет проверять время (или удалять старый), то проблемы быть не должно.
(естественно такой урл не должен попадать в списки "Не обновлять" и "Только из кеша")

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

Цитата: popkov
HC никогда не должен залезать в подкаталог большей вложенности, чем тот, который подразумевается в URL!
Сам не проверял, но полагаю такое может быть для совместимостью с первыми версиями HC


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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 01 апреля 2007, 23:06:57
Цитата: popkov
что не только не есть good, но противоречие всякой логике и явный глюк!
А я и не говорил что это правильно, просто когда в прошлый раз чуток менялось структура кеше у людей некоторые страницы в офлайне вообще не отображались, это "глюк" вроде как помогал...

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 02 апреля 2007, 01:34:43
PS: за нахождение фала вроде отвечает функция ExistsCacheFileNameDo
Конечно, хотелось бы избежать лишних запросов к винчестеру. В идеале должно быть так: запрашиваем файл - получаем ответ, что файла нет, но есть папка. Тогда запрашиваем файл с суффиксом #_, не залезая в папку.


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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 03 апреля 2007, 10:10:32
Цитировать
Почему обрубаем длинный URL на ближайшем слэше, а не на "полуслове"?
Чтобы в разных папках кэша или у разных пользователей обрезанный файл назывался одинаково.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 03 апреля 2007, 17:48:54
volt
Кроме этого прочие представленные в URL кодами спецсимволы типа ~ @ $ ^ и т.п. также примут вид %X'X вместо ожидаемого %XX.
Поправлюсь: Кроме этого прочие представленные в URL кодами спецсимволы типа ~ @ $ ^ и т.п. также примут вид %X'X вместо ожидаемого их естественного вида (либо %XX в сдучае, когда символ запрещен в имени файла).


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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 03 апреля 2007, 20:07:00
Если ты хочешь сказать по глюк из-за пометки заглавных букв символом `...
Да, про него. Хочу сказать также, что, может, надо пытаться декодировать не только буквы кириллицы, но и символы.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 03 апреля 2007, 23:17:28
Юникод и win-1251 могут изображаться и маленькими буквами. Например, %cd, %e8 и т.п. Имхо, надо учесть (т.е. не учитывать регистр).


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 03 апреля 2007, 23:26:23
Новая версия алгоритма:
измения v1.3 beta 2:
-добавлены варианты декодирования %22 ("), %3C (<) и %3E (>);
-обнаружен баг в пометке заглавных латинских букв силволом ` в кодах вида #XX. Решения пока нет (баг нашел Михаил)

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

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

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


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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 04 апреля 2007, 01:36:02
При формировании исправленного URI должно, имхо, также  делаться следующее:
  - переводить коды в верхний регистр (о чем говорили выше);
  - коды %41-%5A, %61-%7A, %30-%39, %2D, %2E, %5F, %7E преобразовывать в соответствующие им символы;
  - http://site.ru:
    http://site.ru:/
    http://site.ru:80
    http://site.ru:80/
    приводить к виду site.ru/ (так же как сейчас приводится к этому виду http://site.ru).
По моему мнению, давно необходимо избавиться от опции "Удалять ссылку на порт 80 из имени файла в кэше" в Настройках/Кэш/Управление и удалять ссылку на порт 80 всегда.
Все эти варианты регламентируются в качестве тождественных URI.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 04 апреля 2007, 01:43:36
В свою очередь, знаю, что в сети полно URL подобного, к примеру, рода:
site.ru/...?...&url=http%3A%2F%2F...%2F...
После длительного обсуждения решено было не декодировать код 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 или сайт, куда производится перенаправление нужно передать скрипту сайта в виде параметра. Причём синтаксис параметров скрипта подразумевает использование в качестве разделителей символов ;:/=& - и декодирование любого из них может привести к неправильной работе скрипта (а они в качестве разделителей, естественно, используются в незакодированном виде, так что мы не будем знать, был данный символ закодирован или нет, если будем всё подряд декодировать).


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

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

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

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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 04 апреля 2007, 09:09:46
Цитировать
коды %41-%5A, %61-%7A, %30-%39
Оно верно, вопрос только возникает: зачем эти символы вообще кодируют? Кому это надо?
Кодируют. Это факт. Например, делают это в параметре &login=. Но не только, есть еще много примеров.
На мой взгляд, процедура FixURL должна выполняться сразу, до проверки любого списка, а не после "Преобразования URL" (http://handycache.ru/component/option,com_smf/Itemid,10/topic,78.msg3096/#msg3096). Тогда и наши правила супостатам обойти не удастся  :P


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 04 апреля 2007, 10:15:28
После длительного обсуждения решено было не декодировать код 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 или сайт, куда производится перенаправление нужно передать скрипту сайта в виде параметра. Причём синтаксис параметров скрипта подразумевает использование в качестве разделителей символов ;:/=& - и декодирование любого из них может привести к неправильной работе скрипта (а они в качестве разделителей, естественно, используются в незакодированном виде, так что мы не будем знать, был данный символ закодирован или нет, если будем всё подряд декодировать).
Пожалуй, логично. Удручает следующее. Заменяя спецсимволы на сочетания типа #x и др., хотим, чтоб пользователю не надо было запоминать коды (не беру пока слэш, у которого есть и другая функция - обозначить папку). С другой стороны, если эти символы изначально представлены в URL в виде кодов, мы их так и оставляем. Т.о., пользователю один хрен придется эти коды учить, только еще плюс к этому придется учить и введенные нами альтернативные обозначения.  ::) Есть ли достойный выход?
Апостроф ' иногда используют в именах файлов, а также в поисковых запросах может использоваться. Правда, и то, и другое - редкость (у меня в логах нашлось только 2 небаннерных URL  с закодированным таким символом). Однако нет полной уверенности, что он никогда не используется как разделитель параметров скриптов. Хоть баннерная ссылка и не аргумент, но сомнения внушил такой URL:
http://counter.yadro.ru/hit?r'%20+%20escape(document.referrer)%20+%20((typeof(screen)=='undefined')?'':';s'+screen.width+'*'+screen.height+'*'+(screen.colorDepth?screen.colorDepth:screen.pixelDepth))%20+%20';'%20+%20Math.random()%20+%20'
Так что с апострофом спешить, наверное, не следует.
В приведенном примере апостроф используется для обозначения строки, не в качестве разделителя параметров скрипта. Он, как и ~.- относится к т.н. незарезервированным в стандарте URI. И при его раскодировании всегда получим URL, эквивалентный исходному.


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

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 04 апреля 2007, 16:13:31
Если ты хочешь сказать по глюк из-за пометки заглавных букв символом `, то да, такое имеется :( спасибо  :thanks:
теперь буду думать как его обойти (в текущей реализации это криво получается...)

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 04 апреля 2007, 16:57:37
На мой взгляд, процедура FixURL должна выполняться сразу, до проверки любого списка, а не после "Преобразования URL" (http://handycache.ru/component/option,com_smf/Itemid,10/topic,78.msg3096/#msg3096). Тогда и наши правила супостатам обойти не удастся  :P
Интересная мысль! Однако требует тщательного анализа на предмет возникновения ситуаций, когда 2 разных URL окажутся в итоге одинаковыми! Этого необходимо избежать со 100%-ной гарантией, тогда эту функцию и правда лучше будет поместить до всех списков!

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


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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 05 апреля 2007, 00:37:42
Ну дык, только у меня пока нелады с регулярными выражениями в C#. Мутно как-то все реализовано, замена непонятно как работает...

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


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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 05 апреля 2007, 21:47:52
Повторное кодирование не допускается. Выражение типа %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=



Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 05 апреля 2007, 22:24:54
Ты уверен?
Если задать  в google поисковую строку "%C2%A0", то получим первый из указанных URL. Здесь %C2%A0 совершенно справедливо воспринимается как строка, а не как закодированные данные.
Остальные URL-ы нерабочие (по крайней мере у меня в Опере).


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 06 апреля 2007, 02:40:31
Михаил
Дело в том, что я не пишу 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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 06 апреля 2007, 11:11:35
А насчёт нерабочих - вот рабочие (проверил!):
Всех их объединяет одно - кодируется текстовый параметр (строка). Попробуй зайти на 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, на мой взгляд, лучше не использовать.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 06 апреля 2007, 11:51:48
Обе ссылки нерабочие :(


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 06 апреля 2007, 21:08:18
Попробуй зайти на URL http://www.gg2.net/upload/Bill%2520Gates.jpg из первого примера - не получится.
С учетом всего этого, правило, преобразующее код типа %2525 в %25, на мой взгляд, лучше не использовать.
Тут ты немного нарушил логику: из того, что закодированный повторно URL обрабатывается неправильно не следует, что противоположная ситуация - когда декодированный URL находится в виде параметра скрипта на месте закодированного - тоже будет обрабатываться неверно!
Попробуй зайти по ссылке:
http://tbn0.google.com/images?q=tbn:P4qJidTTzOytPM:http://www.gg2.net/upload/Bill%20Gates.jpg
- она обрабатывается сервером нормально, хоть я и декодировал знак процента!


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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 07 апреля 2007, 17:17:19
Рассмотрим пример, когда в поисковике надо найти строку "xyz%45". Поисковик сформирует URL с параметром xyz%2545. Если затем мы обрежем "25", то получим "xyz%45" и с таким URL в следующий раз попадем совершенно на другую страницу - на результаты поиска строки "xyzE".
С примером согласен, но не слишком ли он искусственен? Кому придёт в голову искать "%45" - тем более, что при таком поиске Google отбрасывает знак % - и ищет вхождения "45"? Не единственный ли это случай, когда такое может происходить?
У меня в списке "Переадресация" есть правило .+(url|go)=http заменять на http. В свете нашего общения начинаю склоняться к мысли, что для правильной его работы необходимо добавить в белый список правило (url|go)=http.*%25 с запретом переадресации.
Думаю, здесь ты прав! На RU-Board как-то обсуждалась ситуация, когда это правило неправильно работало, если знак двоеточия закодирован. В той ситуации оно всё же должно было сработать, поэтому я доработал это правило так:
#5#~#True#~#.+&(url|go)=http(:|%3a)//#~#http://#~#False#~#True
#5#~#True#~#.+/go.php\?http(:|%3a)//#~#http://#~#False#~#True
Такие правила правильно сработают в описанной тобой ситуации. Хотя, если честно, они кажутся мне наименее полезными и наиболее сомнительными из всех правил по умолчанию. Пока глюков не замечал - поэтому держу их включёнными! Попаданий довольно мало.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 07 апреля 2007, 21:28:27
На мой взгляд, мы немного ушли в сторону :)
Краткое резюме по функции 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 всегда.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 07 апреля 2007, 23:24:19
Краткое резюме по функции 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:<конец>



Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 07 апреля 2007, 23:38:41
какой бывает <конец>  в
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/


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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 08 апреля 2007, 19:49:01
Да, забыл про отсечение фрагментов. Итого 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/


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 11 апреля 2007, 01:07:02
  - отсекаем "http://", а при включении соотв. опции - и "www."
Только после Переадресации... См. мой предыдущий пост... Причём всё, что там написано, относится и к www. перед именем хоста! Иногда важно переадресовывать ссылки с www. на адреса без него! И наоборот! Это действительно важно! Иногда сайт существует в двух видах: c www. и без него! И когда залогинивешься на сайте без www., оказывается, что на его варианте с www. ты не залогинен! Единственный способ обойти этот глюк - использовать Переадресацию! Что я и делаю! Поэтому ДО Переадресации нельзя отбрасывать ни то, ни другое! Ни в коем случае!

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 15 апреля 2007, 18:38:59
ты согласен, что они понятнее и проще, чем соотв. #', #( и #)
В моих глазах `` однозначно лучше #', а остальные одинаково приемлемы.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 15 апреля 2007, 21:21:59
В моих глазах `` однозначно лучше #', а остальные одинаково приемлемы.
Наконец-то в этой теме слышу высказывание в пользу ясности и здорового вкуса! (http://i.ru-board.com/s/jump.gif)

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 19 апреля 2007, 23:32:11
Михаил
Цитировать
- отсекаем "http://", а при включении соотв. опции - и "www."
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 переводятся в верхний регистр


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 20 апреля 2007, 00:14:50
Если мы сильно исправим урл (Михаил: - коды %41-%5A, %61-%7A, %30-%39, %2D, %2E, %5F, %7E преобразовываем в...) и у нас сработает Переадресация, то браузер запросить у сервера такой урл, который тот не найдет у себя.
(вышеприведенные коды допустимы и сервер может ждать именно их, а не соответствующие символы).
Это те символы, которые как ни меняй их на коды и обратно - получим полностью эквивалентный URL, и запрос будет гарантированно отправлен туда же и с теми же параметрами и так же понят сервером. Потому и в FixURL гарантированно можно заменять коды только этих символов, а все остальное будет при необходимости заменять URL2FileName.
А если правило в Переадресации прописывать криво, то и сейчас не попадем по желанному адресу (но я не думаю, что ты это имел ввиду).
Если же я чего не так понял, приведи, плиз, пример.

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 20 апреля 2007, 07:08:36
Это те символы, которые как ни меняй их на коды и обратно - получим полностью эквивалентный URL, и запрос будет гарантированно отправлен туда же и с теми же параметрами и так же понят сервером. Потому и в FixURL гарантированно можно заменять коды только этих символов, а все остальное будет при необходимости заменять URL2FileName.
А если правило в Переадресации прописывать криво, то и сейчас не попадем по желанному адресу (но я не думаю, что ты это имел ввиду).
Если же я чего не так понял, приведи, плиз, пример.
набри в гугле 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=
... другую страницу



Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 20 апреля 2007, 10:03:15
набри в гугле HandyCache%41 получишь в ответе страницы со строками "HandyCache" и "41", и нигде не увидешь выделенное значение кода %41
Мы говорим не о строке поиска Google, а об URL. А он будет содержать параметр не HandyCache%41, а HandyCache%2541.
Цитировать
Пусть мы имеем урл
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=
... другую страницу
Проверь на практике - получим ту же самую!
Посмотри rfc3986 п.2.3:
Цитировать
Characters that are allowed in a URI but do not have a reserved
   purpose are called unreserved.  These include uppercase and lowercase
   letters, decimal digits, hyphen, period, underscore, and tilde.

      unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"

   URIs that differ in the replacement of an unreserved character with
   its corresponding percent-encoded US-ASCII octet are equivalent: they
   identify the same resource
.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 20 апреля 2007, 20:52:27
Михаил
Цитировать
Проверь на практике - получим ту же самую!
Клянусь :D
зашел на http://www.google.ru/ig?hl=ru
ввел HandyCacheA, а гугл меня спрашивает "Возможно, вы имели в виду: Handycache"
А я ему HandyCache%41 и надо же, нашел!
Если надо скриншоты сделаю :)

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

Цитировать
Посмотри rfc3986 п.2.3:
Написано логично, но не все его читали :(


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 20 апреля 2007, 21:26:11
Если заходить по ссылкам, то HandyCache%41 превращается в HandyCacheA, а вот если прямо на странице вводить, тогда результат разный получается.
При чем тут строка google, никак не пойму. URL-ы при этом совершенно разные. Разные URL-ы (разные, заметь, не различием А - %41) - разные результаты. Имхо, один из нас путается. ;)


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: popkov от 20 апреля 2007, 22:19:23
Разные 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.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 04 мая 2007, 11:12:43
volt
В URL->FileName для чего кодируем знак "?" не везде одинаково, а двумя разными вариантами - "^\" и "#^"?


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 04 мая 2007, 19:44:23
volt
В URL->FileName для чего кодируем знак "?" не везде одинаково, а двумя разными вариантами - "^\" и "#^"?
Первый знак вопроса указывает что дальше пойдут т.н. параметры. Поэтому мы их отделяем в отдельную папочку с помощью "\" (сочетание "^\" сложилось историчеки).

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 05 мая 2007, 00:05:06
Volt
Спасибо. Т.е. кодируем "^\" только первый знак вопроса, сколько бы этих знаков вопроса ни было. Просто в xls-файле не очень понятно вышло насчет кодирования знака "?" до и после знака "?", потому и вопрос возник. Фу ты каламбур какой-то  :)


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 19 мая 2007, 12:30:40
В процессе перелопачивания кода 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?


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 19 мая 2007, 15:03:45
файлики к посту выше...


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 20 мая 2007, 22:32:28
файлики к посту выше...
У меня exe выпадает с ошибкой, не запускаясь: "Ошибка при инициализации приложения (0хс00000135). Для выхода из приложения нажмите кнопку "ОК".


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 20 мая 2007, 22:55:25
Михаил
Цитировать
У меня exe выпадает с ошибкой, не запускаясь: "Ошибка при инициализации приложения (0хс00000135). Для выхода из приложения нажмите кнопку "ОК".
странно, я в коде поменял только символ "_" на "." в двух местах
завтра проверю на работе...


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Михаил от 22 мая 2007, 20:14:17
Volt
А на другом компе запускается без проблем. Непонятно.


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 22 мая 2007, 22:49:13
Цитата: Михаил
А на другом компе запускается без проблем. Непонятно.
Если предыдущая версия работает, то можешь тестить её (разница там лишь в первом символе при сортировке по домену).

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


Название: Re: Точки на конце URL
Отправлено: Дем от 27 августа 2007, 15:26:01
Глюк взаимодействия с файловой системой обнаружил...
Если имя папки с точками на конце (например Other...) - то винда такую папку не создаёт...


Название: Re: Точки на конце URL
Отправлено: cepera_ang от 28 августа 2007, 18:30:15
Она и не создаст :) А если особыми методами создать - то и удалить не получится. Ну глючит ФС винды на точках :)


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 28 августа 2007, 20:47:37
Хорошо бы учесть этот баг Винды с точками в будущем алгоритме преобразования URL...


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: v0lt от 28 августа 2007, 22:06:41
Дем
DenZzz
проблема решаема аналогично "\" на конце
путь\ -> путь\#_
путь. -> путь.#_
путь  -> путь #_ (для случая если %20 был заменен на пробел)

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 08 ноября 2007, 11:34:32
PS: описано в URL2filename_ver1_3beta4.xls,
Где лежит этот файлик?


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 08 ноября 2007, 13:15:56
Где лежит этот файлик?

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: Сергей от 08 ноября 2007, 13:43:15
Спасибо. А то я сунулся в поиск по сайту и ничего не нашел :-)


Название: Организация кэша (папки)
Отправлено: Klayq от 29 апреля 2008, 18:08:16
1. Иногда вместо домена в папке сохраняется IP.
2. Как можно сделать так, чтобы кэш-файлы с определенных сайтов сохранялись в отдельной папке.


Название: Re: Организация кэша (папки)
Отправлено: DenZzz от 29 апреля 2008, 18:44:45
1. Иногда вместо домена в папке сохраняется IP.

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

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

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


Название: Re: Организация кэша (папки)
Отправлено: Klayq от 30 апреля 2008, 13:06:27
С помощью преобразование УРЛ не выходит.

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

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



Название: Re: Организация кэша (папки)
Отправлено: DenZzz от 30 апреля 2008, 13:43:04
В результате программа создает папку с именем "папка\папка\сайт.ру".

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

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

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

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


Название: Re: Организация кэша (папки)
Отправлено: Klayq от 30 апреля 2008, 14:00:00
Спасибо. А в не кэша хранить кэш-файлы нельзя?


Название: Re: Организация кэша (папки)
Отправлено: DenZzz от 30 апреля 2008, 14:15:32
Спасибо. А в не кэша хранить кэш-файлы нельзя?

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


Название: Алгоритм преобразования URL в имя файла в кэше
Отправлено: olDjeka от 01 ноября 2008, 23:18:27
Пока кэш небольшой, и его еще не очень сложно поправить, хотелось бы более точно знать алгоритм
преобразования и выяснить некоторые вопросы, косвенно касающиеся этой темы.

Цитировать
Файлы во время загрузки пишутся во временные файлы с расширением *.new  и *.cnk
Не нашел описание применения файлов с расширением *.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 остатка]


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 02 ноября 2008, 11:58:04
Не нашел описание применения файлов с расширением *.cnk, или оно больше не используется ?

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

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

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

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

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

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

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

Цитировать
Записал алгоритм v0.98b1 для себя (см.ниже) - подскажите где наврал.

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

Цитировать
Вышло уже несколько новых версий HC, в "ToDo" эта тема не фигурирует - возможно алгоритм уже изменился, если да то как?

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

Правильно ли указана очередность по пунктам и всем их подпунктам?

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

Цитировать
При необходимости, или по глупости, можно создать правила, которые позволят обойти встроенные в HC преобразования?

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: olDjeka от 02 ноября 2008, 22:31:34
Жаль что свои посты нельзя редактировать.
Чтобы исключить разночтение (я некорректно задал некоторые вопросы) прошу подтвердить ответы.

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

Цитировать
Цитировать
...файл будет переименован в имя#_, и доступ к нему будет утрачен?
Переименован будет. Доступ сохранится.
Т.е. доступ HC к нему сохранится?

Цитировать
Откуда в кэше возьмется папка с именем #m или #_ ? Это невозможно.
При использовании правила:
#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. В исходниках не разбираюсь.

Цитировать
п. 2.1. - удали. Скрипты не вмешиваются на этом этапе.
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)".
В тренажере все в порядке, а в мониторе:
Код:
02.11.2008/13:40:25 local/127.0.0.1 http://ru-board.com/smilies/applause.gif 0 0/204 0 0 "404 Not found (HC)" Offline, П.27
Offline 
П.27 (Преобразование URL): .*/smilies/.*\.gif$
Долго не мог понять в чем дело, хотел уже в форуме спросить, а потом вспомнил про встроенные
в HC преобразования:
[!] -> [#I]
[:] -> [!]
Правило стало работать когда переименовал папку в #i_null_#I.
Чтобы использовать папку !_null_! внес в правило следующие изменения:
Правило: .*/smilies/.*\.gif$  Замена: :_null_:/nullgif.gif


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 03 ноября 2008, 11:58:06
Т.е. первого файла адрес-d/имя-f.new в кэше не будет?

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

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

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

Цитировать
Кандидат для таких замен искался среди всех доступных для файловой системы символов, и лучшим оказался символ # (применяемый только для навигации по странице) и его сочетания.

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

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

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

Правило стало работать когда переименовал папку в #i_null_#I.

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

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

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


Название: Алгоритм преобразования URL в имя файла в кэше
Отправлено: olDjeka от 03 ноября 2008, 15:53:09
Цитировать
Цитировать
Правило стало работать когда переименовал папку в #i_null_#I.
Откуда взялось "#i" ? В замене не было символа "|".
Не совсем то имелось ввиду. Это когда правило оставил без изменений:
Правило: .*/smilies/.*\.gif$  Замена: !_null_!/nullgif.gif
хотел показать что регистр в имени самой папки значения не имеет, т.е. папка может называться:
#I_null_#I
#i_null_#i
#i_null_#I
или
#I_null_#i


Название: Алгоритм преобразования URL в имя файла в кэше
Отправлено: olDjeka от 05 ноября 2008, 13:33:16
Упустил один важный вопрос.
Под каким пунктом в моей схеме (http://handycache.ru/component/option,com_smf/Itemid,10/topic,78.msg15389/#msg15389) должно производится удаление лидирующих http:// и www. ?


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: DenZzz от 05 ноября 2008, 14:58:26
Перед проверкой списка "Преобразование URL".


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


Название: Re: Куда сохраняются загрузки ?
Отправлено: mai62 от 26 марта 2010, 18:13:32
Наведи указатель мыши на URL, должно появиться имя файла с путем.


Название: Re: Куда сохраняются загрузки ?
Отправлено: Selenyt от 26 марта 2010, 21:10:16
Я это и делал . В этой папке пусто . А загрузка была .


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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: mai62 от 04 апреля 2010, 13:19:21
Это можно сделать с помощью списка Преобразование URL. Посмотри эту тему http://handycache.ru/component/option,com_smf/Itemid,10/topic,337.1060/, думаю, там можно найти решение похожей задачи.


Название: Объединение кэшей с разных компьютеров
Отправлено: popkov от 27 сентября 2010, 23:24:20
В процессе объединения двух кэшей, созданных независимо на разных компах, столкнулся с проблемой: встречаются ситуации, когда в одном кэше имеется файл с определенным именем, а в другом - папка с файлами, имеющая то же имя. Файловая система 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)?


Название: Re: Объединение кэшей с разных компьютеров
Отправлено: mai62 от 27 сентября 2010, 23:34:23
Файл, поступивший с URL http://server/name, получит имя cache\server\name\#_


Название: Re: Объединение кэшей с разных компьютеров
Отправлено: popkov от 27 сентября 2010, 23:36:19
Файл, полученный с URL http://server/name, получит имя cache\server\name\#_
Понятно, а во второй ситуации как?

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


Название: Re: Объединение кэшей с разных компьютеров
Отправлено: DenZzz от 27 сентября 2010, 23:44:16
Понятно, а во второй ситуации как?

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

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


Название: Re: Алгоритм преобразования URL в имя файла в кэше
Отправлено: zed от 01 марта 2018, 17:46:49
mai62
Можете выложить актуальную версию юнита UrlToCache?