Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.python > #5342 > unrolled thread

[Python-de] Binärdaten in JSON

Back to article view | Back to de.comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [Python-de] Binärdaten in JSON Thomas Güttler <guettliml@thomas-guettler.de> - 2018-11-29 16:36 +0100
    Re: [Python-de] Binärdaten in JSON Thomas Orgelmacher <trash@odbs.org> - 2018-11-29 18:19 +0100
      Re: [Python-de] Binärdaten in JSON Arnold Krille <arnold@arnoldarts.de> - 2018-11-29 19:46 +0100
      Re: [Python-de] Binärdaten in JSON Thomas Güttler <guettliml@thomas-guettler.de> - 2018-11-30 09:48 +0100
        Re: [Python-de] Binärdaten in JSON Thomas Orgelmacher <trash@odbs.org> - 2018-11-30 19:24 +0100
        Re: [Python-de] Binärdaten in JSON Thomas Orgelmacher <trash@odbs.org> - 2018-11-30 19:37 +0100
      Re: [Python-de] Binärdaten in JSON Stefan Schwarzer <sschwarzer@sschwarzer.net> - 2018-11-30 11:27 +0100
      Re: [Python-de] Binärdaten in JSON Hardy Erlinger <hardy.erlinger@posteo.de> - 2018-11-30 11:40 +0100
      Re: [Python-de] Binärdaten in JSON Thomas Güttler <guettliml@thomas-guettler.de> - 2018-11-30 15:01 +0100
      Re: [Python-de] Binärdaten in JSON Thomas Jollans <tjol@tjol.eu> - 2018-12-03 10:21 +0100
      Re: [Python-de] Binärdaten in JSON Thomas Güttler <guettliml@thomas-guettler.de> - 2018-12-04 10:25 +0100
        Re: [Python-de] Binärdaten in JSON Thomas Güttler <guettliml@thomas-guettler.de> - 2018-12-13 12:14 +0100
          [Python-de] IFF Format: Dict? Thomas Güttler <guettliml@thomas-guettler.de> - 2018-12-14 09:04 +0100
            Re: [Python-de] IFF Format: Dict? Thomas Güttler <guettliml@thomas-guettler.de> - 2019-01-04 14:31 +0100
              Re: [Python-de] IFF Format: Dict? Thomas Orgelmacher <trash@odbs.org> - 2019-01-05 20:58 +0100
          Re: [Python-de] IFF Format: Dict? Armin Stross-Radschinski <developer@acsr.de> - 2018-12-14 10:31 +0100
          [Python-de] IFF Format Verwendung Christopher Arndt <chris@chrisarndt.de> - 2018-12-14 14:53 +0100
      Re: [Python-de] Binärdaten in JSON Stefan Behnel <python-de@behnel.de> - 2018-12-06 09:51 +0100

#5342 — [Python-de] Binärdaten in JSON

Hat jemand schon mal mit binären Daten in JSON gearbeitet?

Welche Lösungsvariante habt ihr gewählt?

V1: http://bsonspec.org/
V2: http://bjson.org/
V3: https://github.com/FasterXML/smile-format-specification
V4: ....

Gruß,
  Thomas


-- 
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

[toc] | [next] | [standalone]

#5343

Am 29.11.18 um 16:36 schrieb Thomas Güttler:
> Hat jemand schon mal mit binären Daten in JSON gearbeitet?
> 
> Welche Lösungsvariante habt ihr gewählt?
> 
> V1: http://bsonspec.org/
> V2: http://bjson.org/
> V3: https://github.com/FasterXML/smile-format-specification
> V4: ....

base64?


Gruß, Thomas

-- 
I have seen things you lusers would not believe.  I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.

[toc] | [prev] | [next] | [standalone]

#5344

[Multipart message — attachments visible in raw view] — view raw

On Thu, 29 Nov 2018 18:19:45 +0100 Thomas Orgelmacher <trash@odbs.org>
wrote:
> Am 29.11.18 um 16:36 schrieb Thomas Güttler:
> > Hat jemand schon mal mit binären Daten in JSON gearbeitet?
> > 
> > Welche Lösungsvariante habt ihr gewählt?
> > 
> > V1: http://bsonspec.org/
> > V2: http://bjson.org/
> > V3: https://github.com/FasterXML/smile-format-specification
> > V4: ....  
> 
> base64?

