Fichier texte avec 0D 0D 0A sauts de ligne
Un client m'envoie un fichier .csv dans lequel les sauts de ligne sont constitués de la séquence 0xD 0xD 0xA. Autant que je sache, les sauts de ligne sont soit 0xA de Mac ou Unix, soit 0xD 0xA de Windows.
Le 0xD 0xD 0xA est-il un encodage connu? Existe-t-il une séquence d'économies connue qui corrompt les fins de ligne d'un fichier et qui provoque cela (je pense que le client utilise un Mac)?
Le fichier ne commence par aucun marqueur de codage, il commence directement par le contenu du texte. Le texte s’affiche correctement s’il est ouvert avec la page de code 1252.
Le CRCRLF est connu comme le résultat d'un bogue wrap Word de Windows XP .
Pour référence future, voici un extrait de la pertinence du blog lié:
Lorsque vous appuyez sur la touche Entrée sur les ordinateurs Windows, deux caractères sont réellement stockés: un retour chariot (CR) et un saut de ligne (LF). Le système d'exploitation interprète toujours la séquence de caractères CR LF de la même manière que la touche Entrée: elle passe à la ligne suivante. Cependant, quand il y a des caractères CR ou LF supplémentaires, cela peut parfois poser problème.
La version Windows XP du Bloc-notes présente un bogue qui peut entraîner le stockage de caractères CR supplémentaires dans la fenêtre d'affichage. Le bogue survient dans la situation suivante:
Si l'option Retour à la ligne est activée et que la fenêtre d'affichage contient des lignes longues qui le retournent, le Bloc-notes insérant les caractères CR CR LF à chaque point de retour dans la fenêtre fichier enregistré.
Les caractères CR CR LF peuvent causer des anomalies si vous les copiez et les collez dans d'autres programmes. Ils empêchent également le Bloc-notes de reformater correctement les lignes si vous redimensionnez la fenêtre du Bloc-notes.
Vous pouvez supprimer les caractères CR CR LF en désactivant la fonctionnalité d'habillage de Word, puis en l'activant si vous le souhaitez. Cependant, le curseur est repositionné au début de la fenêtre d'affichage.
Les fichiers encodés en ANSI Netscape utilisent 0D 0D 0A pour leurs sauts de ligne.
Apple Mail est également connu pour commettre une erreur d’encodage sur le texte et les pièces jointes csv sortantes. Essentiellement, il remplace les fins de ligne par des sauts de ligne souples sur chaque ligne, ce qui ressemble à = 0D dans le codage. Si la pièce jointe est envoyée par courrier électronique à Outlook, Outlook voit les sauts de ligne souples, supprime le = puis ajoute les sauts de ligne réels, à savoir 0D0A, de sorte que vous obtenez 0D0D0A (cr cr lf) à la fin de chaque ligne. Le codage doit être = 0D = s’il s’agit d’un fichier de format Mac (ou de toute autre version d’unix) ou = 0D0A = s’il s’agit d’un fichier de format Windows.
Si vous envoyez un courrier électronique à partir de courrier Apple (au moins en mavericks ou en yosemite), le remplacement de la pièce jointe par un fichier texte ou csv constitue une solution de contournement acceptable, par exemple. le compresser.
Le bogue existe également si vous exécutez Windows VM sous parallèles et envoyez par courrier électronique un fichier txt à partir de celui-ci en utilisant le courrier Apple. C'est l'encodage du courrier électronique. Formulez les commentaires précédents ici, il semble que netscape ait le même problème.
Cela provient généralement d'un bogue dans le système de contrôle de révision, ou similaire. C'était un produit de CVS, si un fichier était archivé de Windows sur un serveur Unix, puis extrait à nouveau ...
En d'autres termes, il est juste cassé ...
Juste en disant, c'est aussi la valeur (genre de ...) qui est renvoyée par php sur
<?php var_dump(urlencode(PHP_EOL)); ?>
// Prints: string '%0D%0A' (length=6)-- used in 5.4.24 at least