Sven K�hler wrote:
UTF-8 is no single-byte charset cause one char get's tranformed into 2
or more bytes. That's why i would call the PostgreSQL's behaviour a bug.
Yup - I totally agree. But I didn't say it's a *bug* - i sayed it's a
*matter* ;-)
To my knowledge there is none. If you insert UTF-8 formatted data into a
UNICODE database, that UTF-8 string will be transformed into a mixture
of UTF-8 and UCS with is the worse thing i can imagine.
Today I tried UTF-8-to-UCS-2 conversion on application level and
inserting the UCS-2 data as hex-value within an ASCII-encoded SQL query
into a Unicode-column of a table in a regular (_UNICODE=NO) database.
Example: The query "INSERT INTO my_table(my_ucs2_column) VALUES
(X'7400650073007400')" should insert the UCS-2 sting "test" into the
Unicode-column "my_ucs2_column".
However... It seems that was too cracy to work out. The result is an
Error -3005 at POS(1) (Invalid SQL statement).
The problem with PHP is, that PHP _does_ _not_ support unicode.
functions like utf8encode() that i found in the php-docs are just
"bridges" to applications/APIs that need UTF-8 input, but you will never
be abled to correctly handle a unicode-string.
unfortunately that's correct. there are couple of conversion tools like
the iconf-functions which can convert almost anything to anything, but
internally PHP can't deal with multibyte strings. AFAIK even PHP 5 will
not offer a proper solution for that :-/
Ask the PHP people to program a ODBC Unicode binding for PHP. You will
also need functions that explicitly or implicitly convert everthing to
UCS2 to pass it to the ODBC Unicode API.
*g* yes, i'll ask them. however... but that will take a while to and i'm
in a rush now :)
So far...
Hannes
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general
