Het is al lang geleden dat ik hier wat gepost heb (5 jaar alweer) :-) Ik heb ongeveer net zo lang geleden een script gemaakt waar een gebruiker middels een HTML formuliertje zijn naam en emailadres in moet vullen. de $_POST waardes worden alleen door een trim() en mysql_real_escape_string() functie gehaald waarna ze weggeschreven worden in de MySQL database (als varchar). Allemaal vrij eenvoudig en werkt eigenlijk ook al jaren zonder problemen.

Van een gebruiker kreeg ik de vraag waarom er af en toe namen niet goed doorkomen. De naam word netjes ingevuld in het formulier maar wordt vervolgens als een punt (.) in de database weggeschreven.
In database zie ik inderdaad een aantal namen staan waar alleen een punt in staat en geen tekst. De gebruiker geeft ook aan dat het niet lukt om het te reproduceren en die ervaring heb ik inmiddels zelf ook.

Komt iemand dit bekend voor of misschien nog ideeen wat er mis zou kunnen zijn?

Alvast bedankt voor het meedenken
Misschien zou het met de character-encoding te maken hebben?
Kom anders eens met wat relevante code, misschien vinden we daar wat interessants.
Het HTML formuliertje:


<html><form method="post" action="index.php?adduser" enctype="multipart/form-data">
<table cellspacing="0" cellpadding"0">
<tr>
	<td><strong>New User</strong></td>
	<td><br /><br /></td>
</tr>
<tr>
	<td>Emailaddress</td>
	<td><input type="text" name="email"></td>
</tr>
<tr>
	<td>First name</td>
	<td><input type="text" name="firstname"></td>
</tr>
<tr>
	<td>Last name</td>
	<td><input type="text" name="lastname"></td>
</tr>
<tr>
	<td></td>
	<td><input type="submit" name="submit" value="submit"></td>
</tr>
</table>
</form>
</html>



En de PHP code die er achter zit:


<?php
if((isset($_POST['submit']) && trim($_POST['email']) != "" && trim($_POST['firstname']) != "") && trim($_POST['lastname']) != "")
{
	$email = mysql_real_escape_string(trim($_POST['email']));
	$firstname = mysql_real_escape_string(trim($_POST['firstname']));
	$lastname = mysql_real_escape_string(trim($_POST['lastname']));
	mysql_query("INSERT INTO user (firstname, lastname, emailaddress, password)
			VALUES ('".$firstname."','".$lastname."','".$email."','".$password."');")or die(mysql_error());
}
?>
k denk dat de combinatie trim en mysql_real_escape...() niet goed gaan bij sommige namen.
Waarom zou je ook iets willen trimmen als je het door de filter heen haalt?

De trim() was in dit geval als check ingebouwd om een leeg veld (met alleen een space er in) te herkennen als leeg veld en dus niet te accepteren. (else heb ik hierboven weggelaten).

Heb je een idee wat voor namen problemen kunnen geven met deze combinatie? Om te testen.

Rickert Bombaklats op 07/04/2015 21:20:01

Ik denk dat de combinatie trim en mysql_real_escape...() niet goed gaan bij sommige namen.


Lijkt mij stug.
Wat Aar zegt snijdt in zekere zin wel hout: zorg dat al je character encoderingen gelijkgeschakeld zijn, dan sluit je iig uit dat daar het probleem zit.
De gebruiker geeft ook aan dat het niet lukt om het te reproduceren en die ervaring heb ik inmiddels zelf ook.

Mja, dit zou de makkelijkste manier zijn: vraag de gebruiker wat deze heeft gedaan. Mocht dit niet (op grote schaal) meer voorkomen dan zou ik dit beschouwen als een incident, maar wel in het achterhoofd houden als dit opnieuw / vaker optreedt.

En het kan nooit kwaad om al je character encoderingen (HTML document, formulier, database-verbinding, database-tabel, database-inhoud) na te lopen.

Verder zijn punten toegestane invoer, dus in zekere zin gebeurt er niets verkeerds :).
Bedankt voor jullie reacties.

Is het dan uberhaupt mogelijk dat door 'afwijkende' character encodering complete namen op random momenten veranderen\wijzigen? De voorbeelden die ik meegekregen heb waren ook gewoon namen met de letters uit het alfabet (geen bijzondere tekens enzo). Bijvoorbeeld 'pietje puk', 'klaas vaak', etc. Niets spannends dus.

Ik kan het mij eerlijk gezegd niet voorstellen. Als ik de specifieke voorbeelden zelf opnieuw intyp (hoe vaak ook) gaan ze altijd goed. Als het een mismatch zou zijn zou het naar mijn mening altijd mis moeten gaan.

Mijn vermoeden gaat toch steeds meer uit naar dat de gebruiker het gewoon verkeerd heeft ingetypt \ geplakt \ of wat dan ook.

Reageren