Man sollte keine Base64-codierten Daten in seiner Datenbank speichern...
Base64 ist eine Codierung, bei der beliebige Binärdaten nur mit druckbaren Textzeichen dargestellt werden:Sie wurde für Situationen entwickelt, in denen solche Binärdaten über ein Protokoll oder Medium übertragen werden müssen, das nur druckbaren Text verarbeiten kann (z. B. SMTP/E-Mail). Es erhöht die Datengröße (um 33 %) und erhöht die Rechenkosten für die Codierung/Decodierung, daher sollte es vermieden werden, es sei denn, es ist absolut notwendig.
Im Gegensatz dazu der ganze Sinn von BLOB Spalten ist, dass sie undurchsichtige binäre Zeichenfolgen speichern . Legen Sie also einfach los und speichern Sie Ihre Sachen direkt in Ihrem BLOB Spalten ohne vorherige Base64-Codierung. (Wenn MySQL jedoch einen geeigneteren Typ für die zu speichernden Daten hat, möchten Sie vielleicht diesen stattdessen verwenden:Textdateien wie JavaScript-Quellen könnten beispielsweise davon profitieren, in TEXT gespeichert zu werden Spalten, für die MySQL nativ textspezifische Metadaten verfolgt – mehr dazu weiter unten).
Die (irrtümliche) Idee, dass SQL-Datenbanken druckbare Textcodierungen wie Base64 benötigen, um beliebige Binärdaten zu verarbeiten, wurde durch eine große Anzahl schlecht informierter Tutorials aufrechterhalten. Diese Idee scheint auf dem Irrglauben zu beruhen, dass SQL, da es in anderen Kontexten nur druckbaren Text enthält, diesen sicher auch für Binärdaten (zumindest für die Datenübertragung, wenn nicht für die Datenspeicherung) benötigen muss. Das ist einfach nicht wahr:SQL kann Binärdaten auf verschiedene Arten übertragen, einschließlich einfacher String-Literale (vorausgesetzt, sie werden wie alle anderen Strings korrekt in Anführungszeichen gesetzt und mit Escapezeichen versehen); Natürlich ist der bevorzugte Weg, Daten (jeglicher Art) an Ihre Datenbank zu übergeben, parametrisierte Abfragen, und die Datentypen Ihrer Parameter können genauso einfach rohe binäre Zeichenfolgen sein wie alles andere.
...es sei denn, es wird aus Leistungsgründen zwischengespeichert...
Die einzige Situation, in der das Speichern von Base64-codierten Daten von Vorteil sein könnte, ist, wenn sie normalerweise unmittelbar nach über ein Protokoll übertragen werden, das eine solche Codierung erfordert (z. B. per E-Mail-Anhang). aus der Datenbank abgerufen werden – in diesem Fall würde das Speichern der Base64-codierten Darstellung die Durchführung des Codierungsvorgangs für die ansonsten rohen Daten bei jedem Abruf ersparen.
Beachten Sie in diesem Sinne jedoch, dass der Base64-codierte Speicher lediglich als Cache fungiert , ähnlich wie man denormalisierte Daten aus Leistungsgründen speichern könnte.
...in diesem Fall sollte es TEXT sein nicht BLOB
Wie oben angedeutet:der einzige Unterschied zwischen TEXT und BLOB Spalten ist das für TEXT -Spalten verfolgt MySQL zusätzlich textspezifische Metadaten (wie Zeichenkodierung und Sortierung ) für dich. Diese zusätzlichen Metadaten ermöglichen es MySQL, Werte zwischen Speicher- und Verbindungszeichensätzen umzuwandeln (sofern zutreffend) und ausgefallene String-Vergleichs-/Sortieroperationen durchzuführen.
Generell gilt:wenn zwei Clients mit unterschiedlichen Zeichensätzen die gleichen Bytes sehen sollen , dann möchten Sie ein BLOB Säule; wenn sie dieselben Zeichen sehen sollten dann möchten Sie einen TEXT Spalte.
Bei Base64 müssen diese beiden Clients letztendlich feststellen, dass die Daten in dieselben Bytes dekodiert werden; aber sie sollten sehen, dass die gespeicherten/codierten Daten die gleichen Zeichen haben . Angenommen, man möchte die Base64-Codierung von 'Hello world!' einfügen (das ist 'SGVsbG8gd29ybGQh' ). Wenn die einfügende Anwendung im Zeichensatz UTF-8 arbeitet, dann sendet sie die Bytefolge 0x53475673624738676432397962475168 zur Datenbank.
-
wenn diese Bytesequenz in einem
BLOBgespeichert ist -Spalte und später von einer Anwendung abgerufen, die in UTF-16 arbeitet, dieselben Bytes zurückgegeben – die für'升噳扇㡧搲㥹扇全'stehen und nicht der gewünschte Base64-codierte Wert; wohingegen -
wenn diese Bytefolge in einem
TEXTgespeichert ist -Spalte und später von einer Anwendung abgerufen werden, die in UTF-16 arbeitet, transcodiert MySQL on-the-fly, um die Bytesequenz0x0053004700560073006200470038006700640032003900790062004700510068zurückzugeben – der den ursprünglichen Base64-codierten Wert'SGVsbG8gd29ybGQh'darstellt wie gewünscht.
Natürlich könnten Sie trotzdem BLOB verwenden Spalten und verfolgen Sie die Zeichencodierung auf andere Weise – aber das würde das Rad unnötigerweise neu erfinden, mit zusätzlicher Komplexität der Wartung und dem Risiko, unbeabsichtigte Fehler einzuführen.