+1

Hihi, ich hab mal in einer Firma gearbeitet, da wurde zwischen Ruby und
Python kommuniziert indem Binär in Base64 in Yaml in ASN.1 in ZeroMQ
gemacht wurde;-) Historisch gewuchert halt.

- Arnold

[toc] | [prev] | [next] | [standalone]

#5349

Am 29.11.18 um 18:19 schrieb Thomas Orgelmacher:
> Am 29.11.18 um 16:36 schrieb Thomas Güttler:
>> Hat jemand schon mal mit binären Daten in JSON gearbeitet?
>>
>> Welche Lösungsvariante habt ihr gewählt?
>>
>> V1: http://bsonspec.org/
>> V2: http://bjson.org/
>> V3: https://github.com/FasterXML/smile-format-specification
>> V4: ....
> 
> base64?

Autofahrer an Polizist: Kann ich hier wenden?
Polizist an Autofahrer: Sie dürfen, wenn Sie es können.

Also wie ist das mit base64 gemeint? Wie ist das JSON ähnliches Datenformat,
welches auch binäre Daten übertragen kann?

Ich suche eine Lösung. Ein Datenformat. Ich suche nicht ein gebasteltes Work-around.

Gruß,
   Thomas


-- 
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

[toc] | [prev] | [next] | [standalone]

#5360

Am 30.11.18 um 09:48 schrieb Thomas Güttler:
> Am 29.11.18 um 18:19 schrieb Thomas Orgelmacher:
>>
>> base64?
> 
> Autofahrer an Polizist: Kann ich hier wenden?
> Polizist an Autofahrer: Sie dürfen, wenn Sie es können.
> 
> Also wie ist das mit base64 gemeint? Wie ist das JSON ähnliches Datenformat,
> welches auch binäre Daten übertragen kann?

Hättest Du es Dir angeschaut, wäre es klar gewesen.

Du kodierst Deine binären Daten mit base64 und packst sie dann in
einen JSON-String. Fertig. Und keine zusätzlichen Abhängigkeiten.


Gruß, Thomas

-- 
I have seen things you lusers would not believe.  I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.

[toc] | [prev] | [next] | [standalone]

#5361

XDR wäre auch noch eine Möglichkeit.

https://docs.python.org/3/library/xdrlib.html



Gruß, Thomas

-- 
I have seen things you lusers would not believe.  I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.

[toc] | [prev] | [next] | [standalone]

#5355

Hallo Thomas,

On 30/11/2018 09:48, Thomas Güttler wrote:
> Am 29.11.18 um 18:19 schrieb Thomas Orgelmacher:
>> Am 29.11.18 um 16:36 schrieb Thomas Güttler:
>>> Hat jemand schon mal mit binären Daten in JSON gearbeitet?
>>>
>>> Welche Lösungsvariante habt ihr gewählt?
>>>
>>> V1: http://bsonspec.org/
>>> V2: http://bjson.org/
>>> V3: https://github.com/FasterXML/smile-format-specification
>>> V4: ....
>>
>> base64?
> 
> Autofahrer an Polizist: Kann ich hier wenden?
> Polizist an Autofahrer: Sie dürfen, wenn Sie es können.
> 
> Also wie ist das mit base64 gemeint? Wie ist das JSON ähnliches Datenformat,
> welches auch binäre Daten übertragen kann?
> 
> Ich suche eine Lösung. Ein Datenformat. Ich suche nicht ein gebasteltes Work-around.

Deine Frage war "Hat jemand schon mal mit binären
Daten in JSON gearbeitet?"

Wenn man sich die von dir genannten Links nicht oder
nur flüchtig angeschaut hat, kann man deine Frage auch
durchaus so interpretieren, dass du binäre Daten
innerhalb von JSON übertragen willst.

Zu "Ich suche eine Lösung": Wir wissen ja gar nicht,
was dein konkretes Problem ist, außer "mit binären
Daten in JSON arbeiten."

Viele Grüße
Stefan

[toc] | [prev] | [next] | [standalone]

#5356

