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

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

Сообщений: 127


« Ответ #120 : 22 марта 2007, 07:00:27 »

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

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

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

Сообщений: 621



« Ответ #121 : 22 марта 2007, 07:16:32 »

Пример: файлы с handycache.ru лежат в \_h_\handycache.ru\
файлы с forum.ru-board.com лежат в _r_\forum.ru-board.com\
домены начинающиеся на цифры лежать в _0_\
Подчеркивание тут лишнее. Давно пора сделать так. В CoolProxy это называлось компактным режимом, кажется.
Сообщить модератору   Записан
Сергей
Beta tester
*****

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

Сообщений: 621



« Ответ #122 : 22 марта 2007, 07:47:39 »

Еще раз по поводу длины.
Цитировать
...имея дело с файлами, всегда необходимо помнить об ограничении длины полного имени файла, накладываемого операционной системой. Для 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.
Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #123 : 22 марта 2007, 18:30:19 »

Сергей
Цитировать
Для Windows NT/2000 доступны UNICODE-версии функций, которые способны расширить этот предел вплоть до 32767 UNICODE символов.
Это хорошо, только на практике толком не работает. Я даже сам пытался вызвать уникод-функции, не получилось, мутно все описано...

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

Тогда можно так:
h\handycache.ru\
r\ru-board.com,forum\
m\mail.ru,img.photo\
Сообщить модератору   Записан
Сергей
Beta tester
*****

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

Сообщений: 621



« Ответ #124 : 22 марта 2007, 20:02:49 »

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

С запятой это интересная идея!
А последнюю строку как рассшифровать?
Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #125 : 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\  (туда же где "циферные" домены?)
Сообщить модератору   Записан
Сергей
Beta tester
*****

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

Сообщений: 621



« Ответ #126 : 23 марта 2007, 12:31:27 »

Нормально.

А как к таким преобазованиям отнесется Историк?
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #127 : 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%
Действительно, немного...
Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #128 : 24 марта 2007, 09:19:50 »

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

Поэтому чтобы не было проблем, придется чуток дорабатывать Историк. Хотя если алгоритм поменяется, дорабатывать придется все равно...
« Последнее редактирование: 24 марта 2007, 09:34:04 от v0lt » Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #129 : 27 марта 2007, 23:37:25 »

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

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

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

* URL2filename_ver1_3beta.zip (19.58 Кб - загружено 37 раз.)
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #130 : 27 марта 2007, 23:52:54 »

-добавлена сортировка по домену (используется префикс "_");

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

Встроенная сортировка может быть только опциональной! Меня, например, вполне устраивает придуманная мной структура кэша, и менять её я не хочу!

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

И хотелось бы, всё-таки, чтобы двойная кавычка кодировалась предложенным мной понятным способом: ``
« Последнее редактирование: 28 марта 2007, 00:10:58 от popkov » Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #131 : 28 марта 2007, 21:47:12 »

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

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

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

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

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

Сообщений: 349


« Ответ #132 : 29 марта 2007, 02:07:27 »

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

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

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

А алгоритм преобразования должен быть в любом случае написан максимально универсально - так, чтобы ложные срабатывания были исключены (и это вопрос требует отдельного детального обсуждения).
« Последнее редактирование: 29 марта 2007, 02:29:09 от popkov » Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #133 : 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 это относится, но и к любым другим посковикам на любых сайтах! Двойная кавычка - общепринятый морфологический признак задания точного вхождения! Она несёт большую смысловую нагрузку, зачем её оставлять нечитабельной???
« Последнее редактирование: 29 марта 2007, 03:14:33 от popkov » Сообщить модератору   Записан
Сергей
Beta tester
*****

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

Сообщений: 621



« Ответ #134 : 29 марта 2007, 10:07:59 »

ЗЫ: как я помню, на FAT-е файлы могут быть только на английском и на языке совпадающей с локализацией винды

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

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

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

Сообщений: 621



« Ответ #135 : 29 марта 2007, 10:24:13 »

Ты, похоже, хочешь отнять у меня свободу кодировать (пока, как я понял, только двойную кавычку) так, как мне кажется оптимальным. Зачем?
Не бойся. Алгоритм URL2Cache работает уже после срабатывания списка Преобразование URL. Так-что ты ничего не потеряешь. Хочешь двойную кавычу - используй.
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #136 : 29 марта 2007, 12:39:19 »

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

Раньше использовался однобайтовый код. По умолчанию, CP437. Мы его можем увидеть на синем экране смерти у русской Windows.
Интересно, на синем экране смерти и в последних версиях NT (2000 и XP) тоже используется эта кодировка? Вот почему он всегда нечитабельный...
И тут уже символы кодируюся двумя байтами кодировки UTF-16LE. В NTFS Юникод имеет приоритет и короткое имя иногда вообще не сохраняется.
То есть можно и под и под FAT и под NTFS декодировать полный набор символов Юникода? А под Linux это будет работать (тут есть энтузиасты, использующие HC под Linux)?
« Последнее редактирование: 29 марта 2007, 12:46:22 от popkov » Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #137 : 29 марта 2007, 12:55:57 »

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

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

Сообщений: 621



« Ответ #138 : 29 марта 2007, 19:27:38 »

Интересно, на синем экране смерти и в последних версиях NT (2000 и XP) тоже используется эта кодировка? Вот почему он всегда нечитабельный...
Руки бы поотрывать тому, кто догадался локализовать экран смерти. Русификатор там не срабатывает и шрифты берутся те, что зашиты в видеокарте. Разумеется, что там нет русских букв.

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

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

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

Сообщений: 349


« Ответ #139 : 29 марта 2007, 19:36:22 »

Этого не может случиться, т.к. # отбрасывается до обработки списка Преобразование URL.
Серьёзно? Ну слава богу... а то я уж решил, что и здесь подстава... Не так всё плохо, так что настаиваю по-прежнему только на кодировании двойной кавычки, поскольку её закодировать наиудачнейшим способом через "Преобразование URL" при новых правилах уже не получится, а очень бы хотелось... Да и зачем вообще делать что-то непрозрачно, если можно сделать просто и ясно???
Сообщить модератору   Записан
Страниц: 1 ... 5 6 [7] 8 9 ... 13   Вверх
  Отправить эту тему    Печать  

 
Перейти в: