Documentation PostgreSQL 14.22 » Langage SQL » Types de données » Types de données binaires

Précédent | Niveau supérieur | Suivant
8.3. Types caractère | Sommaire | 8.5. Types date/heure

## 8.4. Types de données binaires

Le type de données `bytea` permet de stocker des chaînes binaires ; voir le Tableau 8.6.

Tableau 8.6. Types de données binaires

Nom | Espace de stockage | Description
--- | --- | ---
`bytea` | un à quatre octets plus la taille de la chaîne binaire à stocker | Chaîne binaire de longueur variable

Une chaîne binaire est une séquence d'octets. Les chaînes binaires se distinguent des chaînes de caractères de deux façons : tout d'abord, les chaînes binaires permettent de stocker des octets de valeurs zéro ainsi que les autres caractères « non imprimables » (habituellement, les octets en dehors de l'intervalle décimal de 32 à 126). Les chaînes de caractères interdisent les octets de valeur zéro et interdisent aussi toute valeur d'octet ou séquence d'octets invalide selon l'encodage sélectionné pour la base de données. Ensuite, les opérations sur les chaînes binaires traitent réellement les octets alors que le traitement de chaînes de caractères dépend de la configuration de la locale. En résumé, les chaînes binaires sont appropriées pour le stockage de données que le développeur considère comme des « octets bruts », alors que les chaînes de caractères sont appropriées pour le stockage de texte.

Le type `bytea` accepte deux formats en entrée et en sortie le format « hex » et le format historique de PostgreSQL, « escape ». Les deux sont acceptés en entrée. Le format de sortie dépend du paramètre de configuration bytea_output ; ce dernier sélectionne par défaut le format hexadécimal. (Notez que le format hexadécimal est disponible depuis PostgreSQL 9.0 ; les versions antérieures et certains outils ne le comprennent pas.)

Le standard SQL définit un type de chaîne binaire différent, appelé `BLOB` ou `BINARY LARGE OBJECT`. Le format en entrée est différent du `bytea`, mais les fonctions et opérateurs fournis sont pratiquement les mêmes.

### 8.4.1. Le format hexadécimal `bytea`

Le format « hex » code les données binaires sous la forme de deux chiffres hexadécimaux par octet, le plus significatif en premier. La chaîne complète est précédée par la séquence `\x` (pour la distinguer du format d'échappement). Dans certains cas, l'antislash initial peut avoir besoin d'être échappé par un doublage du caractère (voir Section 4.1.2.1). En saisie, les chiffres hexadécimaux peuvent être soit en majuscules, soit en minuscules, et les espaces blancs sont permis entre les paires de chiffres (mais pas à l'intérieur d'une paire ni dans la séquence `\x` de début). Le format hexadécimal est compatible avec une grande variété d'applications et de protocoles externes, et il a tendance à être plus rapide à convertir que le format d'échappement. Son utilisation est donc préférée.

Exemple :

    SET bytea_output = 'hex';

    SELECT '\xDEADBEEF'::bytea;
       bytea
    ------------
     \xdeadbeef

### 8.4.2. Le format d'échappement `bytea`

Le format d'échappement (« escape ») est le format traditionnel de PostgreSQL pour le type `bytea`. Son approche est de représenter une chaîne binaire comme un séquence de caractères ASCII et de convertir les données qui ne peuvent pas être représentées en ASCII en une séquence spéciale d'échappement. Si, du point de vue de l'application, représenter les octets sous la forme de caractères revêt un sens, alors cette représentation est intéressante. En pratique, c'est généralement source de confusion, car cela diminue la distinction entre chaînes binaires et chaînes textuelles. De plus, le mécanisme particulier de l'échappement qui a été choisi est quelque peu complexe. Donc ce format devrait probablement être évité pour la plupart des nouvelles applications.

Lors de la saisie de valeurs `bytea` dans le format d'échappement, les octets de certaines valeurs doivent être échappés alors que les autres valeurs d'octets peuvent être échappés. En général, pour échapper un octet, il suffit de le convertir dans sa valeur octale composée de trois chiffres et de la faire précéder d'un antislash (ou de deux antislashs s'il faut utiliser la syntaxe d'échappement de chaînes). L'antislash lui-même (octet en valeur décimal, 92) peut alternativement être représenté par un double antislash. Le Tableau 8.7 affiche les caractères qui doivent être échappés et donne les séquences d'échappement possibles.

Tableau 8.7. Octets littéraux `bytea` à échapper

Valeur décimale de l'octet | Description | Représentation échappée en entrée | Exemple | Représentation hexadécimale
--- | --- | --- | --- | ---
0 | octet zéro | `'\000'` | `'\000'::bytea;` | `\x00`
39 | apostrophe | `''''` ou `'\047'` | `''''::bytea;` | `\x27`
92 | antislash | `'\\'` or `'\134'` | `'\\'::bytea;` | `\x5c`
de 0 à 31 et de 127 à 255 | octets « non affichables » | `'\`xxx'`` (valeur octale) | `'\001'::bytea;` | `\x01`

La nécessité d'échapper les octets non affichables dépend des paramétrages de la locale. Il est parfois possible de s'en sortir sans échappement.

La raison pour laquelle les guillemets simples doivent être doublés, comme indiqué dans Tableau 8.7, est que cela est vrai pour toute chaîne litérale dans une commande SQL. L'analyseur générique des chaînes litérales utilise les guillemets simples externes et réduit toute paire de guillemets simples en un seul caractère. La fonction en entrée du type `bytea` ne voit qu'un guillemet simple, qu'il traire comme un caractère standard. Néanmoins, la fonction en entrée du type `bytea` traite les antislashs de façon spéciale et les autres comportements montrés dans Tableau 8.7 sont implémentés par cette fonction.

Dans certains contextes, les antislashs doivent être doublés par rapport à ce qui est montré ci-dessus car l'analyseur générique de chaîne litérale réduira aussi les paires d'antislashs en un seul caractère de données ; voir Section 4.1.2.1.

Les octets `Bytea` sont affichés par défaut dans le format `hex`. Si vous modifiez bytea_output à `escape`, les octets « non affichables » sont convertis dans leur équivalent sous la forme d'une valeur octale à trois chiffres et précédé d'un antislash. La plupart des octets « affichables » sont affichés dans leur représentation standard pour le jeu de caractères du client :

    SET bytea_output = 'escape';

    SELECT 'abc \153\154\155 \052\251\124'::bytea;
         bytea
    ----------------
     abc klm *\251T

L'octet de valeur décimale 92 (antislash) est doublé en sortie. Les détails sont dans le Tableau 8.8.

Tableau 8.8. Octets échappés en sortie pour `bytea`

Valeur décimale de l'octet | Description | Représentation de sortie échappée | Exemple | Résultat en sortie
--- | --- | --- | --- | ---
92 | antislash | `\\` | `'\134'::bytea;` | `\\`
0 à 31 et 127 à 255 | octets« non affichables » | `\`xxx`` (valeur octale) | `'\001'::bytea;` | `\001`
32 à 126 | octets « affichables » | Représentation dans le jeu de caractères du client | `'\176'::bytea;` | `~`

En fonction de l'interface utilisée pour accéder à PostgreSQL, un travail supplémentaire d'échappement/de « déséchappement » des chaînes `bytea` peut être nécessaire. Il faut également échapper les sauts de lignes et retours à la ligne si l'interface les traduit automatiquement, par exemple.