Laden...

Wert aus JSON extrahieren - Mit RegEx?

Erstellt von ByteDevil vor 5 Jahren Letzter Beitrag vor 5 Jahren 3.802 Views
ByteDevil Themenstarter:in
132 Beiträge seit 2013
vor 5 Jahren
Wert aus JSON extrahieren - Mit RegEx?

Hi,

ich muss aus einem String einen Wert extrahieren, doch die Zusammensetzung ist leider teilweise zufällig bedingt...zumindest die Reihenfolge. Hierzu mal ein Beispiel:


Freunde
[
	{
		Geld: 55,
		Name: "John",
		Laster: {
			Raucht: "Ja",
			Trinkt: "Nein"
		},
		Alter: 18,
		Besitz: {
			Haus: "Ja",
			Boot: "Nein"
		}
	},
	{
		Besitz: {
			Haus: "Nein",
			Boot: "Nein"
		},
		Laster: {
			Raucht: "Nein",
			Trinkt: "Ja"
		},
		Alter: 22,
		Geld: 10,
		Name: "Gary"
	},
	{
		Name: "Eva",
		Laster: {
			Raucht: "Ja",
			Trinkt: "Ja"
		},
		Alter: 44,
		Besitz: {
			Haus: "Ja",
			Boot: "Ja"
		},
		Geld: 30
	}
]

Das steht sonst alles in einer Zeile...also ohne Tabs und ohne Zeilenumbrüche. Nun seht ihr vielleicht auch was mich so stört und zwar das die Felder (tatsächlich sind es deutlich mehr als die paar) immer unterschiedlich angeordnet sind. Könnt ihr mir helfen? Ich möchte zB anhand des Namens das korrekte Alter bekommen. Sprich: Gary->22 oder Eva->44

Bin für jede Hilfe dankbar.

16.806 Beiträge seit 2008
vor 5 Jahren

Das ist ein Json. Wieso serialisierst Du es nicht einfach?
Wenn Du nicht weißt, was ein Json ist - dann hast echt die letzten Jahre ganz tief gepennt 😉

ByteDevil Themenstarter:in
132 Beiträge seit 2013
vor 5 Jahren

Mh aber das was du da siehst ist sehr weit verschachtelt. Das ganze ist aus einem Seitenquelltext der über 500 kb groß ist. Das alles zu deserialisieren bis ich an die eine Information gekommen bin dauert doch ewig 😦 Da steht noch ganz viel anderer Quatsch drin den ich nicht brauche.

Edit: Wobei ich natürlich den Part da oben mit einem Regex suchen und nur diesen Substring deserialisieren könnte...hmmm...am liebsten wäre mir aber ein Regex der das einfach direkt tut^^

P
441 Beiträge seit 2014
vor 5 Jahren

Dein Regex kann beliebig komplex werden - vor allem dann, wenn zusätzliche Felder dazu kommen.

Du müsstest es ja nicht zu objekten Deserialisieren, aber du könntest es als Json einlesen und navigieren: https://www.newtonsoft.com/json/help/html/ReadingWritingJSON.htm
Es gibt auch Möglichkeiten ähnlich zu XPATH (da fällt mir allerdings der Name nicht ein - Google wird da helfen).

16.806 Beiträge seit 2008
vor 5 Jahren

Mh aber das was du da siehst ist sehr weit verschachtelt.

Tief verschachtelt; ich glaube nicht, dass Du da was hast, was für Json wirklich tief verschachtelt ist.

Das ganze ist aus einem Seitenquelltext der über 500 kb groß ist.

Das ist Mini; nicht Mikro - aber Mini.
Die Json API für Earth gibt Json Daten im Gigabyte-Bereich.

Das alles zu deserialisieren bis ich an die eine Information gekommen bin dauert doch ewig 🙁

Schon probiert oder schaust in die Glaskugel? Glaubst die Zeit, die Du sparst, sofern Regex überhaupt schneller ist, merkst Du?

am liebsten wäre mir aber ein Regex der das einfach direkt tut^^

Regex kann nicht hellsehen. Regex wäre technologisch hier auch einfach falsch.
Du arbeitest hier mit einer Json-Struktur, also behandle sie auch so. Wenn Du nicht serialisieren willst, dann navigier halt.

Aber ich hab den Eindruck, dass Du einfach keine Lust hast, wa? 😉

ByteDevil Themenstarter:in
132 Beiträge seit 2013
vor 5 Jahren

Richtig, große Lust hatte ich nicht dazu. Hätte ja sein können das jemand einen kurzen regulären Ausdruck parat hätte, dann wäre es halt nur ein Einzeiler geworden. Habe es so gemacht wie ihr mir geraten habt. Vielen dank für den Hinweis.

