Gérer les fichiers Excel CSV avec Python

Le paquet csv de Python est très utile. Il effectue correctement le processus d'échappement gênant. Particulièrement utile pour traiter les fichiers envoyés sous forme de fichiers Excel. Après tout, vous pouvez lire correctement Excel CSV avec dialect = 'excel'.

Cependant, lorsque le japonais est impliqué, le problème devient rapidement gênant. Quelle est l'essence du problème? Tout d'abord, ce qui suit est connu concernant la gestion de TSV dans Excel.

• L'exportation Excel tsv est utf-16 (avec nomenclature) --Excel peut lire directement tsv de utf-16 avec BOM (séparer entre les virgules nécessite un assistant) --csv (séparés par des virgules) peut être affiché et lu, mais n'est pas recommandé (décrit plus loin)

Ce que vous pouvez voir, c'est qu'il est préférable de travailler avec des fichiers utf-16 avec BOM. La meilleure façon de gérer cela est d'utiliser le paquet ʻio`.

with io.open(path, encoding='utf-16') as f:
  ...

Je l'ai écrit brièvement, mais il est vraiment important d'utiliser le paquet ʻio. utf-16 est un format assez peu maniable. Tout d'abord, il y a BOM. De plus, si cr + lf est exécuté dans cet état, \ 0sera inséré en unités d'octets. Donc, si vous utilisez normalement ʻopen (), cela se comporte comme un mystère.

Maintenant, le problème se pose ici. Lors de l'utilisation de la série python2, le paquet csv ne prend pas en charge ʻunicode`. Par conséquent, il ne peut pas être lu s'il est ouvert par la méthode ci-dessus. Ici, si vous utilisez «open» par beau temps, il sera difficile à lire pour les raisons ci-dessus. J'avais l'habitude d'exporter avec csv de shift-jis, mais Excel semble être Unicode en interne, et parfois le point trouble est un caractère différent et il est dans un état non normalisé, à ce moment shift-jis Quand je l'ai sorti, tous les points troubles ont disparu. Je ne recommande donc pas cette méthode non plus.

En fait, comment lire Unicode avec csv est décrit dans Fin du manuel. La bonne réponse est d'encoder une fois le flux ʻunicode dans utf-8, de le lire avec le paquet csv dans cet état, de le diviser et de décoder à nouveau utf-8. La même chose est vraie lors de l'écriture, changez simplement ʻunicode en utf-8, écrivez dans StringIO et convertissez-le à nouveau en ʻunicodejuste avant de le cracher dans un fichier. C'était extrêmement gênant deux fois, mais j'ai eu du mal avec Excel pendant de nombreuses années et j'ai finalement obtenu la sortie la plus stable. Au fait, en Python3, le paquetcsv supporte str (ʻunicode en 2), donc vous pouvez l'ouvrir avec ʻio` et le traiter normalement.

Ce serait sombre si j'écrivais ces processus à chaque fois, alors j'en ai fait une bibliothèque.

https://github.com/unnonouno/excelcsv

Cela évite peut-être tous les problèmes ci-dessus.

Ce que tu ne devrais pas faire

C'est tout, mais passons en revue ce que vous ne devriez pas faire et pourquoi.

Encode avec utf-16 pour chaque élément

.encode ('utf-16') produit une chaîne utf-16 avec BOM. C'est la différence décisive par rapport aux autres encodages.

>>> u'a'.encode('utf-16')
'\xff\xfea\x00'

Si vous écrivez un code comme [x.encode ('utf-16') for x in row], une chaîne de caractères mystérieuse avec une nomenclature sera générée. Cette approche est inutile. La nomenclature ne doit être incluse qu'au début du fichier. La meilleure façon d'éviter cela est de le gérer avec ʻunicode en principe et de le contrôler dans la partie sortie du fichier. C'est le paquet ʻio qui fait cela, et vous ne devriez pas l'encoder vous-même en utilisant le "open". Une autre solution de contournement est de sortir vers StringIO avec utf-8, de convertir le tout en ʻunicode avant d'écrire dans le fichier, puis de le reconvertir en utf-16. Cependant, il est plus propre d'utiliser ʻio.

Ouvrir avec ouvrir, analyser puis décoder

utf-16 signifie que le caractère de saut de ligne et le caractère de tabulation que vous voulez analyser sont également écrits sur 2 octets. Si vous laissez le package Python2 csv, qui traite par unités de 1 octet, le traiter, les caractères \ 0 inutiles resteront. Cette approche ne peut être utilisée qu'avec utf-8 et shift-jis, qui conservent les caractères Ascii.

Exporter puis charger avec shift-jis csv

Excel semble avoir les données en Unicode en interne. Pire encore, la turbidité peut être enregistrée en tant que caractère distinct, et si vous exportez avec shift-jis dans cet état, toute la turbidité disparaîtra. J'aimerais pouvoir le normaliser. Par conséquent, l'exportation depuis Excel est un choix de texte utf-16. C'est difficile à gérer, mais on ne peut rien y faire.