The pgExpress Driver can handle Multibyte/UNICODE/Locales in the following ways:
Basicly, you just would have to set in your dbxconnections file:
LocaleCode = XXXX
XXXX
is the TLocaleCode type value for your
Locale. For instance:
LocaleCode = 1041
would set the current locale to 1041 (= Japanese).
Check the Delphi help for TLocaleCode
type,
TSQLConnection.LocaleCode
, and
Driver parameters
(you can use the help's 'Find'
feature if you don't locate these easily).
Using automatic PostgreSQL server-client conversion. The pgExpress Driver implements this by using the
parameter in the dbxconnections(.ini)
file (could also be a value in the TSQLConnection.Parameter
property).
Since dbExpress™ do not provide custom parameters support, and it does not support a ClientCharset
parameter, we have to use the following hack: providing both the Server and Client encodings
ServerCharset
parameter (the client encoding is optional). The format used is:
ServerCharset = ServerEncoding[/ClientEncoding]
Examples (you will actually use only one line at once):
ServerCharset = EUC_JP ServerCharset = EUC_TW/UNICODE
If no client/server encodings are set, defaults are using depending on the database encoding.
The valid encodings, from the PostgreSQL documentation, are:
Table 3.1. PostgreSQL Encodings
Encoding | Description |
---|---|
SQL_ASCII | ASCII |
EUC_JP | Japanese EUC |
EUC_CN | Chinese EUC |
EUC_KR | Korean EUC |
EUC_TW | Taiwan EUC |
BIG5 | Chinese BIG5 |
UNICODE | Unicode (UTF-8) |
MULE_INTERNAL | Mule internal code |
LATIN1 | ISO 8859-1 ECMA-94 Latin Alphabet No.1 |
LATIN2 | ISO 8859-2 ECMA-94 Latin Alphabet No.2 |
LATIN3 | ISO 8859-3 ECMA-94 Latin Alphabet No.3 |
LATIN4 | ISO 8859-4 ECMA-94 Latin Alphabet No.4 |
LATIN5 | ISO 8859-9 ECMA-128 Latin Alphabet No.5 |
LATIN6 | ISO 8859-10 ECMA-144 Latin Alphabet No.6 |
LATIN7 | ISO 8859-13 Latin Alphabet No.7 |
LATIN8 | ISO 8859-14 Latin Alphabet No.8 |
LATIN9 | ISO 8859-15 Latin Alphabet No.9 |
LATIN10 | ISO 8859-16 ASRO SR 14111 Latin Alphabet No.10 |
ISO-8859-5 | ECMA-113 Latin/Cyrillic |
ISO-8859-6 | ECMA-114 Latin/Arabic |
ISO-8859-7 | ECMA-118 Latin/Greek |
ISO-8859-8 | ECMA-121 Latin/Hebrew |
KOI8 | KOI8-R(U) |
WIN | Windows CP1251 |
ALT | Windows CP866 |
The values for valid server encoding and client encodings and their detailed descriptions are in the PostgreSQL's documentation at Multibyte Section ). Internally, pgExpress will interpret the values in the following way:
ServerEncoding
, the pgExpress will try to setup a default ClientEncoding
for it. The default
ClientEncoding
will be set by the libpq
the same as the ServerEncoding
, except for the
UNICODE
and MULE_INTERNAL
ServerEncoding
, whose have
no default value.
ClientEncoding
parameter, it will be set regardless of what is defined in the
ServerEncoding
parameter. If you want to set only a ClientEncoding
value, just omit the
ServerEncoding
value (but include the /
separator), like this:
ServerCharset = /latin2
This will set the ClientEncoding
to
latin2
regardless of the ServerEncoding
.
Other examples:
ServerCharset = latin2
The libpq
will set the ClientEncoding
to latin2
because it's the default
encoding for the latin2
ServerEncoding
.
ServerCharset = latin2/latin3
This will set the ClientEncoding
to latin3
.
As of BDS 2006 and pgExpress 4.x, there is also UNICODE support thorugh
use of TWideStringField
fields. To use
UNICODE, the following requirements must be met:
TWideStringField
fields; otherwise, they would be mapped as
TStringField
fields.
TWideMemo
support for dbExpress™. The VCL/CLX
will remap any fields defined as such as ftBlob/ftBinary.
If you have problems opening bases with UNICODE encoding ("Invalid encoding" errors), add a client encoding to
your dbxconnections(.ini)
entry, that will convert from multibyte to single byte encoding, according to your locale, such as:
ServerCharset = /latin1
...or:
ServerCharset = /latin1