Двоичная строка представляет собой последовательность октетов (или байтов). Двоичные строки отличаются от символьных строк двумя способами. Во- первых, двоичные строки специально позволяют хранить октеты с нулевым значением и другие « непечатаемые » октеты (обычно октеты вне десятичного диапазона от 32 до 126). Строки символов запрещают нулевые октеты, а также любые другие значения октетов и последовательности значений октетов, которые являются недопустимыми в соответствии с выбранной кодировкой набора символов базы данных. Во-вторых, операции с двоичными строками обрабатывают фактические байты, тогда как обработка строк символов зависит от настроек локали. Короче говоря, двоичные строки подходят для хранения данных, которые программист считает « необработанными байтами » ., тогда как строки символов подходят для хранения текста.
Name | Storage Size | Description |
---|---|---|
bytea | 1 or 4 bytes plus the actual binary string | variable-length binary string |
Этот bytea
тип поддерживает два формата для ввода и вывода: « шестнадцатеричный » формат и исторический « экранированный » формат PostgreSQL . Оба они всегда принимаются на вход. Формат вывода зависит от параметра конфигурации bytea_output ; по умолчанию шестнадцатеричный. (Обратите внимание, что шестнадцатеричный формат был введен в PostgreSQL 9.0; более ранние версии и некоторые инструменты его не понимают.)
Стандарт SQL определяет другой тип двоичной строки, называемый BLOB
или BINARY LARGE OBJECT
. Формат ввода отличается от bytea
, но предоставляемые функции и операторы в основном такие же.
bytea Hex Format
Шестнадцатеричный формат кодирует двоичные данные как 2 шестнадцатеричных цифры на байт, начиная со старшего полубайта. Целой строке предшествует последовательность \x
(чтобы отличить ее от escape-формата). В некоторых контекстах может потребоваться экранирование начальной обратной косой черты путем ее удвоения. Для ввода шестнадцатеричные цифры могут быть как в верхнем, так и в нижнем регистре, а между парами цифр разрешены пробелы (но не внутри пары цифр и не в начальной \x
последовательности). Шестнадцатеричный формат совместим с широким спектром внешних приложений и протоколов, и, как правило, он быстрее преобразуется, чем escape-формат, поэтому его использование предпочтительнее.
SELECT '\xDEADBEEF';
bytea Escape Format
Формат escape — это традиционный формат PostgreSQL для этого bytea
типа . В нем используется подход представления двоичной строки в виде последовательности символов ASCII с преобразованием тех байтов, которые не могут быть представлены в виде символа ASCII, в специальные управляющие последовательности. Если с точки зрения приложения представление байтов в виде символов имеет смысл, то такое представление может быть удобным. Но на практике это обычно сбивает с толку, потому что стирает различие между двоичными строками и символьными строками, а также выбранный конкретный механизм выхода несколько громоздкий. Поэтому этого формата, вероятно, следует избегать для большинства новых приложений.
При вводе bytea
значений в escape-формате октеты определенных значений должны быть экранированы, в то время как все значения октетов могут быть экранированы. В общем случае, чтобы избежать октета, преобразуйте его в трехзначное восьмеричное значение и поставьте перед ним обратную косую черту. Сама обратная косая черта (октетное десятичное значение 92) также может быть представлена двойной обратной косой чертой.
Decimal Octet Value | Description | Escaped Input Representation | Example | Hex Representation |
---|---|---|---|---|
0 | zero octet | '\000' | '\000'::bytea | \x00 |
39 | single quote | '''' or '\047' | ''''::bytea | \x27 |
92 | backslash | '\\' or '\134' | '\\'::bytea | \x5c |
0 to 31 and 127 to 255 | “non-printable” octets | '\xxx' (octal value) | '\001'::bytea | \x01 |
Требование экранирования непечатаемых октетов зависит от региональных настроек. В некоторых случаях вам может сойти с рук оставить их неэкранированными.
Причина, по которой одинарные кавычки должны быть удвоены, заключается в том, что это верно для любого строкового литерала в команде SQL. Общий синтаксический анализатор строковых литералов использует самые внешние одинарные кавычки и сокращает любую пару одинарных кавычек до одного символа данных. Функция bytea
ввода видит только одну одиночную кавычку, которую она обрабатывает как простой символ данных. Однако bytea
функция ввода обрабатывает обратную косую черту как особую, и другие варианты поведения, реализуются этой функцией.
В некоторых контекстах обратные косые черты должны быть удвоены по сравнению с тем, что показано выше, потому что универсальный синтаксический анализатор строковых литералов также уменьшит пары обратных косых черт до одного символа данных.
Bytea
октеты выводятся в hex
формате по умолчанию. Если вы измените bytea_output на escape
, « непечатаемые » октеты преобразуются в их эквивалентное трехзначное восьмеричное значение, и им предшествует одна обратная косая черта. Большинство « печатных » октетов выводятся в соответствии со своим стандартным представлением в наборе символов клиента, например:
SET bytea_output = 'escape';
SELECT 'abc \153\154\155 \052\251\124'::bytea;
bytea
----------------
abc klm *\251T
Октет с десятичным значением 92 (обратная косая черта) удваивается на выходе.
Decimal Octet Value | Description | Escaped Output Representation | Example | Output Result |
---|---|---|---|---|
92 | backslash | \\ | '\134'::bytea | \\ |
0 to 31 and 127 to 255 | “non-printable” octets | \xxx (octal value) | '\001'::bytea | \001 |
32 to 126 | “printable” octets | client character set representation | '\176'::bytea | ~ |
В зависимости от внешнего интерфейса PostgreSQL , который вы используете, у вас может быть дополнительная работа с точки зрения экранирования и отмены экранирования bytea
строк. Например, вам также может потребоваться экранировать символы перевода строки и возврата каретки, если ваш интерфейс автоматически переводит их.
0 комментариев