edEITcli - EIT Editor - CLI Version

  • Hallo *,


    Auf Wunsch habe ich eine CLI-Version von edEIT erstellt.
    Es handelt sich dabei um eine Konsolenanwendung, um Informationen aus .eit (und ggf. .meta) auszugeben.


    Was macht die Anwendung?


    edEITcli liest die angegebene .eit Datei (sofern vorhanden auch die zugehörige .ts.meta) und gibt ausgewählte Attribute daraus aus.
    Die Ausgabe kann an die Konsole und/oder als Datei ausgegeben werden.
    Bei Ausgabe in eine Datei wird im Quellverzeichnis der .eit eine neue Datei mit der Endung .json erstellt - ggf. überschrieben.


    Hinweis: Bei Windows werden in der DOS-Shell nur mit Schriftart "Consolas" alle Umlaute und Sonderzeichen richtig dargestellt.

    Änderung in Version 1.0.5:
    - Felder "Content" und "Description" wurden vertauscht, damit sie mit edEIT einheitlich sind.


    Änderung in Version 1.0.4:
    - Default Encoding für Consolenausgabe ist nun utf-8
    - Support für Content Descriptor erweitert
    - Support für Parental Rating Descriptor eingefügt


    Änderung in Version 1.0.3:
    - Default Encoding für Consolenausgabe ist nun iso-8859-15
    - Zusätzlicher Parameter "verbose" : Zeigt interpretierte Übergabeparameter an
    - Zusätzlicher Parameter "conenc=" : optional; Mögliche Werte "dos", "win" oder "utf8"; Zeichensatz für die Consolenausgabe



    md5: 0404b1f5f9c419a5828b41f7e27f1b2f


    PS: Wenn euch edEITcli gefällt, dann klickt doch bitte auf "Gefällt mir" Danke

  • Beispiel einer erzeugten JSON-Datei:


    Code
    {"UserID":null,"EventID":35940,"Starttime":"2017-01-20T23:30:00","Duration":50,"Language":"ger","Title":"Drogen im Visier","Description":"Alltag in London","Content":"3. Staffel, Folge 7: Kokain und Marihuana sind die Drogen für einige Londoner, die hart arbeiten und trotzdem ihren Spaß haben wollen. Auf den Straßen konkurrieren britische Drogenbosse mit osteuropäischen Verbrecherbanden, die in das Land strömen und ohne Rücksicht auf Verluste ins Kokaingeschäft drängen. Gleichzeitig versuchen die einheimischen Dealer, die gestiegene Nachfrage nach Marihuana zu bedienen - und zwar gemeinsam mit vietnamesischen Gangs, die durch an Sklaverei grenzende Ausbeutung in der Lage sind, ihre illegalen Geschäfte im industriellen Maßstab durchzuführen.\nGB 2012. 50 Min.","ServiceReference":"1:0:19:70:D:85:FFFF0000:0:0:0:","Tag":""}

    Beim Dateianhang bitte das ".txt" entfernen.

  • @QtHelex


    Die Version gibt mehr aus, als Du ursprünglich wolltest.
    Ich hoffe, das ist kein Problem für dich :winking_face:


    Fehlt die .ts.meta, dann ist das "Tag"-Attribut trotzdem da, allerdings mit Wert "null". Das entspricht dem JSON-Standard.
    Das Gleiche gilt für die UserID, wenn keine mitgegeben würde.

    Grüße
    ...jp

  • @QtHelex
    Die Version gibt mehr aus, als Du ursprünglich wolltest.
    Ich hoffe, das ist kein Problem für dich :winking_face:


    Mehr ist immer mehr! :grinning_squinting_face:


    Aber ich vermisse ein wenig "Language" und "Service Reference". Meiner Meinung nach durchaus verwertbare Daten.


    @QtHelex
    Fehlt die .ts.meta, dann ist das "Tag"-Attribut trotzdem da, allerdings mit Wert "null". Das entspricht dem JSON-Standard.
    Das Gleiche gilt für die UserID, wenn keine mitgegeben würde.


    Okay, war mir dessen nicht bewusst. Werde mal sehen wie ich dann im Detail damit umgehe, "null" mochte ich bei SQL schon nie. :winking_face:


    Ansonsten sieht das auf den ersten Blick schon verdammt gut aus. Hab jetzt nur 40 Minuten Zeit verplempert da ich in der Kommandozeile wie gewohnt den Parameter für den Dateinamen in " übergeben muss wegen den Leerzeichen, von meinem Programm aus komischerweise nicht, und mit den Pflichtgemäß eingefügten Anführungszeichen meinte Dein Programm partou "File not found". :upside_down_face:


    Hab morgen ne längere to-do Liste. Hoffe mich gegen Nachmittag nochmal hinsetzen zu können. Aber ich denke das parsen des JSON wird bestimmt reibungslos klappen. Nur das Feld "Starttime" gefällt mir persönlich gar nicht. Da wäre mir etwas regionalcode und international unmissverständlicheres deutlich lieber. Hab eben nachgelesen das JSON Datum und Zeit garnicht offiziell unterstützt, Sekunden seit 1.1.1970 0:00 UTC wäre mir aber fast am liebsten, meine zweite Wahl wäre ein Format nach ISO 8601. Da muss ich aber noch gucken ob ich das lesen kann https://stackoverflow.com/ques…he-right-json-date-format
    Eventuell wäre ein zweites Feld "Starttimestamp" eine option. Dann hat derjenige der dein edEITcli nutzt die Wahl.


    Auf jeden fall Herzlichen Dank schon mal! :thumbs_up:

  • Update V1.0.1 :winking_face:


    - Starttime sieht jetzt so aus: "Starttime":"2017-12-22T22:10:00"
    - Zusätzliche Attribute "Language" und "ServiceReference"

    Super, danke! :smiling_face:


    Hab nun auch ne Frühschicht eingeschoben und meine eigentliche To-Do-Liste für heute hinten angestellt... der Baumarkt macht eh erst um 8 Uhr auf. :winking_face::smiling_face_with_halo:


    Beim eingehenden Testen funktionierte bis auf ein Problem soweit alles astrein. Das Datum wird auch korrekt eingelesen. Ich muss nur was das starten in einem separaten Prozess angeht noch etwas optimieren... das läuft aktuell noch total aus dem Ruder. :upside_down_face:


    Ich würde nur vorschlagen das letzte Element "Tags" zu nennen statt "Tag", da hier ja mehrere Tags möglich sind.


    Zudem würde ich Vorschlagen darüber nachzudenken den Vorangestellten Copyrighthinweis bei den JSON Ausgabe weg zu lassen.
    Für mich kein Problem, da es überraschenderweise durch die aufgeteilte Ausgabe in 2 String Blöcken vollautomatisch rausgefiltert wird... aber ich könnte mir vorstellen das das bei anderen die eventuell mal dein edEITcli nutzen wollen zu Problemen führen könnte. Also für mich selbst macht es keinen Unterschied. :smiling_face:


    Ich habe nur noch ein Problem. Und das betrifft die Umlaute. Diese werden nicht korrekt eingelesen. :thinking_face:


    Nimmst Du da eventuell gerade noch ne Umwandlung vor bevor diese in den JSON Serializer geschoben werden? Mit Deinem clitest.exe hat es problemlos funktioniert gehabt.

  • Hi,


    Tag umzubenennen ist kein Problem. In der nächsten Version werde ich einen Schalter "quiet" mit einbauen, der die Anzeige der (c) Infos deaktiviert.
    Das ist alles easy.


    Zu dem Umlauten:
    Kannst Du das präzisieren?
    In der Anzeige (manuell gestartet) stimmt es doch, oder?
    So ganz kann ich nicht nachvollziehen, warum es auf einmal nicht mehr klappen sollte.
    Natürlich gibtes einen Unterschied zwischen clitest und edEITcli. Bei clitest waren es einfach Teststrings, bei edEITcli sind es die eingelesenen und i.d.R. CS-konvertierten Strings. Dennoch: edEITcli arbeitet intern mit Standard-WIN-Kodierung, von daher wundert es mich etwas.
    Hast Du mal Beispiele für mich?
    Es gibt bestimmte Zeichen, die in JSON zwingend codiert sein müssen. Gibt es z.B. in einem Text Anführungszeichen, dann würden die ohne Kodierung als Ende des Feldinhaltes interpretiert werden. Gleiches gilt - wenn ich es richtig gesehen habe - für z.B. das Zeichen '.
    Das ist aber wahrscheinlich nicht das, was zu meinst, oder?

    Grüße
    ...jp

  • Tag umzubenennen ist kein Problem. In der nächsten Version werde ich einen Schalter "quiet" mit einbauen, der die Anzeige der (c) Infos deaktiviert.
    Das ist alles easy.

    Ja, das ist schon im Bereich der Schönheitspolitur. :winking_face:


    Zu dem Umlauten:
    Kannst Du das präzisieren?
    In der Anzeige (manuell gestartet) stimmt es doch, oder?

    Ja, in der Konsole stimmt es.


    Genommen habe ich wieder die Terminator EIT Datei die ich Dir schon im anderen Thread als Beispiel schickte.


    Statt einem ö bekomme ich 0x94 hex, eventuell ist das encoding Windows-1252 oder ISO-8859-1? Bei der Interprätation als UTF8 ist sich mein debugger jedenfalls nicht mal sicher ob es 0x94 als positive (148) oder negative (-108) Dezimalzahl deuten soll. Ein erstes googeln ergab das 0x94 ohne zweites Byte davor wohl kein UTF8 Zeichen ist, kann das sein? Ein ö Zeichen müsste eigentlich 0xc3b6 hex sein, 2 Bytes.


    Es gibt bestimmte Zeichen, die in JSON zwingend codiert sein müssen. Gibt es z.B. in einem Text Anführungszeichen, dann würden die ohne Kodierung als Ende des Feldinhaltes interpretiert werden. Gleiches gilt - wenn ich es richtig gesehen habe - für z.B. das Zeichen '.

    Das Zeichen ' wird auch als \u0027 codiert in meinem ByteArray eingelesen und im String dann korrekt in ' umgewandelt. Ohne weiteres eingreifen. Nur die Umlaute nicht. Was das angeht hatte ich mit JSON da bisher unter Qt keine Probleme, alles schien vollautomatisch richtig zu laufen. Deshalb zweifle ich aktuell etwas ob das korrekt codiert ankommt bzw. gesendet wird... :confused_face:


    Nachtrag: Eben nachgesehen, die test.json Datei die Du mir geschickt hast und die ich problemlos einlesen konnte encodiert das ö auch als 0xC3 0xB6 hex.


    Nachtrag 2: Bei einer Ausgabe in eine Datei statt Konsole stimmt die kodierung des ö auch. Nur beim einlesen der Konsolenausgabe wird aus dem 0xc3b6 ö ein 0x94 hex. :loudly_crying_face:

    Einmal editiert, zuletzt von QtHelex ()

  • @QtHelex


    Probier' mal die neue v1.0.2.
    Ich habe die Ausgabe der Console auf iso-8559-1 (Win) umgestellt. Damit bleiben die Umlaute auch erhalten, wenn man die Ausgabe per ">" in eine Datei umleitet. Ich hoffe, dass dir das hilft.


    Ansonsten ist Tag wunschgemäß umbenannt und auch der "quiet"-Parameter umgesetzt.

    Grüße
    ...jp

  • @QtHelex


    Probier' mal die neue v1.0.2.
    Ich habe die Ausgabe der Console auf iso-8559-1 (Win) umgestellt. Damit bleiben die Umlaute auch erhalten, wenn man die Ausgabe per ">" in eine Datei umleitet. Ich hoffe, dass dir das hilft.

    Jupp, funktioniert. Muss das ganze jetzt zuerst von Latin1 (was iso-8559-1 entsprechen soll) nach UTF8 konvertieren. Sieht soweit gut aus, hoffe da gibt es zukünftig keine Überraschungen. Ich hasse dieses ganze Codierungs- und Zeichendurcheinander Thema. Was ich damit in der Vergangenheit schon an Zeit verplempert habe...


    @QtHelex
    Ansonsten ist Tag wunschgemäß umbenannt und auch der "quiet"-Parameter umgesetzt.

    Funktioniert beides bestens. Der quiet parameter macht jetzt in meinem Fall den unterschied, dass die Funktion um aus der Kommandozeilenausgabe auszulesen nur 1 mal statt wie bisher 2 mal aufgerufen wird. Der bisher erste Fehlversuch mit dem für JSON ungültigen Inhalt entfällt somit. Spart also ein wenig Rechenzeit.


    Vielen Dank! :smiling_face:


    Eine kleine Frage hätt ich da noch... Deine Änderungen waren jetzt aus meinem Blickwinkel betrachtet nicht überaus Umfangreich. Hast Du eine Idee weshalb Deine edEITcli.exe jetzt fast doppelt so groß wurde im vergleich zur vorherigen Version?

  • Hi,


    Ich könnte auch einen Schalter hinzufügen, um die Consolen-Ausgabe in UTF-8 auszugeben, wenn dir das eine Konvertierung erspart :winking_face:


    Der Größenzuwachs erklärt sich in erster Linie dadurch, dass edEITcli jetzt auch das edEIT-Icon enthält.

    Grüße
    ...jp

  • Ich könnte auch einen Schalter hinzufügen, um die Consolen-Ausgabe in UTF-8 auszugeben, wenn dir das eine Konvertierung erspart :winking_face:


    Oh, ich dachte das wäre bei der ersten Version schon der Fall gewesen, hätte nur nicht funktioniert? Ich dachte mal gelesen zu haben das JSON generell UTF8 codiert wäre. Kann aber gut sein das ich das falsch vermerkt hatte oder mit was verwechsle.


    Wir können das ja im Hinterkopf behalten falls es doch noch einen unerwarteten Fehler gibt oder ein anderer User der Dein Programm nutzt um seine EIT Dateien auszulesen Probleme bekommt.
    Alternativ hätte ich noch einen Plan B im Hinterkopf gehabt wenn alle Stricke gerissen wären. B wie Base64. Statt den Parameter JSON hättest Du noch als Alternative B64JSON einführen können, Sprich ein UTF8 JSON Base64 codiert ausgeben (in dem fall zwingend ohne Copyrighthinweis)
    http://www.vbarchiv.net/tipps/…se64-codierung-vbnet.html


    Auf diese Weise wäre (mit ziemlicher Sicherheit) Sichergestellt das Windows in der Konsole keinen zusätzlichen Zeichenkonvertierungsmist einbaut ohne das wir das merken.


    Ist aber denke ich jetzt beides nicht erforderlich. Passt auf den ersten Blick soweit alles.

    Der Größenzuwachs erklärt sich in erster Linie dadurch, dass edEITcli jetzt auch das edEIT-Icon enthält.


    LOL. Okay, darauf hatte ich gar nicht geachtet, das erklärt natürlich einiges. :winking_face_with_tongue:

  • Es gibt einen Unterschied zwischen der Konsolen- und der Dateiausgabe.
    Die Dateiausgabe erfolgt grundsätzlich in UTF-8, weil der JSON-Standard das so möchte.


    Bei der Konsolenausgabe verhält es sich anders.
    Win verwendet bei der Konsole standardmäßig Codepage 850 (Western European (DOS)), bei Win-Anwendungen ISO-8559-1 (Western European (ISO))
    Vor der v1.0.2 erfolgte die Konsolenausgabe in 850, nun in iso-8559-1.
    Es ließe sich aber auch z.B. auf UTF-8 oder andere umstellen.


    Die Überlegung war, ein Parameter "conenc=" einzufügen mit den Optionen "dos" (=850), "win" (=iso-8559-1) und "utf8".
    Damit könnte der Nutzer die Textausgabe selber nach Bedarf anpassen. Auf Wünsch könnten weitere Zeichensätze hinzugefügt werden.


    Aber nochmal: Das ist alles unabhängig der Dateiausgabe. Die erfolgt grundsätzlich in UTF-8.

    Grüße
    ...jp

  • Es gibt einen Unterschied zwischen der Konsolen- und der Dateiausgabe.
    Die Dateiausgabe erfolgt grundsätzlich in UTF-8, weil der JSON-Standard das so möchte.


    Naja, wenn das der JSON-Standard ist, dann frag ich mich weshalb die Konsolenausgabe standardmäßig falsch codiert ist?


    Die Dateiausgabe nutze ich wenn möglich nicht. Bin froh das ich die Konsolenausgabe direkt einlesen kann. Es würde für mich nicht sinn machen eine JSON Datei zu schreiben, einzulesen und direkt wieder zu löschen. Das reduziert nur die Lebensdauer meiner Hardware. :winking_face:


    Ich werd mal morgen mit Deinem neuen Parameter testen ob die UTF-8 Übergabe überhaupt sauber funktioniert. Nicht das da dann ein Zeichen (0x00h z.B.) das ganze scheitern lässt.

  • JSON hat nichts mit der Konsole zu tun.
    Oder anders gesagt: Für die Console gilt die eingestellte Codierung. Was auch immer ausgegeben wird, wird entsprechend gewandelt/konvertiert.
    Dass 850 Standard ist, dürfte den alten DOS Zeiten geschuldet sein.
    Ich bin ja schon froh, dass die Consolenkodierung geändert werden kann :winking_face:


    Hat es schon mit der 1.0.2 und iso-8859-1 geklappt?
    Oder hattest Du da immer noch Probleme mit den Umlauten?

    Grüße
    ...jp

  • Nein, iso-8859-1 hat geklappt. Ich muss aber extra nach UTF-8 umwandeln. Ein € Zeichen ist mir aber noch nicht untergekommen. :smiling_face:


    Ich werd mal sehen ob ich morgen kurz Zeit finde. Dann werd ich das gezielt testen und mit der 1.0.3 vergleichen.