séquence d'octets non valide pour le codage «UTF8»

J'essaie d'importer des données dans ma base de données. J'ai donc créé une table temporaire,

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

Et maintenant j'essaye d'importer les données ,

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

Mais alors j'obtiens l'erreur,

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

Comment résoudre ce problème? Dois-je changer le codage de toute ma base de données (si oui, comment?) Ou puis-je changer uniquement le codage de ma tmptable? Ou devrais-je essayer de modifier le codage du fichier?

Si vous avez besoin de stocker des données UTF8 dans votre base de données, vous avez besoin d'une base de données qui accepte UTF8. Vous pouvez vérifier l'encodage de votre base de données dans pgAdmin. Faites un clic droit sur la base de données et sélectionnez "Propriétés".

Mais cette erreur semble vous indiquer que votre fichier source contient des données UTF8 invalides. Cela signifie que l' copyutilitaire a détecté ou deviné que vous lui fournissez un fichier UTF8.

Si vous utilisez une variante d'Unix, vous pouvez vérifier l'encodage (plus ou moins) avec l' fileutilitaire.

$ file yourfilename
yourfilename: UTF-8 Unicode English text

(Je pense que cela fonctionnera également sur les Mac dans le terminal.) Je ne sais pas comment faire cela sous Windows.

Si vous utilisez ce même utilitaire sur un fichier provenant de systèmes Windows (c'est-à-dire un fichier qui n'est pas encodé en UTF8), il affichera probablement quelque chose comme ceci:

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

Si les choses restent bizarres, vous pouvez essayer de convertir vos données d'entrée en un encodage connu, de changer l'encodage de votre client, ou les deux. (Nous repoussons vraiment les limites de mes connaissances sur les encodages.)

Vous pouvez utiliser l' iconvutilitaire pour modifier le codage des données d'entrée.

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

Vous pouvez modifier le codage psql (le client) en suivant les instructions sur la prise en charge des jeux de caractères . Sur cette page, recherchez l'expression «Pour activer la conversion automatique du jeu de caractères».

psql=# copy tmp from '/path/to/file.csv' with delimiter ',' csv header encoding 'windows-1251';

L'ajout d'une encodingoption a fonctionné dans mon cas.

Apparemment, je peux simplement définir l'encodage à la volée,

 set client_encoding to 'latin1'

Et puis réexécutez la requête. Je ne sais pas quel encodage je devrais utiliser cependant.

latin1rendaient les caractères lisibles, mais la plupart des caractères accentués étaient en majuscules là où ils n'auraient pas dû être. J'ai supposé que cela était dû à un mauvais encodage, mais je pense que ce sont en fait les données qui étaient tout simplement mauvaises. J'ai fini par garder l'encodage latin1, mais j'ai prétraité les données et j'ai corrigé les problèmes de casse.

Si vous acceptez de supprimer les caractères non convertibles, vous pouvez utiliser l' -cindicateur

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

puis copiez-les dans votre table

Cette erreur signifie que le codage des enregistrements dans le fichier est différent par rapport à la connexion. Dans ce cas, iconv peut renvoyer l'erreur, parfois même malgré l'indicateur // IGNORE:

iconv -f ASCII -t utf-8 // IGNORER <b.txt> /a.txt

iconv: séquence d'entrée illégale à la position (un certain nombre)

L'astuce consiste à trouver des caractères incorrects et à les remplacer. Pour le faire sous Linux, utilisez l'éditeur "vim":

vim (votre fichier texte), appuyez sur "ESC": bouton et tapez ": goto (numéro renvoyé par iconv)"

Pour rechercher des caractères non ASCII, vous pouvez utiliser la commande suivante:

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

Si vous supprimez des caractères incorrects, veuillez vérifier si vous avez vraiment besoin de convertir votre fichier: le problème est probablement déjà résolu.

suivez les étapes ci-dessous pour résoudre ce problème dans pgadmin:

1. SET client_encoding = 'ISO_8859_5';

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

Cela dépend du type de machine / d'encodage qui a généré votre fichier d'importation.

Si vous l'obtenez à partir d'une version anglaise ou européenne de Windows, votre meilleur pari est probablement de le définir sur «WIN1252». Si vous l'obtenez d'une autre source, consultez la liste des encodages de caractères ici:

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

Si vous l'obtenez à partir d'un Mac, vous devrez peut-être l'exécuter d'abord via l'utilitaire "iconv" pour le convertir de MacRoman en UTF-8.

Eh bien, je faisais face au même problème. Et ce qui a résolu mon problème est le suivant:

Dans Excel, cliquez sur Enregistrer sous. Dans enregistrer en tant que type, choisissez .csv Cliquez sur Outils . Ensuite, choisissez les options Web dans la liste déroulante. Sous l' onglet Encodage , enregistrez le document au format Unicode (UTF-8) . Cliquez sur OK. Enregistrez le fichier. TERMINÉ !

