Re: latin1/utf-8 problem
Hello. Looks like you've solved the problem? Remove quotes from show create... statements: show create table table_name; Steve Mansfield [EMAIL PROTECTED] wrote: --- On Saturday 27 November 2004 12:38, Steve Mansfield wrote: Seem to be answering my own questions here...:-) Looks like it's a MySQLcc problem. Dumped tables from the live server and then, rather than running them as a sql query via MySQLcc, I did it from the command line with: mysql -h host -D database -p filename.sql And that worked. The data stayed as latin1. For some reason, MySQLcc is messing with the data and turning it into utf-8. Go figure... -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.NET http://www.ensita.net/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Gleb Paharenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET ___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: latin1/utf-8 problem
Hello. Strange behavior. You said that both servers configured to use latin1? What output produced show variables like '%char%'; show variables like '%colla%'; show create database 'database_name'; show create table 'table_name'; on both servers? Also send your my.cnf files. Steve Mansfield [EMAIL PROTECTED] wrote: --- On Saturday 27 November 2004 12:16, Steve Mansfield wrote: | --- | | On Friday 26 November 2004 17:58, Gleb Paharenko wrote: | | Hello. | | | | What charset produced mysqldump with --default-character-set=latin1 | | command line option? | | Hmm, that still produced a file with utf-8 characters, which means they | must be stored that way in the table, no? (Although MySQLcc sees them | correctly). | | (BTW, I've configured Kwrite, the editor I'm using, to open/save as | iso-8859-1). Just to provide a bit more info - and to double-check - I exported the table from the live system (via phpMyAdmin) and looked at it on my local system and it was in latin1. I dropped the table from the live system, then uploaded the copy of the table that I'd dumped from my local system using the --default-character-set=latin1 option. On the live system, this now has utf-8 characters (so it's nothing to do with my editor...). -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.NET http://www.ensita.net/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Gleb Paharenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET ___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: latin1/utf-8 problem
--- On Saturday 27 November 2004 12:52, Gleb Paharenko wrote: | Hello. | | Strange behavior. You said that both servers configured to use latin1? | What output produced Can only do with for the local server, access is denied to the mysql shell on the shared hosting. But it's the local system that's causing the unexpected effects: | show variables like '%char%'; character_set latin1 character_sets latin1 big5 [...bunch of others including latin5 - no utf-8 to be seen anywhere...] convert_character_set | show variables like '%colla%'; empty set | show create database 'database_name'; ERROR 1064: [sql syntax error] | show create table 'table_name'; ERROR 1064: [sql syntax error] | on both servers? Also send your my.cnf files. [client] port= 3306 socket = /var/lib/mysql/mysql.sock default-character-set = latin1 [mysqld] port= 3306 socket = /var/lib/mysql/mysql.sock datadir = /share/mysql/data skip-locking set-variable= key_buffer=16M set-variable= max_allowed_packet=1M set-variable= table_cache=64 set-variable= sort_buffer=512K set-variable= net_buffer_length=8K set-variable= myisam_sort_buffer_size=8M log-bin server-id = 1 [safe_mysqld] err-log=/var/lib/mysql/mysqld.log [mysqldump] quick set-variable= max_allowed_packet=16M [mysql] no-auto-rehash [isamchk] set-variable= key_buffer=20M set-variable= sort_buffer=20M set-variable= read_buffer=2M set-variable= write_buffer=2M [myisamchk] set-variable= key_buffer=20M set-variable= sort_buffer=20M set-variable= read_buffer=2M set-variable= write_buffer=2M [mysqlhotcopy] interactive-timeout -- @+ Steve -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: latin1/utf-8 problem
Hello. What charset produced mysqldump with --default-character-set=latin1 command line option? Steve Mansfield [EMAIL PROTECTED] wrote: I have a strange, irritating problem that I think is to do with MySQL. I have a table on a live (shared hosting) system that, when I use it on my local system, seems to wind up in utf-8 rather than latin1. Here's the set-up: Live system - MySQL 3.2.3.56, PHP 4.1.2, Apache 1.3.27. MySQL is configured to use latin1, PHP to no default charset. Local system - MySQL 4.0.18-32, PHP 4.3.4, Apache2 (all from SuSE 9.1 distro). MySQL is configured to use latin1, PHP to no default charset. I have a table containing text with French accented characters. On the live system, these display correctly when viewed with a browser set to iso-8859-1 encoding (which is what the page specifies). On the local system, the page has to be viewed as utf-8. Huh? This is the same data. I dumped the table from the live system (via phpMyAdmin - also set to use latin1) to my local disk. I viewed that with Kwrite which showed me that the text was, indeed, latin1 in that file. I uploaded the table to the local system. In MySQLcc (set to latin1) the text reads correctly. Running myisamchk on the table tells me it's latin1. And yet, if I mysqldump the table, the resulting file appears to be utf-8! And data pulled from the table by PHP also appears to be utf-8. Help! @+ Steve -- For technical support contracts, goto https://order.mysql.com/?ref=ensita This email is sponsored by Ensita.NET http://www.ensita.net/ __ ___ ___ __ / |/ /_ __/ __/ __ \/ /Gleb Paharenko / /|_/ / // /\ \/ /_/ / /__ [EMAIL PROTECTED] /_/ /_/\_, /___/\___\_\___/ MySQL AB / Ensita.NET ___/ www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: latin1/utf-8 problem
--- On Friday 26 November 2004 17:58, Gleb Paharenko wrote: | Hello. | | What charset produced mysqldump with --default-character-set=latin1 command | line option? Hmm, that still produced a file with utf-8 characters, which means they must be stored that way in the table, no? (Although MySQLcc sees them correctly). (BTW, I've configured Kwrite, the editor I'm using, to open/save as iso-8859-1). @+ Steve -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: latin1/utf-8 problem
--- On Saturday 27 November 2004 12:16, Steve Mansfield wrote: | --- | | On Friday 26 November 2004 17:58, Gleb Paharenko wrote: | | Hello. | | | | What charset produced mysqldump with --default-character-set=latin1 | | command line option? | | Hmm, that still produced a file with utf-8 characters, which means they | must be stored that way in the table, no? (Although MySQLcc sees them | correctly). | | (BTW, I've configured Kwrite, the editor I'm using, to open/save as | iso-8859-1). Just to provide a bit more info - and to double-check - I exported the table from the live system (via phpMyAdmin) and looked at it on my local system and it was in latin1. I dropped the table from the live system, then uploaded the copy of the table that I'd dumped from my local system using the --default-character-set=latin1 option. On the live system, this now has utf-8 characters (so it's nothing to do with my editor...). -- @+ Steve -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: latin1/utf-8 problem
--- On Saturday 27 November 2004 12:38, Steve Mansfield wrote: Seem to be answering my own questions here...:-) Looks like it's a MySQLcc problem. Dumped tables from the live server and then, rather than running them as a sql query via MySQLcc, I did it from the command line with: mysql -h host -D database -p filename.sql And that worked. The data stayed as latin1. For some reason, MySQLcc is messing with the data and turning it into utf-8. Go figure... -- @+ Steve -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
latin1/utf-8 problem
I have a strange, irritating problem that I think is to do with MySQL. I have a table on a live (shared hosting) system that, when I use it on my local system, seems to wind up in utf-8 rather than latin1. Here's the set-up: Live system - MySQL 3.2.3.56, PHP 4.1.2, Apache 1.3.27. MySQL is configured to use latin1, PHP to no default charset. Local system - MySQL 4.0.18-32, PHP 4.3.4, Apache2 (all from SuSE 9.1 distro). MySQL is configured to use latin1, PHP to no default charset. I have a table containing text with French accented characters. On the live system, these display correctly when viewed with a browser set to iso-8859-1 encoding (which is what the page specifies). On the local system, the page has to be viewed as utf-8. Huh? This is the same data. I dumped the table from the live system (via phpMyAdmin - also set to use latin1) to my local disk. I viewed that with Kwrite which showed me that the text was, indeed, latin1 in that file. I uploaded the table to the local system. In MySQLcc (set to latin1) the text reads correctly. Running myisamchk on the table tells me it's latin1. And yet, if I mysqldump the table, the resulting file appears to be utf-8! And data pulled from the table by PHP also appears to be utf-8. Help! @+ Steve -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]