[PHP/MySQL/SOAP] UTF-8 encoding

[Tjolk]

Ik heb een SOAP welke via PHP connect met een MySQL database, daar gegevens uithaalt en teruggeeft. "Vroegah" was het allemaal ISO-8859-1 geëncode. In een project waarbij ik allerlei tabellen heb genormaliseerd, het interne "CMS" hierop heb aangepast en de SOAP server ook, heb ik alles omgezet naar UTF-8 omdat we steeds tegen problemen aanliepen met o.a. eurotekens en imports van externen die ook in UTF-8 aangeleverd worden.

Ik heb nu deze tabel:

SQL:

delimiter $$

CREATE TABLE `data_article` (
  `article_id` int(11) NOT NULL auto_increment,
  `title_shop` varchar(60) default NULL,
  `title_internal` varchar(70) default NULL,
[...]
  `date_created` datetime NOT NULL default '1000-01-01 00:00:00',
  `date_modified` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
  PRIMARY KEY  (`article_id`),
  UNIQUE KEY `FAN_UNIQUE` (`fan`),
  UNIQUE KEY `barcode_UNIQUE` (`barcode`),
  KEY `department_id` (`department_id`),
  KEY `subcat_id` (`subcat_id`)
) ENGINE=InnoDB AUTO_INCREMENT=80606 DEFAULT CHARSET=utf8$$

Het veld `title_shop` kan een euro-teken ( € ) bevatten als het om een cadeaubon o.i.d. gaat. In de database (bekeken met MySQL Workbench) zie ik deze ook netjes als zodanig staan en dat is m.i. ook logisch aangezien de charset UTF8 is en de kolom (alle kolommen) als collation de table default hebben.

Als ik het artikel open binnen het CMS, dan zie ik het ook netjes in de database staan. Als ik het opvraag via SOAP krijg ik echter deze error:

code:

 \x80...' is not a valid utf-8 string

Ik start de SOAP server met deze code:

PHP:

$server = new SoapServer(WSDL_URL, array('encoding'=>'UTF-8', 'features' => SOAP_SINGLE_ELEMENT_ARRAYS));

En de WSDL heb ik ook zodanig gedefinieerd:

XML:

<?xml version="1.0" encoding="utf-8"?>

Toch krijg ik alsnog de melding dat ik geen valide UTF-8 uitspuug. Het stomme is: zodra ik de SoapServer als ISO-8859-1 opstart, dan krijg ik geen foutmelding (echter: dan ontbreekt het euroteken ook en wordt het een blokje.)

Van voor tot achter lijkt het me allemaal netjes UTF-8 te zijn, maar blijkbaar zie ik ergens iets over het hoofd. Iemand die mij aan een geniale ingeving kan helpen?

[mbarie]

Pin me er niet op vast, maar dat komt volgens mij omdat het gebruikte teken niet binnen de XML voor mag komen, niet omdat het geen UTF-8 is.

Volgens mij los je dit op door de content van het XML element in <![CDATA[ ... ]]> te zetten.

[ Voor 4% gewijzigd door mbarie op 30-10-2014 10:56 ]

[Ultimation]

Waarom wil je dat soort tekens opslaan in de database? Daar hebben we gewoon htmlentities voor?

[PrisonerOfPain]

Ultimation schreef op donderdag 30 oktober 2014 @ 10:55:
Waarom wil je dat soort tekens opslaan in de database? Daar hebben we gewoon htmlentities voor?

Nee.

[Ultimation]

PrisonerOfPain schreef op donderdag 30 oktober 2014 @ 11:07:
[...]


Nee.

Goede opbouwende kritiek. Heel leerzaam.

[PrisonerOfPain]

Ger, een aantal mensen op internet zeggen succes te hebben met utf8_encode over bepaalde elementen van de data heen te halen maar dat zou inhouden dat je data alsnog ISO-8859-1 is ergens. Je zou het kunnen gebruiken om uit te vinden waar je data verkeerd gaat

