Operacje na ciągach znaków to jedne z popularniejszych zadań programistycznych  realizowanych w typowym projekcie serwisu internetowego tworzonego przy pomocy PhP. Jedną z popularnych operacji wykonywanych na ciągach znaków to konwersja na ciągi złożone jedynie z małych liter. Realizacja tego zadania jest raczej trywialna. Wystarczy, że użyjecie dostępną w PhP funkcję strtolower() lub w przypadku zamiany pierwszej litery lcfirst().

Zadanie robi się już nieco trudniejsze gdy przyjedzie Wam pracować z ciągami znaków wśród których znajdą się litery odpowiadające znakom diakretycznym charakterystycznym dla danego narodowego alfabetu. Użycie funkcji strtolower oraz lcfirst nie spowoduje że tego typu duże litery będą zamienione na małe. Znaki wykraczające poza zakres liter ‚alphabetic’ są pomijane przez te funkcję.

W takich sytuacjach z pomocą przyjdzie Wam funkcja mb_strtolower($string, $encoding) dostępna w ramach rozszerzenia Multibyte String Functions. Drugi (opcjonalny) argument tej funkcji określa kodowanie znaków konwertowanego ciągu znaków. Pozwala to na obsłużenie praktycznie każdego języka jaki jest obecnie używany w internecie. Warto dodać, że rozszerzenie to nie jest domyślnym rozszerzeniem PhP a co za tym idzie, nie każdy na każdym hostingu możliwe będzie skorzystanie z funkcji mb_strtolower().

W ramach uzupełnienia tematu dodam jeszcze mały tutorial z zakresu MySQL odpowiadający na pytanie: A co zrobić w przypadku, gdy to w bazie danych w jednej z kolumn tabeli mam ciąg znaków, który w trwały sposób chciałbym zamienić na wyrazy składające się tylko z małych liter. Oczywiście można tę operację wykonać po stronie PhP za pomocą funkcji wymienionych wyżej. Jednak znacznie bardziej optymalnym i szybszym rozwiązaniem będzie wykonanie tej operacji za pomocą pojedynczego zapytania UPDATE. Poniżej znajdziecie przykład tego typu zapytania SQL:
UPDATE `tabela` SET `nazwa_kolumny`=LOWER(`nazwa_kolumny`);
Po wykonaniu tego zapytania, we wszystkich rekordach w kolumnie `nazwa_kolumny` znajdą się ciągi znaków składające się tylko z małych liter.

Oczywiście wykonanie takiego zadania jest możliwe na poziomie odpowiedniej konfiguracji serwera. Jednak w przypadku zdecydowanej większości hostingów, zrealizowanie takiego zadania nie jest możliwe. W przypadku typowego wirtualnego hostingu jedynym sensownym rozwiązaniem jest wykorzystanie dobrodziejstwa pliku konfiguracyjnego .htaccess serwera Apache dla danego podkatalogu.

Poniżej znajdziecie odpowiedni kod dzięki któremu apache do każdego nagłówka określonego pliku doda deklarację wieku danego pliku:

<IfModule mod_headers.c>
 <FilesMatch "\.(jpg|jpeg|png|gif|swf|JPG)$">
 Header set Cache-Control "max-age=4838400, public"
 </FilesMatch>
 <FilesMatch "\.(css|js)$">
 Header set Cache-Control "max-age=4838400, private"
 </FilesMatch>
 </IfModule>

W zasobach internetu znajdziecie inne podobnego rodzaju rozwiązania, warto jednak zwrócić uwagę, że w przypadku plików typu css i js Cache-Control musi mieć atrybut Private a nie Public. W przeciwnym wypadku aplikacja PSI w dalszym ciągu będzie wykazywać Wam te pliki jako takie, które nie mają określonej żywotności.

Pewnie niektórzy z Was zrodzi się pytanie: Czy te zmiany mają wpływ tylko i wyłącznie na punktację w PSI?

