MySQL: query di confronto date su campi varchar

(No Ratings Yet)

 Loading ...

Posted by raphe | Filed under Programming, Varie

Se per qualche ragione avete un database MySQL in cui ci sono dei campi data il cui formato non è “date” ma testo normale (ad es. “varchar”, “char”, ecc.) e volete comunque effettuare delle query di ricerca filtrando per data, potete combinare due funzioni di MySQL che fanno proprio al caso vostro.

Le funzioni sono:

• DATE_FORMAT che formatta una data in una sintassi da voi stabilita;
• STR_TO_DATE che converte una stringa in una data in formato MySQL (YYYY-mm-dd).

Vediamo un esempio:

supponiamo di avere un campo che si chiama “data_nascita” che è un varchar e contiene la data in formato dd/mm/YYYY, ecco come effettuare la query:

SELECT data_nascita,DATE_FORMAT(STR_TO_DATE(data_nascita,'%d/%m/%Y'),'%Y-%m-%d')

FROM utenti;


In questo modo otterremo due colonne, una con la data in formato originale e l’altra con la data in formato MySQL.

Se ad esempio vogliamo cercare tutte le persone nate prima del 2000 potremmo scrivere qualcosa del genere:

SELECT *

FROM utenti

WHERE DATE_FORMAT(STR_TO_DATE(data_nascita,'%d/%m/%Y'),'%Y-%m-%d')<'2000-01-01'

In ogni caso ricordate che è buona norma avere i campi data in formato “date”. Questo velocizzerà le query di ricerca. Se possibile convertite gli eventuali campi varchar in campi date.

Tags: date > date_format > db > mysql > Programming > str_to_date > Varie

Caratteri speciali & codifiche su php, mysql e javascript: la soluzione definitiva

(1 votes, average: 5,00 out of 5)

 Loading ...

Posted by raphe | Filed under Appunti, Programming

Il titolo del post è un po’ caotico ma non avevo idea di come scrivere qualcosa di più esplicativo.
Come per i post relativi alle sessioni, anche questo post ha l’obiettivo di essere un appunto per me per il futuro e un riepilogo di cose conoscenze acquisite nel tempo.

Dimentichiamoci delle funzioni htmlspecialchars, htmlentities, html_entity_decode, addslashes, escape, encodeURI, ecc…con una buona configurazione dei vari componenti potremo lavorare in modo trasparente!

Un po’ di teoria

La questione “caratteri speciali” è ben nota a chi si trova a sviluppare per il web, in giro per la rete ci sono centinaia di blog, forum e siti che suggeriscono modi per mostrare al meglio i caratteri accentati e ogni tipo di entità html. La difficoltà sta quasi sempre nell’uso di diverse codifiche nei vari componenti coinvolti (linguaggi di programmazione, database, browser, ecc.). Come prima cosa è bene, quindi, decidere all’inizio quale codifica utilizzare e portare avanti questa scelta in tutti i settaggi che verranno fatti in futuro.

UTF-8 è la codifica che andremo ad utilizzare (dato l’elevato numero di caratteri rappresentabili) ma il discorso vale per qualsiasi codifica vogliate usare.

Innanzitutto è bene sapere che anche i linguaggi di programmazione hanno diversi modi di rappresentare e gestire i caratteri speciali. Ne consegue che ad ogni passaggio da db a linguaggio e da linguaggio a browser si debbano fare delle conversioni. A questo proposito esistono numerose funzione di encoding e decoding in php, js, ecc.

Questa operazione è macchinosa e non scalabile (ci si deve ricordare ogni volta di convertire tutti i dati in transito). L’approccio che presenterò in questo post è diverso: utilizziamo i caratteri speciali per come sono senza convertirli in nessun modo utilizzando solo qualche settaggio e molta attenzione.

Passiamo alla pratica

Innanzitutto è bene iniziare con il database. Nel nostro caso stiamo lavorando su mysql quindi ricordiamoci di creare il database sul quale lavoreremo con collation utf8_general_ci (o altri tipi di utf8), di settare lo stesso valore anche per:

