[html form] Duitse taal

[ViNyL]

Ik ben voor iemand bezig een aantal fouten uit een website te halen. De is opgezet door een bedrijf maar er zijn wat losse eindjes waar ze niet uit komen (of willen komen), maar dat terzijde.

De website is 2-talig en is opgezet in Joomla. De website is in het Nederlands en het Duits. De Duitse teksten op de website zien er allemaal qua characters goed uit. Als een klant echter een bericht verstuurd middels het form op de website dan komen de dingen als de ringel S, á, ë ,ä etc niet goed aan.

De characterset voor de pagina staat op

HTML:

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

De mailtjes komen zo binnen:

Berlin ansässigen Händlers mit antiken Uhren soll die Uhr aber erst Anfang des 20

Ik heb zelf eigenlijk niet goed een idee waar dit uit weg kan komen omdat ik vrij weinig ervaring met de Duitse taal en websites heb.De character set op de site lijkt iig wel overweg te kunnen we de Duits specifieke tekens.

Waar kan dit uit weg komen?

[MueR]

Als de emails niet goed aankomen, zal het vast niet aan de pagina liggen, maar eerder aan de mail instellingen. Je zou dus eens kunnen kijken naar dat script en daarin debuggen.

[Reptile209]

Heb je ook de charset voor je form ingesteld? Hoewel: die zou niet werken op IE. Welke browser(s) gebruiken je klanten?

[Sebazzz]

Waarschijnlijk verstuurt hij HTML email. En waarschijnlijk wordt niet de juiste charset meegegeven in de header van de email (dat is dus niet de head tag). Of de karakters van de tabel en de email matchen niet dus die moet je laten matchen of converteren.

[Manuel]

Dit doet mij denken aan een oude post van CodeCaster:

CodeCaster schreef op vrijdag 16 april 2010 @ 17:17:
Dit komt gewoon hierop neer: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!).


[...]

Het doet wel wat, het geeft aan in welke karakterset de client de ontvangen data moet weergeven. Zorg gewoon dat de karaktersets overal hetzelfde zijn, van database tot php tot html tot http-headers. Als er op één plek een verkeerde karakterset staat gedefinieerd krijg je dit resultaat.

Ik geef je een tip wat dit betreft, zorg ervoor dat de encoding van de PHP bestanden ook op UTF-8 staan, dit heeft namelijk bij mij ook wel eens voor wat kleine probleempjes gezorgd.

[ViNyL]

Die charset van de pagina staat goed ingesteld. Dit heb ik in Joomla nakeken. Ik kwam ook al een artikel tegen zoals Reptile209 aangeeft.

De mogelijkheid dat het om HTML mail gaat en daardoor niet alles goed wordt doorgegeven is overigens ook nog iets wat ik kan uitzoeken! Het contactform is custom geschreven dus ik moet even uitzoeken hoe dat werkt.

[Verwijderd]

Manuel schreef op maandag 12 juli 2010 @ 19:35:
Dit doet mij denken aan een oude post van CodeCaster:

[...]

Ik geef je een tip wat dit betreft, zorg ervoor dat de encoding van de PHP bestanden ook op UTF-8 staan, dit heeft namelijk bij mij ook wel eens voor wat kleine probleempjes gezorgd.

Inderdaad! Niet alleen PHP (.ini) maar ook je webserver (Apache bijvoorbeeld), enkele jaren hadden we een gelijkaardig probleem en uiteindelijk was de oorzaak onze webserver die stond ingesteld op iso-8859-1 ... ondanks alle geforceerde utf-8 headers / tags etc. die we in onze code hadden toegevoegd

[ViNyL]

Bedankt voor de reacties.

Ik heb alles nagekeken en wat tests gedaan. Binnen mijn eigen webmail/mail clients komt de e-mail wel goed binnen met de tekens.

Het probleem lijkt te zitten in de instellingen van de mail client van de klant.

[Cartman!]

Je moet het ook gewoon niet zoeken in je pagina maar in het script dat je mailtje verstuurt zoals MueR direct al zegt. Bij de grote mailscripts (Zend_Mail, phpMailer) kun je gewoon meegeven wat voor charset je content is en dan regelt het zichzelf.

[Vos]

Ik zit met ditzelfde probleem, maar dan vanuit Wordpress....ga er zo ook naar kijken. Bevindingen post ik wel.

[ViNyL]

