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

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

Сообщений: 349


« Ответ #40 : 05 марта 2007, 23:38:01 »

Преобразования кодов %xx в "прозрачные" символы в большинстве случаях противоречит такому требованию.
Здесь ты заблуждаешься. Все символы кодируются двухбуквенными кодами, начинающимися со знака "#". Сам этот знак (если он встретился в URL в виде кода "%23" - а сам по себе он встретиться не может) кодируется в виде "##". Поэтому всё однозначно: если встретился в кэше файл с символом "#" - у нас есть только один способ правильно декодировать. Алгоритм декодирования простой:
"##" -> "#" (а строго говоря, "%23", поскольку ни один реальный URL, отправленный браузером, не может содержать незакодированный символ "#".  Тем не менее, для визуального представления в таких программах, как hc.historian, удобнее код "%23" представлять как "#", но браузеру при открытии страницы отправлять, естественно, в виде "%23")
"#"+символ кроме # -> надо интерпретировать как кодовую последовательность. Ситуация, когда эта кодовая последовательность неизвестна - заведомо исключена, поскольку одиночный символ "#" случайно появиться не может.
Так что твоё основное требование выполняется. Проблем нет. Подмигивающий
В конце концов, это дело разработчиков программ обратного декодирования - как представлять код "%23" в декодированном URL - как код "%23" или как символ "#". Но описанный алгоритм однозначно, ясно и коротко позволяет кодировать/декодировать любой символ.
« Последнее редактирование: 06 марта 2007, 00:20:34 от popkov » Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #41 : 06 марта 2007, 12:20:58 »

Сегодня запустил поиск в логах HandyCache, и, к своему удивлению, нашёл в этих логах аж 9 URL, в которых символ "#" не отброшен (а всего там около 280000 URL). Это оказались:

_http://forum.ru-board.com/topic.cgi?forum=5&bm=1&topic=20528&start=1520#lt

_http://forum.ru-board.com/topic.cgi?forum=5&bm=1&topic=20528&start=1520#lt

_http://popunder.adsrevenue.net/links.php?data=rSe_2/ю/,-0#-+($S\\7Vq^Ye^jV]lюq_ZcY;%20+-,6уlcY;ю)1\'6{1/&1&id=astakiller&subid=63378&tid=1172829513&clater=&m=75&o=1&c=4096&a=65535&q=6&s=<=&ah=10&al=0&l=english&campaign=&rurl=&serverfile=paypopup&ref=http://asta-killer.com/&os=W1&bs=I1&isframe=false&bk=1&serverfile=popnetwork

_http://popunder.adsrevenue.net/links.php?data=rSe_2/ю/,-0#-+($S\\7Vq^Ye^jV]lюq_ZcY;%20+-,6уlcY;ю)1\'6{1/&1&id=astakiller&subid=63378&tid=1172829513&clater=&m=75&o=1&c=4096&a=65535&q=6&s=<=&ah=10&al=0&l=english&campaign=&rurl=&serverfile=paypopup&ref=http://asta-killer.com/&os=W1&bs=I1&isframe=false&bk=1&serverfile=popnetwork

_http://forum.kaspersky.com/index.php?s=8f31675557ec91eadc7d17cff9e7d132&showtopic=17353&st=0&p=143302&#entry143302

_http://forum.kaspersky.com/index.php?s=8f31675557ec91eadc7d17cff9e7d132&showtopic=17353&st=0&p=143302&#entry143302

_http://imho.ws/showthread.php?p=1265969#post1265969]http://imho.ws/showthread.php?p=1265969#post1265969


Выходит, что редко, но всё же происходит глюк, когда браузер отправляет URL с незакодированным символом "#". Это надо просто учитывать - вот и всё!

Интересный вопрос к mai62: в таких случаях, насколько я понимаю, HandyCache не отбрасывает символ "#" вместе со всем, что идёт за ним при записи на диск? Наверное, стоит ещё такое правило ввести, но работать оно должно до всех списков, преобразующих и переадресующих URL.
« Последнее редактирование: 06 марта 2007, 12:32:52 от popkov » Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #42 : 06 марта 2007, 19:59:54 »

