Webserver verandert mijn characters, waar komt dat vandaan?

[Sando]

Ik heb een xhtml met wat 'tèkens'. Ziet er prima uit in de browser.

Als ik dit uploadt met een FTP client en online bekijk is het precies hetzelfde. Je verwacht ook niet anders.

Na een upload (met FileZilla) naar een andere webserver zijn de tekens echter raar, terwijl ze in de source nog gewoon goed zijn. Als ik de file met FileZilla weer downloadt of de source van de fout ogende html opsla en in de browser bekijk, is alles weer goed.

Ik snap er niets van! Hoe kan dit?

Heb de opties van filezilla bekeken maar er wordt geen character conversie gedaan ofzo. Enige wat je kan overriden is de character encoding van file names maar dat is in dit geval niet relevant.

Ik heb de encoding ook al verandert (in het document) van utf8 naar iso1159-1 en -15, waardoor het effect precies omdraait.

Volgens mij moet op die 2e server ergens de boel omdraaien maar ik heb geen idee of daar een switch, config of header voor is. Waar kan ik verder nog naar kijken? Waar kan dit aan liggen?

Samenvatting:
Server 1:
utf-8
iso8859-1
Server 2:
utf-8
iso1159-1

-update-

Wel raar, de source die in de browser raar is maar na opslaan goed is was gedaan met Notepad++, maar met Firefox source viewer zie je wel dat er een verschil in de source is..

[F_J_K]

Misschien wil je even de binary mode zetten.

Los daarvan zou ik alle speciale karakters escapen È etc. Maar daar ben ik dan misschien ouderwets in, ik heb html2 geleerd in emacs

[Snow_King]

Als het Apache is probeer dan eens in een .htaccess te zetten:

code:

AddDefaultCharset UTF-8

Of in plaats van UTF-8 (iso-8859-1)

Dan forceer je daarmee de encoding.

[xtra]

Bij server 2 zie ik in ieder geval de volgende header bij het utf-8 bestand:

code:

Content-Type: text/html; charset=iso-8859-1

Dat zou niet mogen. Heb je het bestand ook opgeslagen als utf-8 of alleen de encoding in xml aangepast?

Oh, en server 1 doet alleen (bij het utf-8 bestand)

code:

Content-Type: text/html

Zou kunnen betekenen dat de browser het zelf probeert uit te vinden.

[ Voor 25% gewijzigd door xtra op 29-06-2009 22:32 . Reden: toevoeging ]

[Joen]

Het zelfde probleem kom ik wel eens tegen met speciale karakters opslaan in MySQL en dan later uitlezen: dan komen ze er ook zo apart uit. Vooral bij userinput als een forum valt dat moeilijk van te voren af te vangen en om te zetten naar &-codes.

[remco_k]

Zoals al gezegd, er klopt iets niet met je karakterset.

Bij dit soort (en andere problemen) wil het nog weleens helpen om je pagina door de w3c validator te halen.

Die geeft je (in dit geval) ook direct een zet in de juiste richting.
Ook als je geen problemen hebt, is het een aanrader om je pagina er even doorheen te fietsen. Soms wordt je gewezen op een potentieel probleem wat zich alleen nog niet heeft geuit.

[ Voor 18% gewijzigd door remco_k op 29-06-2009 22:37 ]

[BastiaanN]

Als die 2e server een apache bak is waar je zelf de controle over hebt dan moet je even AddDefaultCharset uit de config slopen, doet wonderen. Die geeft dan niet meer zelf een charset mee maar laat het de browser zelf uit zoeken of je kunt het opgeven in je html. Ik heb dit zelf ook zo ingesteld op al mijn servers.

En anders gewoon gebruikmaken van de & tekens. ë is bijvoorbeeld ë
De meeste tekens kan je hier wel vinden: Wikipedia: Help:Speciale tekens

[ Voor 30% gewijzigd door BastiaanN op 30-06-2009 14:54 ]

[Verwijderd]

Joen schreef op maandag 29 juni 2009 @ 22:30:
Het zelfde probleem kom ik wel eens tegen met speciale karakters opslaan in MySQL en dan later uitlezen: dan komen ze er ook zo apart uit. Vooral bij userinput als een forum valt dat moeilijk van te voren af te vangen en om te zetten naar &-codes.