Oczywiście wprowadzanie tych zmian tylko i wyłącznie w celu uzyskania lepszego wyniku nie ma większego sensu (poza satysfakcją). Zdecydowanie ważniejszą korzyścią jest to, że dzięki tym zmianom Apache instruuje przeglądarkę, aby w pierwszej kolejności starała się ładować pobierane zasoby z lokalnego dysku komputera użytkownika, a nie z sieci. Oczywiście przy pierwszym wywołaniu danego elementu (np. obrazka jpg) musi on zostać pobrany, jednak każde kolejne wywołanie tego elementu będzie powodowało odwołanie do pliku znajdującego się w cache przeglądarki. Zdecydowanie skraca to czas ładowania się stron, oraz zmniejsza ilość danych przesyłanych między serwerem a komputerem użytkownika.

A jak zmieniło to wynik uzyskiwany przez moją stronę w PSI? Poniżej znajdziecie zrzut:

Jak widać naprawdę niezły skok :).

W pliku css możliwe jest to za pomocą @fotn-face. W przypadku większości przeglądarek wystarczający jest plik TTF, niestety Internet Explorer jest tu wyjątkiem wymagającym specjalnego traktowania. Od wersji 6 do wersji 8 operacja ta obsługiwana jest za pomocą pliku z EOT (Embedded OpenType).

Dosyć dużym problemem jest wygenerowanie prawidłowo działającego pliku EOT. Teoretycznie pomoc powinno stanowić narzędzie WEFT dostarczane przez Microsoft. Niestety program ten jest bardzo stary i w większości wypadków mówiąc delikatnie działa mało zadowalająco (bardzo często zawiesza się oraz wypuszcza nieprawidłowe pliki). Obecnie jedynym w pełni działającym narzędziem (jakie znalazłem) umożliwiającym utworzenie sprawnego pliku EOT jest konwerter online dostępny pod wskazanym adresem:
http://www.kirsle.net/wizards/ttf2eot.cgi

IE9 wnosi kolejną zmianę do obsługi ładowanych czcionek. W tej wersji przeglądarki obsługa opiera się na nowym formacie plików WOFF (Web Open Font Format) opracowanym przez W3C. Najprawdopodobniej w przyszłości będzie to ogólny standard przyjęty przez wszystkie popularne przeglądarki.

Stosowanie @font-face w pliku CSS, wymaga bardzo starannej deklaracji, szczególnie istotna jest kolejność formatów plików. Poniżej znajdziecie prawidłową kolejność, która powinna działać poprawnie na wszystkich popularnych przeglądarkach (również mobilnych):

