Prawidłowe, ale Linq to XML jest znacznie ładniejszy.
Finglas
3
Chociaż mówisz, że to „ładniejsze”, jest jeszcze jedna wada w porównaniu z LINQ? Osobiście uznałem tę metodę za najprostszą, przynajmniej dla moich potrzeb.
Kolors
6
Napisałem to, zanim zacząłem używać LINQ. LINQ jest ładny i może mieć łatwiejszą czytelność. Obecnie najczęściej używam LINQ. Ale niektóre komponenty potrzebują obiektów XML starego stylu, więc od czasu do czasu są używane. Poleciłbym wypróbowanie zarówno „starego stylu” tutaj, jak i LINQ i zobaczenie, co ci pasuje.
Wolf5
1
Czy XmlNode node = XmlDocument.Docu...linia nie powinna tak naprawdę być XmlNode = doc.Docu...? Dlaczego zmieniono odpowiedź i doc.usunięto?
wasatchwizard
Prawdziwe. Nie mam pojęcia, dlaczego to zmieniłem ... Naprawię.
// Loading from a file, you can also load from a streamvar xml =XDocument.Load(@"C:\contacts.xml");// Query the data and write out a subset of contactsvar query =from c in xml.Root.Descendants("contact")where(int)c.Attribute("id")<4select c.Element("firstName").Value+" "+
c.Element("lastName").Value;foreach(string name in query){Console.WriteLine("Contact's Full Name: {0}", name);}
Ludzie, którzy nie uwzględniają włączeń, są wredni, dzięki za odpowiedź :)
Gabriel Garcia
@GabrielGarcia prawda, czasami początkujący utknął w błędzie brakującym to błąd
Anonimowy
1
jakie są odpowiednie obejmuje?
powiedzmy
18
Oto aplikacja, którą napisałem do czytania map witryn XML:
usingSystem;usingSystem.Collections.Generic;usingSystem.Windows.Forms;usingSystem.Linq;usingSystem.Text;usingSystem.Threading.Tasks;usingSystem.IO;usingSystem.Data;usingSystem.Xml;namespaceSiteMapReader{classProgram{staticvoidMain(string[] args){Console.WriteLine("Please Enter the Location of the file");// get the location we want to get the sitemaps from string dirLoc =Console.ReadLine();// get all the sitemaps string[] sitemaps =Directory.GetFiles(dirLoc);StreamWriter sw =newStreamWriter(Application.StartupPath+@"\locs.txt",true);// loop through each file foreach(string sitemap in sitemaps){try{// new xdoc instance XmlDocument xDoc =newXmlDocument();//load up the xml from the location
xDoc.Load(sitemap);// cycle through each child noed foreach(XmlNode node in xDoc.DocumentElement.ChildNodes){// first node is the url ... have to go to nexted loc node foreach(XmlNode locNode in node){// thereare a couple child nodes here so only take data from node named loc if(locNode.Name=="loc"){// get the content of the loc node string loc = locNode.InnerText;// write it to the console so you can see its working Console.WriteLine(loc +Environment.NewLine);// write it to the file
sw.Write(loc +Environment.NewLine);}}}}catch{}}Console.WriteLine("All Done :-)");Console.ReadLine();}staticvoid readSitemap(){}}}
publicvoidReadXmlFile(){string path =HttpContext.Current.Server.MapPath("~/App_Data");// Finds the location of App_Data on server.XmlTextReader reader =newXmlTextReader(System.IO.Path.Combine(path,"XMLFile7.xml"));//Combines the location of App_Data and the file namewhile(reader.Read()){switch(reader.NodeType){caseXmlNodeType.Element:break;caseXmlNodeType.Text:
columnNames.Add(reader.Value);break;caseXmlNodeType.EndElement:break;}}}
Możesz uniknąć pierwszej instrukcji i po prostu podać nazwę ścieżki w konstruktorze XmlTextReader.
Istnieją różne sposoby, w zależności od tego, gdzie chcesz się dostać. XmlDocument jest lżejszy niż XDocument, ale jeśli chcesz minimalnie sprawdzić, czy ciąg zawiera XML, to wyrażenie regularne jest prawdopodobnie najszybszym i najlżejszym wyborem, jaki możesz zrobić. Na przykład zaimplementowałem testy dymu z SpecFlow dla mojego API i chciałbym sprawdzić, czy któryś z wyników w jakimkolwiek poprawnym pliku XML - wtedy użyłbym wyrażenia regularnego. Ale jeśli muszę wyodrębnić wartości z tego kodu XML, wówczas przeanalizuję go za pomocą XDocument, aby zrobić to szybciej i przy mniejszej ilości kodu. Albo użyłbym XmlDocument, gdybym musiał pracować z dużym XML-em (a czasami pracuję z XML-em, które mają około 1M linii, a nawet więcej); wtedy mogłem nawet przeczytać to wiersz po wierszu. Dlaczego? Spróbuj otworzyć więcej niż 800 MB w bajtach prywatnych w Visual Studio; nawet podczas produkcji nie powinieneś mieć obiektów większych niż 2 GB. Możesz z twerkerem, ale nie powinieneś. Jeśli musiałbyś parsować dokument, który zawiera DUŻO wierszy, to prawdopodobnie byłby to CSV.
Napisałem ten komentarz, ponieważ widzę mnóstwo przykładów z XDocument. XDocument nie nadaje się do dużych dokumentów lub gdy chcesz tylko sprawdzić, czy zawartość jest poprawna XML. Jeśli chcesz sprawdzić, czy sam XML ma sens, potrzebujesz Schematu.
Głosowałem również za sugerowaną odpowiedzią, ponieważ uważam, że potrzebuje ona powyższych informacji w sobie. Wyobraź sobie, że muszę sprawdzić, czy 200 mln plików XML, 10 razy na godzinę, jest poprawnym plikiem XML. XDocument zmarnuje mnóstwo zasobów.
prasanna venkatesh stwierdza również, że możesz spróbować wypełnić ciąg do zbioru danych, będzie to również wskazywać poprawny kod XML.
Odpowiedzi:
XmlDocument do odczytu XML z ciągu znaków lub z pliku.
lub
następnie znajdź pod nim węzeł, czyli tak
lub
następnie przeczytaj tekst w tym węźle w ten sposób
lub przeczytaj atrybut
Zawsze sprawdzaj wartość NULL w atrybutach [„coś”], ponieważ będzie ona pusta, jeśli atrybut nie istnieje.
źródło
XmlNode node = XmlDocument.Docu...
linia nie powinna tak naprawdę byćXmlNode = doc.Docu...
? Dlaczego zmieniono odpowiedź idoc.
usunięto?Przykład LINQ to XML :
Odniesienie : LINQ do XML w MSDN
źródło
Oto aplikacja, którą napisałem do czytania map witryn XML:
Kod na Paste Bin http://pastebin.com/yK7cSNeY
źródło
Jest wiele sposobów, niektóre:
źródło
Możesz albo:
Przykłady znajdują się na podanych stronach msdn
źródło
Linq do XML.
Ponadto VB.NET ma znacznie lepszą obsługę parsowania XML za pośrednictwem kompilatora niż C #. Jeśli masz opcję i pragnienie, sprawdź to.
źródło
Możesz użyć zestawu danych do odczytu ciągów XML.
Publikowanie tego ze względu na informacje.
źródło
Sprawdź na przykład klasę XmlTextReader .
źródło
Możesz uniknąć pierwszej instrukcji i po prostu podać nazwę ścieżki w konstruktorze XmlTextReader.
źródło
Istnieją różne sposoby, w zależności od tego, gdzie chcesz się dostać. XmlDocument jest lżejszy niż XDocument, ale jeśli chcesz minimalnie sprawdzić, czy ciąg zawiera XML, to wyrażenie regularne jest prawdopodobnie najszybszym i najlżejszym wyborem, jaki możesz zrobić. Na przykład zaimplementowałem testy dymu z SpecFlow dla mojego API i chciałbym sprawdzić, czy któryś z wyników w jakimkolwiek poprawnym pliku XML - wtedy użyłbym wyrażenia regularnego. Ale jeśli muszę wyodrębnić wartości z tego kodu XML, wówczas przeanalizuję go za pomocą XDocument, aby zrobić to szybciej i przy mniejszej ilości kodu. Albo użyłbym XmlDocument, gdybym musiał pracować z dużym XML-em (a czasami pracuję z XML-em, które mają około 1M linii, a nawet więcej); wtedy mogłem nawet przeczytać to wiersz po wierszu. Dlaczego? Spróbuj otworzyć więcej niż 800 MB w bajtach prywatnych w Visual Studio; nawet podczas produkcji nie powinieneś mieć obiektów większych niż 2 GB. Możesz z twerkerem, ale nie powinieneś. Jeśli musiałbyś parsować dokument, który zawiera DUŻO wierszy, to prawdopodobnie byłby to CSV.
Napisałem ten komentarz, ponieważ widzę mnóstwo przykładów z XDocument. XDocument nie nadaje się do dużych dokumentów lub gdy chcesz tylko sprawdzić, czy zawartość jest poprawna XML. Jeśli chcesz sprawdzić, czy sam XML ma sens, potrzebujesz Schematu.
Głosowałem również za sugerowaną odpowiedzią, ponieważ uważam, że potrzebuje ona powyższych informacji w sobie. Wyobraź sobie, że muszę sprawdzić, czy 200 mln plików XML, 10 razy na godzinę, jest poprawnym plikiem XML. XDocument zmarnuje mnóstwo zasobów.
prasanna venkatesh stwierdza również, że możesz spróbować wypełnić ciąg do zbioru danych, będzie to również wskazywać poprawny kod XML.
źródło