Что корректное кодирует HTTP, получают строки запроса?
Да, это может быть сделано. Необходимо предположить, что приложение будет только развернуто на Windows XP (или Windows Server 2003) или позже, и затем можно использовать то, что называют 'регистрацией свободным COM', чтобы заставить это произойти.
По существу то, что Вы делаете, создают файл манифеста для DLL элемента управления ActiveX так загрузчик Windows & COM DLL знает то, что его регистрация, не имея необходимость помещать это в реестр.
пошаговая демонстрация А того, что сделать, находится в этой статье о MSDN: Активация без Регистрации COM-компонентов: Пошаговая демонстрация
"Шаг 6" и "Шаг 7" в той статье содержат все , Вам будет нужно.
я просто испытал это на моих собственных программах C#, которое использует управление сеткой Microsoft ActiveX (старая "Сетка Flex MS"), и она работает просто великолепно. Удостоверьтесь, что Вы создаете файл манифеста и для Вашего приложения и для COM DLL, и заменяете соответствующими GUID в правильных местах. Вы, возможно, должны использовать OLEVIEW для откапывания правильных идентификаторов для использования от DLL ActiveX, если у Вас нет их удобными.
3 ответа
Определяет ли стандарт HTTP или что-то еще, какая кодировка должна использоваться для специальных символов, прежде чем они будут закодированы в URL-адресе с помощью% XX?
Стандарт HTTP, нет. Но другой стандарт, IRI, может вступить в игру.
URI представляют собой явно (после% -декодирования) байтовые последовательности. На какие символы Unicode отображаются эти байты, не указано ни в стандарте URI, ни в стандарте HTTP для URI http: -scheme.
В частности, для параметров запроса: веб-браузеры будут использовать кодировку исходной страницы для отправки формы GET URL , поэтому, если у вас есть страница в ISO-8859-1 и вы поместите 'é' в поле поиска, вы получите '? search =% E9', но если вы сделаете то же самое на странице, закодированной как UTF-8, вы получится? search =% C3% E9. Если вы не t обслуживайте страницу формы с любой конкретной кодировкой, которую угадывает браузер, что вам не нужно, поскольку из-за этого невозможно будет угадать, в каком формате будет отправка.
Для других частей URL , браузер не будет их генерировать сам, но если вы предоставите ему символы, отличные от ASCII, в ссылках, он обычно будет кодировать их как UTF-8. Это ненадежно, так как зависит от настроек браузера и локали, поэтому на данный момент лучше не использовать его.
Стандарт, который правильно разрешает символы, отличные от ASCII, в ссылках - IRI . IRI преобразуется в URI по UTF-8 -% - кодируя большую часть URL, но вместо этого имя хоста преобразуется с использованием Punycode . Для совместимости лучше пока не полагаться на то, что браузеры понимают IRI в ссылках. Вместо, UTF-8-then -% - самостоятельно кодирует ваш путь и символы параметров. В современных браузерах они по-прежнему будут отображаться как правильные символы в адресной строке; К сожалению, IE не будет отображать IRI с декодированными символами во всех случаях, в зависимости от языковых настроек.
Wiki IRI для греческого гамма-символа:
http://en.wikipedia.org/wiki/Γ
Закодирован в URI, это:
http://en.wikipedia.org/wiki/%CE%93
Per RFC 2616,
CHAR =
and
token = 1*
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
and URIs are tokens with various specific separators. So, in theory, nothing but US-ASCII should be there. (In practice, since the ISO-8859-1 extension to US-ASCII is used in many other spots in the HTTP specs, it's not unusual to find HTTP implementations which support ISO-8859-1 rather than just US-ASCII, but strictly speaking that's not standards-compliant HTTP).
As far as I'm aware, there is no way to define it, though I've always assumed that it is ASCII, since that is what DNS is (currently, though localised DNS is coming, with all the problems that entails).
Note: UTF8 is "ASCII compatible" unless you try to use extended characters. This probably plays some small part in the reasoning behind why some browsers might send their GET data UTF8 encoded.
EDIT: From your comment, it seems like you don't know how the % encoding works at all, so here goes.
Given the following string query string, "?foo=Hello World!", the "Hello World!" part needs URL encoding. The way this works is any 'special' characters get their ASCII value taken and converted to hex prefixed by a '%'. So the above string would convert to "?foo=Hello%20World%21".