Bienvenido al sitio de software libre de CUTE, editor de bases de datos para MS Access y SQL Server. Este proyecto necesita reanimación desde Marzo de 2013.


Se puede realizar mediante donaciones, patrocinio o ayuda en la instalación.

donate sponsor aided installation

O puedes ayudar escribiendo nuevas traducciones, un artículo en la wikipedia acerca del programa, comentarios en foros o blogs, añadir código o documentación, etc... En cualquier caso gracias.

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_addmetaencoding in preferences file preferences.ida
  • Text directionality. Set in cute_preference_languagedirection in 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:

  • Browser
  • Server
  • 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 ntext, nchar or 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'♝♞')


Add your comment:

(Too weird, even outrageous perhaps?: try a regeneration)
Top of the page