Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #20584 > unrolled thread

query db

Back to article view | Back to it.comp.www.php

Contents

  query db "Halnow" <21718invalid@mynewsgate.net> - 2016-03-26 10:04 +0000
    Re: query db Alex <tommaso5ita@yahoo.it> - 2016-03-26 11:44 +0100
      Re: query db Enrico Maria Chellini <bitit@bitit.it> - 2016-04-02 16:52 +0200
        Re: query db Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-02 20:24 +0000
          Re: query db Alex <tommaso5ita@yahoo.it> - 2016-04-03 13:45 +0200
            Re: query db Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-03 13:32 +0000
              Re: query db Alex <tommaso5ita@yahoo.it> - 2016-04-03 18:30 +0200
                Re: query db Alessandro Pellizzari <shuriken@amiran.it> - 2016-04-03 18:12 +0000
                  Re: query db Alex <tommaso5ita@yahoo.it> - 2016-04-04 11:05 +0200
    Re: query db Alessandro Pellizzari <shuriken@amiran.it> - 2016-03-26 17:48 +0000

#20584 — 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 :)

[toc] | [next] | [standalone]

#20585

Halnow ha spiegato il 26/03/2016 :

>
> ho provato anche ad aggiungere addslashes 
>
> SELECT * FROM DB WHERE nominativo LIKE '%'.addslashes($nominativo).'%' 
>
>
> 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: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#20594

Alex wrote:

> Halnow ha spiegato il 26/03/2016 :
> 
>>
>> ho provato anche ad aggiungere addslashes
>>
>> SELECT * FROM DB WHERE nominativo LIKE '%'.addslashes($nominativo).'%'
>>
>>
>> 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
> 

e insere nel database delle stringhe con htmlspecialcharacters ?

http://php.net/manual/en/function.htmlspecialchars.php

Enrico

[toc] | [prev] | [next] | [standalone]

#20596

Il Sat, 02 Apr 2016 16:52:27 +0200, Enrico Maria Chellini ha scritto:

> e insere nel database delle stringhe con htmlspecialcharacters ?
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#20597

Alessandro Pellizzari ha pensato forte :
> Il Sat, 02 Apr 2016 16:52:27 +0200, Enrico Maria Chellini ha scritto:
>
>> e insere nel database delle stringhe con htmlspecialcharacters ?
>> 
>> http://php.net/manual/en/function.htmlspecialchars.php
>
> Hai il problema di come tornare alla stringa originale.
>
> 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.
>
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.
Bye

-- 
Alex

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#20598

Il Sun, 03 Apr 2016 13:45:51 +0200, Alex ha scritto:

> 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.

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.

[toc] | [prev] | [next] | [standalone]

#20599

Alessandro Pellizzari ha pensato forte :

> Non so se ho capito bene cosa intendi.
hai capito benissimo!
>
> 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).
>
Uniformato tutto. Temevo.
In breve, se inizi un lavoro nuovo puoi facilmente uniformare tutto. Se 
rivedi qualcosa già fatto, con il set di caratteri della tabella del db 
che magari non è quello dell' html incontri delle difficoltà.
Forse per questo è stata prevista l' htmlentities() ?

> Bye.

Bye

-- 
Alex

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#20600

Il Sun, 03 Apr 2016 18:30:06 +0200, Alex ha scritto:

> Uniformato tutto. Temevo.
> In breve, se inizi un lavoro nuovo puoi facilmente uniformare tutto. Se
> rivedi qualcosa già fatto, con il set di caratteri della tabella del db
> che magari non è quello dell' html incontri delle difficoltà.
> 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.

[toc] | [prev] | [next] | [standalone]

#20601

Alessandro Pellizzari ha pensato forte :

>
> 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.
>

Beh, grazie :-)

Bye
> Bye.

-- 
Alex

--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#20587

Il Sat, 26 Mar 2016 10:04:23 +0000, Halnow ha scritto:

> Quando memorizzo un dato nel DB, effettuo un addslashes sul campo utente
>  poichè alcuni nominativi possono avere apici al loro interno.

Anche tu vittima di tutorial stravecchi mai rimossi da Internet, eh? :)

addslashes() è sbagliato.

Devi usare PDO, che è il modo più semplice e chiaro.
In alternativa le funzioni/classi mysqli o, al massimo, 
mysql_real_escape_string()

> SELECT * FROM DB WHERE nominativo LIKE '%'.$nominativo.'%'
> 
> ho provato anche ad aggiungere addslashes
> 
> 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.

[toc] | [prev] | [standalone]

Back to top | Article view | it.comp.www.php

csiph-web