Just a nitpick:
The character "\x{263A}" is "\x{E2}\x{98}\x{BA}" in UTF-8.
hp
--
_ | Peter J. Holzer | Auf jedem Computer sollte der Satz Ludwigs II
|_|_) | Sysadmin WSR | eingeprägt stehen: "Ein ewig Rätsel will ich
| | | h...@wsr.ac.at | bleiben, mir und andern."
__/ | http://www.hjp.at/ | -- Wolfram Heinrich in desd
Thanks Noel.
I will look at this as soon as I can and get back to you.
The ODBC unicode support in DBD::ODBC requires a driver to support the
so called "Wide" functions - SQLxxxW and has little to do with
supporting SQL_C_WCHAR. Columns may be bound as SQL_C_WCHAR even in non
unicode builds of DBD::ODBC in which case they are returned as is from
the driver.
I am not aware of there being any existing way of handling ODBC drivers
that return UTF-8 encoded data and to this day I still cannot understand
how drivers can do this within ODBC and still support APIs like
SQLGetData see http://www.martin-evans.me.uk/node/20#unicode and
http://www.easysoft.com/products/data_access/odbc_oracle_driver/unicode.html#odbc.
However, if your driver returns UTF-8 encoded data consistently and you
are happy this patch works I'll try and incorporate it.
BTW, I only just noticed your CC list - I guess this is related to:
"Enquisite selects Aster Data to Scale its Worldwide Search Data Network
November 2, 2009"
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com