Useresti matrici di byte o XML se la dimensione non era un problema?

È certamente possibile che le persone JPEG e PNG abbiano utilizzato intestazioni basate su XML se la dimensione del file non era un problema. Usare il testo renderebbe più ovvio ciò che significano tutti i campi e così via.

Ma per memorizzare i dati dei file effettivi, quasi certamente no. Gli elementi di dati delle immagini JPEG / PNG sono una sequenza di byte, non elementi XML che spiegano cosa significano questi dati. Quindi memorizzarlo come caratteri, anche in base64 o alcuni di questi, è semplicemente inutile. Rende l'elaborazione più lunga del necessario (dato che devi eseguire molte conversioni da testo a binario), e tutto a beneficio di nessuno. Non renderebbe più semplice la comprensione della porzione di dati; dovresti comunque cercare l'algoritmo di compressione vero e proprio.

In effetti, il tempo di elaborazione sarebbe probabilmente la ragione per evitare persino intestazioni XML. Certo, l'analisi del testo non è così costosa, ma non è quasi tanto economica quanto spargere dati in memoria, lanciare un puntatore e leggere una struttura.

Gli array di byte sono leggibili dall'uomo. Li ho letti da quando avevo 10 anni e sono stato umano più a lungo. Questo accadeva prima ancora di avere un editor esagonale di fantasia. I comandi Peek e Poke sono vecchi amici.

Che cosa offre un documento xml non è la leggibilità umana. Ti dà una codifica ragionevolmente prevedibile (ASCII, UTF-8, ecc.) Che ti permette di usare notepad o vi come editor, e ti fornisce meta informazioni proprio lì nel file.

L'immagine dell'editor esadecimale che hai postato sull'array di byte ha molte informazioni sulla meta. Questa meta informazione che hai aggiunto, usando un programma di pittura, semplicemente non è nell'array di byte. Tu sai solo quella informazione perché sai che questo è un JPEG e sai come sono strutturati i JPEG. Dovevi andare a dare un'occhiata in un documento di specifiche. A volte i programmatori non sono in grado di pubblicare e distribuire meta informazioni separatamente dal file di dati. È improbabile che il formato di file dei miei giochi con tick tick tack sia disponibile in qualunque momento in Wikipedia.

Essere in grado di tralasciare le meta-informazioni e poter usare ogni valore di un byte significa che gli array di byte sono più piccoli. Ma è un tipo O (0,6n) più piccolo. Se questo è davvero un problema, puoi sempre usare la compressione. Seriamente, la dimensione non è davvero il problema principale.

Guarda ad esempio i fogli elettronici excel. Cambia la loro estensione in .zip ed estraili e troverai una tonnellata di file xml nascosti sotto.

Un file di array di byte può essere strutturato dinamicamente come un file xml o json. Ma a meno che i marcatori di quella struttura dinamica non siano pubblicati da qualche parte, buona fortuna a capire la struttura.

La struttura JPEG è già ben nota, quindi convertila in XML in modo da poterla distribuire in quanto le meta-informazioni risolvono un problema.

Uso XML o JSON quando non ho voglia di pubblicare una specifica per definire la mia struttura. Io uso gli array di byte quando non mi interessa se qualcun altro capisce mai la mia struttura o quando capisco che la mia struttura è qualcosa che posso pubblicare.

Due cose:

1. I vantaggi del tuo schema sono piccoli e discutibili: sì, posso analizzare ed estrarre i metadati un po 'più facilmente. Ma hai solo bisogno di una sola libreria C per analizzare un formato immagine e quindi è un problema risolto.

2. Anche con le moderne dimensioni dell'immagine della larghezza di banda è una grande preoccupazione. Pensa a navigare su Facebook da un telefono cellulare: ci saranno centinaia di immagini costantemente caricate. Non vuoi che richieda più tempo e mangi attraverso il tuo piano dati perché gli sviluppatori hanno trovato questo formato XML moderatamente più facile da usare.

Tanto per sottolineare che differenza c'è: codificando i dati come una stringa esadecimale si usa 4 volte più spazio. In molti contesti è assolutamente inaccettabile e in realtà non ti compra molto.

L'esempio XML non è nemmeno un buon esempio, poiché stai ancora utilizzando un array di byte. Un 'vero' XML per un'immagine, in contrasto con gli array di byte, sarebbe qualcosa di simile a:

<s:Image xmlns="www.w3c.org" width="1000" height="600" bits="8">
   <s:pixels>
      <s:row>
         <pixel>000000<pixel>
         <pixel>000001<pixel>
         <pixel>000002<pixel>
      <s:row>
      <s:row>
         <pixel>000010<pixel>
         <pixel>000011<pixel>
         <pixel>000012<pixel>
      <s:row>
      ...
   </s:pixels>
</s:Image>

O qualche creazione empia simile. Anche se lo spazio su disco è economico, questo è un costo piuttosto serio di molte parentesi angolari. Ora sicuro, potresti .zip o comprimere il tuo file XML, ma poi stai introducendo un requisito per gli strumenti per vedere cosa succede con il file, quindi a quel punto potresti anche rendere il formato del file più sensato e avere strumenti per spostare il file dati nella giusta direzione.

Per approfondire una parte della risposta di Nicol Bolas , con un esempio dei formati di immagine o di qualsiasi cosa che comprenda la compressione, perdi istantaneamente qualsiasi tipo di aspetto leggibile dall'uomo, poiché migliore è la compressione, più il risultato è incomprensibile. Il formato che avevo nel mio esempio è un bitmap. Un jpeg non sarà leggibile in alcun formato, dal momento che i dati sono molto diversi da quelli matematici.

Un ulteriore comportamento che è possibile fare con gli array di byte, ma è impossibile con XML, è il trasferimento di dati in perdita. Comune nelle applicazioni di elaborazione dei segnali, a volte non è importante ed è necessario essere in grado di leggere, leggere e utilizzare un flusso di dati anche quando non tutti i bit vengono trasferiti correttamente. Lo streaming di video è una di queste applicazioni. Nel caso di un file XML questo non è accettabile in quanto manca un singolo bit in cui prevedi una chiusura ">" e l'intera struttura dei dati non verrà analizzata.