On 30.11.2018 11:27, Stefan Schwarzer wrote:
> Hallo Thomas,
>
> On 30/11/2018 09:48, Thomas Güttler wrote:
>> Am 29.11.18 um 18:19 schrieb Thomas Orgelmacher:
>>> Am 29.11.18 um 16:36 schrieb Thomas Güttler:
>>>> Hat jemand schon mal mit binären Daten in JSON gearbeitet?
>>>>
>>>> Welche Lösungsvariante habt ihr gewählt?
>>>>
>>>> V1: http://bsonspec.org/
>>>> V2: http://bjson.org/
>>>> V3: https://github.com/FasterXML/smile-format-specification
>>>> V4: ....
>>> base64?
>> Also wie ist das mit base64 gemeint? Wie ist das JSON ähnliches Datenformat,
>> welches auch binäre Daten übertragen kann?
>>
>> Ich suche eine Lösung. Ein Datenformat. Ich suche nicht ein gebasteltes Work-around.
> Zu "Ich suche eine Lösung": Wir wissen ja gar nicht,
> was dein konkretes Problem ist, außer "mit binären
> Daten in JSON arbeiten."
>
Exakt. Base64 ist kein Workaround. Damit kannst Du ganz ohne externe 
Libraries binäre Daten in JSON-Feldern serialisieren. Beispiel:

person = {
     'name': 'Luke Skywalker',
}
pic_content = pathlib.Path(pic_path).read_bytes()
person['picture'] = base64.encodebytes(pic_content).decode('ascii')

Das dict kann nun problemlos mit json.dumps() serialisiert werden. Das 
'picture'-Attribut ist reines ASCII. Es muss kein neues Binärformat 
eingeführt werden, beim Tracen der Messages zwischen Client und Server 
ist alles weiterhin JSON und damit sehr gut lesbar etc. etc.

Viele Grüße,
Hardy

[toc] | [prev] | [next] | [standalone]

#5359

Am 30.11.18 um 11:27 schrieb Stefan Schwarzer:
> Hallo Thomas,
> 
> On 30/11/2018 09:48, Thomas Güttler wrote:
>> Am 29.11.18 um 18:19 schrieb Thomas Orgelmacher:
>>> Am 29.11.18 um 16:36 schrieb Thomas Güttler:
>>>> Hat jemand schon mal mit binären Daten in JSON gearbeitet?
>>>>
>>>> Welche Lösungsvariante habt ihr gewählt?
>>>>
>>>> V1: http://bsonspec.org/
>>>> V2: http://bjson.org/
>>>> V3: https://github.com/FasterXML/smile-format-specification
>>>> V4: ....
>>>
>>> base64?
>>
>> Autofahrer an Polizist: Kann ich hier wenden?
>> Polizist an Autofahrer: Sie dürfen, wenn Sie es können.
>>
>> Also wie ist das mit base64 gemeint? Wie ist das JSON ähnliches Datenformat,
>> welches auch binäre Daten übertragen kann?
>>
>> Ich suche eine Lösung. Ein Datenformat. Ich suche nicht ein gebasteltes Work-around.
> 
> Deine Frage war "Hat jemand schon mal mit binären
> Daten in JSON gearbeitet?"
> 
> Wenn man sich die von dir genannten Links nicht oder
> nur flüchtig angeschaut hat, kann man deine Frage auch
> durchaus so interpretieren, dass du binäre Daten
> innerhalb von JSON übertragen willst.
> 
> Zu "Ich suche eine Lösung": Wir wissen ja gar nicht,
> was dein konkretes Problem ist, außer "mit binären
> Daten in JSON arbeiten."

Ja, sorry. Ich bin hier etwas genervt, weil die Grundlagen nicht klar sind.
JSON kann jeder. Aber binäre Daten darin zu übertragen geht leider nicht.
Mit base64 benötigt es einer expliziten Absprache und darum ist
es aus meiner Sicht ein work-around. Vermutlich wird es das werden.
Es kommt darauf an, was der Empfänger der Daten kann. Ich vermute
MessagePack werden die vermutlich nicht können. Aber vielleicht liege ich da auch falsch.

Ich finde es immer super, wenn es einen klaren Weg gibt. Also eine Art world-wide-agreement.
Wie bei zB JSON. Aber bis jetzt gibt es das hier noch nicht.

Gruß,
   Thomas




-- 
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

[toc] | [prev] | [next] | [standalone]

#5362

On 30/11/2018 15:01, Thomas Güttler wrote:
> 
> Ja, sorry. Ich bin hier etwas genervt, weil die Grundlagen nicht klar sind.
> JSON kann jeder. Aber binäre Daten darin zu übertragen geht leider nicht.
> Mit base64 benötigt es einer expliziten Absprache und darum ist
> es aus meiner Sicht ein work-around. Vermutlich wird es das werden.
> Es kommt darauf an, was der Empfänger der Daten kann. Ich vermute
> MessagePack werden die vermutlich nicht können. Aber vielleicht liege
> ich da auch falsch.

Base64 kann auch jeder, und die Absprache brauchst Du eh: ein
JSON-Datensatz ist schön und gut, man muss aber immer wissen, wie ein
bestimmtes JSON zu interpretieren ist. Was bedeuten die Felder? Ist ein
String eine URL, eine interne ID, ein Titel, eine Nachricht, oder was?
Je nachdem wie der Datensatz aufgebaut ist, kannst Du solche Sachen als
Mensch wahrscheinlich erraten, aber als Mensch kannst Du auch Base64
erkennen.

Je nachdem was Du überträgst, könntest Du auch Data-URIs in dem JSON
einbetten (… die dann wiederum Base64 für Binärdaten benutzen). Da ist
dann auch ein MIME-Typ drin.

Gruß
Thomas

> 
> Ich finde es immer super, wenn es einen klaren Weg gibt. Also eine Art
> world-wide-agreement.
> Wie bei zB JSON. Aber bis jetzt gibt es das hier noch nicht.
> 
> Gruß,
>   Thomas
> 
> 
> 
> 

[toc] | [prev] | [next] | [standalone]

#5363

Am 03.12.18 um 10:21 schrieb Thomas Jollans:
> On 30/11/2018 15:01, Thomas Güttler wrote:
>>
>> Ja, sorry. Ich bin hier etwas genervt, weil die Grundlagen nicht klar sind.
>> JSON kann jeder. Aber binäre Daten darin zu übertragen geht leider nicht.
>> Mit base64 benötigt es einer expliziten Absprache und darum ist
>> es aus meiner Sicht ein work-around. Vermutlich wird es das werden.
>> Es kommt darauf an, was der Empfänger der Daten kann. Ich vermute
>> MessagePack werden die vermutlich nicht können. Aber vielleicht liege
>> ich da auch falsch.
> 
> Base64 kann auch jeder, und die Absprache brauchst Du eh: ein
> JSON-Datensatz ist schön und gut, man muss aber immer wissen, wie ein
> bestimmtes JSON zu interpretieren ist.

In diesem konkreten Fall reiche ich die Daten einfach durch.
Ich erhalte per SAP-RFC eine Datenstruktur und geben diese als JSON
aus. SAP-RFC kann mit binären Daten umgehen. Schön wäre eine generische Lösung.
Die scheitert gerade daran, dass man dann wieder programmieren muss:

  "if blablabla, dann die Daten erst noch per base64 verwurschteln ..."

Wäre wirklich super, wenn ich meinem Kunden sagen könnte:

Wir nehmen JSON++ (gibt es nicht, der Name ist erfunden) und fertig.

> Je nachdem was Du überträgst, könntest Du auch Data-URIs in dem JSON
> einbetten (… die dann wiederum Base64 für Binärdaten benutzen). Da ist
> dann auch ein MIME-Typ drin.

Es gibt tausend work-Arounds (wie zb base64 selber erstellen) und
hundert alternative JSON-Formate.

In zehn Jahren werden wir wissen welches Format das Rennen gemacht hat.

Aktuell ist das für mich noch nicht abzusehen.

Gruß,
   Thomas



-- 
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

[toc] | [prev] | [next] | [standalone]

#5366