49.485 Beiträge seit 2005
vor 5 Jahren

Hallo ByteDevil,

Hätte ja sein können das jemand einen kurzen regulären Ausdruck parat hätte

grundsätzlich stimme ich den anderen zu, dass Regex hier (ausnahmsweise) mal nicht unbedingt die erste Wahl ist. Und das Forum ist nun generell auch kein Patterngenerator.

Trotzdem ist es mit Regex nun auch nicht so aufwendig. Der Trick für Dinge, die in einer beliebigen Reihenfolge auftreten können, ist, eine wiederholte Alternative zu benutzen und sich die auszulesenden Teile anschließend nicht aus den Gruppen sondern den Captures zu besorgen.

Also wenn ein Pattern sowohl auf (vereinfacht) AB als auch auf BA passen soll, dann z.B. (A|B){2}. Anschließend gibt es in der ersten Regex-Group zwei Captures. Die Captures sind in der Reihenfolge, wie die Alternativen im Text auftreten, aber das kann man dann mit normalem C# leicht (aus)sortieren.

Das kann man sich hübsch bunt und - bezogen auf die Captures - unterschiedlich hell in On-the-fly Regex-Tester: Regex-Lab ansehen und leicht ausprobieren.

Klar in deinem Fall kommt noch ein bisschen was dazu, z.B. dass die Alternativen nicht direkt hintereinander stehen müssen, und man nicht versehentlich über die Grenzen von zwei Json-Objekten hinweg matcht. Das sind aber alles keine prinzipiellen Klippen.

Geschwindigkeit sehe ich bei 500k übrigens weder so noch so als Kriterium, sondern eher dass man sich durch Regex eine externe Bibliothek (Json-Parser) sparen kann (@all: oder kann .NET Json mittlerweile nativ)?

herbivore

PS: Der Pattern (A|B){2} passt natürlich auch auf AA und BB, aber auch das kann man dann mit normalem C# leicht aussortieren.

16.806 Beiträge seit 2008
vor 5 Jahren

@all: oder kann .NET Json mittlerweile nativ)?

Ob externe Bibliothek oder nicht sollte im Jahr 2018 in der .NET Welt keine Rolle mehr spielen.
Es gibt dafür jedenfalls keinen Grund - man hat eher die Zeit verpennt; denn von dem monolitischen Ansatz verabschiedet sich .NET aus guten Gründen: die Zukunft sind Pakete.

Davon abgesehen ist die NewtonSoft.Json Bibliothek von James Newton-King - und der ist bei Microsoft.

ByteDevil Themenstarter:in
132 Beiträge seit 2013
vor 5 Jahren

@herbivore Ja das mit der externen Library fand ich auch nicht so prima, habe mich aber der newtonsoft.json bedient. Ist ja schnell und einfach über nuget installiert und funktioniert prima. Für deinen Exkurs in Regex danke ich dir auch^^ Habe sowas in der Art auch versucht, aber es wollte nicht so recht hin hauen.

Und das Forum ist nun generell auch kein Patterngenerator.

Das ist mir bewusst und es ist ja auch nicht so als hätte ich damit nicht gute 3h genervt gekämpft und auch google um Rat gefragt 😉

656 Beiträge seit 2008
vor 5 Jahren

...was viele nicht wissen: Es gibt auch im Framework was dafür; nämlich die JsonReaderWriterFactory, die JSON auf XML und umgekehrt mappt.

16.806 Beiträge seit 2008
vor 5 Jahren

.. die unheimlich langsam ist und deswegen kaum einer verwendet 😃

T
2.219 Beiträge seit 2008
vor 5 Jahren

@BhaaL
JSON.NET kann dies übrigens auch, dürfte dann auch schneller sein!

Link:
https://www.newtonsoft.com/json/help/html/ConvertingJSONandXML.htm

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

F
10.010 Beiträge seit 2004
vor 5 Jahren

Ja, aber wenn man NIH-Syndrom hat, geht das eben nicht

49.485 Beiträge seit 2005
vor 5 Jahren

Hallo FZelle,

