v0lt
|
|
« Ответ #200 : 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= ... другую страницу
|
|
|
|
|
Михаил
|
|
« Ответ #201 : 20 апреля 2007, 10:03:15 » |
|
набри в гугле HandyCache%41 получишь в ответе страницы со строками "HandyCache" и "41", и нигде не увидешь выделенное значение кода %41
Мы говорим не о строке поиска Google, а об URL. А он будет содержать параметр не HandyCache%41, а HandyCache%2541. Проверь на практике - получим ту же самую! Посмотри 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.
|
|
|
|
|
v0lt
|
|
« Ответ #202 : 20 апреля 2007, 20:52:27 » |
|
МихаилПроверь на практике - получим ту же самую! Клянусь зашел на http://www.google.ru/ig?hl=ruввел HandyCacheA, а гугл меня спрашивает "Возможно, вы имели в виду: Handycache" А я ему HandyCache%41 и надо же, нашел! Если надо скриншоты сделаю PS: Если заходить по ссылкам, то HandyCache%41 превращается в HandyCacheA, а вот если прямо на странице вводить, тогда результат разный получается. Посмотри rfc3986 п.2.3: Написано логично, но не все его читали
|
|
|
|
|
Михаил
|
|
« Ответ #203 : 20 апреля 2007, 21:26:11 » |
|
Если заходить по ссылкам, то HandyCache%41 превращается в HandyCacheA, а вот если прямо на странице вводить, тогда результат разный получается.
При чем тут строка google, никак не пойму. URL-ы при этом совершенно разные. Разные URL-ы (разные, заметь, не различием А - %41) - разные результаты. Имхо, один из нас путается.
|
|
|
|
|
popkov
|
|
« Ответ #204 : 20 апреля 2007, 22:19:23 » |
|
Разные URL-ы (разные, заметь, не различием А - %41) - разные результаты. Можно просто привести две эти ссылки: Поиск в Google строки "HandyCache%41"Поиск в Google строки "HandyCacheA"Совершенно очевидна правота Михаила. В первом случае предлагаемый им FixURL ничего не изменит в URL, во втором - тоже. Они останутся такими, какие есть, если не декодировать код %25. Насчёт того, что Internet Explorer в строке состояния отображает первую ссылку в декодированном виде (символ процента не закодирован %25) - это просто свойство IE - он для удобства пользователя декодирует коды символов! Это, кстати, очень удобно! Только он почему-то "не догадывается" в строке состояния о существовании кодироваки Win-1251 - все русские буквы в строке состояния декодирует кракозябрами... Очередной глюк IE.
|
|
|
|
|
Михаил
|
|
« Ответ #205 : 04 мая 2007, 11:12:43 » |
|
volt В URL->FileName для чего кодируем знак "?" не везде одинаково, а двумя разными вариантами - "^\" и "#^"?
|
|
|
|
|
v0lt
|
|
« Ответ #206 : 04 мая 2007, 19:44:23 » |
|
volt В URL->FileName для чего кодируем знак "?" не везде одинаково, а двумя разными вариантами - "^\" и "#^"?
Первый знак вопроса указывает что дальше пойдут т.н. параметры. Поэтому мы их отделяем в отдельную папочку с помощью "\" (сочетание "^\" сложилось историчеки). Последующие знаки вопроса мы кодим иначе, для того чтобы получилось только имя файла (без папок). (символ "/" кодится по-разному по этой же причине). Так очень удобно, потому что в ранних версиях HC файл урла из-за "параметров" мог находиться очень глубокой цепочке папок (часто получалось очень много разных вложенных папок и в кажндой папке по 1..2 файла).
|
|
|
|
|
Михаил
|
|
« Ответ #207 : 05 мая 2007, 00:05:06 » |
|
VoltСпасибо. Т.е. кодируем "^\" только первый знак вопроса, сколько бы этих знаков вопроса ни было. Просто в xls-файле не очень понятно вышло насчет кодирования знака "?" до и после знака "?", потому и вопрос возник. Фу ты каламбур какой-то
|
|
|
|
|
v0lt
|
|
« Ответ #208 : 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?
|
|
|
|
|
v0lt
|
|
« Ответ #209 : 19 мая 2007, 15:03:45 » |
|
файлики к посту выше...
|
|
|
|
|
Михаил
|
|
« Ответ #210 : 20 мая 2007, 22:32:28 » |
|
файлики к посту выше...
У меня exe выпадает с ошибкой, не запускаясь: "Ошибка при инициализации приложения (0хс00000135). Для выхода из приложения нажмите кнопку "ОК".
|
|
|
|
|
v0lt
|
|
« Ответ #211 : 20 мая 2007, 22:55:25 » |
|
МихаилУ меня exe выпадает с ошибкой, не запускаясь: "Ошибка при инициализации приложения (0хс00000135). Для выхода из приложения нажмите кнопку "ОК". странно, я в коде поменял только символ "_" на "." в двух местах завтра проверю на работе...
|
|
|
|
|
Михаил
|
|
« Ответ #212 : 22 мая 2007, 20:14:17 » |
|
Volt А на другом компе запускается без проблем. Непонятно.
|
|
|
|
|
v0lt
|
|
« Ответ #213 : 22 мая 2007, 22:49:13 » |
|
А на другом компе запускается без проблем. Непонятно. Если предыдущая версия работает, то можешь тестить её (разница там лишь в первом символе при сортировке по домену). Если вообще никакая версия не работаетб капай в сторону .NET v2.0 (сравни версии). У меня все нормльно...
|
|
|
|
|
Дем
Постоялец
Репутация: +6/-3
Offline
Сообщений: 167
|
|
« Ответ #214 : 27 августа 2007, 15:26:01 » |
|
Глюк взаимодействия с файловой системой обнаружил... Если имя папки с точками на конце (например Other...) - то винда такую папку не создаёт...
|
|
|
|
|
cepera_ang
|
|
« Ответ #215 : 28 августа 2007, 18:30:15 » |
|
Она и не создаст А если особыми методами создать - то и удалить не получится. Ну глючит ФС винды на точках
|
|
|
|
|
DenZzz
|
|
« Ответ #216 : 28 августа 2007, 20:47:37 » |
|
Хорошо бы учесть этот баг Винды с точками в будущем алгоритме преобразования URL...
|
|
|
|
|
v0lt
|
|
« Ответ #217 : 28 августа 2007, 22:06:41 » |
|
Дем DenZzz проблема решаема аналогично "\" на конце путь\ -> путь\#_ путь. -> путь.#_ путь -> путь #_ (для случая если %20 был заменен на пробел)
PS: описано в URL2filename_ver1_3beta4.xls, базовая часть, решение проблем. В новом алгоритме тоже реализовано.
Преобразование путь. -> путь.#_ в принципе и в текущую версию можно внедрить, проблем быть не должно.
|
|
|
|
|
Сергей
|
|
« Ответ #218 : 08 ноября 2007, 11:34:32 » |
|
PS: описано в URL2filename_ver1_3beta4.xls,
Где лежит этот файлик?
|
|
|
|
|
DenZzz
|
|
« Ответ #219 : 08 ноября 2007, 13:15:56 » |
|
Где лежит этот файлик?
Прикреплен к одному из постов v0lt-а выше.
|
|
|
|
|
|