Člověk by neměl ukládat data zakódovaná v Base64 do své databáze...
Base64 je kódování, ve kterém jsou libovolná binární data reprezentována pouze pomocí tisknutelných textových znaků:bylo navrženo pro situace, kdy je třeba tato binární data přenést přes protokol nebo médium, které dokáže zpracovat pouze tisknutelný text (např. SMTP/e-mail). Zvyšuje velikost dat (o 33 %) a zvyšuje výpočetní náklady na kódování/dekódování, takže je třeba se mu vyhnout, pokud to není nezbytně nutné.
Naproti tomu celý smysl BLOB sloupců je, že ukládají neprůhledné binární řetězce . Takže pokračujte a uložte své věci přímo do BLOB sloupce bez jejich prvního kódování Base64. (To znamená, že pokud má MySQL vhodnější typ pro konkrétní ukládaná data, možná budete chtít místo toho použít tento:například textové soubory, jako jsou zdroje JavaScriptu, by mohly mít prospěch z uložení v TEXT sloupce, pro které MySQL nativně sleduje textově specifická metadata – více o tom níže).
(Chybná) myšlenka, že databáze SQL vyžadují tisknutelné kódování textu jako Base64 pro manipulaci s libovolnými binárními daty, byla udržována velkým množstvím špatně informovaných tutoriálů. Zdá se, že tato myšlenka spočívá v mylném přesvědčení, že protože SQL obsahuje v jiných kontextech pouze tisknutelný text, musí jej jistě vyžadovat i pro binární data (alespoň pro přenos dat, ne-li pro ukládání dat). To prostě není pravda:SQL může předávat binární data mnoha způsoby, včetně prostých řetězcových literálů (za předpokladu, že jsou správně uvozovány a escapovány jako jakýkoli jiný řetězec); samozřejmě preferovaný způsob předávání dat (jakéhokoli typu) do vaší databáze je prostřednictvím parametrizovaných dotazů a datové typy vašich parametrů mohou být stejně snadno nezpracované binární řetězce jako cokoli jiného.
...pokud není uložen do mezipaměti z důvodu výkonu...
Jediná situace, ve které může být ukládání dat kódovaných Base64 přínosem, je situace, kdy jsou obvykle přenášena přes protokol vyžadující takové kódování (např. přílohou e-mailu) bezprostředně po získávání z databáze – v takovém případě by uložení reprezentace kódované Base64 ušetřilo nutnost provádět operaci kódování na jinak nezpracovaných datech při každém načtení.
V tomto smyslu však poznamenejte, že úložiště kódované Base64 funguje pouze jako mezipaměť , podobně jako byste mohli ukládat denormalizovaná data z důvodů výkonu.
...v tom případě by to mělo být TEXT ne BLOB
Jak bylo zmíněno výše:jediný rozdíl mezi TEXT a BLOB sloupců je to pro TEXT sloupců, MySQL navíc sleduje metadata specifická pro text (jako je kódování znaků a třídění ) pro tebe. Tato dodatečná metadata umožňují MySQL převádět hodnoty mezi znakovými sadami úložiště a připojení (kde je to vhodné) a provádět efektní operace porovnávání/třídění řetězců.
Obecně řečeno:pokud by dva klienti pracující v různých znakových sadách měli vidět stejné bajty , pak chcete BLOB sloupec; pokud by měli vidět stejné znaky pak chcete TEXT sloupec.
S Base64 musí tito dva klienti nakonec zjistit, že se data dekódují na stejné bajty; ale měli by vidět, že uložená/zakódovaná data mají stejné znaky . Předpokládejme například, že si přejete vložit kódování Base64 z 'Hello world!' (což je 'SGVsbG8gd29ybGQh' ). Pokud vkládací aplikace pracuje ve znakové sadě UTF-8, odešle sekvenci bajtů 0x53475673624738676432397962475168 do databáze.
-
pokud je tato sekvence bajtů uložena v
BLOBsloupec a později načtený aplikací, která pracuje v UTF-16, stejné bajty bude vráceno – což představuje'升噳扇㡧搲㥹扇全'a nikoli požadovanou hodnotu zakódovanou v Base64; zatímco -
pokud je tato bajtová sekvence uložena v
TEXTsloupec a později načtený aplikací, která pracuje v UTF-16, MySQL překóduje za běhu, aby vrátil sekvenci bajtů0x00530047005600730062004700380067006400320039007900620047005100680 —což představuje původní hodnotu zakódovanou v Base64'SGVsbG8gd29ybGQh'podle přání.
Samozřejmě můžete přesto použít BLOB sloupce a sledovat kódování znaků nějakým jiným způsobem – ale to by jen zbytečně znovu vynalézalo kolo s přidanou složitostí údržby a rizikem zavedení neúmyslných chyb.