MySQL Bugs: #72021: WB displays multiple latin1 bytes as one multiple byte utf8 character

Bug #72021	WB displays multiple latin1 bytes as one multiple byte utf8 character
Submitted:	12 Mar 2014 13:49	Modified:	25 Apr 2014 20:34
Reporter:	Arnaud Adant	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Workbench: SQL Editor	Severity:	S3 (Non-critical)
Version:	6.0.9	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
2 byte latin1 should display 2 characters.

here : C3A5 => Ã¥

but WB displays å

How to repeat:
set names latin1;
select convert(unhex('C3A5') using latin1);

Suggested fix:
Fix the conversion.

Is WB (on Windows at least) guaranteed to work with any other client character set than utf8 (or utf8mb4 to the extend that there is font support)?

I don't think so!

For both this and the other report you just posted, I think you should simply omit "set names latin1;".

I checked the same in our own (SQLyog) program and if I omit SET NAMES or SET NAMES UTF8 it works. SQLyog is only able to use UTF8 as client character set, what it also specifies in mysql_options() for every connection (it may also work with utf8mb4 to the extend that Windows supports and there is font support)

And Workbench is probably the same. Looks like it at last!

(you may refer our issuetracker https://code.google.com/p/sqlyog/issues/detail?id=2027 where I just added an entry with your test cases.  And we have FAQ http://faq.webyog.com/content/8/148/en/do-i-need-to-set-names-to-display-characters-of-my-...).

It is not conversions that fails.  The server does the conversions correctly.  But the client requires data sent to the client as UTF8 (because it can only handle that).  So if you don't "SET NAMES latin1" it will probably work as expected.

Workbench assumes utf8 (or utf8mb4) as the client character set, which is set by WB when it connects. Unless there's a strong business case for supporting client charset changes triggered by the user, we will not add support for that.