Man bør ikke gemme Base64-kodede data i sin database...
Base64 er en kodning, hvor vilkårlige binære data er repræsenteret ved kun at bruge udskrivbare teksttegn:den er designet til situationer, hvor sådanne binære data skal overføres på tværs af en protokol eller et medium, der kun kan håndtere udskrivbar tekst (f.eks. SMTP/e-mail). Det øger datastørrelsen (med 33 %) og tilføjer beregningsomkostningerne ved kodning/afkodning, så det bør undgås, medmindre det er absolut nødvendigt.
Derimod hele pointen med BLOB kolonner er, at de gemmer uigennemsigtige binære strenge . Så bare gå videre og gem dine ting direkte i din BLOB kolonner uden først Base64-kodning af dem. (Når det er sagt, hvis MySQL har en mere passende type til de bestemte data, der gemmes, kan du ønske at bruge det i stedet:for eksempel kan tekstfiler som JavaScript-kilder drage fordel af at blive gemt i TEXT kolonner, for hvilke MySQL indbygget sporer tekstspecifikke metadata – mere om dette nedenfor).
Den (fejlagtige) idé om, at SQL-databaser kræver udskrivbare tekstkodninger som Base64 til håndtering af vilkårlige binære data, er blevet videreført af et stort antal dårligt informerede tutorials. Denne idé ser ud til at have en fejlagtig tro på, at fordi SQL kun omfatter udskrivbar tekst i andre sammenhænge, så skal den bestemt også kræve det til binære data (i det mindste til dataoverførsel, hvis ikke til datalagring). Dette er ganske enkelt ikke sandt:SQL kan formidle binære data på en række måder, inklusive almindelige strenge bogstaver (forudsat at de er korrekt citeret og escaped som enhver anden streng); selvfølgelig er den foretrukne måde at videregive data (af enhver type) til din database gennem parametriserede forespørgsler, og datatyperne for dine parametre kan lige så nemt være rå binære strenge som noget andet.
...medmindre den er cachelagret af ydeevneårsager...
Den eneste situation, hvor der kan være en vis fordel ved at gemme Base64-kodede data, er hvor de normalt transmitteres på tværs af en protokol, der kræver en sådan kodning (f.eks. ved e-mail) umiddelbart efter bliver hentet fra databasen – i hvilket tilfælde lagring af den Base64-kodede repræsentation ville spare fra at skulle udføre kodningsoperationen på de ellers rå data ved hver hentning.
Bemærk dog i denne forstand, at det Base64-kodede lager kun fungerer som en cache , ligesom man kan gemme denormaliserede data af ydeevnemæssige årsager.
...i så fald skal det være TEXT ikke BLOB
Som nævnt ovenfor:den eneste forskel mellem TEXT og BLOB kolonner er det for TEXT kolonner, sporer MySQL desuden tekstspecifikke metadata (såsom tegnkodning og sortering ) for dig. Disse ekstra metadata gør det muligt for MySQL at konvertere værdier mellem lager- og forbindelsestegnsæt (hvor det er relevant) og udføre smarte strengsammenlignings-/sorteringsoperationer.
Generelt:hvis to klienter, der arbejder i forskellige tegnsæt, skal se de samme bytes , så vil du have en BLOB kolonne; hvis de skulle se de samme tegn så vil du have en TEKST kolonne.
Med Base64 skal disse to klienter i sidste ende finde ud af, at dataene afkoder til de samme bytes; men de bør se, at de lagrede/kodede data har de samme tegn . Antag for eksempel, at man ønsker at indsætte Base64-kodningen af 'Hello world!' (som er 'SGVsbG8gd29ybGQh' ). Hvis indsættelsesapplikationen fungerer i UTF-8-tegnsættet, sender den bytesekvensen 0x53475673624738676432397962475168 til databasen.
-
hvis den byte-sekvens er gemt i en
BLOBkolonne og senere hentet af et program, der fungerer i UTF-16, de samme bytes vil blive returneret - som repræsenterer'升噳扇㡧搲㥹扇全'og ikke den ønskede Base64-kodede værdi; hvorimod -
hvis den byte-sekvens er gemt i en
TEXTkolonne og senere hentet af en applikation, der fungerer i UTF-16, vil MySQL omkode på-the-fly for at returnere bytesekvensen0x00530047005600730062004700380067006400320039007900602007code10407900608'SGVsbG8gd29ybGQh'som ønsket.
Selvfølgelig kan du alligevel bruge BLOB kolonner og spor tegnkodningen på en anden måde - men det ville bare unødvendigt genopfinde hjulet med ekstra vedligeholdelseskompleksitet og risiko for at introducere utilsigtede fejl.