Outils de développement · Convertisseurs de syntaxe
CSV : ce que couvre la RFC 4180 et ce qu'elle laisse ouvert
· Contexte
csv json formats de données
CSV est antérieur à toute spécification, et la RFC qui la décrit est informative et délibérément étroite. Cet article explique ce que définit la RFC 4180, ce sur quoi elle ne dit rien et pourquoi la conversion de CSV est donc toujours une négociation.
De qui CSV est correct ? — deux exports de la même table, un avec des points-virgules et un avec des virgules, tous deux appelés CSV
ToolAcre peut émettre une sortie délimitée par des virgules, des points-virgules ou des tabulations à partir de JSON. Il ne lit pas deux exportations CSV concurrentes et ne déclare ni l'une ni l'autre correcte. CSV est ici en écriture seule, le choix du délimiteur est donc une option de sortie explicite plutôt qu'un algorithme de détection.
Cette distinction évite une erreur factuelle courante. Une interface capable d'écrire des points-virgules n'a pas prouvé qu'elle pouvait identifier les points-virgules dans un fichier inconnu, gérer les décimales locales ou interpréter les en-têtes. Ce sont des responsabilités d’entrée distinctes délibérément exclues.
Deux choix de délimiteurs sont des options de sortie, et non une preuve que ce panneau lit l'un ou l'autre fichier.
Le référentiel ne contient aucune source pour les premiers feuilles de calcul ou l'historique des bases de données, donc l'article n'invente pas de chronologie. Cela commence par le rédacteur actuel et ses tests : enregistrements, champs, délimiteurs, terminaison CRLF et échappement de guillemets.
Le contexte historique peut être ajouté ultérieurement avec des sources révisées. L'implémentation d'un convertisseur est une preuve de ce que le produit écrit aujourd'hui, et non de la date d'apparition d'une convention ou de la raison pour laquelle les fournisseurs ont divergé.
CSV historique avant RFC 4180 est une preuve extérieure au référentiel
Un champ contenant le délimiteur, les guillemets doubles, le retour chariot ou le saut de ligne est entouré de guillemets doubles et chaque guillemet intégré est doublé. Les espaces de début ou de fin sont également cités pour empêcher le découpage courant des feuilles de calcul. Les enregistrements se terminent par CRLF et le fichier est terminé.
Ces comportements suivent les règles de style RFC 4180 testées dans le référentiel. L'article évite de revendiquer une conformité universelle car l'auteur prend également en charge des délimiteurs alternatifs et ajoute une gestion de la sécurité en dehors de la grammaire étroite.
L'auteur utilise les citations de style RFC 4180 et CRLF sans revendiquer une conformité totale aux normes. Les cellules
CSV ne conservent pas les types JSON. Les chaînes nulles et vides deviennent toutes deux des cellules vides, tandis que les booléens et les nombres deviennent des représentations textuelles. Le contenu UTF-8 est transmis et une nomenclature facultative peut être préfixée pour les consommateurs qui en ont besoin.
L'interprétation des paramètres régionaux n'est pas intégrée. Un délimiteur point-virgule peut coexister avec des virgules décimales, mais l'écrivain ne reformate pas les nombres par paramètres régionaux ni n'encode un type de date. L'application réceptrice décide toujours comment interpréter chaque champ.
Les limites d'encodage, de type et de paramètres régionaux restent explicites dans cet écrivain
Les variantes implémentées sont la virgule, le point-virgule et la tabulation, plus une nomenclature facultative. Le texte de type formule commençant par `=`, `+`, `-`, `@`, une tabulation ou un retour chariot est préfixé par une apostrophe par défaut afin que les feuilles de calcul le traitent comme du texte. Les utilisateurs peuvent désactiver cette protection et recevoir un avertissement.
Il n'y a pas d'indice `sep=` ni de mode d'échappement avec barre oblique inverse dans cet écrivain. Les mentionner comme options expédiées serait faux. Les guillemets intégrés utilisent le doublement, exactement comme l'affirment les tests.
Les variations observées dans la feuille de calcul sont limitées aux options et protections mises en œuvre ici
Chaque hypothèse de cette route commence à partir de JSON analysé : quelle valeur fournit les lignes, comment l'imbrication s'aplatit en colonnes en pointillés et quelles clés deviennent des en-têtes. Aucune hypothèse n'est faite concernant un dialecte CSV entrant car le CSV entrant est rejeté.
Cette correction inverse la direction demandée du classeur. Un flux de travail CSV-to-JSON doit choisir les types de délimiteur, de guillemets, d'en-tête et de cellule dans un autre outil. L’erreur de ToolAcre explique ce refus plutôt que de deviner tranquillement.
Les hypothèses de conversion s'appliquent à JSON-to-CSV uniquement parce que l'entrée CSV est refusée.
La réparation de CSV mal formé n'est pas couverte par le champ d'application. Les guillemets brisés, les encodages mixtes et les délimiteurs accidentels nécessitent le CSV Cleaner ou un autre analyseur avec des diagnostics explicites. Le convertisseur de syntaxe reçoit un texte JSON strict et non endommagé CSV.
La sortie peut toujours ne pas convenir à une cible lorsqu'une arborescence imbriquée crée des colonnes en pointillés ambiguës ou dépasse 2,000 colonnes. Les avertissements et les majuscules exposent ces échecs en forme de tableau avant le téléchargement.
À retenir : CSV est une convention, pas un format - et comment le panneau des convertisseurs de syntaxe transforme un fichier bien formé en JSON que vous pouvez inspecter
Traitez CSV comme une convention dont les choix doivent être visibles. ToolAcre documente ses choix de sortie et refuse l'inverse sous-spécifié. C'est plus fiable que d'utiliser un seul bouton pour deux tâches fondamentalement différentes.
Inspectez le délimiteur, les guillemets, le CRLF, la nomenclature et la formule qui s'échappent du système de réception. Si une analyse des entrées est requise, utilisez un outil qui demande au lieu de transférer les conventions de l'auteur sur un fichier inconnu.
Un contrôle d'acceptation pratique ouvre le fichier généré dans le consommateur prévu et examine également les octets bruts ou le texte. Le point de vue du consommateur détecte les problèmes d'affichage et d'importation ; la vue brute confirme le délimiteur, les guillemets doublés, le CRLF et une nomenclature facultative sans réinterprétation de la feuille de calcul. Testez les chaînes de type formule sous forme de texte inerte et un nombre négatif sous forme de nombre. Ces vérifications appariées vérifient le contrat réel de l’auteur sans prétendre que chaque programme implémente les conventions CSV de manière identique.