Re: Encoding, character not shown correctly in pgAdmin or in query - Mailing list pgsql-novice
| From | Gerald Cheves |
|---|---|
| Subject | Re: Encoding, character not shown correctly in pgAdmin or in query |
| Date | |
| Msg-id | 52FF72A5.6090002@verizon.net Whole thread Raw |
| In response to | Re: Encoding, character not shown correctly in pgAdmin or in query (Gerald Cheves <gcheves@verizon.net>) |
| List | pgsql-novice |
An important restriction, however, is that each database's character set must be compatible with the database's LC_CTYPE (character classification) and LC_COLLATE (string sort order) locale settings. For C or POSIX locale, any character set is allowed, but for other locales there is only one character set that will work correctly. (On Windows, however, UTF-8 encoding can be used with any locale.)
example:
initdb defines the default character set (encoding) for a PostgreSQL cluster. For example,
initdb -E EUC_JPsets the default character set to EUC_JP (Extended Unix Code for Japanese). You can use --encoding instead of -E if you prefer longer option strings. If no -E or --encoding option is given, initdb attempts to determine the appropriate encoding to use based on the specified or default locale.
You can specify a non-default encoding at database creation time, provided that the encoding is compatible with the selected locale:
createdb -E EUC_KR -T template0 --lc-collate=ko_KR.euckr --lc-ctype=ko_KR.euckr koreanThis will create a database named korean that uses the character set EUC_KR, and locale ko_KR. Another way to accomplish this is to use this SQL command:
CREATE DATABASE korean WITH ENCODING 'EUC_KR' LC_COLLATE='ko_KR.euckr' LC_CTYPE='ko_KR.euckr' TEMPLATE=template0;Notice that the above commands specify copying the template0 database. When copying any other database, the encoding and locale settings cannot be changed from those of the source database, because that might result in corrupt data. For more information see Section 21.3.
On 2/15/2014 8:31 AM, Gerald Cheves wrote:
The full list of available character sets are contained in this document
Some of the ISO variations may work ...
http://www.postgresql.org/docs/current/static/multibyte.htmlSiamo arrivati sani e salviOn , Gerald Cheves <gcheves@verizon.net> wrote:I understand what you mean. Try All of the LATIN variations - LATIN1, LATIN2 ...., LATIN10Siamo arrivati sani e salviOn Saturday, February 15, 2014 7:39 AM, avpro avpro <avprowebeden@gmail.com> wrote:Hi,I was saying that after I I imported the file with LATIN1 all unrecognized characters were replaced with "?".On 15 February 2014 13:17, Gerald Cheves <gcheves@verizon.net> wrote:I had a similar problem. Try different encodings like this command:
set client_encoding to 'LATIN1';
Then:
COPY filename
FROM 'file/path/filename.csv'
WITH DELIMITER ',' CSV HEADER;
On 2/15/2014 6:18 AM, avpro avpro wrote:
Hello all,
In postgresql 9.3 using pgAdmin, I created a table for my application developed in Qt Creator.
the table contains:
idstudent - pk
name
country
town
street
I would like to import a csv file containing all the info about these students. The file was saved/encoded in excel with UTF8 characters.
When I'm importing my file in psql, using the encoding UTF8, I receive the following error for each character not recognized:
"error: invalid byte sequence for encoding "UTF8": ... " followed by the character code
I tried to import the file using SQL_ASCII, I got similar errors.
I tried to import the file using MULE_INTERNAL and it worked, but the characters not recognized are not shown correct in pdAdmin and in my application when query is executed. For example after I imported the file with LATIN1 all unrecognized characters were replaced with "?".
Any suggestion what encoding shall I use to display the characters correctly?
note: the student's names and addresses are written using characters from North Europe, Eastern EU, Russia, South America, Asia, etc. everywhere.
Thank you for your input.----
siamo arrivati sani e salvi
Sent via pgsql-novice mailing list (pgsql-novice@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-novice
-- siamo arrivati sani e salvi
pgsql-novice by date: