[Erledigt] Im eigenen Mailer gehen LFs in im Atachment verloren

02.06.2006, 11:42

Hi,

vor einigen Jahren habe ich eine Mailer-Klasse geschrieben. Kann so ziemlich alles. Gestern Nacht wollte ich ein Text-Attachment versenden.
Hm... was ankommt, kann man in Word, Excel und Php-Editor gebrauchen. Im Outlook-Notepad sieht man aber, dass die Datei Ihre Line Feeds "\n"
wohl verloren hat.

Dachte ich zumindest, denn die Datei steht im Notepad praktisch in einer Zeile.

Jetzt wird es aber "lustig": Ich habe mir die Datei 3 x zusenden lassen, getrennt mit "\r\n", nur mit "\n" und nur mit "\r" (per PHP unter Unix erzeugt).
Jetzt verstehe ich es nicht mehr. Denn alle drei Dateien kommen nicht nur in einer Zeile an, sondern können z.B. von Excel dennoch KORREKT angezeigt werden.

Also verschluckt der Mailer wohl doch weder das "\n" noch das "\r"??? Würde es eines davon verlieren, würde wenigstens eine der Dateien
wirklich in Excel als Zeile angezeigt.

Ich versende unter Unix, empfange unter Windows. Hmmmm, damit hat es aber doch nichts zu tun, denn die Routine ist unabhängig.

PHP-Code:

      function createBody()

    {

        if (($this->text and $this->html) or $this->attachment)

        {

            $this->body  = '--OuterBoundary' . "\n";

            $this->body .= 'Content-Type: multipart/alternative; boundary="InnerBoundary"' . "\n\n";

 
            $this->body .= '--InnerBoundary' . "\n";

            $this->body .= 'Content-Type: text/plain; charset="iso-8859-1"' . "\n";

            $this->body .= 'Content-Transfer-Encoding: 8bit' . "\n\n";

            $this->body .= $this->text ."\n";

 
            if ($this->html)

            {

                $this->body .= '--InnerBoundary' . "\n";

                $this->body .= 'Content-Type: text/html; charset="iso-8859-1"' . "\n";

                $this->body .= 'Content-Transfer-Encoding: base64' . "\n\n";

                $this->body .= $this->html ."\n";

            }

 
            $this->body .= '--InnerBoundary--' . "\n";

 
            if ($this->attachment)

            {

                foreach ($this->attachment as $attach => $element)

                {

                    $this->body .= '--OuterBoundary' . "\n";

 
                    $nameA = stringTailFromEnd($attach, $this->base->slash);

                    $typeA = $element['type'];

                    $usedA = $element['used'];

                    $idNoA = $element['idNo'];

 
                    $this->body .= 'Content-Type: ' . $typeA . '; name="' . $nameA . '"' . "\n";

                    $this->body .= 'Content-Transfer-Encoding: base64' . "\n";

                    $this->body .= 'Content-Disposition: attachment; filename="' . $nameA . '"' . "\n";

                    if ($this->type == 'HTML_WITH_INCLUDED_OBJECTS' and $usedA)

                        $this->body .= "Content-ID: impulse_CID" . $idNoA . "\n";

                    $this->body .= "\n";

 
                    if ($file = @fopen($attach, "r"))

                    {

                        $this->body .= chunk_split( base64_encode( fread($file, filesize($attach))))    . "\n";

                        fclose ($file);

                    }

                    else

                        $this->writeErrorMessage('FILE_NOT_FOUND', 'createBody', array($attach));

                }

            }

 
            $this->body .= '--OuterBoundary--' . "\n";

        }

        elseif ($this->html)

            $this->body = $this->html;

        else                                                            // empty or text or attachment

            $this->body = $this->text;

    }

Sollte man etwa text-Attachments anders kodieren.....

Mit Bildern klappte es damals prima.

Zusatz: Type ist übrigens text/plain, what else

02.06.2006, 14:24

Zitat:

Zitat von stani