Am 07.12.18 um 02:08 schrieb Stefan Ram:
> =?UTF-8?Q?Thomas_G=c3=bcttler?= <guettliml@thomas-guettler.de> writes:
>> "if blablabla, dann die Daten erst noch per base64 verwurschteln ..."
> 
>    Du kannst ja einfach /alle/ Daten (auch die Textdaten)
>    base64-kodieren. Dann brauchst Du kein "if".
> 
>> Wäre wirklich super, wenn ich meinem Kunden sagen könnte:
>> Wir nehmen JSON++ (gibt es nicht, der Name ist erfunden) und fertig.
> 
>    Dann nenne das Verfahren, bei dem alle Daten base64-kodiert
>    werden, "JSON64".

Ich suche nach einem Datenformat, dass mehr oder weniger etabliert ist.



-- 
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

[toc] | [prev] | [next] | [standalone]

#5368 — [Python-de] IFF Format: Dict?

Am 13.12.18 um 16:06 schrieb Stefan Ram:
> =?UTF-8?Q?Thomas_G=c3=bcttler?= <guettliml@thomas-guettler.de> writes:
>> Am 07.12.18 um 02:08 schrieb Stefan Ram:
>>> =?UTF-8?Q?Thomas_G=c3=bcttler?= <guettliml@thomas-guettler.de> writes:
>>>> "if blablabla, dann die Daten erst noch per base64 verwurschteln ..."
>>> Du kannst ja einfach /alle/ Daten (auch die Textdaten)
>>> base64-kodieren. Dann brauchst Du kein "if".
>>>> Wäre wirklich super, wenn ich meinem Kunden sagen könnte:
>>>> Wir nehmen JSON++ (gibt es nicht, der Name ist erfunden) und fertig.
>>> Dann nenne das Verfahren, bei dem alle Daten base64-kodiert
>>> werden, "JSON64".
>> Ich suche nach einem Datenformat, dass mehr oder weniger etabliert ist.
> 
>    Dann nimm doch IFF. Das wird sogar mit dem Modul "chunk.py"
>    schon von der Python-Standardbibliothek unterstützt.

Wie kann man ein Python Dictionary in IFF speichern/laden?

Gruß,
   Thomas

-- 
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

[toc] | [prev] | [next] | [standalone]

#5381 — Re: [Python-de] IFF Format: Dict?

Noch mal kurz langsam.
Dieser Thread geht um ein passendes Datenformat. Sicherlich
kann man da nun ganz viel programmieren, aber das will ich ganz
bewusst nicht tun. Wenn ich für die Lösung programmieren muss,
dann muss es wohl auch der Empfänger der Daten.
Das würde ich gerne vermeiden.

Gruß,
   Thomas

Am 14.12.18 um 22:10 schrieb Stefan Ram:
> =?UTF-8?Q?Thomas_G=c3=bcttler?= <guettliml@thomas-guettler.de> writes:
>> Wie kann man ein Python Dictionary in IFF speichern/laden?
> 
>    Ich habe mal angefangen, als Beispiel eine Methode
>    »write_CHRS« zu schreiben, die einen Python-String
>    als CHRS-Chunk in eine Datei schreibt. Danach lese
>    ich diesen wieder mit dem Modul "chunk" ein.
> 
>    Ich weiß aber nicht, ob ich jemals dazu komme, jetzt
>    noch darauf aufbauend das für ein Dictionary zu schreiben.
> 
>    main.py
> 
> class chunk():
>        def __init__( my, type=None, size=None ):
>            my.type = type
>            my.size = size
> 
> class chunk_CHRS( chunk ):
> 
>        class size_too_large( Exception ):
>              pass
> 
>        class unprepared_write_attempt( Exception ):
>              pass
> 
>        class no_text_given( Exception ):
>              pass
> 
>        def __init__( my, text=None ):
>            chunk.__init__( my, b'CHRS', None )
>            my.set_text( text )
> 
>        def set_text( my, text=None ):
>            my.text = text
>            my.data = None
>            my.prepared = False
> 
>        def prepare_for_writing( my ):
>            if my.text == None: raise no_text_given()
>            my.data = my.text.encode( 'utf-8' )
>            l = len( my.data )
>            if l > 2**32-1: raise size_too_large()
>            my.size = l
>            my.prepared = True
> 
>        def write_to_file( my, file ):
>            if not my.prepared: raise unprepared_write_attempt()
>            if my.size > 2**32-1: raise size_too_large()
>            file.write( my.type )
>            file.write( my.size.to_bytes( 4, byteorder='big', signed=False ))
>            file.write( my.data )
> 
> def write_CHRS( file, text ):
>      chunk = chunk_CHRS( text )
>      chunk.prepare_for_writing()
>      chunk.write_to_file( file )
> 
> with open( 'test20181214215507.txt', 'wb' ) as file:
>       write_CHRS( file, 'example' )
> 
> import chunk
> 
> with open( 'test20181214215507.txt', 'rb' ) as file:
>       c = chunk.Chunk( file )
>       print( c.getname() )
>       print( c.getsize() )
>       print( c.read( c.getsize() ))
>       c.close()
> 
>    transcript
> 
> b'CHRS'
> 7
> b'example'
> 
> _______________________________________________
> python-de maillist  -  python-de@python.org
> https://mail.python.org/mailman/listinfo/python-de
> 

