VBS: URL Encoding при отправке формы в WinHttpRequest

2 smaharbA > Так и я далек от мысли - нужно, чтобы кто-то недалекий от мысли откликнулся, а так - непонятно все остается.

чем не устраивает нативный хекс ?

For CharPosition = 1 To Len(Data)
    s=Mid(Data, CharPosition,1)
    CharCode = Asc(s)
    if ( charcode > 90 and charcode < 95 ) or charcode = 96 or charcode > 122 then
        URLEncode = URLEncode & "%" & right("0" & hex(CharCode),2)
    else
        URLEncode = URLEncode & s
    end if
Next
msgbox URLEncode

Или всеж таки вас интересует енкод в утф-8 ?

и к слову - обертку можно несколько изящнее пользовать

set this=oScript.Eval("this")
...
...this.encodeURIComponent(this.String.fromCharCode(CharCode))

RFC 1738 не менялся с 1994 года, но это не значит, что он устарел. Этот документ писался, когда Unicode только зарождался и, я полагаю, о его влиянии не было речи. Вот эта цитата (страница 2) по адресу http://www.ietf.org/rfc/rfc1738.txt говорит о том, как кодировать символы с кодами > 127. Этого достаточно, чтобы представить любой символ из любого алфавита и набора символов. URL-кодируя некоторый текст Вы ожидаете получить список триплетов в некой кодировке (866 или 1251), но это не так. URL как средство доступа к ресурсу  не знает об этих кодировках -- только Latin-1 (в переделах, описанных в RFC).

Используйте нативные, документированные средства кодирования и будьте спокойны - современные серверы умеют обрабатывать нелатинские символы.

Амперсанд к данному RFC отношения не имеет -- его кодирование задокументировано в других документах - http://www.w3.org/MarkUp/html-spec/html … l#SEC9.7.1. Этот символ иммет особое значение (используется для представления сущностей) поэтому для корректного представления самого символа используется его сущность &. Вы ни проиграете, и не выиграете, используя сущность вместо самого символа, и наоборот. Однако подстановка сущности будет правильнее.

Я так полагаю, VBScript не имеет своих средств URL-кодирования, коли Вы используете jscript-"инъекции"?

kefi, используйте BBCode.

кодирования URL как такогого не существует (с некоторым допущением), существует кодирование URI

Давайте Вы не будете путать своими неопределенными вопросами и кратко и четко сформулируете Вашу проблему. Я Вам привел вполне корректный пример кодирования компонентов URL/URI и мне не понятно Ваше непонимание.

Неопределенно - это Вы изъясняетесь.
Куда уж проще объяснить - см. мой предыдущий пост, уже n-ный раз пытаюсь спросить : какую из приведенных двух функций будет правильно использовать для URL кодирования запросов , отравляемых при GET отправке формы (ну или  см. WebFormClass v.3.0. из первого поста - он взят, как конкретный пример) ?

кто-то может все-таки дать ответ - в какой кодировке текст дожен поступать на вход процедуры осуществляющей его  %-кодирование ?

2 Xameleon > спасибо, что откликнулись, ибо топик вызван именно благодаря Вашим кодам, упомянутым в первом посте. Но вот url-кодирование там я как раз и не понял. Точнее, я понимаю их так, что работать Ваше url кодирование будет только для серверов , которые принимают windows-1251 кодировку, когда раскодируют url.

Объясню :

1) Ваш ответ выше говорит , что Вы не поняли моего вопроса от 2010-11-01 18:41:55.  Там я не спрашивал - КАК делать url-кодирование некоей процедурой, а спрашивал - в какой кодировке на ее вход должны поступать данные для url-кодирования (или точнее %-кодирования).

2) НА вход Вашей  UrlEncode поступает, как известно, строка типа WindowsUnicode1 (т.е. подмножество <=&#xFFFF;  Utf16 от текущей выполняющейся Windows)

Далее в UrlEncode она посимвольно  анализируется на допустимые символы - и возражений нет, когда выявленные т.о. допустимые символы Вы НЕ %-кодируете, а без изменения отправляете в результирующую строку (которая , конечно тоже WindowsUnicode1 типа).

Остальные символы Вашей исходной строки посимвольно  AnsiCode=Asc(Mid(Text, i, 1)) Преобразовываются в ANSI (т.е. windows-1251 по нашенски если) после чего этот Ansi код %-кодируется и обратно преобразовывается в WindowsUnicode1: "%"+Hex(AnsiCode).

В итоге на выходе имеем WindowsUnicode1 строку, состоящую из разрешенных символов и %hh-кодов. Теперь далее - эта строка при отправке методом send объекта MSXML2.XMLHTTP превращается в байты посылаемого URL, из которых каждый соотвествует одному символу url-кодированной строки
Пример :

wЮ  - UrlEncode("wЮ") ->  w%DE

Сервер примет эти 4 байта w%DE и  :
прежде всего их %-раскодирует(для этого процесса не надо знать ничего о кодировках) - получит 2 байта с кодами 77hex и DEhex и вот уже после :
ЕСЛИ ОН ЗНАЕТ что эти два байта в кодировке Windows-1251, то правильно их превратит в wЮ своей внутренней кодировки  и далее использует полученные данные для того , чтобы, скажем, найти путь к каталогу с файлами /wЮ/тар-тата/та-та.
А Если сервер не о windows-1251, а думает , скажем , что это пришло в UTF-8 кодировке, то в этом случае он после %-декодирования превратит коды 77hex и DEhex -> в один только w (т.к. после первого корректно превращенного байта в w он встретит DEhex байт , не имеющий в UTF-8 корректного символа) и соответственно при построении пути будет вместо нужного

/wЮ/тар-тата/та-та использовать /w/тар-тата/та-та.

Т.о. вывод :
Нужно учитывать (как - вопрос отдельный) то в какой кодировке данные принимаютсмя сервером и соответсвенно поступают на вход процедуры url-кодирования, которая в этом случае, конечно, сильно усложняется, вот если сервер хочет , чтобы это была UTF-8 , то - пожалйста, для этого можно использовать encodeURIComponent от JScript, но если он хочет koi-8, и более ничего , то тогда Ваша процедура не должна сработать, как и , впрочем, encodeURIComponent - нужна такая url-кодирования, которая бы учитывала кодировку, которую хочет сервер.
Вот собственно об этом я и справшивал в предыдущем своем посте - как понять , на какую кодировку следует рассчитвать в процедуре делающую url-кодирование , т.е. - как определить эту кодировку?