Ultimation schreef op donderdag 30 oktober 2014 @ 11:16:
[...]


Goede opbouwende kritiek. Heel leerzaam.

Ok prima, nee je zet je data niet pre-encoded in je tabel tenzij je dat nodig hebt om performance redenen (en dan sla je het dubbel op). Je source materiaal wil je zo "clean" mogelijk opslaan in de database. Verder is het natuurlijk een houtje-touwtje oplossing voor een probleem dat wel degelijk een fatsoenlijke oplossing zou moeten hebben.

[ Voor 5% gewijzigd door PrisonerOfPain op 30-10-2014 11:23 ]

[Cloud]

Htmlentities is fijn als je userinput hebt die direct weergegeven wordt, comments, profielen enzo. Dat is inderdaad veilig.

Maar voor niet-userinput kun je prima UTF-8 in je DB hebben staan natuurlijk, daar wil je niet standaard htmlentities hebben. Dat is wel heel beperkend Je kunt altijd pre-weergave nog de entites omzetten als je dat fijn vindt maar data wil je puur houden.

---

@TS
Je verschillende elementen lijken inderdaad wel UTF-8 ready te zijn. Kan het zijn dat er op een tussenliggende stap, bij het ophalen van data en als invoer gebruiken voor je Soap response, ergens iets gebeurt wat niet goed omgaat met UTF-8?

[Joolee]

Ger schreef op donderdag 30 oktober 2014 @ 10:48:
Ik heb een SOAP welke via PHP connect met een MySQL database, daar gegevens uithaalt en teruggeeft. "Vroegah" was het allemaal ISO-8859-1 geëncode. In een project waarbij ik allerlei tabellen heb genormaliseerd, het interne "CMS" hierop heb aangepast en de SOAP server ook, heb ik alles omgezet naar UTF-8 omdat we steeds tegen problemen aanliepen met o.a. eurotekens en imports van externen die ook in UTF-8 aangeleverd worden.

Ik heb nu deze tabel:

SQL:

delimiter $$

CREATE TABLE `data_article` (
  `article_id` int(11) NOT NULL auto_increment,
  `title_shop` varchar(60) default NULL,
  `title_internal` varchar(70) default NULL,
[...]
  `date_created` datetime NOT NULL default '1000-01-01 00:00:00',
  `date_modified` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
  PRIMARY KEY  (`article_id`),
  UNIQUE KEY `FAN_UNIQUE` (`fan`),
  UNIQUE KEY `barcode_UNIQUE` (`barcode`),
  KEY `department_id` (`department_id`),
  KEY `subcat_id` (`subcat_id`)
) ENGINE=InnoDB AUTO_INCREMENT=80606 DEFAULT CHARSET=utf8$$

Het veld `title_shop` kan een euro-teken ( € ) bevatten als het om een cadeaubon o.i.d. gaat. In de database (bekeken met MySQL Workbench) zie ik deze ook netjes als zodanig staan en dat is m.i. ook logisch aangezien de charset UTF8 is en de kolom (alle kolommen) als collation de table default hebben.

Als ik het artikel open binnen het CMS, dan zie ik het ook netjes in de database staan. Als ik het opvraag via SOAP krijg ik echter deze error:

code:

 \x80...' is not a valid utf-8 string

Ik start de SOAP server met deze code:

PHP:

$server = new SoapServer(WSDL_URL, array('encoding'=>'UTF-8', 'features' => SOAP_SINGLE_ELEMENT_ARRAYS));

En de WSDL heb ik ook zodanig gedefinieerd:

XML:

<?xml version="1.0" encoding="utf-8"?>

Toch krijg ik alsnog de melding dat ik geen valide UTF-8 uitspuug. Het stomme is: zodra ik de SoapServer als ISO-8859-1 opstart, dan krijg ik geen foutmelding (echter: dan ontbreekt het euroteken ook en wordt het een blokje.)

Van voor tot achter lijkt het me allemaal netjes UTF-8 te zijn, maar blijkbaar zie ik ergens iets over het hoofd. Iemand die mij aan een geniale ingeving kan helpen?