-- 
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

[toc] | [prev] | [next] | [standalone]

#5382 — Re: [Python-de] IFF Format: Dict?

Am 04.01.19 um 14:31 schrieb Thomas Güttler:
> Noch mal kurz langsam.
> Dieser Thread geht um ein passendes Datenformat. Sicherlich
> kann man da nun ganz viel programmieren, aber das will ich ganz
> bewusst nicht tun. Wenn ich für die Lösung programmieren muss,
> dann muss es wohl auch der Empfänger der Daten.
> Das würde ich gerne vermeiden.

Es gibt keine nicht triviale Kommunikation ohne vorherige Vereinbarung.
Selbst bei internationalen genormten und wirklich viel genutzten Dingern
wie EDIFACT funktioniert das NICHT.

Ich verstehe Deinen Wunsch wirklich sehr gut, aber Deine Anforderungen
werden so nicht realisierbar sein.

Am ehesten sehe ich da XML. Damit kannst Du Art und Typ Deiner Daten klar
(z.B. über Attribute: type und encoding z.B.) klassifizieren. Damit hast
Du ein eindeutiges Format und eben Arbeit auf beiden Seiten. Aber eben
wohldefiniert.
Und: wenn das Schema gut ausgearbeitet ist, ist das Arbeit, die man genau
einmal macht. Vielleicht kannst Du Deinen Kommunikations-Partnern ja einfach
eine Library zur Verfügung stellen?

Kannst Du vielleicht mal ein paar Hintergründe bringen? Z.B. was die
Kommunikations-Partner oder die Daten an sich angeht?

Vielleicht gibt es ja einen ganz anderen Ansatz...


Gruss, Thomas

-- 
I have seen things you lusers would not believe.  I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.

[toc] | [prev] | [next] | [standalone]

#5369 — Re: [Python-de] IFF Format: Dict?

[Multipart message — attachments visible in raw view] — view raw

IFF ist so etabliert, dass es fast keiner mehr kennt und nur noch als AIFF herumgeistert. (Oder habe ich etwas übersehen?).

(Antworten separat erbeten)

Das geniale am IFF ist die fast universelle Konzeption als Containerformat, dass für jeden Chunk den man hinten dranschreibt andere Payloads verstauen kann und nahezu jede Art von Daten mixen kann. Allerdings muss der Partner (Kunde) das auch beherrschen. Für jede Art von Chunk konnte man früher bei Electronic Arts (Ja die!) einen 4-Letter Code für den Chunk beantragen und reserviert registrieren. Ob das noch lebt, weiß ich nicht.

Wenn Du das Format beim Kunden selbst etablieren kannst ist es eine tolle Sache. Du kannst sogar die Binärdaten und Plaintext Version im selben File zusammen liefern, so kann man effektiv laden und doch ohne dekodieren Volltext indizieren etc.

Ich sehe aber bei Deinem UseCase keinen Vorteil. Ich beschäftige mich seit Jahrzehnten mit langfristiger Datenarchivierung > 20 Jahre. Ich empfehle dir daher den gesamten Lifecycle der Daten als Userstory aufzuschreiben, um die Requirements zu überblicken. Einfach dem Mainstream hinterherlaufen ist Blödsinn, sonst kommt ja nichts besseres mehr.

