php/mysql en karakters met een accent

[trinite_t]

Ik loop opeens tegen een raar probleem aan. Ik heb een simpel cms achtig systeem draaien. Vandaag kwam ik er opeens achter dat als ik karakters met accenten (zoals ë, é enz) gebruik in een query, hij van die kolom de data tot aan dat karakter in de database zet.Alles wat er na komt wordt als het ware weggegooid.

Voorbeeld:

code:

INSERT INTO news (titel, text) VALUES ('blablaébla', 'een heleboel tekst');

dan wordt er in de kolom text 'blabla' gezet, en 'een heleboel tekst' in het text veld. Maar waarom wordt de 'ébla' tekst weggegooid?

[Alex)]

Is de charset van je tables wel goed?

Ik adviseer je trouwens om 't te htmlspecialcharren, dan heb je ook geen problemen met ophalen en weergeven van die tekens naderhand. In andere charsets zien tekens er soms anders uit

blaébla = blaébla

[Toolskyn]

Alex) schreef op maandag 28 januari 2008 @ 20:59:
Is de charset van je tables wel goed?

Ik adviseer je trouwens om 't te htmlspecialcharren, dan heb je ook geen problemen met ophalen en weergeven van die tekens naderhand. In andere charsets zien tekens er soms anders uit

blaébla = blaébla

htmlspecialchar doet helemaal niets met é hoor, daarvoor moet je kijken naar htmlentities.

[Cartman!]

Ben ik het niet mee eens Alex), je moet je velden van je database in UTF8 zetten zodat je later altijd de entities nog kunt omzetten.

[trinite_t]

Als we even de bewuste tabel er bij pakken (uit phpmyadmin):

code:

CREATE TABLE `news` (
  `id` int(11) NOT NULL auto_increment,
  `title` varchar(50) character set utf8 NOT NULL,
  `text` text character set utf8 NOT NULL,
  PRIMARY KEY  (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=9 ;

Dus volgensmij is alles wel UTF8. Ik heb de collation ook al op UTF8_bin en UTF8_unicode_ci geprobeerd. Dat haalt ook niets uit. Het meest vreemde vind ik nog dat ik met phpmyadmin wel die accents in de database kan zetten.

[Ramon]

probeer eens

code:

INSERT INTO news (titel, text) VALUES (_utf8'blablaébla', 'een heleboel tekst');

[WOmBaT]

Als ik me niet vergis moet je voor je je query uitvoert nog het volgende doen:

code:

SET NAMES utf8

[ Voor 3% gewijzigd door WOmBaT op 29-01-2008 07:48 ]

[trinite_t]

Probleem gefixed! Ik heb nu bij de index.php pagina's het volgende meegegeven:

PHP:

header("Content-Type: text/html; charset=UTF-8");

Het probleem bleek dus niet in de database te zitten, maar in hetgeen dat de server niet met utf8 werkte.

[Voutloos]

trinite_t schreef op dinsdag 29 januari 2008 @ 07:54:
Het probleem bleek dus niet in de database te zitten, maar in hetgeen dat de server niet met utf8 werkte.

Nee, dat de user agent niet te horen krijgt hoe hij de binnenkomende sloot bitjes moet interpreteren.
Het eeuwige encoding probleem antwoord: Zonder encoding aanduiding kan je gewoon niet weten wat er in een string staat. Ergo moet ook op elke plek de encoding correct aangegeven worden.

Overigens zit é ook gewoon in latin 1, maar goed, werken met UTF8 kan weinig kwaad.

[André]

Move naar Programming

[trinite_t]

Voutloos schreef op dinsdag 29 januari 2008 @ 08:34:
[...]
Nee, dat de user agent niet te horen krijgt hoe hij de binnenkomende sloot bitjes moet interpreteren.
Het eeuwige encoding probleem antwoord: Zonder encoding aanduiding kan je gewoon niet weten wat er in een string staat. Ergo moet ook op elke plek de encoding correct aangegeven worden.

Je hebt helemaal gelijk. Nog een ding dat ik trouwens niet helemaal snap: Als ik de de text uit het post gedeelte met print_r() liet zien zag ik wel de hele string, terwijl in de query dus het tweede deel wegviel. Is er iemand die me kan uitleggen hoe ik dat moet plaatsen ten opzichte van een user agent die de verkeerde encoding gebruiktt ?

edit:
Ipv die header in php heb ik nu:
AddDefaultCharset UTF-8
in het .htaccess bestand gezet.

[ Voor 6% gewijzigd door trinite_t op 29-01-2008 09:47 ]

[FragFrog]

Cartman! schreef op maandag 28 januari 2008 @ 22:00:
Ben ik het niet mee eens Alex), je moet je velden van je database in UTF8 zetten zodat je later altijd de entities nog kunt omzetten.

Agreed, met mysql_real_escape_string kun je prima dit soort tekens in je DB gooien, van te voren al dit soort conversies gaan maken gaat je op den duur opbreken.

[Bosmonster]

Alex) schreef op maandag 28 januari 2008 @ 20:59:
Is de charset van je tables wel goed?

Ik adviseer je trouwens om 't te htmlspecialcharren, dan heb je ook geen problemen met ophalen en weergeven van die tekens naderhand. In andere charsets zien tekens er soms anders uit

blaébla = blaébla

