sql >> Database >  >> RDS >> Mysql

Wat is het verschil tussen de addlashes van PHP en mysql(i)_escape_string?

Allereerst:gebruik geen mysql_escape_string , het is verouderd (met een reden)!

Als u een verouderde applicatie moet ondersteunen die verbinding maakt met de database via de mysql extensie (die is beëindigd ), gebruik mysql_real_escape_string in plaats van. Anders onmiddellijk overschakelen naar mysqli , waar voorbereide instructies en gebonden parameters een robuuster mechanisme bieden om gebruikersinvoer te ontlopen.

Dat gezegd hebbende, het antwoord kan worden gevonden door de beschrijving te lezen van mysql_real_escape_string en addslashes :

Verschil #1

addslashes weet niets over MySql-verbindingscoderingen. Als je het een string doorgeeft met bytes die een andere codering vertegenwoordigen dan de codering die wordt gebruikt door de MySql-verbinding, zal het met plezier ontsnappen aan alle bytes met de waarden van de tekens ' , " , \ en \x00 . Dit is mogelijk niet hetzelfde als alle tekens ' , " , \ en \x00 als u een andere codering gebruikt dan 8-bits codering en UTF-8. Het resultaat is dat de string die door MySql wordt ontvangen, beschadigd raakt.

Probeer om deze bug te activeren iconv om uw variabele naar UTF-16 te converteren en er vervolgens aan te ontsnappen met addslashes . Bekijk wat uw database ontvangt.

Dit is een reden waarom addslashes mag niet worden gebruikt om te ontsnappen.

Verschil #2

In tegenstelling tot addslashes , mysql_real_escape_string ontsnapt ook aan de tekens \r , \n , en \x1a . Het lijkt erop dat deze tekens ook moeten worden ontsnapt wanneer u met MySql praat, anders kan een verkeerd opgemaakte zoekopdracht het resultaat zijn

Dit is de andere reden waarom addslashes mag niet worden gebruikt om te ontsnappen.



  1. Hoe PHP te dwingen nieuwe regels te lezen en terug te keren als

  2. Cheatsheet voor PostgreSQL-configuratie

  3. Correcte manier om gebruikers toegang te geven tot aanvullende schema's in Oracle

  4. UTF-8 tekencodering gevechten json_encode()