MySQL Bugs: #14380: No german characters in skript tab

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:	Windows (WinXP)
Assigned to:	Mike Lischke	CPU Architecture:	Any

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

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)?

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.

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.

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.

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.