solchen Unterstellungen sind nicht wirklich zielführend. Statt Diskreditierungen sollten Argumente ausgetauscht werden. Natürlich gibt es Leute, die für NIH anfällig sind. Doch hier ging es darum gar nicht. Ich hab freimütig eingeräumt, dass Regex hier nicht die erste Wahl ist. Und ein guter JSON-Namespace, der Teil von .NET wäre, wäre eindeutig vorzuziehen. Doch bei externe Bibliotheken stellt sich immer die Frage des dauerhaften Supports und der dauerhaften Verfügbarkeit. Wenn man eine Bibliothek findet, die das erfüllt, spricht nichts dagegen und hier viel dafür. Doch Voraussagen sind schwierig, besonders wenn sie die Zukunft betreffen. Natürlich gibt es auch für Klassen aus dem .NET Framework keine 100% Garantie, doch zumindest eine berechtigte Hoffnung. Es bleibt jedenfalls immer die Abwägung zwischen dem Aufwand, den man aktuell für eine Lösung benötigt (inkl. des oft unterschätzen Aufwandes, sie stabil zu bekommen), gegen den Aufwand, der entsteht, wenn man später ggf. eine externe Bibliothek wechseln muss. Das ist eine ganz rationale Abwägung und nichts Verwerfliches. Dabei ist es auch egal, wie leicht sich eine Bibliothek verschaffen oder installieren lässt (NuGet). Wichtig ist die Einschätzung der zukünftigen Stabilität und Verfügbarkeit. Und die ist in der Welt von 2018 genauso erforderlich wie früher.

herbivore

656 Beiträge seit 2008
vor 5 Jahren

.. die unheimlich langsam ist und deswegen kaum einer verwendet 😃

Really? Wäre mir noch nie aufgefallen; und teilweise werf ich da auch umfangreichere JSON aus Jira und Co rein.
Aber schön langsam wirds echt off-topic 😉

T
2.219 Beiträge seit 2008
vor 5 Jahren

@herbivore
Sehe ich im groben und ganzen ähnlich.
Aber bei JSON.NET kann man auf lange Sicht planen.
Diese Lib gehört seit Jahrem schon zum Status Quo bei JSON mit C#
Ich wusste z.B. nicht mal, dass .NET JSON auch schon mit eigenen Klassen supportet.
Wir haben schon vor einigen Jahren mit JSON.NET in einem SPA Projekt gearbeitet und da es auch immer weiter ausgebaut wird und eben auch schon in vielen Projekten einen festen Bestandteil bildet, kann man hier auch nicht langfristig mit planen.

In sogut wie jedem Fall wäre es einfacher JSON oder gar XML zu deserialisieren oder ggf. per entsprechenden Iterationsmöglichkeiten, XmlDocument samt XPath bei XML als Beispiel, um die gewünschten Daten zu erhalten als über umständliche RegEx durch die Dokumente zu parsen.

Welche Lösung man dann nimmt ist dann nur noch für mich vom Aufwand und Sinn her entscheidend.
Wenn ich später andere Daten brauche, ist es leichter auf einem deserialisiertem Objekt zu arbeiten als umständlich wieder mit RegEx Erweiterungen zu kämpfen.
Und es dürfte bei weitem auch sauberer sein, da es auch nach einiger Zeit leichter ständlich ist was man eigentlich machen will.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

5.657 Beiträge seit 2006
vor 5 Jahren

Das Parsen mittels JSON-Serializer hätte auch den Vorteil, daß man bei einer fehlerhaften Datei auch einen Fehler zurückbekommt.

Weeks of programming can save you hours of planning

49.485 Beiträge seit 2005
vor 5 Jahren

Hallo MrSparkle,

ob das Vor- oder Nachteil ist, hängt davon ab, was man erreichen will. Ist die Integrität der Daten wichtig, ist es eher ein Vorteil. Ist die Verfügbarkeit wichtig, ist es eher ein Nachteil. Also eine Entscheidung nach den Umständen bzw. Zielen.

herbivore

16.806 Beiträge seit 2008
vor 5 Jahren

Und ein guter JSON-Namespace, der Teil von .NET wäre, wäre eindeutig vorzuziehen.

Nein. Definitiv - in dieser pauschalen Form - nein: stimme hier FZelle zu.
Nur, weil ein Namespace von .NET kommt, heisst es nicht, dass dieser besser ist oder vorzuziehen ist. Die Zeiten sind vorbei. Und gut ist immer relativ.

Wir sind definitiv nicht mehr in den Jahren, in denen Open Source nur eine Idee ist - .NET lebt davon.
Und die Zukunft sind Pakete; und Microsoft wird ein Teufel tun erfolgreiche Open Source Projekte schlecht in das Framework umzusetzen; siehe Reactive Extensions.

49.485 Beiträge seit 2005
vor 5 Jahren

Hallo Abt,

du hast mich missverstanden. Es ging nicht um die Auswahl zwischen .NET und einer externen Bibliothek, sondern um die Auswahl zwischen Regex und einem JSON-Namespace in .NET. Durch einen JSON-Namespace würde nämlich der letzte verbleibende Grund (s.o.) für Regex wegfallen.

