[php-xml] vreemde tekens (Turks) verwerken

[HenkS]

Hallo,

Wij bij ons bedrijf krijgen orders (voor boeken te drukken) via XML aangeleverd.
Dit doen wij voor veel landen, hiervoor hebben we een systeem gebouwd waarmee we de XML inlezen in de database, barcodes op de artikelen worden geprint enz enz.

Echter is nu ook Turkije erbij gekomen en hier heb ik problemen met de Turkse tekens.

De Nederlandse 'vreemde' tekens als een éë enz kan ik oplossen door:

code:

$city = utf8_decode($tot_order['City']);

(XML wordt als een array ingelezen via PEAR)

Waarbij deze tekens goed worden verwerkt.

Nu staat er in de Turkse XML bij de naam of adres bijvoorbeeld dit:
<Firstname>alper</Firstname>
<Lastname>adıgüzel</Lastname>
<Address1>denizköşkler mah. denizköşkler cad. akın sok. akın apt. NO: 5 D :1 Bahçekatı avcılar</Address1>


Als ik dan de utf8_decode hierop loslaat komt er dit uiteindelijk in de database te staan:
lastname: ad?g?
address: denizk?er mah. denizk?er cad. ak?n sok. ak?n apt. NO: 5 D :1 Bah?at?
avc?lar

Moet ik hiervoor een andere decode optie gebruiken? ik kan zo namelijk niet vinden wat.

[TwoR]

Kan je er niet voor zorgen dat alles sowieso in UTF-8 gecodeerd word?

Dus ook de XML. Op het moment dat alles UTF-8 is zou het wel goed moeten zijn

[mace]

Welke encoding gebruikt de database?

[Verwijderd]

utf8_decode zet de string om naar karakterset ISO-8859-1. Mogelijk zijn de Turkse tekens niet in deze set opgenomen. Daarnaast weet ik niet of je het in een database opslaat, maar ook daar moet je de karakterset goed zetten. Let op dat de verbinding ook een karakterset gebruikt.

[HenkS]

De database (moest ff zoeken:))

MySQL charset: UTF-8 Unicode (utf8) staat erbij.

Twor wat jij zegt, ook de XML utf8 decode,

maar ik utf8 decode het al als ik de array uitlees voordat ik deze insert in de database en de database heeft ook nog eens UTF8 decode. Is het dan niet allemaal dubbel-op (driedubbel op?)

en de verbinding gebruikt ook een karakterset, die snap ik even niet...

[HenkS]

nou volgens mij is het inderdaad dat utf8 (die ISO) karakter set bepaalde tekens niet ondersteund.

Dit zijn de ondersteunde tekens:

http://htmlhelp.com/reference/charset/latin1.gif

Dus dan zou ik een andere optie als utf8 moeten gebruiken?

[Verwijderd]

Inderdaad. Je zult moeten overstappen op een meer internationale karakterset. UTF-8 is hier uitermate voor geschikt. Dit betekent wel dat je gaat werken met een multi-byte karakterset. En je dus de multi-byte functies in php dient te gebruiken. Je zult niet 1-2-3 kunnen overstappen van een single-byte naar een multi-byte karakterset (als je het goed wilt doen).

[Eddy Dean]

Er zijn (volgens wikipedia) zes tekens in het Turks die niet in de ISO-8859-1 charset zitten (Ğ, İ, Ş, ğ, ı, ş). Ik gebruik zelf altijd overal Unicode (UTF-8). Als je dit overal consequent doorvoert hoef je ook nooit meer te encoden en decoden.

Bron: Wikipedia: Wikipedia:Turkish characters

-- Edit --
Nog wat leesvoer:
http://developer.loftdigital.com/blog/php-utf-8-cheatsheet
http://www.joelonsoftware.com/articles/Unicode.html

[ Voor 15% gewijzigd door Eddy Dean op 23-06-2009 09:21 ]

[Joolee]

HenkS schreef op dinsdag 23 juni 2009 @ 09:12:
nou volgens mij is het inderdaad dat utf8 (die ISO) karakter set bepaalde tekens niet ondersteund.

Dit zijn de ondersteunde tekens:

http://htmlhelp.com/reference/charset/latin1.gif

Dus dan zou ik een andere optie als utf8 moeten gebruiken?

De afbeelding die je plaatst is van ISO 8859-1. UTF-8 zou die tekens als het goed is gewoon moeten ondersteunen.

Wat je moet doen is niet overal UTF-8 decode toepassen maar juist overal UTF-8 gebruiken. Denk eraan dat je in je HTML pagina en HTTP Headers ook aangeeft dat het om UTF-8 gaat. Vergeet ook je MySQL connection niet.

[TwoR]

HenkS schreef op dinsdag 23 juni 2009 @ 09:10:
De database (moest ff zoeken:))

