апостроф в PostgreSQL запрос выходит (32-битный) c3 a2 c2 80 - PullRequest
0 голосов
/ 31 марта 2020

В процессе вставки строк в PostgreSQL 11.3 из CSV-файла и последующего выполнения запросов я получил (32 бита) шестнадцатеричный "c3 a2 c2 80" вместо того, что должно было быть апострофом (8 -битовый гекс 27). Что случилось?

1 Ответ

0 голосов
/ 09 апреля 2020

Вы перепутались с кодировкой. Вот пример того, как вы это сделали:

Исходный символ, вероятно, был не апострофом, а либо ‘ (символ ЮНИКОД 2018), либо ’ (символ ЮНИКОД 2019).

Исходный файл, вероятно, был закодирован в UTF-8, где символ закодирован как Hex E2 80 98 (для U + 2018) или Hex E2 80 99 (для U + 2019).

Теперь вы использовали COPY (вероятно, COPY FROM STDIN, вы не сообщаете нам подробности) с другой однобайтовой кодировкой, например LATIN1 (ISO 8859-1). Затем PostgreSQL будет интерпретировать каждый байт как один символ и преобразовать его в кодировку базы данных (UTF8).

Первый байт (шестнадцатеричный E2, â в LATIN1) станет шестнадцатеричным C3 A2 в UTF-8, а второй байт (Hex 80, непечатаемый управляющий символ в LATIN1) станет Hex C2 80 в UTF-8, и это именно то, что вы наблюдаете.

Вы можете проверить мой гипотеза путем проверки двух следующих байтов: Hex C2 98 или Hex C2 99.

Решение состоит в том, чтобы правильно указать кодировку файла как UTF-8 при загрузке файла CSV в базу данных. С COPY вы можете использовать опцию ENCODING, чтобы сделать это.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...