Klucz dostępu n przeskakuje w nawigacji strony. Przejdź do początku.

Ten dokument jest tłumaczeniem. W przypadku rozbieżności i błędów aktualna wersja angielska powinna być uznana za autorytatywną. Pierwotne prawa autorskie należą do W3C jak wykazano poniżej.

Tłumacz: Tłumaczenia team.

s_gotoW3cHome Internacjonalizacja
 

Formularze wielojęzyczne

Potencjalni odbiorcy: Programiści kodujący w XHTML/HTML (używając edytorów lub skryptów), deweloperzy skryptów (PHP, JSP, etc.), kierownicy projektów internetowych oraz wszyscy, którzy szukają informacji o tym jak poradzić sobie z kodowaniem znaków w formularzach.

Pytania

Jaki jest najlepszy sposób na poradzenie sobie z kwestiami dotyczącymi kodowania w formularzach, które mogą wykorzystywać wiele języków i skryptów?

Odpowiedź

Najlepszym sposobem na poradzenie sobie z kwestiami kodowania w formularzach (X)HTML jest dostarczanie wszystkich twoich stron kodowanych w UTF-8. UTF-8 daje możliwość przedstawienia znaków z największego zakresu języków. Przeglądarki odsyłają dane z formularza w tym samym kodowaniu, co strona zawierająca formularz, zatem użytkownik może wprowadzać dane w dowolnie wybranym przez siebie języku lub skrypcie.

By mieć pewność, że wszystko będzie działać jak trzeba należy zadbać o kilka drobiazgów. Po pierwsze, ważne jest, aby dać zasygnalizować przeglądarce, że strona zawierająca formularz jest kodowana w UTF-8. Istnieje wiele różnych metod zasygnalizowania przeglądarce kodowania twojej strony. Jest to ważne w każdym przypadku, jednak szczególnie, gdy na twojej stronie zawierającej formularz nie ma żadnych znaków spoza US-ASCII, jednak użytkownicy twojej strony mogą chcieć wpisać inne znaki.

Po drugie, dobrym pomysłem będzie sprawdzenie przez skrypt, który otrzymuje dane z formularza, że dane te rzeczywiście kodowane są w UTF-8 (na wypadek gdyby coś poszło źle, np. użytkownik zmienił kodowanie). Sprawdzenie takie jest możliwe dzięki specyficznemu wzorcowi bajtów kodowania UTF-8 nie występującym w żadnym innym kodowaniu. Jeżeli otrzymane dane nie są kodowane w UTF-8 powinien zostać zwrócony komunikat o błędzie.

Dla przykładu, w Pearlu, regularne wyrażenie sprawdzające kodowanie UTF-8 może wyglądać jak poniżej:

$field =~
  m/\A(
     [\x09\x0A\x0D\x20-\x7E]            # ASCII
   | [\xC2-\xDF][\x80-\xBF]             # non-overlong 2-byte
   |  \xE0[\xA0-\xBF][\x80-\xBF]        # excluding overlongs
   | [\xE1-\xEC\xEE\xEF][\x80-\xBF]{2}  # straight 3-byte
   |  \xED[\x80-\x9F][\x80-\xBF]        # excluding surrogates
   |  \xF0[\x90-\xBF][\x80-\xBF]{2}     # planes 1-3
   | [\xF1-\xF3][\x80-\xBF]{3}          # planes 4-15
   |  \xF4[\x80-\x8F][\x80-\xBF]{2}     # plane 16
  )*\z/x;

Wyrażenie to można adaptować w innych językach programowania. Rozwiązuje ono wiele kwestii, takich jak niedozwolone, zbyt długie kodowania i użycie niedozwolonych odpowiedników. Zwróci wartość true jeżeli $field okaże się kodowaniem UTF-8, a wartość false w każdym innym przypadku..

Powiedz nam co myślisz (po angielsku).

Prenumeruj kanał RSS.

Nowe źródła

Wiadomość ze strony głównej

Twitter (Wiadomość ze strony głównej)

‎@webi18n

Warto przeczytać

Autor: Martin Dürst, W3C. Tłumacz: Tłumaczenia team..

Ważny XHTML 1.0!
Ważne CSS!
Zakodowano w UTF-8!

Angielska wersja dokumentu z dnia 2004-06-16. Tłumaczenie wykonano dnia 2010-08-20 11:17 GMT

Historia zmian dokumentu qa-forms-utf-8 w blogu i18n.