[MySQL] Escape backslash werkt niet

[ajakkes]

Ik heb de volgende MySQL Tabel

id (primary key)	pad (varchar utf8_general_ci)
1	TEKST TEKST \ TEKST

Nu probeer ik op basis van het Pad de bijbehorende primary key te vinden, maar dit wil niet lukken. Van de volgende 3 query's werken de eerste 2 wel, maar de laatste niet. De Collatie wijzigen van utf8_general_si naar latin1_swedish_ci werkt ook niet. Het Database type is Inno_DB.

MySQL:

SELECT *  FROM `table` WHERE `pad` LIKE '% \\\\ %' #werkt
SELECT *  FROM `table` WHERE `pad` LIKE '%TEKST \\\\ %' #werkt
SELECT *  FROM `table` WHERE `pad` LIKE '%T TEKST \\\\ %' #werkt niet
SELECT *  FROM `table` WHERE `pad` LIKE '%T TEKST%' #werkt niet

Ik begrijp niet helemaal waarom ik de backslash moet Escapen met \\\\ ipv \\ en waarom de query mislukt wanneer er een 2e spatie in zit.

Heeft iemand een idee waarom dit mis gaat?

Via PHP en via phpMyAdmin geprobeerd
PHP Version 5.3.29
phpMyAdmin 4.1.9


EDIT:
Het lijkt er op dat juist de spatie mij de spreekwoordelijke das om doet. '%TEKST TEKST%' werkt ook niet.

[ Voor 8% gewijzigd door ajakkes op 26-05-2015 16:49 . Reden: verder onderzoek ]

[ajakkes]

*random krachtterm*

Oh, ja. Er staan   in mijn database ipv spaties.

Weet iemand hoe ik spaties vervang door het   character? En dan de utf8 variant en niet de html variant?

Er staat dus TEKST TEKST \ TEKST in mijn database en de zoekterm is TEKST TEKST \ TEKST. In de zoekterm moeten dus alle spaties vervangen door de non breaking space, maar hoe?

[NMe]

Geen HTML in je database mikken is geen optie? Je database is voor opslag, niet voor presentatie. Anders dan dat: REPLACE. Maar dan kun je geen indexen gebruiken. Niet dat je dat nu met je LIKE wel kan, overigens.

Waarom je moet escapen als \\\\ en niet als \\ is redelijk logisch natuurlijk. Je moet één keer escapen voor je clientsoftware (PHP?) en één keer voor MySQL.

[ajakkes]

Er staat geen HTML in mn database. Maar een speciale spatie ipv de standaard spatie.

HTML in de database was me wel opgevallen.

Cliënt hoeft toch niet escaped te worden? Zit reeds in de string.

[RobIII]

ajakkes schreef op dinsdag 26 mei 2015 @ 17:48:
Er staat geen HTML in mn database. Maar een speciale spatie ipv de standaard spatie.

Waar heeft die 'speciale spatie' die   (ofwel een character entity reference) is nog meer betekenis buiten HTML (nou ja, SGML) dan

[ Voor 25% gewijzigd door RobIII op 26-05-2015 17:58 ]

[NMe]

ajakkes schreef op dinsdag 26 mei 2015 @ 17:48:
Cliënt hoeft toch niet escaped te worden? Zit reeds in de string.

Cliënt hoeft sowieso niet escaped te worden. Jij bedoelt waarschijnlijk encoded waarbij je ë omzet naar ë en ook dat doe je nadat je het uit de database haalt, niet voordat je het erin zet. Hetzelfde met je  .

[.oisyn]

Ik heb het vermoeden dat jullie langs elkaar heen praten, waarbij NMe denkt dat het over het woord "cliënt" gaat, terwijl ajakkes het wellicht over NMe's opmerking over cliensoftware (en dus de extra escaping) heeft

[ajakkes]

Ik leg het niet goed uit blijkbaar. Er staat een utf8(A0) in mijn database. Dat valt niet op maar als ik zoek naar een stuk tekst met spaties ga ik niks vinden.

[NMe]

Waarom U+00A0 en niet gewoon U+0020?

.oisyn schreef op dinsdag 26 mei 2015 @ 18:57:
Ik heb het vermoeden dat jullie langs elkaar heen praten, waarbij NMe denkt dat het over het woord "cliënt" gaat, terwijl ajakkes het wellicht over NMe's opmerking over cliensoftware (en dus de extra escaping) heeft

Ah, zo kun je het inderdaad ook lezen... Maar in dat geval is dat gewoon een foute oplossing en precies de reden waarom het nu fout gaat. Encoden in de database in plaats van in de client betekent dat je nu door allerlei hoepels moet springen om iets simpels te kunnen doen zoals een search...

