Zitat:
Zitat von de-maebinger
Das ist der Code der zuständig ist, dass die Mail verschickt wird und die Daten rauskommen und wo der Fehler stecken muss.
|
Der ist fehlerhaft und dürftig.
Zitat:
zu 1. Ist das relevant dafür wie die Daten in der Mail ankommen?
|
Grundsätzlich: mail basiert auf 7bit US-ASCII. Im Header sind alle non-US-ASCII-Zeichen verboten und müssen deshalb codiert werden.
Zitat:
Ist es dafür relevant das nicht alles übertragen wird?
|
Ich habe absolut keine Ahnung, was Du wie verschickst und was fehlt.
Zitat:
Ich kann es noch einfügen, bezweifele aber das es aufgrund dessen dann funktioniert. Ich würde "charset=utf-8" nutzen
|
Egal, was Du würdest. Auch der Body muß beim Transfer aus 7bit US-ASCII bestehen. Genutzt wird da als content-transfer encoding normalerweise base64 oder quoted printable. Das muß der phpmailer wissen, weil sonst die Mail in nem gut sortiertem SPAM Filter in die Tonne getreten wird.
Zitat:
zu 3. $treffer['colum'] ist als Varchar
$treffer['wert_vorher'] und $treffer['wert_nachher'] haben beide Text als Collation.
|
Da verstehste mich miß. Klar sind Texte Texte und keine Ziffern.
Ich will wissen, wie die varchars gespeichert wurden, weil Du sie mit utf8_decode() behandelst. Das:
Zitat:
utf8_decode(utf8_decode($treffer['wert_nachher']))
|
ist Blödsinn. Ich frage deshalb, weil ich bezüglich von Formulardaten und SQL Daten schon Pferde kotzen gesehen habe.
Zitat:
Die Daten kommen ja korrekt an, werden aber in der Mail nach x Zeichen abgeschnitten, darum glaube ich auch hier das es nicht relevant ist.
|
Ich kann nicht hellsehen, weil ich nicht weiß, wie die Daten aussehen, die Du zusammenhäkelst.
In Deinem Script tummeln sich Umlaute, htmlentities und nach ISO-8859-1 konvertierte Strings, die (KA, obs stimmt) mit charset UTF-8 aufschlagen. Da Du (wie Du weiter untenschreibst) den Kram höchstwahrscheinlich mit xampp verwurstest, besteht zusätzlich noch die Gefahr, daß vielleicht noch "Windowsumlaute" den Kohl fett machen.
Zitat:
zu 4. bei beiden utf-8 und text/plain
|
text/plain ist bei US-ASCII - a-zA-Z0-9 und die paar Sonder- und Satzzeichen - umkompliziert. Taucht in header und body ein lausiger Umlaut auf, fängt die Arbeit an.
Verwende als content transfer encoding base64 oder quoted printable. Damit kommen zumindest alle mir bekannten Emailprogrämmelchen klar. Bei 8bit u/o UTF-8 habe so meine Zweifel.
Zitat:
zu 5. ??? auf was genau spielst du an?
|
Verwendest Du LF oder CRLF?
Zitat:
zu 6. war Absicht. Muss ja nicht wissen an wen ich die Mail schicken möchte.
|
Das Format stimmt nicht:
PHP-Code:
public function AddAddress($address, $name = '')
Adresse ohne Username ist pfui.
Zitat:
zu 7 und 8. Ich nutze keinen SMTP, weil ich nur innerhalb der Firma die Mail versenden möchte und da geht alles über den Mercury und dann zum Exchange.
|
Mercury kenne ich nicht genau und weiß nicht, wie das Teil dann reagiert, wenn in der Mail am Zeilenanfang ein Punkt steht. So wird eigentlich das Ende der mail gekennzeichnet.
Da mußte durch. HTML ist ein Standard, an den man sich halten sollte, wenn man keine Fehler haben möchte. Komplettiere das HTML einfach so, daß es HTML ist. Ohne DOCTYPE, <head> und content="text/html; charset=ISO-8859-1" könnte der Emailreader auf stur schalten und HTML 3.20 annehmen.
Folgende Fehlerquellen sind denkbar: irgend wo produzierst Du irgend ein "nicht druckbares" Zeichen, welches eventuell als Stringende interpretiert wird. Möglicherweise stirbt das Script hier
utf8_decode(utf8_decode())
oder produziert ungewollt Unfug. Steht eventuell im error_log was drin?
Oder Mercury frißt die Mail nicht komplett.
Zitat:
Ich habe nicht behauptet das ich es kann...
|
Dann würdest Du nicht fragen. Ich tippere ja deshalb, weil Du phpmailer verwendest und Dich damit schon wohltuend von der "plain-mail()" Fraktion unterscheidest.