Les principaux formats de fichiers de données et de configuration

Lorsque vous devez passer des données de configuration à une application, il existe de nombreux formats de fichiers disponibles, certains plus connus que d'autres.

Il n'existe pas de format parfait, le but est toujours d'avoir un format à la fois complet, très lisible et facile à prendre en main, mais les spécificités de chaque écosystème font que chacun d'eux est pertinent.

L'objectif de cet article est de vous faire découvrir et de vous familiariser avec des formats que vous ne connaissez pas forcément, c'est pour le même jeu de données sera utilisé comme exemple à chaque fois.

Format INI

C'est un format majoritairement fait de paires clé-valeur mais avec la possibilité de séparer ces dernières par des sections. Il est principalement utilisé dans l'environnement de Microsoft (sous l'extension .ini), mais une grosse partie des fichiers de configuration sur Linux est représentée par un format clé-valeur simplifié.

;List of all endpoints

[request]
id=request
protocol=https 
domain=example.com
uri=/request, 
description="Request enpoint"

[search]
id=search
protocol=https 
domain=google.com
uri=/search, 
description="Search enpoint"

Le format INI est particulier car en comparaison des autres formats présents dans cette liste, c'est le seul à être "informel" car il n'est pas défini par une spécification stricte.

Format CSV

Le format CSV est un format conçu à l'origine pour représenter des tableaux en deux dimensions, beaucoup utilisé pour exporter des données présentes dans des feuilles de tableurs (type Excel).

Ce format est très simple et son nom explicite (comma-separated values) décrit très bien son fonctionnement. Les commentaires ne sont pas prévus pour figurer dans un fichire CSV, uniquement des valeurs, et des virgules !

id, protocol, domain, uri, description
request, https, example.com, /request, Request endpoint
search, https, google.com, /search, Search enpoint

Format XML

Ce format est très présent dans l'écosystème Java, mais aussi dans le web (de moins en moins). Si XML est verbeux, il a l'avantage d'être très explicite, et surtout c'est le seul format qui prévoit dans sa spécification une technologie de validation de la structure du fichier avec DTD !

<?xml version="1.0" encoding="UTF-8" ?>
<!-- List of all endpoints -->
<endpoints>
	<endpoint id="request">
    	<protocol>https</protocol>
        <domain>example.com</domain>
        <uri>/request</uri>
        <description>Request endpoint</description>
    </endpoint>
    <endpoint id="search">
    	<protocol>https</protocol>
        <domain>google.com</domain>
        <uri>/search</uri>
        <description>Search endpoint</description>
    </endpoint>
</endpoints>

Format JSON

Si vous avez fait du Javascript, alors vous savez ce qu'est le format JSON. En réalité appelé "JavaScript Object Notation" il est utilisé dans tout l'écosystème Javascript, NodeJS et prend de plus en plus de place dans le web en général.

[{
    "id": "request",
    "protocol": "https", 
    "domain":"example.com"
    "uri":"/request", 
    "description":"Request enpoint"
},
{
    "id":"search",
    "protocol":"https" 
    "domain":"google.com"
    "uri":"/search", 
    "description":"Search enpoint"
}]

Le format JSON est aussi utilisé par certaines bases de données NoSQL pour stocker les données et construire les requêtes, c'est le cas avec MongoDB par exemple.

Format YAML

Le YAML (dont le nom est un acronyme récursif pour "YAML Ain't Markup Language") est un format mettant en opposition la simplicité de lecture avec une certaine complexité d'écriture dû aux nombreux types de données, à l'indentation par espace obligatoire, etc...

Les types données et de structures ajoutés à YAML 1.2 en fait notamment un "sur-ensemble" (superset) de JSON avec l'arrivée des listes "[...]" et des maps "{...}", il est donc possible de décrire des architectures de données complexes.

---# List of all endpoints

- request:
    protocol: https
    domain: example.com
    uri: /request 
    description: Request enpoint 
- search:
    protocol: https
    domain: google.com
    uri: /search
    description: Search enpoint
    

Format TOML

Ce format, un acronyme pour "Tom's Obvious, Minimal Language" est un nouvel arrivant (il existe depuis 2013, mais la version 1.0 date de Janvier 2021) et combine les bons côtés de plusieurs des formats cités ci-dessus.

Pour l'instant les utilisations de ce format reste assez peu nombreuses mais il est par exemple utilisé pour la configuration de l'outil Cargo, le gestionnaire de paquets de Rust.

#List of all endpoints

[endpoints]
    [endpoint.request]
        protocol="https" 
        domain="example.com"
        uri="/request", 
        description="Request enpoint"

    [endpoint.search]
        protocol=https 
        domain=google.com
        uri=/search, 
        description="Search enpoint"

TOML propose une structure complexe mais lisible et facilement éditable, possède des commentaires, de l'indentation mais facultative, et reste implémentable beaucoup plus facilement que YAML étant donné sa spécification plus légère.