W pewnym stadium zaawansowania wyrażenia regularne stają się potężnym narzędziem każdego programisty PHP (i nie tylko). A to dlatego, że pozwalają na wykonywanie operacji, których często nie sposób dokonać w prosty sposób przy pomocy standardowych funkcji zawartych w tym języku. Walidacja zawartości zmiennych, czy podmienianie specyficznej części ich zawartości - na to pozwalają wyrażenia regularne. 15-ście przykładowych, najbardziej niezbędnych dla każdego web developera, skompletowałem w dalszej części artykułu. Do Waszej dyspozycji oddaję także prosty serwis sprawdzający poprawność wprowadzanych wzorców.
Wyrażenie ma za zadanie sprawdzać, czy wprowadzony przez użytkownika adres e-mail ma poprawną formę. Aby test zakończył się sukcesem muszą zostać spełnione następujące warunki:
2.a_a-d@n-do.x-d.pl
2.a_a-d@n-do.x-d.v-.pl (część domeny kończąca się nieprawidłowym znakiem)
Jeżeli rozwiązanie w jakimkolwiek stopniu zawiedzie można pokusić się o użycie wyrażenia z ostatniej aktualizacji pliku logical_filters.c ze źródeł PHP.
Od jakiegoś czasu jak sobie przeglądam różne fora, cały czas widzę że ludzie mają problemy z kodowaniem na stronie, a to nie widzą co jest tego przyczyną, a to znowu ustawiają kodowanie w nagłówku html inne niż w pliku, a to do bazy danych podczas połączenia zapominają ustawić kodowania znaków. Jest to trochę smutne a rzecz jest tak prosta, że mógłbym rzec trywialna. Co należy zrobić by tego uniknąć.
I tutaj chciałbym Wam wszystkim powiedzieć że iso-8859-2 nie jest standardem kodowania, tak nie jest! Są dwa standardy kodowania pliku, jeden to iso-8859-1 a drugi to mój ulubiony utf-8. O każdym z nich możecie sobie przeczytać na wiki. Jeżeli pracujecie na systemach z rodziny windows, to od razu Wam współczuje, ponieważ słabe edytory plików są ustawione defaultowo na kodowanie windowsowkie czyli cp 1250, co jest bardzo złym podejściem dla programistów, oraz złym nawykiem jeżeli się do tego przyzwyczaimy. Ci którzy pracują na linuxie, mogą sobie darować resztę tego paragrafu ponieważ u nas domyślnie wszystko jest w utf-8 (wyjątkiem od tej reguły jest slackware), ale co tam.
O co chodzi, dajmy na to że używamy notatnika do edycji plików php czy html. W nagłówku head ustawiamy kodowanie strony np dla iso-8859-2, zapisujemy, przeglądamy treść i co? I błędy! Tak Polskie znaki diakrytyczne (mowa o znakach alfabetu z ogonkami) są w postaci tzw. krzaków. Spowodowane jest to tym iż plik jest zapisany w formacie cp 1250 (czyli windowsowskim). Nie pamiętam w tej chwili czy notatnik pozwala nam na zmianę kodowania, ale wydaję mi się że nie, i w cale bym się nie zdziwił gdyby tak było.
Co należy zrobić, otóż sprawa jest prosta, pobrać jakiś edytor tekstu, który pozwala nam na zmianę formatu zapisu pliku, jednym który znam, oraz w pełni darmowym jest Notepad++, pewnie nie jeden z Was już o nim słyszał lub go używa. Nie będę nikogo nakłaniał na żadne z IDE, ponieważ DE ma pomagać a nie przeszkadzać a początkującemu programiście może utrudniać życie. Wracając do Notepad++, ustawiamy w nim kodowanie na UTF-8, ustawiamy w nagłówku dokumentu html charset również na utf-8 i odświeżamy stronę. Proszę jak ładnie wyglądają teraz nasze Polskie literki.
W komentarz pewnie zostanę zlinczowany za to co tutaj napiszę, ale to mój blog i mogę sobie pisać co chce ;] A więc nawiązując do powyższego paragrafu, w dalszym ciągu będę się upierał przy kodowaniu w UTF-8, sprawa ma się tak iż dostępnych mamy b.dużo baz danych, a hostingi przeważnie udostępniają nam jedną w porywach do dwóch typów baz danych są nimi MySQL oraz PostgreSQL. Co do drugiej sprawa ma się krótko, defaultowo kodowanie ustawione na utf-8, sprawa zamknięta, ale że Postgres w naszym kraju jest jakimś małym procentem (nie wiadomo czemu), przejdźmy do MySQL. Przykładowy kod do utworzenia tabeli w bazie danych.
CREATE TABLE `users` ( `id` int(4) NOT NULL AUTO_INCREMENT, `slogin` varchar(128), `shaslo` varchar(32), PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1;
Jak widać po zamknięciu definicji kolumn w tabeli, mamy ustawiony typ tabeli na InnoDB oraz ustawiony domyślny typ zapisu danych do bazy na kodowanie utf-8, i na samym końcu o ile ma być zwiększany id przy nowym rekordzie.
Gdybyśmy się pozbyli wpisu dotyczącego CHARSET, najprawdopodobniej domyślnym kodowaniem zostałby iso-1, tak 1 nie 2. A my gupie polaczki jedziemy ostrona na 2 jakby to było spełnieniem naszych marzeń. NIE! I jeszcze raz nie! Tak jak pisałem wyżej Standardami są iso-1 oraz utf-8.
Następnym krokiem jest ustawienie typu kodowania podczas połączenia się z bazą danych, zróbmy tak:
$link = mysql_connect('host', 'user', 'password'); $charset = mysql_client_encoding($link); if ( $charset != 'utf8' ) { mysql_set_charset('utf8',$link); }
Co tutaj robimy, łączymy się z bazą danych w najprostszy z możliwych sposobów, pobieramy kodowanie bazy danych, jeżeli jest inne niż utf8, ustawiamy je na właśnie ten typ kodowania. Wymagania co do komendy mysql_set_charset, manual przedstawia nam: mysql >= 5.0.7, oraz jednoznacznie jest napisane że SET NAMES nie powinno się wykonywać poprzez mysql_query, przykład:
$result = mysql_query("set names 'utf8'";);
Dobrym też nawykiem, bynajmniej dla mnie jest też stosowanie htmlspecialchars (oczywiście z utf-8 i ENT_QUOTES) przy zapisie danych do bazy, powoduje to konwersję znaków na encje, przy czym kodowanie tego typu znaków nie powinno się burzyć. Kolejnym dobrym nawykiem podczas walidacji danych z formularza powinno być z Waszej strony sprawdzanie typu kodowania znaków przesyłanych przez formularz do Waszego skryptu, poprzez mb_check_encoding, używamy:
Kanał ATOM
