Przechowywanie danych zakodowanych w base64 jako typu danych BLOB lub TEXT

Nie należy przechowywać danych zakodowanych w Base64 w swojej bazie danych...

Base64 to kodowanie, w którym dowolne dane binarne są reprezentowane wyłącznie za pomocą drukowalnych znaków tekstowych:zostało zaprojektowane z myślą o sytuacjach, w których takie dane binarne muszą być przesyłane za pośrednictwem protokołu lub nośnika, który obsługuje tylko tekst drukowalny (np. SMTP/e-mail). Zwiększa rozmiar danych (o 33%) i dodaje koszt obliczeniowy kodowania/dekodowania, więc należy tego unikać, chyba że jest to absolutnie konieczne.

Natomiast cały punkt BLOB kolumny polegają na tym, że przechowują nieprzezroczyste ciągi binarne . Więc po prostu idź dalej i przechowuj swoje rzeczy bezpośrednio w swoim BLOB kolumny bez pierwszego zakodowania ich w Base64. (To powiedziawszy, jeśli MySQL ma bardziej odpowiedni typ dla konkretnych przechowywanych danych, możesz chcieć użyć go zamiast tego:na przykład pliki tekstowe, takie jak źródła JavaScript, mogą skorzystać na przechowywaniu w TEXT kolumny, dla których MySQL natywnie śledzi metadane specyficzne dla tekstu — więcej na ten temat poniżej).

(Błędny) pomysł, że bazy danych SQL wymagają kodowania tekstu do wydrukowania, takiego jak Base64, do obsługi dowolnych danych binarnych, został utrwalony przez dużą liczbę źle poinformowanych samouczków. Wydaje się, że pomysł ten opiera się na błędnym przekonaniu, że skoro SQL zawiera tylko tekst drukowalny w innych kontekstach, z pewnością wymaga go również dla danych binarnych (przynajmniej do przesyłania danych, jeśli nie do przechowywania danych). To po prostu nieprawda:SQL może przekazywać dane binarne na wiele sposobów, w tym zwykłe literały łańcuchowe (pod warunkiem, że są one właściwie cytowane i mają znak ucieczki, jak każdy inny łańcuch); oczywiście preferowanym sposobem przekazywania danych (dowolnego typu) do bazy danych są zapytania parametryczne, a typy danych parametrów mogą równie łatwo być nieprzetworzonymi ciągami binarnymi, jak cokolwiek innego.

...chyba że jest buforowany ze względu na wydajność...

Jedyną sytuacją, w której mogą wystąpić pewne korzyści z przechowywania danych zakodowanych w Base64, jest to, że są one zwykle przesyłane przez protokół wymagający takiego kodowania (np. jako załącznik do wiadomości e-mail) bezpośrednio po są pobierane z bazy danych — w takim przypadku przechowywanie reprezentacji zakodowanej w Base64 zaoszczędziłoby konieczności wykonywania operacji kodowania na surowych danych przy każdym pobieraniu.

Należy jednak pamiętać, że w tym sensie pamięć zakodowana w Base64 działa jedynie jako pamięć podręczna , podobnie jak można przechowywać zdenormalizowane dane ze względu na wydajność.

...w takim przypadku powinien to być TEXT nie BLOB

Jak wspomniano powyżej:jedyna różnica między TEXT i BLOB kolumny są takie, dla TEXT kolumn, MySQL dodatkowo śledzi metadane specyficzne dla tekstu (takie jak kodowanie znaków i zestawianie ) dla Was. Te dodatkowe metadane umożliwiają MySQL konwertowanie wartości między zestawami znaków pamięci masowej i połączenia (w stosownych przypadkach) oraz wykonywanie fantazyjnych operacji porównywania/sortowania łańcuchów.

Ogólnie mówiąc:jeśli dwóch klientów pracujących w różnych zestawach znaków powinno zobaczyć te same bajty , to chcesz BLOB kolumna; czy powinni widzieć te same znaki wtedy chcesz TEXT kolumna.

W przypadku Base64 ci dwaj klienci muszą ostatecznie stwierdzić, że dane dekodują się do tych samych bajtów; ale powinni zobaczyć, że przechowywane/zakodowane dane mają te same znaki . Załóżmy na przykład, że ktoś chce wstawić kodowanie Base64 'Hello world!' (czyli 'SGVsbG8gd29ybGQh' ). Jeśli aplikacja wstawiająca działa w zestawie znaków UTF-8, wyśle ​​sekwencję bajtów 0x53475673624738676432397962475168 do bazy danych.

• jeśli ta sekwencja bajtów jest przechowywana w BLOB kolumna i później pobierane przez aplikację działającą w UTF-16, te same bajty zostanie zwrócony — co reprezentuje '升噳扇㡧搲㥹扇全' a nie żądaną wartość zakodowaną w Base64; podczas gdy

• jeśli ta sekwencja bajtów jest przechowywana w TEXT kolumna i później pobierane przez aplikację działającą w UTF-16, MySQL transkoduje w locie, aby zwrócić sekwencję bajtów 0x0053004700560073006200470038006700640032003900790062004700510068 —co reprezentuje oryginalną zakodowaną w Base64 wartość 'SGVsbG8gd29ybGQh' zgodnie z potrzebami.

Oczywiście możesz mimo wszystko użyć BLOB kolumn i śledzić kodowanie znaków w inny sposób – ale to niepotrzebnie wymyślałoby koło na nowo, zwiększając złożoność konserwacji i ryzyko wprowadzenia niezamierzonych błędów.