Формат “hex” кодирует двоичные данные в виде 2-х шестнадцатеричных цифр на байт, сначала наиболее значимый полубайт. Вся строка предшествует последовательности \x (для отличия от формата экранирования). В некоторых контекстах начальную обратную косую черту может потребоваться удвоить (см. Раздел 4.1.2.1). При вводе шестнадцатеричные цифры могут быть как в верхнем, так и в нижнем регистре, и между парой цифр допускается наличие пробелов (но не внутри пары цифр и не в начальной последовательности \x). Формат hex совместим с широким спектром внешних приложений и протоколов, и его преобразование обычно происходит быстрее, чем формат экранирования, поэтому его использование предпочтительно.

Пример:

SET bytea_output = 'hex';

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

Формат “escape” является традиционным форматом Tantor SE-1C для типа bytea. Он представляет двоичную строку в виде последовательности ASCII-символов, преобразуя те байты, которые не могут быть представлены в виде ASCII-символа, в специальные последовательности экранирования. Если с точки зрения приложения имеет смысл представлять байты в виде символов, то такое представление может быть удобным. Однако на практике оно обычно вызывает путаницу между двоичными строками и строками символов, а также выбранный механизм экранирования неудобен. Поэтому этот формат, вероятно, следует избегать в большинстве новых приложений.

При вводе значений bytea в формате escape, определенные октеты значений должны быть экранированы, в то время как все октеты значений могут быть экранированы. Обычно, для экранирования октета, преобразуйте его в его трехзначное восьмеричное значение и предшествуйте ему обратной косой чертой. Сама обратная косая черта (десятичное значение октета 92) может быть представлена двойной обратной косой чертой. Таблица 8.7 показывает символы, которые должны быть экранированы, и предоставляет альтернативные последовательности экранирования, где это применимо.

Требование к экранированию непечатаемых октетов зависит от настроек локали. В некоторых случаях их можно оставить неэкранированными.

Причина, по которой апострофы должны быть удвоены, как показано в Таблица 8.7, заключается в том, что это верно для любой строковой литеры в SQL-команде. Общий парсер строковых литер потребляет наружные апострофы и сокращает любую пару апострофов до одного символа данных. То, что видит функция ввода bytea, это просто один апостроф, которую она рассматривает как обычный символ данных. Однако функция ввода bytea рассматривает обратные косые черты как специальные символы, и другие поведения, показанные в Таблица 8.7, реализуются этой функцией.

В некоторых контекстах обратные косые черты должны быть удвоены по сравнению с тем, что показано выше, потому что общий парсер строковых литералов также сокращает пары обратных косых черт до одного символа данных; см. Раздел 4.1.2.1.

Bytea октеты по умолчанию выводятся в формате hex. Если вы измените bytea_output на escape, “непечатаемые” октеты будут преобразованы в их эквивалентное трехзначное восьмеричное значение и предварены обратной косой чертой. Большинство “печатаемых” октетов выводятся в стандартном представлении в клиентской кодировке символов, например:

SET bytea_output = 'escape';

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

Октет с десятичным значением 92 (обратная косая черта) удваивается в выводе. Подробности приведены в Таблица 8.8.

В зависимости от используемого пользовательского интерфейса для Tantor SE-1C вам может потребоваться выполнить дополнительную работу по экранированию и деэкранированию строк типа bytea. Например, вам также может потребоваться экранировать символы перевода строки и возврата каретки, если ваш интерфейс автоматически выполняет их перевод.