Problème de sauts de ligne dans un fichier CSV
Les utilisateurs de la fusion de données ont tous rencontré un jour ce problème : une « cellule » contient un saut de ligne ( Ex: adresse sur deux lignes ) et lors de la fusion de données dans InDesign, rien ne se passe comme prévu ! Des informations apparaissent au mauvais endroit, d’autres sont carrément absentes. Et pourtant tout est bien là dans votre tableur. Un simple retour à la ligne a suffi en effet à corrompre l’interprétation des données du fichier CSV/TXT par InDesign. Petite cause, grandes conséquences.
Quel est le problème au juste ?
Imaginons un tableau comme ci-dessus. Pour le champ « adresse », nous avons trois lignes séparées par deux retours chariots. Nous disposons sommairement quelques balises pour l’exemple :
Mais lorsque nous demandons l’aperçu, notre « belle » maquette explose.
Le champ « société » n’apparaît pas dans InDesign. Pire encore, sur la deuxième entrée, ça devient n’importe quoi :
Pour la plupart d’entre vous, il faut bien admettre que j’enfonce une porte ouverte. Mais au delà du constat, laissez-moi juste vous expliquer le pourquoi du comment. InDesign nous fait de la tambouille car les sauts de ligne contenus dans une cellule sont interprétés en fait comme le passage à une nouvelle ligne d’enregistrement. La chaine en regard du saut devient de facto la première donnée du premier champ.
La fausse bonne idée
Nous pensions avoir trouvé la solution à ce problème avec un algorithme aux petits oignons. En soi, l’axiome était des plus simples : déterminer le nombre de colonnes et s’assurer que chaque ligne compte bien le nombre de cellules cohérent quite à fusionner des lignes et remplacer temporairement ces retours chariots par une chaine de caractère unique. Il serait toujours temps de changer à nouveau cette chaine dans InDesign a posteriori pour retrouver les sauts de ligne comme attendu.
Dans le cas présenté ci-dessus, la première ligne de données ne comporte que deux « cellules » alors qu’il devrait y en avoir trois. On fusionne donc les lignes 1 et 2 pour obtenir une ligne de trois cellules. C’est le concept de base. Alors que les premiers tests étaient très concluants, il nous a fallu nous rendre à l’évidence. Cette cuisine ne pouvait tout simplement pas marcher pour tous les cas. En effet, en fonction de la disposition des données, il devenait impossible de recomposer les lignes à bon escient.
Soit la bloc de donnée en rouge, doit-on considérer qu’il fait partie du bloc de donnée orange ou bien qu’il constitue une donnée à part. Impossible à dire !!
Conclusion
Il semble donc impossible de prendre en charge la gestion des sauts de lignes dans un fichier CSV/TXT car il y aura toujours un cas où seul l’humain pourra déterminer le sens à donner à telle ou telle information. C’est la raison pour laquelle InDesign ne les prends pas en charge et c’est probablement le cas pour toues les éditeurs qui travaillent avec ce format. Nous ne ferons pas hélas exception à cette règle.
Que vous restent-ils donc à faire ? Si vous souhaitez rester en fusion de données, vous serez amenés à remplacer les sauts de ligne à la source ( Fichier Excel ou autre ) et vous assurer ainsi que les seuls retours chariots ne disent effectivement rien d’autre qu’un passage vers un nouvel enregistrement. Vous pouvez utiliser une chaine de caractères très spécifiques comme ##RC## ou toute autre motif dont vous aurez la certitude de ne pas les retrouver dans vos données.
Une autre solution consisterait à privilégier le format XML qui lui est capable d’interpréter des retours chariots dans une donnée. Si vous utilisez une autre astuce, faîtes-en nous part.
Loic
Je me suis heurté au même problème avec Acrobat et l’importation de données dans un PDF via JavaScript.
Parce-que par nature dans un fichier CSV le saut de ligne délimite le changement de rangée… et c’est la zone…
Ce phénomène est aussi ancien que connu, alors dans un « bon » CSV, en plus de la tabulation, les données sont généralement délimitées par des guillemets (ou autre en option), et si le CSV n’est pas « bon » il suffit de les rajouter.
Ce qui permet de distinguer les « changements de rangées » des « sauts de ligne dans le texte des données » si on prend lesdits guillemets en compte.
Et si on prend aussi en compte la proximité récurrente « guillemet-tab-guillemet » ça permet d’éviter les interférences avec les guillemets éventuellement contenus dans les données.
Le fait que je m’en soit tiré tout seul avec un peu de logique et mes maigres connaissances en JavaScript me conduit à penser que les ingénieurs de InDesign ne se sont pas vraiment penchés sur la question…
:-)))
Si un JavaScripteur pour InDesign souhaite adapter mon JavaScript pour Acrobat qu’il me contacte, je le partagerais avec plaisir.
🙂