Now a days, UTF-8 is the most used data encoding format, and the fact that your database is not using UTF8 encoding is really annoying, specially additionally when it comes to integrating different systems, that has no one unified encoding format.
So if you think it’s time to change your data encoding to utf8 format, then here what this post is all about.
I’ll list here the steps to do so, i just have to clarify that the main data encoding here is windows-1256 (which is the main Arabic encoding used in web applications), but it’s saved in latin1 encoding in the database (mydata ->windows-1256 -> latin1) ,also note that i’m using Mysql database.
Here are the steps:

1. Export (only) the schema of the db,without “set Names” phrase in the outputted sql file, this will bring you back the data in the original encoding (windows-1256)

   mysqldump --default-character-set=latin1 --skip-set-charset -d -uusername -ppassword db_name > db_name_schema.sql

2. Export the data of the db without “set Names” phrase in the outputted sql file, this will bring you back the data in the original encoding (windows-1256):

   mysqldump --default-character-set=latin1 --skip-set-charset -t -uusername -ppassword  db_name > db_name_data.sql

3. Change the encoding of both files from arabic to utf8 -check the notes if you r using windows

   iconv -f windows-1256 -t utf8 db_name_schema.sql > db_name_schema_utf8.sql
   iconv -f windows-1256 -t utf8 db_name_data.sql > db_name_data_utf8.sql

4. Open the file ‘db_name_schema.sql’ with any editor and replace each “DEFAULT CHARSET=latin1″ phrase with “DEFAULT CHARSET=utf8″ one
5. Make a new db ,encoded in utf8:

    mysql -uusername -ppassword -e 'CREATE DATABASE new_db DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci'

6. Import the schema and data in utf8 encoding:

   mysql --default-character-set=utf8 -uusername -ppassword new_db < db_name_schema_utf8.sql
   mysql --default-character-set=utf8  -uusername -ppassword new_db < db_name_data_utf8.sql

notes

• If you are wondering why to separate schema from data upon exporting , then the answer is that the operation of replacing “DEFAULT CHARSET=latin1″ phrase with “DEFAULT CHARSET=utf8″ one , is taking place only on schema files, so it’s recommended to separate them so that you dont stuck when loading the big data files.
• If you are a windows user and can’t use iconv , then u can use any editor to do the job for u, try scite or note++ or even dreamweaver

enjoy!!!

A little problem that i faced with grails , was setting the locale dynamically, i followed this nice article , and here is how i could manage it :

1. I made a new file called messages_ar.properties that contains the arabic localization under the i18n folder.
2. I made a simple beforeinterceptor:

   def beforeInterceptor = {
           def key = "org.springframework.web.servlet.DispatcherServlet.LOCALE_RESOLVER"
           def localeResolver = request.getAttribute(key)
           localeResolver.setLocale(request, response, new Locale("ar","JO"))
       }

Of course you can use grails/Filters to save yourself repeating the same code in every controller.

However what i want to mention is the locale object, which in case of Arabic localization, was seeking the country argument ( “JO” in our case) :

new Locale("ar","JO")

While for other localizations like German one it doesn’t seek this second argument, so this snippet of code will work for them

new Locale("de")

Also you can change this country argument value to match this rule :

The country argument is a valid ISO Country Code. These codes are the upper-case, two-letter codes as defined by ISO-3166. You can find a full list of these codes at a number of sites, such as:

http://www.chemie.fu-berlin.de/diverse/doc/ISO_3166.html

I hope that was helpful , enjoy!