Chr(10) en chr(13) geven problemen

[Anoniem: 174744]

Allereerst, laat ik maar te beginnen met dat ik een probleem had, en dit gelukkig onderhand heb opgelost. Maar ik snap eerlijk gezegd zelf nog niet helemaal wat er aan de hand is.

Laat ik allereerst beginnen met dat ik een hele boel termen en definities in de database heb gegooid met de volgende (ingekorte) code:

code:

foreach($aFile as $sLine) {
    $aTab = explode("\t", $sLine);
    $term = addslashes($aTab[0]);
    $definitie = addslashes($aTab[1]);
    mysql_query("INSERT IGNORE INTO glossary (term, definitie) VALUES('$term', '$definitie' ) ");  
}

Invoer kwam uit een tekstbestand met op iedere regel een term en een bijbehorende definitie (onderling gescheiden door een tab).

Problemen ontstonden bij een javascript functie. Iedere keer als ik de $definitie uit de database meegaf als variabele, kreeg ik een unterminated string literal error. Als ik $term meegaf, kreeg ik deze error niet.

Dat probleem wist ik uiteindelijk op te lossen door een str_replace chr(13) en chr(10) toe te passen op $definitie.

Het volgende probleem was echter dat de mysql_query niet meer de goede resultaten gaf.

code:

mysql_query("SELECT * FROM tabel WHERE definitie LIKE '$term'");

Behalve als ik het volgende er weer vooraf aan toevoegde:

code:

$term .= chr(13);
$term .= chr(10);

(en ook echt op deze volgorde!)

Op deze manier werkt alles picobello.

Maar dan vraag ik me af... waarom is dit allemaal benodigd? Waar gaat het mis? Is er een omweg voor?

[ValHallASW]

Er gaan hier drie dingen (min of meer) mis. Dat zijn de dingen waar je even over na moet denken aangezien ze wellicht niet doen wat je dacht.

1. De import van tekstbestand naar database. Je bent hierbij vergeten de newline (\r\n = chr(13)chr(10)) aan het einde van elke regel weg te halen. Je database bevat bij de definities nu dus elke keer een newline!
Overigens gebruik je addslashes - daar zou je mysql_real_escape_string moeten gebruiken. Doen ongeveer hetzelfde (nl. SQL injectie voorkomen), maar de eerste doet het niet op de goede manier en is dus eigenlijk onveilig.

2. Je query. Je doet daar WHERE a LIKE "bla", wat (misschien op collation na, dat weet ik niet zeker) equivalent is aan WHERE a = "bla". Waarschijnlijk bedoel je een string die met "bla" begint (WHERE a LIKE "bla%") of een string waar bla in voorkomt (WHERE a LIKE "%bla%").

3. Je output naar javascript. Je vergeet hier te escapen! Je schrijft je code namelijk weg naar een javascript-string, maar daar moet je tekens als ' en newlines wel escapen! Dan krijg je namelijk gewoon een string met een newline erin, in plaats van code die stuk gaat.


Nu ik je verhaal nog een keer nalees - wat ik vertel is niet geheel consistent met je verhaal (nl. de

Dat probleem wist ik uiteindelijk op te lossen door een str_replace chr(13) en chr(10) toe te passen op $definitie.

). Bedoel je daar wellicht dat je dat doet met data nadat je die weer uit de database hebt gehaald?

[Anoniem: 174744]

[b][message=35675784,noline]
Nu ik je verhaal nog een keer nalees - wat ik vertel is niet geheel consistent met je verhaal.

Bedoel je daar wellicht dat je dat doet met data nadat je die weer uit de database hebt gehaald?

Inderdaad. Als ik de data raw meegeef aan de javascript functie, wat er als volgt uitziet overigens:

code:

while ($result = $query ->fetch_object()) {
    echo '<li onClick="fill(\''.$result->term.'\');">'.$result->term.'</li>';
}

(Het gaat natuurlijk om het onClick gedeelte) Dan werkt het één en ander niet helemaal correct. In de foutconsole is een JS foutmelding te vinden, namelijk unterminated string literal.

De oplossing is dan:

code:

while ($result = $query ->fetch_object()) {
    $jsterm = str_replace(chr(13), "", $result->term );
    $jsterm = str_replace(chr(10), "", $jsterm );
    echo '<li onClick="fill(\''.$jsterm.'\');">'.$result->term.'</li>';
}

Ergo: de chr(13) en chr(10) dienen verwijderd te worden alvorens ik de variabele die ik uit de database trek in de functie kan stoppen.

[drm]

Je feitelijke probleem is dat je geen output escaping op de term toepast. Het zou namelijk ook mis gaan als er single quotes, dubbele quotes, html characters, enz, in de term zouden staan. Dat is dus sowieso problematisch. Hiervoor zou je json_encode i.c.m. htmlspecialchars kunnen gebruiken.

De vraag of je dan nog wel newlines toe wilt staan staat hier eigenlijk los van.

[ Voor 5% gewijzigd door drm op 13-03-2011 12:47 ]