Ansonsten kannst du natürlich so entscheiden, wie du persönlich es für richtig hältst, solange du anderen die gleiche Freiheit lässt. Ich glaube nicht, dass es in der Frage, ob oder welche externe Bibliotheken man verwendet (egal ob für JSON oder was anderes), so etwas den einzig richtigen Weg gibt. Und wenn es in einem Projekt ohne Klimmzüge gelingt, ohne externe Bibliotheken auszukommen, ist daran sicher nichts verwerfliches. Die Gründe für und wider wurden genannt, so dass jeder selbst entscheiden kann.

herbivore

16.806 Beiträge seit 2008
vor 5 Jahren

Und wenn es in einem Projekt ohne Klimmzüge gelingt, ohne externe Bibliotheken auszukommen, ist daran sicher nichts verwerfliches.

Verwerflich ist jedoch ein potentieller Anspruch ohne externe Bibliothek auskommen zu müssen.
Wäre dem so, dann würde >ich< die Kompetenz desjenigen anzweifeln, der das bestimmt. Da hat derjenige einfach das Ökosystem nicht verstanden.

49.485 Beiträge seit 2005
vor 5 Jahren

Hallo Abt,

ich halte es nicht für nötig, hier irgendwas auf die persönliche Ebene zu ziehen. Nicht die Kompetenz von Personen steht zur Diskussion, sondern die sachlichen Argumente für oder gegen eine bestimmte Entscheidung. Und die sind ja nun getauscht worden.

herbivore

T
2.219 Beiträge seit 2008
vor 5 Jahren

Hier würde ich herbivore größtenteils zustimmen und möglichst den Ansatz ohne zusätzliche Abhängigkeiten wählen.
Aber wenn eine Lösung durch eine Abhängigkeit z.B. besser/effizienter gelöst wird als mit Bordmitteln, dann würde ich schon zu externen Lösungen greifen.
Warum das ein eckiges Rad nehmen, wenn es auch rund sein kann 😃

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.806 Beiträge seit 2008
vor 5 Jahren

und möglichst den Ansatz ohne zusätzliche Abhängigkeiten wählen.

So funktioniert nur das .NET Ökosystem nicht mehr.
Übrigens auch nicht das Ökosystem von Java, NodeJS und Co...

Daher ist diese Denkweise (schon lange) nicht mehr zeitgemäß - und ich bleibe auch bei meiner allgemeinen Aussage, was die Kompetenz einer solchen Gewichtung betrifft.
Natürlich sollte man nicht blind jedes Paket nehmen; aber das NIH-Syndrom ist leider wirklich weit verbreitet.

PS: selbst Microsoft verwendet in VS Templates Pakete, die nicht von ihnen aktiv gepflegt werden - obwohl für einige Framework-Funktionalitäten (ähnlich) zur Verfügung stehen
Eine Devise nach "ich nehm lieber Framework Funktionen" in ihrer reinen Pauschalität: völlig Banane

T
2.219 Beiträge seit 2008
vor 5 Jahren

@Abt
Dann verstehst du mein Anliegen nicht (richtig).
Dies hat nichts mit NIH zu tun sondern mit dem Überladen von Projekte mit unnötigen Abhängigkeiten.
Klar will ich nicht das Rad selbst neu erfinden, ich will aber nicht Abhängigkeiten schaffen, die unnötig oder zu komplex sind oder das ursprüngliche Problem nicht vollständig lösen.

Wozu soll ich mein Programm mit solchen Abhängigkeiten vollmüllen, wenn es eine einfachere und sogar eine effizientere Lösung mit ein paar Zeilen Code auch tut?
Und ich meine ein paar Zeilen, nicht gleich 10 Klassen die dann mehr Aufwand und Performance kosten als eine fertige Lösung.

Mir geht es nicht darum jede Lösung selbst zu entwickeln, dass ist weder zeitlich und wegen fehlenden/unvollständigen Wissen auch nicht möglich.
Aber ich sehe ebend keinen Mehrwert mein Projekt mit Abhängigkeiten zu zukippen nur weil es gerade hipp ist und es alle so machen.
Wenn eine fertige Lösung mein Problem löst, dann ist es ja absolut in Ordnung und dann verwende ich auch die entsprchende Abhängigkeit in meinem Projekt.

Wenn ich aber keine fertige Lösung habe oder die gefundenen Lösungen eben nicht die ausreichende Qualität aufweisen oder das erwartete Ergebnis eben nicht passt, dann gehe ich lieber hin und schreibe eine eigene Lösung und informiere mich und arbeite mich in das Thema ein und kann dann eine passende Lösung entwickeln.
Dies wäre dann aber die absolute Notlösung und nur wenn es wirklich keine Alternative gibt, ein Ansatz.
Gerade weil dies unnötig Zeit frisst und eben wegen dem fehlenden/unvollständigen Wissen auch zu Fehlern führen kann, die andere schon lange gelöst haben.

