convertir fichier de configuration cisco en fichier xml

Bonjour:
Je veux transformer des fichiers de configuration cisco en des fichiers xml.
Le fichier de configuration a la forme suivante:
***************
Current configuration : 4764 bytes
!
! NVRAM config last updated at 08:18:34 UTC Fri Sep 17 2010
!
version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname KSB-SW21
!
boot-start-marker
boot-end-marker
!
enable secret
no aaa new-model
system mtu routing 1500
ip subnet-zero
!
ip dhcp snooping vlan 1,10,20,30,40
ip dhcp snooping
!
cluster commander-address - member 5 name - vlan 1
!
!
!
!
!
spanning-tree mode pvst
spanning-tree extend system-id
!
vlan internal allocation policy ascending
!
!
!
interface FastEthernet0/1
switchport access vlan 10
switchport mode access
switchport nonegotiate
switchport voice vlan 20
spanning-tree portfast
!
interface FastEthernet0/2
switchport access vlan 10
switchport mode access
switchport nonegotiate
switchport voice vlan 20
spanning-tree portfast

......
***************

je me :arf: depuis longtemps mais pas de résultat!!
avez vous des propositions??
Merci d'avance.

Bonjour,

c'est clairement faisable, mais je ne connais pas d'autres méthodes que de créer une classe à la main pour obtenir ce xml.

En gros, il faut définit les éléments de ton fichier XML, la correspondance entre le texte de ton fichier texte et les éléments XML, puis écrire la classe reflétant cette correspondance.

Bonjour,

Une autre approche, moins académique peut-être, consiste à utiliser XSLT pour faire celà.

Avec XSLT 1.0, il est nécessaire de d'abord rajouter un élément racine. Avec XSLT 2.0, grâce à la fonction unparsed-text(), ce n'est même pas la peine !

-Alain

Citation:

---

Envoyé par alain.couthures

Une autre approche, moins académique peut-être, consiste à utiliser XSLT pour faire celà.

Avec XSLT 1.0, il est nécessaire de d'abord rajouter un élément racine. Avec XSLT 2.0, grâce à la fonction unparsed-text(), ce n'est même pas la peine !

---

Moins académique et surtout moins pragmatique -_-°. XSLT peut être bon pour transformer des données qui sont déjà au format XML, mais pas pour l'inverse.

Citation:

---

Envoyé par thelvin

Moins académique et surtout moins pragmatique -_-°. XSLT peut être bon pour transformer des données qui sont déjà au format XML, mais pas pour l'inverse.

---

XPath 2.0 intègre beaucoup de fonctions de manipulation de chaines supplémentaires.

XSLT n'a pas son pareil pour bien générer du XML, à part peut-être XQuery.

Mais c'est vrai qu'il faut nativement penser en récursif !

-Alain

Bonjour,

je n'ai jamais vraiment chercher pourquoi XSLT n'était pas très performant pour manipuler du texte. Auriez-vous des tests le démontrant ?

veillez m'expliquer d'avantage comment faire avec xslt?? je suis vraiment ignorante de ce propos et je suis obligée de ce faire juste comme outil dans une autre application.
encore Merci

Citation:

---

Envoyé par alain.couthures

XPath 2.0 intègre beaucoup de fonctions de manipulation de chaines supplémentaires.

---

Et alors ? Tout le reste aussi, mais le reste est mieux prévu pour.

Citation:

---

Envoyé par alain.couthures

XSLT n'a pas son pareil pour bien générer du XML, à part peut-être XQuery.

---

Et à part aussi 98% des générateurs XML de la planète. Le point fort de XSLT c'est de lire du XML et de le décorer à la manière d'un super-CSS. Pas de créer du XML, où il n'est pas meilleur que n'importe quoi d'autre.

Citation:

---

Envoyé par alain.couthures

Mais c'est vrai qu'il faut nativement penser en récursif !

---

Déjà, oui, et mille autres limitations inutiles, dues au choix d'un outil qui n'a rien à voir.

Citation:

---

Envoyé par BSmum

veillez m'expliquer d'avantage comment faire avec xslt??

---

Ce n'est pas intéressant, il t'a menti.

Cher thelvin,

