Quel encodage ouvre correctement les fichiers CSV avec Excel sur Mac et Windows?
Nous avons une application Web qui exporte des fichiers CSV contenant des caractères étrangers avec UTF-8, sans nomenclature. Les utilisateurs Windows et Mac obtiennent des caractères incohérents dans Excel. J'ai essayé de convertir en UTF-8 avec BOM; Excel/Win va très bien, Excel/Mac montre du charabia. J'utilise Excel 2003/Win, Excel 2011/Mac. Voici tous les encodages que j'ai essayés:
Encoding BOM Win Mac
-------- --- ---------------------------- ------------
utf-8 -- scrambled scrambled
utf-8 BOM WORKS scrambled
utf-16 -- file not recognized file not recognized
utf-16 BOM file not recognized Chinese gibberish
utf-16LE -- file not recognized file not recognized
utf-16LE BOM characters OK, same as Win
row data all in first field
Le meilleur est UTF-16LE avec nomenclature, mais le fichier CSV n’est pas reconnu en tant que tel. Le séparateur de champ est une virgule, mais le point-virgule ne change rien.
Y at-il un encodage qui fonctionne dans les deux mondes?
La vérité est: il n'y a pas de solution. Excel 2011/Mac ne peut pas interpréter correctement un fichier CSV contenant des signes de majuscules et des signes diacritiques, quel que soit le codage ou le saut de boucle que vous effectuez. Je serais heureux d'entendre quelqu'un me dire différent!
Encodages Excel
J'ai trouvé que le codage WINDOWS-1252 était le moins frustrant pour Excel. Comme son jeu de caractères propriétaire appartient en gros à Microsoft, on peut supposer que cela fonctionnera à la fois sur la version Mac et Windows de MS-Excel. Les deux versions incluent au moins un sélecteur "File Origin" ou "File encoding" correspondant qui lit correctement les données.
Selon votre système et les outils que vous utilisez, cet encodage peut également être nommé CP1252, ANSI, Windows (ANSI), MS-ANSI ou simplement Windows, entre autres variations.
Cet encodage est un sur-ensemble de ISO-8859-1 (alias LATIN1 et autres), de sorte que vous pouvez revenir à ISO-8859-1 si vous ne pouvez pas utiliser WINDOWS-1252 pour une raison quelconque. Sachez que ISO-8859-1 ne contient pas certains caractères de WINDOWS-1252, comme indiqué ci-dessous:
| Char | ANSI | Unicode | ANSI Hex | Unicode Hex | HTML entity | Unicode Name | Unicode Range |
| € | 128 | 8364 | 0x80 | U+20AC | € | euro sign | Currency Symbols |
| ‚ | 130 | 8218 | 0x82 | U+201A | ‚ | single low-9 quotation mark | General Punctuation |
| ƒ | 131 | 402 | 0x83 | U+0192 | ƒ | Latin small letter f with hook | Latin Extended-B |
| „ | 132 | 8222 | 0x84 | U+201E | „ | double low-9 quotation mark | General Punctuation |
| … | 133 | 8230 | 0x85 | U+2026 | … | horizontal Ellipsis | General Punctuation |
| † | 134 | 8224 | 0x86 | U+2020 | † | dagger | General Punctuation |
| ‡ | 135 | 8225 | 0x87 | U+2021 | ‡ | double dagger | General Punctuation |
| ˆ | 136 | 710 | 0x88 | U+02C6 | ˆ | modifier letter circumflex accent | Spacing Modifier Letters |
| ‰ | 137 | 8240 | 0x89 | U+2030 | ‰ | per mille sign | General Punctuation |
| Š | 138 | 352 | 0x8A | U+0160 | Š | Latin capital letter S with caron | Latin Extended-A |
| ‹ | 139 | 8249 | 0x8B | U+2039 | ‹ | single left-pointing angle quotation mark | General Punctuation |
| Π| 140 | 338 | 0x8C | U+0152 | Π| Latin capital ligature OE | Latin Extended-A |
| Ž | 142 | 381 | 0x8E | U+017D | | Latin capital letter Z with caron | Latin Extended-A |
| ‘ | 145 | 8216 | 0x91 | U+2018 | ‘ | left single quotation mark | General Punctuation |
| ’ | 146 | 8217 | 0x92 | U+2019 | ’ | right single quotation mark | General Punctuation |
| “ | 147 | 8220 | 0x93 | U+201C | “ | left double quotation mark | General Punctuation |
| ” | 148 | 8221 | 0x94 | U+201D | ” | right double quotation mark | General Punctuation |
| • | 149 | 8226 | 0x95 | U+2022 | • | bullet | General Punctuation |
| – | 150 | 8211 | 0x96 | U+2013 | – | en dash | General Punctuation |
| — | 151 | 8212 | 0x97 | U+2014 | — | em dash | General Punctuation |
| ˜ | 152 | 732 | 0x98 | U+02DC | ˜ | small tilde | Spacing Modifier Letters |
| ™ | 153 | 8482 | 0x99 | U+2122 | ™ | trade mark sign | Letterlike Symbols |
| š | 154 | 353 | 0x9A | U+0161 | š | Latin small letter s with caron | Latin Extended-A |
| › | 155 | 8250 | 0x9B | U+203A | › | single right-pointing angle quotation mark | General Punctuation |
| œ | 156 | 339 | 0x9C | U+0153 | œ | Latin small ligature oe | Latin Extended-A |
| ž | 158 | 382 | 0x9E | U+017E | | Latin small letter z with caron | Latin Extended-A |
| Ÿ | 159 | 376 | 0x9F | U+0178 | Ÿ | Latin capital letter Y with diaeresis | Latin Extended-A |
Notez que le signe en euro est manquant . Ce tableau peut être trouvé à Alan Wood .
Conversion
La conversion se fait différemment selon les outils et les langues. Cependant, supposons que vous ayez un fichier query_result.csv dont vous savez qu'il est UTF-8 codé. Convertissez-le en WINDOWS-1252 en utilisant iconv:
iconv -f UTF-8 -t WINDOWS-1252 query_result.csv > query_result-win.csv
Pour UTF-16LE avec nomenclature si vous utilisez des caractères de tabulation comme délimiteurs au lieu de virgules, Excel reconnaîtra les champs. Cela fonctionne parce qu'Excel finit par utiliser son analyseur Unicode * .txt.
Caveat: Si le fichier est édité dans Excel et enregistré, il sera enregistré au format ASCII délimité par des tabulations. Le problème, c’est que lorsque vous rouvrez le fichier, Excel suppose qu’il s’agit d’un fichier CSV réel (avec des virgules), que ce n’est pas du format Unicode.
Mise à jour: La mise en garde ci-dessus ne semble pas se produire aujourd'hui dans Excel 2010 (Windows) au moins, bien qu'il semble y avoir une différence dans le comportement d'enregistrement lorsque:
- vous éditez et quittez Excel (tente de sauvegarder en tant que 'Unicode * .txt')
par rapport à:
- édition et fermeture seulement le fichier (fonctionne comme prévu).
Vous avez uniquement essayé des fichiers CSV séparés par des virgules et des points-virgules. Si vous aviez essayé le format de fichier CSV (aussi appelé TSV), vous auriez trouvé la réponse:
TF-16LE avec BOM (marque d'ordre des octets), séparé par des tabulations
Mais: Dans un commentaire, vous mentionnez que TSV n'est pas une option pour vous (je n'ai toutefois pas trouvé cette exigence dans votre question). C'est dommage. Cela signifie souvent que vous autorisez l'édition manuelle des fichiers TSV, ce qui n'est probablement pas une bonne idée. La vérification visuelle des fichiers TSV n'est pas un problème. De plus, les éditeurs peuvent être configurés pour afficher un caractère spécial pour marquer les onglets.
Et oui, j'ai essayé ceci sous Windows et Mac.
La meilleure solution de contournement pour lire des fichiers CSV avec UTF-8 sur Mac consiste à les convertir au format XLSX. J'ai trouvé un script créé par Konrad Foerstner, que j'ai amélioré un peu en ajoutant la prise en charge de différents caractères de délimitation.
Téléchargez le script depuis Github https://github.com/brablc/clit/blob/master/csv2xlsx.py . Pour l'exécuter, vous devez installer un module python openpyxl pour la manipulation de fichiers Excel: Sudo easy_install openpyxl.
Voici le clincher sur l'importation de fichiers CSV codés en utf8 dans Excel 2011 pour Mac: Microsoft: "Excel pour Mac ne prend actuellement pas en charge le format UTF-8". Excel pour Mac 2011 et UTF-8
Oui, comment aller MS!
Il me semble qu'Excel 2011 pour Mac OS n'utilise pas Encoding.GetEncoding ("10000") comme je le pensais et a perdu 2 jours avec mais la même iso que sur Microsoft OS. La meilleure preuve en est de créer un fichier dans Excel 2011 pour MAC avec des caractères spéciaux, de l'enregistrer au format CSV, puis de l'ouvrir dans un éditeur de texte MAC. Les caractères sont brouillés.
Pour moi, cette approche a fonctionné - ce qui signifie que l'exportation CSV sur Excel 2011 sous MAC OS contient des caractères spéciaux d'europe occidentale:
Encoding isoMacOS = Encoding.GetEncoding("iso-8859-1");
Encoding defaultEncoding = Encoding.Default;
// Convert the string into a byte array.
byte[] defaultEncodingBytes = defaultEncoding.GetBytes(exportText);
// Perform the conversion from one encoding to the other.
byte[] ansiBytes = Encoding.Convert(defaultEncoding, isoMacOS, defaultEncodingBytes);
decodedString = isoMacOS.GetString(ansiBytes);
UTF-8 sans nomenclature fonctionne actuellement avec Excel Mac 2011 14.3.2.
Type de travail UTF-8 + BOM, mais BOM rendu sous forme de charabia.
UTF-16 fonctionne si vous importez le fichier et terminez l'assistant, mais pas si vous double-cliquez dessus.
Dans mon cas, cela a fonctionné (Mac, Excel 2011, caractères cyrilliques et latins avec diacritiques tchèques):
- Jeu de caractères UTF-16LE (simplement, UTF-16 ne suffisait pas)
- BOM "\ xFF\xFE"
- \ t (tab) comme séparateur
- N'oubliez pas de coder également les séparateurs et les CRLF :-)
- Utilisez iconv au lieu de mb_convert_encoding
Ce qui suit a fonctionné pour moi sur Excel pour Mac 2011 et Windows Excel 2002:
A l'aide de iconv sur Mac, convertissez le fichier en UTF-16 Little-Endian + nommez-le * .txt (l'extension .txt oblige Excel à exécuter l'Assistant Importation de texte):
iconv -f UTF-8 -t UTF-16LE filename.csv >filename_UTF-16LE.csv.txtOuvrez le fichier dans Excel et dans Importation de texte Wizard choisissez:
- Étape 1: Origine du fichier: ignorez-le, peu importe ce que vous choisissez
- Étape 2: sélectionnez les valeurs appropriées pour délimiteurs et qualificateur de texte
- Étape 3: si nécessaire, sélectionnez les formats de colonne
PS L’UTF-16LE créé par iconv a au début des octets de nomenclature FF FE.
PPS Mon fichier csv d'origine a été créé sur un ordinateur Windows 7, au format UTF-8 (avec les octets de nomenclature EF BB BF au début) et utilisait des sauts de ligne CRLF. La virgule a été utilisée en tant que délimiteur de champ et guillemets simples en tant que qualificateur de texte. Il contenait ASCII lettres plus différentes lettres latines avec tildes, trémas, etc., ainsi que du cyrillique. Tout s'affiche correctement dans Excel pour Windows et Mac.
Versions du logiciel PPPS Exact:
* Mac OS X 10.6.8
* Excel pour Mac 2011 v.14.1.3
* Windows Server 2003 SP2
* Windows Excel 2002 v.10.2701.2625
Sur mon Mac OS, Text Wrangler a identifié un fichier CSV créé avec Excel comme ayant un codage "Western".
Après quelques recherches sur Google, j'ai créé ce petit script (je ne suis pas sûr de la disponibilité de Windows, peut-être avec Cygwin ?):
$ cat /usr/local/bin/utf8.sh
#!/bin/bash
INPUTFILE="$1"
iconv -f macroman -c -t UTF-8 $INPUTFILE |tr '\r' '\n' >/tmp/file.$$.csv
mv $INPUTFILE ms_trash
mv /tmp/file.$$.csv $INPUTFILE
Dans mon cas, ajouter Préambule au fichier a résolu mon problème:
var data = Encoding.UTF8.GetBytes(csv);
var result = Encoding.UTF8.GetPreamble().Concat(data).ToArray();
return File(new MemoryStream(result), "application/octet-stream", "data.csv");
Ça marche pour moi
- Ouvrez le fichier dans BBEdit ou TextWrangler *.
- Définissez le fichier en tant que Unicode (UTF-16 Little-Endian) (les fins de ligne peuvent être Unix ou Windows). Sauver!
- Dans Excel: Données> Obtenir des données externes> Importer un fichier texte ...
Maintenant le point clé, choisissez Macintosh comme origine du fichier (ce devrait être le premier choix).
Ceci utilise Excel 2011 (version 14.4.2)
* Il y a un petit menu déroulant au bas de la fenêtre
au lieu de csv, essayez de sortir du code HTML avec une extension XLS et un type mime "application/Excel". Je sais que cela fonctionnera sous Windows, mais je ne peux pas parler pour MacOS
Résolvez ceci en utilisant Java (UTF-16LE avec BOM):
String csvReportStr = getCsvReport();
byte[] data = Charset.forName("UTF-16LE").encode(csvReportStr)
.put(0, (byte) 0xFF)
.put(1, (byte) 0xFE)
.array();
Notez que le fichier CSV doit utiliser TAB comme séparateur. Vous pouvez lire le fichier CSV sous Windows et MAC OS X.
Voir: Comment encoder/décoder des tableaux d'octets UTF-16LE avec une nomenclature?