Przejdź do treści

Formularze

Forma odszyfrowana

<form action="..." enctype="text/plain">...</form>

Formularze są wysyłane w formie zakodowanej, np. możesz otrzymać coś takiego:

Imi%EA=S%B3awomir&Nazwisko=Kok%B3owski&P%B3e%E6=M%EA%BFczyzna&Wiek=20-29&Muzyka=Rock&Muzyka=Elektroniczna&Przegl%B9darka=Opera&System+operacyjny=Dos&System+operacyjny=Windows&System+operacyjny=Linux&Komentarz=Prosz%EA%2C+wpisz+tutaj+jaki%9C+komentarz...

Powyższy atrybut (enctype="text/plain") powoduje, że wszystkie formularze będą przysyłane w formie odszyfrowanej, dla powyższego przykładu jest to:

Imię=Sławomir
Nazwisko=Kokłowski
Płeć=Mężczyzna
Wiek=20-29
Muzyka=Rock
Muzyka=Inna
Muzyka=Elektroniczna
Przeglądarka=Opera
System operacyjny=Dos
System operacyjny=Windows
System operacyjny=Linux
Komentarz=Proszę, wpisz tutaj jakiś komentarz...

Prawda, że łatwiej przeczytać coś takiego? Zatem staraj się zawsze używać tej metody w formularzach pocztowych, ponieważ może Ci ona zaoszczędzić dużo czasu na odszyfrowywanie przysłanych danych. Nie ma to natomiast większego znaczenia, w przypadku wykorzystywania formularza w skryptach (po stronie klienta lub serwera).

UWAGA!
Jeśli na stronie WWW została zdeklarowana zalecana w polskim Internecie strona kodowa iso-8859-2, a jednocześnie używaną przeglądarką jest Internet Explorer 5, 6 lub 7 (program pocztowy Outlook Express 5 lub 6), to w przesyłanym formularzu, w miejscu niektórych polskich liter (ą, ś, ź, Ą, Ś, Ź), wystąpią błędne znaki!

Błędów prawdopodobnie nie będzie, jeśli na stronie z formularem użyjemy strony kodowej windows-1250, ale nie jest ona zalecanym standardem międzynarodowym i dlatego niestety w innych przeglądarkach polskie litery na całej stronie mogą wtedy zostać błędnie wyświetlone (gdy przeglądarka nie obsługuje takiego standardu).

Jeżeli bardzo przeszkadzają Ci błędne litery w przysyłanych formularzach, rozwiązaniem problemu może być zastosowanie mimo wszystko strony kodowej windows-1250, nawet jeśli w niektórych przypadkach miałoby to spowodować błędne wyświetlanie polskich znaków na stronie. Dobre przeglądarki powinny interpretować taką stronę kodową, a poza tym w Polsce większość internautów używa Internet Explorera (który oczywiście poprawnie interpretuje kodowanie windows-1250), zatem ryzyko jest niewielkie. Natomiast na wszystkich innych stronach serwisu powinniśmy nadal używać kodowania iso-8859-2.

Usunięcie polskich znaków z formularza

Innym sposobem rozwiązania problemu jest automatyczne usunięcie przed wysłaniem formularza wszystkich polskich znaków, które mógł podać użytkownik. Odnosi się to do pól tekstowych oraz obszarów tekstowych. Jeśli chodzi o inne pola (np. checkbox, radio), dla nich możesz samodzielnie wpisać w treści atrybutów value="..." tekst bez polskich znaków. Atrybut ten można również podać dla znacznika <option>...</option> (lista rozwijalna):

<select name="nazwa">
	<option value="acelnoszz">ąćęłńóśźż</option>
	<option value="ACELNOSZZ">ĄĆĘŁŃÓŚŹŻ</option>
</select>

Zwróć uwagę, że tekst po znaczniku <option> może się różnić od wartości atrybutu value="...". W ten sposób użytkownik wypełniający formularz, zobaczy poprawne polskie litery.

Aby automatycznie usunąć polskie znaki z pól i obszarów tekstowych, można umieścić przed formularzem odpowiedni skrypt:

<script type="text/javascript">
// <![CDATA[
function usun_pl(formularz)
{
	for (i = 0; i < formularz.length; i++)
	{
		var pole = formularz.elements[i];
		if (pole.type != "text" && pole.type != "textarea") continue;
		var str = "";
		for (j = 0; j < pole.value.length; j++)
		{
			switch (pole.value.charAt(j))
			{
				case "ą": str += "a"; break;
				case "ć": str += "c"; break;
				case "ę": str += "e"; break;
				case "ł": str += "l"; break;
				case "ń": str += "n"; break;
				case "ó": str += "o"; break;
				case "ś": str += "s"; break;
				case "ź": str += "z"; break;
				case "ż": str += "z"; break;
				case "Ą": str += "a"; break;
				case "Ć": str += "c"; break;
				case "Ę": str += "e"; break;
				case "Ł": str += "l"; break;
				case "Ń": str += "n"; break;
				case "Ó": str += "o"; break;
				case "Ś": str += "s"; break;
				case "Ź": str += "z"; break;
				case "Ż": str += "z"; break;
				default: str += pole.value.charAt(j); break;
			}
		}
		pole.value = str;
	}
}
// ]]>
</script>

<form action="mailto:adres e-mail?subject=temat" method="post" enctype="text/plain" onsubmit="usun_pl(this)">
	(Pola formularza)
</form>

Zwróć uwagę, aby dodać atrybut onsubmit="usun_pl(this)" do znacznika <form>!

Strona kodowa formularza

<form action="..." accept-charset="strona kodowa">...</form>

Domyślnie zawartość formularza, wypełniona przez użytkownika, jest wysyłana przy użyciu takiej samej strony kodowej jak określona w dokumencie z formularzem. Może się jednak zdarzyć, że system odbierający dane (np. skrypt PHP albo program pocztowy użytkownika) posługuje się innym kodowaniem znaków. W takiej sytuacji powinniśmy ujednolicić kodowanie dokumentu i systemu odbierającego dane, bo inaczej informacje zostaną zniekształcone przez ten system - m.in. w miejsce polskich znaków diakrytycznych mogą pojawić się "krzaczki".

Jednak często zmiana strony kodowej dokumentu z formularzem nie jest najlepszym rozwiązaniem, ponieważ cała reszta serwisu byłaby zapisana inaczej niż ten jeden dokument. Zmiana kodowania znaków systemu odbierającego dane z formularza może w ogóle nie wchodzić w grę - możemy nie mieć wpływu na stronę kodową systemu operacyjnego, programu pocztowego czy skryptu na serwerze. W takiej sytuacji wystarczy zdefiniować, jakiej strony kodowej używa system odbierający dane, a przeglądarka podczas wysyłania formularza powinna automatycznie skonwertować cały tekst. Na przykład, jeśli nasza strona jest zapisana przy użyciu kodowania znaków iso-8859-2, ale wiemy, że system, do którego wysyłamy formularz używa kodowania utf-8, powinniśmy wpisać:

<form action="..." accept-charset="utf-8">...</form>

Niestety atrybut accept-charset="..." nie jest cudownym sposobem na zachowanie prawidłowych polskich znaków diakrytycznych w prostych formularzach pocztowych :-( Nie wiadomo z jakiego systemu operacyjnego ani z jakiego programu pocztowego korzysta użytkownik, który będzie wypełniał formularz, a więc nie można jednoznacznie ustalić docelowej strony kodowej wysyłanych danych.

Zobacz także

Komentarze

Zobacz więcej komentarzy