Je moet de encoding door de hele lijn doorvoeren:
HTTP headers (goede kans dat het hier mis gaat), SQL client character set, multibyte php functions, HTTP headers van je SOAP client response, HTML meta tag van je SOAP client response.
Handig is om ook alle php bestanden als UTF-8 zonder BOM op te slaan. Niet echt nodig, maar wel handig als je speciale tekens in je comments of hard-coded strings wilt gebruiken.

[Tjolk]

Zowel de CDATA oplossing als de htmlentities oplossing heb ik aan gedacht, maar dat vond ik inderdaad zoals PrisonerOfPain zegt een houtje-touwtje oplossing. Immers: volgens mij is het gewoon valide UTF8.

Cloud schreef op donderdag 30 oktober 2014 @ 11:22:
Je verschillende elementen lijken inderdaad wel UTF-8 ready te zijn. Kan het zijn dat er op een tussenliggende stap, bij het ophalen van data en als invoer gebruiken voor je Soap response, ergens iets gebeurt wat niet goed omgaat met UTF-8?

Zou kunnen. Iets meer detail:
Vanuit mijn SOAP class start ik een DB class. Die connect als volgt:

PHP:

$this->mysqli = new mysqli(DB_HOST, DB_USERNAME, DB_PASSWORD, DB_DATABASE);

Vervolgens loop ik door wat parameters en die zet ik ook door naar de DB class:

PHP:

$packet_content = $this->db->get_packet_content($packet_params);

Die $packet_params doen wat dingen in de WHERE e.d.
De DB doet vervolgens dit:

PHP:

$result = $this->query($sql);

En dan:

PHP:

        while ($row = $result->fetch_object())
        {
            // Voorraad check, levertijd, etc; even geknipt tbv overzicht - Doet niets met betreffende veld
            $return[] = $row;
        }
        return $return;

De query method is heel simpel:

PHP:

    private function query($sql)
    {
        if (DEVELOPMENT)
        {
            $this->querys[] = $sql;
        }
        return $this->mysqli->query($sql);
    }

Vervolgens:

PHP:

$return = new stdClass();
$return->status = TRUE;
$return->products = $packet_content;
return $return;

Dat zijn allemaal logische, simpele stappen naar mijn idee. En belangrijker: ik zie niet waarom dit iets met de encoding zou doen.

[Woy]

Cloud schreef op donderdag 30 oktober 2014 @ 11:22:
Htmlentities is fijn als je userinput hebt die direct weergegeven wordt, comments, profielen enzo. Dat is inderdaad veilig.

Zelfs daar eigenlijk niet, want stel je maakt straks ook een App die niet op HTML gebasseerd is, dan moet je alle data eerst weer gaan converteren. Gewoon de brondata zo puur mogelijk opslaan, en pas op het moment van presenteren converteren naar het juiste formaat is het best.

Natuurlijk zijn er altijd redenen om daar vanaf te wijken, maar een encoding fout ergens is daar IMHO geen reden voor.

[Joolee]

Ger schreef op donderdag 30 oktober 2014 @ 11:40:
Zowel de CDATA oplossing als de htmlentities oplossing heb ik aan gedacht, maar dat vond ik inderdaad zoals PrisonerOfPain zegt een houtje-touwtje oplossing. Immers: volgens mij is het gewoon valide UTF8.


[...]

Zou kunnen. Iets meer detail:
Vanuit mijn SOAP class start ik een DB class. Die connect als volgt:

PHP:

$this->mysqli = new mysqli(DB_HOST, DB_USERNAME, DB_PASSWORD, DB_DATABASE);

[..]

Dat is alvast stap 2:

PHP:

$this->mysqli->set_charset("utf8")

[Cloud]

Woy schreef op donderdag 30 oktober 2014 @ 11:41:
[...]