Cartman! schreef op woensdag 14 juli 2010 @ 09:53:
Je moet het ook gewoon niet zoeken in je pagina maar in het script dat je mailtje verstuurt zoals MueR direct al zegt. Bij de grote mailscripts (Zend_Mail, phpMailer) kun je gewoon meegeven wat voor charset je content is en dan regelt het zichzelf.

Geef in de header op dat het plain text moet zijn. Het wordt overal goed weergegeven waar ik zo ver gekeken heb. Ik kan de foute tekens ook reproduceren als ik de codering in de mail client verander. Ga eerst dat dus eens nakijken, voor ik nog meer (onnodige) aanpassingen ga doen aan het script zelf.

[Cartman!]

Lees dit eens door zou ik zeggen: http://www.joelonsoftware.com/articles/Unicode.html

[Janoz]

ViNyL schreef op woensdag 14 juli 2010 @ 10:00:
[...]


Geef in de header op dat het plain text moet zijn.

Enkel plain text bestaat natuurlijk niet.

[Raynman]

Plain text (MIME-type text/plain) wil gewoon zeggen dat het niet met HTML opgemaakt is. Encoding/charset kan dan nog van alles zijn. Misschien ontbreekt dat bij de headers en vallen MUA's terug op een standaardwaarde die bij de jouwe toevallig goed is en bij de klant niet, maar dat kun je niet een probleem van de klant of diens software noemen.

[ViNyL]

Raynman schreef op woensdag 14 juli 2010 @ 10:25:
Plain text (MIME-type text/plain) wil gewoon zeggen dat het niet met HTML opgemaakt is. Encoding/charset kan dan nog van alles zijn. Misschien ontbreekt dat bij de headers en vallen MUA's terug op een standaardwaarde die bij de jouwe toevallig goed is en bij de klant niet, maar dat kun je niet een probleem van de klant of diens software noemen.

Binnen de code die het form verstuurd wordt het bericht omgezet naar UTF-8 (php: utf8_encode). De headers zijn ook voorzien van de opgave dat het UTF-8 moet zijn. Vandaar mijn conclusie dat ik het probleem in de eigen mail client van de klant moet zoeken..

[Cartman!]

Maar dat zegt nog steeds niks over hoe je de mail verstuurd, lees je onze reacties wel?

[ViNyL]

Cartman! schreef op woensdag 14 juli 2010 @ 12:21:
Maar dat zegt nog steeds niks over hoe je de mail verstuurd, lees je onze reacties wel?

Ik heb het over de mail headers natuurlijk en niet over de headers van de pagina

[Cartman!]

Maar hoe zet jij die headers dan? En utf8_encode() is (meestal) geen magische functie die je encoding fixt Ik denk dat het handig is dat je relevante code post hoe je die mail verstuurt.

edit: net zeg je dat je opgeeft "plaintext" te versturen en dan hier net boven weer "utf8", ik heb het idee dat je t eigenlijk niet weet. En als je pagina's al UTF8 zijn, waarom gooi je er dan utf8_encode() overheen? Je content is dan toch al UTF8? Volgens mij ontbreekt het aan basiskennis over encodings, heb je die link al gecheckt die ik eerder gaf?

@MueR: die TR heb je snel gelezen!

[ Voor 51% gewijzigd door Cartman! op 14-07-2010 13:26 ]

[MueR]

Goed, ik gooi hem ondertussen even over de schutting naar Programming. Ik zou graag zien dat je wat relevante code post, zoals Cartman! ook al suggereerde.

@Cartman!: Die TR zag ik pas na de move

[ Voor 11% gewijzigd door MueR op 14-07-2010 13:55 ]

[ViNyL]

Cartman! schreef op woensdag 14 juli 2010 @ 13:17:
Maar hoe zet jij die headers dan? En utf8_encode() is (meestal) geen magische functie die je encoding fixt Ik denk dat het handig is dat je relevante code post hoe je die mail verstuurt.

edit: net zeg je dat je opgeeft "plaintext" te versturen en dan hier net boven weer "utf8", ik heb het idee dat je t eigenlijk niet weet. En als je pagina's al UTF8 zijn, waarom gooi je er dan utf8_encode() overheen? Je content is dan toch al UTF8? Volgens mij ontbreekt het aan basiskennis over encodings, heb je die link al gecheckt die ik eerder gaf?

@MueR: die TR heb je snel gelezen!

Ik heb inmiddels een en ander aangepast, plain text stond er in eerste instantie.

Nu gaat het zo de deur uit:

code:

    $headers = "From:".$From."\r\nReply-To: ".$Reply."\r\n" .
        'X-Mailer: PHP/' . phpversion() . "\r\n" .
        "MIME-Version: 1.0\r\n" .
        "Content-Type: text/html; charset=utf-8\r\n";       
    $MailResult = @mail($MailRecipient, $subject, $Message, $headers);

