Un’espressione regolare è per sempre…

Scrivo pochissimo da un po’ di tempo a questa parte, ma è perchè il lavoro mi assorbe completamente : - ( . Metteteci pure che sono in lotta con l’azienda per ottenere un contratto degno di questo nome e capirete che non è che si viva tranquillissimi in questo periodo.

Però, nella migliore tradizione del blog utilizzato come mio personale block notes (forse lo chiamerò blog notes : - P ) oggi vorrei scrivere qualcosina di interessante (quantomeno per me) sul PHP e l’utilizzo delle espressioni regolari.

Non starò qui a dire che esistono due tipi fondamentali di espressioni regolari (le perl compatibili e le posix). Per queste cose c’è il manuale ; - ) . Voglio un po’ dissertare sul loro utilizzo pratico. Perchè e in che contesti possono essere utilizzate.

Cosa permette di fare un’espressione regolare?
Permettono di controllare e manipolare una stringa. Un valore variabile inviato con i comuni metodi di passaggio delle variabili.

In che contesto ha senso utilizzare un’espressione regolare?
Nel contesto in cui il coder individua un’utilità per l’applicazione : - ) . Di base possono essere utilizzate sempre e comunque ci si trovi in presenza di un flusso di dati da controllare.
Nella pratica, un’applicazione utilizzata da un solo individuo coincidente con il coder principale, difficilmente avrà bisogno di espressioni regolari. Diciamo che suonerà strano che il coder dell’applicazione, unico utilizzatore del programma, abbia necessità di controllare se stesso. In teoria dovrebbe conoscere bene la gestione delle stringhe, e non avere bisogno di auto cassarsi in caso di errore.

Se, al contrario, si parla di applicazioni multiutenza e/o ad utilizzo di terze persone, controllare i flussi di questi risulta doveroso. Gli utenti sbagliano. A volte lo fanno con cognizione di causa, spesso lo fanno per pura distrazione, nel 99% dei casi non conoscono le velleità di una stringa passata via http, che dovrà essere salvata in un database (MySQL o chi per lui) e dovrà successivamente essere estrapolata da questo come dato di visualizzazione. L’utente non sa ed è meglio che non sappia questo genere di cose.
Piuttosto che andare a scrivere i manualissimi con indicazione dettagliata di ogni voce di form da inserire, meglio costringere in concreto l’utilizzato a comportarsi in un certo modo, o ancor meglio rendere un comportamento errato, giusto per noi : - ) .

Ma qualche esempio concreto?!
Ce ne sono a bizzeffe! Solo che spesso gli utenti non si accorgono nemmeno di essere vittima di un’espressione regolare : - D .
Avete presente il BBCode (Bulletin Board Code) presente in molte applicazioni per la tenuta di forum e simili? Bene, spesso il BBCode non è altro che una serie di espressioni regolari che controllano un flusso di informazioni e reagiscono sostituendo a certi elementi, quelli che dovranno comparire in visualizzazione.
Non ditemi che non avete mai scritto in un forum una frase fra i tag [b] e [/b]. Se vi siete ritrovati il testo contenuto fra i tag in grassetto è perchè anche voi siete caduti nella tremenda rete delle espressioni regolari : - P .

Volete qualche esempio pratico?
Per prima cosa andatevi a leggere questa pagina. Sapere cos’è un metacarettere è fondamentale al fine di organizzare buoni flussi di controllo!
Ora, posto che abbiate letto tutto per benino, posto che sappiate che per far riconoscere un metacarettere come valore stringa dovete farlo precedere da backslash “”, andiamo a vedere qualche utilizzo pratico delle espressioni regolari : - ) .

Controllo validità password.
Avete il vostro bel form di registrazione. Gli utenti impostano la propria password in fase di registrazione passandola con la variabile $_POST[‘password’].
Voi volete che i vostri utenti usino una password che sia compresa in valori alfanumerici e che abbia lunghezza minima di 6 caratteri e massima di 15. Come fare?
Nella pagina deputata al trattamento delle variabili inviate dall’utente in fase di registrazione, inserite fra l’altro un’espressione regolare di questo tipo:

if(!preg_match(‘/^[A-Za-z0-9]{6,15}$/’,$_POST[‘password’])){

// Avviso che la password non può essere accettata
echo ‘La password deve contenere valori alfanumerici e deve essere di lunghezza non inferiore a 6 e non superiore a 15 caratteri’;

//Cautelativamente interrompo il processo di registrazione
exit();
}

Cosa ho fatto? Con preg_match eseguo il riconoscimento funzionale di una stringa. Il punto esclamativo non fa altro che impostare una negazione. Il tutto va dunque letto così: se la stringa che vado a controllare NON corrisponde ai criteri di controllo impostati.
Andiamo a spiegare ad uno ad uno come è stata scritta l’espressione di controllo:

  • ^ = inizio dell’espressione di controllo.
  • [A-Za-z0-9]: qui imposto tre intervalli, che in questo caso sono di validità.
    • [A-Z]: tutti i caratteri alfabetici maiuscoli.
    • [a-z]: tutti i caratteri alfabetici minuscoli.
    • [0-9]: tutti i caratteri numerici.
  • {6-15}: valore minimo e massimo di lunghezza della stringa.
  • $ = fine dell’espressione di cotrollo.
  • $_POST[‘password’]: stringa da controllare.

