2013-05-29 7 views
23

Czy zwyczajowo pomijamy ;charset="utf-8", gdy typem treści jest application/x-www-form-urlencoded?application/x-www-form-urlencoded i charset = "utf-8"?

W szczególności, przy użyciu accept-charset="utf-8" w znaczniku formularza, oczekiwałbym pewnego wskazania, że ​​utf-8 jest używany w nagłówkach, ale nie widzę żadnego.

Oto mój prosty test w Chrome. Strona forma jest:

<html> 
<head> 
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/> 
</head> 
<body> 
<form method="POST" action="printenv.cgi" accept-charset="utf-8"> 
Your name: 
<input name="name" type="text" size="30"> 
</form> 
</body> 
</html> 

A nagłówki na wygenerowanym życzenie:

POST /printenv.cgi HTTP/1.1 
Host: ...:8000 
Connection: keep-alive 
Content-Length: 19 
Cache-Control: max-age=0 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Origin: http://...:8000 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.94 Safari/537.36 
Content-Type: application/x-www-form-urlencoded 
Referer: http://...:8000/utf8-test.html 
Accept-Encoding: gzip,deflate,sdch 
Accept-Language: en-US,en;q=0.8 

Co to jest konwencja o określenie, w jaki sposób wartości parametrów forma są kodowane?

Odpowiedz

24

1) Dla tego typu mediów nie zdefiniowano żadnego parametru zestawu znaków.

2) Aby zapoznać się z wytycznymi dotyczącymi kodowania, zobacz https://www.w3.org/TR/html5/sec-forms.html#application-x-www-form-urlencoded-encoding-algorithm.

+7

Och, ciekawa ciekawostka, której nie znałem: * "Jeśli nazwa wpisu to" _charset_ ", a jego typ jest" ukryty ", należy zastąpić jego wartość zestawem znaków."* – deceze

+0

Pamiętaj, że łączysz się ze specyfikacją ** HTML 5 **, ale zamiast tego HTML używa ** HTML 4 ** Oto algorytm przesyłania formularzy dla HTML 4: http: //www.w3 .org/TR/1999/REC-html401-19991224/interact/forms.html # h-17.13, chociaż nie mówi o obsłudze zestawów znaków.) –

+0

Remy: typ dokumentu nie wpływa na to, co przeglądarki robią w odniesieniu do kodowania formularzy. –

4

Uwaga: w kroku 2 powyższego linku jest napisane: "W przeciwnym razie kodowanie wybranego znaku będzie możliwe jako UTF-8." (zob. http://www.w3.org/TR/html5/forms.html#application/x-www-form-urlencoded-encoding-algorithm)

ja również, że ten wydaje się wskazywać, że jest to najlepsza praktyka dla klienckie używać UTF-8?

http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars

Oto co mówi: B.2.1 znaków spoza ASCII w atrybucie URI wartości

Chociaż URI nie zawierają wartości spoza ASCII (patrz [URI], sekcja 2.1) Autorzy czasami określaj je w wartościach atrybutów oczekujących identyfikatorów URI (tj. zdefiniowanych za pomocą% URI, w DTD). Na przykład, następująca wartość href jest nielegalne:

...

Zalecamy klienckie przyjąć następującą konwencję do obsługi znaków spoza ASCII w takich przypadkach:

Represent each character in UTF-8 (see [RFC2279]) as one or more bytes. 
Escape these bytes with the URI escaping mechanism (i.e., by converting each byte to %HH, where HH is the hexadecimal notation of the byte value). 

Ta procedura wyników w składnie prawnie zdefiniowanym identyfikatorze URI (zdefiniowanym w [RFC1738], sekcji 2.2 lub [RFC2141], sekcja 2), który jest niezależny od kodowania znaków, do którego mógł zostać transkodowany dokument HTML przenoszący URI.

Uwaga. Niektóre starsze aplikacje użytkownika trywialnie przetwarzają identyfikatory URI w HTML przy użyciu bajtów kodowania znaków, w którym odebrano dokument. Niektóre starsze dokumenty HTML polegają na tej praktyce i łamią się podczas transkodowania. Programy użytkownika, które chcą obsługiwać te starsze dokumenty, powinny po otrzymaniu identyfikatora URI zawierającego znaki spoza zestawu prawnego najpierw użyć konwersji opartej na UTF-8. Tylko jeśli wynikowy identyfikator URI nie zostanie rozwiązany, jeśli spróbuje utworzyć identyfikator URI na podstawie bajtów kodowania znaków, w którym odebrano dokument.

Uwaga. Ta sama konwersja oparta na UTF-8 powinna być zastosowana do wartości atrybutu name dla elementu A.