Ga dan eens iets meer lezen over character encoding. Het is eigenlijk heel erg simpel, stel je voor dat je niet de tekens zag, maar alleen de ascii nummers van de tekens, dus bijvoorbeeld 84 119 101 97 107 101 114 115 46 110 101 116.

Zolang je onder de 127 zit, zullen alle tekensets hetzelfde resultaat geven. Als je echter aan "bijzondere" tekens begint, start het probleem. Je zult de lezer erbij moeten vertellen welk "codeboek" hij erbij moet pakken om de boel te "ontcijferen". Zorg er gewoon voor dat overal hetzelfde wordt gebruikt, en je hebt geen enkel probleem. Bij elk transport zul je ook moeten aangeven welke encoding moet worden gebruikt voor wat er verstuurd wordt. Vandaar dat het in PHP moet (default_charset) voor de interne verwerking van PHP, in Apache (AddDefaultCharset) voor het transport (HTTP headers), en in MySQL (CHARACTER SET bij aanmaken tabellen/kolommen en SET NAMES 'utf8' voor het transport).

BastiaanN schreef op maandag 29 juni 2009 @ 22:39:
Als die 2e server een apache bak is waar je zelf de controle over hebt dan moet je even DefaultCharset uit de config slopen, doet wonderen. Die geeft dan niet meer zelf een charset mee maar laat het de browser zelf uit zoeken. Ik heb dit zelf ook zo ingesteld op al mijn servers.

Ga dan een andere hobby zoeken. Waarom moet een browser zelf raden welke character set moet worden gebruikt, terwijl de maker van de website dat wéét? Het is onkunde van de serverbeheerder en ontwikkelaar als een client moet gaan raden...

Het is niet "je moet even dit weghalen en dan werkt het wel", het is een kwestie van begrijpen wat er aan de hand is en hoe je het op moet lossen. En dat stelt echt niet veel voor. Ga alsjeblieft niet lopen verkondigen dat mensen lui moeten zijn en maar wat moeten prutsen.

[ Voor 25% gewijzigd door Verwijderd op 29-06-2009 22:45 ]

[Sando]

Snelle reacties, bedankt.

