type XMLStruct struct {
Name string `json:"name" json:"FirstName"`
Date string `xml:"Date" xml:"pudDate"`
}
4 Réponses :
Je vais dire non pas de cette façon.
vous pouvez faire ceci,
type XMLStruct struct {
Name string `json:"name, omitempty" xml:"name, omitempty"`
Date string `json:"Date, omitempty" xml:"Date, omitempty"`
FirstName string `json:"FirstName, omitempty" xml:"FirstName, omitempty"`
}
ou ceci,
type XMLStruct struct {
Name string `json:"name" xml:"name"`
Date string `json:"Date" xml:"Date"`
}
Si vous avez la même clé dans la paire clé: "valeur", la recherche de balise struct n'utilisera que la première valeur que vous avez spécifiée.
Ainsi, votre structure ressemblera à
type XMLStruct struct {
Name string `json:"name"`
Date string `xml:"Date"`
}
La balise field d'un go-struct peut littéralement avoir n'importe quelle séquence UTF-8. C'est un code go légal:
type XMLStruct struct {
Name string `g1bb3ri$h...T@g`
}
Les balises sont donc à interpréter. Le package json de la bibliothèque standard attend des balises dans un format particulier - qui mappe un seul champ struct à un seul attribut JSON.
Si vous vouliez prendre en charge plusieurs attributs pour un seul field - on pourrait écrire son propre Marshal / Unmarshal et agir sur ce nouveau format de balise. Mais comme certains des autres commentaires / réponses l'ont suggéré, il y a le dilemme de la gestion des conflits.
Il n'y a pas de réponse définitive à cela. Les balises Struct, au niveau des spécifications du langage, sont du texte arbitraire, sans signification intrinsèque. Consultez les spécifications . Cela signifie que, d'un point de vue linguistique, json: "name" json: "FirstName" est une balise valide, comme tout autre texte arbitraire.
Ce qui compte, c'est la manière dont le code interprète les balises. Puisque vous parlez de la balise json , vous vous souciez probablement de la < code> encoding / json dans la bibliothèque standard. La manière dont ce package interprète les balises est décrite dans la documentation ici et ici . Une balise en double comme celle-ci serait, au mieux, ambiguë, donc on pourrait dire qu'elle n'est pas prise en charge. Bien que l'utilisation d'une telle balise fasse quelque chose . Ce qu'il fait peut ou non correspondre à ce que vous attendez (en fonction de ce que vous attendez).
Mais il peut y avoir d'autres paquets qui interprètent les balises json - y compris éventuellement un que vous écrivez vous-même. Et ils peuvent utiliser les règles de leur choix, y compris autoriser ou interdire plusieurs segments de balises portant le même nom.
Jetez simplement un œil à la documentation de package encoding / json et encoding / xml et mettez en rouge les parties concernant les balises, par exemple golang.org/pkg/encoding/json/#Marshal . Y a-t-il une mention de plusieurs clés json? Non. Donc: Non. Consultez toujours la documentation officielle en premier. BTW: Comment cela devrait-il fonctionner? Si vous marshalez une telle structure: quelle clé json doit être utilisée? Et si vous annulez un json avec des champs de nom et de prénom: comment cela fonctionnerait-il?
Il n'y avait aucune mention dans la documentation. C'est pourquoi j'ai demandé ici. Quel serait le besoin de demander alors? J'espérais juste gérer plusieurs clés dans un seul paramètre, parce que dans mon cas j'obtiendrai "date" ou "pubDate" et j'ai juste besoin de les décoder. En cas de marshaling et de démarshaling, je suppose qu'une hiérarchisation est nécessaire.
Exactement: il n'y a aucune mention de plusieurs clés json, donc plusieurs clés json ne sont pas prises en charge. Il n'y a généralement pas de fonctionnalités cachées qui ne sont pas documentées.
Si le JSON que vous devez annuler est incohérent: Démarrez dans une structure avec deux champs mappés: "date" et "pubDate" (peut-être les deux types de pointeurs). Ensuite, consolidez votre code dans un champ que vous allez utiliser. Cette solution est extrêmement simple, nécessite moins de 10 lignes de code, est claire et ne fait pas de magie.
Oui, j'utilise actuellement cette solution. Mais comme je l'ai déjà dit, dans mon cas, ces deux champs ne coexisteront jamais, alors j'essayais de trouver un moyen de les gérer tous les deux dans un seul paramètre. Mais comme vous l'avez expliqué, cela poserait d'autres problèmes de logique.