popkov
вот часть кода получения урла из файла:
private string File2URL(string filename)
{
  string s = filename;
  int i;
//.................................
  if (s.IndexOf("`") >= 0)
  {
    s = s.ToLower();
    for (int j = 33; j < 65; j++)
      s = s.Replace('`'+ russian_chars[j], russian_chars[j-32]);
    s = s.Replace("`ё", "Ё");

    for (char j = 'a'; j <= 'z'; j++)
    {
      s = s.Replace('`' + j.ToString(), j.ToString().ToUpper());
    }
  }
  if (checkBox_unicode_rus.Checked) s = escape_unicode_rus(s);
  if (checkBox_Win1251.Checked) s = escape_Win1251_rus(s);

  return s;
}
если в имени файла появятся `` будет сложнее и медленнее...

по поводу опонентов ты прав, маловато...
тогда поступим так, что mai62 по поводу "(%22) скажет:
- не декодируем
- кодируем как #'
- кодируем как ``
то и сделаем (мне лично нравятся два первых варианта)

По поводу < (%3c) > (%3e) -> #{ #} или #( #) - аналогично

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

Сергей
нет еще, но файлы с именами из японских иероглифов создаются

popkov
Не стоит вообще самовольно кодировать через #. Символ # является служебным для HC. обычный пользователь не знает какие коды используются, какие появятся в будущем, такое использование символа # может привести к нарушению структуры кеша.

я произвольно переименовывал в тотале, работает, алгоритм еще не писал...

Поэтому остаются вопросы:
- есть ли символы (кроме первых 256) которые нельзя использовать в именах файлов
- где-нибудь описаны границы "виндового" уникода
- что будет если из %xx%xx или %xx%xx%xx (иероглифы) я получу символ которого нет или не знает винда

Windows знает все символы, т.к. она понимает юникод.
Проблемы возникают со старыми программами, которые его не понимают. Например, FAR.
HC к ним не относится

