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

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

Сообщений: 349


« Ответ #20 : 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". Это не супер-прозрачно, поскольку букву интуитивно хочется произнести про себя, а не связывать с предшествующим служебным символом, но намного лучшее решение мне тоже придумать непросто. В качестве альтернативы могу предложить "#&". Два служебных символа легче связать друг с другом, чем букву со служебным символом - ведь при чтении текста все небуквенные символы воспринимаются как скобки!
Двойные кавычки можно кодировать как "#''" - три символа, но зато очень ясно.
А символы больше-меньше - как предложил Дем: больше - "#)", меньше - "#(". Надо запомнить только сходство между ">" и ")" и между "<" и "(".
Осталось ещё придумать, как кодировать два слэша: "//".
Сообщить модератору   Записан
DenZzz
Модератор
*****

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

Сообщений: 5589



« Ответ #21 : 28 Февраль 2007, 21:13:22 »

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

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

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

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

Сообщений: 621



« Ответ #22 : 28 Февраль 2007, 21:28:44 »

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

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

Сообщений: 5589



« Ответ #23 : 28 Февраль 2007, 22:03:18 »

Что касается отдельного символа "/", то я сильно сомневаюсь, что его стоит вообще кодировать - проще создать подпапку.

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

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

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

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

Сообщений: 127


« Ответ #24 : 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 и более получим соответственно
/// -> \#%#%
/// -> #%#%#%

Основной критерий, которого я придерживался - это однозначность преобразований.
« Последнее редактирование: 28 Февраль 2007, 23:08:44 от v0lt » Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #25 : 01 Март 2007, 07:04:30 »

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

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

Пункты 1..4 естественно придется согласовывать с mai62 Подмигивающий

сегодня вечером напишу ситуацию по первому пункту
Сообщить модератору   Записан
Сергей
Beta tester
*****

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

Сообщений: 621



« Ответ #26 : 01 Март 2007, 07:34:04 »

5. Написание конвектора кеша (я могу этим занятся)
Нужен универсальный конвертор исправляющий файлы и папки в кэше после редактирования списка Преобразование URL.
Обычные утилиты пакетного переименования тут не катят, т.к. работают только с именами файлов и не в состоянии обработать полное имя включаящее папки.
Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #27 : 01 Март 2007, 21:14:27 »

Сергей
Цитировать
Нужен универсальный конвертор исправляющий файлы и папки в кэше после редактирования списка Преобразование URL.
Сделать можно, только есть одна заковырка. Создали мы некое правило, ввели в его конвертер, преобразовали кеш. Упс! Правило неправильное, хотим другое или просто хочется его отключить. А уже всё, поезд уехал. В обратную сторону конвертер не сработает. Даже если специально написать еще одно правило, данных может не хватить...
Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #28 : 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 тоже не могу, инфы нет), поэтому есть теоретическая вероятность разночтений. Поэтому правило не менял, только выделил. Можно заменять так - ? -> #\ .
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #29 : 02 Март 2007, 11:15:17 »

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

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

Сообщений: 349


« Ответ #30 : 02 Март 2007, 11:38:20 »

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

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

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

Сообщений: 127


« Ответ #31 : 02 Март 2007, 20:00:43 »

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

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

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

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

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

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

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

Сообщений: 127


« Ответ #32 : 02 Март 2007, 20:10:25 »

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

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

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

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

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

Сообщений: 167



« Ответ #33 : 03 Март 2007, 14:26:30 »

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

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

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

Сообщений: 349


« Ответ #34 : 03 Март 2007, 17:30:04 »

Это НЕ стандарт, а побочный эффект невозможности использовать их в HTML-файле.
Вот это правильное понимание! Так и надо!
Но для читабельности кеша лучше перевести его назад.
Полностью согласен! Мои правила декодируют все символы, которые могут быть закодированы (перечень взял со страницы http://ru.wikipedia.org/wiki/URL ). Я считаю, что нечитаемых кодов в кэше не должно быть! А символ "#", если он встретится в закодированном виде, надо декодировать в удвоенном виде для однозначности: "##".
Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #35 : 03 Март 2007, 22:19:06 »

Это НЕ стандарт, а побочный эффект невозможности использовать их в HTML-файле.
спорить не буду, можете почитать http://www.lib.ru/WEBMASTER/rfc2068/rfc2068rus.txt

Мои правила декодируют все символы, которые могут быть закодированы (перечень взял со страницы http://ru.wikipedia.org/wiki/URL ).
хорошо, только не мог бы ты свой список написать в виде
%xx - @
чтобы сразу было видно, что было в урле и что мы получим в файле

PS: я тут немного поразмыслил и теперь мне кажется, что коды в диапазоне %01...%7f вообще не стоит декодировать Грустный Когда будет список, поясню...
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #36 : 04 Март 2007, 13:53:46 »

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

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

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

Сообщений: 127


« Ответ #37 : 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}
примерно так?
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #38 : 05 Март 2007, 20:55:11 »

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

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

Сообщений: 127


« Ответ #39 : 05 Март 2007, 22:14:26 »

Только с символами <> ты напутал немного...
Ладно, это не принципиально.

Тут основная проблема - это преобразования URL->FileName->URL. Я считаю, что алгоритм должен быть такой, что зная полное имя файла, я мог бы получить исходный урл. Это основное требование. Преобразования кодов %xx в "прозрачные" символы в большинстве случаях противоречит такому требованию.
Завтра постараюсь все растолковать с примерами (сегодня спать хочется...)
Сообщить модератору   Записан
Страниц: 1 [2] 3 4 ... 13   Вверх
  Отправить эту тему    Печать  

 
Перейти в: