Base64-gecodeerde gegevens opslaan als BLOB- of TEXT-gegevenstype

Je mag geen Base64-gecodeerde gegevens in je database opslaan...

Base64 is een codering waarin willekeurige binaire gegevens worden weergegeven met alleen afdrukbare teksttekens:het is ontworpen voor situaties waarin dergelijke binaire gegevens moeten worden overgedragen via een protocol of medium dat alleen afdrukbare tekst kan verwerken (bijv. SMTP/e-mail). Het vergroot de gegevensomvang (met 33%) en voegt de rekenkosten van het coderen/decoderen toe, dus het moet worden vermeden tenzij het absoluut noodzakelijk is.

Daarentegen het hele punt van BLOB kolommen is dat ze ondoorzichtige binaire strings opslaan . Dus ga je gang en sla je spullen direct op in je BLOB kolommen zonder ze eerst met Base64 te coderen. (Dat gezegd hebbende, als MySQL een meer geschikt type heeft voor de specifieke gegevens die worden opgeslagen, zou je dat in plaats daarvan kunnen gebruiken:tekstbestanden zoals JavaScript-bronnen kunnen er bijvoorbeeld baat bij hebben om te worden opgeslagen in TEXT kolommen waarvoor MySQL native tekstspecifieke metadata bijhoudt (meer hierover hieronder).

Het (foutieve) idee dat SQL-databases afdrukbare tekstcoderingen zoals Base64 nodig hebben voor het verwerken van willekeurige binaire gegevens, is in stand gehouden door een groot aantal slecht geïnformeerde tutorials. Dit idee lijkt te berusten op de verkeerde overtuiging dat, omdat SQL alleen afdrukbare tekst bevat in andere contexten, het dit zeker ook nodig moet hebben voor binaire gegevens (tenminste voor gegevensoverdracht, zo niet voor gegevensopslag). Dit is gewoon niet waar:SQL kan binaire gegevens op een aantal manieren overbrengen, inclusief letterlijke tekenreeksen (op voorwaarde dat ze correct worden geciteerd en ontsnapt zoals elke andere tekenreeks); natuurlijk is de geprefereerde manier om gegevens (van welk type dan ook) aan uw database door te geven via geparametriseerde query's, en de gegevenstypen van uw parameters kunnen net zo gemakkelijk onbewerkte binaire tekenreeksen zijn als al het andere.

...tenzij het om prestatieredenen in de cache is opgeslagen...

De enige situatie waarin er enig voordeel zou kunnen zijn bij het opslaan van Base64-gecodeerde gegevens, is wanneer deze gewoonlijk onmiddellijk na worden verzonden via een protocol dat een dergelijke codering vereist (bijvoorbeeld via e-mailbijlage) worden opgehaald uit de database, in welk geval het opslaan van de Base64-gecodeerde weergave zou besparen op het uitvoeren van de coderingsbewerking op de anders onbewerkte gegevens bij elke ophaalactie.

Houd er echter rekening mee dat de Base64-gecodeerde opslag slechts fungeert als een cache , net zoals men om prestatieredenen gedenormaliseerde gegevens zou kunnen opslaan.

...in dat geval moet het TEXT zijn niet BLOB

Zoals hierboven vermeld:het enige verschil tussen TEXT en BLOB kolommen is dat, voor TEXT kolommen, houdt MySQL bovendien tekstspecifieke metadata bij (zoals tekencodering en sortering ) voor jou. Met deze extra metadata kan MySQL waarden converteren tussen opslag- en verbindingstekensets (indien van toepassing) en mooie stringvergelijkings-/sorteerbewerkingen uitvoeren.

Algemeen gesproken:als twee clients die in verschillende tekensets werken, dezelfde bytes zouden moeten zien , dan wil je een BLOB kolom; als ze dezelfde tekens zouden moeten zien dan wil je een TEXT kolom.

Met Base64 moeten die twee clients uiteindelijk ontdekken dat de gegevens decoderen tot dezelfde bytes; maar ze zouden moeten zien dat de opgeslagen/gecodeerde gegevens dezelfde tekens hebben . Stel bijvoorbeeld dat men de Base64-codering van 'Hello world!' . wil invoegen (dat is 'SGVsbG8gd29ybGQh' ). Als de invoegtoepassing werkt in de UTF-8-tekenset, wordt de bytereeks 0x53475673624738676432397962475168 verzonden naar de database.

• als die bytereeks is opgeslagen in een BLOB kolom en later opgehaald door een toepassing die werkt in UTF-16, dezelfde bytes worden geretourneerd—die '升噳扇㡧搲㥹扇全' . vertegenwoordigen en niet de gewenste Base64-gecodeerde waarde; overwegende dat

• als die bytereeks is opgeslagen in een TEXT kolom en later opgehaald door een toepassing die in UTF-16 werkt, zal MySQL on-the-fly transcoderen om de bytereeks 0x0053004700560073006200470038006700640032003900790062004700510068 te retourneren —die de originele Base64-gecodeerde waarde 'SGVsbG8gd29ybGQh' vertegenwoordigt naar wens.

Natuurlijk kunt u toch BLOB . gebruiken kolommen en de karaktercodering op een andere manier volgen, maar dat zou nodeloos het wiel opnieuw uitvinden, met extra onderhoudscomplexiteit en het risico op het introduceren van onbedoelde fouten.