urlencode() en + v.s. %20

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

- Ariën -
Beheerder

- Ariën -

10/04/2020 16:03:04
Quote Anchor link
Ik loop nu tegen iets vreemds aan.

Stel dat ik dit in mijn database heb staan. Let even op de spatie, oftewel de %20
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
<img alt="Whoei" src="/uploads/image/04112010457%20jajaja.jpg" style="width: 800px; height: 600px;">


Dan kan ik met deze query het record opzoeken:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
SELECT id, title FROM articles WHERE message LIKE '%/uploads/image/04112010457%20jajaja.jpg%'


Maar de bestandsnaam die ik opzoek is in werkelijkheid: "04112010457 jajaja.jpg"

Ik dacht dat ik hier urlencode() erover kon gooien, zodat ik uiteindelijk de %20 krijg. Maar ik krijg dan in plaats van de %20 een +? Waarom is dat? Hoe kan ik nou die %20 krijgen?

Toevoeging op 10/04/2020 16:25:09:

Update:
Opgelost met rawurlencode()

Alleen een beetje jammer dat je ook echt in de developer-tools van de browser moet kijken of het lukt. Want normaal zie je ook weer een spatie in de dialoogvensters als je de eigenschappen van bijv een ajax-request wilt zien. :-P

Maar gelukkig zoekt hij nu wel netjes naar de juiste string.
Gewijzigd op 10/04/2020 16:58:04 door - Ariën -
 
PHP hulp

PHP hulp

20/04/2024 15:16:20
 
Thomas van den Heuvel

Thomas van den Heuvel

10/04/2020 17:14:06
Quote Anchor link
Wanneer je het LIKE statement gebruikt hebben het procent-teken (%) en de underscore (_) een speciale betekenis.

Een % matcht 0 of meer karakters, een _ matcht precies één karakter.

Indien je een letterlijke % of _ wilt matchen zul je deze moeten escapen met een backslash (\).

Op elke plek waar je dit soort zoekfunctionaliteit gebruikt zou je jezelf ook moeten afvragen of je dit wilt toestaan of niet.

Ik neem aan dat je je zoekterm ook escaped met behulp van real_escape_string(). Deze doet echter niets met procenten en underscores. Misschien is het daarom handig om een shorthand te schrijven in je wrapperclass, als je die gebruikt, om te voorzien in deze optie, waarbij het default gedrag is dat deze nog steeds ongemoeid blijven. Dit is logisch gedrag, wat ook de beste backwards compatibiliteit geeft met bestaande functionaliteit.

Dus zoiets:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
8
9
<?php
public function escape($input, $escapeWildCards=false) {
    $input = $this->_connection->real_escape_string($input);
    if ($escapeWildCards) {
        $input = str_replace(array('_', '%'), array('\_', '\%'), $input);
    }
    return $input;
}
?>
 
- Ariën -
Beheerder

- Ariën -

10/04/2020 17:38:43
Quote Anchor link
Ja, ik escape het geheel wel, en ik zal eens kijken naar jouw code.

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
<?php
$sql= "UPDATE articles SET content = REPLACE(content, '/uploads/image/" . rawurlencode($db->escape_string($_GET['file'])) . "', '/uploads/image/original/" . $UploadStatus_array['filedata']['filename'] . ".jpg')";
?>

Voor spaties werkt dit prima. Maar blijkbaar is er ergens een verschil tussen het gebruik van een ë in de content, en het gebruik van rawurlencode.

Dit is wat er in de content staat:
/uploads/image/000%20Ari%C3%ABn%20test.jpg
(dus in werkelijkheid staat er: 000 Ariën test.jpg)

En dit is de rawurlencode() in de query:
LIKE '%/uploads/image/000%20Ari%EBn%20test.jpg%'

Waarom verschilt dit? De encoding uit de content komt overigens uit CKeditor, maar ergens verschilt dit met rawurlencode()? Dit lijkt mij los te staan van het gebruik van real_escape_string?

Hoe is dit te verklaren? Of is de de gebruikte encoding uit die editor verouderd?
Gewijzigd op 10/04/2020 17:49:50 door - Ariën -
 
Thomas van den Heuvel

Thomas van den Heuvel

10/04/2020 17:56:30
Quote Anchor link
EB is ISO-8859-1/latin1 encodering voor ë
C3AB is UTF-8/utf8 encodering voor ë

Ik zou trouwens escape_string() altijd als laatste gebruiken, en niet rawurlencode(), om er 100% zeker van te zijn dat rawurlencode() geen SQL-escaping ongedaan maakt, wat misschien voor veiligheidslekken kan zorgen.

Het escapen zou altijd de laatste operatie op input moeten zijn.
Gewijzigd op 10/04/2020 17:57:15 door Thomas van den Heuvel
 
- Ariën -
Beheerder

- Ariën -

10/04/2020 17:59:20
Quote Anchor link
Oké, ik kreeg al een vermoeden.
Ik ga nog even verder sleutelen...

Het lijkt dus dat Firefox die bestandsnaam via GET in UTF-8 encoding verstuurt.
Ook lekker handig, als dit echt zo is.... ;-)
Gewijzigd op 10/04/2020 18:03:03 door - Ariën -
 
Thomas van den Heuvel

Thomas van den Heuvel

10/04/2020 18:08:55
Quote Anchor link
NB misschien zijdelings gerelateerd: alles wat in $_GET staat wordt gedecodeerd met urldecode().

Je kunt altijd een beroep doen op bin2hex(). Dit toont je de hexadecimale waarden van de karakters, ongeacht de encodering. Je zou dus kunnen kijken hoe eea geencodeerd is in $_GET mbv strtoupper(bin2hex($_GET['file'])). Dit zodat je kunt nagaan hoe iets op byteniveau in elkaar steekt.

EDIT: hangt dit niet mede af van hoe je je charset instelt voor het HTML-document? Of de accept-charset in het zoekformulier? Lijkt mij handig om dit altijd expliciet in te stellen zodat een browser niet terugvalt op een afwijkende default als deze formulierinhoud voor jou encodeert (dus in feite alle formulieren met method="GET").
Gewijzigd op 10/04/2020 18:11:27 door Thomas van den Heuvel
 
- Ariën -
Beheerder

- Ariën -

10/04/2020 19:35:05
Quote Anchor link
Volgens mij lijkt urlencode() te kijken naar de encoding van je pagina.
Deze is nog ISO-8859-1, en via de snelle sandbox van 3v4l.org is het UTF-8...

Maar ik weet nu waar ik het moet zoeken. Ook die escape-functie zal ik toepassen.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.