Working with Unicode (UTF-8), non western(ISO-8859-1) languages
CUTE is transparent to working with international (unicode) characters, except in two points, but only related to interface:
- HTML page encoding specification. Set in
cute_preference_addmetaencodingin preferences file
- Text directionality. Set in
cute_preference_languagedirectionin preferences file
preferences.ida. Supported values are ltr and rtl (this last one very useful for example for texts in Hebrew or Arab).
In general, working with international character sets depend only on the underlying mechanisms:
- Scripting language (ASP engine)
- Database and its drivers
Usually, this mechanisms try to align themselves to do the job the best as possible, for example the browsers uses to take into account the HTML page encoding specification to either send to the server a text/html content type with the characters encoded as unicode html entities, if it founds a latin1 page specification, or a utf-8 stream if it founds an utf-8 page specification.
CUTE uses a selection switch based in the HTML page encoding specification, to prevent the Server/ASP engine set that the information we are working with has a windows locale associated to that encoding spec, and make the needed encoding transformations to be able to interpret correctly the byte stream as the needed character set.
The key responsible of everything to go ok is database side: so the responsibility relies on the use of
nvarchar field types in SQL Server for saving unicode streams, or create databases in the appropriate locale for MS Access databases, which I think depends strongly on the underlying operating system locale configuration. I didn't test this last msaccess one. Hope this theory is all ok.
One last thing. Supposing you're using SQL Server with nchar, nvarchar or ntext fields, preceding their quoted string values with
N (uppercase letter n) is a correct way to use a SQL query to insert unicode values:
INSERT INTO my_i18n_table (my_ntext_field, my_nvarchar_field) VALUES (N'♚♛♜',N'♝♞')