Menyimpan data yang disandikan base64 sebagai tipe data BLOB atau TEXT

Seseorang tidak boleh menyimpan data yang disandikan Base64 dalam database seseorang...

Base64 adalah pengkodean di mana data biner arbitrer diwakili hanya menggunakan karakter teks yang dapat dicetak:ini dirancang untuk situasi di mana data biner tersebut perlu ditransfer melalui protokol atau media yang hanya dapat menangani teks yang dapat dicetak (misalnya SMTP/email). Ini meningkatkan ukuran data (sebesar 33%) dan menambah biaya komputasi encoding/decoding, sehingga harus dihindari kecuali benar-benar diperlukan.

Sebaliknya, inti dari BLOB kolom adalah bahwa mereka menyimpan string biner buram . Jadi, lanjutkan dan simpan barang Anda langsung ke BLOB kolom tanpa mengkodekan Base64 terlebih dahulu. (Yang mengatakan, jika MySQL memiliki tipe yang lebih cocok untuk data tertentu yang disimpan, Anda mungkin ingin menggunakannya sebagai gantinya:misalnya, file teks seperti sumber JavaScript dapat mengambil manfaat dari disimpan di TEXT kolom di mana MySQL secara asli melacak metadata khusus teks—selengkapnya tentang ini di bawah).

Gagasan (salah) bahwa database SQL memerlukan pengkodean teks yang dapat dicetak seperti Base64 untuk menangani data biner arbitrer telah diabadikan oleh sejumlah besar tutorial yang kurang informasi. Gagasan ini tampaknya didasarkan pada keyakinan yang salah bahwa, karena SQL hanya terdiri dari teks yang dapat dicetak dalam konteks lain, SQL pasti juga memerlukannya untuk data biner (setidaknya untuk transfer data, jika bukan untuk penyimpanan data). Ini sama sekali tidak benar:SQL dapat menyampaikan data biner dalam beberapa cara, termasuk literal string biasa (asalkan mereka dikutip dengan benar dan diloloskan seperti string lainnya); tentu saja, cara yang lebih disukai untuk meneruskan data (jenis apa pun) ke database Anda adalah melalui kueri berparameter, dan tipe data parameter Anda dapat dengan mudah berupa string biner mentah seperti yang lainnya.

...kecuali di-cache karena alasan kinerja...

Satu-satunya situasi di mana mungkin ada beberapa manfaat dari menyimpan data yang disandikan Base64 adalah di mana biasanya ditransmisikan melalui protokol yang memerlukan pengkodean tersebut (misalnya melalui lampiran email) segera setelah diambil dari database—dalam hal ini, menyimpan representasi yang disandikan Base64 akan menghemat dari keharusan melakukan operasi penyandian pada data mentah pada setiap pengambilan.

Namun, perhatikan dalam pengertian ini bahwa penyimpanan yang disandikan Base64 hanya bertindak sebagai cache , seperti halnya orang menyimpan data yang didenormalisasi karena alasan kinerja.

...dalam hal ini seharusnya TEXT bukan BLOB

Seperti disinggung di atas:satu-satunya perbedaan antara TEXT dan BLOB kolom adalah itu, untuk TEXT kolom, MySQL juga melacak metadata khusus teks (seperti pengkodean karakter dan kolasi ) untuk kamu. Metadata tambahan ini memungkinkan MySQL untuk mengonversi nilai antara kumpulan karakter penyimpanan dan koneksi (jika sesuai) dan melakukan operasi perbandingan/penyortiran string yang bagus.

Secara umum:jika dua klien yang bekerja dalam rangkaian karakter yang berbeda akan melihat byte yang sama , maka Anda menginginkan BLOB kolom; jika mereka melihat karakter yang sama maka Anda menginginkan TEXT kolom.

Dengan Base64, kedua klien tersebut pada akhirnya harus menemukan bahwa data mendekode ke byte yang sama; tetapi mereka akan melihat bahwa data yang disimpan/dikodekan memiliki karakter yang sama . Misalnya, seseorang ingin memasukkan pengkodean Base64 dari 'Hello world!' (yaitu 'SGVsbG8gd29ybGQh' ). Jika aplikasi penyisipan bekerja dalam rangkaian karakter UTF-8, maka itu akan mengirimkan urutan byte 0x53475673624738676432397962475168 ke basis data.

• jika urutan byte itu disimpan dalam BLOB kolom dan kemudian diambil oleh aplikasi yang bekerja di UTF-16, byte yang sama akan dikembalikan—yang mewakili '升噳扇㡧搲㥹扇全' dan bukan nilai yang disandikan Base64 yang diinginkan; sedangkan

• jika urutan byte itu disimpan dalam TEXT kolom dan kemudian diambil oleh aplikasi yang bekerja di UTF-16, MySQL akan melakukan transcode on-the-fly untuk mengembalikan urutan byte 0x0053004700560073006200470038006700640032003900790062004700510068 —yang mewakili nilai asli yang disandikan Base64 'SGVsbG8gd29ybGQh' sesuai keinginan.

Tentu saja, Anda tetap dapat menggunakan BLOB kolom dan lacak pengkodean karakter dengan cara lain—tetapi itu hanya akan menemukan kembali roda yang tidak perlu, dengan kompleksitas pemeliharaan tambahan dan risiko menimbulkan kesalahan yang tidak disengaja.