Newsgroup: it.comp.www.php
Titolo: query db

Ciao
 
ho realizzato un piccolo gestionale utilizzando php, datatables e mysql.
 
Quando memorizzo un dato nel DB, effettuo un addslashes sul campo utente
 poichè alcuni nominativi possono avere apici al loro interno.
 
consideriamo un nominativo es. D'Andrea Rossi
 
nel db viene memorizzato come
 
D\'Andrea Rossi
 
se provo a digitare nella casella di ricerca di datatables Rossi oppure
Andrea il record viene individuato e mostrato, ma se digito D'Andrea
quindi inserendo l'apice, allora non ottengo alcun risultato.
 
 
 
La query è 
 
SELECT * FROM DB WHERE nominativo LIKE '%'.$nominativo.'%' 
 
ho provato anche ad aggiungere addslashes 
 
SELECT * FROM DB WHERE nominativo LIKE '%'.addslashes($nominativo).'%' 
 
 
Grazie :)
 
 

 Grazie :)
 
Non credo che addslashes() possa funzionare dentro una query.
Forse è meglio scrivere un codice un tantino meno concentrato. Con la 
query più semplice e chiara possibile.
 
Bye
 
-- 
Alex
 
--- news://
freenews.netfront.net/
 - complaints: 
ne...@netfront.net
 ---

 SELECT * FROM DB WHERE nominativo LIKE '%'.addslashes($nominativo).'%'
 
In PDO è una cosa tipo
 
$st = $pdo->prepare('select * from db where nominativo like :nome');
$st->execute(['nome' => '%'.$nominativo.'%']);
 
$result = $st->fetchAll();
 
Ancora più semplice se usi un thin wrapper come Aura.DB
 
Bye.

 
 
e insere nel database delle stringhe con htmlspecialcharacters ?
 
http://php.net/manual/en/function.htmlspecialchars.php
 
 
Enrico

 
http://php.net/manual/en/function.htmlspecialchars.php
 
 
Hai il problema di come tornare alla stringa originale.
 
Non è detto che quella stringa ti serva sempre e solo da mettere in una 
pagina web.
 
Se è un CMS le devi mostrare all'utente in caso di modifica, e la _decode
() presuppone che usi gli stessi flag della fase di encoding.
 
Le funzioni *_escape_string() e PDO sono fatti apposta per non dover 
convertire roba avanti e indietro, e sono il modo corretto per fare 
escaping delle stringhe da mettere in DB.
 
Bye.


Troppo giusto. Il set di caratteri può anche dare qualche grattacapo 
però.
Per esempio una stringa come D' Arquà Petrarca  oppure  Mac O'Brièn che 
hanno di tutto, come le risolvi? Bisogna inserirle in tabella, farci la 
ricerca e ritornarle al browser.


 ricerca e ritornarle al browser.
 
Non so se ho capito bene cosa intendi.
 
Per il charset sul DB dipende da come l'hai configurato. In PotgreSQL 
basta selezionare utf8 e metti quello che vuoi, mentre in MySQL devi stare 
attento perché ce ne sono due: utf8 che non supporta i alcuni caratteri 
(cinesi, giapponesi, klingon, elfico, ecc.) e utf8mb4 che è il "vero" utf8 
che supporta tutto.
 
Una volta che hai uniformato tutto (db, header http, meta charset 
nell'html, ecc.) a utf8 (quello vero), è esattamente la stessa cosa che 
con ASCII semplice (se usi *_escape_string() o PDO, appunto).
 
Bye.

 Bye.


 Forse per questo è stata prevista l' htmlentities() ?
 
No. :)
htmlentities() è stata inventata quando HTML e i browser non supportavano 
UTF8 e charset multipli. 
 
Oggi i browser supportano tutti i caratteri e non ce n'è più bisogno. 
 
Forse, ma non sono sicuro, ti serve quando encodi i CDATA dentro gli XML. 
Ma io evito XML più possiible. :D
 
Se hai i dati nel DB in un certo charset, la cosa più semplice è 
uniformare tutto il resto a quel charset.
 
Hai latin1 in DB? Imposta header HTTP e <meta charset> nell'HTML a latin1.
 
Se devi fare API accessibili in JS (che "ragiona" in UTF8), e ti arrivano 
dati in UTF8, usa mb_convert_encoding() o utf8_encode() per convertire utf8 
in latin1 prima di salvarlo in DB, ma devi essere consapevole che perderai 
tutti i caratteri non supportati da latin1.
 
Se hai tempo di farlo (e il tempo si trova sempre ;), prepara una 
migrazione del DB a UTF8. Il futuro te stesso ti farà una statua in piazza.
 
Bye.

 Bye.
