print_r ausgabe in Array verwandeln

[T-Rex]

Lieber Leser,

da gibt es einen extrem langen json-string. Dieser String kommt von einer Api, die ich abrufe. Er liefert Daten. Ich würde gerne diese Daten manuell bearbeiten. Um genauer zu sein möchte ich Teile aus diesem String löschen. Da der String mit 90.000 Zeichen sehr lang ist und keinerlei Zeilenumbrüche hat sehe ich in meinem Texteditor nur eine ganz lange Wurst. Es ist mir unmöglich dort etwas zu bearbeiten.

Deshalb habe ich die Idee, den json-String erstmal in ein Array um zu wandeln und dieses mittels print_r in eine Datei zu schreiben. Soweit so gut. Jetzt sind die Daten leserlich. Ich kann es sehr leicht nach meinen Wünschen manipulieren.

Doch leider bekomme ich die Daten jetzt aus der Datei nicht mehr zurück ins php um es weiter zu verarbeiten. Leider sind meine Recherchen diesbezüglich gescheitert. Anscheinend gibt es von php aus keine Funktion, die eine print_r ausgabe wieder zurück in ein php Array bringt. Wobei mir dieser umstand natürlich irgendwie klar ist- warum sollte man etwas, dass man veranschaulicht auch weiter verarbeiten wollen. Bei mir ist aber eben aus genannten Gründen ein Sonderfall eingetreten.

Mit wurstigem Zeichensalat Gruß T-Rex

[Felix Riesterer]

Lieber T-Rex,

Suche nach "php beautify json" ergab das hier: format-json-with-php

Liebe Grüße,

Felix Riesterer.

[dedlfix]

Tach!

Suche nach "php beautify json" ergab das hier: format-json-with-php

Diese Weise halte ich auch für zielführend, aber nicht mit diesem Script, zu lang. Zum einen gibt es JSON-Beautifier auch als Plugins für Editoren. Zum anderen hat PHPs json_encode() die Option JSON_PRETTY_PRINT für die lesbare Ausgabe. Also decode, encode, fertig. Das nachbearbeitete JSON geht dann natürlich auch wieder mit json_decode() einzulesen.

dedlfix.

[Rolf B]

Hallo dedlfix,

ein Umcodieren in der Pretty-Variante ist eine gute Möglichkeit.

Die Frage ist: Warum nicht einfach doch im Editor? Reicht es nicht, einfach Zeilenumbrüche (Word Wrap) einzuschalten? Wenn's der Leib- und Mageneditor nicht hat, einfach mal einen anderen ausprobieren (z.B. Notepad++)

Rolf

[dedlfix]

Tach!

Die Frage ist: Warum nicht einfach doch im Editor? Reicht es nicht, einfach Zeilenumbrüche (Word Wrap) einzuschalten?

Eher nicht, denn der orientiert sich an Zeilenlänge und nicht an sinnvollen Umbrüchen anhand der Daten. Aber ich schrub ja auch, dass es Beautifier als Plugins für Editoren gibt.

dedlfix.

[Self-Nachtwächter]

Anscheinend gibt es von php aus keine Funktion, die eine print_r ausgabe wieder zurück in ein php Array bringt.

Wozu? Du hast doch das Array doch mit print_r() ausgegeben. Warum willst Du die Ausgaben zurückverwandeln? Ist das Array weg?

Übrigens hat print_r() eine Schwester: var_export().

Das Handbuch sagt: "Gibt die Daten als parsbaren PHP-Code zurück".

Daten wegschreiben:

<?php
$foo = [1,2,4,8,'Hallo'];
file_put_contents( 'var_foo.php', '<?php $foo = ' . var_export( $foo ) );

Daten einlesen:

<?php
include 'var_foo.php';
print_r( $foo );

Wichtige Hinweise:

Man könnte auf die Idee kommen, Daten regelmäßig so zu speichern und abzulegen. Das ist keine gute Idee, weil:

1. Das Einlesen ist langsamer als bei serialisierten Daten (serialice() / unserialice() ) bzw. der Import von JSON, weil das exportierte Zeug als vermutetes PHP geparst wird.

2. Serialisierte Daten sind sicherer. Grund wie vorstehend.

[pl]

moin,

