Italian Image su db MySQL

Elric

Well-Known Member
Licensed User
Ciao,

qual è il modo più veloce e semplice per caricare un'immagine/blob in un db MySQL?

L'obiettivo è avere un db online che viene poi scaricato in locale in SQLite per poter funzionare anche offline.

Grazie in anticipo!
 

sirjo66

Well-Known Member
Licensed User
Longtime User
potresti convertire l'immagine in base64, salvarla quindi come una stringa
poi per leggerla fai l'operazione inversa, la leggi come una stringa, fai il decode64 e te la ritrovi nello stesso formato
 

Elric

Well-Known Member
Licensed User
C'ho provato (come da allegato).

In linea di massima pare funzionare.

Il db ce l'ho in ODT ODS e carico il file ODT ODS in MySQL.

Se la stringa che mi genera il progetto allegato la copio su blocco note o altrove, nessun problema, poi me la riconosce.

Se la copio i una cella del file ODT ODS, do invio, poi riaccedo alla cella, la ricopio e la riconverto mi dà errore.
 

Attachments

  • ImageIntoString.zip
    10.2 KB · Views: 186
Last edited:

Elric

Well-Known Member
Licensed User
Se la copio i una cella del file ODT ODS, do invio, poi riaccedo alla cella, la ricopio e la riconverto mi dà errore.

L'errore è questo:
B4X:
WARNING: Corrupt JPEG data: premature end of data segment
 
Last edited:

LucaMs

Expert
Licensed User
Longtime User
Non hai allegato la parte di codice che genera l'errore, o sbaglio?

Il db ce l'ho in ODT e carico il file ODT in MySQL.
Eh? Traduzione?


NOTE:

1 - Puoi usare:
B4X:
strFilePath = File.GetFileParent(myPathAndFile)
strFileName = File.GetName(myPathAndFile)

2 - specifica che il progetto è B4J, la prossima volta; il primo che ho aperto è B4A ?
 

Elric

Well-Known Member
Licensed User
Non hai allegato la parte di codice che genera l'errore, o sbaglio?
Teoricamente il programma allegato in B4J funziona. O meglio: se la stringa generata la copio direttamente nella view dedicata all'input per la conversione oppure la incollo in BloccoNote e dal BloccoNote la copio e la incollo nella view dedicata all'input per la conversione, non ho nessuno errore.

L'errore:
B4X:
lug 03, 2022 6:18:59 PM com.sun.javafx.tk.quantum.PrismImageLoader2$PrismLoadListener imageLoadWarning
WARNING: Corrupt JPEG data: premature end of data segment
me lo genera se copio la stringa generata dentro una cella di un file ODS e da questa cella la ricopio e la incollo nella view dedicata all'input per la conversione - oppure se la inserisco mediante un UPDATE direttamente nel db MySQL e poi la scarico, la inserisco dentro un db SQLite e da qui cerco di fargliela interpretare:
B4X:
    Private Buffer64 As String = ResultSet2.GetString("Immagine")
    Private su As StringUtils
    Private Buffer() As Byte
    Buffer = su.decodeBase64(Buffer64)
    B4XImageView1.Bitmap = BytesToImage(Buffer)

Elric said:
Il db ce l'ho in ODT ODS e carico il file ODT ODS in MySQL.

Eh? Traduzione?
Ho sbagliato! ?

Il formato file è "ODS" - OpenDocument Spreadsheet. Quando devo rimaneggiare un corposo DB di solo testo o numeri, ci metto meno a lavorarlo in LibreOffice, salvarlo in ods e poi importarlo su MySQL.

NOTE:

1 - Puoi usare:
B4X:
strFilePath = File.GetFileParent(myPathAndFile)
strFileName = File.GetName(myPathAndFile)
Ok, thanks!
2 - specifica che il progetto è B4J, la prossima volta; il primo che ho aperto è B4A ?
Be', la domanda è multipiattaforma! ...

Si, sorry, tieni ragggione!
 

LucaMs

Expert
Licensed User
Longtime User
Alura...

1 - non sapevo cosa fosse un file ODS (presumibilmente: file ODIOSO ?)
2 - se non ho un file di quel tipo e nemmeno modo di aprirlo/gestirlo, non posso darti una mano (se non, forse, cercando un tool che funzioni online, non ho certo intenzione di installarne)
3 - salvando in quel modo, "JPEG", ovviamente non ti funzionerà se l'utente dovesse scegliere una PNG (o, meglio, perderesti la trasparenza)
4 - la domanda era: come salvare un'immagine su MySQL. Ha riposto bene @sirjo66: la salvi come stringa Base64. In un campo di testo! Che poi tu non riesca a trasformarla nuovamente in immagine, una volta scaricata dal DB, in un file di tipo particolare, è tutta un'altra faccenda (e potresti, forse dovresti, aprire un nuovo thread, al riguardo); anche in Excel, non è che puoi incollare in una cella una stringa Base64 e ti venga visualizzata come immagine! Vorrà dire che scaricherai la stringa Base64 da MySQL, la decodificherai, salverai l'immagine su file e la importerai in una cella del tuo ODS.
 
