100 % local — vos données ne quittent jamais votre navigateur

JSON en Kotlin — des data classes à coller

Transformez un échantillon JSON en data classes Kotlin. Les noms restent ceux du JSON, entre accents graves là où le langage l’exige, prêts à compiler.

Instantané Privé Zéro cookie

Entrée JSON

Sortie Kotlin

Ce que fait cet outil

Un échantillon JSON devient des data class Kotlin, une par objet.

{ "id": 1, "firstName": "Ada", "address": { "city": "Paris" } }
data class Root(
    val id: Long,
    val firstName: String,
    val address: Address,
)

data class Address(
    val city: String,
)

Chaque propriété est un val : une charge décodée est une valeur. Les data class vous donnent equals, hashCode, toString et copy() — cette dernière est la façon de changer un champ sans rien muter.

La clé reste la clé

Les identifiants Kotlin s’écrivent entre accents graves, et cela suffit à garder une clé JSON telle quelle :

data class Root(
    val `content-type`: String,
    val `class`: Long,
    val `2fa`: Boolean,
)

class est un mot-clé, content-type porte un tiret, 2fa commence par un chiffre — rien de tout cela ne compte entre accents graves. Avec kotlinx.serialization, le nom de la propriété est le nom JSON : cela se décode tel quel, sans la moindre annotation.

Avec Jackson ou Moshi, le nom de la propriété est aussi ce qu’ils cherchent : les noms entre accents graves y fonctionnent également. Ce n’est que si vous décidez de renommer une propriété — contentType plutôt que `content-type` — qu’il vous faut @JsonProperty("content-type") ou @Json(name = "content-type") pour repointer vers la clé.

Les types, et le ? qui n’est pas là

  • Les entiers deviennent Long et les décimaux Double, ce qu’un nombre JSON peut porter sans discussion.
  • null et les valeurs inconnues deviennent Any? — le seul endroit où un point d’interrogation apparaît, parce que c’est le seul où l’échantillon en montrait un.
  • Un tableau vide ou mêlé devient List<Any>.

Rien d’autre n’est nullable et rien n’a de valeur par défaut. Un champ parfois absent est un ? et un = null que vous ajoutez, une fois qu’une seconde charge vous a dit ce que celle-ci ne pouvait pas.

Deux clés, deux propriétés

Deux clés qui entreraient en collision comme noms de propriétés sont tenues séparées plutôt que fondues : la seconde reçoit un suffixe numéroté. Comme le nom entre accents graves est le nom JSON, les collisions sont rares ici : elles n’arrivent que lorsqu’une réparation est inévitable.

Confidentiel par conception

Tout s’exécute localement dans votre navigateur en JavaScript. Vos données ne sont jamais envoyées sur un serveur, ce qui rend l’outil sûr pour des contenus sensibles, et il fonctionne hors ligne.

Questions fréquentes

Pourquoi ma propriété s’appelle-t-elle `` `content-type` `` avec des accents graves ?
Parce que Kotlin accepte n’importe quel identifiant entre accents graves, et que c’est ainsi qu’on garde la clé JSON comme nom de propriété. Avec kotlinx.serialization, le nom de la propriété *est* le nom JSON : rien d’autre n’est nécessaire. Avec Jackson ou Moshi, le même résultat demande une annotation — `@JsonProperty` ou `@Json(name = …)` — ajoutée à la main.
Les champs devraient-ils être `val` ou `var` ?
`val`, parce qu’une charge décodée est une valeur, pas un formulaire. Tout rendre mutable invite à du code qui modifie l’objet sur place, puis se demande quelle version il regarde. Là où il faut vraiment modifier, `copy()` rend une nouvelle instance avec un champ changé — l’idiome pour lequel les data class existent.
Pourquoi aucune valeur par défaut ?
Parce qu’un défaut est une affirmation sur ce que veut dire une clé manquante, et qu’un échantillon ne montre jamais de clé manquante. Un `= null` transformerait « absent » en « null » pour toute la base de code. L’ajouter est un mot quand vous connaissez l’API ; le deviner est une décision que personne n’a demandée à cet outil.

Convertisseurs associés