Umlaute in Formular

[cuep]

Hallo zusammen,

Habe folgendes Problem.
Ich habe ein Formular, was ein Textarea enthält.
Das Formular funktioniert soweit, nur das alles was mit Umlauten zu tun hat nicht richtig ankommt. Hat wahrscheinlich was mit UTF8 oder iso 8859-1 zu tun, soweit ich schon im I-Net gelesen habe. Leider habe ich keine Lösung gefunden.Zumindestens keine die funktioniert.

So kommen die Sonderzeichen nach abschicken der mail an:

Ä = Ä
ä = ä
Ö = Ö
ö = ö
Ü = Ü
ü = ü

Was kann man da am besten machen?

Gruß

CueP

[David]

Ja, ich sollte mich wirklich auf "so geht's" beschränken und nicht den x.ten Sermon tippen
Andererseits, es gibt so viel, das ich sollte aber nicht tue

[nikosch]

Daher kam mir wohl "Steck soviel Zeit und Arbeit rein in das Gebiet, auf dem Du exzellent sein kannst" so bekannt vor...

[David]

Scho recht.
Aber jetzt habe ich mich schon warm geschrieben beim Thema "Bibliotheken ja|nein"

[Manko10]

Das war auch mehr ironisch gemeint.

[David]

Das hat nichts mit Faulheit zu tun.
Steck soviel Zeit und Arbeit rein in das Gebiet, auf dem Du exzellent sein kannst (oder willst). Aber verschwende keine Zeit auf mittelmäßigen oder schlechten Code - schon garnicht, wenn Du etwas anz anderes erreichen willst(will ich primär email Code schreiben oder Werbung/Passwörter/Benachrichtungen verschicken, zufällig per email). Und sorry, die Mehrheit der String-Concat-Mail-Unlesbar-Skripte ist einfach Schrott, kompletter Schrott. Funktioniert nicht, unwartbar, unerweiterbar, starr, Schrott eben.

[Manko10]

Du bis ja sooooo faul!

[David]

Ja, wie gesagt, kann gut sein. Ich hoffe trotzdem, dass cuep SwiftMailer verwendet und bereits fertig ist und sich nicht um das Hacken von Mails mit Stringfunktionen kümmern muss

[Manko10]

Jap, dort habe ich auch nachgesehen und ebenfalls nichts gefunden. Da diese Header sich eigentlich nicht von ganz normalen HTTP-Headern unterscheiden, würde es mich auch wundern.

[nikosch]

Find da nix zur Order:
RFC 2045 - Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
RFC 2046 - Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types

[Manko10]

Nee, also mit Klassen muss schon sein. Wo kämen wir hin, wenn mail() der einzige Weg wäre?

[David]

Da sage ich in Richting cuep nur: Verwende SwiftMailer und solche Sachen können Dir so egal sein wie sonst nur etwas

Die Begeisterung für eigene Mail-, Template-, String-Klassen (bzw ohne Klassen alles wie ein echter Mann mit dem blanken Eisen coden) konnte ich noch nie nachvollziehen. Ok, bei Parsern und Compilern kann man mich kriegen ....aber das ist ein anderes Thema

[Manko10]

Ich denke, das hat einfach den ordnenden Charakter. Ebenso wie ich meine CSS-Eigenschaften alphabetisch sortiere, steht dort der Header an erster Stelle.
Es würde mich wundern, wenn es hier eine Rolle spielen würde, da Header sonst keine feste Reihenfolge haben.
Aber da ich mir das RFC natürlich nicht Zeile für Zeile durchgelesen habe, kann ich natürlich etwas überlesen haben...
Also mich interessiert es schon in sofern, dass ich nicht gerne auf Dauer solche Sachen falsch mache. Ich käme mir vor wie ein Tabellenlayouter, der fest davon überzeugt ist, das Richtige zu tun.

Wenn ich mir die Mails hier durchsehe, die ich im Postfach habe, sind schon ein paar dabei, die z.B. einen Content-Type-Header vor dem MIME-Version-Header haben (was natürlich noch längst heißt, dass es richtig ist).

[David]

Ich habe mir eben nur mal Mime-Mails von Outlook und Thunderbird im Text-Editor angesehen. Und da steht Mime-Version vor allen anderen Mime-spezifischen Headern. Wenn Du sagst, es geht, glaube ich es und es gibt trotzdem wenig, das mich weniger interessiert - naja, die 10000ste universelle Template-Klasse vielleicht

[Manko10]

David, jetzt musst du mir aber nochmal erklären, warum die Reihenfolge bei Headern eine Rolle spielt.
Soweit ich das sehe, steht in den RFCs nur, dass eine Header MIME-Version mit rein muss, aber nichts über die Reihenfolge.