Qui saut de ligne dans php-tête du message, \r\n ou \n?

J'ai vu beaucoup d'exemples à l'aide de la fonction mail de php. Certains d'entre eux d'utilisation \r\n saut de ligne pour l'en-tête, certains, \n.

$headers = "From: Just Me\n"; 
$headers .= "Reply-To:  Just me <$email>\n";

vs

$headers = "From: Just Me\r\n";
$headers .= "Reply-To:  Just me <$email>\r\n";

laquelle est la bonne?

J'ai parfois eu des cas où les \r\n permet et une partie de l'en-tête est interprété par certains clients de messagerie de messagerie texte (le fait de perdre ces informations d'en-tête) - est-ce parce que \r\n est le problème?

InformationsquelleAutor Sam | 2010-12-11
  1. 22

    Le CRLF \r\n, doit être utilisé selon la la documentation php. Aussi, pour se conformer à la RFC 2822 spec lignes doivent être délimités par le caractère de retour chariot, CR \r immédiatement suivie par la ligne d'alimentation, LF \n.

    Depuis \r\n est natif pour les plates-formes Windows et \n sous Unix, vous pouvez utiliser le PHP_EOLDocs constante sur Windows, ce qui est le propre caractère de nouvelle ligne pour la plate-forme le script est actuellement en cours d'exécution sur.

    • Oups! Édité. Merci pour ça 🙂
    • Je me demande pourquoi certains clients de messagerie interpréter \r\n comme deux sauts de ligne (thunderbird semble être parmi eux).
    • Malheureusement, je ne suis pas entièrement sûr. S'il vous plaît laissez-moi savoir si vous aurez une réponse.
    • J'ai fait une question de ce problème, peut-être que quelqu'un connaît la réponse.
    • Cette réponse n'est pas vraiment logique: si le document php et le Rfc demande spécifiquement l'utilisation de \r\n, à l'aide de la constante PHP_EOL sera certainement violent que sur tous les non-MS-Windows plates-formes. Pourquoi devrait-on l'utiliser? Utiliser le littéral \r\n et tout est très bien.
    • Je remarque que lors de l'utilisation de \r\n dans le php $headers argument pour la fonction mail (4ème argument), mon local MTA (postfix via sendmail) est la conversion \n \r\n. La résultante e-mail envoyé contient alors \r\r\n qui vis les en-têtes sur certains clients. Peut-être la raison pour utiliser PHP_EOL est parce que le MTA attend natif de la ligne de délimiteurs de sendmail. Que fera alors de sens que sur un système unix, il serait nécessaire de convertir les \n \r\n compatible avec le RFC.

    InformationsquelleAutor Russell Dias
  2. 11

    Juste au cas où un moteur de recherche capte et enregistre quelqu'un d'autre la frustration, je suis allé à travers: voici un supplémentaire de curiosité.

    Sur php 5.2 x sur Linux, j'ai eu \r\n sur mes e-mails dans mail () de php, après une mise à jour de php 5.3.3, la mise en forme et l'envoi mystérieusement échoué. Retrait de la \r fixe le script (après examen de beaucoup de beaucoup d'autres possibilités).

    • je viens de tombé sur ce problème, résolu par le remplacement de la CRLF avec de simples retours à la ligne
    • C'est dans la mesure où ils permettent de convertir \n dans \r\n ainsi, lorsque vous utilisez \r\n, la sortie sera \r\r\n
    InformationsquelleAutor Chuck
  3. 8

    Comme indiqué ci-dessus, \r\n que vous devriez utiliser selon la RFC, mais cela rompt avec vos en-têtes sur plusieurs systèmes de messagerie (f.j'. Outlook 2003). Même si le \n n'est pas le " bon " saut de ligne à utiliser, dans mon expérience, il fonctionne correctement sur tous les systèmes de messagerie que j'ai rencontré jusqu'à présent. De ce fait, j'ai toujours utiliser seulement \n.

    • Une liste de clients de messagerie sur lequel les \n par elle-même provoque des en-têtes d'être mal interprété serait utile. Il semble que de rares et insensé est le client de messagerie programmeur qui permettrait d'utiliser le caractère \n dans le cadre d'un e-mail de l'en-tête valeur, depuis la RFC interdit explicitement: "le corps d'Un champ peut être composé de caractères US-ASCII, sauf pour le CR et LF." (Section 2.2). Le comportement du client quand il y a un \n par lui-même avant que les deux retours à la ligne qui termine les en-têtes n'est pas défini, donc, en utilisant \n comme une valeur d'en-tête de terminator est plus sensible qu'à la suite de la RFC.
    InformationsquelleAutor Daniel
  4. 3

    La RFC officiellement mandats CRLF (\r\n) mais en utilisant Unix pauses (\n) pour les en-têtes, vous fera économiser un tas de tracas. Certains serveurs de messagerie, tels que qmail, rejetteront votre message si il utilise \r\n.

    Source: expérience, confirmée par cette remarque: http://www.php.net/function.mail#40204

    • c'est effectivement ce que devrait être la accepté de répondre, à mon humble avis.
    • En fait, la raison pourquoi tout le monde dit que \r\n ne fonctionne pas et \n fonctionne est parce qu'ils sont dans un environnement unix, l'envoi de mail en local. Ce n'est pas le même que l'envoi d'un e-mail directement à un serveur de messagerie SMTP.
    InformationsquelleAutor Scott C
  5. 2

    Mon expérience:
    Les e-mails HTML travaillaient dans les clients web, mais la rupture en MS en fonction de clients de bureau (entourage, outlook). A l'aide de \r\n. Retiré de la \r sur le MIME-Version et travaille aujourd'hui à travers le conseil d'administration.

    InformationsquelleAutor Baker
  6. 1

    J'ai eu le problème de gmail malentendu \r\n-têtes de, mais en les laissant simplement l'en-tête des sauts de ligne à \n était pas assez dans mon cas, parce que dans ce cas, certaines versions d'Outlook ont montré des e-mails comme du vide.

    La solution dans https://stackoverflow.com/a/7960957 (j'ai choisi d'installer postfix 2.9 lucide d'un ppa) couplé avec l'aide de \n semble fonctionner un peu partout maintenant.

    InformationsquelleAutor raquo
  7. 1

    J'ai modifié mon script pour l'utiliser PHP_EOL à la place qui semble fonctionner -- comme ceci:

    //Set Content-type header
$headers  = "MIME-Version: 1.0" . PHP_EOL;
$headers .= "Content-type: text/html; charset=iso-8859-1" . PHP_EOL;
//Additional headers
$headers .= "From: $from" . PHP_EOL;
$headers .= "Cc: $cc"   . PHP_EOL;      
$headers .= "Content-type: text/html" . PHP_EOL;
$headers .= "Bcc: $bcc" . PHP_EOL;

    NB. Assurez-vous de nous "au lieu de" que ce dernier ne semble pas fonctionner!

    InformationsquelleAutor Kee