MySQL gbk→utf-8 Code Conversion _php Techniques

Objective:
The first time to write a tutorial, in fact, not a tutorial, just want to sum up a conversion of the notes. If there is a mistake in the middle, or the method is not ideal, everyone replies to the study.
In addition, I also hope that our forum is not only as a place to chat, but also hope that we can be active in our forum learning atmosphere, after all, we are from a should give us knowledge of the place, no matter how much you have to get the knowledge you need.

Okay, here we are.

One preparation:
Environment: mysql4.1.x and above version.
convertz--Text Encoding Conversion tool, Molyx introduced on, I adopted. In fact, there are many such tools.

Two theories:
MySQL starts with version 4.1 the internal storage character set supports UTF-8, which I have only seen these days. Because the upgrade forum process, the server database environment for 4.0.26 did not know at that time did not support the Utf-8 character set, but also wasted some twists and pains. This will also upgrade the MySQL version to over 4.1 if it involves a UTF-8 dump.
The general idea of the conversion is--backup (with no delay) → Repair Database →mysqldump export →convertz conversion code → modify conversion file →mysqldump Import recovery

Three practices:
1, Backup. This doesn't have to be too much to say. You can use any kind of regular backup method as long as you're back on your own.
2, repair. Mysqlcheck-r-U user-p if all ok then OK, if not all OK, come again. Not all OK, do not know how to get.
3, export. Because Latin1 is the default store, you need to determine the encoding format of your database beforehand. For example, Lncz.net is originally GBK encoded, but is stored as latin1, so you should specify the encoding as latin1 when exporting 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 am the one who guides each table alone. The idea was simple, because the database had bad tables and just wanted to know which table was wrong and fix it alone when it came back.
4, conversion. Convertz Use this software is very simple, needless to say more.
5, modify. I tried to import the recovery database directly, failed n times, each time garbled. After careful thought before understand, if you directly guide back, the database or use the default Latin1 to store, and your current encoding is utf-8 so it will be another conversion then error. Here MySQL in the end how to deal with I am not very clear, who knows the trouble to tell. Then we need to add the statement "set names UTF8" to the converted file. Note that it is not utf-8 and need to "charset=latin1" in the file. Replaced by "CHARSET=UTF8;" To specify the storage encoding for the table.
6, recovery. The recovery process should be very simple in principle, it is mysqldump processing. Need to note that if your database is large, to do the changes in global variables max_allowed_packet default to 1M, see your database table size, modify the My.ini file accordingly.
Import command: mysqldump database_name < path-u user-p Import smoothly your database code has been converted to utf-8.


In the next comparison dish, if there is a mistake please correct me, the table laughs at me. The above is for reference only.