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:
Ostatnio dłuższy czas nic na blogu nie pisałem, ale to dlatego że w pracy siedzimy głównie nad rozbudową oraz dopracowywaniem obecnych rozwiązań to głównie programowanie ogranicza się do tworzenia kolejnych list, zestawień itp. Niestety nie jest to ani nic skomplikowanego, nietypowego czy stawiającego jakiekolwiek wyzwania. Dlatego aby nie zapomnieć o blogu i coś w końcu napisać tym razem opiszę zastosowanie w praktyce Zend_Paginatora
Diagram użytych w przykładzie tabel
W prawie każdym projekcie istnieją listy, zestawienia, raporty itp. W dobrym guście (nie wspominając o wygodzie) jest aby listy te były sortowalne, i w przypadku większej ilości danych podzielone na strony (chociaż tu mój szef ma ostre obiekcje i zawsze chce wszystkie rekordy (często nawet kilka tysięcy) na jednej stronie).
Do tworzenia takich właśnie list został stworzony Zend_Paginator. Poniżej natomiast przedstawię moje podejście do jego praktycznego i dość elastycznego wykorzystania.
Zaczniemy sobie od stworzenia problemu – w końcu na nich najszybciej się człowiek uczy (podobno 
). Załóżmy że mamy prosty blog i 2 tabele – posty i autorzy oraz proste zadanie – wyświetlić listę/wyszukiwarke postów
Zacznijmy więc od stworzenia sobie kontrolera:
Kanał ATOM
<?php
class test_ListsController extends Zend_Controller_Action
{
/**
* Index
*/
public function indexAction ()
{
$postsModel = new test_models_Posts( );
// Czyścimy sobie dane otrzymane z GET/POST
$params = $this->_parseSearchParams( $this->getRequest()->getParams() );
// Tworzymy formę wyszukiwania
$searchForm = new test_forms_SearchForm( );
$searchForm->setAction( '/test/lists/index' );
$searchForm->setDefaults( $params );
$this->view->searchForm = $searchForm;
// Przekazujemy otrzymane parametry do widoku - jeszcze nam się przydadzą
$this->view->params = $params;
// Pobieramy selecta na którym będziemy bazowali
$select = $postsModel->prepareFetchAllSelect( $params );
// Przypisujemy selecta do paginatora
$paginator = new Zend_Paginator( new Zend_Paginator_Adapter_DbTableSelect( $select ) );
// Ustawiamy aktualną stronę na której jesteśmy (domyślnie 1)
$paginator->setCurrentPageNumber( $this->getRequest()->getParam( 'page', 1 ) );
// Ustawiamy ilość rekordów na stronę
$paginator->setItemCountPerPage( $params[ 'perPage' ] );
$this->view->paginator = $paginator;
}
/**
* Czyści i poprawia tablicę parametrów dla wyszukiwania
*
* @param array $params tablica parametrów GET/POST
* @return array poprawiona i wyczyszczona tablica parametrów
*/
private function _parseSearchParams ( $params )
{
// Domyślnie chcemy wyświetlać po 5 rekordów na stronę
if ( ! isset( $params[ 'perPage' ] ) ) {
$params[ 'perPage' ] = 5;
}
// Domyślnie chcemy wyświetlać tylko aktywne posty
if ( ! isset( $params[ 'active' ] ) ) {
$params[ 'active' ] = 1;
}
foreach ( $params as $key => $value ) {
// Filtrujemy puste wartości
if ( is_null( $value ) or $value == '' ) {
unset( $params[ $key ] );
continue;
}
switch ( $key ) {
case 'module':
case 'controller':
case 'action':
case 'submit':
// Te dane nie będą nam potrzebne - usuwamy
unset( $params[ $key ] );
continue;
break;
}
}
return $params;
}
}
Kod jest skomentowany i chyba nie wymaga większych wyjaśnień.
Pierwszą wartą wspomnienia rzeczą jest metoda _parseSearchParams(). Tam wydzielam wszelką logikę związaną z specjalnymi przypadkami filtrowania czy ustawiania wartości domyślnych dla danej listy (jak np. domyślne pokazywanie tylko aktywnych postów).
Idąc dalej trafiamy na formę test_forms_SearchForm – naszą wyszukiwarkę: