【问题标题】:invalid byte sequence for encoding "UTF8"编码“UTF8”的无效字节序列
【发布时间】:2011-06-19 12:44:55
【问题描述】:

我是trying to import some data 进入我的数据库。所以我创建了一个临时表,

create temporary table tmp(pc varchar(10), lat decimal(18,12), lon decimal(18,12), city varchar(100), prov varchar(2));

现在我正在尝试导入the data

 copy tmp from '/home/mark/Desktop/Canada.csv' delimiter ',' csv

然后我得到了错误,

ERROR:  invalid byte sequence for encoding "UTF8": 0xc92c

我该如何解决这个问题?我是否需要更改整个数据库的编码(如果需要,如何更改?)还是只更改tmp 表的编码?还是我应该尝试更改文件的编码?

【问题讨论】:

  • 在导入时更改编码选项。我将我的设置为“Windows-1251”,它毫无怨言地工作。
  • 感谢@BrianD,我也遇到了这个问题,这对我有用。

标签: postgresql import


【解决方案1】:

如果您需要在数据库中存储 UTF8 数据,则需要一个接受 UTF8 的数据库。您可以在 pgAdmin 中检查数据库的编码。只需右键单击数据库,然后选择“属性”。

但该错误似乎告诉您源文件中有一些无效的 UTF8 数据。这意味着copy 实用程序已检测到或猜测您正在为其提供 UTF8 文件。

如果您在某些 Unix 变体下运行,您可以使用 file 实用程序检查编码(或多或少)。

$ file yourfilename
yourfilename: UTF-8 Unicode English text

(我认为这也适用于终端中的 Mac。)不确定如何在 Windows 下执行此操作。

如果您对来自 Windows 系统的文件(即,以 UTF8 编码的文件)使用相同的实用程序,它可能会显示如下内容:

$ file yourfilename
yourfilename: ASCII text, with CRLF line terminators

如果情况仍然很奇怪,您可能会尝试将输入数据转换为已知编码,或更改客户端的编码,或两者兼而有之。 (我们真的在扩展我对编码的了解。)

您可以使用iconv 实用程序来更改输入数据的编码。

iconv -f original_charset -t utf-8 originalfile > newfile

您可以按照Character Set Support 上的说明更改 psql(客户端)编码。在该页面上,搜索短语“启用自动字符集转换”。

【讨论】:

  • 说文件是ASCII,但是里面有重音字符,那一定是错的吧?
  • 会接受这个答案,但我认为问题实际上出在数据上(更新后的 Q)。
  • 我觉得这很有帮助,谢谢。顺便说一句,它也可以在 OS X 终端上运行
  • 这对我有用,但方式略有不同。 “iconv”命令实际上轰炸了我的文件,但它确实在问题所在 - 某种奇怪的“-”字符。无论如何,我删除了它,我的文件能够加载到 postgres 中。感谢您的提示!
  • 只是为了帮助其他人和搜索引擎:这适用于将带有不可读字符的 Stripe CSV 导出转换回 UTF-8:` iconv -f ISO-8859-15 -t utf-8 客户。 csv > 客户-utf8.csv`
【解决方案2】:
psql=# copy tmp from '/path/to/file.csv' with delimiter ',' csv header encoding 'windows-1251';

添加encoding 选项在我的情况下有效。

【讨论】:

  • 它将完成而不会出错,它可能会或可能不会给出有用的结果。您需要知道数据的预期编码。
  • 在我的场景中,上面的查询是如何工作的?我有用 UTF8 编码的 csv 文件和用 UTF8 编码的 DB。
【解决方案3】:

如果您可以丢弃不可转换的字符,您可以使用-c 标志

iconv -c -t utf8 filename.csv > filename.utf8.csv

然后将它们复制到您的表中

【讨论】:

  • 在 Mac 上我是 iconv -c -t UTF-8 filename.csv > filename.utf8.csv
【解决方案4】:

显然我可以即时set the encoding

 set client_encoding to 'latin1'

然后重新运行查询。不知道我应该使用什么编码。


latin1 使字符清晰易读,但大多数重音字符是大写的,而它们不应该是大写。我认为这是由于编码错误造成的,但我认为它实际上只是糟糕的数据。我最终保留了 latin1 编码,但对数据进行了预处理并修复了大小写问题。

【讨论】:

  • 有趣的是,我在 SELECT 语句中遇到了错误!这解决了它,因为它是我的 psql client 给出了错误,而不是数据库本身。 (如果编码被禁止,它会首先拒绝数据。)
【解决方案5】:

此错误表示文件中的记录编码相对于连接不同。在这种情况下,iconv 可能会返回错误,有时即使 //IGNORE 标志:

iconv -f ASCII -t utf-8//IGNORE /a.txt

iconv: 位置非法输入序列(某个数字)

诀窍是找到不正确的字符并替换它。在 Linux 上使用“vim”编辑器:

vim(你的文本文件),按“ESC”:按钮并输入“:goto(iconv返回的数字)”

要查找非 ASCII 字符,您可以使用以下命令:

grep --color='auto' -P "[\x80-\xFF]"

如果你删除了不正确的字符,请检查你是否真的需要转换你的文件:可能问题已经解决了。

【讨论】:

  • iconv -c -f utf8 -t utf8//IGNORE < dirty.txt > clean.txt
【解决方案6】:

按照以下步骤在 pgadmin 中解决此问题:

  1. SET client_encoding = 'ISO_8859_5';

  2. COPY tablename(column names) FROM 'D:/DB_BAK/csvfilename.csv' WITH DELIMITER ',' CSV ;

【讨论】:

    【解决方案7】:

    这取决于生成您的导入文件的机器/编码类型。

    如果您是从英语或西欧版本的 Windows 获取它,最好的选择可能是将其设置为“WIN1252”。如果您是从其他来源获取的,请在此处查阅字符编码列表:

    http://www.postgresql.org/docs/8.3/static/multibyte.html

    如果您是从 Mac 获取它,您可能必须先通过“iconv”实用程序运行它,才能将它从 MacRoman 转换为 UTF-8。

    【讨论】:

      【解决方案8】:

      嗯,我也面临同样的问题。解决我的问题的是:

      在excel中点击另存为。 从另存为类型中,选择 .csv 点击工具。然后从下拉列表中选择网络选项。 在 Encoding 选项卡下,将文档另存为 Unicode(UTF-8)。单击确定。 保存文件。完成!

      【讨论】:

        【解决方案9】:

        我遇到了同样的问题,在这里找到了一个不错的解决方案: http://blog.e-shell.org/134

        这是由于您的数据库编码不匹配造成的,这肯定是因为您从中获取 SQL 转储的数据库被编码为 SQL_ASCII 而新的数据库被编码为 UTF8。 .. Recode 是 GNU 项目中的一个小工具,可让您即时更改给定文件的编码。

        所以我只是在播放之前重新编码了转储文件:

        postgres> gunzip -c /var/backups/pgall_b1.zip | recode iso-8859-1..u8 | psql test
        

        在 Debian 或 Ubuntu 系统中,recode 可以通过 package 安装。

        【讨论】:

          【解决方案10】:
          copy tablename from 'filepath\filename' DELIMITERS '=' ENCODING 'WIN1252';
          

          你可以试试这个来处理 UTF8 编码。

          【讨论】:

            【解决方案11】:

            用 PHP 解决这个问题的简短示例-

            $val = "E'\377'";
            iconv(mb_detect_encoding($val, mb_detect_order(), true), "UTF-8", $val);
            

            错误详情:由于 POSTGRES 数据库不处理除 UTF-8 以外的字符,当我们尝试将上述给定输入传递给列时,它会给出“用于编码“UTF8”的字节序列无效:0xab”的错误。

            因此,只需将该值转换为 UTF-8,然后再插入 POSTGRES 数据库即可。

            【讨论】:

              【解决方案12】:

              我遇到了同样的问题:我的文件未编码为 UTF-8。我已经通过使用记事本++打开文件并更改文件的编码来解决它。

              转到“编码”并选择“转换为 UTF-8”。 保存更改,仅此而已!

              【讨论】:

                【解决方案13】:

                我在 Windows 下专门使用 psql(没有图形工具)时遇到了这个问题。要解决此问题,请永久更改 psql(客户端)的默认编码以匹配 PostgreSQL 服务器的默认编码。在 CMD 或 Powershell 中运行以下命令:

                setx PGCLIENTENCODING UTF8
                

                关闭并重新打开命令提示符/Powershell 以使更改生效。

                通过使用记事本打开备份文件并转到文件 -> 另存为,将备份文件的编码从 Unicode 更改为 UTF8。将编码下拉列表从 Unicode 更改为 UTF8。 (还将保存类型从文本文档 (.txt) 更改为所有文件,以避免将 .txt 扩展名添加到备份文件的名称中)。 您现在应该可以恢复备份了。

                【讨论】:

                  【解决方案14】:

                  在 excel 中打开您的 csv 文件,并将其保存为 utf8-csv 格式

                  【讨论】:

                    【解决方案15】:

                    如果输入数据本身包含转义字符,则可能会发生此错误。默认情况下转义字符是“\”符号,因此如果您的输入文本包含“\”字符 - 请尝试使用 ESCAPE 选项更改默认值。

                    【讨论】:

                      【解决方案16】:

                      您可以用 sed 替换反斜杠字符,例如管道字符。

                      sed -i -- 's/\\/|/g' filename.txt
                      

                      【讨论】:

                        【解决方案17】:

                        对于python,你需要使用

                        类 pg8000.types.Bytea (str) Bytea 是一个 str 派生类,映射到 PostgreSQL 字节数组。

                        Pg8000.Binary(值) 构造一个保存二进制数据的对象。

                        【讨论】:

                          【解决方案18】:

                          通过 Notepad++ 打开文件 CSV。选择菜单Encoding\Encoding in UTF-8,然后手动修复几个单元格。

                          然后再次尝试导入。

                          【讨论】:

                            【解决方案19】:

                            在 Windows 上使用 pgadmin v4.4 的替代原因:

                            带有非 ASCII 字符的列名会以某种方式混淆 psql 导入命令,并给您这个不直观的错误消息。您的 UTF8 csv 数据可能没问题。

                            解决方案:

                            重命名您的字段。

                            例子:

                            "Résultat" -> resultat
                            

                            【讨论】:

                              【解决方案20】:

                              这个错误也很可能是字段被加密的地方。确保您查看的是正确的表,在某些情况下,管理员会创建一个您可以使用的未加密视图。我最近遇到了一个非常相似的问题。

                              【讨论】:

                                【解决方案21】:

                                我在尝试将 Excel 生成的 csv 复制到 Postgres 表(全部在 Mac 上)时遇到了同样的错误。我就是这样解决的:

                                1) 在 Atom(我使用的 IDE)中打开文件

                                2) 对文件进行微不足道的更改。保存文件。撤消更改。再次保存。

                                快!复制命令现在有效。

                                (我认为 Atom 以可行的格式保存它)

                                【讨论】:

                                  【解决方案22】:

                                  如果你的 CSV 要从 SQL Server 导出,它很大,并且有 Unicode 字符,你可以通过将编码设置为 UTF-8 来导出它:

                                  Right-Click DB > Tasks > Export > 'SQL Server Native Client 11.0' >> 'Flat File Destination > File name: ... > Code page: UTF-8 >> ...

                                  在下一页中,它会询问您是要从表中复制数据还是要编写查询。如果您的表中有charvarchar 数据类型,请选择查询选项并将这些列转换为nvarchar(max)。例如,如果myTable 有两列,第一列是varchar,第二列是int,我将第一列转换为nvarchar

                                  select cast (col1 as nvarchar(max)) col1
                                         , col2
                                  from myTable
                                  

                                  【讨论】:

                                    【解决方案23】:

                                    有些谩骂可能很啰嗦

                                    comlun 名称中的任何空格都会导致此问题

                                    查看每列名称 例如 "colum_name "#>>荣 "colum_nam"#>对

                                    【讨论】:

                                      猜你喜欢
                                      • 1970-01-01
                                      • 1970-01-01
                                      • 1970-01-01
                                      • 1970-01-01
                                      • 1970-01-01
                                      • 1970-01-01
                                      • 1970-01-01
                                      • 2021-05-01
                                      相关资源
                                      最近更新 更多