Interceptor
Цитата:
Скачай последнюю версию, линк в шапке.
Цитата:
Перешел с версии 94б2 на 95б1. Начались глшюки
Скачай последнюю версию, линк в шапке.
Перешел с версии 94б2 на 95б1. Начались глшюки
http://rose.ixbt.com/phones/search.php?Firma=&weight_min=&weight_max=&TimeTalk=&TimeWait=&Battery=&DisplayLines=&Color=0&Colors=&Network2=on&MinPrice=&MaxPrice=&Feature10=-1&Feature46=-1&Feature32=-1&Feature24=-1&Feature27=-1&Feature9=-1&Feature44=-1&Feature45=-1&Feature41=-1&Feature40=-1&Feature48=1&Feature8=-1&Feature43=-1&Feature34=-1&Feature2=-1&Feature4=-1&Feature15=-1&Feature28=-1&Feature38=-1&Feature16=-1&Feature26=-1&Feature6=-1&Feature22=-1&Feature7=-1&Feature5=-1&Feature11=-1&Feature1=-1&Feature3=-1&Feature33=-1&Feature39=-1&Feature19=-1&Feature35=-1&Feature21=-1&Feature18=-1&Feature25=-1&Feature29=-1&Feature31=-1&Feature12=-1&Feature36=-1&Feature30=-1&Feature42=-1&Feature23=-1&Feature17=-1&submit=%CD%E0%E9%F2%E8%21
Поставил НС, картинки в списке "Не обновлять", но HC постоянно запрашивает их на сервере! Процент "экономии" очень низкий! Почему?
"Виноват" кэш браузера! "Неправильный" браузер (например, IE) видит файл в своем кэше и запрашивает в Инете, изменился он или нет. НС каждый раз транслирует запрос и получает ответ сервера "Not Modified". Сам файл при этом не скачивается и не попадает в кэш HC. Естественно, каждый раз будет тратиться время и трафик на выполнение такого запроса!
Чтобы избежать данной ситуации, нужно почистить кэш браузера и уменьшить его размер до минимума (1 Мб) или отключить совсем.
Это правильный ответ?
для IE выставить опцию "Проверять наличие обновления сохраненных страниц:" - "Никогда"
при совпадении "rose.ixbt.com/phones/search" заменить все "Feature" на "#"
когда планируется сделать сохранение длинных урлов?
Чтобы избежать данной ситуации, нужно почистить кэш браузера и уменьшить его размер до минимума (1 Мб) или отключить совсем.
Ключевые слова: "почистить кэш браузера",
когда планируется сделать сохранение длинных урлов?
как в преобразованиях сделать замену всех "Feature" ?
примерная логика правила:
при совпадении "rose.ixbt.com/phones/search" заменить все "Feature" на "#"
Хорошо бы найти алгоритм преобразования длинной строки в более короткую. Умеют же архиваторы жать текстовые фыйлы в разы.
А на самом деле, почему бы не преобразовывать имя слишком длинного файла в кэше в MD5 его имени и сохранять рядом, скажем, файл MD5.url с полным URL-ом? Эти файлы класть в папки соответствующих сайтов.
Только есть одно НО, делать обратное преобразовывание будет очень сложно
А md5($url) не подойдет? А потом сравнивать с md5 страницы. Совпало - грузить из кеша.
С новой версией приколы продолжаются. На запрещенные урл (когда срабатывает правило из черного списка) выдается кусок черного списка. Юзаю черный список, который тут выкладывался однажды.
Кстати, а можно где-нить в мониторе сделать, чтобы фиксировался общий размер загруженной страницы?
2. Выделить имя файла (без пути) и если оно больше 200 байт, то имя файла составить из след. частей:
- первые 200 байт имени файла
- символ #
- md5 имени файла.
Так наибольшая длина имени файла в винде считается именно для полного пути.
- первые 200 байт имени файла
- символ #
- md5 имени файла.
Странно. Разве имя файла с полным путем где-нибудь хранится целиком? Мне кажется нет. А зачем тогда его ограничивать?
Обратное преобразование имени файла в url будет невозможно.
Если дадите функцию для дельфи преобразующую строку в md5, то могу внедрить ее в свой вариант преобразователя.
Для экономии места предлагаю вместо md5 использовать crc32
Сделал эксперимент. В ФАТ32 макс. длина пути вместе с именем файла 258 символов.
код отправил на мыло
В черном списке, выложенном в шапке есть 6-е правило...
Кстати о Avant Browser...
...имея дело с файлами, всегда необходимо помнить об ограничении длины полного имени файла, накладываемого операционной системой. Для 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. Поэтому, ограничение на длину пути может быть преодолено.
Unicode-версии функций CreateDirectory, FindFirstFile, GetFileAttributes, и SetFileAttributes позволяют использовать пути, превышающие длину MAX_PATH, если путь имеет префикс "\\?\" or "\\?\UNC\". Эти префиксы указывают функции на необходимость отключения проверки пути. Используйте "\\?\" префикс для путей на локальных носителях, а "\\?\UNC\" для путей, которые имеют UNC-формат.
Universal Naming Convention
Universal Naming Convention - сокращенно UNC, можно дословно перевести как "Универсальное Соглашение об Именах", это формат для записи пути к файлу расположенному на удаленном компьютере. Он имеет вид "\\server\share\path". Server это, как ни странно сервер, share - это расшаренный ресурс на нем, а дальше следует путь к файлу в обычном формате. Такой способ доступа к файлам можно использовать и для локальной машины, только в этом случае вместо "server" нужно подставлять "?" или ".", а путь к файлу указывать вместе с буквой диска. Например так: "\\?\C:\folder\file.txt".
Например, Архивариус не сможет проиндексировать страницы с длинным именем.
Страницы: 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667
Предыдущая тема: грабилка экрана под OpenGL