MySQL charset: UTF-8 Unicode (utf8) staat erbij.

Twor wat jij zegt, ook de XML utf8 decode,

maar ik utf8 decode het al als ik de array uitlees voordat ik deze insert in de database en de database heeft ook nog eens UTF8 decode. Is het dan niet allemaal dubbel-op (driedubbel op?)

en de verbinding gebruikt ook een karakterset, die snap ik even niet...

Ik bedoelde niet dat je die moest decoden maar dat je helemaal moet overstappen op UTF-8 zoals Joolee ook aangeeft

[HenkS]

TwoR schreef op dinsdag 23 juni 2009 @ 09:18:
[...]

Ik bedoelde niet dat je die moest decoden maar dat je helemaal moet overstappen op UTF-8 zoals Joolee ook aangeeft

ok ehmm nu ga ik denk ik iets stoms vragen.

Hoe stap je over op UTF-8, ben hier niet zo bekend mee. Doe je dat dmv een php setting of...
sorry haha schaam schaam

[Janoz]

Nou, begin iig met het doorlezen van de door Eddy Dean geplaatste link naar Joel on Software over Unicode. Het artikel heet niet voor niks "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)".

[cariolive23]

(XML wordt als een array ingelezen via PEAR)

Waarom niet met de standaard functies van PHP? Zowel DOM als SimpleXML zijn eenvoudig te gebruiken en leveren geen enkel probleem op met correcte XML.

En die XML, is dat wel correcte XML? Lijkt een rare vraag, maar de ervaring leert mij dat vele zogenaamde XML's in werkelijkheid alleen maar lijken op XML maar er verder weinig mee te maken hebben. De eerste de beste validatie levert dan al een fraaie foutmelding op.

XML is standaard UTF8, tenzij er een andere encoding wordt opgegeven in de XML-declaratie. Wat staat er bij jou in de declaratie?

[HenkS]

cariolive23 schreef op dinsdag 23 juni 2009 @ 09:25:
[...]

Waarom niet met de standaard functies van PHP? Zowel DOM als SimpleXML zijn eenvoudig te gebruiken en leveren geen enkel probleem op met correcte XML.

En die XML, is dat wel correcte XML? Lijkt een rare vraag, maar de ervaring leert mij dat vele zogenaamde XML's in werkelijkheid alleen maar lijken op XML maar er verder weinig mee te maken hebben. De eerste de beste validatie levert dan al een fraaie foutmelding op.

XML is standaard UTF8, tenzij er een andere encoding wordt opgegeven in de XML-declaratie. Wat staat er bij jou in de declaratie?

Ja de XML is correcte XML en er is gekozen om gebruik te maken van PEAR, bevalt ook prima.
In de XML declaratie staat dit:
<?xml version="1.0" encoding="UTF-8" ?>

En de inhoud van de XML staat een deel van in mijn starting post. Hier worden de tekens dus wel correct weergegeven.

[cariolive23]

Wanneer je UTF8 ontvangt en UTF8 in de database nodig hebt, waarom wil je dan in je PHP-code met iets anders gaan werken dan UTF8? Volgens mij maak je daarmee een probleem aan wat helemaal niet nodig is.

Gooi die conversie de deur uit en volgens mij is jouw probleem dan opgelost.

Overigens kent MySQL een flink aantal varianten op UTF8, je zou even in de handleiding moeten uitzoeken wat daarin de verschillen zijn en welke nu de enige echte UTF8 is. Je hebt de generieke variant nodig en niet een variant die bij taal A wel werkt maar bij taal B weer de nodige problemen oplevert. Daarmee zou je alle voordelen van UTF8 de nek omdraaien.

[mace]

In het kort: Alles naar UTF-8, je PHP, je XML (is al), je database (is ook al), en je database connectie (niet vergeten!).

Ik weet niet of ik nog wat mis, maar vooral je PHP gedeelte gaat wel wat werk in zitten, alle utf-8 decodes moeten er uit en zoals Backlash zegt multi-byte functies.

[Verwijderd]

Niet alleen de declaratie is belangrijk maar ook de encoding van de file waarin het opgeslagen zit, maar ik krijg niet het idee dat daar problemen mee zijn. Het probleem zit vooral in de database. Als deze database geen UTF-8 encoding gebruikt kan je er ook geen UTF-8 characters in knallen.

Verder moet je als je in php de XML file parsed ook aan de parser kenbaar maken dat het een UTF-8 file betreft. Dan pakt php ook direct de juiste charcacters. Deze hoef je dan niet nog een keer extra te decoden maar kan je ze direct in de database zetten.

PHP weet dan dat hij omgaat met UTF-8 content en de database accepteerd dit ook.
Dit linkje kan je hier wellicht bij helpen maar ook de utf8_decode($string) is een prima oplossing.

