String vergelijken in PHP

[TheNephilim]

Ik probeer een string te vergelijken in PHP en dat wil maar niet lukken...

Het resultaat van var_dump is het volgende:

code:

string(29) "Lorem ipsum & dolor sit amets"

code:

string(33) "Lorem ipsum & dolor sit amets"

Dus 29 voor de een en 33 voor de ander. Ik heb trim al gebruikt, html_entity_encode en ook mb_detect_encoding (strict) geeft aan dat beide UTF-8 zijn.

Die van 29 komt uit een API rollen en die van 33 uit mijn database. De database gebruikt de utf8mb4_unicode_ci encoding. Als hij in de database niet bestaat, dan sla ik hem op in de database. De eerstvolgende vergelijking met dezelfde waarde gaat echter niet.

Edit: die & is overduidelijk het probleem. Hij word in de database opgeslagen als &, maar dat moet gewoon een & zijn.

Wat kan ik hier nog proberen?

[ Voor 8% gewijzigd door RobIII op 13-07-2016 13:30 . Reden: Even correct escaped zodat & & & goed weergegeven wordt :P ]

[scosec]

Kun je hem niet hashen om te vergelijken?

[Haan]

Blijkbaar gaat er bij het opslaan in de database dan iets mis / werkt het anders dan je verwacht. Je bent neem ik aan wel bekend met dit verhaal?

[TheNephilim]

scosec schreef op woensdag 13 juli 2016 @ 13:01:
Kun je hem niet hashen om te vergelijken?

Nee dan zou het net zo niet gelijk zijn.

Haan schreef op woensdag 13 juli 2016 @ 13:10:
Blijkbaar gaat er bij het opslaan in de database dan iets mis / werkt het anders dan je verwacht. Je bent neem ik aan wel bekend met dit verhaal?

Nou ik ben geen specialist in encoding, zeker niet. Alleen daar lag het niet aan, gezien beide strings netjes UTF-8 zijn.

---

Inmiddels heb ik het probleem opgelost; zowel bij opslaan als vergelijken htmlspecialchars gebruiken. Dan gaat het in alle gevallen goed. Ik heb geen controle over hoe het word opgeslagen in de database, je zou denken dat gewoon "&" prima moet kunnen tegenwoordig, ipv. "&".

De enige string was "Lorem ipsum & dolor sit amets" en de andere "Lorem ipsum & dolor sit amets"

[ Voor 0% gewijzigd door RobIII op 13-07-2016 13:32 . Reden: Even correct escaped zodat & & & correct weergegeven wordt. ]

[Janoz]

Dat het als & in de database terecht komt is imho een behoorlijke bug in het deel waarover jij geen controle hebt.

[TheNephilim]

WordPress...

Als ik htmlspecialchars_decode gebruik en daarna met wp_insert_term een nieuwe taxonomy term aanmaak, dan staat er & in de database.

Dus de enige optie die ik heb is dan het tegenovergestelde, namelijk htmlspecialchars om alles op één lijn te krijgen.

[Ventieldopje]

code:

string(33) "Lorem ipsum & dolor sit amets"

En daarom altijd je debug output tussen <pre> tags. Dan worden speciale karakters die in html geschreven staan als & bijv. niet omgezet naar het teken (&) in de browser.

[Merethil]

Ventieldopje schreef op woensdag 13 juli 2016 @ 16:26:

code:

string(33) "Lorem ipsum & dolor sit amets"

En daarom altijd je debug output tussen <pre> tags. Dan worden speciale karakters die in html geschreven staan als & bijv. niet omgezet naar het teken (&) in de browser.

Errrrr, even getest in een .html-bestandje maar dat lijkt toch echt niet te werken. Tenzij ik iets over het hoofd zie en het niet

HTML:

<pre>&amp;</pre>

is?

Ook in JSFiddle is het niet zo: https://jsfiddle.net/674y30oL/

[ Voor 5% gewijzigd door Merethil op 13-07-2016 16:42 ]

[storeman]

