2010-09-15 10 views
48

Dla stron już określonych (albo przez nagłówek HTTP, albo przez metatag), aby mieć typ zawartości z zestawem znaków UTF-8 ... czy istnieje korzyść z dodawania accept-charset="UTF-8" do formularzy HTML?Czy jest jakaś korzyść z dodawania accept-charset = "UTF-8" do formularzy HTML, jeśli strona jest już w UTF-8?

(Rozumiem, że atrybut accept-charset jest uszkodzony w IE dla ISO-8859-1, ale nie słyszałem o problemie z IE i UTF-8. Po prostu pytam, czy jest jakaś korzyść z dodania go z UTF-8, aby zapobiec wprowadzeniu niepoprawnych sekwencji bajtów.)

+0

Moje pytanie jest bardziej szczegółowe ... ale powiązane: http://stackoverflow.com/questions/3715264/how-to-handle-user-input-of-invalid-utf-8-characters i http: // stackoverflow.com/questions/1317152/am-i-correctly-supporting-utf-8-in-my-php-apps/1317301#1317301 – philfreo

+0

Powiązane odwołanie W3C: http://www.w3.org/TR/html401/ interact/forms.html # adef-accept-charset (zanotuj "może" w "Agentach użytkownika można zinterpretować tę wartość jako kodowanie znaków, które było używane do przesyłania dokumentu" - czy oznacza to, że bezpieczniej jest wyraźnie o tym wspomnieć? Z mojego doświadczenia wynika, że ​​zgadzam się z tym co mówi @elusive) –

Odpowiedz

33

Jeśli strona jest już interpretowana przez przeglądarkę jako UTF-8, ustawienie accept-charset="utf-8" nic nie robi.

Jeśli ustawisz kodowanie strony na UTF-8 w nagłówku <meta> i/lub HTTP, to będzie interpretowane jako UTF-8, chyba użytkownik świadomie idzie do menu Widok-> Kodowanie i wybiera inne kodowanie, przesłonięcie podanego przez Ciebie.

W takim przypadku ustawienie accept-encoding spowodowałoby ustawienie kodowania przesyłania z powrotem na kodowanie UTF-8 w sytuacji, gdy użytkownik kręciłby się przy kodowaniu strony. Jednak nadal nie będzie działać w IE, ze względu na poprzednie problemy omówione w tej przeglądarce z accept-encoding.

IMO ma wątpliwości, czy warto włączyć accept-charset, aby naprawić przypadek, w którym użytkownik inny niż IE celowo sabotował kodowanie strony (prawdopodobnie zepsuł więcej na stronie niż tylko formularz).

Osobiście nie zawracam sobie głowy.

+1

Czy jesteś pewien? To ma sens, ale dokument mówi, że "może interpretować", a domyślną wartością jest NIEZNANY. – philfreo

+4

We wszystkich przeglądarkach (obecnie i historycznie), "UNKNOWN'/unset" oznacza zawsze aktualne kodowanie strony, niezależnie od tego, czy był to zestaw kodowania strony serwera w nagłówku/meta, czy kodowanie jawnie ustawione przez użytkownika jako nadpisanie. Wyjątek, który prawdopodobnie nie dotyczy Ciebie: większość przeglądarek nie wysyła wysyłanych formularzy w kodowaniu innym niż ASCII, takim jak UTF-16, nawet jeśli strona została wyświetlona w ten sposób. To naprawdę nie ma sensu. – bobince

3

Nie napotkałem żadnych problemów przy użyciu UTF-8 z IE (6+) lub jakąkolwiek inną ważną przeglądarką. Musisz się upewnić, że ustawiony jest metatag UTF-8 (IE tego potrzebuje) i że wszystkie twoje pliki są zakodowane w UTF-8 (co oznacza, że ​​serwer WWW wysyła nagłówki UTF-8). Wtedy nie powinno być problemu, jeśli pominiesz accept-charset.

+0

Robię te rzeczy, sans, które tworzą atrybut, dostaję pewne przypadki nieważnego wejścia w UTF-8 (http://stackoverflow.com/questions/ 3715264/how-to-handle-user-input-of-invalid-utf-8-characters), więc próbuję dowiedzieć się jednoznacznie, czy dodanie tego do wszystkich moich f orms będą pomocne lub niepotrzebne. – philfreo

+0

@philfreo: Nigdy go nie używałem i nie miałem żadnych problemów. Czy możesz przekazać nam link do Twojej strony? – jwueller

+2

Jeśli strona rzeczywiście jest prawidłowo wyświetlana jako UTF-8, nie powinieneś otrzymywać zgłoszeń innych niż UTF-8 z tego formularza. Oczywiście, jeśli masz inne witryny, w których umieszczasz formularz prowadzący do Twojej witryny, lub zautomatyzowane agenty przekazujące treści ogólnie, wszystkie zakłady są wyłączone. – bobince

Powiązane problemy