新浦京81707con > 首页 > 8编码转换,总结下MYSQL编码转换的问题latin1转u

原标题:8编码转换,总结下MYSQL编码转换的问题latin1转u

浏览次数:98 时间:2019-08-28

前言:
率先次写教程,其实算不得教程,只是想计算个转移的手写。假诺中间有错误,恐怕措施非常不足理想,咱们回贴研讨下。
另外,笔者也指望大家论坛不独有作为闲谈的地方,也期待我们能活跃我们论坛的学习气氛,毕竟大家都来源于二个应该给大家知识的地方,不论你从那边取得了有一些你供给的学识。

黑面

第二个点子:
MySQL 4.1 汉语乱码的主题素材
这段日子要将 MySQL 4.0 晋级到 MySQL 4.1 ,开采了汉语乱码的标题,希望以下意见对大家有用。

好了,言归正传。

明天蒙受个PHP网址,数据库是MYSQL5.1的,进了网址的phpmyadmin管理后意识表内汉语全体展示乱码,导出后本地导入同样是乱码,不能够查看所急需的音信,乱码一般景色并非说都领会大多是编码的题材,查看了下指标库的编码为latin1,测度网址前后相继是GBK的。。。直接备份下载,下载到本地供给转移下编码,缺憾此前没搞过,网络检索了一堆资料测量检验。。。具体有这二种自己给急需的相爱的人总计下,就无须处处寻找了

  1. MySQL 4.1 在文字上有非常大改进,它有了 Character Set 与 Collation 的慨念。
  2. 在 MySQL 4.0 ,一般的程式都会将文字以拉丁文 ( latin) 来积存,即使大家输入汉语字,结果仍是身处以拉丁文设置的文字栏里头,那对 MySQL 4.0 与以 MySQL 4.0 为基楚的程式来讲,并不会不平时。
  3. 只是 MySQL 4.1 的系统编码是预设用 UTF-8 的,当要 restore MySQL 4.0 的 backup 档到 MySQL 4.1 时,乱码就出现了。原因在于 MySQL 4.1 将 latin 码转变过来,而后调换是并不完全完美的,那变成了出现一些些文字出现乱码现象。
    涸泽而渔PHP存取MySQL 4.1乱码难题
    QUOTE:
    从MySQL 4.1开始引进的多语言协助确实很棒,何况部分特征已经超先生越了别的的数据库系统。但是本人在测量试验进度中发觉选取适用于MySQL 4.1以前的PHP语句操作MySQL数据库会招致乱码,就算是设置过了表字符集也是如此。小编读了一下新的MySQL在线手册中第十章 "Character Set Support"后究竟找到了化解措施并测验通过。
    MySQL 4.1的字符集帮忙(Character Set Support)有七个地方:字符集(Character set)和排序格局(Collation)。对于字符集的协理细化到五个档期的顺序: 服务器(server),数据库(database),数据表(table)和再而三(connection)。
    查看系统的字符集和排序格局的设定能够由此上面包车型的士两条命令:
    CODE:
    mysql> SHOW VARIABLES LIKE 'character_set_%';
    -------------------------- ----------------------------
    | 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 | /usr/share/mysql/charsets/ |
    -------------------------- ----------------------------
    7 rows in set (0.00 sec)
    mysql> SHOW VARIABLES LIKE 'collation_%';
    ---------------------- -------------------
    | Variable_name | Value |
    ---------------------- -------------------
    | collation_connection | latin1_swedish_ci |
    | collation_database | latin1_swedish_ci |
    | collation_server | latin1_swedish_ci |
    ---------------------- -------------------
    3 rows in set (0.00 sec)
    地点列出的值正是系统的暗中认可值。假令你意外系统怎么私下认可是latin1的日语排序方式,原因是MySQL由瑞典王国的T.c.X.DataKonsultAB公司(最近公司名叫MySQL AB)开采,不用再多说了呢。
    当我们根据原先的不二秘诀通过PHP存取MySQL数据库时,尽管设置了表的暗中同意字符集为utf8而且通过UTF-8编码发送查询,你会发觉存入数据库的依然是乱码。难题就出在那一个connection连接层上。化解措施是在出殡和埋葬查询前实践一下底下那句:
    SET NAMES 'utf8';
    它一定于下边包车型地铁三句发号施令:
    CODE:
    SET character_set_client = utf8;
    SET character_set_results = utf8;
    SET character_set_connection = utf8;
    再尝试看,平常了啊?
    尽管连接之后加个查询
    CODE:
    $this->query(”SET NAMES ‘utf8'”);
    看了手册第10章感觉事关心重视大照旧Character Sets的主题素材。
    character_set_client,character_set_results,character_set_connection多少个运行变量是形成乱码的重大。mysql把客商端提交的询问由character_set_client转换为character_set_connection
    ,由于默许网页提交的询问是gb2312(表单页面meta里能够看看),而mysql私下认可将其当作utf8(能够查到那时的 character_set_client=utf8),所以自然乱码。同理,mysql重回的结果是早已转变到character_set_results编码的(与表的编码无关),同样暗许是utf8,而网页页面把它当gb2312管理,所以明确有标题等由数据库读出的字段是乱码而别的单位文字不乱码的景况。
    上述那几个例子是utf8字符集,用此措施,设置为gbk,就能够减轻
    其多个章程:
    mysql 4.1乱码终极技术方案
    请小心,本文只针对mysql 4.1,另外版本的mysql请看别的小说。
    mysql4.1是比较烦人,协助多语言的细化设置,再增多phpmyadmin2.6也相比较笨,暗中同意正是改不动的utf8,怎么弄都乱码。
    好了,废话少说,我们来一步步化解那几个标题:
    1.改造/etc/my.cnf文件,改成这么:
    [mysqld]
    datadir=/var/lib/mysql
    socket=/var/lib/mysql/mysql.sock
    default-character-set=utf8
    [mysql.server]
    user=mysql
    basedir=/var/lib
    [mysqld_safe]
    err-log=/var/log/mysqld.log
    pid-file=/var/run/mysqld/mysqld.pid
    留神:正是投入了一句default-character-set=utf8。
    2./etc/init.d/mysqld restart 再次启航mysql;
    3.打开phpmyadmin,选取lang为"Chines simplifies(zh-utf-8)",选取"MySQL 连接核对"为"utf8_general_ci "点“展现 MySQL 的周转消息”--“变量”,能够看来:
    character set client utf8 utf8
    character set connection utf8 utf8
    character set database utf8 utf8
    character set results utf8 utf8
    character set server utf8 utf8
    character set system utf8 utf8
    collation connection utf8_general_ci utf8_general_ci
    collation database utf8_general_ci utf8_general_ci
    collation server utf8_general_ci utf8_general_ci
    从此间能够阅览character全体制革新为utf8了。
    有人要问,为啥都要改成utf8呢?改成GB2312不行啊?
    解释如下:
    自己也不想改成utf8,只是phpmyadmin2.6在mysql4.1的时候只会用utf8,连别的页面包车型客车charset也都以utf8,改成gb2312一定会乱码,大家只能凑phpmyadmin了。
    除非在mysql3.23的时候,phpmyadmin才会多二个gb2312的页面charset,那时候是正规的。
    3.将原先的mysql3的库文件导入mysql4.1的库
    有二种情况:
    一是从phpmyadmin上导入,那时候你要留心的是在甄选库文件的页面左下脚有个“文件的字符集:”,私下认可是utf8,要改成gb2312,不然导进去乱码;
    二是在linux下导入,那时候你必要先在库文件的尾部加一行:
    SET NAMES 'gb2312'; 注意最后也是;号,别漏了。
    下一场执行mysql -u客户名 -p密码 xxx.sql > 库名
    导入完毕以往再用phpmyadmin张开看,里面包车型客车汉语字正是理所当然的。
    4.从mysql4.1里导出库文件
    一.用phpmyadmin导出
    导出倒是难题非常小,若是phpmyadmin的浏览页面里突显的汉语是例行的,那么导出鲜明也是寻常的
    二.在linux上导出
    假设用mysqldump导出现身了乱码也从没提到,能够运转iconv来转换一下
    iconv -c -f UTF-8 -t GB2312 库文件名 > 新的gb2312的库文件名
    综合,你要注意:
    1。尽量在急需导入的库文件的伊始参与SET NAMES 'gb2312';告诉mysql你要导入的是三个gb2312的公文;
    2。大概您须求那么些:
    SET NAMES 'utf8';
    在登录到mysql后用,把character的一部分暗中同意参数改到utf8上,一时能够削减部分劳神,然而亦不是必需的。
    在mysql上使用:
    SHOW VARIABLES LIKE 'character_set_%';
    用来查看当前的气象。
    3.比方出现乱码也绝不怕,一是您要静心留存原有的备份,二是用iconv来进行转向。
    在常规使用在此之前注意做导入导出的测验,确认保障百下百全。
    下边再作证一下,网络海人民广播广播台湾大学爱人说Mysql4.1的只可以升,无法降. 那是不科学的. 同样使用mysqldump 导出数据库时加二个 --compatible 的参数.也一定不能够忘了--default-character-set=这几个设定字符集的参数.
    示范: mysqldump -uroot -pPassword --compatible=mysql40 --default-character-set=gb2312 discuz>d:discuz.sql
    ok 那样导出来的文书,就能够在Mysql4.0.X和Mysql.3.2.X版本中动用了.
    Linux下 Mysql 5 中文乱码的深透消除及选择的有个别注意事项
    一. 自从mysql4.1从头,mysql对中文的补助难点是比较烦人的,怎么弄都乱码,近来mysql5 听他们讲是mysql的新篇章,但从官方下载安装的mysql5仍存在乱码现象,这里正是本着此境况做的座谈:
    提出最棒是下载mysql的源码进行编写翻译,那是由于官方编写翻译的mysql的暗中认可扶助理编辑码是latin字符集,所以普通话字符在数据Curry查看的时候来看的是乱码。编写翻译MySQL时利用withcharset=编码,可以一本万利地把mysql编写翻译成该编码方式,那样MySQL就能够一贯辅助中文寻找和排序,-- with-extra-charsets参数内定其余可用的字符集。
    下载并解压源码包,展开INSTALL-SOURCE,这里介绍了linux下详细的装置情势,所以大家所要注意的只是底下的configure指令:
    groupadd mysql
    useradd -g mysql mysql
    ./configure --with-charset=gbk --with-collation=gbk_chinese_ci --with-extra-charsets=gb2312,big5,utf8,binary,ascii --prefix=/usr/local/mysql
    make
    make install
    cp support-files/my-medium.cnf /etc/my.cnf
    cd /usr/local/mysql
    bin/mysql_install_db --user=mysql
    chown -R root .
    chown -R mysql var
    chgrp -R mysql .
    bin/mysqld_safe --user=mysql &
    bin/mysql
    mysql> show variables;
    你能够看出全局的字符集参数全都以gbk,gb2312字集应该富含在gbk里,所以不商讨。
    伸开和经常mysql4.0一模二样的php操作,你会意识照旧出现中文乱码现象。
    此间要声明的是:从mysql 4.1始发,必得在mysql数据库连接后对使用的字符集做出表达,不然非保加不莱梅语字母的文字存取都不可能解释产生?号。
    化解措施正是要适应新版mysql的渴求:
    在连接mysql数据库后执行set character set 字符集,该指令在风靡版的mysql 5若是暗中同意字集和存款和储蓄相符可避防设:
    set character set gbk;
    在php里应该是如此写:mysql_query("set character set gbk");
    指令大小写均可
    phpwind和discuz是遍布应用的国产php论坛,大量的爱侣在行使它,明白了上述步骤,你也得以对论坛源码进行相当的小的修改,安全地把数据库晋级到mysql5:
    找到include/db_mysql.php,修改function connect(...){.....}
    在增选数据库mysql_select_db($dbname);前面加上一句mysql_query('set character set gbk');存盘。
    二. 文件的导入导出:假若存入非gbk字符,那时候你供给先在导入文本的尾部加一行: SET NAMES '字符集'; 并细心最后也是;号,别漏了。
    文本导入和导出实行
    mysql -u顾客名 -p密码 数据库名
    mysqldump -u顾客名 -p密码 数据库名>data.sql
    一经用mysqldump导出多少出现了乱码也尚无涉嫌,可以运作iconv来转换一下:
    iconv -c -f utf8 -t gbk 库文件名>新的gbk的库文件名
    综述,你要潜心:
    1。尽量在急需导入的库文件的发端参与set names 'gbk';告诉mysql你要导入的是叁个gbk的公文;
    2。在mysql上使用 show variables;或show variables like 'character_set_%'; 用来查阅当前的字集状态。
    3。如若出现乱码也无须怕,其一是您要注意留存原有的备份,其二是用iconv来进展转账。
    #PHP连接难题:
    是因为MySQL 4.1版本开始密码的hash算法改换,所以一而再数据库时或然会并发Client does not support authentication protocol难题
    此主题材料在mysql 5中海市蜃楼,mysql 5没有必要以下的装置。
    能够由此弹指间三种方法化解数据库客户密码不符难题:
    其一: mysql> SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('newpwd');
    其二: mysql> Update mysql.user SET Password = OLD_PASSWORD('newpwd') Where Host = 'some_host' AND User = 'some_user'
    PHP输出的别的乱码问题:
    倘诺将mysql编译为私下认可编码gbk的话,又会产生非gbk数据直接导入显示为乱码,举例部份utf8积累的字符,假如您大部份数据是utf8字集,当然得把mysql编写翻译为默许编码utf8才合适。
    Mysql 4.1.x出来未来,引进了collation (校订)的概念,终于有措施让mysql同一时候辅助三种编码的数据库了,所以PHP要用以下SQL语句来创造utf-8编码的数据库:
    Create DATABASE `mytest` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
    但是只是是将数据库的校对改为utf-8是远远不足的,还非得在连接了mysql数据库之后用那些语句来安装:set names 'utf8';才能在php程序里拿走不错编码的字符,并将其出示在web页面里。
    mysql_query("set names 'utf8'",$connection);
    下边再作证一下,网络海人民广播广播台湾大学对象说Mysql4.1的只可以升,不能够降. 那是不准确的. 一样使用mysqldump 导出数据库时加叁个 --compatible 的参数.也绝对不可能忘了--default-character-set=那么些设定字符集的参数。
    示范: mysqldump -uroot -pPassword --compatible=mysql40 --default-character-set=gb2312 discuz>d:discuz.sql
    ok 那样导出来的文本,就能够在Mysql4.0.X和Mysql.3.2.X版本中接纳了.
    上边要写的是一篇非常俗气的事物,充斥了大量饶有的编码、转换、客商端、服务器端、连接……呃,笔者要好都不甘于去看它,但想一想,写下来仍然略微意思的,原因有四:
    MySQL 4.1 对多语言的帮忙有了异常的大变化 (那产生了难点的现身);
    就算超越58%的地点 (包涵个人运用和主机提供商),MySQL 3 如故占主导地位;但 MySQL 4.1 是 MySQL 官方推荐的数据库,已经有主机提供商初阶提供并将会越多;
    重重 PHP 程序以 MySQL 作为暗中同意的数据库管理软件,但它们一般不区分 MySQL 4.1 与 4.1 以下版本的界别,笼统地称“MySQL 3.xx.xx 以上版本”就知足安装需要了;
    因为 latin1 在非常多地点 (上边会详细描述具体是哪些地方) 作为暗中同意的字符集,成功的蒙蔽了非常的多 PHP 程序的开垦者和客户,掩盖了在中文等语言情状下会并发的主题材料;
    简轻松单的说,MySQL 本人的更换和接纳 MySQL 的 PHP 程序对此忽略,导致了难点的产出和复杂化,而鉴于超越四分之二顾客选取的是乌Crane语,使这种难点不被重视。这里涉及的 PHP 程序,首要就 WordPress 来说。
    MySQL 4.1 字符集扶助的法规MySQL 4.1 对于字符集的钦定能够细化到一台机械上设置的 MySQL,在那之中的一个数据库,个中的一张表,当中的一栏,应该用什么字符集。不过,古板的 Web 程序在开创数据库和数码表时并未有动用那么复杂的布局,它们用的是默许的布局,那么,暗中同意的布署从何而来呢?
    编写翻译 MySQL 时,钦定了二个暗中认可的字符集,那几个字符集是 latin1;
    安装 MySQL 时,能够在安插文件 (my.ini) 中钦点八个暗中认可的的字符集,假若没钦点,那一个值继承自编译时内定的;
    运维 mysqld 时,能够在命令行参数中钦命一个默许的的字符集,尽管没钦命,那一个值承袭自配置文件中的;
    此时 character_set_server 被设定为这几个暗许的字符集;
    当创立三个新的数据库时,除非显著钦点,这些数据库的字符集被缺省设定为 character_set_server;
    当选定了三个数据库时,character_set_database 被设定为这些数据库暗中同意的字符集;
    在这些数据Curry创设一张表时,表暗中认可的字符集被设定为 character_set_database,也等于那一个数据库暗中认可的字符集;
    当在表内设置一栏时,除非显著钦定,不然此栏缺省的字符集就是表暗中认可的字符集;
    其一字符集正是数据库中实际上存款和储蓄数据运用的字符集,mysqldump 出来的内容正是这么些字符集下的;
    简易的总括一下,如若什么地方都不改换,那么全体的数据库的全数表的装有栏位的都用 latin1 存款和储蓄,可是大家只要设置 MySQL,一般都会接纳多语言协理,也正是说,安装程序会自动在安顿文件中把 default_character_set 设置为 UTF-8,那有限支撑了缺省意况下,全数的数据库的全部表的具有栏位的都用 UTF-8 存款和储蓄。
    当一个 PHP 程序与 MySQL 创设连接后,那个顺序发送给 MySQL 的多寡应用的是怎么着字符集?MySQL 无从得知 (它最两只好猜想),所以 MySQL 4.1 供给顾客端必得钦赐这几个字符集,也正是 character_set_client,MySQL 的好奇之处在于,获得的那一个字符集并比不上时转移为存款和储蓄在数据库中的那多少个字符集,而是先转移为 character_set_connection 变量内定的二个字符集;那几个 connection 层究竟有怎么着用自个儿非常的小掌握,但更动为 character_set_connection 的这么些字符集之后,还要转变为数据库私下认可的字符集,也正是说要透过四次转变;当以此数据被输出时,又要由数据库默许的字符集转换为 character_set_results 钦定的字符集。
    贰个超人的情状出色的境遇以本人要好的Computer上设置的 MySQL 4.1 为例,笔者要好的计算机上安装着 Apache 2,PHP 5 和 WordPress 1.5.1.3,MySQL 配置文件中钦点了 default_character_set 为 utf8。于是难题应际而生了:
    WordPress 依据暗中认可意况设置,所以具有的表都用 UTF-8 存款和储蓄数据;
    WordPress 默许采取的浏览字符集是 UTF-8 (Options->Reading 中装置),由此全部 WP 页面包车型地铁 meta 中会表达 charset 是 utf-8;
    之所以浏览器会以 utf-8 形式呈现全体的 WP 页面;那样一来 Write 的装有 Post,和 Comment 都会以 UTF-8 格式从浏览器发送给 Apache,再由 Apache 交给 PHP;
    因而 WP 从有着的表单中获得的数目都以 utf-8 编码的;WP 不加调换的直接把那个多少发送给 MySQL;
    MySQL 默许设置的 character_set_client 和 character_set_connection 都以 latin1,此时离奇的业务发生了,实际上是 utf-8 格式的数额,被“当作 latin1”转变来……居然依旧转变到 latin1,然后再由那几个 latin1 调换来utf-8,这么五遍调换,有局地 utf-8 的字符就不见了,产生??,最终输出的时候 character_set_results 私下认可是 latin1,也就输出为意外的事物了。
    最美妙的还不是以此,假设 WordPress 中安装以 GB2312 格式阅读,那么 WP 发送给 MySQL 的 GB2312 编码的多寡,被“当作 latin1”调换后,存进数据库的是一种不敢相信 无法相信的格式 (真的是意外的格式,mysqldump 出来就会觉察,无论作为 utf-8 依然作为 gb2312 来读都以乱码),但只要这种格式以 latin1 输出出来,居然又能变回 GB2312!
    那会促成如何情况呢?WP 借使利用 MySQL 4.1 数据库,把编码改用 GB2312 就像常了,可惜,这种健康只是形似符合规律。
    何以化解难题借使您早就不耐烦了 (大致是一定的),google 一下,会意识绝大多数的解答是,query 从前先进行一下:SET NAMES 'utf8',没有错,那是设计方案,但本文的目标是注解,那干吗是消除方案。
    要确认保障结果精确,必得确定保障数据表选拔的格式是不易的,也正是说,至少可以贮存全体的方块字,那么大家唯有三种选用,gbk 恐怕 utf-8,下边商讨 utf-8 的意况。
    因为安插文件设置的 default_character_set 是 utf8,数据表暗中认可选拔的即是utf-8 创建的。那也理应是兼备应用 MySQL 4.1 的主机提供商应该选择的布局。所以咱们要保管的只是顾客端与 MySQL 交互之间钦点编码的不易。
    那唯有二种只怕,客户端以 gb2312 格式发送数据,大概以 utf-8 格式发送数据。
    举例以 gb2312 格式发送:
    SET character_set_client='gb2312'
    SET character_set_connection='utf8' 或者
    SET character_set_connection='gb2312'
    都以足以的,都可以保障数据在编码转变中不出现遗失,也正是有限协理仓库储存入数据库的是不利的剧情。
    怎么保险抽取的是没错的开始和结果吧?思虑到多方客商端 (包括WP),发送数据的编码也正是它所期望接受数额的编码,所以:
    SET character_set_results='gb2312'
    能够确定保障收取给浏览器展现的格式正是 gb2312。
    一经是第三种景况,客商端以 utf-8 格式发送 (WP 的默许处境),能够使用下述配置:
    SET character_set_client='utf8'
    SET character_set_connection='utf8'
    SET character_set_results='utf8'
    本条布局就相当于 SET NAMES 'utf8'。
    WP 应该作什么修改照旧那句话,顾客端要发给数据库什么编码的多寡,数据库是不容许适合知道的,只可以让客商端本身说精晓,所以,WP 是必得发送准确的 SET... 给 MySQL 的。怎么发送最合适呢?吉林的 pLog 同仁给出了部分建议:
    率先,测量检验服务器是或不是 >= 4.1,编写翻译时是不是出席了 UTF-8 协理;是则继续
    然后测量检验数据库以怎么样格式存款和储蓄 ($dbEncoding);
    SET NAMES $dbEncoding
    对此第二点,WP 的场合是见仁见智的,根据上面包车型客车头名配置,只要用 WP,料定数据库是用 UTF-8 存款和储蓄的,所以要依据客户安装的以 GB2312 依然UTF-8 浏览来剖断(bloginfo('charset')),但那个值是要连接数据库现在本事获得的,所以效用最高的艺术是连接数据库之后,依照这一个布局安装一次SET NAMES,而不用每一遍查询在此之前都安装三次。
    自家的修改章程是那样的,在 wp_includes/wp-db.php 中增加:
    function set_charset($charset)
    {
    // check mysql version first.
    $serverVersion = mysql_get_server_info($this->dbh);
    $version = explode('.', $serverVersion);
    if ($version[0] < 4) return;
    // check if utf8 support was compiled in
    $result = mysql_query("SHOW CHARACTER SET like 'utf8'",
    $this->dbh);
    if (mysql_num_rows($result) < = 0) return;
    if ($charset == 'utf-8' || $charset == 'UTF-8')
    $charset = 'utf8';
    @mysql_query("SET NAMES '$charset'", $this->dbh);
    }
    在 wp-settings.php 的 require (ABSPATH . WPINC . '/vars.php'); 后增加:
    $wpdb->set_charset(get_bloginfo('charset'));

  4. MySQL 4.1 在文字上有非常大革新,它有了 Character Set 与 Collation 的慨念。

  5. 在 MySQL 4.0 ,一般的程式都会将文字以拉丁文 ( latin) 来积攒,固然大家输入中文字,结果仍是放在以拉丁文设置的文字栏里头,那对 MySQL 4.0 与以 MySQL 4.0 为基楚的程式来讲,并不会有有失常态态。
  6. 唯独 MySQL 4.1 的体系编码是预设用 UTF-8 的,当要 restore MySQL 4.0 的 backup 档到 MySQL 4.1 时,乱码就出现了。原因在于 MySQL 4.1 将 latin 码转变过来,而后转变是并不完全完美的,那导致了产出一些些文字出现乱码现象。
  7. 要消除这乱码难点并简单。首先,在 MySQL 4.0 备份时,先将全数文字栏产生binary 类型,然后开展常规备份。第二步,可在 MySQL 4.1 里将刚刚的备份 restore。最后,将较早前所更动到 binay 类型的文字栏,再度大张旗鼓到文字类型。那样中文编码的难题就相应可以完全缓慢解决。
  8. 将文字栏更动到 binay 类型时,必须设定 binary 栏的长短大过或等于 (>=) 文字栏的长度,不然资料会失掉。
  9. 别的,经那样晋级的 MySQL 数据库,在 MySQL 4.1 里将会日常干活,就终于什么 backup 与 restore 都不会再有乱码难点。
    小编: MySQL 公布日期: 2006-12-14
    mysql4.1是相比烦人,辅助多语言的细化设置,再增多phpmyadmin2.6也正如笨,私下认可便是改不动的utf8,怎么弄都乱码。
    好了,废话少说,大家来一步步化解那几个主题素材:
    1.修改/etc/my.cnf文件,改成那样:
    [mysqld]
    datadir=/var/lib/mysql
    socket=/var/lib/mysql/mysql.sock
    default-character-set=utf8
    [mysql.server]
    user=mysql
    basedir=/var/lib
    [mysqld_safe]
    err-log=/var/log/mysqld.log
    pid-file=/var/run/mysqld/mysqld.pid
    注意:就是步入了一句default-character-set=utf8。
    2./etc/init.d/mysqld restart 双重启航mysql;
    3.开辟phpmyadmin,选用lang为"Chines simplifies(zh-utf-8)",选拔"MySQL 连接查对"为"utf8_general_ci "点“展现 MySQL 的运作消息”--“变量”,能够见见:
    character set client utf8 utf8
    character set connection utf8 utf8
    character set database utf8 utf8
    character set results utf8 utf8
    character set server utf8 utf8
    character set system utf8 utf8
    collation connection utf8_general_ci utf8_general_ci
    collation database utf8_general_ci utf8_general_ci
    collation server utf8_general_ci utf8_general_ci
    从那边能够见到character全体造成utf8了。
    有人要问,为何都要改成utf8呢?改成GB2312不行呢?
    表明如下:
    本身也不想改成utf8,只是phpmyadmin2.6在mysql4.1的时候只会用utf8,连别的页面包车型地铁charset也都是utf8,改成gb2312一定会乱码,大家只可以凑phpmyadmin了。
    除非在mysql3.23的时候,phpmyadmin才会多三个gb2312的页面charset,那时候是平常的。
    3.将此前的mysql3的库文件导入mysql4.1的库
    有二种景况:
    一是从phpmyadmin上导入,那时候你要注意的是在挑选库文件的页面左下脚有个“文件的字符集:”,私下认可是utf8,要改成gb2312,不然导进去乱码;
    二是在linux下导入,那时候你需求先在库文件的头顶加一行:
    SET NAMES 'gb2312'; 注意最终也是;号,别漏了。
    下一场施行mysql -u客户名 -p密码 xxx.sql > 库名
    导入完毕之后再用phpmyadmin展开看,里面包车型大巴汉语字就是合情合理的。
    4.从mysql4.1里导出库文件
    一.用phpmyadmin导出
    导出倒是难点一点都不大,如若phpmyadmin的浏览页面里呈现的国语是符合规律的,那么导出料定也是健康的
    二.在linux上导出
    万一用mysqldump导出出现了乱码也未曾涉嫌,能够运转iconv来转换一下
    iconv -c -f UTF-8 -t GB2312 库文件名 > 新的gb2312的库文件名
    综合,你要专一:
    1。尽量在急需导入的库文件的发端插手SET NAMES 'gb2312';告诉mysql你要导入的是二个gb2312的文书;
    2。或许您须求那一个:
    SET NAMES 'utf8';
    在登录到mysql后用,把character的一些私下认可参数改到utf8上,不时能够减弱部分烦劳,但是亦不是必需的。
    在mysql上使用:
    SHOW VARIABLES LIKE 'character_set_%';
    用来查阅当前的景色。
    3.只要出现乱码也不要怕,一是你要细心留存原有的备份,二是用iconv来拓宽转载。
    在健康使用在此以前注意做导入导出的测验,确认保障万不一失。

一准备:
条件:MySQL4.1.x及以上版本。
Convertz——文本编码转变工具,molyx上介绍的,笔者动用的。其实那类工具比较多。

一:

自己晋级了MYSQL到4.1.2,phpmyadmin用的是2.6.2。数据表里面有中文的字段粤语都改成了乱码,导出数据也是乱码。作者用在此以前的2.5.7未曾难点,想问一下,应该在phpmyadmin的老大文件里改哪个设置一下才干显得出来的是例行的中文字?
和字符相关的变量中那多少个和sql很有提到:
character_set_client
character_set_connection
character_set_results
除此以外就是数据库中对相应字段设置的charact set,若无对字段设置,缺省是table的charact set,table也从没点名则缺省使用database的。
地方3个变量的职能是那样的,client表示客商端发送过来的字符集,results代表发送到客商端的字符集(那五个分别是因为发送过来和发送过去的不必然是同三个客商端),connection则在顾客端和数据库起叁个再三再四成效。
切实是这样:譬如自身在mysql命令行设置client为gbk,connection为utf8,results为gbk,数据库为big5,
当自家发送二个insert语句的时候,那么些讲话作为gbk代码,先转为utf8代码(connection),再转为big5(database)插入数据库。
而运转二个select语句的时候,从数据库得到的结果则相反的长河,由big5转为utf8,再转为gbk,你获得gbk的结果。
为此最根本的是让client和results和您利用的顾客端一致。举例你的网页是utf8编码,你将在设置那多个为utf8。
而在mysql命令行的时候,作者用的是两千,供给安装为gbk
而作者辈用的set names XXX,实际上正是同有时间安装那3个变量为XXX。
在如此的状态下,我们能够把八个数据库中的不一致表或分化字段设为分化的字符集,只要上边3个设置科学,就能够在数据库中并且利用不相同的字符集。
在意要确定保障你的数据库中的字符已经使用了不错的字符集,举例借使一同先你设置错误,插入数据后,自身数据的编码就是不得法的,然后就是设置改回来,也不容许获取精确的来得了。
还会有多少个是编码相互之间的包容性,如果七个字符在gbk中有,在utf第88中学未有,那么在gbk-》utf8-》gbk的进度中,它就形成了“?”
再说一下实际化解的法子。
率先要钦命你的升官后的database及table及田野先生的character set,一般的话大家用gb2312可能utf8的,借使区别期采用两种编码,只要内定database就能够,可以在建库的sql语句加上相应的 character set,在phpMyAdmin里也能够修改。
接下来是导入旧数据。首先要规定本身的数据文件的编码。假若用phpMyAdmin导入,在分界面上有文件编码的选项,一定要和数据文件的编码一致。
借使从mysql的一声令下行导入,将在和煦安装方面谈起的3个变量,set names xxx。
选用任何的客商端程序一样要留意。
如此那般就足以让旧数据转入新数据库后的编码才是理所当然的,假设这一步错了,前面不大概赢得不错的显得。
下一场是温馨的顺序,在连接后就能够试行贰遍set names xxx,根据你的网页编码而定。
这么基本就足以保险编码准确了。
你很有非常大大概是导入的数据编码已经不对了。

二理论:
MySQL从4.1本子发轫内部存款和储蓄字符集协助了UTF-8,那个自家也是近些日子才看到的。因为晋级论坛进度中,服务器数据库境遇为4.0.26立即不清楚并不帮忙utf-8字符集,还废了些周折。那样只要涉嫌到UTF-8转储还要进级MySQL版本到4.1上述。
转移的光景思路是——备份(有备无缓)→修复数据库→mysqldump导出→Convertz转变编码→修改调换后文件→mysqldump导入苏醒

1、备份数据库

MYSQL数据库暗中同意语言为立陶宛语, 现存一GB2312字符的数据库.
组织OK. 为何内容是乱码? 不重装数据库有办法消除码?
从MySQL 4.1上马引进的多语言协理确实很棒,何况一些特征已经超先生越了别的的数据库系统。然则小编在测量试验进度中开采接纳适用于MySQL 4.1事先的PHP语句操作MySQL数据库会促成乱码,即便是设置过了表字符集也是那般。笔者读了一晃新的MySQL在线手册中第十章 "Character Set Support"后终归找到了缓慢解决办法并测验通过。
MySQL 4.1的字符集补助(Character Set Support)有七个方面:字符集(Character set)和排序情势(Collation)。对于字符集的支撑细化到八个档案的次序: 服务器(server),数据库(database),数据表(table)和连接(connection)。
翻开系统的字符集和排序情势的设定能够由此上面包车型地铁两条命令:

三实践:
1、备份。那个没有须要太多说了您可以选择其余一种寻常的备份格局只要你本人回复的了。
2、修复。mysqlcheck -r -u user -p 就算全OK那就OK了,假使不全OK,再来遍。还没全OK,不知情怎么弄了。
3、导出。由于latin1为暗中认可存款和储蓄,所以您需求事先鲜明你数据库的编码格式。比如,lncz.net原为gbk编码,但存款和储蓄为latin1,那样导出时应当钦点编码为latin1,导出后才具以ANSI方式准确呈现gbk的文字。
导出命令:mysqldump database_name field > path --default-character-set=latin1 -u user -p
数据库大需求分段,不然接下去的操作会很坚苦。笔者是独立把各样表导出来的。当时设法比较轻便,因为数据库有坏表,只想在平复的时候知道哪些表出错单独修复。
4、转换。Convertz用这几个软件很简短,不必多说了。
5、修改。我在尝试直接导入恢复生机数据库时,战败了N次,每一趟都乱码。细心想过之后才明白,要是您一向导回去,数据库照旧用暗中认可的latin1去存款和储蓄,而你的现行反革命的编码是utf-8所以它会再拓宽一回转换便出错了。这里MySQL到底怎么管理的自小编还不是极度接头,哪个人知道麻烦相告。那时大家须求对转移好的公文参加语句 “set names utf8;”注意不是utf-8;何况供给将文件中“CHA途锐SET=latin1;”改为“CHA中华VSET=utf8;”来钦定表的存放编码。
6、恢复生机。恢复生机过程按道理应该是很简短的,都以mysqldump管理。要求注意一点便是要是您的数据库大,要做全局变量的改造max_allowed_packet默以为1M,看您多少库表的尺寸,相应修改my.ini文件。
导入命令:mysqldump database_name < path -u user -p 导入顺遂的话你的数据库编码就已经转移为utf-8了。

mysqldump --default-character-set=latin1 --create-options=false --set-charset=false -u root -p 数据库名称 > E: ack.sql

mysql> SHOW VARIABLES LIKE 'character_set_%';
-------------------------- ----------------------------
| 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 | /usr/share/mysql/charsets/ |
-------------------------- ----------------------------
7 rows in set (0.00 sec)
mysql> SHOW VARIABLES LIKE 'collation_%';
---------------------- -------------------
| Variable_name | Value |
---------------------- -------------------
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
---------------------- -------------------
3 rows in set (0.00 sec)

在下相比较菜,假诺有错误请指正,表笑作者。以上仅供仿照效法。 

2、创制新数据库

地点列出的值正是系统的暗许值。(很古怪系统怎么私下认可是latin1的印度语印尼语排序方式)...
当大家依照原先的点子通过PHP存取MySQL数据库时,尽管设置了表的默许字符集为utf8何况经过UTF-8编码发送查询,你会发觉存入数据库的照旧是乱码。难点就出在那么些connection连接层上。消除办法是在发送查询前施行一下下边那句:
SET NAMES 'utf8';
它一定于上边包车型客车三句发号施令:
SET character_set_client = utf8;
SET character_set_results = utf8;
SET character_set_connection = utf8;
再尝试看,平常了吗?^_^ Enjoy!
具体讲
在你的询问前加一行:
mysql_query("SET NAMES 'gb2312';",$this->con);
真应该把手册细心看一回.
和字符相关的变量中那多少个和sql很有涉及:
character_set_client
character_set_connection
character_set_results
别的正是数据库中对相应字段设置的charact set,若无对字段设置,缺省是table的charact set,table也不曾点名则缺省使用database的。
上面3个变量的机能是那般的,client表示客商端发送过来的字符集,results表示发送到客商端的字符集(那五个分别是因为发送过来和发送过去的不必然是同一个顾客端),connection则在客商端和数据库起四个接连功效。
切切实实是这般:比方作者在mysql命令行设置client为gbk,connection为utf8,results为gbk,数据库为big5,
当小编发送八个insert语句的时候,那么些讲话作为gbk代码,先转为utf8代码(connection),再转为big5(database)插入数据库。
而运作一个select语句的时候,从数据库得到的结果则相反的进程,由big5转为utf8,再转为gbk,你获得gbk的结果。
由此最重视的是让client和results和你利用的客商端一致。比方您的网页是utf8编码,你将在设置那三个为utf8。
而在mysql命令行的时候,笔者用的是3000,须要设置为gbk
而小编辈用的set names XXX,实际上即使同期安装这3个变量为XXX。
在这么的状态下,我们得以把贰个数据库中的区别表或差别字段设为分歧的字符集,只要上面3个设置科学,就足以在数据库中并且选用差别的字符集。
留意要保管你的数据库中的字符已经采取了不错的字符集,比方倘诺一初阶你设置错误,插入数据后,本身数据的编码便是不准确的,然后正是设置改回来,也不容许获得正确的显得了。
再有贰个是编码相互之间的包容性,假设三个字符在gbk中有,在utf第88中学未有,那么在gbk-》utf8-》gbk的经过中,它就改为了“?”
再说一下切实化解的主意。
先是要钦赐你的升官后的database及table及田野先生的character set,一般的话我们用gb2312只怕utf8的,若是不一致不常候利用多样编码,只要钦定database就能够,能够在建库的sql语句加上相应的 character set,在phpMyAdmin里也足以修改。
下一场是导入旧数据。首先要规定本人的数据文件的编码。倘若用phpMyAdmin导入,在分界面上有文件编码的选项,必须求和数据文件的编码一致。
假如从mysql的吩咐行导入,就要团结安装方面聊到的3个变量,set names xxx。
应用别的的顾客端程序同样要细心。
诸如此比就足以让旧数据转入新数据库后的编码才是不利的,若是这一步错了,后边不容许获取不错的呈现。
接下来是友善的前后相继,在连接后就足以实施一遍set names

您恐怕感兴趣的稿子:

  • Mysql数据库编码难点(修改数据库,表,字段编码为utf8)
  • 修改mysql5.5暗许编码(图像和文字步骤修改为utf-8编码)
  • MySql修改数据库编码为UTF8制止变成乱码难题
  • 查阅修改mysql编码形式让它帮助汉语(gbk或然utf8)
  • MYSQL数据库使用UTF-8中文编码乱码的解决办法
  • php页面,mysql数据库转utf-8乱码,utf-8编码难点计算
  • mysql私下认可编码为UTF-8 通过改换my.ini完结方式
  • Window 下安装Mysql5.7.17 及安装编码为utf8的章程
  • PHP与MYSQL中UTF8编码的国语排序实例
  • windows下mysql 5.7本子中期维修改编码为utf-8的方法步骤

CREATE DATABASE 数据库名称 CHARACTE奥迪Q7 SET utf8 COLLATE utf8_general_ci;

xxx,依据你的网页编码而定。

mysql 导入乱码难题- -
mysql从4.1选用mysqldump导出多少并在4.0导入的时候会产出sql语句错误,并且具有数据产生乱码。使用上边包车型客车参数就能够化解
mysqldump -uxunai -p --compatible=mysql40 --default-character-set=latin1 xunai>xunai.sql
mysql -uroot -p fmx < fmx3.sql -f --default-character-set=latin1

3、导入数据

你大概感兴趣的稿子:

  • mysql导入导出数据普通话乱码化解办法小结
  • MySQL中文乱码问题的解决
  • Mysql 导入导出csv 中文乱码难题的化解措施
  • MySQL字符集 GBK、GB2312、UTF8区别化解MYSQL中文乱码难点
  • 小结下MySQL中文乱码,phpmyadmin乱码,php乱码 发生原因及其化解方法
  • 大规模php与mysql汉语乱码难题消除办法
  • JSP MySQL华语乱码难题post提交乱码技术方案
  • jsp汉语乱码 jsp mysql 乱码的消除格局
  • 实战mysql导出汉语乱码及phpmyadmin导入汉语乱码的化解措施
  • Mysql粤语乱码以及导出为sql语句和Excel难题一蹴即至办法[图文]
  • Mysql 下汉语乱码的标题一下子就解决了方法总计

mysql -u root -p --default-character-set=gbk 数据库名称 < E: ack.sql

 

二:

手续一 命令行实践:mysqldump --opt -hlocalhost -uroot -p*** --default-character-set=lantin1 dbname > /usr/local/dbname.sql

手续二 将 dbname.sql文件中的create table语句的CHACR-VSET=latin1改为CHA凯雷德SET=utf8

本文由新浦京81707con发布于首页,转载请注明出处:8编码转换,总结下MYSQL编码转换的问题latin1转u

关键词: 新浦京81707con

上一篇:附demo源码下载,jQuery实现仿腾讯视频列表分页效

下一篇:没有了