Bug #14380 No german characters in skript tab
Submitted: 27 Oct 2005 9:27 Modified: 27 Oct 2005 11:23
Reporter: Michael Sporleder Email Updates:
Status: Not a Bug Impact on me:
None 
Category:MySQL Query Browser Severity:S1 (Critical)
Version:1.1.17 OS:Microsoft Windows (WinXP)
Assigned to: Mike Lischke CPU Architecture:Any

[27 Oct 2005 9:27] Michael Sporleder
Description:
My skript contains a creation of a table with an enumeration type:

CREATE TABLE tbl_mysqlbug (
  .
  .
  enGeschlecht enum('männlich','weiblich') default NULL,
  .
  .
) TYPE=InnoDB;

If you load this skript in the skript tab the german character 'ä' vanishes:

CREATE TABLE tbl_mysqlbug (
  .
  .
  enGeschlecht enum('mnnlich','weiblich') default NULL,
  .
  .
) TYPE=InnoDB;

The behavior is highly critical !

How to repeat:
See above
[27 Oct 2005 9:50] Mike Lischke
How did you store the script file? What encoding did you use (ANSI, UTF-8, UTF-16)? What did you select when you reopend the script (ANSI, UTF-8, UTF-16)?
[27 Oct 2005 10:04] Michael Sporleder
Its stored ANSI. The problem is, that the default file-type for reopen is UTF-8 and no checks are done, if the file is coded in that way.
[27 Oct 2005 11:23] Mike Lischke
There is no way to automatically determine whether a file contains data encoded in UTF-8 or ANSI. You also cannot say if an ANSI files was written with german or russian characters. This is something the user must take care of. MySQL Query Browser does its best to help the user but if you tell it you load UTF-8 data then it assumes you'll know what you are doing. I guess it is just a matter of getting used to also specify the proper encoding when opening a script. Unicode support was not available in older GUI tools.
[27 Oct 2005 11:25] Mike Lischke
Btw. the default encoding for saving is also UTF-8, so this should always work fine together. Only if you have gotten the script from other sources there can be problems. Generally, I strongly recommend to use Unicode instead of ANSI. It is much more flexible and does no leave uncertainty as ANSI does. It costs more memory, but this is a small price to pay for the gain.
[27 Oct 2005 11:43] Michael Sporleder
I know the problem of different charset very well. For example the MS SQL-Server Enterprise Manager uses two different ways: ANSI and OEM. If a scripts was written within the Enterprise Manager an stored on disc german characters cannot be display correct, if you use notepad. The opposite way is the same: SQLEW cannot display ANSI files if its set to OEM.

But one point is not acceptable: Vanishing of characters. If you open a ANSI file with the UTF-8 option and there is no corresponding character in UTF-8 it should be used a special chararcter (pipe of example - like notepad). Then the user is able to see that he's doing something wrong.