| Документация по PostgreSQL 9.4.1 | |||
|---|---|---|---|
| Пред. | Уровень выше | Глава 8. Типы данных | След. |
8.4. Двоичные типы данных
Для хранения двоичных данных предназначен тип bytea; см. Таблицу 8-6.
Таблица 8-6. Двоичные типы данных
| Имя | Размер | Описание |
|---|---|---|
| bytea | 1 или 4 байта плюс сама двоичная строка | двоичная строка переменной длины |
Двоичные строки представляют собой последовательность октетов (байт) и имеют два отличия от текстовых строк. Во-первых, в двоичных строках можно хранить байты с кодом 0 и другими "непечатаемыми" значениями (обычно это значения вне диапазона 32..126). В текстовых строках нельзя сохранять нулевые байты, а также значения и последовательности значений, не соответствующие выбранной кодировке базы данных. Во-вторых, в операциях с двоичными строками обрабатываются байты в чистом виде, тогда как текстовые строки обрабатываются в зависимости от языковых стандартов. То есть, двоичные строки больше подходят для данных, которые программист видит как "просто байты", а символьные строки — для хранения текста.
Тип bytea поддерживает два внешних формата ввода и вывода: традиционный для PostgreSQL формат "спецпоследовательностей" и "шестнадцатеричный". Входные данные принимаются в обоих форматах, а формат выходных данных зависит от параметра конфигурации bytea_output; по умолчанию выбран шестнадцатеричный. (Заметьте, что шестнадцатеричный формат был введён в PostgreSQL 9.0; в ранних версиях и некоторых программах он не будет работать.)
Стандарт SQL определяет другой тип двоичных данных, BLOB (BINARY LARGE OBJECT, большой двоичный объект). Его входной формат отличается от форматов bytea, но функции и операторы в основном те же.
8.4.1. Шестнадцатеричный формат bytea
В "шестнадцатеричном" формате двоичные данные кодируются двумя шестнадцатеричными цифрами на байт, при этом первая цифра соответствует старшим 4 битам. К полученной строке добавляется префикс \x (чтобы она отличалась от формата спецпоследовательности). В некоторых контекстах обратную косую черту нужно выделить, продублировав её, в тех же случаях это нужно сделать для формата спецпоследовательности; подробнее это описано ниже. Шестнадцатеричные цифры могут быть в любом регистре, а между парами цифр допускаются пробельные символы (но не внутри пары и не в начале последовательности \x). Этот формат совместим со множеством внешних приложений и протоколов, к тому же обычно преобразуется быстрее, поэтому предпочтительнее использовать его.
Пример:
SELECT E'\\xDEADBEEF';
8.4.2. Формат спецпоследовательностей bytea
Формат "спецпоследовательностей" традиционно использовался в PostgreSQL для значений типа bytea. В нём двоичная строка представляется в виде последовательности ASCII-символов, а байты, непредставимые в виде ASCII-символов, передаются в виде спецпоследовательностей. Этот формат может быть удобен, если с точки зрения приложения представление байт в виде символов имеет смысл. Но на практике это обычно создаёт путаницу, так как двоичные и символьные строки могут выглядеть одинаково, а кроме того выбранный механизм спецпоследовательностей довольно неуклюж. Поэтому в новых приложениях этот формат обычно не стоит использовать.
Передавая значения bytea в формате спецпоследовательности, байты с определёнными значениями необходимо записывать специальным образом, хотя так можно записывать и все значения. В общем виде для этого значение байта нужно преобразовать в трёхзначное восьмеричное число и добавить перед ним обратную косую черту (и продублировать её, если значение записывается в текстовой спецстроке). Саму обратную косую черту (символ с кодом 92) можно записать в виде двух таких символов. В Таблице 8-7 перечислены символы, которые нужно записывать спецпоследовательностями, и приведены альтернативные варианты записи там, где они возможны.
Таблица 8-7. Спецпоследовательности записи значений bytea
| Десятичное значение байта | Описание | Спецпоследова- тельность ввода | Пример | Выводимое представление |
|---|---|---|---|---|
| 0 | нулевой байт | E'\\000' | SELECT E'\\000'::bytea; | \000 |
| 39 | апостроф | '''' или E'\\047' | SELECT E'\''::bytea; | ' |
| 92 | обратная косая черта | E'\\\\' или E'\\134' | SELECT E'\\\\'::bytea; | \\ |
| от 0 до 31 и от 127 до 255 | "непечатаемые" байты | E'\\xxx' (значение байта) | SELECT E'\\001'::bytea; | \001 |
Набор непечатаемых символов, которые нужно записывать спецпоследовательностями, определяется языковыми стандартами. В некоторых случаях можно оставить в буквальном виде и другие символы. Заметьте, что во всех примерах в Таблице 8-7 задаётся значение ровно одного байта, хотя выходное представление может состоять из нескольких символов.
Необходимость дублирования обратных косых черт в записи спецпоследовательностей, показанного в Таблице 8-7, объясняется тем, что строковая константа должна пройти два этапа разбора на сервере PostgreSQL. Первая обратная косая черта из каждой пары воспринимается анализатором строки как спецсимвол (если используется синтаксис спецпоследовательностей) и таким образом пропускается, оставляя только вторую косую черту. (Для избавления от этой вложенности можно использовать строки в долларах.) Оставшаяся обратная косая черта затем распознаётся функцией ввода bytea как спецсимвол, предваряющий трёхзначное восьмеричное значение или следующий спецсимвол. Например, переданная серверу строковая константа E'\\001' преобразуется в \001, проходя через анализатор спецстрок. Затем строка \001 передаётся функции ввода типа bytea, где она преобразуется в один байт с десятичным значением 1. Заметьте, что символ апостроф для функции ввода bytea не отличается от остальных, поэтому он записывается как обычно принято в строках. (См. также Подраздел 4.1.2.1.)
Данные bytea иногда выводятся также в спецпоследовательностях. При этом каждый "непечатаемый" байт представляется в виде трёхзначного восьмеричного значения после обратной косой черты. Большинство "печатаемых" байт представляются обычными символами из клиентского набора символов. Байт с десятичным кодом 92 (обратная косая черта) при выводе дублируется. Это иллюстрирует Таблица 8-8.
Таблица 8-8. Спецпоследовательности выходных значений bytea
| Десятичное значение байта | Описание | Спецпоследовательность вывода | Пример | Выводимый результат |
|---|---|---|---|---|
| 92 | обратная косая черта | \\ | SELECT E'\\134'::bytea; | \\ |
| от 0 до 31 и от 127 до 255 | "непечатаемые" байты | \xxx (значение байта) | SELECT E'\\001'::bytea; | \001 |
| от 32 до 126 | "печатаемые" байты | представление из клиентского набора символов | SELECT E'\\176'::bytea; | ~ |
В зависимости от применяемой клиентской библиотеки PostgreSQL, для преобразования значений bytea в спецстроки и обратно могут потребоваться дополнительные действия. Например, если приложение сохраняет в строках символы перевода строк, возможно их также нужно будет представить спецпоследовательностями.
| Пред. | Начало | След. |
| Символьные типы | Уровень выше | Типы даты/времени |
| PostgreSQL 9.4.1 Documentation | |||
|---|---|---|---|
| Prev | Up | Chapter 8. Data Types | Next |
8.4. Binary Data Types
The bytea data type allows storage of binary strings; see Table 8-6.
Table 8-6. Binary Data Types
| Name | Storage Size | Description |
|---|---|---|
| bytea | 1 or 4 bytes plus the actual binary string | variable-length binary string |
A binary string is a sequence of octets (or bytes). Binary strings are distinguished from character strings in two ways. First, binary strings specifically allow storing octets of value zero and other "non-printable" octets (usually, octets outside the range 32 to 126). Character strings disallow zero octets, and also disallow any other octet values and sequences of octet values that are invalid according to the database's selected character set encoding. Second, operations on binary strings process the actual bytes, whereas the processing of character strings depends on locale settings. In short, binary strings are appropriate for storing data that the programmer thinks of as "raw bytes", whereas character strings are appropriate for storing text.
The bytea type supports two external formats for input and output: PostgreSQL's historical "escape" format, and "hex" format. Both of these are always accepted on input. The output format depends on the configuration parameter bytea_output; the default is hex. (Note that the hex format was introduced in PostgreSQL 9.0; earlier versions and some tools don't understand it.)
The SQL standard defines a different binary string type, called BLOB or BINARY LARGE OBJECT. The input format is different from bytea, but the provided functions and operators are mostly the same.
8.4.1. bytea Hex Format
The "hex" format encodes binary data as 2 hexadecimal digits per byte, most significant nibble first. The entire string is preceded by the sequence \x (to distinguish it from the escape format). In some contexts, the initial backslash may need to be escaped by doubling it, in the same cases in which backslashes have to be doubled in escape format; details appear below. The hexadecimal digits can be either upper or lower case, and whitespace is permitted between digit pairs (but not within a digit pair nor in the starting \x sequence). The hex format is compatible with a wide range of external applications and protocols, and it tends to be faster to convert than the escape format, so its use is preferred.
Example:
SELECT E'\\xDEADBEEF';
8.4.2. bytea Escape Format
The "escape" format is the traditional PostgreSQL format for the bytea type. It takes the approach of representing a binary string as a sequence of ASCII characters, while converting those bytes that cannot be represented as an ASCII character into special escape sequences. If, from the point of view of the application, representing bytes as characters makes sense, then this representation can be convenient. But in practice it is usually confusing because it fuzzes up the distinction between binary strings and character strings, and also the particular escape mechanism that was chosen is somewhat unwieldy. So this format should probably be avoided for most new applications.
When entering bytea values in escape format, octets of certain values must be escaped, while all octet values can be escaped. In general, to escape an octet, convert it into its three-digit octal value and precede it by a backslash (or two backslashes, if writing the value as a literal using escape string syntax). Backslash itself (octet value 92) can alternatively be represented by double backslashes. Table 8-7 shows the characters that must be escaped, and gives the alternative escape sequences where applicable.
Table 8-7. bytea Literal Escaped Octets
| Decimal Octet Value | Description | Escaped Input Representation | Example | Output Representation |
|---|---|---|---|---|
| 0 | zero octet | E'\\000' | SELECT E'\\000'::bytea; | \000 |
| 39 | single quote | '''' or E'\\047' | SELECT E'\''::bytea; | ' |
| 92 | backslash | E'\\\\' or E'\\134' | SELECT E'\\\\'::bytea; | \\ |
| 0 to 31 and 127 to 255 | "non-printable" octets | E'\\xxx' (octal value) | SELECT E'\\001'::bytea; | \001 |
The requirement to escape non-printable octets varies depending on locale settings. In some instances you can get away with leaving them unescaped. Note that the result in each of the examples in Table 8-7 was exactly one octet in length, even though the output representation is sometimes more than one character.
The reason multiple backslashes are required, as shown in Table 8-7, is that an input string written as a string literal must pass through two parse phases in the PostgreSQL server. The first backslash of each pair is interpreted as an escape character by the string-literal parser (assuming escape string syntax is used) and is therefore consumed, leaving the second backslash of the pair. (Dollar-quoted strings can be used to avoid this level of escaping.) The remaining backslash is then recognized by the bytea input function as starting either a three digit octal value or escaping another backslash. For example, a string literal passed to the server as E'\\001' becomes \001 after passing through the escape string parser. The \001 is then sent to the bytea input function, where it is converted to a single octet with a decimal value of 1. Note that the single-quote character is not treated specially by bytea, so it follows the normal rules for string literals. (See also Section 4.1.2.1.)
Bytea octets are sometimes escaped when output. In general, each "non-printable" octet is converted into its equivalent three-digit octal value and preceded by one backslash. Most "printable" octets are represented by their standard representation in the client character set. The octet with decimal value 92 (backslash) is doubled in the output. Details are in Table 8-8.
Table 8-8. bytea Output Escaped Octets
| Decimal Octet Value | Description | Escaped Output Representation | Example | Output Result |
|---|---|---|---|---|
| 92 | backslash | \\ | SELECT E'\\134'::bytea; | \\ |
| 0 to 31 and 127 to 255 | "non-printable" octets | \xxx (octal value) | SELECT E'\\001'::bytea; | \001 |
| 32 to 126 | "printable" octets | client character set representation | SELECT E'\\176'::bytea; | ~ |
Depending on the front end to PostgreSQL you use, you might have additional work to do in terms of escaping and unescaping bytea strings. For example, you might also have to escape line feeds and carriage returns if your interface automatically translates these.