Кстати, обнаружил, похоже, 1 ошибку и 1 глюк в текущей реализации алгоритма URL2File.
Глюк очень простой: HC почему-то игнорирут переадресацию (файл #m), когда получает от браузера запрос. Вот пример:
Зайдите по ссылке:
http://www.goupsoft.com/ezsavemht
Если заходите в первый раз, то сервер переадресует на
http://www.goupsoft.com/ezsavemht/
и страница отобразится правильно.
Теперь, ключив, например Автономный режим (или режим Не обновлять ".*"), попробуйте зайти по первой ссылке снова - HC не переадресует, как это делал сервер, и перед вами откроется страница с неправильным URL http://www.goupsoft.com/ezsavemht на которой будет отсутствовать часть картинок!
А отсутствовать они будут потому, что внутри кода страницы ссылки на них оформлены так:
И если в адресной строке URL правильный (то есть http://www.goupsoft.com/ezsavemht/), то результирующая ссылка будет такой:
http://www.goupsoft.com/ezsavemht/image/ez_save_mht_screenshot_1.gif
А если URL неправильный ( то есть http://www.goupsoft.com/ezsavemht), то ссылка получится такой:
http://www.goupsoft.com/image/ez_save_mht_screenshot_1.gif
Последняя ссылка никуда не ведёт, такого файла нет ни в кэше HC, ни на сервере!

Так вот, причиной этого глюка является то, что HC игнорирует лежащий в кэше файл
...\ezsavemht\#m
и вместо него сразу выдаёт файл
...\ezsavemht\#_
- и вэб-страница отображается неверно, поскольку относительные ссылки генерируются неверно, исходя из неверного URL.

Это был глюк. А теперь вопрос: а может быть сервер, у которого по адресам
http://www.goupsoft.com/ezsavemht/
и
http://www.goupsoft.com/ezsavemht
на самом деле лежат два разных файла? В этом случае HC, как я понимаю, будет оба этих URL писать в кэше в один и тот же файл - в файл
...\ezsavemht\#_
То есть возникает неоднозначность обратного декодирования. Если это так, то это - ошибка!

Похоже, ты и правда устал. Иногда и отдых нужен.
А вот #m удалять не нужно - как раз наоборот, его нужно искать в первую очередь, чтобы была хоть какая-то возможность быть переадресованным на нужный URL - иначе страница будет неправильно отображаться (см. мой детальный пример ). Это связано с относительными ссылками на картинки в коде страницы - такая относительность является обычным делом! Исключением скорее являются сайты, где ссылки в коде страницы абсолютные!
И поэтому наличие или отсутствие знака "/" в конце URL отображаемой страницы оказывается принципиальным моментом в том, откуда будет пытаться браузер загрузить картинки, содержащиеся в коде страницы.
А причина, почему это до сих пор не всплывало - редко бывают неправильные ссылки на страницу, в конце которых опущен символ "/". Однако именно неправильную ссылку я встретил на другой странице того же сайта, которая и привела меня к обнаружению сего глюка!
Надо просто в первую очередь выдавать файл с переадресацией - файл #m!
Неужели ничего нельзя придумать?

А как, кстати, будет вести себя HC если надо записать в кэш URL
http://www.goupsoft.com/ezsavemht/
а там уже записан URL
http://www.goupsoft.com/ezsavemht
(оказался записан раньше каким-то чудом - теоретически это возможно)
Что HC будет делать, если нужно создать папку ezsavemht, а уже есть файл с таким именем?

Проверил: HC переименовывает файл ezsavemht в ezsavemht#_, и далее создаёт папку ezsavemht. Интересно!

Выходит, автор HC уже и без нас наполовину решил описанную проблему - а мы даже и не догадывались!
mai62 Respect! 
И ничего "извращенского" в таком решении я не вижу - вполне логичное и простое решение!

Кто-то может и не догадывался. А на руборде этот вопрос обсуждался точно.

Мне кажется запись файла редиректа в папку при запросе http://www.goupsoft.com/ezsavemht
является ошибкой. Даже если папка есть, надо записывать в файл ezsavemht#m а не в ezsavemht\#m

Эти тонкости тоже являются частью обсуждаемого алгоритма.

Это не выход! Файл #m может быть старым, а #_ - новым, тогда в автономном режиме будешь постоянно попадать на старую переадресацию!
Правильней действовать, как озвучил v0lt:

Согласен с этим решением.
Теперь неплохо озвучить уже реализованный в текущей версии HC способ обхода ситуации с файлом и папкой, имеющими одинаковые имена. Сейчас HC при создании папки ведёт себя так:
Тем не менее, даже при наличии файла ezsavemht#_ HC по запросу
http://www.goupsoft.com/ezsavemht
лезет в ezsavemht/#_
а не выдаёт имеющийся файл ezsavemht#_
Это - ещё один глюк!

Вылечить его можно так: HC никогда не должен залезать в подкаталог большей вложенности, чем тот, который подразумевается в URL! Если вместо файла HC обнаружил в кэше поддиректорию, HC должен искать файл с суффиксом #_, не залезая в эту поддиректорию!

Насколько я понимаю (хотя глубоко не вникал в это), для файловой системы (во всяком случае, NTFS) файл и папка - одно и то же. Поэтому запрос о наличии какого-то пути (не оканчивающемся на "/") даст положительный результат, независимо от того, файл найден или папка. Но наверняка информация о том, что найдено, будет предоставлена файловой системой! Поэтому дальнейшие действия будут ясны:

Если найден файл - выдаём его
Если найдена папка - ищем (не залезая в неё!) файл с суффиксом #_ (в нашем случае это ezsavemht#_) и выдаём его
Если ни того, ни другого не найдено - выдаём сообщение, что файла нет в кэше!

На самом деле всё ещё интереснее. При входе например на ЖЖ происходит переадресация на некий файл, проводящий авторизацию и потом с него назад. И с нужными куками по тому же адресу происходит уже не переадресация, а выдача контента.
Т.е. в этом случае оптимальным было бы #m в кеш не писать вообще (но в браузер выдать)