Можно попытаться это определить! Наглядный пример - сервер Яндекса, который сам определяет кодировку в запросе!
Коды символов в UTF-8 всегда "двойные" и начинаются с %D0 или %D1 - это можно использовать для определения кодировки в URL-е...


Пока Россия - это основная целевая аудитория, но, заботясь о будущем, можно вынести перекодировочную таблицу в отдельный файл-список. Тогда каждый иностранец сможет сам задать коды для перекодировки в свой алфавит.

Еще не стоит забывать, что HC работает под Windows и свой WIN есть в каждой локализованной Винде!

На счет KOI-8 - можешь привести реальный рабочий URL, где используется кодировка KOI-8 без явного на то указания в самом URL-е?


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

А во-вторых, тот сервер ру-борда не понимает Юникод, но зато прекрасно понимает WIN:
http://forum.ru-board.com/forum.cgi?action=filter&forum=35&filterby=topictitle&word=%CF%F0%E8%EC%E5%F0
Именно в таком виде страница ру-борда отправляет запрос на свой сервер, когда ты фильтруешь там темы в списке!

Кодировка WIN применяется во многих URL и на многих сайтах! Так почему же не хранить подобные URL-ы на диске в "прозрачном", читабельном виде?!

HC тоже может глянуть, какая страница в кэше уже есть...

Я имел в виду WIN и KOI. Однобайтовую кодировку от юникода отличить легко, разумеется.

Возможно и так.

Ты случайно не кликнул на этой ссылке? Надо было скопировать строку вручную. Форумный движок сам заменил русские буквы на коды.

Согласен. При условии сохранения информации о кодировке для возсожности обратного преобразования.

пишу алгоритм... дошел до декодирования уникода (%xx%xx) и пробела (%20)
обнаружил неприятность в алгоритме:

Согласно алгоритму после символа "?" имеем / -> #%
если имеем урл вида - site.com/page.htm?100/20=5
то получим - site.com\page.htm^\100#%20=5
Если за основными преобразованиями последует декодирование кодов вида %xx, то получим глюки. Придется его ставить в начале
Если сделаем конвертер кеша, который будет преобразовывать %xx согласно поддерживаемым в НС кодировкам, то надо будет не забыть проверку на наличие символа # перед %. Вот такие заморочки...

Еще вариант не использовать #% (совместимость пострадает). Взамен остались #; #, #z или #! (если : -> #=)

Сделал первый вариант кодирования (пока не все фичи)
измения v1.1:
/ -> #!
// -> \#! -?- #!#!
: -> #=
файлы прилагаются
внутри архива таблица "что и как" и конвертор (нужен dotNetFX 2, идет с некоторыми крупными прогами и игрушками)
Конвектор работает очень просто, вводите урл и видите как он будет выглядеть на диске и как он востанавливается обратно...

DenZzz
ну понятно же... (поправил у себя)

DenZzz
было такое, но там был конвертор работающий с самим кешем...
когда дойдет до настоящего конвертора переведу код на Дельфи (наверно за основу возьму предыдущий вариант). сейчас пишу на C#, мне так проще...

PS: Есть Turbo Delphi (BDS2006) на нем можно безпроблемно написать для Win98 или нужен Delphi 7 ?

Чем тебе .Net не угодил? Он и под Win98 ставится. Я бы и сам HC под Net не отказался использовать. С совместимостью было-бы намного лучше.

Rick
ну я бы не сказал, например C# вообще без dotNET не напишешь
был Delphi 8 - это вообще непонятно что, старые проекты не компилятся
Сейчас стоит Turbo Delphi 10 (Borland Developer Studio 2006) вроде нормально, проекты из Delphi 7 запускаются

Всем
Не беспокойтесь, будет конвертор без .NET. Сделаю когда отладим алгоритм и mai62 дасть добро...

Абсолютно верно. Причем еще нужен ручной конвертор. Без него пока сложно использовать список Преобразование URL без потери имеющихся в кэше данных.

С Windows Mobile. Чтобы иметь возможность использовать HC и на коммуникаторе.

Так, думаю стоит обсудить проблему длинных урлов.
Эту тему я как-то обсуждал с mai62, но в тот момент революция не планировалось, поэтому этот ворпрос был отложен...

Сейчас алгоритм работает так:
  На последнем этапе преобразования урла в имя файла проверяется длина имени (относительно папки кеша). Если она больше 200, то мы находим последний символ "\" в пределах первых 192 символов. Строку до символа "\" оставляем, а оставшееся кодируем хешем CRC32:

[путь<192]\[CRC32(путь>192)]


Я предлагаю:
- высчитывать CRC32 на основе URL, а не имени файла. Так будет более однозначный результат и меньше вероятнось потерь при преобразованиях.
(урл брать уже пофиксеный, без багов IE)
- помечать строку хеша. Так будет стразу понятно, что это урл был длинным.
- сделать опцию типа "Для длинных URL сохранять *.url". Возможно кому-то может понадобиться узнать реальный урл.

Алгоритм такой:
 Проверяем длину имени (относительно папки кеша). Если она больше 200, то мы находим последний символ "\" в пределах первых 190 символов. Строку до символа "\" оставляем, плюс добавляем помеченный хеш урла без хоста. Помечать предлагаю кодом #- :

[путь<190]\#-[CRC32(урл_без_хоста)]   

 IMHO Хост кодить не надо. Причины: В зависимости от настроек .www может как отбрасываться, так и нет. Иногда сайты меняют хостинг, оставляя структуру, и чтобы ничего не пропало, юзер может просто переименовать соответствующую папку.
+ очень легко реализуемо
+ на CRC практически ничего не влияет