Bravo pour vos remarques si constructives, toujours agréables et bien à propos (c'est ironique bien sûr).

Dommage que cela nuise tant au niveau de ce forum...

-Alain

Que ce que je dis te plaise ou pas ne change rien à sa véracité pure et simple.

Et dire les choses aux gens est plus utile au forum que leur raconter n'importe quoi. À part dire "utilise XSLT 2.0 !" tu n'as servi à rien, et dire cela n'a non seulement servi à rien mais a en plus ouvert une mauvaise piste.

En l’occurrence, On ne peut pas aider cette personne parce que ce qui lui manque c'est des notions de XML et c'est tout. La seule chose qu'elle peut faire c'est apprendre le XML et c'est ce que je lui ai dit de faire.

J'ajoute que polymorphisme t'a déjà demandé de défendre ton point de vue, et que tu ne l'as pas fait, ce qui est normal parce que tu ne saurais pas le faire, ce qui est normal parce qu'il est erroné. De plus le demandeur aussi t'a demandé de préciser ce que tu voulais dire et tu ne l'as pas fait, parce que tu n'as rien à préciser : ta suggestion ne servait à rien.

Bonne soirée, jaloux (c'est comme un mauvais perdant, mais qui se rend compte qu'il est moins capable qu'un autre plutôt que d'avoir perdu une partie de quelque chose).

C'est bien avec des avis comme ceux-là que le niveau de ce forum n'est décidément pas terrible...

Cela fait des années que je parse des langages texte avec XSLT. Oui, je dois être le seul sur ce forum. Cela ne veut pas dire que ce n'est pas performant.

Ecrire un programme nécessite un compilateur ou un interpréteur. Le nombre de lignes de code pour faire cela sera fatalement conséquent.

Avec Saxon, ceci peut être fait en passant une commande et la feuille de style ne devrait pas être si conséquente, tout dépend du format XML cible.

Voici l'exemple figurant dans le livre de Michael Kay (je dois aussi être le seul de ce forum à le connaître personnellement...) pour convertir un fichier CSV en XML :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.orh/2001/XMLSchema" version="2.0"> <xsl:param name="input-uri" as="xs:string"/> <xsl:output indent="yes"/> <xsl:template name="main"> <xsl:variable name="in" select="unparsed-text($input-uri, 'iso-8859-1')"/> <table> <xsl:analyze-string select="$in" regex="\n"> <xsl:non-matching-substring> <row> <xsl:analyze-string select="." regex='("([^"]*?)")|([^,]+?),'> <xsl:matching-substring> <cell> <xsl:value-of select="regex-group(2)"/> <xsl:value-of select="regex-group(3)"/> </cell> </xsl:matching-substring> </xsl:analyze-string> </row> </xsl:non-matching-substring> </xsl:analyze-string> </table> </xsl:template> </xsl:stylesheet>

---

Donc, la réponse avec XSLT 2.0 ne serait pas bien plus compliquée...

Veillez vous calmez et merci en tout cas, de toute façon je me suis débrouillé en développant un script php!

Tartaglia et Cardan ...

Citation:

---

Envoyé par BSmum

Veillez vous calmez et merci en tout cas, de toute façon je me suis débrouillé en développant un script php!

---

Nous n'avons pas d'ordre à recevoir de toi, une simple demande raisonnable ne se fait pas en rouge, je suis calme mais je corrige les erreurs si j'en ai envie et je ne me laisse pas marcher sur les pieds, et ça s'écrit "veuillez."

Te débrouiller avec un script PHP est exactement ce qu'il fallait faire, alors félicitations.

Citation:

---

Envoyé par alain.couthures

C'est bien avec des avis comme ceux-là que le niveau de ce forum n'est décidément pas terrible...

---

Prouve-le. C'est au contraire en disant aux gens d'utiliser des outils qui n'ont rien à voir, qu'on en arrive aux solutions miteuses genre prendre une photo sur une table en bois.

Le forum XML/XML Schema/XSLT est d'ailleurs d'un fort bon niveau, de ce que j'en ai vu. Les gens qui viennent pour de l'aide sont pas très doués, logiques, ils sont là pour ça, aussi.

Citation:

---

Envoyé par alain.couthures

Cela fait des années que je parse des langages texte avec XSLT. Oui, je dois être le seul sur ce forum. Cela ne veut pas dire que ce n'est pas performant.

---

Mais ça veut dire que cette solution n'est bonne que pour toi et les gens dans ton cas. Je peux faire une bibliothèque d'imagerie en pur Java dynamique. C'est pas pour autant que je vais le faire, le langage étant totalement inadapté, comparé à une petite bibli native.

Citation:

---

Envoyé par alain.couthures

Ecrire un programme nécessite un compilateur ou un interpréteur. Le nombre de lignes de code pour faire cela sera fatalement conséquent.

---

Non. D'ailleurs la personne l'a fait en PHP et même si je ne raffole pas de ce langage, le problème peut y être résolu en un nombre de lignes correspondant à la complexité du problème.

Citation:

---

Envoyé par alain.couthures

Avec Saxon, ceci peut être fait en passant une commande et la feuille de style ne devrait pas être si conséquente, tout dépend du format XML cible.

---

Et de la XSLT correspondante, le gain est donc nul et le coût supérieur.

Citation:

---

Envoyé par alain.couthures

Voici l'exemple figurant dans le livre de Michael Kay (je dois aussi être le seul de ce forum à le connaître personnellement...) pour convertir un fichier CSV en XML :
[snip]
Donc, la réponse avec XSLT 2.0 ne serait pas bien plus compliquée...

