[OT] Ottavo bit... in pericolo?

[xshell]

Salve.

Sono ancora alle prese con la creazione di un nuovo formato di file che contenga le informazioni su oggetti 3D.

Per identificare il formato, ho deciso di inserire dei "bit firma", memorizzandoli in un array e, come suggerito da Oregon, scrivendoli con fwrite(). Mi sono documentato sulla creazione di un nuovo formato, ma ho letto che se si inserisse la "firma" di più di 7 bit e si volesse visualizzare l'oggetto 3D tramite email (aggiungendo ad esempio un apposito plug-in) il formato potrebbe non venire riconosciuto dai Client di posta, perché hanno "la brutta abitudine" di tagliare l'ottavo bit... le voci che mi sono giunte sono vere? Come potrei risolvere ciò? Sposto la firma "più in là" e inserisco dei bit a caso all'inizio?

[oregon]

Anche ammesso che qualche client possa avere difficoltà, che significa "spostare più in là" la firma? Basta che utilizzi valori che siano minori di 128 ...

Ad esempio, i file .exe (gli eseguibili) utilizzano le lettere

MZ

all'inizio di ogni file e basta ...

[LeleFT]

Al di là del fatto che non è un problema di programmazione, credo che il problema non sussista.
Quando viene allegato un oggetto (file, immagine, audio, ecc) ad una mail, generalmente questo "allegato" viene inserito utilizzando la codifica MIME Base64, che effettua una rappresentazione di ciascun gruppo di 3 byte su 4 byte. E' il client di posta che, successivamente, esegue una lettura dell'allegato e lo interpreta (ovviamente dopo una ri-traduzione).

Una banalissima controprova è data dal formato JPG che usa come "firma" la sequenza 0xFF 0xD8 0xFF. Mi risulta che la quasi totalità dei client riescano a riprodurre pacificamente le immagini in questo formato..


Ciao.

[xshell]

Originariamente inviato da oregon
Anche ammesso che qualche client possa avere difficoltà, che significa "spostare più in là" la firma? Basta che utilizzi valori che siano minori di 128 ...

Ad esempio, i file .exe (gli eseguibili) utilizzano le lettere

MZ

all'inizio di ogni file e basta ...

Sì, ma il client andrà comunque a bastonare qualche altro bit di qualche altra parte funzionale... mi conviene quindi spostare la firma, con tutto il resto, oltre l'ottavo bit o il problema non si pone perché le voci che ho sentito non sono veritiere? Avete sentito qualcosa a proposito? Il fatto è che vorrei far visualizzare un'immagine ruotabile attraverso mail... non come allegato, bensì direttamente...

Per avere un'idea di come poter strutturare un file, ho "spiato" vari sorgenti... tra cui PNG...

Un file PNG ha la firma: 137, 80, 78, 71, 13, 10, 26, 10...

I numeri decimali "80, 78 e 71" corrispondono esattamente all'ASCII "PNG"... il "137" è invece un numero rappresentabile con 8 bit... leggendo la documentazione, ho letto che serve per evitare problemi con i client... Quindi mi son chiesto: Perché? Quali sono questi problemi? Cerca, cerca e ricerca... Spunta che i client di posta "strip the 8th bit"...

@LeleFT: Quindi sarebbe "colpa" della codifica in Base64?

[LeleFT]

Originariamente inviato da xshell
@LeleFT: Quindi sarebbe "colpa" della codifica in Base64?

No: quindi il problema non sussiste. Non c'è nessuna perdita di informazione (grave sarebbe se ci fosse).

O forse non ho capito qual è l'effettivo problema?

Edit: ho riletto e credo che se il problema esistesse sarebbe limitato ad una schiera di vecchi client text-only... talmente vecchi che non sarebbero nemmeno in grado di riprodurre un'immagine, figurati degli oggetti 3d.


Ciao.

[oregon]

Sono d'accordo con Lele ... ma continuo a non capire il problema ...

Se hai un dubbio del genere (che non esiste), perchè non decidi di utilizzare valori minori di 128 e tagli la testa al toro?

Perche' complicarsi la vita?

[XWolverineX]

127?


