Тип «hex» кодирует двоичные данные в виде 2 шестнадцатеричных цифр на байт, начиная со старшего полубайта. Всей строке предшествует последовательность \x (чтобы отличить её от формата escape). В некоторых контекстах начальную обратную косую черту может понадобиться экранировать путём её удвоения (см. Раздел 2.1.1.2.1). При вводе шестнадцатеричные цифры могут быть как в верхнем, так и в нижнем регистре; между парами цифр допускаются пробелы (но не внутри пары цифр и не в начальной \x последовательности). Формат hex совместим с широким спектром внешних приложений и протоколов, и он обычно преобразуется быстрее, чем формат escape, поэтому его использование предпочтительно.

Пример:

SET bytea_output = 'hex';

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

Тип «escape» является традиционным Digital Q.DataBase форматом для bytea. В данном подходе используется представление двоичной строки в виде последовательности ASCII-символов, при этом байты, которые не могут быть представлены как ASCII-символы, преобразуются в специальные escape-последовательности. Если с точки зрения приложения интерпретация байтов как символов оправдана, то такая форма представления может быть удобной. Однако на практике это обычно вносит путаницу, так как размывает различие между двоичными и символьными строками; кроме того, выбранный механизм экранирования довольно громоздкий. Следовательно, использования данного формата, вероятно, следует избегать в большинстве новых приложений.

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

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

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

В некоторых контекстах количество обратных косых черт должно быть удвоено по сравнению с указанным выше, так как универсальный парсер строковых литералов также заменяет пары обратных косых черт одним символом данных; см. Раздел 2.1.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 (обратная косая черта) при выводе дублируется. Подробная информация приведена в Таблица 2.5.8.

В зависимости от используемого клиентского приложения, Digital Q.DataBase вы используете, может потребоваться дополнительная обработка в части экранирования и обратного преобразования bytea строк. Например, может также потребоваться экранировать символы перевода строки и возврата каретки, если интерфейс преобразует их автоматически.