Zelfs daar eigenlijk niet, want stel je maakt straks ook een App die niet op HTML gebasseerd is, dan moet je alle data eerst weer gaan converteren. Gewoon de brondata zo puur mogelijk opslaan, en pas op het moment van presenteren converteren naar het juiste formaat is het best.

Ik bracht het misschien niet helemaal duidelijk maar dat was inderdaad wat ik bedoelde

[Saven]

het heeft iets met die mb_* functions te maken die je moet gebruiken maar weet niet precies hoe dat zit. ooit eens mee gegoochelt en het werkt, maar waarom geen idee

[Joolee]

Saven schreef op donderdag 30 oktober 2014 @ 11:44:
het heeft iets met die mb_* functions te maken die je moet gebruiken maar weet niet precies hoe dat zit. ooit eens mee gegoochelt en het werkt, maar waarom geen idee

Niet alleen voor jouw, belangrijk leesvoer voor iederreen:
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

[Tjolk]

Joolee schreef op donderdag 30 oktober 2014 @ 11:42:
[...]

Dat is alvast stap 2:

PHP:

$this->mysqli->set_charset("utf8")

10 punten, dat was 'm!

De database in kwestie heeft nog de collation latin1. Dat zit 'm in de historie en niet alle tabellen zijn al correct omgezet naar UTF-8.

* Tjolk is very happy

[Tjolk]

Joolee schreef op donderdag 30 oktober 2014 @ 11:46:
[...]

Niet alleen voor jouw, belangrijk leesvoer voor iederreen:
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Thanks!

[ValHallASW]

Ger schreef op donderdag 30 oktober 2014 @ 11:59:
[...]
De database in kwestie heeft nog de collation latin1. Dat zit 'm in de historie en niet alle tabellen zijn al correct omgezet naar UTF-8.

Dat maakt niet uit, want mysql snapt dat. Wat er fout ging door het weglaten van

Joolee schreef op donderdag 30 oktober 2014 @ 11:42:
[...]

PHP:

$this->mysqli->set_charset("utf8")

is dat de communicatie tussen mysql en php niet in utf-8 maar in wat mysql 'latin-1' noemt (maar wat eigenlijk windows-1252 is) gebeurt (immers: mysql en php praten met elkaar in bytes, niet in karakters). En in windows-1252 wordt het euroteken gerepresenteerd met:

Python:

>>> u"€".encode('windows-1252')
'\x80'

Vervolgens doet php er niets meer mee behalve die bytes letterlijk in de XML plakken (php kent het concept 'karakter' niet en werkt alleen met bytes). Als je die XML vervolgens inleest staat daar nog steeds die '\x80' byte, die je terugziet in

Ger schreef op donderdag 30 oktober 2014 @ 10:48:
Als ik het artikel open binnen het CMS, dan zie ik het ook netjes in de database staan. Als ik het opvraag via SOAP krijg ik echter deze error:

code:

 \x80...' is not a valid utf-8 string

Als je vervolgens met

Toch krijg ik alsnog de melding dat ik geen valide UTF-8 uitspuug. Het stomme is: zodra ik de SoapServer als ISO-8859-1 opstart, dan krijg ik geen foutmelding (echter: dan ontbreekt het euroteken ook en wordt het een blokje.)

de rest van je XML als (echt) latin-1 encoded, dan staat er nog steeds een '\x80' in... wat in latin-1 een control character is en geen euroteken. Vandaar het blokje.

On a sidenote: je wilt geen utf8 gebruiken in mysql, maar utf8x. Anders ga je alsnog de mist in met bv. 𨭎, 𠬠, en 𩷶, die buiten het 'Basic Multilingual Plane' liggen.

[ Voor 21% gewijzigd door ValHallASW op 30-10-2014 12:14 ]

[Saven]

ValHallASW schreef op donderdag 30 oktober 2014 @ 12:06:
On a sidenote: je wilt geen utf8 gebruiken in mysql, maar utf8x. Anders ga je alsnog de mist in met bv. 𨭎, 𠬠, en 𩷶, die buiten het 'Basic Multilingual Plane' liggen.

