Fix UTF-8 display for guru hints
Branch
--
master
Details
---
http://git.postgresql.org/gitweb?p=pgadmin3.git;a=commitdiff;h=95c14eea5e6ee502f3e64053a6cdbc89ba7487fd
Author: Marek Cernocky
Modified Files
--
CHANGELOG |1 +
docs/en_US
#283: Add an option to save files without UTF-8 BOM sequence
---+
Reporter: Taras Kopets | Owner: gleu
Type: feature | Status: closed
Priority: minor | Milestone: 1.14
#283: Add an option to save files without UTF-8 BOM sequence
--+-
Reporter: Taras Kopets | Owner: gleu
Type: feature | Status: assigned
Priority: minor | Milestone
#283: Add an option to save files without UTF-8 BOM sequence
--+-
Reporter: Taras Kopets | Owner: dpage
Type: feature | Status: new
Priority: minor | Milestone:
Component
Dear Andreas,
wxWindows includes an mbconv class to convert text into/from UTF-8:
http://www.lpthe.jussieu.fr/~zeitlin/wxWindows/docs/wxwin457.htm#unicode
http://www.lpthe.jussieu.fr/~zeitlin/wxWindows/docs/wxwin458.htm#mbconvclasses
It seems that wxWindows supports all encodings. It would allow
e done easilly?
- I think it is preferable to store all .po files in UTF-8 format. This will
help us track UTF-8 bugs. Also, it is always easier to have a single encoding
for all languages.
To convert language files to UTF-8:
recode latin1..utf8 DE_de/pgadmin3.po
Cheers,
Jea
g difference?
Latin is the other name for ISO-8859_1 which is the basic encoding of all
PCs. EUC_JP is not supported by Windows as it belongs to the Unix world.
But Windows has native support of Windows Japanese fonts. This is a
historical fact, before UTF-8, Windows could already display Japanese f
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 25 February 2002 11:25
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [ODBC] pgAdmin2 UTF-8 support
>
>
> Le Lundi 25 Février 2002 10:55, Dave Page a
> I tried EUC_JP, it does work.
Sorry, I meant it does NOT work.
Le Lundi 25 Février 2002 10:55, Dave Page a écrit :
> Does it matter? I thought it was the client encoding that mattered: I would
> guess that it should be set to EUC_JP.
Yes, it matters. EUC_JP is a unix encoding. It will never display under
Windows.
Jean-Michel
Hmm - interesting idea. We werent able to display or enter hebrew chars in
Pgadmin2 because apparently the VB objects it uses dont support hebrew. Let
me try and I'll get back to you real soon
danny
Le Lundi 25 Février 2002 10:55, vous avez écrit :
> Does it matter? I thought it was the client encoding that mattered: I would
> guess that it should be set to EUC_JP.
I tried EUC_JP, it does work. This is a Japanese encoding for Unixes. We need
its Windows equivalent, if exists. It could be ad
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 25 February 2002 09:42
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [ODBC] pgAdmin2 UTF-8 support
>
>
> Le Lundi 25 Février 2002 10:23, Dave Pag
Dear Danny,
Could you try pgAdmin2 and enter 'SET CLIENT_ENCODING = ISO-8859-8'. Then try
to display data in pgAdmin2. Does it work?
Information can be found at
http://developer.postgresql.org/docs/postgres/multibyte.html#AEN16680
Cheers,
Jean-Michel POURE
Le Lundi 25 Février 2002 10:23, Dave Page a écrit :
> Cool. Is it possible for you to try a simple test on one of your Japanese
> databases?
I don't knwo the Windows encodings names.
byte.html#AEN13682
A guy already did what we are looking for :
UTF-8 <-> WIN1250 ( Czeck I guess).
It should be possible to ask PostgreSQL to recode UTF-8 into :
- Japanse Windows,
- Chinses Windows,
- Hebrew Windows...
Recode manual can be found at:
http://www.iro.umontreal.ca/contrib/recode/HTML/recode.html
> We have a Unicode hebrew db in PG7.2. Uou dont need to write the functions
> and views in UTF-8 unless you have some
> literals inside the code. We had this issue with Hebrew; so we store all
> the literals as tokens in another table which may have some overhead but
>
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 25 February 2002 09:15
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [ODBC] pgAdmin2 UTF-8 support
>
>
> Le Lundi 25 Février 2002 10:02, Dave Pa
for Japanese/Hebrew
> etc...
Yes.
PostgreSQL uses the recode library.
Recode can translate UTF-8 to any Windows encoding. i.e, it should be
possible to translate UTF-8 (server) to Hebrew (Windows encoding, client),
provided that Western VB is able to display Windows Hebrew fonts (which
should
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 25 February 2002 08:51
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [ODBC] pgAdmin2 UTF-8 support
>
>
> > OK, what about if you select the dat
> OK, what about if you select the data back in pgAdmin - does it then
> display it?
Sure, it does. This is a new feature of PostgreSQL 7.2.
> Also, does SET CLIENT_ENCODING SQL_ASCII; work?
No it does not. "é" is stored as 'i'.
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 25 February 2002 08:39
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [ODBC] pgAdmin2 UTF-8 support
>
>
> Le Lundi 25 Février 2002 09:29,
Le Lundi 25 Février 2002 09:29, Dave Page a écrit :
> SET CLIENT_ENCODING Latin1;
> INSERT INTO table_foo (field_bar) VALUES ('é'); SELECT field_bar FROM
> table_foo WHERE field_bar='é';
In case of an UTF-8 database,
- schema queries should always be sent in Lati
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 25 February 2002 08:30
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [ODBC] pgAdmin2 UTF-8 support
>
>
> Le Lundi 25 Février 2002 09:29, Dave Page
Le Lundi 25 Février 2002 09:29, Dave Page a écrit :
> Presumably we should do this in SQL (I don't think you can do it in the
> ODBC connect string can you?). Have you tried in pgAdmin:
>
> SET CLIENT_ENCODING Latin1;
> INSERT INTO table_foo (field_bar) VALUES ('é'); SELECT field_bar FROM
> table_
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 25 February 2002 08:18
> To: Dave Page
> Cc: [EMAIL PROTECTED]
> Subject: Re: [pgadmin-hackers] [ODBC] pgAdmin2 UTF-8 support
>
>
> Dear Dave,
>
> I used pgsql with Pos
Jean Michel
We have a Unicode hebrew db in PG7.2. Uou dont need to write the functions
and views in UTF-8 unless you have some
literals inside the code. We had this issue with Hebrew; so we store all
the literals as tokens in another table which may have some overhead but
makes for great
Dear Dave,
I used pgsql with PostgreSQL 7.2 and noticed there was an automatic
translation between UTF-8 <-> Latin characters. This is a new feature of
PostgreSQL 7.2.
So fine :
Suppose we have a Unicode database :
\Encoding Latin1 (\same with \Encoding SQL_ASCII does not work)
INSER
Dear friends,
PostgreSQL 7.2 offers extensive UTF-8 support. In case of an UTF-8 database,
the big news seems that we now have to write function and view definitions in
UTF-8.
The problem is that pgAdmin2, HighlightBox (the colour code editor) and the
result view do not support Unicode by
Dear all,
I am trying to test pgAdmin2 compliance with Unicode:
- PostgreSQL 7.1.3 is configured with Unicode support. My test database is
Unicode. I can display Japanese glyphs in Php, so I presume everything is
configured well.
- ODBC. Connect string is set to SET CLIENT_ENCODING = 'UNICODE';
At 11:01 09/11/01 +, you wrote:
>Others are saying UTF-8 is possible (pseudo UTF-8 anyway, it's actually a
>subset of UTF-16) but is *seriously* difficult. I've not found any real
>answers though :-(
Microsoft declares UTF-8/16 compatible as for VB 6 SP3+, including contro
> -Original Message-
> From: Jean-Michel POURE [mailto:[EMAIL PROTECTED]]
> Sent: 09 November 2001 10:39
> To: [EMAIL PROTECTED]
> Cc: dave Page
> Subject: Re: [pgadmin-hackers] UTF-8
>
>
> At 11:21 09/11/01 +0100, you wrote:
> >Arial Unicode M
At 11:21 09/11/01 +0100, you wrote:
>Arial Unicode MS 51,180 glyphs in version 0.86
Well, after testing, using Arial Unicode MS does not suffice.
I am sure PostgreSQL backend is well configured as I display Japanese fonts
with PHP.
Maybe we need to configure odbc to declare it as an UT
>Yes, isn't this also the case with Unicode data? When you mentioned that
>before I asked how to fix it and nobody could tell me... There was mention
>of using a Unicode font, but that was many megabytes in size as I recall.
>
>Suggestions?
Yes, you are right.
I am doing a test with Arial Unicod
34 matches
Mail list logo
