Discussion :

[thierryler]

Le format CSV est, aujourd'hui encore, largement utilisé. Il fait le bonheur des équipes de développement car il est simple à manipuler. La lecture d'un fichier au format CSV demande toutefois un certain nombre de compétences.

Je propose ici un article qui aborde les points clés à maîtriser, pas à pas avec une difficulté progressive, pour savoir traiter le célèbre CSV. Il y aurait beaucoup de choses à ajouter, notamment à propos des fichiers volumineux, mais l'essentiel est là pour bien commencer.

L'article se trouve à l'adresse suivante : http://thierry-leriche-dessirier.dev...csv-avec-java/

Tous les commentaires, surtout ceux qui disent du bien et m'encouragent (lol), sont les bienvenus.

Bonne lecture.

[Jidefix]

Bonjour,
je n'ai pas été jusqu'en bas, mais ai été surpris de voir que Excel ne modifiait pas les fichiers .csv.
Là où je travaille nous avons justement eu pas mal de problème avec des fichiers CSV ouverts avec Excel (2000 et 2003), où apparaissent subitement des guillemets autour des champs, où les dates changent de format, où des 0 deviennent des 0.0...
Je ne sais pas ce qu'il en est d'Excel 2007 et 2010 mais il me semble important de le mentionner!

[thierryler]

Effectivement je n'ai pas testé sur les vieilles versions d'Excel. Les captures ont été faites sur 2010. Du coup ma remarque sur Open office est peut-être également valable pour Excel 2003.

[tvibes]

Merci pour ce tuto complet sur les CSV.

Il est vrai que ces fichiers sont plus légers que des fichiers XML mais selon moi ils sont infiniment plus compliqués du fait de l'absence de règles. Prendre en compte tous les cas se révèle complexe comme le montre votre tutorial finalement (16 paragraphes quand même).
Au moins avec le XML il y a les DTD ou les XSD qui permettent de vérifier l'intégrité du fichier avant la lecture.

Toutes les applications proposent des export CSV mais jamais sous la même forme (séparateur duifférents, pas de protections, ...) et au final c'est pénible à intégrer. Combien d'imports plantent en plein milieu parce que notre parseur de fichier CSV ne prend pas tout en charge?

Enfin, je trouve dommage que la notion d'encodage des caractères ne soit pas évoquée bien que la problématique soit plus large que la lecture de fichiers CSV. C'est très souvent une source de problèmes.
Le code proposé n'est donc pas 100% portable (NB: je n'ai pas téléchargé le .zip) puisque les classes "bas niveau" utilisées pour lire le fichier vont s'appuyer sur l'encodage par défaut de la JVM. En tout cas j'espère que vos élèves sont sensibilisés, sinon j'imagine bien leur déconvenue lorsqu'ils reprendront vos sources pour lire un fichier CSV encodé en UTF-8, sous Windows...

[thierryler]

Effectivement l'article pourrait encore traiter un grand nombre de choses. Quand j'ai réalisé qu'il y avait autant de pages, j'ai reporté ces ajouts pour une prochaine version. J'avoue toutefois que je n'avais pas pensé à l'encoding.

Le format CSV possède un avantage sur le XML, c'est son poids. En effet, lorsqu'il y a des millions de lignes, ça fait une grosse différence. Dans tous les cas, avec les fichiers volumineux, on utilise des techniques qui ne sont pas présentées dans l'article.

[_skip]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public static List<String> readFile(File file) {
 
        List<String> result = new ArrayList<String>();
 
        FileReader fr = new FileReader(file);
        BufferedReader br = new BufferedReader(fr);
 
        for (String line = br.readLine(); line != null; line = br.readLine()) {
            result.add(line);
        }
 
        br.close();
        fr.close();
 
        return result;
}

La méthode close() d'un stream ou d'un reader appelle automatiquement les méthods close() de ses enfants, conformément au pattern decorator. Donc vous ne devriez pas faire fr.close() car la ressource est déjà fermée et suivant les implémentations, vous pourriez vous manger une IOException.

Par ailleurs votre boucle peut s'écrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
while( (String line = br.readLine()) != null ) 
{
   ...
}

Je lirai plus en détails ce soir ou demain.

Il est vrai que ces fichiers sont plus légers que des fichiers XML mais selon moi ils sont infiniment plus compliqués du fait de l'absence de règles. Prendre en compte tous les cas se révèle complexe comme le montre votre tutorial finalement (16 paragraphes quand même).
Au moins avec le XML il y a les DTD ou les XSD qui permettent de vérifier l'intégrité du fichier avant la lecture.

C'est mitigé...
La validation XSD est très coûteuse et bien souvent, elle ne permettra pas de se passer d'une validation métier "a mano". Et lire un gros fichier XML (de l'ordre des 500mo-1GB) est infiniment plus complexe que lire un gros fichier CSV.

Toutes les applications proposent des export CSV mais jamais sous la même forme (séparateur duifférents, pas de protections, ...) et au final c'est pénible à intégrer. Combien d'imports plantent en plein milieu parce que notre parseur de fichier CSV ne prend pas tout en charge?

Je suis moyennement d'accord. CSV souffre de l'absence de spécification claire mais il est admis que les tokens sont séparés par des virgules, peuvent ou non être entourés de guillemets et qu'un dédoublement de guillemets sert d'échappement.
Si vous intégrez ces règles, votre parseur peut facilement gérer 98% des sorties générées par d'autres produits.