Sorry per l'OT
Mi interessa il tuo tentativo di creare un formato 3D.
Sono alla continua ricerca di persone con passione per Real Time Rendering.
Se vuoi, contattami in PV

[xshell]

Originariamente inviato da XWolverineX
127?


Sorry per l'OT
Mi interessa il tuo tentativo di creare un formato 3D.
Sono alla continua ricerca di persone con passione per Real Time Rendering.
Se vuoi, contattami in PV

Penso che io non sia la persona più adatta ad una collaborazione. Ho ancora molto da imparare riguardo la programmazione. Diciamo piuttosto che sto facendo dei tentativi basati su codice in parte già scritto, studiandolo e rielaborandolo. Sto scrivendo (o meglio sto cercando di scrivere) un formato che abbia la capacità di interpretare files OBJ, 3DS e 3DM (Rhinoceros), in quest'ultimo caso basandomi sul codice della libreria OpenNurbs, di trasformarli in file BLEND (Blender) e di visualizzare gli oggetti 3D tramite mail. La libreria SDL di cui parlavo giorni fa, serve anche per gestire questi formati. Quindi non sto scrivendo un nuovo formato partendo da zero, perché non ne ho le capacità, ma una specie di formato-contenitore, per evitare le continue importazioni ed esportazioni di file tra programmi di grafica 3D. Per ogni singolo formato esistono librerie già belle e fatte, io le voglio riunire tutte in un nuovo formato, cercando di rendere un risultato omogeneo.

Comunque, se vuoi cimentarti nella creazione di un nuovo formato grafico, tutto tuo, posso consigliarti di partire dal formato BLEND di Blender (OpenSource), perché così puoi dare un'occhiata anche al sorgente del software completo. Se vuoi maggiori informazioni, scrivimi.

[xshell]

Originariamente inviato da oregon
Perche' complicarsi la vita?

Me lo sono chiesto anch'io... ma guardando la struttura di alcuni formati, come il PNG, mi sono domandato: e perché loro si sono comportati in questo modo? E se loro avessero scritto 137 solo perché gli stava simpatico il numero o perché nel loro studio hanno 137 computer o 137 formiche in giardino? E se invece avessero scelto quel numero onde evitare il sorgere di un determinato effetto collaterale (i client di posta, ad esempio)? Se poi aggiungiamo le varie tecniche per memorizzare i chunks... beh... per questo ho chiesto... in fin dei conti è solo una sottigliezza, ma non vorrei incappare in qualche grave errore dovuto alla mia ignoranza...

[LeleFT]

Io continuo a non capire dove sia il problema.
Se il "problema" è il client, non è un tuo problema e non lo risolvi.

Faccio un esempio. Prendiamo due client di posta elettronica: una webmail (tipo mail2web) e Microsoft Outlook.

Prendiamo un formato, ad esempio, il formato di Autocad.

Nella webmail non vedrai mai il disegno autocad: la webmail non è in grado di "interpretare" il formato autocad. Cosa accade? Semplice: la webmail ti mette a disposizione una "graffetta" per poter scaricare l'allegato. Lo scarichi e lo esegui sul tuo PC in locale, usando il motore per Autocad.

Microsoft Outlook: potrebbe esistere (non lo so perchè non conosco Autocad) un plug-in per Outlook che permette a quest'ultimo di visualizzare i file in tale formato. Cosa succede? Se apri una mail che contiene un allegato Autocad con Outlook equipaggiato col plug-in, vedi nella mail l'immagine 3D di Autocad. Altrimenti vedi una graffetta per scaricare l'allegato e aprirtelo comodamente con il motore Autocad installato sul PC.

Insomma, non esiste nessun problema dell'ottavo bit. Esistono client vecchi che non supportano codifiche su 8 bit, ma nessuno impedisce loro di farti scaricare l'allegato e di eseguirtelo comodamente con il tuo PC. Ma quegli stessi client non ti permetterebbero di visualizzare l'allegato nemmeno se la tua firma fosse fatta tutta di caratteri su 7 bit: non è un problema di "firma" o di "codifica". E' un problema di client, che non ha nulla a che vedere né con i formati, né con le firme, né con la quantità di bit di ciascun elemento.


Ciao.