Hat nichts mit NIH zutun sondern einfach mit vermeiden von unnötigen/unpassenden/komplexen/unvollständigen Abhängigkeiten im Projekt die im Endeffekt das Problem nicht oder nur bedingt/teilweise lösen können.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

49.485 Beiträge seit 2005
vor 5 Jahren

Hallo Abt,

da du die persönliche Ebene leider immer noch nicht verlassen hast, muss ich sie jetzt doch mal kurz(!) betreten und etwas deutlicher werden. Interessant zu sehen, wie du hier ein Weltbild proklamierst und jedem, der dieses Bild nicht unreflektiert teilt oder übernimmt oder sich sogar erdreistet, aus der eigenen Programmier- und Lebenserfahrung heraus eine andere Ansicht zu haben, mit irgendwelchen Worthülsen und an der Sache vorbeigehenden Schlagworten kommst und ihnen pauschal die Kompetenz absprichst, wogegen die anderen Diskutierenden hier ganz sachlich inhaltliche Argumente vortragen. Ich hätte mehr von dir erwartet. Vor allem mehr Diskussionskultur. Das ist ärgerlich für die Unbescholtenen, die hier vollkommen ungerechtfertigt mit Schlamm beworfen werden, zeigt aber vor allem Defizite in deiner eigenen sozialen Kompetenz. Ich nehme mir hier das Recht, gleiches mit gleichem zu vergelten. Wer austeilt, muss auch einstecken können. Schade das nötig geworden ist. Ich hoffe, du ersparst uns das in Zukunft!

Doch nun zurück zur sachlichen Ebene. Bleiben wir bei deinem Bild vom Ökosystem. In einem Ökosystem leben die verschiedensten Arten und Individuen zusammen, die alle ihre eigene Anpassung an das Ökosystem haben. Entsprechend unterschiedlich sind die herausgebildeten Strategien. Was für die eine Art gut funktioniert muss für die andere Art nicht die gleichen Vorteile bringen oder kann sogar Nachteile haben. Hier im Forum sind die unterschiedlichsten Leute, die C# für die unterschiedlichsten Zwecke einsetzen. Vom Hobbyprogrammierer bis zum großen Projektentwickler ist hier alles dabei. Und die haben natürlich unterschiedliche Anforderungen, Einschätzungen und Erfahrungen. Und von daher werden sie in einer bestimmten Situation mit einem Zielkonflikt(!), wie diesem hier, vollkommen berechtigter Weise unterschiedlich abwägen und zu unterschiedlichen Ergebnissen kommen. Wichtig war mir, die Kriterien zu beleuchten, die bei dieser Abwägung eine Rolle spielen, damit - wie auch schon oben mehrfach gesagt - jeder Einzelne rational und fundiert eine eigene für ihn in seiner Situation passende Lösung wählen kann.

herbivore

5.941 Beiträge seit 2005
vor 5 Jahren

Hallo zusammen

Nach dem integralen Gedanken haben meiner Meinung nach schlussendlich alle hier, zumindest zu einem Anteil, Recht. Die die sagen, dass es schöner wäre, hauseigene Bibliotheken von .NET zu benutzen. Wenn möglich, kann man da zustimmen. Auch jene die sagen, dass laut Zeitgeist OpenSource und Pakete die Gegenwart und Zukunft sind.

Es ist schöner, etwas "natives" zu benutzen, ganz meine Meinung. Ich bin auch ein Anhänger von wenigen Abhängigkeiten. Es ist schön das zu haben, aber nicht unbedingt nötig. Der Overhead von der externen Bibliothek im konkreten Fall JSON.NET ist sicher zu vernachlässigen. Es ist auch zu beachten, dass JSON.NET schon seit längerer Zeit ein Standart ist.

Nach dem Grundsatz: "Soviel wie nötig, so wenig wie möglich".

Das Problem entsteht dadurch, dass es verschiedene Ideologien / Ideengebäude gibt, die sich offensichtlich wiedersprechen. Ich denke aber, dass beide zum Teil recht haben und zum anderen Teil auch der anderen Seite recht geben müssten.
Wenn sich alle aneinander annähern und offen sind, ist es nicht nötig alles lang und breit zu diskutieren oder persönlich zu werden. Egal ob anfänglich oder als Reaktion. Es geht um die Sache, nicht um die Ideologie.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011