Objective:
The first time to write a tutorial, in fact, not a tutorial, just want to summarize a conversion notes. If there is an error in the middle, or the method is not ideal, we huitie study.
In addition, I also hope that our forum not only as a place for small talk, but also hope that we can be active in the study atmosphere of our forum, after all, we all come from a place that should give us knowledge, no matter how much you get the knowledge you need.
Okay, here we are.
A preparation:
Environment: mysql4.1.x and above version.
convertz--Text encoding conversion tool, described on Molyx, I used. In fact, there are many such tools.
Two theories:
MySQL started with the 4.1 version of the internal storage character set support UTF-8, which I also saw these days. As the upgrade forum process, the server database environment for 4.0.26 at that time did not know that does not support the Utf-8 character set, but also wasted some trouble. This will also upgrade the MySQL version to more than 4.1 if the UTF-8 dump is involved.
The general idea of conversion is--backup (with no delay) → Repair Database →mysqldump export →convertz conversion code → Modify the converted file →mysqldump import recovery
Three practices:
1, Backup. This doesn't have to be too much to say. You can use any of the usual backup methods as long as you recover yourself.
2, repair. Mysqlcheck-r-U user-p if all ok then OK, if not all OK, come again. Not yet all OK, do not know how to get it.
3, export. Since latin1 is the default storage, you need to determine the encoding format of your database beforehand. For example, Lncz.net is originally encoded as GBK, but is stored as latin1, so the export should be encoded as latin1 and exported to correctly display GBK text in ANSI form.
Export command: mysqldump database_name field > Path--default-character-set=latin1-u user-p
The database needs to be segmented, or the next operation will be cumbersome. I took each of the tables separately. The idea was simple because the database had bad tables and wanted to know which table was going to be repaired when it was restored.
4, conversion. Convertz with this software is very simple, need not say more.
5. Modification. I tried to import the recovery database directly, failed n times, each time garbled. After careful thought to understand, if you direct back, the database is still using the default Latin1 to store, and your current code is UTF-8 so it will be a conversion of the error. I'm not quite sure what MySQL is dealing with here, who knows the trouble. Then we need to add the statement "set names UTF8" to the converted file. Note that it is not utf-8 and needs to be "charset=latin1;" in the file. Change to "CHARSET=UTF8;" To specify the storage encoding for the table.
6, recovery. The recovery process is supposed to be simple and mysqldump. One thing to note is that if your database is large, make changes to the global variables Max_allowed_packet default to 1M, look at the size of your database table, modify the My.ini file accordingly.
Import command: mysqldump database_name < path-u user-p Import successfully, your database encoding has been converted to utf-8.
In the next comparison dish, if there is an error please correct me, the table laughs at me. The above is for reference only.
http://www.bkjia.com/PHPjc/318321.html www.bkjia.com true http://www.bkjia.com/PHPjc/318321.html techarticle Preface: The first time to write a tutorial, in fact, not a tutorial, just want to summarize a conversion notes. If there is an error in the middle, or the method is not ideal, we huitie study. In addition, I also hope ...