Validare il formato data.
Stesso discorso che vale per la password. Faccio scrivere la data in formato GG/MM/AAAA. Una stringa di tipo “23/09/2006” è valida, una di tipo “23/09/06” o “23-09-2006” invece non mi sta bene. Potrei pilotare l’operato dell’utente, ma dato che al momento siamo bastardi dentro, lo costringiamo a riempire nuovamente il form con i dati corretti : - ) .
La nostra variabile da controllare sarà $_POST[‘data’].

if(!preg_match(‘/^[0-9]{2}/[0-9]{2}/[0-9]{4}/’,$_POST[‘data’])){
echo ‘Stai utilizzando un formato data non conforme.<br />
Il formato data corretto deve essere:<br />
<center><strong>GG/MM/AAAA</strong></center>’;
exit;
}

Anche in questo caso uno un’espressione che definiremo di tipo validante, perchè l’evento del flusso if si verificherà in caso di negazione dell’espressione di controllo.
Di fatto cosa faccio? Controllo che la variabile $_POST[‘data’] sia composta da un primo pezzettino numerico di 2 caratteri, dopo di che devo avere il carattere slash “”. Altro pezzettino numerico da due caratteri, altro slash, ed ultimo pezzettino numerico di 4 caratteri : - ) .

Ovviamente l’espressione regolare per come riportata non valida una vera e propria data, ma un formato di testo predefinito. Dovrete implementare altri flussi di controllo per far si che il numero corrispondente al giorno non sia superiore a 31 e quello corrispondente al mese non sia superiore a 12. Ma per il momento non sono controlli che ci interessano ; - ) .

Disabilitare l’HTML in un form.
Abbiamo il nostro bel commentario. In una casella di testo i nostri utenti possono scrivere tutto quello che vogliono, ma noi non vogliamo che questi usino l’HTML, ed allora, magari con una bella espressione regolare, lo disabilitiamo : - ) .
Stabiliamo di controllare la variabile $_POST[‘commento’]. Il modo più facile di eliminare l’html è eliminare tutto quello che è compreso fra < e > .

$_POST[‘commento’] = preg_replace(‘#<(.*?)>#i’,”,$_POST[‘commento’]);

Qualsiasi cosa ci sia dentro i caratteri che identificano sintassi HTML, deve scomparire con i caratteri identificativi stessi!
E se volessimo far sparire anche le istruzioni comprese fra due tag HTML uno di apertura ed uno di chiusura? Ad esempio, la facile istruzione <a href=”link”>TestoLinkato</a>, oppure la pericolosa <script>qualcosa</script>.

$_POST[‘commento’] = preg_replace(‘#<(.*?)>(.*?)</(.*?)>#i’,”,$_POST[‘commento’]);

E saluti e baci : - ) . Non penso ci sia bisogno di ulteriori spiegazioni.

Un po’ di BBCode.
Ok, disabilitiamo l’html, ma vogliamo proprio tarpare le ali ai nostri utenti?! Non siamo poi mica tanto carogne… O quantomeno cerchiamo di non esserlo. Allora costringiamo l’utente a dover usare nostre regole se vuole che un po’ di codice html venga postato nei suoi deliri : - P.
Di fatto implementiamo un po’ di BBCode, che magari usiamo da anni nei nostri forum preferiti. Qui facciamo qualche esempio facile, ma quelli difficili sono solo estenzione di casistica ; - ) . E’ normale che maggiori sono le regole di controllo, maggiore è la difficoltà nel controllare il flusso relativo.

Ma vediamo degli esempi banali partendo dall’assunto che non accettiamo codice html diretto dagli utenti:

 – Permettere il linkining nella variabile $text:

$text = preg_replace(“#[url=(.*?)](.*?)[/url]#i”,”<a href=”\1″ target=”_blank”>\2</a>”,$text);

La tecnica è quella usata di solito da molte board. Per linkare si useranno dei tag predefiniti dall’utente, nella fattispece [url=valore del url]testo linkato[/url].

Notate l’uso del carattere di escape davanti alle parentesi quadre. Necessario perchè altrimenti queste sarebbero lette come metacaratteri.
I valori \1 e \2 nel risultato dell’espressione non sono altro che la specificazione di quello che trona nel primo  e nel secondo (*.?).
E’ poi ovvio che serviranno altri flussi di controllo per verificare che si tratti di un link valido!

 – Inserire immagini. Variabile $text:

$text = preg_replace(“#[img](.*?)[/img]#i”,”<img src=”\1″ alt=”Immagine” />”,$text);

Esattamente come prima! Facile no?

 – Elementi di formattazione. Variabile $text:

  //Grassetto
$text = preg_replace(“#[b](.*?)[/b]#i”,”<b>\1</b>”,$text);  //Corsivo
$text = preg_replace(“#[i](.*?)[/i]#i”,”<i>\1</i>”,$text);

//Sottolineato
$text = preg_replace(“#[u](.*?)[/u]#i”,”<u>\1</u>”,$text);

Non penso ci sia bisogno di spiegare la cosa ; - ) .

Bene, spero sia utile a qualcuno. A me lo sarà sicuramente : - ) . Ovviamente il discorso è molto più lungo e complesso di come è stato presentato da me, ma per queste cose ci sono i manuali, io resto sempre uno smanettone.

Un saluto a tutti e prometto di essere più presente d’ora in poi : - )

4 thoughts on “Un’espressione regolare è per sempre…”

Comments are closed.