Сегодня запустил поиск в логах HandyCache, и, к своему удивлению, нашёл в этих логах аж 9 URL, в которых символ "#" не отброшен (а всего там около 280000 URL). Это оказались:
проверил у себя, в мониторе # нет (IE, Firefox)

Цитата: popkov
Интересный вопрос к mai62: в таких случаях, насколько я понимаю, HandyCache не отбрасывает символ "#" вместе со всем, что идёт за ним при записи на диск?
На всякий случай отбрасывает (см. исходники).
Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #43 : 06 марта 2007, 20:03:17 »

А теперь как обещал...

Вот примеры нормальных урлов (согласно стандарту)
http://site/page?test_$_%24
http://site/page?test_%_%25
http://site/page?test_&_%26
http://site/page?test_'_%27
http://site/page?test_*_%2a
http://site/page?test_,_%2c
http://site/page?test_/_%2f
http://site/page?test_:_%3a
http://site/page?test_;_%3b
http://site/page?test_?_%3f
http://site/page?test_[_%5b
http://site/page?test_]_%5d
http://site/page?test_^_%5e
http://site/page?test_\_%5c
http://site/page?test_{_%7b
http://site/page?test_|_%7c
http://site/page?test_}_%7d
в точно же таком виде они отсылаются серверу в любом браузере.
А что будет если мы проделаем преобразование URL->filename->URL? Правильно, потеряем либо явно заданный символ, либо код. Потому что мы не знаем, был ли закодирован символ изначально.

Теперь более опасные вещи. Символы "/" и "?" несут специальные функции.
Имеем - http://site/page%2f.htm
после URL->filename - ..\site\page#%.htm
затем filename->URL - http://site/page/.htm - это уже серьезно, появилась новая "папка"

аналогично http://site/page%3f.htm?topic=5
URL->filename - ..\site\page#^.htm^\topic=5
filename->URL - http://site/page?.htm?topic=5  - изменились путь и строка параметров
URL->filename - ..\site\page^\.htm#^topic=5 - "^\" и "#^" поменялись местами

PS: HC использует лишь функцию URL->filename
Функция filename->URL требуется для просмотщиков кеша (например hc.Historian)
Функция filename->URL->filename требуется для преобразователей/конвертеров кеша