Jetzt verstehe ich es nicht mehr. Denn alle drei Dateien kommen nicht nur in einer Zeile an, sondern können z.B. von Excel dennoch KORREKT angezeigt werden.

Das klingt danach, als ob die Zeilenumbrüche nur als einfaches LF vorliegen.

Versuche noch einmal eine Datei, die CRLF verwendet (überprüfen!), zu
senden und poste anschließend, wenn es zum gleichen Problem kommt,
den Quelltext des Attachments. Also Folgendes:

PHP-Code:

  <?php

  chunk_split( base64_encode( fread($file, filesize($attach))));

?>

02.06.2006, 14:59

Ja das klingt absolut danach. Sehe ich genauso. Auch wenn es schon deswegen unlogisch ist, weil eine der drei Dateien nur LF gar nicht beinhaltet (beinhalten sollte) sondern nur CR. Ich werde das so machen wie Du vorschlägst und gebe außerdem mal sowohl auf dem Server als auch nach dem Empfang die ORDs für die Zeichen aus (man weiß ja nie). Dann melde ich mich.

02.06.2006, 21:39

Ich habe getestet. Habe die Dateien per php ausgelesen und als ORD ausgegeben (vor und nach dem Empfang). Ergab folgendes:

Hat die Datei auf dem Server ein \r oder ein \n, dann bleibt dieses unverändert erhalten. Hat sie dagegen \r\n hintereinander, dann wird irgendwo das \n (13) rauzsgefiltert, es bleibt das \r (10).

Da Windows wohl beide Zeichen braucht, um eine Zeile umzubrechen, ist nun klar, dass in allen Fällen eine Elenlange zeile ankommt.

Nun poste ich das gecodete File.

Code:

VmlzaXRzCTI0MDUKCgpQaXMJMzM1MTEKCgpVbmlxdWUgVXNlcgkxNjM2CgoKV2FyZW5r9nJiZQkz MjYKCgoKCgo=

Und so sieht der Inhalt vor dem versenden aus (Datei mit jeweils 3 x \r\n):

Code:

Visits	2405


Pis	33511


Unique User	1636


Warenkörbe	326

und danach halt (nur noch die \r sind vorhanden):

Code:

Visits	2405Pis	33511Unique User	1636Warenkörbe	326

Hat es etwa mit dem Format was zu tun und sollte man bei text/plain nicht encoden?

03.06.2006, 15:02

Zitat:

Zitat von stani

PHP-Code:

  VmlzaXRzCTI0MDUKCgpQaXMJMzM1MTEKCgpVbmlxdWUgVXNlcgkxNjM2CgoKV2FyZW5r9nJiZQkz MjYKCgoKCgo=

Der dekodierte String sieht damit folgendermaßen aus:

PHP-Code:

  Visits    2405nnnPis    33511nnn [...]

Hier fehlen also bereits sämtliche CR. Der Fehler liegt also mit ziemlicher
Sicherheit vor oder bei der Kodierung ins Base64-Format. Wobei eigentlich
weder fread() noch base64_encode() schuld sein können. Denn:

Zitat:

Zitat von http://de2.php.net/fread

fread -- Binary-safe file read

Zitat:

Zitat von http://de2.php.net/base64_encode

This encoding is designed to make binary data survive transport [...]

Zitat:

Zitat von stani

Habe die Dateien per php ausgelesen und als ORD ausgegeben (vor und nach dem Empfang).

Das waren exakt die Daten, die bei

PHP-Code:

  <?php

  if ($file = @fopen($attach, "r"))

  {

      $this->body .= chunk_split( base64_encode( fread($file, filesize($attach))))    . "\n";

      fclose ($file);

  } 

?>

vorliegen?

Und wenn Du diese Daten, die mit Sicherheit CRLF verwenden, von
base64_encode() bearbeiten lässt, erhältst Du oben genannten String?

Zitat:

Zitat von stani

PHP-Code:

  VmlzaXR[...]=

Das klingt für mich alles recht merkwürdig.

