UTF8 und Probleme mit der Ausgabe?

J

Japs

Angesehenes Mitglied
Hallo,

ich habe ein Onlienportal, wo ich die DB, Die Felder der DB & die Ausgabe der Webseite jetzt alles auf UTF8 gestellt habe - das war vorher nicht der Fall, da war die DB auf UTF8, die Felder der DB auf ISO und die Ausgabe der Webseite auch auf ISO. Jetzt hab ich alles auf UTF8 umgestellt, wie gesagt auch die einzellen Felder - wie es ja auch normalerweise richtig sein soll DB, Felder der DB & Ausgabe der Webseite auf UTF8.

Problem ist auch halt jetzt, dass ich bei automatisch generierten E-Mails, welche Daten aus der DB wiedergeben - diese Daten jetzt auch in der E-Mail so drinn stehen: Dänemark anstatt Dänemark.

Ich müsste praktisch bei der Ausgabe wieder von Dänemark in Dänemark umwandeln, bei E-Mails etc. welche Daten aus der DB verwenden, aber wie kann ich das umsetzen ?

Danke & Gruß Dirk
 
QUOTE ch müsste praktisch bei der Ausgabe wieder von Dänemark in Dänemark umwandeln, bei E-Mails etc. welche Daten aus der DB verwenden, aber wie kann ich das umsetzen ?


in PHP mit utf8_decode()

Alternativ kannst du im Emailheader den Zeichensatz mitteilen


CODE mail($empfaenger, $betreff, $nachricht, "From: " $absender . "\r\n" . "Content-Type: text/plain; charset=utf-8");
 
QUOTE (Jörg Kruse @ Mo 20.07.2009, 11:17)
Alternativ kannst du im Emailheader den Zeichensatz mitteilen

mail($empfaenger, $betreff, $nachricht, "From: " $absender . "\r\n" . "Content-Type: text/plain; charset=utf-8");




Danke - ich hab die zweite Möglichkeit gewählt, da ich mich mit " utf8_decode()" echt schwer tue :)
Klappt jetzt super ! Danke!

Gruß Dirk
 
Hallo,
nachdem ich alles auf UTF8 bei einer bestehenden DB mit Einträgen umgestellt habe - Eintragen & Ausgeben der Daten speziel mit Umlauten klappt super, ahbe ich aber ein Problem mit den "alten Daten":

Die alten Daten werden jetzt zb. so ausgegeben: "größten" oder "Österreich - Tirol"
Gibt es eine Möglichkeit alle alten Einträge in der DB auf einmal in UTF8 zu konvertieren ?

Ich habe es schon so probiert:
in der DB die betreffenden Spalten, welche generell auf "varchar" standen mal mit "BINARY (VARBINARY)" gespeichert und dann wieder zurück mit CHAR (VARCHAR) - aber eine Änderun konnte ich nicht feststellen ?

Danke & Gruß Dirk
 
Wenn die alten Daten noch im richtigen Charset vorhanden sind und nicht total zerschossen sind, geht das ganz einfach so.

QUOTE UPDATE TABELLENNAME SET SPALTENNAME=CONVERT(SPALTENNAME USING utf8)


Vorher aber unbedingt ein Backup machen oder erst mit Testdatensätzen probieren.
 
Na ja ich hab ja quasi zwei Datenbanken - die alte und die neue, da kann ich ja immerweider auf die alten Daten zurückgreifen
smile.gif


Aber wohl mal noch eine blöde Frage - wo gebe ich das ein ?
QUOTE UPDATE TABELLENNAME SET SPALTENNAME=CONVERT(SPALTENNAME USING utf8)


Kenne mich leider mit sowas absolut nicht wirklich aus
smile.gif

Danke & Gruß Dirk

 
Danke - Problem gelöst!!!!

Kommischerweise gings einfacher, wie ich dachte - hab die betreffenden Tabelln aus der alten DB nochmasl in die neue DB imprtiert und dabei UTF8 angegeben und jetzt werdend iese korrekt wieder im neuem Portal wieder ausgegeben
smile.gif


Danke & Gruß Dirk
 
Hallo,

habe auch das Problem das alle Formulardaten die per E-Mail gesendet werden
mit falschen Umlauten ankommen.

Im Wordpress habe ich als Zeichensatz UTF-8 voreingestellt. Muss ich dort einfach
einen anderen Zeichensatz angeben z.B. ISO. Oder auf den einzelnen Seiten
das "form" tag erweitern. Bisher sehen Form tags auf meinen Seiten so aus.

<form action="/cgi-bin/auswertung.pl" method="post">

Gruß

Mike
 
Hallo,

QUOTE (Nanuma @ Sa 1.08.2009, 21:18) Die mail(); Funktion sollte man _NICHT_ produktiv einsetzen. Es gibt da jede menge lustige Injections. Verwende lieber PHP-Mailer...

mich würde mal eine Quelle interessieren. Ich hoffe es sind nicht nur reine benutzertechische Injections.


MfG Sascha
 
Klar mein ich die Injections, würd mich interessieren, ob das ein PEBKAC ist, oder wirklich Exploits in PHP sind. Bisher würde ich eher auf PEBKAC tippen.
 
mail() filtert keine unerwünschten Umbrüche in den Header-Angaben, also muss man sich selber drum kümmern. Ich würde das auch nicht als Exploit einstufen, man darf halt nicht erwarten, dass einem solche Funktionen alles abnehmen.

Gut, ich hätte in meinem Beispiel vielleicht noch darauf hinweisen können, dass die Variablen vorher entsprechend gefiltert werden müssen, wenn sie von außen kommen.
 
QUOTE Die mail(); Funktion sollte man _NICHT_ produktiv einsetzen.

wink.gif
Sicher soll man die Funktion produktiv einsetzen.
Wenn Du Deine Variablen nicht im Griff hast, darfst Du mit dieser Argumentation auch keine DB nutzen, weil unescaped die bösen Keime rein können....
Klar ist das pebkac. Wenn man eine Funktion nutzt, sollte man sich die Variablen anschauen die als Parameter übergeben wird... Its not a bug, its a feature...

Es ist allerdings richtig, dass viele unerfahrene Programmierer aus Ihrem Server eine Spamschleuder gemacht haben, weil sie die Parameter von mail() nicht im Detail studiert haben... Da kann mail() aber nix für. Der Hund überlebt die Microwelle auch nicht. Da kann die Microwelle auch nichts für...
wink.gif
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben