Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

[PHP/MySQL5] UTF-8 probleempje

Pagina: 1
Acties:

  • P.O. Box
  • Registratie: Augustus 2005
  • Niet online
ik heb een voor mij vreemd "probleempje"... heb een tabel met als charset: utf8, collation: utf8_unicode_ci (de velden erven de "table charset", maar heb ook geprobeerd het veld een eigen charset te geven).

normaal gesproken doe ik altijd (misschien beetje dubbelop, maar als ik 1 van de 2 weghaal is mijn probleem niet opgelost):
PHP:
1
2
3
$db = new mysqli(....);
$db->query("SET NAMES utf8");
$db->set_charset('utf8');


dit heeft eigenlijk nog nooit problemen gegeven.

Nu wil ik in de tabel een stuk tekst wegschrijven waarin het woord "Qualität" staat.

PHP:
1
2
3
4
$strSQL  = sprintf("INSERT INTO mijntabel SET " );
$strSQL .= sprintf("mijntekst = '%1\$s' ", $db->real_escape_string($mijntekst));
$strSQL .= sprintf("WHERE id = 1 ");
$db->query($strSQL);


in mijn database komt nu het volgende in "mijntabel" te staan: Qualit

dus hij kapt de string af.
Heb de $strSQL geprint en zie dat de query wel de volledige tekst bevat.

Als ik de utf8-zooi uitslash:
PHP:
1
2
//  $db->query("SET NAMES utf8");
//  $db->set_charset('utf8');


dan wordt de data wel goed in de database weggeschreven.

dan zou je zeggen: laat die utf-8 zooi dan weg uit je code !... dat kan natuurlijk... maar ik wil begrijpen waarom dit fout gaat... want ik gebruik die utf-8-php/mysql-code eigenlijk altijd al zo (probleemloos) en wil wel graag weten wat ik nu precies verkeerd doe om dat in het vervolg niet weer te doen...

iemand enig idee hoe ik er achter kan komen waarom het verkeerd gaat?

phpversie: 5.3.9
mysql versie: 5.5.10

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Is je invoer wel utf-8? Of is het simpelweg ISO-8859-... en probeer je dat te proppen in een utf-8 verbinding / database?

Alles moet utf-8 zijn, van het begin tot eind.

  • P.O. Box
  • Registratie: Augustus 2005
  • Niet online
dat is het !!! de invoer komt uit een webservice... en die is ISO-8859-1 zie ik nu...
stom van me ! thanks !

kun je dan uren op staren he ;)

[ Voor 13% gewijzigd door P.O. Box op 08-11-2013 10:37 ]


  • Barryvdh
  • Registratie: Juni 2003
  • Laatst online: 21-11 14:12
Misschien wel nog even kijken naar prepared statements, in plaats van zo je query builden?

  • P.O. Box
  • Registratie: Augustus 2005
  • Niet online
want? prepared statements zijn toch origineel bedoeld om dezelfde query meerdere keren achter elkaar uit te voeren met andere data?

  • Barryvdh
  • Registratie: Juni 2003
  • Laatst online: 21-11 14:12
Nouja het wordt over het algemeen wel aangeraden om het veiliger is, omdat je niet zelf je variabelen hoeft te escapen (en dus ook niet kan vergeten een keertje).
Maargoed, ik gebruik persoonlijk ook liever PDO dan mysqli, want dat lijkt (van wat ik overal zo zie) wel de geprefereerde manier.

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 20-11 11:59

NMe

Quia Ego Sic Dico.

P.O. Box schreef op vrijdag 08 november 2013 @ 10:19:
normaal gesproken doe ik altijd (misschien beetje dubbelop, maar als ik 1 van de 2 weghaal is mijn probleem niet opgelost):
PHP:
1
2
3
$db = new mysqli(....);
$db->query("SET NAMES utf8");
$db->set_charset('utf8');
Dat is niet "misschien" een beetje dubbelop, dat is gewoon dubbellop. Die SET NAMES-query wil je gewoon weglaten. De set_charset-method doet die query namelijk ook maar zorgt daarnaast ook dat de escapefuncties charset-aware zijn. Die kun je dus niet echt weglaten, de andere wel.

Verder natuurlijk: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) ;)
P.O. Box schreef op vrijdag 08 november 2013 @ 11:59:
want? prepared statements zijn toch origineel bedoeld om dezelfde query meerdere keren achter elkaar uit te voeren met andere data?
Dat ze daar origineel voor bedoeld zijn wil niet zeggen dat ze niet meer voordelen met zich meebrengen natuurlijk. En aangezien je toch al sprintf gebruikt ga je weinig verschil zien in je code.

[ Voor 20% gewijzigd door NMe op 08-11-2013 12:32 ]

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • P.O. Box
  • Registratie: Augustus 2005
  • Niet online
NMe schreef op vrijdag 08 november 2013 @ 12:31:
[...]


Dat ze daar origineel voor bedoeld zijn wil niet zeggen dat ze niet meer voordelen met zich meebrengen natuurlijk. En aangezien je toch al sprintf gebruikt ga je weinig verschil zien in je code.
maar wat zijn die voordelen? en wat is er veiliger dan real_escape-en?

  • NMe
  • Registratie: Februari 2004
  • Laatst online: 20-11 11:59

NMe

Quia Ego Sic Dico.

P.O. Box schreef op vrijdag 08 november 2013 @ 12:40:
[...]

maar wat zijn die voordelen? en wat is er veiliger dan real_escape-en?
Het feit dat je het nu kan vergeten en dat met prepared statements onmogelijk is. Nog los van het feit dat je code compacter wordt omdat je niet én sprintf én voor elke variabele een real_escape_string-call hoeft te doen.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.


  • HuHu
  • Registratie: Maart 2005
  • Niet online
Hoe kom je aan $mijntekst? Weet je zeker dat daar de correcte invoer in staat, want misschien zit het probleem al eerder? Bijvoorbeeld op de plaats waar je invoer in $mijntekst stopt.

  • drm
  • Registratie: Februari 2001
  • Laatst online: 09-06 13:31

drm

f0pc0dert

Vergeet niet naast je verbinding ook je kolomspecificaties op de juiste charset en collation in te stellen. http://dev.mysql.com/doc/refman/5.5/en/charset-column.html

Music is the pleasure the human mind experiences from counting without being aware that it is counting
~ Gottfried Leibniz

Pagina: 1