Navicat导出PostgreSQL数组字段为CSV时默认扁平化而非保留原始格式，本质是JDBC驱动调用getString()所致；需通过array_to_string()、启用双引号文本限定符、UTF-8 with BOM编码等措施避免解析失真。
PostgreSQL数组字段导出CSV时默认会被扁平化，不是“保留格式”而是“避免失真”
Navicat 导出 PostgreSQL 的 ARRAY 类型（如 TEXT[]、INTEGER[]）到 CSV 时，不会原样保留 {a,b,c} 或 ARRAY['x','y'] 这类语法，而是直接转成字符串形式，比如 "{a,b,c}"（带双引号包裹）或 "{""a"",""b"",""c""}"。这不是 bug，是 PostgreSQL JDBC 驱动 + Navicat 导出逻辑的共同行为：它调用的是 JDBC 的 getString()，而非自定义序列化。
你真正要防的，是 CSV 解析器把数组内容里的逗号、换行、双引号当成分隔符或结构符——这会导致 Excel 或 Python pandas 读取后列错位、行断裂。
- 导出前在 SQL 中显式
CAST或array_to_string()：例如array_to_string(tags, '|')把{'web','api'}变成web|api，规避所有 CSV 元字符 - 若必须保留原始
{}格式，请确保 Navicat 导出向导中勾选「文本限定符」为双引号（默认已启用），且「字段分隔符」不用逗号，改用\t或| - 不要依赖「自动识别」：Navicat 不会主动检测某列是数组类型并特殊处理，它只按 JDBC 返回的字符串渲染
导出向导里哪些设置直接影响数组字段的可读性
你在「导出向导」中选中一张含数组字段的表后，关键控制点只有三个，其他全是干扰项：
- 「导出格式」必须选「文本文件」，不是 Excel 或 HTML——Excel 会把
{a,b}当普通字符串但丢失引号，后续无法反解 - 「文本限定符」保持默认双引号
"，不可为空或单引号；否则{hello,world}会被拆成两列 - 「编码」必须选
UTF-8 with BOM（尤其 Windows 环境），否则中文数组元素如{'用户','管理员'}在 Excel 里显示为乱码
注意：Include column headers 勾选与否不影响数组内容，但不勾选会让下游脚本难定位字段——建议始终开启。
为什么用 COPY 命令导出更可靠，但 Navicat 不走这条路
PostgreSQL 原生命令 COPY (SELECT ... ) TO '/path.csv' WITH (FORMAT CSV, HEADER true) 能严格遵循 RFC 4180，对数组字段输出标准 CSV 字符串（自动加引号、转义内部引号）。而 Navicat 从不调用 COPY，它走 JDBC ResultSet 流式拉取，再逐行拼接——这就绕过了服务端格式化逻辑。
从 CSV 数据集生成图数据库加载器和三元组映射。将表格 CSV 数据转换为图数据库可直接使用的节点、边和三元组。
所以当你发现 Navicat 导出的 CSV 里数组字段出现 "{""a"",""b""}" 而不是预期的 "{a,b}"，不是配置错了，是驱动把 PostgreSQL 的数组字面量二次转义了。此时唯一干净解法是改写查询：
SELECT
id,
name,
replace(replace(replace(arr_col::TEXT, '{', ''), '}', ''), '"', '') AS arr_flat
FROM your_table;
或者用 array_to_json(arr_col)::TEXT 得到 ["a","b"]，比花括号格式更通用。
容易被忽略的 PostgreSQL 特定陷阱
PostgreSQL 数组字段还有几个 Navicat 完全不提示、但会导致导出静默异常的点：
-
NULL数组和空数组{}表现一致：JDBC 都返回null字符串，导出 CSV 后都是空单元格，无法区分 - 多维数组（如
INTEGER[][]）会被转成类似"{{1,2},{3,4}}"，但 Navicat 不校验维度，若下游解析器不支持嵌套，直接报错 - 如果字段用了自定义域（domain）包装数组类型，比如
CREATE DOMAIN tag_list AS TEXT[]，Navicat 仍按基础类型处理，注释和约束信息全部丢失
真正需要保真导出的场景，别卡在 Navicat 图形界面里——用 psql + COPY，或写个简单 Python 脚本调用 psycopg2.extras.register_default_jsonb() 控制序列化行为。Navicat 是工具，不是数据格式转换器。
