With the backup 'powertool' it is possible to deselect the UTF8-encoding, but it seems to have no effect!
The 'SQL_mode statements' are omitted but the data are still encoded I think!
We start with those data here:
We can export with the UTF8 option and it imports Ok
Full Version: Deselect Utf8:
Now we export WITHOUT the UTF8 -option
File reads like:
Executing this from the editor is OK. Importing from a file with the UTF8 options is also OK (as written in previous post).
However importing the file without the UTF8 -option garbles data.
If the file has NO 'SET NAMES' statement it becomes garbage
Also if file contains 'SET NAMES latin1' it becomes garbage
(all defaults are 'latin1' so this is nothing new!)
but if file contains 'SET NAMES utf8' it imports OK.
now 'ÆØÅæøå' is a valid latin1 string ???
and from the editor I can 'SET NAMES' anything where 'ÆØÅæøå' is a valid string (latin1, utf2, ucs2) and it saves OK!
On this system:
File reads like:
CODE
insert into `nn` (`id`,`english_letters`,`danish_letters`) values (0,'ABCabc','ÆØÅæøå');
Executing this from the editor is OK. Importing from a file with the UTF8 options is also OK (as written in previous post).
However importing the file without the UTF8 -option garbles data.
If the file has NO 'SET NAMES' statement it becomes garbage
Also if file contains 'SET NAMES latin1' it becomes garbage
(all defaults are 'latin1' so this is nothing new!)
but if file contains 'SET NAMES utf8' it imports OK.
now 'ÆØÅæøå' is a valid latin1 string ???
and from the editor I can 'SET NAMES' anything where 'ÆØÅæøå' is a valid string (latin1, utf2, ucs2) and it saves OK!
On this system:
CODE
show variables like '%character%';
/*returns
Variable_name Value
------------------------ ----------------------------------------------------
character_set_client latin1
character_set_connection latin1
character_set_database latin1
character_set_results latin1
character_set_server latin1
character_set_system utf8
character_sets_dir C:\Programmer\MySQL\MySQL Server 4.1\share\charsets/
*/
/*returns
Variable_name Value
------------------------ ----------------------------------------------------
character_set_client latin1
character_set_connection latin1
character_set_database latin1
character_set_results latin1
character_set_server latin1
character_set_system utf8
character_sets_dir C:\Programmer\MySQL\MySQL Server 4.1\share\charsets/
*/
Now it is working OK on MySQL 4.0.
Also a dump created with SQLyog 4.1 reading like
.. imports OK with 5.18 and 5.2 beta.
Is it really so simple and silly that it we uncheck the UTF8-option then the SET NAMES statement is not added to the file but the data are still encoded?
I am now totally confused!
Fresh eyes on this please!
Also a dump created with SQLyog 4.1 reading like
CODE
/*
SQLyog Enterprise - MySQL GUI v4.1
Host - 4.0.27-nt-max : Database - test
*********************************************************************
Server version : 4.0.27-nt-max
*/
create database if not exists `test`;
USE `test`;
/*Table structure for table `nn` */
drop table if exists `nn`;
CREATE TABLE `nn` (
`id` bigint(20) NOT NULL default '0',
`english_letters` varchar(50) default NULL,
`danish_letters` varchar(50) default NULL
) TYPE=MyISAM;
/*Data for the table `nn` */
insert into `nn` values (0,'ABCabc','ÆØÅæøå');
SQLyog Enterprise - MySQL GUI v4.1
Host - 4.0.27-nt-max : Database - test
*********************************************************************
Server version : 4.0.27-nt-max
*/
create database if not exists `test`;
USE `test`;
/*Table structure for table `nn` */
drop table if exists `nn`;
CREATE TABLE `nn` (
`id` bigint(20) NOT NULL default '0',
`english_letters` varchar(50) default NULL,
`danish_letters` varchar(50) default NULL
) TYPE=MyISAM;
/*Data for the table `nn` */
insert into `nn` values (0,'ABCabc','ÆØÅæøå');
.. imports OK with 5.18 and 5.2 beta.
Is it really so simple and silly that it we uncheck the UTF8-option then the SET NAMES statement is not added to the file but the data are still encoded?
I am now totally confused!
Fresh eyes on this please!
I do not think this is related to any specific connection type at all!
But when I first started working on it, I thought that it was.
That is the reason for the 'sub-header' reading ".. and HTTP-tunnelling"
But when I first started working on it, I thought that it was.
That is the reason for the 'sub-header' reading ".. and HTTP-tunnelling"
the statement:
as it displays in a HEX-editor with UTF8 box selected and de-selected. Identically. Danish letter are represented by 2 bytes. That is UTF8 encoding in both cases! In Latin1/ANSI those characters are one byte only!
It shall not be if not UTF8 is selected. It shall then simply be a byte-to-byte copy of the stored data!
CODE
insert into `nn` (`id`,`english_letters`,`danish_letters`) values ('0','ABCabc','ÆØÅæøå');
as it displays in a HEX-editor with UTF8 box selected and de-selected. Identically. Danish letter are represented by 2 bytes. That is UTF8 encoding in both cases! In Latin1/ANSI those characters are one byte only!
It shall not be if not UTF8 is selected. It shall then simply be a byte-to-byte copy of the stored data!
And this is from SQLyog 4.1 and here 'ÆØÅæøå' have the correct ANSI numbers corresponding to 'latin1' charset and are ONE byte only each.
All above was MySQL 4.1 and higher.
With 4.0 it is like this. And that is OK. No other encoding than how it is stored.
With 4.0 it is like this. And that is OK. No other encoding than how it is stored.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.