ruby中的postgres字节数组转义是否被破坏？

简单的例子：

Zlib::Inflate.inflate(PG::Connection.unescape_bytea(PG::Connection.escape_bytea(Zlib::Deflate.deflate('["128,491,128,487"]'))))
Zlib::DataError: incorrect data check

zlib没有此问题，因为以下操作成功：

Zlib::Inflate.inflate(Zlib::Deflate.deflate('["128,491,128,487"]'))
=> "[\"128,491,128,487\"]"

解析失败/成功取决于提供的字符串：

Zlib::Inflate.inflate(PG::Connection.unescape_bytea(PG::Connection.escape_bytea(Zlib::Deflate.deflate('["128,491,128,487", "128,491,128,490", "38,465,40,463"]'))))
=> "[\"128,491,128,487\", \"128,491,128,490\", \"38,465,40,463\"]"

是我做错了什么，还是博士后比提亚·菲尔德在红宝石中逃走了？作为替代方案，我可以做什么

试用版：Ruby 2.2.3p173，gem pg-0.18.4；Ruby 2.4.1p111，gem pg-0.21.0

对逃逸行为的描述具有误导性。它不是完全相反的

PG:：Connection.escape_bytea使用旧的和不推荐使用的转义机制，必须双重转义-首先作为bytea转义，其次作为字符串文本（在字符串之前和之后添加）插入SQL字符串。出于方便和性能方面的考虑，这是一步完成的

相反，PG:：Connection.unescape_bytea只执行bytea unescaping，因为它用于解码查询检索到的列数据。此数据不会作为字符串文字转义。 您现在有两个选项来实现上述功能：

enco = PG::TextEncoder::Bytea.new
deco = PG::TextDecoder::Bytea.new
Zlib::Inflate.inflate(deco.decode(enco.encode(Zlib::Deflate.deflate('["128,491,128,487"]'))))

这使得使用pg gem的类型编码器而不是libpq。编码器使用较新的BYTEA转义机制，比libpq的函数快一点。这仍然独立于服务器连接。 连接=PG.connect

Zlib::Inflate.inflate(conn.unescape_bytea(conn.escape_bytea(Zlib::Deflate.deflate('["128,491,128,487"]'))))

这利用了libpq的连接绑定转义函数。它们还使用较新的转义机制，因此不会发生双重转义。

回答：

对逃逸行为的描述具有误导性。它不是完全相反的

PG:：Connection.escape_bytea使用旧的和不推荐使用的转义机制，必须双重转义-首先作为bytea转义，其次作为字符串文本（在字符串之前和之后添加）插入SQL字符串。出于方便和性能方面的考虑，这是一步完成的

相反，PG:：Connection.unescape_bytea只执行bytea unescaping，因为它用于解码查询检索到的列数据。此数据不会作为字符串文字转义。 您现在有两个选项来实现上述功能：

enco = PG::TextEncoder::Bytea.new
deco = PG::TextDecoder::Bytea.new
Zlib::Inflate.inflate(deco.decode(enco.encode(Zlib::Deflate.deflate('["128,491,128,487"]'))))

这使得使用pg gem的类型编码器而不是libpq。编码器使用较新的BYTEA转义机制，比libpq的函数快一点。这仍然独立于服务器连接。 连接=PG.connect

Zlib::Inflate.inflate(conn.unescape_bytea(conn.escape_bytea(Zlib::Deflate.deflate('["128,491,128,487"]'))))

这利用了libpq的连接绑定转义函数。它们还使用较新的转义机制，因此不会发生双重转义