@font-face {
font-family: ‚MyWebFont';
src: url(‚/katalog/nazwaPliku.eot’);
src: url(‚/katalog/nazwaPliku.eot?#iefix’) format(‚embedded-opentype’),
url(‚/katalog/nazwaPliku.woff’) format(‚woff’),
url(‚/katalog/nazwaPliku.TTF’)  format(‚truetype’)
font-weight: normal;
font-style: normal;
}

Pewnie w tym momencie zaświecą się oczy wielu osobom, które chciały by ukryć w ten sposób arkusz stylów przed „przeciętnymi” użytkownikami. Niestety muszę ostudzić Wasz zapał, gdyż ta metoda linkowania ma również jedną bardzo dużą wadę dyskwalifikującą ją z powszechnego użycia … w tej chwili metoda ta jest obsługiwana jedynie przez Operę i Firefoxa.

W dalszym ciągu tego sposobu ładowania pliku CSS można użyć jeśli chcemy dodać „spersonalizowane” style dla przeglądarek obsługujących tę metodę linkowania. Na chwilę obecną to chyba jedne sensowne zastosowanie dla tej metody.

Jednym z popularnych zadań jakie może realizować GD to konwersja tekstu do pliku graficznego. Poniżej znajdziecie przykładowy listing w którym przestawiam realizację takiej operacji. Oczywiście należy potraktować ten kod bardziej jako przykład możliwości niż samo rozwiązanie tego zagadnienia.

<?php
header('Content-Type: image/png');

imagepng($im);
imagedestroy($im);
?>

Omawianie początkowego kodu zawierającego definicję tekstów poddawanych konwersji pomijam, właściwe wykorzystanie GD2 rozpoczyna się na etapie tworzenia zasobu zawierającego obrazek. Za działanie to odpowiada funkcja: imagecreatetruecolor(). Argumenty tej funkcji to szerokość oraz wysokość utworzonego obrazka. Funkcja zwraca identyfikator zasobu lub „false” w przypadku błędnego działania. Utworzony obrazek będzie miał założone wymiary oraz zostanie wypełniony czarnym kolorem.

W kolejnym kroku definiowane są kolory przypisane do utworzonego obrazka. Operację tę realizuje funkcja imagecolorallocate(resource $image , int $red , int $green , int $blue ). Argumenty tej funkcji to: $image – identyfikator zasobu, $red – poziom wartości koloru czerwonego 0-255, $blue – poziom wartości koloru niebieskiego 0-255, $green – poziom wartości koloru zielonego 0-255. Jeśli zależy Wam aby przypisany kolor odpowiadał konkretnej barwie, to w celu uzyskania wartości jego składowych w przestrzeni barw RGB, najlepiej skorzystać z jednego z programów graficznych (GIMP, Photoshop) lub innego narzędzia, gdzie możecie podejrzeć te wartości.

Tak jak pisałem wcześniej, utworzony obrazek będzie w całości wypełniony czarnym kolorem. Korzystając w funkcji imagefilledrectangle() wypełnimy go w całości białym kolorem. Funkcja ta ma następujące argumenty: resource $image – identyfikator zasobu , int $x1 – wartość współrzędnej x punktu początkowego , int $y1 – wartość współrzędnej y punktu początkowego  , int $x2 – wartość współrzędnej x punktu końcowego, int $y2  – wartość współrzędnej y punktu końcowego, int $color – identyfikator koloru wykorzystanego do wypełnienia. Warto zwrócić uwagę, że wartości współrzędnych punktu początkowego i końcowego operują od 0, co oznacza że w przypadku naszego obrazka zakres wartości x mieści się w przedziale <0,99> a współrzędnej y w przedziale <0,29>.

Kolejna operacja jaką musimy wykonać, to podanie miejsca w którym znajdują się kroje czcionek jakie chcemy wykorzystać przy pomocy biblioteki GD2. Za wykonanie tej operacji odpowiada funkcja putenv('GDFONTPATH=' . realpath('.')). Wynikiem działania tej funkcji jest przypisanie danej wartości do zmiennej środowiskowej serwera. Warto zauważyć, że wykonane działanie ma jedynie zasięg lokalny i jest widoczne jedynie dla danego skryptu PHP w którym funkcja została użyta. W naszym przypadku do zmiennej środowiskowej GDFONTPATH została przypisana wartość funkcji realpath('.'), czyli ścieżka do bieżącego katalogu w którym znajduje się skrypt. W przypadku, gdy plik z krojem czcionki znajduje się w innym katalogu, musicie wskazać poprawny adres do właściwego  katalogu.

W kolejnym kroku utworzymy cień do napisu. Budując tego typu obrazki musicie rozdzielić je na poszczególne warstwy składowe, które będą tworzone w odpowiedniej kolejności. Cień znajduje się nad tłem ale pod finalnym tekstem, więc musi być on utworzony między tymi warstwami.

Do transformacji tekstu na obraz posłużymy się funkcją imagettftext(). Funkcja ta ma następujące argumenty: $image – identyfikator zasobu , $size – wielkość textu , $angle – kąt pod jakim tekst będzie pisany , $x – wartość współrzędnej x początkowego punktu , $y – wartość współrzędnej y punktu , $color  – identyfikator koloru, $fontfile – ścieżka do pliku z krojem czcionki , $text – tekst przeznaczony do konwersji. W celu uzyskania bardziej rzeczywistego wyglądu cienia, stosując funkcję imagefilter($im, IMG_FILTER_SMOOTH, 1) – wykonamy rozmycie obrazka. Oczywiście rozmycie będzie dotyczyły bieżącego stanu w jakim znajduje się grafika, zastosowanie filtru nie ma wpływu na kolejne warstwy i efekty stosowane na dany obrazek.

Korzystając znów z funkcji imagettftext() dodamy właściwy tekst, który będzie przesunięty o 2 piksele w górę i w lewo w stosunku do cienia. W ostatnim kroku z uzyskanego zasobu $im uzyskamy finalny obrazek w postaci PNG. Działanie to realizowane jest za pośrednictwem polecenia imagepng($im). Na samym końcu niszczymy utworzony zasób $im – imagedestroy($im).

Wywołanie w przeglądarce pliku zawierającego powyższy kod, spowoduje wyświetlenie się utworzonego obrazka. Warto zauważyć, że w przypadku gdy nie prześlemy w nagłówku informacji o formacie pliku – header('Content-Type: image/png'); – po wywołaniu pliku w w oknie przeglądarki plik będzie prezentowany jako plik tekstowy a nie plik graficzny. Mam nadzieję że zachęciłem Was do nauki i zabawy z biblioteką GD2.

Przykład

Od jakiegoś czasu bardzo chętnie stosuję tę funkcję. Muszę przyznać, że jest ona wygodna i znacznie ułatwia implementację eksportu danych do pliku. Poniżej znajdziecie przykładowy kod PHP w którym wykonano prosty eksport danych pozyskanych z bazy MySQL do pliku CSV, który ma być wykorzystywany w programach z pakietu MS Office.

$usersRes = $pdo->query('SELECT * FROM `user`');
$users = $usersRes->fetchAll(PDO::FETCH_ASSOC);

$data = array();
$data[0]['id_user'] = 'Id';
$data[0]['f_name'] = 'Imię';
$data[0]['s_name'] = 'Nazwisko';
$data[0]['email'] = 'Email';
$data[0]['city_c'] = 'Miejscowość';
$data[0]['post_c'] = 'Kod pocztowy';
$data[0]['phone_c'] = 'Telefon';
$data[0]['add_date'] = 'Data rejestracji';

$datas = array_merge($data,$users);

foreach($datas as $key => $data){
foreach($data as $key_s => $single_data){
$datas[$key][$key_s] = iconv("UTF-8","cp1250", $single_data);
}
}

$filename = 'users.csv';

$FileHandle = fopen($filename, 'w+') or die("can't open file");

foreach($datas as $key => $data) {
fputcsv($FileHandle, $data, ';', '"');
}

fclose($FileHandle);


Omówienie kodu

Idąc od góry – pobranie danych za pomocą PDO w postaci tablicy asocjacyjnej. Utworzenie tablicy $data zawierającej nagłówek dla tabeli. Złączenie tablicy (array_merge) z nagłówkami kolumn z tablicą z danymi. Kolejnym ważnym krokiem jest konwersja kodowania w pozyskanych danych w celu prawidłowego wyświetlania danych w programach uruchamianych w Windowsie. W pętli pojedyncze pola rekordów konwertowane są na kodowanie cp1250 (właściwe dla MS Windows). W dalszej części tworzony jest uchwyt do podanego pliku csv (w+ – wskaźnik ustawiany na początku pliku, jeśli plik nie istnieje to będzie podjęta próba stworzenia go). Ostatnia część kodu odpowiada za wsad danych do pliku. I tyle :).