da gibt es einen extrem langen json-string. Dieser String kommt von einer Api, die ich abrufe. Er liefert Daten. Ich würde gerne diese Daten manuell bearbeiten. Um genauer zu sein möchte ich Teile aus diesem String löschen. Da der String mit 90.000 Zeichen sehr lang ist und keinerlei Zeilenumbrüche hat sehe ich in meinem Texteditor nur eine ganz lange Wurst. Es ist mir unmöglich dort etwas zu bearbeiten.

Deshalb habe ich die Idee, den json-String erstmal in ein Array um zu wandeln und dieses mittels print_r in eine Datei zu schreiben.

Bleib doch beim JSON. Den musst Du nur umbauen, daß da Zeilenumbrüche drin sind. In JS geht das z.B. mit JSON.stringify(array,null,2) und in PHP gibts da sicher Ahnliches.

Ansonsten gänge ja auch der Weg über JS wo Du sowieso schon Hand anlegst.

MfG

[ursus contionabundo]

Bleib doch beim JSON. Den musst Du nur umbauen, daß da Zeilenumbrüche drin sind. In JS geht das z.B. mit JSON.stringify(array,null,2) und in PHP gibts da sicher Ahnliches.

Aber ja doch! Das Handbuch sagt:

$string = json_encode( $mixed, JSON_PRETTY_PRINT );

will man Unicode-Zeichen zusätzlich nicht escapen, dann geht auch:

$string = json_encode( $mixed, JSON_PRETTY_PRINT + JSON_UNESCAPED_UNICODE );

Mit json_decode() in Variable einlesen:

$mixed = json_decode( $string );

Will man auf Fehler überprüfen, dann hat man mit json_last_error() und json_last_error_msg() "zauberhafte" Möglichkeiten dazu.

Allerdings sollte ich nicht verschweigen, dass das Herumeditieren in JSON-Code im Hinblick auf die Syntax und also der Fehlerträchtigkeit manueller Bearbeitung auch nicht "das Wahre" ist. Man sollte die Aufgabe überprüfen und schauen, ob man nicht mit "normalen Formularen" und den üblichen Methoden zum Bearbeiten von Inhalten von Arrays oder dergleichen besser wegkommt.

Zumindest bei der Anwendung von json_decode( $string ); sollte also unbedingt mit

$mixed = json_decode( $string );
if ( ! JSON_ERROR_NONE === json_last_error() ) {
   #Fehlerbearbeitung
}

auf mögliche Fehler getestet und (unbedingt) zusätzlich eine Plausibilitätsprüfung der erhaltenen Daten stattfinden. Letzteres treibt den Aufwand dann so hoch, dass man auch gleich "was richtiges" schreiben kann.

Weitere Alternative: YAML.

[TS]

Hello,

[...]
Wenn die Aufgabe öfter ansteht, lässt man sich besser gleich ein HTML-Formular generieren, in dem man dann gezielt Name-ValuePaare löschen, hinzufügen, editieren kann.

Ich bin mir aber sicher, dass ich derartige Tools (PHP-Klassensammlung) schon gesehen habe und wahrscheinlich sogar auf meinem Desktoprechner gespeichert habe.

Vorteil der Methode ist, dass man Fehler bei der Kodierung vermeidet. Wie schnell hat man sonst einen Klammerfehler o. ä. erzeugt...

Glück Auf
Tom vom Berg

[pl]

Allerdings sollte ICH nicht verschweigen, dass das Herumeditieren in JSON-Code im Hinblick auf die Syntax und also der Fehlerträchtigkeit manueller Bearbeitung auch nicht "das Wahre" ist. Man sollte die Aufgabe überprüfen und schauen, ob man nicht mit "normalen Formularen" und den üblichen Methoden zum Bearbeiten von Inhalten von Arrays oder dergleichen besser wegkommt.

So isses! Aber diese Unsitte ist nunmal so drin und schwer wieder rauszukriegen. Sie nimmt ihren Anfang in der weiteren Unsitte, Daten in unüberlegten Strukturen anzulegen die rekursiv geparst werden müssen, weils ja ein JSON Algorithmus schön brav tut ohne Mucke.

Und was dabei rauskommt sehen wir hier. Fehlt nur noch daß mir hier wieder einer erklären möchte daß JSON ein maschinenlesbares Dateiformat ist und worin der Vorteil maschinenlesbarer Dateiformate gegeüber Handabeit mit menschenlesbaren Dateiformaten besteht.