Makkelijkste en naar mijn mening ook de beste oplossing is al genoemd, database op utf8.

[Swaptor]

TS: je doet een utf8_decode. Lijkt me relatief duidelijk wat daar gebeurt; je neemt een UTF-8 encoded string en gaat er jouw localized encoding van maken.
Het zou wat testwerk op kunnen leveren, maar ik vermoed dat als je niet decode alles in 1 keer goed gaat werken (want je krijgt het al als UTF-8).

[Apen-nootjes]

Waarschijnlijk gaat het niet direct goed, moet zijn verbinding ook nog even op UTF8 gezet worden:

PHP:

mysql_query("SET NAMES utf8");
mysql_query("SET CHARACTER_SET utf8;");

Ook moet je erop letten dat bepaalde PHP functies niet (goed) meer werken... Deze functies werken namelijk op bytes en niet op karakters, aangezien een UTF8 karakter multi-byte kan zijn zal dat niet altijd goed gaan, denk hierbij aan functies als split() en str_len()

Ohw, en als je alles in UTF8 gaat doen, haal dan alle utf8-decode eruit!

Waarom heb je dat er uberhaupt in gezet trouwens? Als je een functie gebruikt dan moet je snappen wat je doet, en dat snap jij overduidelijk niet! Ik wil je aanraden om voortaan dus ook niet klakkeloos dat soort dingen te gebruiken maar je ook een beetje in te lezen

[ Voor 27% gewijzigd door Apen-nootjes op 23-06-2009 10:31 ]

[whoami]

Janoz schreef op dinsdag 23 juni 2009 @ 09:23:
Nou, begin iig met het doorlezen van de door Eddy Dean geplaatste link naar Joel on Software over Unicode. Het artikel heet niet voor niks "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)".

The turkey test:
http://www.moserware.com/...ode-pass-turkey-test.html

[Eddy Dean]

Apen-nootjes schreef op dinsdag 23 juni 2009 @ 10:29:Ook moet je erop letten dat bepaalde PHP functies niet (goed) meer werken... Deze functies werken namelijk op bytes en niet op karakters, aangezien een UTF8 karakter multi-byte kan zijn zal dat niet altijd goed gaan, denk hierbij aan functies als split() en str_len()

Er is voor PHP wel een module die deze functies vervangt door functies die wel om kunnen gaan met multibyte tekens. Dan krijg je functies als mb_strlen enzo. Lijkt me echt heerlijk als je toevallig een library/framework gebruikt wat hier geen support voor heeft.

http://nl.php.net/mbstring

[Apen-nootjes]

Klopt, zitten echter ook wat haken en ogen aan als ik me goed herinner, zo eens kijken of ik m'n afstudeer scriptie nog kan vinden, had ik het een en ander uitgezocht

edit:
Dit gaat over de 'gevaarlijke' functies: http://www.phpwact.org/php/i18n/utf-8

Ook deze is interessant, wat gaat er allemaal mis en hoe op te lossen, hier staat ook een stukje in over mb_ :
http://www.phpwact.org/php/i18n/charsets

relevante stukjes uit de laatste link over mb_string:

quote: http://www.phpwact.org/php/i18n/charsets

mbstring: The mbstring extension is potentially a magic wand, as it provides a mechanism to override a large number of PHP‘s string functions. Bad news is it’s not avaible by default in PHP. Third-hand reports say it used to be pretty unstable but in the last year or so has stabilized (more detail appreciated).

quote: http://www.phpwact.org/php/i18n/charsets

The mbstring extension

Manual: http://www.php.net/mbstring

Provides multibyte aware implementations of some of the most common PHP string functions, the POSIX extended regex extension and the mail function. These are either accessible via their own namespace (i.e. functions beginning mb_*) or can be used to “overload” the normal PHP implementations, giving you half a chance (expect to have additional work to do) to have an application support a different character set to that it was designed for.

The mbstring extension supports many different character sets, most importantly UTF-8. It also allows for conversion between character sets and implements some level of encoding detection (no idea how effective this is though).

The mbstring extension is not part of the default PHP distribution - if you need it and are using a web hosting service, make sure you provide has compiled it into PHP. Common Linux distributions (like Debian) package PHP with mbstring.

[ Voor 114% gewijzigd door Apen-nootjes op 23-06-2009 11:46 ]

[HenkS]

bedankt allemaal

na alles goed gelezen te hebben

vooral deze pagina ivm database aanpassen:
http://developer.loftdigital.com/blog/php-utf-8-cheatsheet

het verwijderen van de decode functie en nog wat andere kleine aanpassingen zie ik alle letters nu op het scherm en in de database zoals het hoort.

bedankt voor de hulp en de goede links!