Bardzo szybkie i efektywne rozwiązanie wszelkiego rodzaju eksportów danych. Oczywiście można powyższy kod jeszcze uprościć, np dokonywać konwersji znaków na poziomie bazy danych (wykonanie zapytania: SET NAMES CP1250; przed właściwym zapytaniem pozyskującym dane) … ale takie zmiany pozostawiam już w Waszych rękach.

Wyczerpywanie limitu pamięci spowoduje, że zwiększanie wartości session.gc_maxlifetime w ini_set nie będzie dawało żadnych wymiernych korzyści. Garbage collection i tak notorycznie będzie niszczył najstarsze nieaktywne sesje. Ciągła rotacja powracających wylogowanych użytkowników będzie powodowała krótkie trwanie pozostałych sesji.

W niektórych przypadkach można dokonać optymalizacji kodu źródłowego witryny, przez rezygnację z utrzymywania niektórych danych jako zmienne sesyjne. Będzie to jednak dosyć trudne do wykonania w przypadku obszernych istniejących już projektów. W takich przypadkach modyfikacja kodu będzie pracochłonna

Oczywiście można zwiększyć zasoby fizyczne serwera, lub też zmienić jego konfigurację. Jest to możliwe jedynie w sytuacjach, gdy masz pełną kontrolę nad serwerem. W większości wypadków, rozpatrując typowy hosting, rozwiązania te nie są możliwe do wykonania. W takich sytuacjach najlepszym i najprostszym sposobem będzie przeniesienie zawartości sesji z pamięci serwera do plików.