Остались %20, %22, %23, %3c, %3e, %60 - коды, соответствующие символам (пробел"#<>`), которые по стандарту вообще не могут использоваться в урле в явном виде. Причем "#<> придется кодировать как #', ##, #), #( - не очень наглядно. Остаются `(обратная ковычка) и "пробел".
Имхо из этих 6 символов стоит заморачиваться лишь не пробеле...
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #44 : 07 марта 2007, 02:50:43 »

Теперь более опасные вещи. Символы "/" и "?" несут специальные функции.
Имеем - http://site/page%2f.htm
после URL->filename - ..\site\page#%.htm
затем filename->URL - http://site/page/.htm - это уже серьезно, появилась новая "папка"

аналогично http://site/page%3f.htm?topic=5
URL->filename - ..\site\page#^.htm^\topic=5
filename->URL - http://site/page?.htm?topic=5  - изменились путь и строка параметров
URL->filename - ..\site\page^\.htm#^topic=5 - "^\" и "#^" поменялись местами

Блестящий анализ. Насчёт кодов %2f и %3f - согласен, что декодировать их не нужно.

Остались %20, %22, %23, %3c, %3e, %60 - коды, соответствующие символам (пробел"#<>`), которые по стандарту вообще не могут использоваться в урле в явном виде. Причем "#<> придется кодировать как #', ##, #), #( - не очень наглядно. Остаются `(обратная ковычка) и "пробел".
Имхо из этих 6 символов стоит заморачиваться лишь не пробеле...
А вот здесь не вполне согласен. Раз уж мы не декодируем %2f (слэш "/"), то вполне логично не декодировать и %23 (символ "#"). Это так. Обратная кавычка вряд ли может нести серьёзную синтаксическую нагрузку, и встречается редко (у меня 19 раз, и все - в параметрах баннерных скриптов). Но символ двойной кавычки несёт серьёзную смысловую и синтаксическую нагрузку, и регулярно встречается в параметрах поисковых запросов. Поэтому, для облегчения чтения последних я всё же считаю нужным его декодировать максимально прозрачно. Раз уж мы не декодируем %23, то освобождается супер-удобный код "##", который я и предлагаю теперь использовать для декодирования символа двойной кавычки. Символы <> тоже могут иногда помочь пониманию, и предложенный мной способ их кодирования:
для ">" - код "#}"
для "<" - код "#{"

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

По сути, благодаря отказу от декодирования %23 у нас появилась возможность максимально прозрачно закодировать именно тот символ, который несёт действительно большую смысловую нагрузку - двойную кавычку. И код "##" для неё, по-моему, очень подходит - он легко выделяется глазами внутри имени файла благодаря своей форме и легко запоминается.
« Последнее редактирование: 07 марта 2007, 03:05:46 от popkov » Сообщить модератору   Записан
Дем
Постоялец
***

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

Сообщений: 167



« Ответ #45 : 08 марта 2007, 01:16:40 »

Как мне кажется, преобразование filename->URL не должно восстанавливать исходный URL (это всё равно зачастую невозможно) - а должно давать URL, по которому будет выдан нужный файл в кеше.
Поэтому абсолютно всё равно, в каком виде в нём будут символы - %2a или *
Сообщить модератору   Записан
cepera_ang
Beta tester
*****

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

Сообщений: 355


« Ответ #46 : 08 марта 2007, 11:11:49 »

Как мне кажется, преобразование filename->URL не должно восстанавливать исходный URL (это всё равно зачастую невозможно) - а должно давать URL, по которому будет выдан нужный файл в кеше.
Поэтому абсолютно всё равно, в каком виде в нём будут символы - %2a или *
В чем в нем? В имени файла? Звездочка там не может быть, как некоторые другие символы.
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #47 : 08 марта 2007, 11:38:43 »

В чем в нем? В имени файла? Звездочка там не может быть, как некоторые другие символы.
Имелся в виду, конечно же, именно URL - вопрос поставлен о том, нужно ли его однозначно восстанавливать из имени файла.
Как мне кажется, преобразование filename->URL не должно восстанавливать исходный URL (это всё равно зачастую невозмо.жно) - а должно давать URL, по которому будет выдан нужный файл в кеше.
Поэтому абсолютно всё равно, в каком виде в нём будут символы - %2a или *
В общем-то, восстановление рабочего исходного URL всё же желательно: что будет, если ты захочешь увидеть обновлённую версию вэб-странички, которую отобразил Историк из кэша? Даблкликнешь по ней в списке Историка, и он передаст браузеру восстановленный URL. Конечно, хотелось бы, чтобы в такой ситуации нужная страница была всё-таки открыта.
Другое дело, что нужен именно рабочий URL, а вовсе не абсолютно совпадающий с изначальным. И тут следует обсудить, в каких ситуациях и для каких именно символов декодировка их внутри URL может привести ко глюкам, а в каких - нет.
С символами "/" и "?" - уже всё ясно, лучше их и правда оставить в покое.
Двойные кавычки, пробел и <>, думаю, тоже стоит декодировать для читабельности кэша - они всегда закодированы в URL, и неоднозначности не возникает.
Думаю, ни при каких обстоятельствах декодировка закодированного символа процента ("%25" -> "%") к глюкам привести не может, поскольку символ процента в обоих ситуациях присутствует в явном виде всё равно. Откровенно говоря, у меня большие непонятки, зачем вообще символ "%" зачастую оказывается закодирован в виде "%25"? Например, пробел при этом оказывается закодирован не "%20", а "%2520". И эта ситуация - частое явление (у меня 27887 строк, содержащих такие URL). Это приводит к неслабому удлинению имени файла.
 
« Последнее редактирование: 08 марта 2007, 11:52:13 от popkov » Сообщить модератору   Записан
Дем
Постоялец
***

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

Сообщений: 167



« Ответ #48 : 08 марта 2007, 13:12:25 »

Цитировать
Откровенно говоря, у меня большие непонятки, зачем вообще символ "%" зачастую оказывается закодирован в виде "%25"? Например, пробел при этом оказывается закодирован не "%20", а "%2520".
А если реальное имя файла на сервере его содержит? Например в исходном имени - пробел, а после загрузки на сервер уже %20 (а в урле уже %2520)
А вот в кеше некоторым хотелось бы иметь именно исходное имя...

Цитировать
В чем в нем? В имени файла? Звездочка там не может быть, как некоторые другие символы.
В востановленном УРЛ. В принципе, в нём можно дать даже (в смысле %23х), а не заниматься обратным преобразованием.
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #49 : 08 марта 2007, 15:06:00 »

А если реальное имя файла на сервере его содержит? Например в исходном имени - пробел, а после загрузки на сервер уже %20 (а в урле уже %2520)
В моих логах я не нашёл ни одного примера под твоё замечание. Может, подкинешь пример такого URL?

Закодированный символ процента встречается в моих логах часто (27887 таких символов, и чаще всего в одном и том же URL их может оказаться хоть полсотни - все закодированные русские буквы, слэши, пробелы, знаки вопроса - повторно закодированы). Однако в 100% случаев закодированный знак процента в моих логах встречается не в имени файла или папки, а именно в параметрах скрипта. Практически всегда - когда параметром скрипта идёт URL (Referer), и в нём все слэши, знаки вопроса, двоеточия, тильды и русские буквы для безопасности закодированы, причём ещё и по два раза. В таких случаях, видимо, однократное декодирование знака процента никакой опасности представлять не может. Большинство таких ссылок являются баннерными.
Хотя я помню редкие случаи, когда какой-то ничинающий сайтостроитель выкладывал у себя на сайте файлы и папки с пробелами и русскими буквами в именах. Но эти символы там не были закодированы! А если бы и были - тут уже встаёт вопрос о том, какой алгоритм использует сервер при поиске файла по URL - сразу декодирует или вначале сравнивает?

Надо найти реальную ссылку на файл, имя которого закодировано на сервере, и протестировать!
Да и бывают ли такие файлы? Можешь привести пример программы, которая при закачке по FTP файла с пробелами или русскими буквами будет создавать в целевой папке файл с закодированным пробелом или русскими буквами? Все FTP-клиенты, с которыми я работал, такой ерундой не занимались.

Только что специально зашёл на FTP-сервер с литературой нашей локальной сети. Там полно файлов с длинными именами, в которых одни русские буквы и пробелы. Я специально закачал на один из них ещё один такой файл с именем "Тест с пробелами.doc", используя в качестве FTP-клиента Internet Explorer. Никакого искажения имени "Тест с пробелами.doc" не произошло! Тем не менее, когда я открыл этот файл в FTP-папке, Internet Explorer в адресной строке представил ссылку на него следующим образом:
_ftp://172.16.38.140/Upload/%D2%E5%F1%F2%20%F1%20%EF%F0%EE%E1%E5%EB%E0%EC%E8.doc
Правда, с открытием этой ссылки у IE возникли проблемы, хотя скопировать из этой папки данный файл он позволяет без труда.
Обрати внимание, что служебный символ процента "%" здесь не подвергнут повторному кодированию в виде %25!
А вот когда я закачал на сервер файл "Тест % %.doc", неслужебные символы процента оказались закодированы в URL, сформированном Internet Explorer:
_ftp://172.16.38.140/Upload/%D2%E5%F1%F2%20%25%20%25.doc

Провёл эксперимент с программой Wget.
Заставил её скачать несколько URL:
wget "ftp://172.16.38.140/Books and Documents/%25.html"
wget "ftp://172.16.38.140/Books%20and%20Documents/%25.html"
wget ftp://172.16.38.140/Books%20and%20Documents/%25.html
wget ftp://172.16.38.140/Books%20and%20Documents/%.html
Во всех этих случаях результат был одинаков: Wget открывает папку Books and Documents,
затем запрашивает файл с именем "%.html".
А вот в следующем примере:
wget ftp://172.16.38.140/Books%20and%20Documents/%2525.html
программа искала уже файл с именем "%25.html".
А если закодировать проценты в имени папки:
wget ftp://172.16.38.140/Books%2520and%2520Documents/%25.html
программа ищет уже несуществующую папку "Books%20and%20Documents" и не находит...
« Последнее редактирование: 08 марта 2007, 16:01:29 от popkov » Сообщить модератору   Записан
Сергей
Beta tester
*****

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

Сообщений: 621



« Ответ #50 : 08 марта 2007, 16:02:35 »

Еще бы подумать как кодировать в именах файлов заглавные буквы встречающиеся в URL.
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #51 : 08 марта 2007, 16:07:00 »

Еще бы подумать как кодировать в именах файлов заглавные буквы встречающиеся в URL.
А примеры можно, когда это имеет значение?
В спецификации URL действительно указано, что строчные и прописные буквы не равнозначны?
Сообщить модератору   Записан
Сергей
Beta tester
*****

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

Сообщений: 621



« Ответ #52 : 08 марта 2007, 16:23:21 »

А примеры можно, когда это имеет значение?
http://ru.wikipedia.org/wiki/gps википедия перенаправит нас на http://ru.wikipedia.org/wiki/Gps и скажет что такой статьи нет.
Потом когда мы введем правильное название http://ru.wikipedia.org/wiki/GPS, то HC увидит что такой файл уже есть в кэше и может отказаться его обновлять.
В принципе могут существовать разные статьи с именами различающимися только регистрами букв. Если бы HC работал под Linux и хранил кэш в его файловой системе, то этой проблемы бы не возникало.
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #53 : 08 марта 2007, 16:55:41 »

http://ru.wikipedia.org/wiki/gps википедия перенаправит нас на http://ru.wikipedia.org/wiki/Gps и скажет что такой статьи нет.
Потом когда мы введем правильное название http://ru.wikipedia.org/wiki/GPS, то HC увидит что такой файл уже есть в кэше и может отказаться его обновлять.
Так и происходит! Печально...  Непонимаю
А вот Internet Explorer - хоть, вроде, и тупой ослик, а этот момент не упускает - у меня поначалу ссылки
http://ru.wikipedia.org/wiki/Gps
и
http://ru.wikipedia.org/wiki/GPS
действительно открывали разные страницы - одна бралась из кэша IE (ответ HC, что не изменилась), а вторая - из кэша HC! Забавно, но поначалу всё работало правильно, пока я не почистил кэш IE...
Впрочем, сама эта проблема уже не кажется мне забавной... Хоть, как в RegExp, вводи метки, указывающие, что следующие буквы становятся прописными или заглавными. Но это не выход...
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #54 : 08 марта 2007, 16:59:38 »

Если бы HC работал под Linux и хранил кэш в его файловой системе, то этой проблемы бы не возникало.
Да, Microsoft даже здесь умудрился сделать подставу!
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #55 : 10 марта 2007, 12:54:58 »

Еще бы подумать как кодировать в именах файлов заглавные буквы встречающиеся в URL.
Могу предложить ставить перед заглавными буквами символ ударения (обратную кавычку) "`". Этот символ не может встречаться в URL в явном виде - только в виде кода %60. Причём этот код, если поискать в кэше, встречается только в параметрах счётчиков и баннерных скриптов, да и то - редко (у меня 10 вхождений среди 300000 URL в логах).
Причём, для повышения удобочитаемости содержимого кэша и укорочения имён файлов, предлагаю - в случае, если идёт несколько заглавных букв подряд - ставить символ ударения, а за ним - количество заглавных букв, идущих подряд (цифра). Такое кодирование будет однозначным: символ ударения в имени файла случайно появиться не может, а значит, кодирование/декодирование будет носить однозначный характер.
И вместе с тем, символы ударения не будут загромождать экран и бросаться в глаза.
Во многих случаях регистр букв точно не может иметь значения: это имя сайта, а также внутри кодов %2F (которые мы не декодируем) и т.п., поэтому для них стоит сделать исключение.
Сообщить модератору   Записан
popkov
Beta tester
*****

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

Сообщений: 349


« Ответ #56 : 10 марта 2007, 13:11:06 »

А сейчас мне пришла ещё более удачная мысль:вместо символа ударения можно использовать неразрывный пробел!
Его можно ввести, набрав при нажатой клавише ALT на цифровой клавиатуре код 0160 (или просто нажать в Word Ctrl+Shift+Пробел). Имя файла или папки в Windows может состоять даже из одного - единственного символа неразрывного пробела!
Вот этот символ: " ".
Остерегайтесь, правда, копировать его из Word - по какой-то причине он при вставке в имя файла превращается в обычный пробел. Но если скопировать из EmEditor или Блокнота (набрав его там Alt+0160) - всё в порядке! Удобнее всего делать это в TotalCommander - переименуйте любой файл, оставив в качестве его имени только символ " ". Работает - проверено! Подмигивающий

Так вот, предлагаю теперь перед каждой заглавной буквой просто ставить этот неразрывный пробел - теперь всё будет совсем читабельно и однозначно! Проще некуда!
Ну а если этот символ встретится в исходном URL (у меня нашлось всего 3 вхождения (среди 300000 URL) в параметрах баннерных скриптов в явном виде) - надо его закодировать (например, кодом "# " - решёточка с неразрывным пробелом).

Как вам такое? Тупой ослик отдыхает... Подмигивающий
« Последнее редактирование: 10 марта 2007, 13:16:42 от popkov » Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #57 : 11 марта 2007, 10:02:26 »

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

Как вариант решения, сделать сие опционально, добавить правило "Кодировать заглавные буквы" по подобию "Сохранять www. ..." или "Не загружать большие файлы"
Сообщить модератору   Записан
v0lt
Beta tester
*****

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

Сообщений: 127


« Ответ #58 : 11 марта 2007, 13:05:03 »

Подведем предварительные итоги первой части (см. ниже). Пора узнать мнение Главного раработчика Улыбка

Преобразования URL<->filename (измениния/дополнения выделены жирным)

Лечим глюки IE (приводим урл к стандарту)
символдо "?"после "?"
URL#строкаURL
"%22
<%3C
>%3E
`%60
^%5E^ (не кодируем)
PS: Последний пункт нужен для правильного декодирования первой строки "^\".

Основная часть кодирования
символдо "?"после "?"
/\#%
//\#%#%#%
*#x
\#~
|#i
!! (не кодируем)
:#= или #!
?^\#^
С двоеточием пора определиться. mai62 ты где?

Красивости
строказамена
%D1%8Fя (кирилица)
%20пробел
Тут сразу вопросы. Реализовывать "Красивости" намертво или опционально? Понимают ли UNIX-овые файловые системы пробел?

Опциональное кодирование регистра (под вопросом: стоит ли?)
строказамена
W`w
imho эту фичу пока не стоит вводить. Поповоду неразрывного пробела, надо проверять, как он поведет себя на FAT, на unix-овых ФС.

Редирект и решение проблем
строказамена
редиректредирект#m
.\.#n\
пробел\пробел#n\
путь\путь\#_
путь.путь.#_
путьпробелпутьпробел#_
Добавилось следующее: если папка или файл заканчиваются точкой или пробелом, то соответственно добавляем #n и #_

Красивости II (нужно ли?)
строказамена
%22#'
%3C#( или #}
%3E#) или #}
imho эти коды не стоит трогать, на наглядность они не сильно влияют. По поводу %22->## я тем более против.

PS: Кто в курсе какие символы запрещены в unix-овых файловых системах? Киньте сюда информацию.

PPS: Если будет время, то на следующей неделе напишу конвертор URL->filename->URL (будем наглядно видеть что у нас получается)
Сообщить модератору   Записан
cepera_ang
Beta tester
*****

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

Сообщений: 355


« Ответ #59 : 11 марта 2007, 13:34:11 »


PS: Кто в курсе какие символы запрещены в unix-овых файловых системах? Киньте сюда информацию.
В файловой системе Unix запрещены два символа - "/" (обозначает папки в пути) и "\000" (то есть нулл символ, обозначающий конец имени файла). Все остальные символы - разрешены.
Сообщить модератору   Записан
Страниц: 1 2 [3] 4 5 ... 13   Вверх
  Отправить эту тему    Печать  

 
Перейти в: