windows 和 linux 之间的编码和 pg_dump/restore 问题

Question

我有一个使用 WIN1252 编码的 pg_dump 创建的 dmp 文件。我想做的是使用 pg_restore 将它导入到 Linux 机器上的数据库中。问题是在 Windows 机器上 postgreSQL 识别编码 WIN1252 但不识别 CP1252 编码（它们都是相同的，只是相同标准的不同名称）。在 Linux 机器上，postgreSQL 能识别 CP1252 但不能识别 WIN1252。因此，当我尝试执行 pg_restore 时，出现错误，因为 WIN1252 未被识别为正确的编码。此外，如果我尝试在 Windows 上执行 pg_dump 并将编码指定为 CP1252，则会出现类似的错误。我想坚持使用这种编码格式，因此在 utf8 中执行 pg_dump 或其他事情不是我想做的事情。任何帮助，将不胜感激！

编辑：实际上，经过进一步调查，postgreSQL 不理解 cp1252。用于将文本文件从一种编码转换为另一种编码的 iconv linux 命令理解 cp1252 而不是 win1252，这就是我从哪里得到它的。在Linux机器上，我仍然无法将客户端编码设置为WIN1252。这是错误消息：

FATAL:  conversion between WIN1252 and LATIN1 is not supported

变量 client_encoding 在 Linux 机器上最初设置为 UTF8，所以我不知道 LATIN1 来自哪里。除非不支持 WIN1252，否则 postgres 会尝试将其转换为 latin1，因为这是最接近它的东西，并且由于某些字符不匹配而无法实现？

Answer 1

我参加聚会迟到了，但我认为接受的答案并不能说明全部情况。

如果您使用的是语法

pg_dump ... > out.sql

，那么实际上是 shell 将文件写入磁盘，而不是 pg_dump。有时，Windows 中的 shell 在写入文件时会“帮助”将其转换为另一个字符集。我发现cmd.exe在 Windows 11 上将我的输出写入某种形式的 UTF-16（不确定是 LE 还是 BE），而不是我指定的 UTF-8-E。结果文件大小是我预期的两倍！

为了真正安全，最好使用-E 和选项-f来指定文件名：

pg_dump -E UTF-8 -f out.sql

这样，就可以绕过 shell 重定向（以及可能的字符集转换），并且pg_dump直接写入输出文件，从而完全控制编码过程。

额外的好处是，shell 的字符集转换也会带来额外的性能开销，因此直接写入文件可能也会稍微快一些。

Answer 2

我假设您的转储文件以 WIN1252 编码，而 Linux 上的目标数据库以 LATIN1 作为服务器编码。正如错误消息所示，这是行不通的。

我建议您使用UTF8重新初始化目标数据库。

或者，使用 选项以 UTF8 创建转储pg_dump -E。