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

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

Еще раз по поводу длины.

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

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

Нормально.

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

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

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

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

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

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

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

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

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

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

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

Ты проверял?

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

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

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

Получается что так. Но надо проверить.

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