Wykonanie tej operacji jest stosunkowo proste. Można to zrobić na kilka sposobów. Dwa najprostsze to:
umieszczenie w kodzie PHP następującego polecenia:
session_save_path('/sciezka/nazwa_katalogu');

lub umieszczenie w pliku .htaccess następującego wpisu:
php_value session.save_path /sciezka/nazwa_katalogu/

Same zmiany po stronie użytkownika witryny nie będą zauważalne (oczywistym poza wydłużeniem trwania sesji). Dodatkowymi korzyściami jakie możesz wyciągnąć z tych zmian to kontrola nad zalogowanymi użytkownikami. W katalogu, który przeznaczyłeś do przechowywania zawartości sesji, znajdziesz pliki, których nazwy wyglądają mniej więcej w ten sposób:

sess_004a0196f6d57c622454e5f0cb19678b

Część nazwy pliku po znaku „_” to identyfikator sesji. We wnętrzu pliku znajdziesz zserializowaną zawartość tej sesji. Dzięki w miarę prostej aplikacji napisanej w PHP można zbudować raport, który pozwoli na sprawdzenie którzy użytkownicy mają aktywne sesje, oraz podejrzenie zawartości ich sesji. Skasowanie pliku sesji jest równoznaczne z wylogowaniem użytkownika z witryny (zniszczeniem jego sesji). Pozwala to w łatwy sposób wylogować, pojedynczego użytkownika, grupę lub wszystkich użytkowników danego serwisu.

Dzięki znajomości identyfikatora sesji użytkownika możliwe jest również wykonanie operacji podszycia się pod dane zalogowane konto. Wystarczy skorzystać choćby z firefoxa wzbogaconego o dodatek firebug, który pozwala edytować wartości przechowywanych w cookies. Ta korzyść to jednak bardziej ciekawostka niż przydatna właściwość (być może jednak są osoby które skorzystają z tej opcji).

Osobiście korzystam z utrzymywania sesji w plikach, od ponad roku i jak na razie nie spotkałem się z sytuacją, aby rozwiązanie to miało jakiś niekorzystny wpływ na działanie serwisu. Od tamtej pory nie spotkałem się z uwagami co do działania sesji oraz długości ich trwania. Sesje trwają dokładnie tyle na ile ustawiony jest parametr session.gc_maxlifetime. Z czystym sumieniem mogę polecić to rozwiązanie :).

Kilka lat temu w MySQL domyślnym typem tabel był MyISAM i chociaż InnnoDB było wtedy już dostępne to jednak niewiele osób korzystało z tego rozwiązania. Szkoda, bo mimo pewnych wad, niewątpliwą zaletą InnoDB jest możliwość zrzucenia utrzymywania integralności danych na MySQL’a. Poświęcając odpowiednią ilość czasu na wykonanie prawidłowego projektu relacyjnej bazy danych opartej na tabelach typu InnoDB, nie będziemy tracić czasu na kodowanie odpowiednich metod utrzymujących integralność danych w bazie.

Jedną z podstawowych zalet mechanizmu składowania InnoDB, której nie posiada MyISAM to możliwość definiowania kluczy obcych w tabelach. W przypadku MyISAM klucze obce mogły być jedynie indeksowane, co oczywiście wpływało na na szybkość wykonywania zapytań jednak nie miało przełożenia na utrzymywanie integralności danych. Osobiście uważam, że w obecnej chwili poza wyjątkowymi sytuacjami praktycznie nie ma uzasadnienia by w swoich projektach wciąż kurczowo trzymać się MyISAM. Część osób w tym momencie powie, że InnoDB nie ma wyszukiwania pełno-tekstowego (Full-text search indexes) … no cóż od wersji 5.6.4 już ma, więc jeśli dysponujesz taką lub wyższą wersją MySQL, to wtedy pada ostatni bastion by nie używać InnoDB.

Warto zauważyć, że w przypadku istniejących tabel, zmiana mechanizmu składowania nie wymaga ponownego tworzenia tabel. Zmianę można dokonać wykonując poniższe zapytanie:

ALTER TABLE `nazwa_tabeli` ENGINE = InnoDB

Metodę definiowania kluczy obcych opiszę na podstawie przykładów opartych na poniższym schemacie ERD prostej bazy danych:

Baza składa się z dwóch tabel w których przechowywane są dane oraz jednej tabeli asocjacyjne, która je wiąże ze sobą. Po utworzeniu tabel i nadaniu odpowiednich indeksów na klucze można przejść do definiowania kluczy obcych.

ALTER TABLE `uzytkownik_typ` ADD FOREIGN KEY ( `id_uzytkownik` ) REFERENCES `uzytkownik` (`id_uzytkownik`) ON DELETE CASCADE ON UPDATE CASCADE ;

ALTER TABLE `uzytkownik_typ` ADD FOREIGN KEY ( `id_typ` ) REFERENCES `typ` (`id_typ`) ON DELETE CASCADE ON UPDATE CASCADE ;

I już! Dzięki tym prostym zabiegom uzyskaliśmy pełną integralność danych w bazie, oraz kaskadowe usuwanie rekordów. Oznacza to, że każdorazowe usunięcie rekordu z tabeli `typ` lub też `uzytkownik` spowoduje usunięcie wszystkich wystąpień kasowanego klucza obcego w tabeli `uzytkownik_typ`. Przykład:

DELETE FROM `uzytkownik` WHERE `uzytkownik`.`id_uzytkownik` = 1

Wykonanie powyższego zapytania spowoduje usunięcie z tabeli `uzytkownicy` rekordu o identyfikatorze 1. Mechanizmy bazy danych, dążące do utrzymania integralności danych w tabelach wykonaja jednak również usunięcie wszystkich typów przypisanych do kasowanego użytkownika. Usnięte zostaną wszystkie rekordy z tabeli `uzytkownik_typ` w których wartość klucza obcego `id_uzytkownik` są równe 1.

Analogiczna sytuacja będzie występować w przypadku zmiany wartości klucza głównego w tabeli, `uzytkownik` lub `typ`. Każda z takich zmian będzie kaskadowo przenoszona na tabelę asocjacyjną `uzytkownik_typ`.

Jedna uwaga odnośnie modyfikacji istniejących tabel. Sama zmiana mechanizmów składowania na InnoDB nie wymaga zachowania integralności, jednak zdefiniowanie kluczy obcych wymaga doprowadzenia tabel do porządku. Sytuacja gdy tabela będzie  zwiera rekordy w których występują klucze obce, których nie ma w macierzystej, spowoduje zablokowanie możliwości ich zdefiniowania. W takich przypadkach przed definiowaniem kluczy obcych, dane w tabeli muszą być w pełni uporządkowane względem pozostałych tabel. Musisz samodzielnie przeprowadzić integrację tabel.

W zależności od zawartości pola WYNIK test traktowany jest jako zapisany (wartość NULL) lub wysłany (wartość liczbowa decimal z uzyskanym wynikiem). W ostatnim czasie spotkałem się z dziwnym zachowaniem tego mechanizmu testów punktowanych. Korzystając z formularza otwartego w kilku oknach, można było nadpisać pierwotnie wysłane dane z odpowiedziami testu. Błąd ten wynikał z faktu, że mechanizm nie rozpoznawał w prawidłowy sposób statusu wysłanego testu. Było to o tyle dziwne, że patrząc od strony rekordów znajdujących się w bazie danych wyglądało to całkowicie prawidłowo.

Za brak prawidłowego rozpoznania odpowiedzialny był MySQL, dla którego wartość pola WYNIK = NULL jest równoważne z wartością pola WYNIK = 0.00.

W celu sprawdzenia statusu danego testu wykonywane było sprawdzenie liczby rekordów zwracanych przez poniższe zapytanie:
SELECT *FROM `test`
WHERE `id_uzytkownika` =1
AND `punkty` != NULL
w obu przypadkach zwróci ten sam wynik, czyli 0 rekordów.

Sposób na szybkie sprawdzenie rzeczywistego statusu testu to pobranie rekordu danego użytkownika a następnie sprawdzenie wartości pola już po stronie PHP. Można to zrealizować choćby w ten sposób:

$test_wyslany=0;
if (!empty($test['WYNIK'])) {
$test_wyslany=1;
}

$test – tablica z wynikiem powyższego zapytania SQL

Ot taka ciekawostka ze styku programowania i właściwości baz danych.
ddd