[Cartman!]

En wat als je een gerenomeerde class gebruikt voor sturen van mail zoals Zend_Mail of phpMailer? Die pakken de headers vaak net even wat anders aan waardoor het in meer mailclients werkt. Ook is het belangrijk dat $Message echt utf8 is, dat betekent niet dat je een willekeurige string pakt en er utf8_encode() omheen zet dus. Als een string al utf8 is en je hem nogmaals encode dan gaat ie juist weer stuk.

[ViNyL]

Dan moet ik het form deel van de site volledig opnieuw maken. Wat ik eigenlijk ook liever doe, en dan binnen Joomla (of inderdaad metZend_Mail of phpMailer). De vraag was om naar het formulier te kijken en het probleem om te lossen, maar daar wordt ik zelf ook niet vrolijker van.

Ik gebruik zelf altijd phpMimeMail, en dat werkt zoals je al aangeeft met veel meer mailclients en zonder problemen.

Toch maar eens voorstellen..

[ Voor 7% gewijzigd door ViNyL op 14-07-2010 15:40 ]

[Cartman!]

Hoezo? Je hoeft alleen maar je stukje mail() aan te passen naar het stukje van phpMailer (iets makkelijker met includen dan Zend_Mail) en dan ben je er al. Je denkt veel te moeilijk.

[ViNyL]

Hmm dat is inderdaad waar Thanks, denk dat ik dat inderdaad doe!

[netvor]

ViNyL schreef op maandag 12 juli 2010 @ 19:07:
Berlin ansässigen Händlers mit antiken Uhren soll die Uhr aber erst Anfang des 20

Je krijgt dus ä (karakters U+00C3 en U+00A4) in plaats van ä (U+00E4) te zien. Dit kan komen door, onder andere:

a) De U+00E4 wordt in de mail als UTF-8 verstuurd, oftewel omgezet naar 0xC3 0xA4. Maar de MUA van de klant interpreteert het als ISO-8859-1, oftewel U+00C3 U+00A4.

b) De U+00E4 wordt in PHP aangeleverd als UTF-8 (0xC3 0xA4). Je script gooit hier utf8_encode over heen, wat de 0xC3 dus als U+00C3 interpreteert en er 0xC3 0x83 van maakt. Van de 0xA4 wordt op zijn beurt 0xC2 0xA4 gemaakt. In je mail staat dus 0xC3 0x83 0xC2 0xA4, wat door de UTF-8 codec van de MUA correct wordt geinterpreteerd als U+00C3 U+00A4.

[ViNyL]

netvor schreef op woensdag 14 juli 2010 @ 16:04:
[...]


Je krijgt dus ä (karakters U+00C3 en U+00A4) in plaats van ä (U+00E4) te zien. Dit kan komen door, onder andere:

a) De U+00E4 wordt in de mail als UTF-8 verstuurd, oftewel omgezet naar 0xC3 0xA4. Maar de MUA van de klant interpreteert het als ISO-8859-1, oftewel U+00C3 U+00A4.

b) De U+00E4 wordt in PHP aangeleverd als UTF-8 (0xC3 0xA4). Je script gooit hier utf8_encode over heen, wat de 0xC3 dus als U+00C3 interpreteert en er 0xC3 0x83 van maakt. Van de 0xA4 wordt op zijn beurt 0xC2 0xA4 gemaakt. In je mail staat dus 0xC3 0x83 0xC2 0xA4, wat door de UTF-8 codec van de MUA correct wordt geinterpreteerd als U+00C3 U+00A4.

Utf8_encode heb ik er inmiddels tussenuit gehaald. Dus dan zou het alleen nog een MUA probleem kunnen zijn.

Maakt niet uit, om zeker van mijn zaak te zijn ga ik de afhandeling van het mail gedeelte aanpassen zoals hierboven genoemd.

[netvor]

Het kan ook helpen om de ruwe source van de mail eens te bekijken. Wat zijn precies de byte values die verstuurd worden? Als je dat weet ben je al een stapje verder in het doorgronden van het probleem. Als je Thunderbird gebruikt kan je gewoon je mailarchief in een hexeditor openen, Thunderbird slaat mail op in mbox-formaat.

Maar je kan natuurlijk ook de software omzetten naar een nieuwe mailer, en dan testen of de mails er goed uitzien in Thunderbird/Outlook/Gmail/Hotmail.