Hmm, ik zie in phpmyadmin alleen utf8 en utf8mb4, is dat utf8x? En welke charset moet ik dan nemen voor kolommen? In utf8 was dat utf8_general

[ Voor 50% gewijzigd door Saven op 30-10-2014 13:55 ]

[ValHallASW]

Saven schreef op donderdag 30 oktober 2014 @ 13:55:

Hmm, ik zie in phpmyadmin alleen utf8 en utf8mb4, is dat utf8x? En welke charset moet ik dan nemen voor kolommen? In utf8 was dat utf8_general

Sorry, utf8mb4 inderdaad. Ik was even in de war met LaTeX :-p utf8mb4 ís de charset, maar als collation zou je dan utf8mb4_general moeten kunnen gebruiken.

zie ook: https://dev.mysql.com/doc...charset-unicode-sets.html

[Tjolk]

The utf8mb4, utf16, and utf32 character sets were added in MySQL 5.5.3

Dat gaat hem nog even niet worden voor mij. Al staat een upgrade naar een nieuwe server met MySQL 5.5 wel op de planning overigens, maar dat duurt nog ff.

Nu is het wel zo dat we eigenlijk niet zulke exotische tekens gebruiken; we zouden dan bijvoorbeeld ook profi-vertalers in dienst moeten nemen om dergelijke teksten te schrijven. We zijn net begonnen met support voor Engels. Voorlopig hou ik het dus maar ff bij standaard utf8 - default collation.

Anyhow: bedankt voor alle nuttige input.

[ Voor 4% gewijzigd door Tjolk op 30-10-2014 16:24 ]

[Saven]

ValHallASW schreef op donderdag 30 oktober 2014 @ 14:24:
[...]

Sorry, utf8mb4 inderdaad. Ik was even in de war met LaTeX :-p utf8mb4 ís de charset, maar als collation zou je dan utf8mb4_general moeten kunnen gebruiken.

zie ook: https://dev.mysql.com/doc...charset-unicode-sets.html

Hehe thnx Even lichtelijk offtopic: moet je dan de php mb_* functions gebruiken? (dus mb_strlen etc ipv strlen) of is dat niet nodig? daar kwam ik niet helemaal uit..

[ValHallASW]

Saven schreef op donderdag 30 oktober 2014 @ 16:23:
Hehe thnx Even lichtelijk offtopic: moet je dan de php mb_* functions gebruiken? (dus mb_strlen etc ipv strlen) of is dat niet nodig? daar kwam ik niet helemaal uit..

Dat hangt er vanaf wat je wilt doen. As noted: php 'strings' zijn arrays van bytes. De gewone functies tellen het aantal bytes (of replacen een reeks van bytes met een reeks andere bytes). De mb_* functies interpreteren eerst de arrays met een bepaalde charset en bewerken ze vervolgens als een lijst van karakters.

Specifiek voorbeeld: Stel, je hebt de volgende php-code, in een utf-8-encoded bestand:

PHP:

$woord = "überhaupt";

dan staat er op de schijf:

code:

00000000  24 77 6f 6f 72 64 20 3d  20 22 c3 bc 62 65 72 68  |$woord = "..berh|
00000010  61 75 70 74 22 3b 0a                              |aupt";.|
00000017

wat wil zeggen dat je 'string' de bytes c3 bc 62 65 72 68 61 75 70 74 bevat. Als je dan strlen() gebruikt, dan vertelt php je dat 'ie 10 bytes telt. mb_strlen ($woord, 'utf-8') interpreteert het weer als utf-8, telt 9 code points (want "ü" is één code point¹).

Maar: je moet wel de goede encoding meegeven aan mb_strlen! Als je namelijk mb_strlen ($woord, 'latin-1') gebruikt, dan worden die bytes geinterpreteerd als 'überhaupt', en dat bestaat weer uit 10 code points.

Als je géén encoding meegeeft dan hoop je maar dat mb_internal_encoding toevallig goed ingesteld is, en dan verdien je een schop onder je kont.

¹ unicode normalization daargelaten