Das ongeveer wel het stomste dat je kan doen. Je moet gewoon zorgen dat je databasecontent en je applicatie de juiste character encodings gebruiken (UTF8 bijvoorbeeld dus).

HTML-encoding is om bepaalde dingen in HTML goed weergegeven te krijgen, niet om dingen encoding problemen in je database te omzeilen.

[Bosmonster]

FragFrog schreef op dinsdag 29 januari 2008 @ 09:21:
[...]

Agreed, met mysql_real_escape_string kun je prima dit soort tekens in je DB gooien, van te voren al dit soort conversies gaan maken gaat je op den duur opbreken.

mysql_real_escape_string (degene die die functienaam heeft bedacht moeten ze ook afschieten overigens ) is volgens mij alleen tegen sql-injection, dus escaped dingen als quotes e.d. en geen vreemde tekens?

[Bosmonster]

edit: spastische dubbelklik..

[ Voor 93% gewijzigd door Bosmonster op 29-01-2008 10:55 ]

[Voutloos]

Bosmonster schreef op dinsdag 29 januari 2008 @ 10:55:
[...]
mysql_real_escape_string (degene die die functienaam heeft bedacht moeten ze ook afschieten overigens ) is volgens mij alleen tegen sql-injection, dus escaped dingen als quotes e.d. en geen vreemde tekens?

Volgens mij bedoelt hij ook dat je gewoon de echte input wil opslaan. En anders bedoel ik dat wel, want htmlentities ed. zijn pas relevant bij presentatie, en dan dus niet bij alle soorten van presentatie.

[Verwijderd]

Je hebt helemaal gelijk. Nog een ding dat ik trouwens niet helemaal snap: Als ik de de text uit het post gedeelte met print_r() liet zien zag ik wel de hele string, terwijl in de query dus het tweede deel wegviel. Is er iemand die me kan uitleggen hoe ik dat moet plaatsen ten opzichte van een user agent die de verkeerde encoding gebruikt?

De useragent gebruikt gewoon de encoding die jij hem opgeeft. En als je geen encoding opgeeft, zal de user agent de default character set/encoding van het OS gebruiken. In veel gevallen zal dat windows-1252 zijn (een 8-bit character set die grotendeels compatible is met iso-8859-1).
Bij het posten van formulierdata zal de browser ook die bewuste character set gebruiken.

De é staat in windows-1252 en iso-8859-1 op code point 233 en dat levert in beide character encodings 1 octet op waarin de drie hoogste bits gevuld zijn. De letter b levert in de genoemde character encodings een octet op waarin de hoogste bit niet gevuld is.

Een dergelijke sequence van octetten is ongeldig in utf-8. Wanneer in een utf-8 encoded string een octet voorkomt, waarin de drie hoogste bits gevuld zijn, hoort dit octet gevolgd te worden door twee andere octetten waarin de hoogste bit gevuld is. De string die je voert aan je utf-8 MySQL tabel, is dus niet correct utf-8 encoded. MySQL reageert hierop door simpelweg de string af te kappen bij de ongeldige sequence. Een harde error - zoals gebruikelijk is bij iedere zichzelf respecterende XML parser - zou mijns inziens beter zijn geweest.

De functie htmlentities() is crap. Wanneer je gebruik maakt van iso-8859-1 is het grotendeels onnodig. Karakters als é, ë. maken gewoon deel uit van deze character set en hoeven dus niet ge-escaped te worden met een entity reference. Daarnaast is het mogelijk dat de content die de browser verzendt, reeds ge-escaped is. Opera bijvoorbeeld verzendt in een iso-8859-1 pagina het euro teken als & #8364;. Als je daar nog eens htmlentities() overheen gooit, wordt het & amp;#8364;. Een laatste nadeel van htmlentities() is, dat de meeste entity references niet werken in XML.

Wanneer je gebruik maakt van utf-8, lijkt het me al helemaal zinloos. In utf-8 beschik je immers over het hele Unicode repertoire aan karakters, dus waarom zou
je dan karakters gaan escapen.

[FragFrog]

Bosmonster schreef op dinsdag 29 januari 2008 @ 10:55:
mysql_real_escape_string (degene die die functienaam heeft bedacht moeten ze ook afschieten overigens ) is volgens mij alleen tegen sql-injection, dus escaped dingen als quotes e.d. en geen vreemde tekens?

Jup, en da's ook precies de bedoeling Ik zie nogal eens dingen als htmlentities, eventueel met ENT_QOUTES, gebruikt worden om SQL injectie tegen te gaan, terwijl daar een veel beter alternatief voor is.

De enige reden voor htmlentities / htmlspecialchar is om ervoor te zorgen dat HTML tags zonder moeite op je site toonbaar zijn, voor het gebruik in AJAX calls en eventueel in emails. Als je het gaat gebruiken om vreemde tekens tegen te gaan of SQL injecties ermee probeert te voorkomen ben je in mijn opinie fout bezig

Voutloos schreef op dinsdag 29 januari 2008 @ 11:03:
Volgens mij bedoelt hij ook dat je gewoon de echte input wil opslaan. En anders bedoel ik dat wel, want htmlentities ed. zijn pas relevant bij presentatie, en dan dus niet bij alle soorten van presentatie.

Precies

[ Voor 16% gewijzigd door FragFrog op 29-01-2008 14:47 ]