[freetds] UTF-8 support: What about N'xxx' string literals?
sf at 4js.com
Wed Aug 13 09:13:40 EDT 2008
Concerning UTF-8 / UNICODE support, I was wondering about the usage of N'xxx'
string literals in SQL statements (in ODBC or tsql commands)...
Actually if you want to specify a "UNICODE" (i.e. UCS-2) string in SQL Server,
you must prefix the string with a N :
create table tab1 ( k int, c nchar(10), nvarchar(10) )
insert into tab1 values (1, 'abc王鴻', 'abc王鴻傑王鴻傑' )
insert into tab1 values (2, N'abc王鴻', N'abc王鴻傑王鴻傑' )
select * from tab1
Otherwise, non-prefixed strings are converted by SQL Server to the default
code page of the database... (following docs).
Actually SQL Server docs talk about "Server side" programming, where strings
should use N prefix for UNICODE (UCS-2), but what about the clients then?
>From my understanding, if I want to use UTF-8 encoded strings in my SQL stmts,
(defining my FreeTDS client charset as UTF-8 and forcing FreeTDS to convert from
UTF-8 to UCS-2 for TDS exchanges), I need always to specify N prefix to avoid
the server-side conversion to the database charset defined by the collation.
Since FreeTDS converts from any client charset to/from UCS-2 for TDS exchanges,
the final string literal will be encoded in UCS-2 and so the client is seen as
a UCS-2 client from the server... right?
So should not ALL FreeTDS application use the N prefix for string literals,
even if the encoding is for example ISO-8859-1?
Maybe some words about this could be added to:
More information about the FreeTDS