[Saven]

Stel mijn hele db is ingericht op utf8mb4. Ik haal uit de database allerlei titels, daar loop ik doorheen met een foreach..

PHP:

header('charset: utf-8');

$titels = $db->fetch(); //......... db is overal utf8mb4

foreach( $titels as $titel )
{
    $titel = mb_str_replace('ü', 'u', $titel);
    $titel = mb_str_replace('ê', 'e', $titel);
    $titel = mb_str_replace('ç', 'c', $titel);
   ///.... etc. bijv. alle rare tekens vervangen naar hun 'gewone' gelijkenis

    echo $titel."\r\n";
}

Ik weet niet wanneer een string een ü bevat en wanneer niet. Dus moet ik dan altijd die mb_ functie gebruiken als database in utf8mb4 is ingericht? En moet ik dan wel gewoon voor de browser charset utf-8 gebruiken?

[Joolee]

Saven schreef op vrijdag 31 oktober 2014 @ 15:04:
Stel mijn hele db is ingericht op utf8mb4. Ik haal uit de database allerlei titels, daar loop ik doorheen met een foreach..

PHP:

header('charset: utf-8');

$titels = $db->fetch(); //......... db is overal utf8mb4

foreach( $titels as $titel )
{
    $titel = mb_str_replace('ü', 'u', $titel);
    $titel = mb_str_replace('ê', 'e', $titel);
    $titel = mb_str_replace('ç', 'c', $titel);
   ///.... etc. bijv. alle rare tekens vervangen naar hun 'gewone' gelijkenis

    echo $titel."\r\n";
}

Ik weet niet wanneer een string een ü bevat en wanneer niet. Dus moet ik dan altijd die mb_ functie gebruiken als database in utf8mb4 is ingericht? En moet ik dan wel gewoon voor de browser charset utf-8 gebruiken?

Dit lijkt mij niet een erg praktische benadering. Probeer eens iets als: http://php.net/manual/en/function.iconv.php

[ValHallASW]

Saven schreef op vrijdag 31 oktober 2014 @ 15:04:
Ik weet niet wanneer een string een ü bevat en wanneer niet. Dus moet ik dan altijd die mb_ functie gebruiken als database in utf8mb4 is ingericht? En moet ik dan wel gewoon voor de browser charset utf-8 gebruiken?

Stop. Er zijn geen shortcuts. Je moet stap voor stap nagaan: wat wordt er opgeslagen (bytes of karakters? als bytes, welke encoding dan, en waarom? of worden de bytes als binary data gezien?), wat wordt er doorgegeven (bytes of karakters? als bytes, welke encoding dan, en waarom? of worden de bytes als binary data gezien?) en wat wordt er weer weggestuurd (bytes of karakters? als bytes, welke encoding dan, en waarom? of worden de bytes als binary data gezien?)

Doe dat, stap voor stap, voor de volgende zaken:
1) wat wordt er opgeslagen in de database? bytes of karakters? als bytes, welke encoding dan, en waarom? of worden de bytes als binary data gezien?
2) hoe wordt dat vervolgens gecommuniceerd tussen mysql en php? bytes of karakters? als bytes, welke encoding dan, en waarom? of worden de bytes als binary data gezien?
3) hoe leest php je php-bestand in? bytes of karakters? als bytes, welke encoding dan, en waarom? of worden de bytes als binary data gezien?
4) wat stuur je naar mb_str_replace? bytes of karakters? als bytes, welke encoding dan, en waarom? of worden de bytes als binary data gezien?
5) wat doet mb_str_replace vervolgens? bytes of karakters? als bytes, welke encoding dan, en waarom? of worden de bytes als binary data gezien?
6) wat geeft mb_str_replace terug? bytes of karakters? als bytes, welke encoding dan, en waarom? of worden de bytes als binary data gezien?
7) wat stuur je vervolgens naar de browser? bytes of karakters? als bytes, welke encoding dan, en waarom? of worden de bytes gewoon als binary blob gezien?