Erlang binary_to_term解析异常及跨语言读取PostgreSQL数据问题

1. 手动执行binary_to_term报bad_argument的原因及解决 #

核心原因 #

• PostgreSQL bytea格式差异：Erlang 17.1时期的项目，大概率采用PostgreSQL的escape格式存储bytea（旧版PostgreSQL默认格式，后续版本改为hex）。直接从数据库查询得到的是带转义符的字符串（比如\\、\xXX），而项目内的get_record函数已经做了转义解码，手动调用时直接用原始查询结果转二进制就会格式错误。
• Erlang版本兼容性：binary_to_term的序列化格式在Erlang版本迭代中有变化，若手动用高版本Erlang执行，可能无法兼容17.1版本生成的term结构。
• 自定义包装处理：项目存储时可能对term做了额外包装（比如前缀校验位、自定义编码），get_record会先剥离这些包装，手动调用时缺少该步骤导致报错。

解决步骤 #

• 确认数据库bytea格式：执行SQL语句SHOW bytea_output;，若返回escape，需先将查询到的转义字符串还原为原始二进制。比如在Erlang中用binary:replace/3处理转义符，或用PostgreSQL的decode(your_bytea_column, 'escape')函数直接获取原始二进制。
• 必须使用Erlang 17.1版本执行binary_to_term，避免版本不兼容问题。
• 查看get_record源码，复制它从数据库取数后的解码逻辑（比如是否调用了自定义转义处理函数），手动执行时照搬该流程。

2. 仅通过SQL获取正确值的可能性 #

原生SQL无法直接解析Erlang特有的term格式，因为term是Erlang专属的序列化结构，PostgreSQL没有内置解析函数。可行的替代方案：

• 若存储的是简单类型列表（如字符串、数字），可先将bytea转为十六进制或转义字符串，手动分析结构，但仅适用于极简单场景，效率低且易出错。
• 安装PostgreSQL的Erlang扩展（如plerlang），编写自定义SQL函数调用binary_to_term解析，但需要适配Erlang 17.1版本，维护成本较高，不推荐。
• 结论：仅靠原生SQL难以直接获取正确的列表值，建议通过Erlang程序解析。

3. Ruby项目读取该数据的可行性 #

可以读取，但需要借助第三方库处理Erlang term格式：

实现步骤 #

1. 处理bytea格式：从数据库读取bytea字段时，若存储格式是escape，需将转义字符串还原为原始二进制；若为hex格式，需解码十六进制字符串为二进制。
2. 使用Ruby库解析：借助erlang-term或ruby-erl这类gem，将二进制数据转换为Ruby对应的数据结构（Erlang列表对应Ruby数组）。

注意事项 #

• 确保选用的Ruby库支持Erlang 17.1版本的term格式，部分库仅适配新版Erlang的term结构。
• 复杂Erlang term（如自定义记录、进程ID、函数引用等）无法在Ruby中完全解析，仅能处理基本类型组成的列表。

内容的提问来源于stack exchange，提问作者Piotr Aleksandrowicz