Sto ottenendo il seguente eccezione:caratteri con la codifica UTF-8 non ha equivalenti in win1252
Caused by: org.postgresql.util.PSQLException: ERROR: character 0xefbfbd of encoding "UTF8" has no equivalent in "WIN1252"
Esiste un modo per sradicare tali caratteri, tramite SQL o di programmazione?
(la soluzione SQL deve essere preferita).
Stavo pensando di connettermi al DB usando WIN1252, ma darà lo stesso problema.
Cosa fai quando ricevi questo messaggio? Importa un file su Postgres? Come ha detto il devstuff, è un personaggio BOM. Questo è un carattere che Windows scrive per primo in un file di testo, quando viene salvato nella codifica UTF8 - è invisibile, con carattere a larghezza 0, quindi non lo vedrai quando lo si apre in un editor di testo.
Prova ad aprire questo file, ad esempio Blocco note, salva, come nella codifica ANSI e aggiungi (o sostituisci) la riga set client_encoding to 'WIN1252' nel file.
Stiamo recuperando alcuni dati da un DB di origine (UTad-8 codificato Teradata DB) e scrivendolo in un DB di destinazione (DB Postgres con codifica WIN1252). Penso che non ci sia nulla che possiamo fare per convertire questi caratteri in WIN1252 poiché non sono supportati, per questo motivo volevamo ignorarli mentre andavamo a cercare dal DB di origine o salvavamo nel DB di destinazione. –
È quindi possibile importare questi dati prima in bytea e quindi utilizzare convert_from (stringa bytea, digitare testo). Puoi definire la tua funzione facendo una conversione usando "crea conversione". Questa funzione può ignorare i caratteri che non si trovano in WIN1252. È più facile utilizzare un filtro di programma per i dati "dovrebbe fare iconv -f utf-8 -t windows-1252 // translit". – Tometzky
Più facile: importare i dati nel database UTF-8 temporaneo in PostgreSQL, esportarli in file di testo usando pg_dump, convertire il file in WIN1252 usando "iconv -f utf-8 -t windows-1252 // translit", convertire un file in UTF- 8 utilizzando "iconv -t windows-1252 -t utf-8" e quindi importare questo file nel nuovo database WIN1252. – Tometzky
Non erodicare i personaggi, sono reali e utilizzati per validi motivi. Invece, eridicare Win1252.
Vorrei poterlo fare, è un requisito :) –
Sembra la sequenza di byte 0xBD, 0xBF, 0xEF come un intero little-endian. Questa è la forma codificata UTF8 del carattere 0xFEFF del byte-order-mark (BOM) Unicode.
Non sono sicuro del comportamento normale di Postgre, ma la distinta materiali viene normalmente utilizzata solo per il rilevamento della codifica all'inizio di un flusso di input e in genere non viene restituita come parte del risultato.
In ogni caso, l'eccezione è dovuta a questo punto codice che non ha una mappatura nella codepage Win1252. Ciò si verificherà anche con la maggior parte degli altri caratteri non latini, come quelli usati negli script asiatici.
È possibile modificare la codifica del database in modo che sia UTF8 anziché 1252? Ciò consentirà alle colonne di contenere quasi qualsiasi carattere.
No, non possiamo cambiare la codifica del database di destinazione in UTF8. –
La forma codificata UTF-8 di 0xFEFF è "0xEFBBBF", non "0xEFBFBD". L'OP è la forma codificata UTF-8 del carattere di sostituzione 0x0fffd: " " –
Avevo un problema simile e ho risolto impostando la codifica su UTF8 con \encoding UTF8 nel client prima di tentare uno INSERT INTO foo (SELECT * from bar WHERE x=y);. Il mio client utilizzava la codifica WIN1252 ma il database era in UTF8, quindi l'errore.
Ulteriori informazioni sono disponibili sul wiki PostgreSQL sotto Character Set Support (devel docs).
sono stato in grado di ottenere intorno ad esso utilizzando la funzione sottostringa Postgres' e selezionando che invece:
select substring(comments from 1 for 200) from billing
Il commento che il carattere speciale iniziato ciascun campo è stato un grande aiuto per risolverlo definitivamente.
Ho avuto un problema molto simile. Ho avuto un server collegato da SQL Server a un database PostgreSQL. Alcuni dati che avevo nella tabella che stavo selezionando usando un'istruzione openquery avevano un carattere che non aveva un equivalente in Win1252. Il problema era che la voce DSN di sistema (che si trovava sotto l'amministratore ODBC Data Source) che avevo usato per la connessione era configurata per utilizzare ANSI PostgreSQL (x64) anziché Unicode PostgreSQL (x64). La creazione di una nuova fonte di dati con il supporto Unicode e la creazione di un nuovo server collegato modificato e il riferimento al nuovo server collegato in openquery hanno risolto il problema per me. Giorni felici.
Questo problema è apparso per noi intorno al 19/11/2016 con la nostra vecchia Access 97 che accedeva a un DB postgresql 9.1.
Questo problema è stato risolto modificando il driver in UNICODE anziché ANSI (vedere commento plang).
Ecco cosa ha funzionato per me: 1 abilitare query ad-hoc in sp_configure. 2 aggiungi ODBC DSN per il tuo server PostgreSQL collegato. 3 assicurati di avere entrambi i driver ANSI e Unicode (x64) (prova con entrambi). 4 eseguire query come questo qui sotto - cambiare UID, server ip, nome db e password. 5 mantieni la query nell'ultima riga nel formato PostgreSQL.
EXEC sp_configure 'show advanced options', 1
RECONFIGURE
GO
EXEC sp_configure 'ad hoc distributed queries', 1
RECONFIGURE
GO
SELECT * FROM OPENROWSET('MSDASQL',
'Driver=PostgreSQL Unicode(x64);
uid=loginid;
Server=1.2.3.41;
port=5432;
database=dbname;
pwd=password',
'select * FROM table_name limit 10;')
per favore dimmi la soluzione di questa domanda perché ho avuto un problema simile. – TopDeveloper
Ho avuto un errore simile sul mio setup, dopo aver migrato un database da LATIN1 a UTF8. Il problema era un driver ODBC ANSI, quando era previsto UNICODE. – plang