[Damic]

en waarom gebruik je mysqli_real_escape_string() niet?

[ajakkes]

Weet op dit moment niet waarom er allemaal U+00A0 in die kolom staan. (En geen enkele U+0020. Er was vast een reden. Nu kan ik de 00A0 in de database vervangen door 0020 en uitzoeken waar de 00A0 voor was en op die plek de 0020 weer vervangen door 00A0 of de zoekopdracht aanpassen naar replace(U+0020,U+00A0,$query), alleen weet ik niet exact hoe die replace er uit zou moeten zien.

[NMe]

Dan zoek je dat even uit?

Ik kan me trouwens geen goede reden bedenken waarom een stuk lopende tekst alleen maar non-breaking spaces bevat in plaats van gewone spaces.

[ Voor 74% gewijzigd door NMe op 26-05-2015 20:38 ]

[Antrax]

Damic schreef op dinsdag 26 mei 2015 @ 19:12:
en waarom gebruik je mysqli_real_escape_string() niet?

Iedereen is natuurlijk vrij om te bepalen welke methode hij of zij gebruikt maar het alom bekende advies in deze luid dat een PDO extensie toch meer te bieden heeft dan de mysqli extensie.

Just my two cents.

[NMe]

Het punt is dat hij geen van beiden gebruikt want dan zou hij geen problemen hebben gehad met \\\\.

[Antrax]

NMe schreef op dinsdag 26 mei 2015 @ 21:12:
Het punt is dat hij geen van beiden gebruikt want dan zou hij geen problemen hebben gehad met \\\\.

That was the point I was going for

[Damic]

Lol PDO is eignelijk gewoon een soort klass hetzelfde als phpbb doet met hun database dingen. Daar kun je ook gemakkelijk een klasse toevoegen zodoende dat je een extra soort db kunt aanspreken. Als ik zo verder lees is dat dan in software gegoten zodoende dat het sneller is maar nog steeds trager dan direct de db driver aan te roepen.

[NMe]

Jep. Op dezelfde manier waarop code schrijven in PHP trager is dan assembly gebruiken om je programma te schrijven.

[ajakkes]

Met de volgende Code heb ik het probleem kunnen oplossen.

PHP:

$pad = mysql_real_escape_string($pad);
$pad = str_replace("\x20", "\xA0",$pad);
$pad = str_replace('\\','\\\\',$pad);

Kwam er uiteindelijk achter dat in de database niet consequent met spaties en non breaking spaties was gewerkt en heb de database aangepast. Hopen dat ik verderop niets gesloopt heb.

Iedereen bedankt voor het meedenken.

[Damic]

Euhm als je die real escape gebruikt moet je normaal niet meer escapen

[ajakkes]

Ja, daar ging ik ook van uit. Maar zoals ik in de eerste post aan aan gaf bleek dat niet te kloppen, waardoor ik lange tijd naar het verkeerde probleem aan het zoeken was.

Wie weet waarom ik dubbel moet escapen mag het zeggen.

[ Voor 14% gewijzigd door ajakkes op 27-05-2015 10:02 ]

[NMe]

ajakkes schreef op woensdag 27 mei 2015 @ 10:01:
Ja, daar ging ik ook van uit. Maar zoals ik in de eerste post aan aan gaf bleek dat niet te kloppen, waardoor ik lange tijd naar het verkeerde probleem aan het zoeken was.

Wie weet waarom ik dubbel moet escapen mag het zeggen.

Oh, gaaf, een raadspelletje!

Ik zeg: magic quotes.

[ajakkes]

Nope

Het zit tussen server en database. Niet tussen cliënt en server.

[DexterDee]

NMe schreef op woensdag 27 mei 2015 @ 01:31:
Jep. Op dezelfde manier waarop code schrijven in PHP trager is dan assembly gebruiken om je programma te schrijven.

Het schrijven van code in PHP gaat ongetwijfeld véél sneller dan het schrijven in assembly, maar I get your point

[NMe]

ajakkes schreef op woensdag 27 mei 2015 @ 12:50:
Nope

Het zit tussen server en database. Niet tussen cliënt en server.

Met magic quotes zet je zonder het te weten zelf dubbele quotes in de database. Maar ik zal wat minder subtiel zijn: je geeft ons nul informatie. Hoe moeten wij dan raden wat jij fout doet?

[ajakkes]

Als ik wist waar ik moest zoeken had ik de info allang gegeven. Maar dank voor de verwijzing naar de mogelijkheid dat mijn database nog lelijker is dan ik dacht.

Gok wel dat dat de oorzaak is.