J'ai un très long fichier texte que j'essaie de traiter avec python.
Cependant, le code suivant: p> ne produit que la sortie suivante: P> $ file textbase.txt
textbase.txt: Big-endian UTF-16 Unicode English text, with CR line terminators
4 Réponses :
Vous trouverez probablement que c'est le "avec les terminaisons de ligne CR" qui donne au jeu. Si vous travaillez sur une plate-forme qui utilise de nouvelles lignes en tant que terminateurs de ligne, il va voir votre fichier comme une grande ligne de Honkin '
Changez votre fichier d'entrée afin qu'il utilise les terminateurs de ligne appropriés. Votre éditeur est probablement plus indulgent que votre implémentation de Python.
Les terminaisons de la ligne CR sont une chose mac aussi loin que je suis au courant et vous pouvez utiliser le modificateur de mode u sur Ouvrir pour détecter automatiquement en fonction du premier Terminateur de ligne trouvé.
Nail + Head Combo Me pense. +1.
Merci. Avez-vous une idée de ce que je dois les changer?
pourrait soit être CR + LF (Windows) ou LF (mais cela serait sur des macs plus anciens).
@Adriano: CR est le terminateur de ligne pour les Mac plus anciens. C'est la LF pour tous les systèmes * Nix.
@Tzootzioy: Je n'aurais pas dû faire cette erreur. Temps de sac en papier brun.
ouvert () code> renvoie un objet de fichier. Vous devez utiliser: for line in open('textbase.txt', 'r').readlines():
print line
Ce n'est pas nécessaire, car l'objet de fichier ouvert se comporte comme un itérateur.
Selon le Documentation pour ceci active " nouvelles lignes universelles ", qui les normalise à Cependant, le La bonne chose à faire est de décoder l'UTF-16BE dans des objets Unicode premier , avant de traduire les nouvelles lignes. Sinon, une chance UnicodedecodeError: le codec 'utf16' ne peut pas décoder octet 0x0a en position 12: données tronquées.
si le fichier comporte une marque d'ordre d'octet (BOM) et vous spécifiez Spécifier l'endansité vous-même (avec Voir aussi: Ouvrir () , vous devez ajouter un fournit un u au mode: \ n dans les chaînes qu'il vous donne. 0x0d octet pourrait être transformée à tort à tort dans un 0x0a , résultant
codecs module Ouvrir la fonction pouvant décoder unicode et gérer les nouvelles lignes en même temps: 'UTF-16' , puis il détecte l'endoignesse et masque la naissance pour vous. Si ce n'est pas le cas (puisque la nomenclature est facultatif), ce décodeur va simplement aller de l'avant et utiliser l'endansion de votre système, ce qui ne sera probablement pas bon. ' utf-16be ') ne cachera pas la nomenclature, de sorte que vous souhaiterez peut-être utiliser ce piratage:
+1 pour la solution plutôt que juste l'analyse (comme dans ma réponse) - vous étiez trop rapide pour moi :-)
Résout le problème, Python voit maintenant toutes les lignes. Merci beaucoup: j'adore ce site :)
@ AP257: Est-ce qu'ils décodent également correctement? Si c'est vraiment utf-16be, il y aura une octet zéro devant toutes les lignes, puisque l'objet de fichier de Python est codé - ignorant et divise simplement sur les caractèresWLINE. IMHO, vous devrez décoder le fichier (en utilisant le module CODECS) correctement avant que la fractionnement dans des lignes soit possible.
@Ttorsten Depuis que nous utilisons Big Endian, les NuLs viennent avant les nouvelles lignes. Un point de code ne sera pas haché en deux. C'est un bon point cependant. bugs.python.org/issue691291
@JleeDev: Droite, mon mauvais. J'ai confondu les fichiers de test dans mes expériences.
@Ttorsten merci pour le conseil de toute façon; J'ai mis à jour cela pour utiliser le module CODECS.
@JleeDev: Bienvenue. La source de ma confusion était que recodé (l'outil) par défaut crée UTF-16BE (bien sûr, y compris la norme) lorsque je spécifie UTF-16 (avec commande) comme cible. Je pensais que cela créerait tout ce qui est l'endansement de la plate-forme (Le, car il est X86-64).
On dirait que votre fichier a des lignes terminées uniquement par CR, et Python s'attend probablement à la LF ou à la CRLF. Essayez d'utiliser la "nouvelle ligne universelle": http://docs.python.org/library/fonctions.html?highlight=OPEN#OPEN
@Op, où vient textbase.txt? les fenêtres? Essayez de faire un DOS2UNIX dans le fichier et voyez qu'il résout le problème
@jlduPont: Je pense que AP257 s'attendait à imprimer "Hello World" pour chaque ligne du fichier d'entrée, comme le code indique :-)
C'est une boucle pour un fichier avec de nombreuses lignes :)
Voir aussi: codinghorror.com/blog/archives/001319.html