MisLead (4/24/2012) opc.three (4/24/2012) MisLead (4/23/2012)
I have no knowledge on c#. However i have the following code below that converts double byte to unicode. My requirement is reverse engineering i.e convert unicode (non english characters) to double byte ANSI.I have no idea what changes I should make to achieve that.Please help. thanks.
public static class ConvertStringToUnicode
public static string ConvertToUnicode(int codePage, SqlString input)
Encoding srcEncoding = Encoding.GetEncoding(codePage);
byte byteInput = input.GetNonUnicodeBytes();
byte byteOutput =UnicodeEncoding.Convert(srcEncoding, Encoding.Unicode, byteInput);
output = Encoding.Unicode.GetString(byteOutput);
Not enough info...
What you posted is presumably from a standard C# class...not necessarily a SQLCLR object.
What is your goal? To create a SQLCLR function that does the same thing?
What do you mean by "double byte ANSI"? UCS-2, i.e. Windows version of "Unicode"? Or Windows 1252 stored in double-byte format? What is the desired destination code page?
I agree its a C# class but when i have proper codes that does what it needs to do, i want to deploy as a clr function ssms.
As stated in my post, what this code does is converts double byte ANSI characters (ansi characters>127) back to Unicode (chinesse/japanese). My requirement though is to convert those chinese/japanese characters to double byte characters(don't ask me why, its the requirement) because these non english letters cannot be contained within single byte unlike English.
Your understanding of "double byte ANSI characters (ansi characters>127)" may need a tweak. Characters represented on the ASCII map at positions 128-255 still only occupy 1 byte.
Apparently there is a way to map the unicode(when i say unicode its strictly non english) to extended ansi characters. the link below has the list of extended characters from 128-255.http://ascii-table.com/ansi-codes.php
my guess is that you just need to tweak some code up there, but as i said i have NULL in c#.
Only the converse is true...while the characters in ASCII 128-255 may have Unicode representations, by definition ASCII != Unicode and certainly cannot model anything in the realm of Korean or Chinese per its single-byte representation. Futher to that, you still need to apply a codepage before the binary will make sense. Do you know if the dialects you are trying to model are included the Unicode BMP? If so then you can simply store them in SQL Server as NVARCHAR or NCHAR. If you are simply trying to fool SQL Server into storing multi-byte Chinese and Korean characters in a VARCHAR column, and then encoding the contents on the way and and out then you are playing with fire. Collations in a VARCHAR column may eat characters and replace them with '?' (question marks).
I need to know more about your data source, your column storage, and your goals on storage and retrieval before I can help.
__________________________________________________________________________________________________There are no special teachers of virtue, because virtue is taught by the whole community. --Plato