Wat mij ook net opviel (via http://www.hashemian.com/tools/browser-simulator.htm ) is dit:

xtra schreef op maandag 29 juni 2009 @ 22:30:
Bij server 2 zie ik in ieder geval de volgende header bij het utf-8 bestand:

code:

Content-Type: text/html; charset=iso-8859-1

Dat zou niet mogen. Heb je het bestand ook opgeslagen als utf-8 of alleen de encoding in xml aangepast?

Oh, en server 1 doet alleen (bij het utf-8 bestand)

code:

Content-Type: text/html

Zou kunnen betekenen dat de browser het zelf probeert uit te vinden.

Ik denk dat dat het probleem is. Alsof server2 de ISO eraan wil forceren, want in de xhtml wordt duidelijk utf tweemaal geforced. Idd ook deze link gevolgt:

remco_k schreef op maandag 29 juni 2009 @ 22:35:
Bij dit soort (en andere problemen) wil het nog weleens helpen om je pagina door de w3c validator te halen.

Geeft idd aan dat HTTP header (iso-8859-1) wordt geforced, en dat moet helemaal niet!
btw klein stukje html ergens uit gesloopt, ik weet dat de markup verder niet klopt zo maar is eventjes minder relevant

Waar wordt een encoding header gegeven als er geen .htaccess is? (en server1 doet dat ook niet)

Ik zoek nog even door naar rommeltjes, die AddDefaultCharset tip zal ik later proberen, ik fix het liever anders (als dat kan natuurlijk) dit zou betekenen dat ik .htaccessjes moet gaan geven om iets wat een andere server wel gewoon kan te fixen.

[Sando]

Was snel uitgekeken, gewoon geen .htaccess in folders of parentfolders (hoe noem je dat) te vinden dus toch maar dit gedaan:

Snow_King schreef op maandag 29 juni 2009 @ 22:28:
Als het Apache is probeer dan eens in een .htaccess te zetten:

code:

AddDefaultCharset UTF-8

Dan forceer je daarmee de encoding.

En dat werkt!

Maar liever wil ik die header van server2 als server1 hebben. Iemand een idee?

[McKaamos]

Sando schreef op maandag 29 juni 2009 @ 22:49:
Snelle reacties, bedankt.

Wat mij ook net opviel (via http://www.hashemian.com/tools/browser-simulator.htm ) is dit:


[...]


Ik denk dat dat het probleem is. Alsof server2 de ISO eraan wil forceren, want in de xhtml wordt duidelijk utf tweemaal geforced. Idd ook deze link gevolgt:


[...]

Geeft idd aan dat HTTP header (iso-8859-1) wordt geforced, en dat moet helemaal niet!
btw klein stukje html ergens uit gesloopt, ik weet dat de markup verder niet klopt zo maar is eventjes minder relevant

Waar wordt een encoding header gegeven als er geen .htaccess is? (en server1 doet dat ook niet)

In geval van Apache staat dat normaliter in een van de configuratiefiles, wss httpd.conf.
Via een .htaccess file kan je zelf instellingen wijzigen. Aannemende dat je bij een webhoster zit, zal dat alleen gelden voor die betreffende documentroot.

Verder weet ik niet of je toevallig bij twee verschillende hosts bezig bent, maar als dat het geval is, is dat simpelweg een configuratiekeuze van de webhost geweest.

Ik zoek nog even door naar rommeltjes, die AddDefaultCharset tip zal ik later proberen, ik fix het liever anders (als dat kan natuurlijk) dit zou betekenen dat ik .htaccessjes moet gaan geven om iets wat een andere server wel gewoon kan te fixen.

Verder raad ik je sowieso aan om html chars te gebruiken ipv een encoding te forceren. dus een "e" met een naar rechts wijzend streepje er op wordt dan "& eacute;". (zonder spatie, GoT lijkt het ook te parsen ) Zo zijn er voor alle speciale tekens wel dergelijke codes, en die werken onafhankelijk van je karakterset encoding.

Anyway, zoals al gezegd wordt, je kan in je HTML document lullen wat je wil over de encoding, als de server iets stuurt is dat de wet en zal de browser gehoorzamen.
De enige foolproof methode is html karakter codes gebruiken. De browser zoekt dan wel uit welke dat zou moeten zijn.

[ Voor 8% gewijzigd door McKaamos op 29-06-2009 23:06 ]

[Verwijderd]

Sando schreef op maandag 29 juni 2009 @ 22:49:

Ik denk dat dat het probleem is. Alsof server2 de ISO eraan wil forceren, want in de xhtml wordt duidelijk utf tweemaal geforced.

Waarom zou een client nog moeite doen uit de inhoud een character encoding proberen te halen als de server al duidelijk heeft aangegeven welke character encoding het document heeft? Juist, daar is niet echt een reden voor. Die "hints" die er staan, want meer zijn ze in dit geval niet, zijn eigenlijk meer geschikt als er geen transport plaatsvindt, en een client zelf moet gaan bepalen welke encoding een bestand heeft. Dat moet je helemaal niet willen. De server kan prima aangeven in welke character encoding hij een respons gaat sturen. In dit geval vertelt server 2 iets wat niet klopt, dus moet je die server configureren.

Geeft idd aan dat HTTP header (iso-8859-1) wordt geforced, en dat moet helemaal niet!

Er wordt niks geforceerd. Alleen de client kan zichzelf forceren een document in een bepaalde character encoding te interpreteren.

Waar wordt een encoding header gegeven als er geen .htaccess is? (en server1 doet dat ook niet)

In de algemene serverconfiguratie van Apache, dit verschilt per besturingssysteem. Probeer /etc/httpd/conf/httpd.conf en /etc/apache2/apache2.conf. Ook kan het per virtual host of directory worden ingesteld. Meestal is er één algehele default character set, maar het is niet raar om dit voor een virtual host of een directory anders in te willen stellen. Een .htaccess is eigenlijk een prima plek om dit te configureren, al is een stapje hoger iets mooier.

Ik zoek nog even door naar rommeltjes, die AddDefaultCharset tip zal ik later proberen, ik fix het liever anders (als dat kan natuurlijk) dit zou betekenen dat ik .htaccessjes moet gaan geven om iets wat een andere server wel gewoon kan te fixen.

Ik weet vrij zeker dat de AddDefaultCharset gaat werken. Forceer je client maar eens om UTF-8 te gebruiken

[Sando]

McKaamos schreef op maandag 29 juni 2009 @ 23:00:
In geval van Apache staat dat normaliter in een van de configuratiefiles, wss httpd.conf.
Via een .htaccess file kan je zelf instellingen wijzigen. Aannemende dat je bij een webhoster zit, zal dat alleen gelden voor die betreffende documentroot.

Thx voor de uitleg.

Verder weet ik niet of je toevallig bij twee verschillende hosts bezig bent, maar als dat het geval is, is dat simpelweg een configuratiekeuze van de webhost geweest.

Dat is inderdaad het geval, die 2e host koos er zeker voor dat te configureren. Naar mijn mening beetje dom, een encoding opgeven, dat laat je toch over aan je documenten (lees: klanten)?

Verder raad ik je sowieso aan om html chars te gebruiken ipv een encoding te forceren.

Daar ben ik het dan minder mee eens, die encodings zijn gestandaardiseerd om dat te kunnen en zullen niet snel vergeten worden.

Bovendien gaat het in dit specifieke geval om xhtml exports van verschillende projecten opgezet in Gnome Planner die ik gewoon online wilde zetten en er achter kwam dat dat eventjes mis ging na het uploaden op die ene server waar ik het nu net op wilde hebben terwijl het bij een aantal anderen wel gewoon goed ging. Was daardoor even verbaasd en je wilt niet weten hoe lang ik er al mee aan het klooien ben terwijl het zo iets kleins blijkt.

Verwijderd schreef op maandag 29 juni 2009 @ 23:01:
Waarom zou een client nog moeite doen uit de inhoud een character encoding proberen te halen als de server al duidelijk heeft aangegeven welke character encoding het document heeft? (..) In dit geval vertelt server 2 iets wat niet klopt, dus moet je die server configureren.

Ehm, als een auto naar links lijkt af te slaan en te signaleren maar op de weg staat een verplicht rechts afslaan bord dan zal ik toch afremmen voor deze auto. Maw, als een document zegt wat het is, vind ik het logischer om daar op af te gaan dan wat de documentenmap (server) over de documenten beweert. Maar dat ben ik, mijn server is het wel met je eens

Een server trouwens die ik niet kan configureren (shared) dus dan moet ik idd maar forceren met .htaccess, wat niet zou hoeven als men gewoon naar het document luistert en doet als of het utf-8 is.

Bedankt voor je overige uitleg! Zoals ik eerder zei, die .htaccess werkt idd, ik kijk nog even of ik niet stiekem toch eea kan configureren op die locaties die je aangaf.

[ Voor 0% gewijzigd door Sando op 29-06-2009 23:17 . Reden: typo ]

[Sando]

-update-

Verwijderd schreef op maandag 29 juni 2009 @ 23:01:
In de algemene serverconfiguratie van Apache, dit verschilt per besturingssysteem. Probeer /etc/httpd/conf/httpd.conf en /etc/apache2/apache2.conf.

apache2 folder bestaat niet en /etc/httpd/(conf/) is leeg.. ook in de andere mappen kom ik niet de bekende bestanden tegen. Ik denk dat dat van hogeraf bepaald wordt en dat .htaccess de oplossing is.

Maar ik wil op verschillende pagina's verschillende encodings kunnen gebruiken. Kan ik met .htaccess de encoding ook annuleren, zodat de header wel zoals server1 wordt?

-edit-
en dan bedoel ik een .htacceess dicht bij de root zodat ik niet in elke subfolder een nieuwe plaats, gewoon één enkele "maak die encoding opgave ongedaan" .htaccess.

[ Voor 13% gewijzigd door Sando op 29-06-2009 23:23 ]

[McKaamos]

AddDefaultCharset off

Daarmee geeft de server geen encoding mee. Of dat het resultaat geeft wat je wil weet ik niet though.
Kan net zo goed zijn dattie dan nog weer wat anders gaat doen.
De .htaccess geld voor de betreffende folder en alle onderliggende folders, tenzij die een eigen .htaccess hebben die de betreffende settings overriden.
Je kan dus idd een master .htaccess maken en die in de root folder van je website neerplempen.

Verder kan je nagenoeg nooit bij een shared host de .conf files aanpassen. Die zijn gecentraliseerd op de server, dus je bent verplicht om het te doen via .htaccess als je iets veranderd wil hebben.
Het is wel zo dat je niet bij alle hosts alles kan veranderen, dus daar moet je ook nog rekening mee houden.

[ Voor 19% gewijzigd door McKaamos op 29-06-2009 23:26 ]

[Sando]

McKaamos schreef op maandag 29 juni 2009 @ 23:25:
AddDefaultCharset off

Daarmee geeft de server geen encoding mee. Of dat het resultaat geeft wat je wil weet ik niet though.
Kan net zo goed zijn dattie dan nog weer wat anders gaat doen.
De .htaccess geld voor de betreffende folder en alle onderliggende folders, tenzij die een eigen .htaccess hebben die de betreffende settings overriden.
Je kan dus idd een master .htaccess maken en die in de root folder van je website neerplempen.

Super, dankje!

Bedankt allen, ik weet nu wat het probleem is en wat ik er wel en niet tegen kan doen.

[Sando]

Laatste update nog even,

Verwijderd schreef op maandag 29 juni 2009 @ 23:01:
"Geeft idd aan dat HTTP header (iso-8859-1) wordt geforced, en dat moet helemaal niet!"
Er wordt niks geforceerd. Alleen de client kan zichzelf forceren een document in een bepaalde character encoding te interpreteren.

Net kreeg ik reply van mijn hoster en die noemt dat gewoon hetzelfde hoor.

Hoi,

De charset "iso-8859-1" wordt geforceerd door de standaard instelling van de server. Je kan deze middels een regel in een .htaccess bestand eenvoudig overrulen. Zodra je de regel "AddDefaultCharset utf-8" toevoegt zal de weergave en header op de gewenste charset terecht komen.

Hopende je hierbij voldoende van dienst te zijn geweest.

[McKaamos]

Sando schreef op dinsdag 30 juni 2009 @ 00:09:
[...]

Super, dankje!

Bedankt allen, ik weet nu wat het probleem is en wat ik er wel en niet tegen kan doen.

Graag gedaan!

Je kan trouwens nog veel meer leuks met .htaccess doen.
Uiteraard wel afhankelijk van welke opties je hoster toestaat, maar je kan ook settings van PHP beinvloeden, je eigen errordocuments instellen (eigen 404 page b.v.) en prutsen met mod_rewrite voor SEO Friendly URLs en hotlink beveiliging b.v.

[BastiaanN]

Verwijderd schreef op maandag 29 juni 2009 @ 22:41:
[...]

Ga dan een andere hobby zoeken. Waarom moet een browser zelf raden welke character set moet worden gebruikt, terwijl de maker van de website dat wéét? Het is onkunde van de serverbeheerder en ontwikkelaar als een client moet gaan raden...

Het is niet "je moet even dit weghalen en dan werkt het wel", het is een kwestie van begrijpen wat er aan de hand is en hoe je het op moet lossen. En dat stelt echt niet veel voor. Ga alsjeblieft niet lopen verkondigen dat mensen lui moeten zijn en maar wat moeten prutsen.

Deze setting zorgt er gewoon voor dat de charset die geconfigureerd staat in de serverconfig niet meer "forced" is. Daardoor kan je dus in de broncode van je html de charset opgeven. Bij de bedrijven waar ik werkzaam ben hebben ze dit ook nog altijd uitgeschakeld. Wellicht was mijn uitleg een beetje krom, echter mag je jezelf ook wel even inlezen voordat je begint te schreeuwen

In de help van apache staat ook:

AddDefaultCharset should only be used when all of the text resources to which it applies are known to be in that character encoding and it is too inconvenient to label their charset individually.