---

Cet exemple est déjà infiniment plus compliqué que nécessaire si on ne connaît pas déjà XSLT 2.0 et tout ce qui y est utilisé. XSLT 2.0 est capable de ça, mais n'a pas été créé pour ça, au contraire de la plupart des langages.

Si l'intégration m'oblige, je n'hesite pas de prendre d'avantage de unparsed-text(): on peut aussi dire que la fonction est faite pour ça.

Perl est fort à traiter des fichiers textuels, ça n'empeche pas des travailleurs de logiciels de les traiter avec un langage d'une porter plus limitée comme Basic - pour faire plus de contrast.

Xml n'est souvent pas réputé d'être concis, mais ça n'empeche pas de devenir un format porteur de méssages à longue distance qui consume "bandwidth". Est-ce que xml est fait pour ça particulièrement?

Je ne vois pas de raison d'extrapoler trop d'après des goûts personnels et d'en prendre comme absolus jusqu'à agresser les autres collègues à cet égard.

Citation:

---

Envoyé par tsuji

Si l'intégration m'oblige, je n'hesite pas de prendre d'avantage de unparsed-text(): on peut aussi dire que la fonction est faite pour ça.

---

Absolument. Mais le si, en début de phrase, est le mot-clé de la phrase. Sans aller jusqu'à parler d'obliger, lorsque la situation dans laquelle on se trouve favorise déjà XSLT 2.0, on peut se rappeler qu'on a pas besoin d'avoir peur du texte grâce à unparsed-text().

Et dans ce cas-là seulement.

Citation:

---

Envoyé par tsuji

Perl est fort à traiter des fichiers textuels, ça n'empeche pas des travailleurs de logiciels de les traiter avec un langage d'une porter plus limitée comme Basic - pour faire plus de contrast.

---

J'en sais rien, Perl c'est pas mon truc.

Citation:

---

Envoyé par tsuji

Xml n'est souvent pas réputé d'être concis, mais ça n'empeche pas de devenir un format porteur de méssages à longue distance qui consume "bandwidth". Est-ce que xml est fait pour ça particulièrement?

---

Littéralement oui. XML est étudié pour mettre tout le monde d'accord universellement sur comment représenter des données, et quelles données sont représentées exactement par tel ou tel document XML.
À l'époque cela concernait absolument tout échange d'une application à l'autre, que ce soit à travers le réseau, entre applications à travers les pipes, à travers des fichiers, ou d'une version à l'autre.

De nos jours ça semble moins intéressant grâce à JSON ou Google Protocol Buffer, mais les habitudes sont tenaces, et il reste des cas pathologiques sans XML.

Par ailleurs, pas mal de gens se jettent sur XML sans se soucier de justifier ce choix. Pourquoi pas si ça leur fait gagner du temps et qu'ils comprennent à l'à peu près comment ça marche. Mais là nous parlions de perdre du temps, et d'une technologie qui a juste rien à voir, donc fondamentalement incompréhensible vis-à-vis de l'objectif visé.

Citation:

---

Envoyé par tsuji

Je ne vois pas de raison d'extrapoler trop d'après des goûts personnels et d'en prendre comme absolus jusqu'à agresser les autres collègues à cet égard.

---

Bah en voilà deux : le coût en temps de mise en place et d'apprentissage ; et le coût de la maintenance, qui découle de la logique de mise en œuvre.
En plus je suis désolé, mais dire à quelqu'un que ce qu'il a dit à quelqu'un d'autre ne marche pas, ça passera toujours comme agressif. Non, c'est la vérité ni plus ni moins, pourquoi je devrais obliger les générations futures qui viendront lire des trucs, à écouter des mauvais conseils et essayer d'en tirer quelque chose ? Si c'est pas bon c'est pas bon, et je le dis, c'est pas dans ce sens qu'il faut aller, et tant pis pour l'amour-propre du monsieur.

De toute façon des professionnels ne discuteraient pas de cela si longtemps : "quand la seule chose qu'on a c'est un marteau, tous les problèmes ressemblent à un clou," c'est connu, parfaitement vérifié, et on en voit très bien les défauts.

Bonjour tsuji,

Citation:

---

Xml n'est souvent pas réputé d'être concis, mais ça n'empeche pas de devenir un format porteur de méssages à longue distance qui consume "bandwidth". Est-ce que xml est fait pour ça particulièrement?

---

Je crois que les Web Services l'utilisent tel quel.
Après, je sais qu'il existe des applications dont le but est réduire la taille du XML. Par exemple, en supprimant les espaces blancs inutiles, en modifiant le type des éléments, en compressant les données, ...

Bonjour M Roche,
C'est entendu, merci; j'ai bien conscience de cela et bien d'autres venant avec. C'est absolument impossible autant qu'inutile d'y plunger dedans, ça ramène trop loin du sujet malheursement.
-tsuji