'dezelfde' servers, verschillende encoding

[Standeman]

Ik heb een beetje vreemd probleem, waar ik maar niet mijn vinger op kan leggen. Onze huidige (oude) server (Fedora, Tomcat 5, MySQL 4, Apache 2) doet het nog prima, maar is toe aan vervanging. Dus is er een nieuwe server ingericht (CentOS 6.3, Tomcat6, MySQL 5.1, Apache2).

Ik heb op deze nieuwe server een dump van de db geladen in MySQL, applicaties deployed in tomcat en alles werkt op zich weer prima, alleen een stukje sneller . Echter zag ik na wat rondklikken in onze applicatie op de nieuwe server het bekende � tekentje verschijnen waar bijvoorbeeld een é had moeten staan? Op onze huidige server komt dit helemaal niet voor. Daar wordt é gewoon opgeslagen als hex c3 a9 (UTF-8) in de db.

Wanneer ik naar de response headers kijk, zie ik wel wat vreemds:
Oude server:

Date: Tue, 20 Nov 2012 11:28:00 GMT
Server: Apache/2.0.54 (Fedora)
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html;charset=ISO-8859-1

200 OK

Nieuwe server

Date: Tue, 20 Nov 2012 11:26:26 GMT
Server: Apache/2.2.15 (CentOS)
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

200 OK

In alle pagina's is opgenomen dat de pagina's UTF-8 encoded moeten zijn:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Blijkbaar wordt op onze oude productieserver ergens van UTF-8 (database) de boel omgezet in ISO-8859-1 en dit is altijd blijven werken omdat de browser (ondanks de content-type in de HTML) het goed interpreteerde. (zie header). Vanuit de nieuwe omgeving wordt de tekst die blijkbaar ISO-8859-1 wordt omgezet wel als UTF-8 geinterpreteerd en gaat het dus fout.

De applicaties zijn 100% identiek en dus ook de manier waarop de db connecties worden opgebouwd. De databases zelf zijn ook goed. Wanneer ik namelijk vanaf mijn dev-pc dezelfde applicatie naar de database op de nieuwe server laat verbinden, zie ik geen encoding problemen.

Ik zit me heftig af te vragen waar ik het nu moet zoeken om dit goed te krijgen?

edit:
En ja, ik heb The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) al gelezen

[ Voor 12% gewijzigd door Standeman op 20-11-2012 14:18 ]

[Hero of Time]

Heb je ook je locale settings van de servers vergeleken? Dus wat geeft het commando 'locale' als uitvoer?

[Standeman]

uhmmm... nee.. nog niet, ga ik even doen

Maar wordt 'standaard' encoding van apache ofzo daar mee bepaald? Ik zie net hier dat het voor de JVM wel uitmaakt. Dan zal het voor apache ook wel van toepassing zijn, gok ik..

Nu besef ik trouwens dat ik heel veel moet gaan wijzigen. Onze servers communiceren namelijk ook veel met andere devices. Ik denk dat het flink fout gaat als ze opeens UTF-8 (prefered) gaan uitspugen ipv ISO-8859-1 wat de productie servers nu doen.. Ik zal sowieso het hele zooitje moeten omgooien naar 8859, omdat we de devices (tablets enzo) niet zomaar kunnen updaten zonder dat klanten boos worden.

[ Voor 81% gewijzigd door Standeman op 20-11-2012 15:39 ]

[Hero of Time]

Dat is mogelijk, daarom even controleren. Het OS zelf gebruikt een bepaalde encoding, en alles wat er op draait zal dat in eerste instantie gebruiken. Daarom zie je andere tekens als je met Putty aanmeld op een Linux machine die UTF-8 is, ipv de standaard encoding van ISO-8859-1 zoals in Windows wordt gebruikt (hoewel daar eigenlijk Win1252 van toepassing is volgens mij).

Je browser geeft alleen maar weer in de encoding die 't krijgt. Je webserver leest de DB uit en dumpt z'n eigen tekens naar je browser. UTF-8 teken in ISO8859-1, wat door je browser weer als UTF-8 wordt weergegeven geeft leuke dingen. De mime-type van de webserver wordt aangehouden door de browser, niet altijd de encoding in de HTML.

edit:
Wat andere devices doen boeit niet echt. Je hoeft niet alles om te gaan gooien, je moet alleen zorgen dat je nieuwe server hetzelfde levert als je oude. Dat je tablet met ISO8859-1 werkt, en je server met UTF-8 is niet belangrijk. Ze snappen het allebei, het is alleen wat de default is op je systeem, als je een bestand opslaat.

[ Voor 19% gewijzigd door Hero of Time op 20-11-2012 15:47 ]

[Standeman]

hmmmm, jammer. locale geeft op beide machines hetzelfde, namelijk:

code:

LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Wat betreft de devices: er wordt nogal op een obscure manier gecommuniceerd met die dingen, zou me verbazen als het goed gaat.

Ik heb inmiddels al wel voor elkaar gekregen dat Tomcat 8859 uitspuugt door

code:

URIEncoding="ISO-8859-1" useBodyEncodingForURI="true"

toe te voegen aan de server.xml config file

Nu zit ik nog even rond te neuzen in de httpd.conf om te zien of daar nog wat te regelen valt.

Overigens kan ik er nog steeds niet met mijn pet bij waarom onze oude server 8859 uitspuugt, terwijl alles op utf-8 staat

[Standeman]

Ok, het is gelukt

In apache AddDefaultCharset van UTF-8 naar ISO-8859-1 aangepast en nu wordt dezelfde encoding gebruikt als op onze oude productie machines.

Hero of Time.. my hero

[Hero of Time]

Zit nu bij onze server te kijken en daar staat het in commentaar in /etc/apache2/conf.d/charset. Staat ook dit leuke stukje:

# Read the documentation before enabling AddDefaultCharset.
# In general, it is only a good idea if you know that all your files
# have this encoding. It will override any encoding given in the files
# in meta http-equiv or xml encoding tags.

Oftewel, het boeit niet wat je in je HTML hebt, wat Apache zegt moet gebruikt worden

Even ter info voor wie hier iets mee wilt gaan doen en tegen vage dingen aan loopt en dit vind.

[Standeman]

Het rare is dat op onze productie server AddDefaultCharset ook gewoon op UTF-8 staat. Ik snap echt niet waarom dat ding 8859 uitspuugt..

Niet dat ik het wil gaan veranderen, maar ik snap er de balle van.. (en daar kan ik vaak slecht tegen )