Wenn das Fire & Forget Daten sind die nicht archiviert oder protokolliert werden müssen (Blockchain? bewahre uns davor!). Würde ich mich eher auf saubere Dokumentation und Testing (Unicode, ByteOrder, Float Precision, l10n bei Units, Import Konvertierung etc.) konzentrieren. Hier passieren die meisten Fehler, weil die Leute Specs und Beispieldaten nicht auseinanderhalten können und nur Ihre Welt sehen. (Hat doch mal funktioniert..., Amis am Hebel).

my 2 Cent

> Am 14.12.2018 um 09:04 schrieb Thomas Güttler <guettliml@thomas-guettler.de>:
> 
> 
> 
> Am 13.12.18 um 16:06 schrieb Stefan Ram:
>> =?UTF-8?Q?Thomas_G=c3=bcttler?= <guettliml@thomas-guettler.de> writes:
>>> Am 07.12.18 um 02:08 schrieb Stefan Ram:
>>>> =?UTF-8?Q?Thomas_G=c3=bcttler?= <guettliml@thomas-guettler.de> writes:
>>>>> "if blablabla, dann die Daten erst noch per base64 verwurschteln ..."
>>>> Du kannst ja einfach /alle/ Daten (auch die Textdaten)
>>>> base64-kodieren. Dann brauchst Du kein "if".
>>>>> Wäre wirklich super, wenn ich meinem Kunden sagen könnte:
>>>>> Wir nehmen JSON++ (gibt es nicht, der Name ist erfunden) und fertig.
>>>> Dann nenne das Verfahren, bei dem alle Daten base64-kodiert
>>>> werden, "JSON64".
>>> Ich suche nach einem Datenformat, dass mehr oder weniger etabliert ist.
>>   Dann nimm doch IFF. Das wird sogar mit dem Modul "chunk.py"
>>   schon von der Python-Standardbibliothek unterstützt.
> 
> Wie kann man ein Python Dictionary in IFF speichern/laden?
> 
> Gruß,
>  Thomas
> 
> --
> Thomas Guettler http://www.thomas-guettler.de/
> I am looking for feedback: https://github.com/guettli/programming-guidelines
> _______________________________________________
> python-de maillist  -  python-de@python.org
> https://mail.python.org/mailman/listinfo/python-de

[toc] | [prev] | [next] | [standalone]

#5370 — [Python-de] IFF Format Verwendung

Am 14.12.18 um 10:31 schrieb Armin Stross-Radschinski:
> IFF ist so etabliert, dass es fast keiner mehr kennt und nur noch als AIFF herumgeistert. (Oder habe ich etwas übersehen?).

IFF in Reinform vielleicht weniger, aber Varianten davon begegnet man
überall. Der wichtigste Vertreter zahlenmäßig ist wohl der Abkömmling
RIFF (little-endian), der insbesondere beim WAV-Format verwendet wird.
Aber auch bei Soundfonts, File-Datenbanken, Videodateien, usw.

Und die Chunks bei PNG sind im Prinzip auch wie bei IFF, nur dass sie
man Ende noch eine CRC Summe haben.


Gruß, Chris

[toc] | [prev] | [next] | [standalone]

#5364

Thomas Güttler schrieb am 04.12.18 um 10:25:
> Es gibt tausend work-Arounds (wie zb base64 selber erstellen) und
> hundert alternative JSON-Formate.
> 
> In zehn Jahren werden wir wissen welches Format das Rennen gemacht hat.
> 
> Aktuell ist das für mich noch nicht abzusehen.

So ist das halt, wenn jemand ein neues Datenformat erfindet, das "total
viel einfacher" als alles andere ist, und sich dann herausstellt, dass es
nur deshalb "total viel einfacher" ist, weil alles, was die anderen Formate
halt mit der Zeit an notwendigen Features entwickelt haben, auch deren
Komplexität erhöht hat. Also wird noch schnell alles an Features
drangeklatsch, was die anderen Formate schon haben, und – hoppsa – schon
brauchen wir ein neues Datenformat, das endlich alles "total viel
einfacher" macht.

https://xkcd.com/927/

Stefan

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.lang.python

csiph-web