Convertisseur Go vers XML
Colle des structs Go. Récupère du XML propre.
Ce que fait cet outil
Si tu as déjà dû construire un payload XML qui colle à un struct Go — pour un client SOAP, un flux RSS, un webhook d'un SaaS legacy ou un sitemap fournisseur — tu sais à quel point c'est pénible. Tu peux appeler toi-même xml.Marshal, mais ça veut dire bricoler un main.go, compiler et relire la sortie à l'œil. Colle le Go ici et tu récupères du XML bien formé en une étape. Un struct, un fichier avec plusieurs, ou un literal que tu as copié-collé depuis Go by Example — même combat : un document XML complet avec tous les champs.
Ça reproduit ce que le paquet encoding/xml produirait vraiment. Un tag comme xml:"OrderId,attr" transforme le champ en attribut du parent ; xml:"-" le retire ; xml:",omitempty" saute l'élément quand la valeur est la valeur zéro ; xml:"Items>OrderItem" enveloppe le slice dans un conteneur <Items> avec un <OrderItem> par élément ; xml:",chardata" met la valeur en contenu texte. XMLName xml.Name renomme l'élément lui-même. Les champs pointeurs nil sortent en éléments vides uniquement quand ,omitempty est absent — exactement comme la lib standard.
Les scalaires sont traités comme Go les traiterait : float64 s'écrit sans notation scientifique quand ça rentre, time.Time utilise RFC 3339, les booléens sont true/false en minuscules, et int/uint sortent sans padding. Les structs imbriqués deviennent des éléments imbriqués. Les slices de structs deviennent des éléments répétés au même niveau. encoding/xml ne gère pas nativement les maps — elles sont aplaties en enfants répétés <Entry><Key/><Value/></Entry> pour que la forme reste lisible. Tu écris du Go idiomatique ? Le guide de style Effective Go est une bonne référence pour les patterns que cet outil attend.
Comment l'utiliser
Trois étapes. Ça marche pareil si tu colles un struct ou un fichier de package entier.
Colle ton Go (ou essaie l'exemple)
Balance ton Go dans l'éditeur de gauche tel quel. Une seule déclaration de struct, un fichier entier avec les imports et plusieurs types, ou un composite literal comme order := Order{...} — tout passe. Clique sur Charger un exemple pour voir d'abord un cas concret.
Pas besoin de retirer la ligne package, de virer les imports ou de nettoyer le fichier. Colle-le tel qu'il sort de gofmt. Les tags de struct avec backticks sont attendus.
Clique sur Convertir
Clique sur le bouton vert Convertir. L'outil lit le Go, respecte chaque tag xml de struct et construit le XML en une passe. Tu verras un petit indicateur de chargement pendant l'exécution.
Copie le XML
Le panneau de droite se remplit avec du XML indenté et bien formé qu'un parseur XML conforme acceptera. Copie-le dans ton enveloppe SOAP, fichier de config, fixture de test ou doc d'API.
Quand ça sert vraiment
Construire des fixtures de client SOAP
Tu parles à une API SOAP d'entreprise legacy depuis un service Go. Colle le struct de requête, récupère le body XML prêt pour SoapUI, Postman ou la suite de tests.
Flux RSS et Atom
Un struct de flux avec des champs Channel, Item et enclosure devient un template RSS ou Atom fonctionnel — pratique pour vérifier la disposition des tags avant de brancher le handler.
Fichiers de config fournisseur
Certains outils SaaS consomment encore de la config en XML (sitemaps, pipelines de logging, consoles ops legacy). Colle le struct Go de config, récupère le XML directement.
Garder la doc honnête
Génère des exemples XML pour un README ou une référence d'API à partir des vrais types Go, comme ça les exemples ne se désynchronisent jamais du code qui part en main.
Questions fréquentes
Je peux coller plusieurs structs d'un coup ?
Oui — colle le fichier entier. La racine est détectée depuis le composite literal (p. ex. order := Order{...}) quand il est présent, ou depuis le premier struct qui référence les autres. Les structs imbriqués et frères ressortent comme éléments imbriqués ou fragments séparés, rien n'est perdu en silence.
Est-ce que ça respecte les tags de struct comme xml:"x,attr", xml:"-" et xml:",omitempty" ?
Oui — et toutes les variantes courantes. xml:"name" renomme l'élément, xml:"name,attr" l'émet en attribut sur le parent, xml:"-" retire complètement le champ, xml:",omitempty" saute les champs à la valeur zéro, xml:"a>b" enveloppe le slice dans un conteneur <a> avec un <b> par élément, xml:",chardata" met la valeur en texte de l'élément, et xml:",innerxml" passe en XML brut. Ça colle au comportement documenté dans la référence encoding/xml Marshal.
Et le champ spécial XMLName ?
Un champ de type xml.Name nommé XMLName renomme l'élément racine. XMLName xml.Name `xml:"Order"` produit <Order>...</Order>. Sans lui, l'outil utilise le nom du type du struct comme racine — le même défaut que xml.Marshal.
Comment ça gère les pointeurs, slices et maps ?
Les champs pointeurs nil émettent un élément vide sauf si ,omitempty est présent, auquel cas ils sont sautés. Les slices de structs deviennent des éléments frères répétés (ou enveloppés dans un conteneur quand le tag utilise la forme a>b). Les maps ne sont pas gérées nativement par encoding/xml, donc l'outil les sort en série d'enfants <Entry><Key/><Value/></Entry> — suffisant pour la plupart des cas, et assez explicite pour être édité si tu veux une autre forme.
Mon code est-il stocké ?
Ton code est envoyé au backend pour la conversion et n'est pas persisté — on ne loggue pas le payload. Avertissement standard pour tout outil en ligne : si le code est vraiment sensible, relis-le avant de le coller.
Et si le struct utilise des types que encoding/xml ne supporte pas — channels, funcs, complex ?
Ils sortent en éléments vides plutôt que de faire planter toute la conversion, en cohérence avec ce que ferait xml.Marshal au runtime (il renvoie une erreur ; l'outil continue pour que tu récupères le reste). Si le Go lui-même a une erreur de syntaxe, corrige d'abord les cas évidents — le parser est tolérant mais ce n'est pas un gc complet.
Autres outils qui peuvent servir
Go vers XML n'est qu'une pièce du puzzle. Voici les outils qui vont bien avec :