Il ne faut pas stocker de données encodées en Base64 dans sa base de données...
Base64 est un codage dans lequel des données binaires arbitraires sont représentées en utilisant uniquement des caractères de texte imprimables :il a été conçu pour les situations où ces données binaires doivent être transférées via un protocole ou un support qui ne peut gérer que du texte imprimable (par exemple, SMTP/email). Il augmente la taille des données (de 33 %) et ajoute le coût de calcul de l'encodage/décodage, il doit donc être évité sauf en cas d'absolue nécessité.
En revanche, tout l'intérêt de BLOB colonnes est qu'elles stockent des chaînes binaires opaques . Alors allez-y et stockez vos affaires directement dans votre BLOB colonnes sans les encoder d'abord en Base64. (Cela dit, si MySQL a un type plus approprié pour les données particulières stockées, vous pouvez l'utiliser à la place :par exemple, les fichiers texte comme les sources JavaScript pourraient bénéficier d'être stockés dans TEXT colonnes pour lesquelles MySQL suit nativement les métadonnées spécifiques au texte ; plus d'informations à ce sujet ci-dessous).
L'idée (erronée) selon laquelle les bases de données SQL nécessitent des encodages de texte imprimables comme Base64 pour gérer des données binaires arbitraires a été perpétuée par un grand nombre de didacticiels mal informés. Cette idée semble reposer sur la croyance erronée selon laquelle, puisque SQL ne comprend que du texte imprimable dans d'autres contextes, il doit sûrement l'exiger également pour les données binaires (au moins pour le transfert de données, sinon pour le stockage de données). Ce n'est tout simplement pas vrai :SQL peut transmettre des données binaires de plusieurs façons, y compris des littéraux de chaîne simples (à condition qu'ils soient correctement entre guillemets et échappés comme n'importe quelle autre chaîne); bien sûr, la meilleure façon de transmettre des données (de tout type) à votre base de données consiste à utiliser des requêtes paramétrées, et les types de données de vos paramètres peuvent tout aussi bien être des chaînes binaires brutes que n'importe quoi d'autre.
... à moins qu'il ne soit mis en cache pour des raisons de performances...
La seule situation dans laquelle il pourrait y avoir un avantage à stocker des données encodées en Base64 est celle où elles sont généralement transmises via un protocole nécessitant un tel encodage (par exemple, par pièce jointe à un e-mail) immédiatement après en cours de récupération à partir de la base de données, auquel cas le stockage de la représentation encodée en Base64 éviterait d'avoir à effectuer l'opération d'encodage sur les données autrement brutes à chaque extraction.
Cependant, notez dans ce sens que le stockage encodé en Base64 agit simplement comme un cache , un peu comme on pourrait stocker des données dénormalisées pour des raisons de performances.
... auquel cas ce devrait être TEXT pas BLOB
Comme évoqué ci-dessus :la seule différence entre TEXT et BLOB colonnes est que, pour TEXT colonnes, MySQL suit en outre les métadonnées spécifiques au texte (telles que l'encodage des caractères et collation ) pour toi. Ces métadonnées supplémentaires permettent à MySQL de convertir les valeurs entre les jeux de caractères de stockage et de connexion (le cas échéant) et d'effectuer des opérations sophistiquées de comparaison/tri de chaînes.
D'une manière générale :si deux clients travaillant dans des jeux de caractères différents doivent voir les mêmes octets , alors vous voulez un BLOB colonne; s'ils doivent voir les mêmes caractères alors vous voulez un TEXTE colonne.
Avec Base64, ces deux clients doivent finalement trouver que les données se décodent sur les mêmes octets; mais ils doivent voir que les données stockées/encodées ont les mêmes caractères . Par exemple, supposons que l'on souhaite insérer l'encodage Base64 de 'Hello world!' (qui est 'SGVsbG8gd29ybGQh' ). Si l'application d'insertion fonctionne dans le jeu de caractères UTF-8, elle enverra la séquence d'octets 0x53475673624738676432397962475168 à la base de données.
-
si cette séquence d'octets est stockée dans un
BLOBcolonne et récupéré plus tard par une application qui travaille en UTF-16, les mêmes octets seront renvoyés—qui représentent'升噳扇㡧搲㥹扇全'et non la valeur encodée en Base64 souhaitée ; alors que -
si cette séquence d'octets est stockée dans un
TEXTcolonne et récupérée ultérieurement par une application qui fonctionne en UTF-16, MySQL transcodera à la volée pour renvoyer la séquence d'octets — qui représente la valeur originale encodée en Base64'SGVsbG8gd29ybGQh'comme vous le souhaitez.
Bien sûr, vous pouvez néanmoins utiliser BLOB colonnes et suivre l'encodage des caractères d'une autre manière, mais cela réinventerait inutilement la roue, avec une complexité de maintenance supplémentaire et le risque d'introduire des erreurs involontaires.
