Unicode content in Cookies

This is another small small things but can get to the nerves ;)

So basically, I was doing some changes with a Taiwan web application, previously it was using Session to store some information and right now because of we're integrating with other application, we need to use the cookie instead so the information can be shared.
Note: When using cookies, if the information is confidential, you may need to consider encryption.

After i modified the application and tested it in one of the server, everything is working perfectly, until I tried it in the other server, just to make sure that this is working fine as well. And the unexpected actually happened, the unicode characters were corrupted, they are becoming question marks (????).
Firstly I thought that the server probably missing some language pack, and then I installed the language pack to the server and turned out, it was not helping either. Then I tried this application into another server again (it is fun to have a lot of servers to play and test with hohohoho), and some of them were able to save the unicode correctly and some of them didn't, including my own PC :(

I was kept thinking, what is the difference between these machines, why some of them are working and some of them aren't. I looked into the cookie file in the my local machine, the cookies which were saved correctly are having UTF-8 as the encoding and the cookies which are corrupted were having ANSI as the encoding.

So in the end, actually instead of thinking why UTF-8 and ANSI, there is a simple solution.
Use HttpUtility.UrlEncode when saving cookie, and use HttpUtility.UrlDecode when reading back from the cookie.
Using this way, we don't need to worry whether the characters will be corrupted because of some machine settings :)

Sounds easy rite? hhhmm... it took me almost 2 days browsing and browsing and then have this solution come to my mind. Getting older I guess hahaha ;)

ASP.Net - Export to Excel - Unicode characters are not being displayed correctly

I found this problem when exporting datagrid to excel using .Net Response object.
Quite strange actually, we have no problem in our local (WinXP), but when we deploy to the Server (Win2K), the excel result is not displaying the unicode characters correctly.
It can work after we tried to open the excel result using notepad and then saved it with unicode encoding, notice that previously when we first open the document in excel, the font is Arial, but after saving the file with the encoding, it is using Arial Unicode MS.
After several hours, testing this and that, in the end i found an article for exporting datagrid to excel in CodeProject.
And the reply post in the link just resolved my problem.

Illustration :
When exporting the datagrid to excel, actually all of the things are still in html elements (can try to open the excel file using notepad / text editor). So the content will be <table><tr>.....</tr></table>.

I thought that this encoding problem can be resolved by trying to modify the charset and contentencoding in the response object. But i was wrong :(
From the reply post above, you can see that actually it is very simple thing, just add a head element with

<meta http-equiv=Content-Type content="text/html; charset=utf-8">

before rendering the datagrid.
This way, the output can be intepreted correctly, and the unicode can be displayed correctly.

Korean (Unicode) ASP Application Migration

These are the things that my Team discovered when we did the migration for Korean Application from Korean Server Based System to English Server:
1. Database objects
If the tables are already using nvarchar / nchar as the field type, there should not be a problem.
But if the fields which contain korean characters are using varchar / char with korean collation, we will need to modify the field type into nvarchar / nchar.
And after changing the field type, all insert / update to these fields will have to have 'N' before the string, for example : N'This is the string'
The modification can be :
- in the code
- in the stored procedures (parameters)
2. Language Packs
The server may need to be installed with the korean language packs
3. Sending Email
The application has a tool to send out emails. There's a feature to encode the from name, subject, and body using certain charset, euc-kr is a standard charset that we are using for Korean Application.
4. ASP Application
To display the information correctly in the korean characters, we may need to set the <%@ CODEPAGE=949 %> in the top of the page.
Previously we're using the Session.CodePage=949 but still don't know why it's not working after we move the application to our server, but we tried using Session.CodePage=CP949 and it worked.
Because CODEPAGE=949 is documented in the msdn articles and Session.CodePage=CP949 is not, we decided to just use the CODEPAGE.