Merethil schreef op woensdag 13 juli 2016 @ 16:41:
[...]


Errrrr, even getest in een .html-bestandje maar dat lijkt toch echt niet te werken. Tenzij ik iets over het hoofd zie en het niet

HTML:

<pre>&amp;</pre>

is?

Ook in JSFiddle is het niet zo: https://jsfiddle.net/674y30oL/

Slaat ook nergens op, pre heeft dat nooit gedaan en zal dat ook nooit doen. Daarom moet je het door htmlentities heen trekken in php, of gewoon de source bekijken...

[Ventieldopje]

Merethil schreef op woensdag 13 juli 2016 @ 16:41:
[...]


Errrrr, even getest in een .html-bestandje maar dat lijkt toch echt niet te werken. Tenzij ik iets over het hoofd zie en het niet

HTML:

<pre>&amp;</pre>

is?

Ook in JSFiddle is het niet zo: https://jsfiddle.net/674y30oL/

Ah right, stom dat hij dat alsnog omzet. In ieder geval is het wel aan te raden om <pre> tags te gebruiken (of iig een monospace font) om misverstanden tussen karakters te voorkomen.

In dit geval kom je er niet onder uit om inderdaad htmlentities te gebruiken.

[TheNephilim]

Ik wilde al zeggen, maar ook te lezen in de reacties; onderstaande gebruikte ik al in m'n test:

code:

<?php echo '<pre>'; var_dump($string); echo '</pre>';

Dat maakt inderdaad geen verschil, ook print_r niet.

Ventieldopje schreef op woensdag 13 juli 2016 @ 16:55:
[...]

In dit geval kom je er niet onder uit om inderdaad htmlentities te gebruiken.

Nee het lijkt er inderdaad op dat het gewoon niet anders is. Het werkt gelukkig op deze manier, al is het inderdaad niet geheel optimaal.

[DJMaze]

Jullie bedoelen

PHP:

header('Content-Type: text/plain');

Of anders gewoon "view source". Vertrouw nooit wat je ziet op een scherm in het geval van HTML.

[ Voor 41% gewijzigd door DJMaze op 14-07-2016 12:10 ]

[Krilo_89]

Je moet in ieder geval zorgen dat je alles opnieuw opslaat in je database en dan niet de speciale tekens omzetten. Wanneer je helemaal zelf bepaalt wat er de database in gaat, hoef je dat qua veiligheid sowieso niet om te zetten.

[Lye]

Krilo_89 schreef op vrijdag 15 juli 2016 @ 07:47:
Wanneer je helemaal zelf bepaalt wat er de database in gaat, hoef je dat qua veiligheid sowieso niet om te zetten.

Je zou dat per definitie niet om moeten zetten (Alleen waar nodig escapen, maar dat zou de database driver op moeten lossen).
In de database wil je je input hebben staan zoals ingevoerd. Stel dat je over een bepaalde tijd naast (bijvoorbeeld) HTML output ook PDF output wil, moet je al je entries opnieuw genereren. Of, nog erger, je wil je entry aanpassen. Dan moet je het eerst terug converteren naar het input formaat (en hopen dat dat 1-op-1 overeen komt) en na aanpassingen weer converteren naar het output formaat. Dat voelt al niet goed.

Dergelijke converteer functionaliteit is, in het MVC-model, onderdeel van de view-laag, niet de controller of het model. De view is verantwoordelijk voor het correct weergeven van de output.

Op het moment dat de input de veiligheid van de applicatie in gevaar brengt is er iets goed mis met de applicatie.

[NiHearts]

En als je de twee strings vergelijkt met Levenshtein ?

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

[Haan]

De Levenshtein distance gebruik je om te bepalen in hoeverre woorden op elkaar lijken, wat bijvoorbeeld handig is bij spellingscontrole om suggesties te kunnen doen voor woorden die er op lijken. Dat is hier niet van toepassing. Daarbij is het vergeleken met gewoon equals een zware functie, die kwadratisch toeneemt met de lengte van een string, dus ook niet praktisch om op complete zinnen los te laten.