Last edited:

sirjo66

Well-Known Member
Licensed User
Longtime User
Quando trasformi una serie di byte in Base64 ti trovi una stringa che è 1,333 volte più grande della serie di byte originale.
Se prendi ad esempio un file JPG lungo 10000 byte e lo trasformi in Base64 ti troverai una stringa lunga 13333 caratteri.
Da come esponi il problema mi viene da pensare che quando copi-incolli sul file ODS la tua stringa venga troncata e che perdi la parte finale del file JPG, questo si capisce anche dall'errore che risulta.

Probabilmente il campo stringa del file ODS ha un limite, e quindi ti tronca i dati.
Come lo hai dimensionato il campo sul file ODS ??
Quanto è lunga la tua stringa in Base64 ??
 

udg

Expert
Licensed User
Longtime User
Ciao, presumo mi sia sfuggito qualcosa, ma perché convertire l'immagine in B64 quando sia MySql che Sqlite hanno il tipo dati BLOB?
Non è sufficiente immagazzinare nel campo BLOB l'array di byte che forma l'immagine ?

Un'altra considerazione è la solita: non sarebbe meglio avere i file in una cartella del server ed inserirne i soli riferimenti nel DB?
L'app client potrebbe scaricare solo quelli che non ha ancora in locale (un accesso Internet deve averlo comunque per scaricare il DB "aggiornato", quindi perché non i singoli file mancanti/aggiornati?)
Oppure pensare ad un tool sul server che "impacchetti" i file immagine sul DB (da byte array a BLOB) e poi renda diponibile il DB (magari già nella versione Sqlite)

Alcune scelte dipendono dal tipo di applicazione. Ad esempio, se le immagini sono gli avatar di centinaia di possibili utenti oppure una decina di "categorie" di cibi, etc
Così come la frequenza di aggiornamento delle immagini, intesa sia come sostituzione con immagini più recenti dello stesso oggetto che inserimento/rimozione di immagini.

Come giustamente faceva notare @sirjo66 l'utilizzo del formato B64 incrementa notevolmente lo spazio occupato da un'immagine. Quindi se parliamo di fotografie scattate con i più moderni cellulari alle pazzesche risoluzioni di oggi..ci penserei due volte. Facciamo tre.
 

Elric

Well-Known Member
Licensed User
Intanto grazie a tutti!

Poi ho riportato la mia esperienza (fallimentare) con il file ODS etc. Riporto anche l'esperienza fallimentare di usare le stringhe in B64 perché se l'immagine è poco-poco più grande, non si riesce a caricare neanche direttamente mediante phpmyadmin (che per immagini sotto una certa dimensione funziona).

La domanda originaria è: voi come fate e/o come consigliate di fare?

Caricare file immagine separati senza averli tutti nel db è l'unica via percorribile?
 

sirjo66

Well-Known Member
Licensed User
Longtime User
La domanda originaria è: voi come fate e/o come consigliate di fare?

Come già spiegato da @udg ...

Le immagini si memorizzano nel database solo se sono immagini piccole e non sono molte (ad esempio immagini avatar o cose del genere)
La soluzione preferita è quella di avere le immagini in una cartella (o più cartelle, dipende da quante sono), e nel database metti solamente il nome del file.

Se sei in locale ti basta fare una cartella condivisa e i client si prendono il file dalla cartella, ma se vuoi proteggere meglio la cosa si possono usare altri sistemi, come ad esempio un server PHP con un banalissimo script che recupera l'immagine e lo trasmette al client.

Se sei collegato su rete pubblica, ti conviene avere un server su internet (ce ne sono anche di gratuiti) dove mettere tutte le immagini e il client, una volta recuperato il nome del file dal database, va a prelevarsi l'immagine tramite internet.
Questa soluzione è la migliore nel caso di molte immagini perchè sgravi un sacco di lavoro dal tuo server locale (quello che ha il database) il quale non dovrà quindi gestire anche la condivisione delle immagini.
 
Cookies are required to use this site. You must accept them to continue using the site. Learn more…