Non si dovrebbero memorizzare dati con codifica Base64 nel proprio database...
Base64 è una codifica in cui i dati binari arbitrari sono rappresentati utilizzando solo caratteri di testo stampabili:è stato progettato per situazioni in cui tali dati binari devono essere trasferiti attraverso un protocollo o un supporto in grado di gestire solo testo stampabile (ad es. SMTP/e-mail). Aumenta la dimensione dei dati (del 33%) e aggiunge il costo computazionale della codifica/decodifica, quindi dovrebbe essere evitato a meno che non sia assolutamente necessario.
Al contrario, l'intero punto di BLOB colonne è che memorizzano stringhe binarie opache . Quindi vai avanti e archivia le tue cose direttamente nel tuo BLOB colonne senza prima codificarle in Base64. (Detto questo, se MySQL ha un tipo più adatto per i particolari dati archiviati, potresti voler utilizzare quello invece:ad esempio, file di testo come le sorgenti JavaScript potrebbero trarre vantaggio dall'essere archiviati in TEXT colonne per le quali MySQL tiene traccia in modo nativo dei metadati specifici del testo, maggiori informazioni di seguito).
L'idea (errata) che i database SQL richiedano codifiche di testo stampabile come Base64 per la gestione di dati binari arbitrari è stata perpetuata da un gran numero di tutorial male informati. Questa idea sembra risiedere nell'errata convinzione che, poiché SQL comprende solo testo stampabile in altri contesti, deve sicuramente richiederlo anche per i dati binari (almeno per il trasferimento dei dati, se non per l'archiviazione dei dati). Questo semplicemente non è vero:SQL può trasmettere dati binari in diversi modi, inclusi semplici valori letterali di stringa (a condizione che siano opportunamente quotati e sottoposti a escape come qualsiasi altra stringa); ovviamente, il modo migliore per passare dati (di qualsiasi tipo) al tuo database è attraverso query parametrizzate e i tipi di dati dei tuoi parametri possono essere facilmente stringhe binarie grezze come qualsiasi altra cosa.
...a meno che non sia memorizzato nella cache per motivi di prestazioni...
L'unica situazione in cui potrebbe esserci qualche vantaggio dall'archiviazione dei dati con codifica Base64 è quella in cui vengono solitamente trasmessi attraverso un protocollo che richiede tale codifica (ad esempio tramite allegato e-mail) immediatamente dopo essere recuperato dal database, nel qual caso, la memorizzazione della rappresentazione con codifica Base64 eviterebbe di dover eseguire l'operazione di codifica sui dati altrimenti grezzi ad ogni recupero.
Tuttavia, nota in questo senso che l'archiviazione con codifica Base64 agisce semplicemente come una cache , proprio come si potrebbero archiviare dati denormalizzati per motivi di prestazioni.
...in tal caso dovrebbe essere TEXT non BLOB
Come accennato sopra:l'unica differenza tra TEXT e BLOB colonne è quello, per TEXT colonne, MySQL tiene inoltre traccia dei metadati specifici del testo (come la codifica dei caratteri e confronto ) per te. Questi metadati aggiuntivi consentono a MySQL di convertire i valori tra i set di caratteri di archiviazione e connessione (ove appropriato) ed eseguire operazioni di confronto/ordinamento di stringhe fantasiose.
In generale:se due client che lavorano in set di caratteri diversi dovrebbero vedere gli stessi byte , allora vuoi un BLOB colonna; se dovessero vedere gli stessi caratteri allora vuoi un TEXT colonna.
Con Base64, questi due client devono infine scoprire che i dati decodificano negli stessi byte; ma dovrebbero vedere che i dati memorizzati/codificati hanno gli stessi caratteri . Ad esempio, supponiamo di voler inserire la codifica Base64 di 'Hello world!' (che è 'SGVsbG8gd29ybGQh' ). Se l'applicazione di inserimento funziona nel set di caratteri UTF-8, invierà la sequenza di byte 0x53475673624738676432397962475168 al database.
-
se quella sequenza di byte è memorizzata in un
BLOBcolonna e successivamente recuperato da un'applicazione che funziona in UTF-16, gli stessi byte verrà restituito, che rappresenta'升噳扇㡧搲㥹扇全'e non il valore codificato Base64 desiderato; mentre -
se quella sequenza di byte è memorizzata in un
TEXTcolonna e successivamente recuperato da un'applicazione che funziona in UTF-16, MySQL eseguirà la transcodifica al volo per restituire la sequenza di byte0x0053004700560073006200470038006700640032003900790062004700510068—che rappresenta il valore originale con codifica Base64'SGVsbG8gd29ybGQh'come desiderato.
Ovviamente puoi comunque usare BLOB colonne e traccia la codifica dei caratteri in qualche altro modo, ma ciò semplicemente reinventerebbe inutilmente la ruota, con una maggiore complessità di manutenzione e il rischio di introdurre errori non intenzionali.
