Encoding - kode vs. server setup

I øvrigt finder jeg det tæt på utilgiveligt at de laver klasserne så de kun kan arbejde i UTF-8. Hvad er ideen så med de properties hvor man kan sætte og aflæse encoding-typen? Er det i øvrigt et generelt problem for PHPs klasser - at de kun arbejder i UTF-8 ?

Den kan da godt arbejde i andet end utf-8: http://dk.php.net/manual/en/function.dom-domdocument-construct.php

dom = new DOMDocument('1.0', 'iso-8859-1');

Prøv at indsætte et element i dit dokument der indeholder 'æøå' uden at encode det i UTF-8. Så vil du få flg. fejl :

Warning: output conversion failed due to conv error, bytes 0xC6 0x2D 0xD8 0x2D in /var/www/test.class.php on line X

Indsætter jeg mine data som UTF-8 - vha. metoden utf8_encode() - så har jeg ingen problemer.
http://dk.php.net/manual/fi/function.utf8-encode.php

Jeg må hellere lige tilføje, at du vist først får fejlen når du kalder save() på dit DOMDocument objekt - altså gemmer din XML i en fil.

Ja, det er rigtigt - Det var da lidt latterligt. Selv hvis du opretter xml dokumentet som iso-8859-1 så forventer createTextNode at inputtet er utf8...
Det lader ikke til at der er en work-around i php - Så mit forslag er at lave din egen DOM som bare nedarver fra php's, så kan du override createTextNode og hvad der ellers måtte være - Men det er klart ikke den fedeste løsning ;P

Det virker i øvrigt hvis du bare kalder saveXML på den node hvor der er æøå i - det er kun hvis du kalder saveXML uden parametre, altså så det er hele dokumentet at det går galt. Virker lidt bug-agtigt.

Enig, det virker en smule galt. Hvad skulle ideen være med at angive en encoding når den ikke virker? Men det er muligvis en "place holder" for noget funktionalitet der følger senere.

Sagen er netop også den, at jeg arver fra DOMDocument - altså 'extender' min egen klasse. Men jeg er ikke helt med på hvad du mener i din sidste kommentar (23/03-2006 22:31:56). Jeg er jo ikke interesseret i at gemme enkelte noder - jeg ønsker at gemme hele mit dokument.

Hvordan vil du i øvrigt mene at en overridden createTextNode()-metode skulle se ud? Noget i retning af nedenstående? (ikke testet):

public function createTextNode($str)
{
  return $this->createTextNode(utf8_encode($str));
}

Hvordan bør jeg i øvrigt behandle output data fra mine klasser? Jeg har en række get-metoder, som returnerer data - og pt. må de vel blive returneret i UTF-8. Men min server er sat op med ISO-8859-1. Så det giver nogle mørkelige ÆØÅ'er. Og da min løsning skal kunne køre på flere forskellige servere, så ville det vel være ideelt hvis mine get-metoder outputtede data i enten ISO-8859-1 eller UTF-8, alt efter hvad serveren er indstillet til. Eller hvad mener du?

Ja, jeg har ikke lige tænkt over det - Din skal vel være parent::createTextNode ser ok ud, men måske kan man detecte om $str er utf8 - Men jeg ved ikke om det er nødvendigt :)
Outputter dine metoder utf8? saveXML outputter iso-8859-1 for mig, selvom createTextNode skal have utf8...

Hvis man nærlæser XML specs, så står der faktisk at alle XML applikationer
skal understøtte UTF-8. ISO-8859-1 er optional.

UTF-8 er vejen frem når det drejer sig om XML.

(og med kinas stigende betydning på internettet også for mange andre
web ting)

Coder > Ah ja. Det skal nok være parent i stedet for this.
Men jeg tror nærmere man skal detecte _serverens_ indstillinger, og så evt. outputte i forhold til det. Alternativt må man pille ved headeren når data sendes, og dermed sende alt i UTF-8. Skal ikke kunne sige om det er god praksis.
I øvrigt outputter saveXML() og save("data.xml") også i ISO-8859-1 hos mig - men det ændre ikke på at hvis jeg henter data ind fra dokumentet, så er det i UTF-8. Jeg benytter tilmed SimpleXML-klassen til at skabe mine DOMDocument objekter (til at populere data i dem). Så heller ikke den synes at have ordentlig encoding support. Den læser i hvertfald ikke encodingen fra XML dokumentet.

Arne > Ok, super. Det er bestemt værd at tage med i overvejelserne. Hvad vil du mene er den rette løsning til dette problem? At outputte i den encoding serveren bruger? Eller at modificere headeren og outputte alt i UTF-8?

Jeg har aldrig arbejdet med XML i PHP, saa det skal jeg ikke goere mig
klog paa det konkrete.

Jeg gav bare lidt baggrund til hvorfor XML kan vaere meget UTF-8 centric.

Generelt ville jeg nok holde XML i UTF-8, men generelt er jo saadan
"medmindre der er gode grunde til andet"

Jeg ville mene at det ville være bedst at "bide i det sure æble", hvis det kan siges sådan, og så outputte alt i UTF-8. Så er det fremtidssikret, og vil sikkert skabe mindst problemer i forhold til klienterne ;)

Ok. Så løsningen er altså at modificere headeren, right? Noget i retning af:
header("Content-Transfer-Encoding: UTF-8");

Oh, det er vist nærmere
header("Content-type: text/css; charset=UTF-8");

Jeg er dog stadig forvirret over måden PHP håndterer encoding på. Hvis serveren er sat op til at bruge UTF-8 som standard, hvorfor får jeg så stadig fejl når jeg placerer data i mine DOM objekter? De burde vel være encodet i UTF-8!?

Anyone ?

Ah, har indset at det afhænger af hvilken type encoding jeg bruger på mine dokumenter. Har jeg fx en PHP fil med nedenstående indhold encodet i ISO-8859-1, og jeg kører UTF-8 på serveren, så vil det blive noget volapyk.

<?php echo "ÆØÅ"; ?>

Så der er flere ting at holde øje med.

1) Encoding på filen som indeholder kode
2) Encoding på serveren (eller kode-mæssigt ændre encoding i headeren)
3) Encoding i DOM objekterne

Nedenstående indlæg i et forum opsummerer rimelig fint hvordan jeg har det lige nu. Min opfattelse er at der er fuldstændig inkonsistens i mellem en masse elementer, som gør det meget besværligt at lave internationale applikationer. Jeg er så småt ved at gå tilbage til en ren ISO-8859-1 applikation, som blot konverterer mellem UTF-8 og ISO-8859-1 i mine DOM* objekter.

http://www.webmasterworld.com/forum88/2256.htm

I må begge to forresten gerne smide et svar ved lejlighed. Jeg har afsat lidt flere points til jer :)

jeg ville nok hve satset på at konvertere det hele til UTF-8

ingen point til mig - mit bidrag har kun været nogle generelle betragtninger

Enig, utf-8 lyder som vejen at gå :)

Jeg siger tak for hjælpen så :)