Съхраняване на кодирани в base64 данни като тип данни BLOB или TEXT

Човек не трябва да съхранява данни, кодирани от Base64 в базата данни...

Base64 е кодиране, в което произволни двоични данни се представят с помощта само на текстови знаци за печат:той е проектиран за ситуации, при които такива двоични данни трябва да се прехвърлят през протокол или носител, който може да обработва само текст за печат (например SMTP/имейл). Това увеличава размера на данните (с 33%) и добавя изчислителните разходи за кодиране/декодиране, така че трябва да се избягва, освен ако не е абсолютно необходимо.

За разлика от това, цялата цел на BLOB колони е, че съхраняват непрозрачни двоични низи . Така че просто продължете и съхранявайте нещата си директно във вашия BLOB колони без първо Base64-кодирането им. (Това каза, че ако MySQL има по-подходящ тип за конкретните данни, които се съхраняват, може да искате да го използвате вместо това:например текстови файлове като JavaScript източници могат да се възползват от съхраняването им в TEXT колони, за които MySQL по естествен начин проследява специфичните за текст метаданни – повече за това по-долу).

(Погрешната) идея, че SQL бази данни изискват кодиране на текст за печат като Base64 за обработка на произволни двоични данни, се поддържа от голям брой зле информирани уроци. Тази идея изглежда се основава на погрешното убеждение, че тъй като SQL съдържа само текст за печат в други контексти, той със сигурност трябва да го изисква и за двоични данни (поне за трансфер на данни, ако не и за съхранение на данни). Това просто не е вярно:SQL може да предава двоични данни по редица начини, включително обикновени низови литерали (при условие, че са правилно кавички и екранирани като всеки друг низ); разбира се, предпочитаният начин за предаване на данни (от всякакъв тип) към вашата база данни е чрез параметризирани заявки и типовете данни на вашите параметри могат също толкова лесно да бъдат необработени двоични низове, както и всичко друго.

...освен ако не е кеширан от съображения за производителност...

Единствената ситуация, в която може да има някаква полза от съхраняването на Base64-кодирани данни, е, когато те обикновено се предават през протокол, изискващ такова кодиране (например чрез прикачен файл към имейл) непосредствено след се извлича от базата данни – в този случай съхраняването на Base64-кодирано представяне би спестило необходимостта от извършване на операцията по кодиране на иначе необработените данни при всяко извличане.

Въпреки това, имайте предвид в този смисъл, че Base64-кодираното хранилище действа просто като кеш , подобно на това, че човек може да съхранява денормализирани данни от съображения за производителност.

...в този случай трябва да бъде TEXT не BLOB

Както бе споменато по-горе:единствената разлика между TEXT и BLOB колони е това за TEXT колони, MySQL допълнително проследява специфичните за текст метаданни (като кодиране на знаци и съпоставяне ) за теб. Тези допълнителни метаданни позволяват на MySQL да преобразува стойности между набори от символи за съхранение и връзка (където е уместно) и да извършва фантастични операции за сравнение/сортиране на низове.

Най-общо казано:ако два клиента, работещи в различни набори от знаци, трябва да виждат едни и същи байтове , тогава искате BLOB колона; ако трябва да видят едни и същи символи тогава искате TEXT колона.

С Base64 тези двама клиента трябва в крайна сметка да открият, че данните декодират до едни и същи байтове; но те трябва да видят, че съхранените/кодирани данни имат същите символи . Например, да предположим, че някой желае да вмъкне Base64-кодирането на „Здравей свят!“ (което е 'SGVsbG8gd29ybGQh' ). Ако приложението за вмъкване работи в набора от символи UTF-8, то ще изпрати байтовата последователност 0x53475673624738676432397962475168 към базата данни.

• ако тази последователност от байтове се съхранява в BLOB колона и по-късно извлечени от приложение, което работи в UTF-16, същите байтове ще бъдат върнати—които представляват '升噳扇㡧搲㥹扇全' а не желаната Base64-кодирана стойност; докато

• ако тази последователност от байтове се съхранява в TEXT колона и по-късно извлечен от приложение, което работи в UTF-16, MySQL ще прекодира в движение, за да върне байтовата последователност 0x00530047005600730062004700380067006400320039007900605> —която представлява оригиналната Base64-кодирана стойност 'SGVsbG8gd29ybGQh' по желание.