Hi all, We use the following (example) code : begin declare DeliveredChars varchar(120); declare ConvertedChars nvarchar(120); set DeliveredChars = 'ä / é / â / ü / ö / Ã-'; // problematic UTF-8 chars // this row started converting the problematic chars from client charset UTF-8 to db charset - // but now it doesn't work anymore... set ConvertedChars = DeliveredChars; // translation from UTF-8 to db charset !? // SQL Anywhere v12.0.1.3942 // CHAR Collation sequence is ISO_BINENG / ISO_8859-1:1987 // NCHAR Collation sequence is UCA / UTF-8 select ConvertedChars, DeliveredChars from dummy; // NO TRANSLATION // ConvertedChars | DeliveredChars // returns ä / é / â / ü / ö / Ã- | ä / é / â / ü / ö / Ã- end Do you have any solutions for this problem? Kind regards Frank |
SQL strings are always first interpreted in the database's character set before being executed. See: SQL statements and character sets
I believe in your test as posted, you really are testing the individual characters
Does CSCONVERT do what you need here? SELECT CAST(CSCONVERT('ä / é / â / ü / ö / Ã-', 'ISO_8859-1','UTF-8') AS VARCHAR) as result; result 'ä / é / â / ü / ö / í' Hello Jeff and Volker, Example: -- -- create a Textfile with the problematic chars - for example ä / é / â -- select cast( csconvert(xp_read_file('c:\\Temp\\test.txt'),'db_charset','utf8') as long varchar) from dummy; -- it doesn't work !!! select cast( csconvert('ä / é / â','db_charset','utf8') as long varchar) from dummy; -- this works fine !!! Kind regards Frank
(06 Mar '14, 09:05)
Frank_V
Replies hidden
2
When you created the text file using your editor, what character set did the editor save the text as? When you use xp_read_file to read file contents the data within the file is not converted to db charset - it will remain in whatever format/charset that the file contained. Therefore the csconvert() 'from'-charset needs to be the charset that the editor used when it saved the file.
(06 Mar '14, 09:35)
Mark Culp
1
Just to add: That's documented for xp_read_file() well enough in the docs, IMHO:
(07 Mar '14, 03:39)
Volker Barth
|
Hello again, has nobody a solution to convert special UTF-8 characters to db charset (in this case to german umlaut characters like ü, ä, ö ...)?
I guess it would be easier to help here if the chars would be assigned via their codepoints and not their graphical representation... - that might make it easier to reproduce the problem.
That's just my 2 cents, I'm no UTF-8 expert (although I surely have to cope with german umlauts everyday...)
I agree even more strongly with Volker: The graphical representation of special characters as (a) captured by unspecified client software for display and then (b) delivered for our viewing pleasure via a long trail of forum, interweb and browser products, makes wild guesswork on our part necessary.
Please tell us, in actual hexadecimal byte values, exactly what the input characters are, what the (incorrect) output characters are, and what the correct output characters should be. We're geeks, we don't care about umlauts, we care about bits :)
And what is the character set of the client application's connection? How was this SQL sent to the database server? dbisql?