J'ai eu le même problème, et j'ai trouvé une belle solution ici: http://blog.e-shell.org/134

Cela est dû à une discordance dans les encodages de votre base de données, sûrement parce que la base de données d'où vous avez obtenu le vidage SQL a été encodée en SQL_ASCII tandis que la nouvelle est encodée en UTF8. .. Recode est un petit outil du projet GNU qui vous permet de changer à la volée l'encodage d'un fichier donné.

Je viens donc de recoder le fichier de vidage avant de le lire:

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

Dans les systèmes Debian ou Ubuntu, recode peut être installé via un package.

Vous pouvez remplacer le caractère barre oblique inverse par, par exemple, un caractère pipe, par sed.

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

copy tablename from 'filepath\filename' DELIMITERS '=' ENCODING 'WIN1252';

vous pouvez essayer ceci pour gérer l'encodage UTF8.

Petit exemple pour résoudre ce problème en PHP-

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

Détail de l'erreur: Comme la base de données POSTGRES ne gère pas les caractères autres que UTF-8 lorsque nous essayons de passer les entrées données ci-dessus à une colonne, elle donne une erreur de "séquence d'octets invalide pour le codage" UTF8 ": 0xab".

Il suffit donc de convertir cette valeur en UTF-8 avant l'insertion dans la base de données POSTGRES.

J'ai eu le même problème: mon fichier n'était pas encodé en UTF-8. Je l'ai résolu en ouvrant le fichier avec notepad ++ et en modifiant l'encodage du fichier.

Allez dans "Encodage" et sélectionnez "Convertir en UTF-8". Enregistrez les modifications et c'est tout!

Cette erreur peut se produire si les données d'entrée contiennent elles-mêmes un caractère d'échappement. Par défaut, le caractère d'échappement est le symbole "\", donc si votre texte d'entrée contient le caractère "\" - essayez de changer la valeur par défaut en utilisant l'option ESCAPE.

Pour python, vous devez utiliser

Classe pg8000.types.Bytea (str) Bytea est une classe dérivée de str qui est mappée à un tableau d'octets PostgreSQL.

ou

Pg8000.Binary (valeur) Construit un objet contenant des données binaires.

J'ai rencontré ce problème sous Windows en travaillant exclusivement avec psql (pas d'outils graphiques). Pour résoudre ce problème, modifiez définitivement le codage par défaut de psql (client) pour qu'il corresponde au codage par défaut du serveur PostgreSQL. Exécutez la commande suivante dans CMD ou Powershell:

setx PGCLIENTENCODING UTF8

Fermez et rouvrez votre invite de commande / Powershell pour que la modification prenne effet.

Changez l'encodage du fichier de sauvegarde d'Unicode en UTF8 en l'ouvrant avec le Bloc-notes et en allant dans Fichier -> Enregistrer sous. Modifiez la liste déroulante Encodage d'Unicode en UTF8. (Modifiez également le type Enregistrer sous de Documents texte (.txt) à Tous les fichiers afin d'éviter d'ajouter l'extension .txt au nom de votre fichier de sauvegarde). Vous devriez maintenant pouvoir restaurer votre sauvegarde.

Il est également très possible avec cette erreur que le champ soit chiffré en place. Assurez-vous que vous regardez la bonne table, dans certains cas, les administrateurs créeront une vue non chiffrée que vous pourrez utiliser à la place. J'ai récemment rencontré un problème très similaire.

J'ai eu la même erreur lorsque j'essayais de copier un csv généré par Excel dans une table Postgres (le tout sur un Mac). Voici comment je l'ai résolu:

1) Ouvrez le fichier dans Atom (l'IDE que j'utilise)

2) Apportez une modification insignifiante au fichier. Enregistrez le fichier. Annulez la modification. Enregistrez à nouveau.

Presto! La commande de copie fonctionnait maintenant.

(Je pense qu'Atom l'a sauvegardé dans un format qui a fonctionné)

Ouvrez le fichier CSV par Notepad ++. Choisissez le menu Encoding\Encoding in UTF-8 , puis corrigez manuellement quelques cellules.

Puis réessayez d'importer.

Si votre CSV doit être exporté depuis SQL Server, il est énorme et contient des caractères Unicode, vous pouvez l'exporter en définissant l'encodage comme suit UTF-8:

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

Dans la page suivante, il vous demande si vous souhaitez copier les données d'une table ou si vous souhaitez écrire une requête. Si vous avez des types de données charou varchardans votre table, sélectionnez l'option de requête et convertissez ces colonnes en nvarchar(max). Par exemple, si myTablea deux colonnes où la première est varcharet la seconde int, je lance la première pour nvarchar:

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