Denn, wenn Deine obigen Aussagen allesamt zutreffen, kann der Fehler
eigentlich nur bei base64_encode() liegen - und das kann ich mir beim
besten Willen nicht vorstellen.

Zitat:

Zitat von stani

Hat es etwa mit dem Format was zu tun

Sicherlich nicht. Base64 ist ja genau dazu gedacht, die Daten eins-zu-eins
in ihre ursprüngliche Form reproduzierbar zu machen.

Zitat:

Zitat von stani

und sollte man bei text/plain nicht encoden?

Im Normalfall ist das nicht erforderlich, da 8bit-Transfer meist unterstützt
wird. Wenn Kodierung, dann wäre die bessere Alternative zu Base64 an
dieser Stelle wohl Quoted-Printable.

http://de.wikipedia.org/wiki/Quoted-printable

-----
Wie sieht das ganze aus, wenn Du die Daten nicht aus einer Datei liest,
sondern direkt aus einem String übernimmst?

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Mailer Error: Language string failed to load: recipients_fai	Soese	PHP Tipps 2008	9	20.02.2008 16:15
Session Daten gehen verloren	rabatz	PHP Tipps 2007	17	11.02.2007 16:19
Warum geht der Wert verloren?	NetLook	PHP Tipps 2006	4	29.11.2006 20:28
Session geht bei include verloren	argon	PHP Tipps 2006	9	14.09.2006 19:45
session geht verloren	imported_kremser	PHP Tipps 2006	7	15.07.2006 23:36
Mailer Error: Language string failed to load: instantiate	HaraDej	PHP Tipps 2006	3	15.05.2006 13:24
Datei Anhang in Form mailer		PHP Tipps 2006	9	19.01.2006 01:46
session geht verloren	Alpha Centauri	PHP Tipps 2007	6	20.12.2005 12:34
Mailer		PHP Tipps 2005-2	16	09.07.2005 15:33
Array-Werte gehen verloren	Connar	PHP Tipps 2005-2	16	04.06.2005 20:59
Session ID geht verloren. child pid (123) exit signal ... fa		PHP Tipps 2005	11	12.05.2005 09:54
einzelne elemente eines arrays gehn verloren bei "inclu		PHP Tipps 2005	2	16.03.2005 23:32
[Erledigt] Session geht bei Seitenwechsel (Domainwechsel) verloren		PHP-Fortgeschrittene	19	14.03.2005 14:40
session geht verloren	Rotti	PHP Tipps 2005	11	18.01.2005 17:39
username immer behalten (variable $username geht verloren)		PHP Tipps 2004-2	11	07.12.2004 11:25