• connessione mysql;
• ogni tabella creata;
• ogni campo testuale di ogni tabella.

Dopo questo passo sappiamo per certo che il database è pronto a gestire dati UTF-8.

Ovviamente dovremo ora comunicare con il database. Per questo esempio utilizzerò la libreria PEAR::MDB2 (consiglio a tutti di lavorare con qualche libreria e non a mano, per avere alcuni automatismi e funzionalità aggiuntive). Nel caso di MDB2 dovremo solo ricordarci di settare il charset sulla connessione al db al primo utilizzo, con il seguente metodo:

$mdb2->setCharset(‘utf8′);

Ora sappiamo che ogni comunicazione (lettura e scrittura) con il database avverrà utilizzando utf8.

Fase seguente è l’inserimento dei dati da parte dell’utente. Ovviamente, come detto sopra, se codifichiamo i dati che l’utente inserisce dovremo poi decodificarli ad ogni utilizzo. Noi non lo faremo. Lasciamo inserire all’utente ogni tipo di carattere (àé!’^$%…) e mettiamolo in database “senza toccarlo”, possiamo farlo perché le tabelle e la connessione in utf-8 ce lo permettono.

Fatto questo nel database avremo i caratteri veri e propri e sarà più facile gestire la fase di visualizzazione. Proprio quest’ultima di solito crea problemi di conversione, soprattutto quando si lavora con javascript che codifica i caratteri speciali in modo diverso dalle entità html.

In fase di visualizzazione dovremo assicurarci che le pagine html generate abbiano anche esse la codifica settata ad utf-8 con l’utilizzo del tag meta, in questo modo:

<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ />

Il testo estratto dal database sarà quindi mostrato direttamente nella pagina che, usando charset utf-8, mostrerà i caratteri speciali senza problemi.

Lo stesso vale se questi dati vengono passati a funzioni javascript per elaborarli o mostrarli: non sarà necessario nessuna chiamata a funzioni di decodifica perché javascript è in grado di visualizzare i caratteri speciali se passati esplicitamente.

Prima di concludere è  importante dire qualcosa relativa al fatto di lasciare inserire all’utente tutti i caratteri che vuole. Questo potrebbe essere un baco di sicurezza per la possibilità di inserire codice malevolo o tentare sql injection. Dal punto di vista delle injection saremo protetti dalla libreria in uso (perciò dovreste usarne una) che si occuperà di gestire le query in ingresso al meglio con opportuni escape – quando necessari – e uso di altre protezioni. Ciò significa che non dovremo fare l’escape di caratteri potenzialmente pericolosi come apice singolo (‘) o doppio apice (“), né lasciarlo fare ad apache. Un escape di questo tipo richiederebbe, infatti, l’unescape al momento della lettura di tutti dati e non avremmo risolto niente.

Per evitare che apache faccia l’escape automatico settiamo nel file php.ini tutte le direttive relative a magic_quotes a Off. In particolare:

magic_quotes_gpc = Off

A questo punto l’ultima cosa che ci resta da fare è evitare che l’utente inserisca codice malevolo nel database. Questo possiamo realizzarlo tranquillamente con l’utilizzo della funzione strip_tags di php. Ad ogni query di inserimento chiamiamo questa funzione che pulirà il testo dai tag inseriti. In visualizzazione non dovremo fare nulla…che era proprio il nostro obiettivo.

Tags: Appunti > caratteri speciali > codifica > entità > html > javascript > mysql > php > Programming > utf-8

PHP: PEAR::DB non mi rimuove i caratteri di escape?

(No Ratings Yet)

 Loading ...

Posted by redsend | Filed under Programming

Se state utilizzando PEAR::DB come libreria per accedere ad un database forse vi sarà capitato di avere problemi con i caratteri di escape memorizzati nel database.

Cosa succede?

Leggi il resto…

Tags: database > mysql > pear > php > Programming