Da wollte mir hier neulich einer erklären, daß 15 Zeilen Code ein Grund sind diesen in eine dedizierte Funktion auzulagern. Und jetzt erklären die Kollegen aus derselben Fraktion wie man eine Datei mit 90 T Zeichen zweckmäßig bearbeitet.

Treppenwitz!

[Patrick C.]

Hallo pl,

Und was dabei rauskommt sehen wir hier. Fehlt nur noch daß mir hier wieder einer erklären möchte daß JSON ein maschinenlesbares Dateiformat ist und worin der Vorteil maschinenlesbarer Dateiformate gegeüber Handabeit mit menschenlesbaren Dateiformaten besteht.

Dein Verhalten der letzten Tage legt nahe, dass es dich eh nicht interessiert, was ich hier jetzt schreibe, ich tue es aber trotzdem:

Laut Wikipedia sind Daten maschinenlesbar, wenn sie von Hard- oder Software interpretiert werden können. Auf JSON trifft das zu, offenkundiger Beweis ist die hohen Menge an Parsern. Warum ist JSON also deiner Auffassung nach nicht maschinenlesbar? Weil es nicht binär ist oder weil ein Parser etwas aufwändiger zu schreiben ist? Sorry, aber das ist bei einer Sprache, die für Menschen lesbar ist (also auch bei jeder ernstzunehmenden Programmiersprache), eben so.

Und ja, ich stimme mit ursus insofern überein, dass das manuelle Editieren von JSON fehleranfällig sein kann – deswegen ist mir INI oder YAML (Übermenge von JSON) in so einem Fall lieber. Deswegen sehe ich aber keinen Grund, JSON nicht als Format für den Datenaustausch zu nehmen. Ich finde es ungemein praktisch, dass ich JSON weitestgehend ohne Hilfsmittel lesen kann oder es mir in einem besseren Editor schön formatiert anzeigen lassen kann. Und dann hat es einen geringen Overhead – im Vergleich zu XML beispielsweise.

Und nur um es noch mal zu sagen: Keiner hier hat irgendein Problem damit, dass du bestehendes in Frage stellst und dann deine Projekte und Ideen vorstellst. Aber dann musst du auch Kritik annehmen und darauf eingehen und sie nicht ignorieren oder behaupten, die anderen hätten keine Ahnung. Und ich finde die Kritik, die dir gegenüber geäußert wurde, weder destruktiv noch beleidigend. Sie wird eher rauer, weil du irgendwann leider anfängst, pampig zu werden.

Gruß
Patrick

[ursus contionabundo]

Und jetzt erklären die Kollegen aus derselben Fraktion wie man eine Datei mit 90 T Zeichen zweckmäßig bearbeitet.

Hehe. Das war nicht für Dich sondern ging an $oThread->getOpener();. Du warst mit

JSON.stringify(array,null,2) und in PHP gibts da sicher Ahnliches.

der Stichwortlieferant, der mich zu näheren Erklärungen über Grundlagen und den Praxiseinsatz verführte.

[pl]

Lieber Leser,

da gibt es einen extrem langen json-string. Dieser String kommt von einer Api, die ich abrufe. Er liefert Daten. Ich würde gerne diese Daten manuell bearbeiten. Um genauer zu sein möchte ich Teile aus diesem String löschen.

Zweckmäßiger ist es grundsätzlich dies auf der Ebene des Wahlfreien Zugriff zu tun: decode -> delete -> encode

Das funktioniert mit jeder Programmiersprache.

MfG

[T-Rex]

Ihr seid der Hammer! JSON_PRETTY_PRINT war genau was ich gebraucht hab. Und ich habe immer nur auf der Einlesen-Seite gesucht roll_eyes.

Ihr habt natürlich alle Recht. Würde man sowas dauerhaft machen wollen, ist die Methode die ich wähle absolut die falsche. Es geht jedoch nur darum max. 5 jsons zu manipulieren und zu speichern. Dann könnte ich bei Weiterentwicklungen des Scripts auf eine "offline" Datei ausweichen und muss nicht immer die Schnittstelle anfragen.

Danke und Gruß
Pretty T-Rex