02.06.2006, 11:42
Gast Beiträge: n/a	[Erledigt] Im eigenen Mailer gehen LFs in im Atachment verloren Hi, vor einigen Jahren habe ich eine Mailer-Klasse geschrieben. Kann so ziemlich alles. Gestern Nacht wollte ich ein Text-Attachment versenden. Hm... was ankommt, kann man in Word, Excel und Php-Editor gebrauchen. Im Outlook-Notepad sieht man aber, dass die Datei Ihre Line Feeds "\n" wohl verloren hat. Dachte ich zumindest, denn die Datei steht im Notepad praktisch in einer Zeile. Jetzt wird es aber "lustig": Ich habe mir die Datei 3 x zusenden lassen, getrennt mit "\r\n", nur mit "\n" und nur mit "\r" (per PHP unter Unix erzeugt). Jetzt verstehe ich es nicht mehr. Denn alle drei Dateien kommen nicht nur in einer Zeile an, sondern können z.B. von Excel dennoch KORREKT angezeigt werden. Also verschluckt der Mailer wohl doch weder das "\n" noch das "\r"??? Würde es eines davon verlieren, würde wenigstens eine der Dateien wirklich in Excel als Zeile angezeigt. Ich versende unter Unix, empfange unter Windows. Hmmmm, damit hat es aber doch nichts zu tun, denn die Routine ist unabhängig. PHP-Code: function createBody() { if (($this->text and $this->html) or $this->attachment) { $this->body = '--OuterBoundary' . "\n"; $this->body .= 'Content-Type: multipart/alternative; boundary="InnerBoundary"' . "\n\n"; $this->body .= '--InnerBoundary' . "\n"; $this->body .= 'Content-Type: text/plain; charset="iso-8859-1"' . "\n"; $this->body .= 'Content-Transfer-Encoding: 8bit' . "\n\n"; $this->body .= $this->text ."\n"; if ($this->html) { $this->body .= '--InnerBoundary' . "\n"; $this->body .= 'Content-Type: text/html; charset="iso-8859-1"' . "\n"; $this->body .= 'Content-Transfer-Encoding: base64' . "\n\n"; $this->body .= $this->html ."\n"; } $this->body .= '--InnerBoundary--' . "\n"; if ($this->attachment) { foreach ($this->attachment as $attach => $element) { $this->body .= '--OuterBoundary' . "\n"; $nameA = stringTailFromEnd($attach, $this->base->slash); $typeA = $element['type']; $usedA = $element['used']; $idNoA = $element['idNo']; $this->body .= 'Content-Type: ' . $typeA . '; name="' . $nameA . '"' . "\n"; $this->body .= 'Content-Transfer-Encoding: base64' . "\n"; $this->body .= 'Content-Disposition: attachment; filename="' . $nameA . '"' . "\n"; if ($this->type == 'HTML_WITH_INCLUDED_OBJECTS' and $usedA) $this->body .= "Content-ID: impulse_CID" . $idNoA . "\n"; $this->body .= "\n"; if ($file = @fopen($attach, "r")) { $this->body .= chunk_split( base64_encode( fread($file, filesize($attach)))) . "\n"; fclose ($file); } else $this->writeErrorMessage('FILE_NOT_FOUND', 'createBody', array($attach)); } } $this->body .= '--OuterBoundary--' . "\n"; } elseif ($this->html) $this->body = $this->html; else // empty or text or attachment $this->body = $this->text; } Sollte man etwa text-Attachments anders kodieren..... Mit Bildern klappte es damals prima. Zusatz: Type ist übrigens text/plain, what else


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

02.06.2006, 14:59
Gast Beiträge: n/a	Ja das klingt absolut danach. Sehe ich genauso. Auch wenn es schon deswegen unlogisch ist, weil eine der drei Dateien nur LF gar nicht beinhaltet (beinhalten sollte) sondern nur CR. Ich werde das so machen wie Du vorschlägst und gebe außerdem mal sowohl auf dem Server als auch nach dem Empfang die ORDs für die Zeichen aus (man weiß ja nie). Dann melde ich mich.

02.06.2006, 21:39
Gast Beiträge: n/a	Ich habe getestet. Habe die Dateien per php ausgelesen und als ORD ausgegeben (vor und nach dem Empfang). Ergab folgendes: Hat die Datei auf dem Server ein \r oder ein \n, dann bleibt dieses unverändert erhalten. Hat sie dagegen \r\n hintereinander, dann wird irgendwo das \n (13) rauzsgefiltert, es bleibt das \r (10). Da Windows wohl beide Zeichen braucht, um eine Zeile umzubrechen, ist nun klar, dass in allen Fällen eine Elenlange zeile ankommt. Nun poste ich das gecodete File. Code: VmlzaXRzCTI0MDUKCgpQaXMJMzM1MTEKCgpVbmlxdWUgVXNlcgkxNjM2CgoKV2FyZW5r9nJiZQkz MjYKCgoKCgo= Und so sieht der Inhalt vor dem versenden aus (Datei mit jeweils 3 x \r\n): Code: Visits 2405 Pis 33511 Unique User 1636 Warenkörbe 326 und danach halt (nur noch die \r sind vorhanden): Code: Visits 2405Pis 33511Unique User 1636Warenkörbe 326 Hat es etwa mit dem Format was zu tun und sollte man bei text/plain nicht encoden?