Unicode and Journyx Timesheet 6.x - Journyx, Inc.

Support
Unicode and Timesheet 6.x

 

Journyx Timesheet does not currently support Unicode as a native database character set as of version 6.0. Full native Unicode database support is expected in a future release but no date has been set.

Even though Timesheet does not support storing native Unicode in the database, your users can still work with Unicode text in a limited way subject to these restrictions:

  1. Unicode is not officially supported by Journyx Timesheet 6.0. If you encounter a problem using Unicode there is no guarantee it will be addressed or fixed. For instance, Unicode is known to display improperly in certain areas of the product.
  2. You must not set Unicode as the main database character set. You must choose a different 8-bit character set such as Windows-1252 or Latin-1. See this page for more details on choosing a character set.
  3. If your users' browsers send raw Unicode data to the server, it will not be handled correctly. Browsers must send Unicode data in the special "HTML entity" format. Modern versions of most browsers such as Microsoft Internet Explorer, Netscape, Mozilla, Firefox, and Safari all handle this automatically.
  4. Unicode is stored in the database in the "HTML entity" format, not as native Unicode. For instance, the Unicode code point 2030 (the per-mille sign ‰) will be stored as the literal text ‰

    That requires 8 bytes of storage per character instead of 2 bytes.

  5. The HTML entity format for Unicode requires more space in the database. This reduces the amount of space available in a text field, usually by a factor of 8. For instance, the User Full Name field normally allows 60 letters. If you try to create a User Full Name using only Unicode characters that are not found in the native characterset, you will find it can only hold 7 characters.

    For the purposes of this document, "using Unicode" means "using Unicode characters that aren't found in the native database character set." Any Unicode characters which are found in the native database character set, such as all regular English letters and numbers, will be stored in the native form and not take up any extra space. The HTML entity form is only used for those characters that can't be translated to the native character set, such as when trying to input Chinese text into a Latin-1 (Western European) database.