The <quote>hex</quote> format encodes binary data as 2 hexadecimal digits per byte, most significant nibble first. The entire string is preceded by the sequence <literal>\x</literal> (to distinguish it from the escape format). In some contexts, the initial backslash may need to be escaped by doubling it (see <xref linkend="sql-syntax-strings"/>). For input, 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 <literal>\x</literal> 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. 「hex」書式ではバイナリデータの各バイトを上位4ビット、下位4ビットの順で2桁の16進数に符号化します。 （エスケープ書式と区別するために）文字列全体は\xという並びの後に付けられます。 一部の文脈では、先頭のバックスラッシュを二重にしてエスケープさせる必要があるかもしれません(以下を参照 4.1.2.1)。 これはエスケープ書式でバックスラッシュを二重にしなければならない場合と同じで、詳細は以下に示します。 入力する16進数の桁は大文字でも小文字でも構いません。 数字のペアの間に空白文字を入れることができます。 （しかし桁の組み合わせの間や先頭の\xの間には入れることはできません。） hex書式は外部のアプリケーションおよびプロトコルの間で広く互換性を持ち、また、エスケープ書式と比べ変換が高速になる傾向があります。 このため使用が好まれます。

Example: 例

SET bytea_output = 'hex';

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

The <quote>escape</quote> format is the traditional <productname>PostgreSQL</productname> format for the <type>bytea</type> 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. Therefore, this format should probably be avoided for most new applications. 「エスケープ」書式はbytea型用の伝統的なPostgreSQLの書式です。 これは、バイナリ列をASCII文字の並びとして表現しASCII文字として表現できないバイトは特殊なエスケープシーケンスとして表現するという方式を取ります。 アプリケーションの見地から文字として表現されたバイトが有意であれば、この表現は簡便です。 しかし現実にはバイナリ列と文字列の間の区別があいまいになりますので、通常は混乱します。 また選択されたこのエスケープ機構自体が多少非効率的です。 このためこの書式はおそらくほとんどの新しいアプリケーションでは避けるべきでしょう。

When entering <type>bytea</type> values in escape format, octets of certain values <emphasis>must</emphasis> be escaped, while all octet values <emphasis>can</emphasis> be escaped. In general, to escape an octet, convert it into its three-digit octal value and precede it by a backslash. Backslash itself (octet decimal value 92) can alternatively be represented by double backslashes. <xref linkend="datatype-binary-sqlesc"/> shows the characters that must be escaped, and gives the alternative escape sequences where applicable. エスケープ書式でbytea値を入力する際に、特定の値のオクテットをエスケープする必要があります。 なお、すべてのオクテットの値をエスケープすることができます。 一般的にあるオクテットをエスケープするには、それをその3桁の8進数に変換し、バックスラッシュを前に付けます。 他にもバックスラッシュ自体(10進数表記のオクテットで92)を二重のバックスラッシュとして表現することができます。 表 8.7には、エスケープする必要がある文字と、その適用可能な代替エスケープシーケンスを示しています。

The requirement to escape <emphasis>non-printable</emphasis> octets varies depending on locale settings. In some instances you can get away with leaving them unescaped. 実際には、表示できないオクテットに対するエスケープ要求はロケールの設定に依存して異なります。 ロケールの設定によっては、エスケープをしないで済むこともあります。

The reason that single quotes must be doubled, as shown in <xref linkend="datatype-binary-sqlesc"/>, is that this is true for any string literal in an SQL command. The generic string-literal parser consumes the outermost single quotes and reduces any pair of single quotes to one data character. What the <type>bytea</type> input function sees is just one single quote, which it treats as a plain data character. However, the <type>bytea</type> input function treats backslashes as special, and the other behaviors shown in <xref linkend="datatype-binary-sqlesc"/> are implemented by that function. 表 8.7で示したように、シングルクォートが二重に必要な理由は、SQLコマンド中のあらゆる文字列に当てはまるためです。 一般的な文字列パーサは最も外側のシングルクォートを消費し、シングルクォートのペアを一つの文字データに減らします。 byteaを入力する関数が見るのは単に一つのシングルクォートであり、一個の単純なデータ文字として扱います。 しかし、byteaを入力する関数はバックスラッシュを特別なものとして扱い、表 8.7に示されているその他の動作はこの関数で実装されています。

In some contexts, backslashes must be doubled compared to what is shown above, because the generic string-literal parser will also reduce pairs of backslashes to one data character; see <xref linkend="sql-syntax-strings"/>. 一般的な文字列パーサはバックスラッシュのペアを一つの文字データに減らすため、文脈によってはバックスラッシュは上記に見られるように、重ねる必要があります。 4.1.2.1も参照ください。

<type>Bytea</type> octets are output in <literal>hex</literal> format by default. If you change <xref linkend="guc-bytea-output"/> to <literal>escape</literal>, <quote>non-printable</quote> octets are converted to their equivalent three-digit octal value and preceded by one backslash. Most <quote>printable</quote> octets are output by their standard representation in the client character set, e.g.: Byteaオクテットはデフォルトではhex書式で出力されます。 bytea_outputをescapeに変えると、「表示できない」オクテットは先頭にバックスラッシュがついた3桁のオクテットの値に変換されます。 ほとんどの「表示可能な」オクテットはクライアント文字セットの標準的な表示で出力されます。例:

SET bytea_output = 'escape';

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

The octet with decimal value 92 (backslash) is doubled in the output. Details are in <xref linkend="datatype-binary-resesc"/>. 10進数で92(バックスラッシュ)を持つオクテットは出力時に二重になります。 詳細は表 8.8を参照してください。

Depending on the front end to <productname>PostgreSQL</productname> you use, you might have additional work to do in terms of escaping and unescaping <type>bytea</type> strings. For example, you might also have to escape line feeds and carriage returns if your interface automatically translates these. 使用するPostgreSQLのフロントエンドによっては、bytea文字列をエスケープまたはアンエスケープする追加的な作業が必要になることがあります。 例えば、使用するインタフェースが改行文字や復帰文字を自動的に翻訳してしまう場合、これらの文字もエスケープしなければならないかもしれません。