mysql下，某数据库中有中文，但因为某种原因，需要转换为latin1编码，如果不进行转码，将会出现乱码.

你把表的DEFAULT CHARSET=latin1设置上

CREATE TABLE `Table_1` (

`ID` INT(11) NOT NULL AUTO_INCREMENT,

`URL` VARCHAR(255) DEFAULT NULL,

PRIMARY KEY (`ID`)

) DEFAULT CHARSET=latin1

如果你已经建完表t1了,可以把表的数据都导到一个临时表t2,然后删掉t1,用上边的方式重建t1,然后再把t2里存的之前的数据导回来

页面传过来的一般为ISO-8859-1格式编码，

中文需对照着解码：

String myname= requestgetParameter("myname");

String mynamemagb=new String(mynamegetBytes("ISO-8859-1"),"UTF-8");

(这样mynamemagb存的就是"UTF-8"，想存成其他编码，将其替换就行)。

页面传过来的也可能是其他编码，这时候只要"ISO-8859-1"换成对应的编码就行了。

以下是Java中常见的编码格式：

US-ASCII 7 位 ASCII 字符，也叫作 ISO646-US、Unicode 字符集的基本拉丁块

ISO-8859-1 ISO 拉丁字母表 No1，也叫作 ISO-LATIN-1

UTF-8 8 位 UCS 转换格式

UTF-16BE 16 位 UCS 转换格式，Big Endian（最低地址存放高位字节）字节顺序

UTF-16LE 16 位 UCS 转换格式，Little-endian（最高地址存放低位字节）字节顺序

UTF-16 16 位 UCS 转换格式，字节顺序由可选的字节顺序标记来标识

根据你的问题，数据库不在自己手边。

那首先要调查清楚，数据表的编码，看清，不是数据库，是表，表的字符集编码。

然后往前顺。

然后再java程序中转码，保证写到sql中的数据是以该数据表所用的字符集编码的就好了。

乱码出现在不同部分的通信之间

一个系统中，通常是在显式输入中文的地方发生转码错误。

比如，servlet处理从浏览器传来的数据的时候，

从资源文件读取数据的时候。

在程序中显式地硬编码字符串中文字面值的时候。

从别人的数据库读取数据的时候。

这些地方经常会跟之后的系统编码不一致，所以在这些地方使用字符串数据的时候，就要转码。

资源文件，可以用文本工具保存成需要的编码。

对于request中的数据，可以在正式处理之前加

过滤器。

对于别的数据库，可以设一个专门的过滤类来转码。

最后用到的一句代码是：

<%= new String(rstgetString(2)getBytes("ISO-8859-1"),"gb2312")%>

大家在JSP的开发过程中，经常出现中文乱码的问题，可能一至困扰着您，我现在把我在JSP开发中遇到的中文乱码的问题及解决办法写出来供大家参考。

一、JSP页面显示乱码

下面的显示页面(displayjsp)就出现乱码：

对不同的WEB服务器和不同的JDK版本，处理结果就不一样。原因：服务器使用的编码方式不同和浏览器对不同的字符显示结果不同而导致的。解决办法：在JSP页面中指定编码方式(gb2312),即在页面的第一行加上：，就可以消除乱码了。完整页面如下：

二、表单提交中文时出现乱码

下面是一个提交页面(submitjsp)，代码如下：

下面是处理页面(processjsp)代码：

如果submitjsp提交英文字符能正确显示，如果提交中文时就会出现乱码。原因：浏览器默认使用UTF-8编码方式来发送请求，而UTF-8和GB2312编码方式表示字符时不一样，这样就出现了不能识别字符。解决办法:通过requestseCharacterEncoding("gb2312")对请求进行统一编码，就实现了中文的正常显示。修改后的processjsp代码如下：

三、数据库连接出现乱码

只要涉及中文的地方全部是乱码，解决办法：在数据库的数据库URL中加上useUnicode=true&characterEncoding=GBK就OK了。

四、数据库的显示乱码

在mysql410中,varchar类型，text类型就会出现中文乱码，对于varchar类型把它设为binary属性就可以解决中文问题，对于text类型就要用一个编码转换类来处理，实现如下：

public class Convert {

/ 把ISO-8859-1码转换成GB2312

/

public static String ISOtoGB(String iso){

String gb;

try{

if(isoequals("") || iso == null){

return "";

}

else{

iso = isotrim();

gb = new String(isogetBytes("ISO-8859-1"),"GB2312");

return gb;

}

}

catch(Exception e){

Systemerrprint("编码转换错误："+egetMessage());

return "";

}

}

}

把它编译成class，就可以调用Convert类的静态方法ISOtoGB()来转换编码。

和Java一样，JSP是目前比较热门的一个话题。它是一种在服务器端编译执行的Web设计语言，因为脚本语言采用了Java，所以JSP继承了Java的所有优点。可是在使用JSP程序的过程中，常遇到中文乱码问题，很多人为此头疼不已，笔者就深受其害，而且使用平台不同，中文乱码问题的解决方法也不同，无形中增加了学习JSP的难度。其实，在彻底了解相关原因后，问题还是比较容易解决的。笔者结合自己的工作实践，对中文显示问题进行了一定的研究，并在不同的环境下进行了相关测试，以下是笔者总结的解决方法，相信对读者会有一定的借鉴意义。

字符内码

每个国家（或区域）都规定了计算机信息交换用的字符编码集，如美国的扩展ASCII码、中国的GB2312-80、日本的 JIS 等，作为该国家(区域)信息处理的基础，有着统一编码的重要作用。由于各本地字符集代码范围重叠，相互间信息交换困难，软件本地化版本独立维护成本较高。因此有必要将本地化工作中的共性抽取出来，做一致性处理，将特殊的本地化处理内容降低到最少，这就是所谓的国际化（I18N）。各种语言信息被规范为本地信息，而底层字符集采用包含了所有字符的Unicode。

字符内码(character code)指的是用来代表字符的内码。我们在输入和存储文档时都要使用内码，内码分为单字节内码和双字节内码。单字节内码的英文全称是Single-Byte Character Sets (SBCS)，可以支持256个字符编码；双字节内码的英文全称是Double-Byte Character Sets(DBCS)，可以支持65000个字符编码，主要用来对大字符集的东方文字进行编码。

CodePage指的是一个经过挑选的以特定顺序排列的字符内码列表，对于早期的单字节内码的语种，CodePage中的内码顺序使得系统可以按照此列表来根据键盘的输入值给出一个对应的内码。对于双字节内码，给出的是MultiByte到Unicode的对应表，这样就可以把以Unicode形式存放的字符转化为相应的字符内码。引入对CodePage的支持主要是为了访问多语种文件名，目前在NTFS和FAT32/VFAT下的文件系统上都使用Unicode，这需要系统在读取这些文件名时动态地将其转换为相应的语言编码。

相信了解JSP代码的读者对ISO8859-1一定不陌生，ISO8859-1是我们平时使用比较多的一个CodePage，它属于西欧语系。GB2312-80 是在国内计算机汉字信息技术发展初始阶段制订的，其中包含了大部分常用的一、二级汉字和9区的符号。该字符集是几乎所有的中文系统和国际化的软件都支持的中文字符集，这也是最基本的中文字符集。

GBK 是 GB2312-80 的扩展，是向上兼容的。它包含了20902个汉字，其编码范围是 0x8140～0xFEFE，剔除高位 0x80 的字位，其所有字符都可以一对一映射到 Unicode 20，也就是说 Java 实际上提供了对 GBK 字符集的支持。

>GB18030-2000(GBK2K) 在 GBK 的基础上进一步扩展了汉字，增加了藏、蒙等少数民族的文字。GBK2K 从根本上解决了字位不够、字形不足的问题。

不同开发平台的区别

1．Tomcat 4开发平台

Windows 98／2000下的Tomcat 4以上版本都会出现中文问题（而在Linux下和Tomcat 3x中则没有问题），主要表现是页面显示乱码。在IE中调整字符集为GB2312，就可以正常显示了。

为解决这个问题，可在每个JSP的页面开始处加上。不过，这还不够，虽然这时显示了中文，但是发现从数据库读出的字段变成了乱码。经过分析发现: 在数据库中保存的中文字符是正常的，数据库用ISO8859-1字符集存取数据，而Java程序在处理字符时默认采用统一的ISO8859-1字符集(这也体现了Java国际化思想)，所以在数据添加的时候Java和数据库都是以ISO8859-1方式处理，这样不会出错。但是在读取数据的时候就出现问题了，因为数据读出也采用ISO8859-1字符集，而 JSP的文件头中有语句，这说明页面采用GB2312的字符集显示，这样就和读出的数据不一样。这时页面显示从数据库中读出的字符是乱码，解决的方法是对这些字符转码，从ISO8859-1转成GB2312，就可以正常显示了。这个解决办法对很多平台具有通用性，读者可以灵活运用。

2．Tomcat 3x、Resin及Linux平台

在Tomcat 3x、Resin中或是在Linux下，没有加入语句，而页面中的语句起了作用，此时可以正常显示。相反，如果加上系统会报错，说明Tomcat 4以上版本的引擎在处理JSP时还是有差别的。

另外，对于不同的数据库如SQL Server，Oracle，Mysql，Sybase等，字符集的选择很重要。如果考虑多语言版本，数据库的字符集就应该统一采用ISO8859-1，需要输出的时候在不同的字符集之间做转换就可以了。

以下是针对不同平台的总结：

(1) JSWDK只适合于普通开发，稳定性和其他问题可能不如商业软件。 由于JDK 13版性能要好于JDK 122很多，并且对中文的支持也较好，所以应该尽量采用。

(2) 作为免费的商业软件，Resin不仅速度快、稳定、自动编译，还可以指出出错行，并可在服务器端支持使用JavaScript等，而且对中文的支持也很好。

(3) Tomcat仅仅是一个对JSP 11、Servlet 22标准的实现, 我们不应该要求这个免费软件在细节和性能上都面面俱到, 它主要考虑英文用户, 这也是为什么不做特殊转换，汉字用URL方法传递就有问题的原因。大部分IE浏览器缺省始终以UTF-8发送, 这似乎是Tomcat的一个不足, 另外Tomcat不管当前的 *** 作系统是什么语言, 都按ISO8859去编译JSP, 似乎也欠妥。

JSP代码的中文处理

在JSP代码中以下几处经常需要涉及到中文处理:

1 在URL中附带中文参数。这里中文参数通常可以直接读取，例如:

2 在JSWDK中读取HTML表单提交的中文值这时需要加以编码，较为简洁的写法是：

String name1=new String(requestgetParameter(“user_id”)getBytes(“ISO8859_1”))。

另外，在JDK 13的支持下，不需加入 ，而在JDK 122 以下，即使以上两种方法同时运用也很不稳定。但在Resin平台，情况较好，只要在页面第一行加入：即可正确处理中文，如果再加代码则反而不对。

3．在JSWDK中Session包含的中文，如果从表单中读出的值经过编码可正确显示，但直接赋予中文值则不行，而Resin平台则很好。

4 在编译Servlet和JSP时加入代码选项。在编译Servlet时使用Java-Encoding ISO8859-1 myservletjava；在JSP的ZONE配置文件中，修改编译参数为：Compiler=builtin - javac- encoding ISO8859-1。使用这种方法后，不需要做其他的改动就可以正常显示中文了。

另外，流行的关系数据库系统都支持数据库Encoding，也就是说在创建数据库时可以指定它自己的字符集设置，数据库的数据以指定的编码形式存储。当应用程序访问数据时，在入口和出口处都会有 Encoding 转换。对于中文数据，数据库字符编码的设置应当保证数据的完整性。 GB2312、GBK、UTF-8 等都是可选的数据库 Encoding，也可以选择 ISO8859-1 (8-bit)， 但会增加了编程的复杂度，ISO8859-1不是推荐的数据库 Encoding。在JSP/Servlet编程时，可以先用数据库管理系统提供的管理功能检查其中的中文数据是否正确。

处理方法实例

下面是两个具体的中文乱码解决实例，读者仔细研究后可能会有所收获。

1．常见的字符转换方法

将Form 中 的 值 传 送 到 数 据 库 中 再 取 出 来 后 全 变 成 了“？”。Form用POST提交数据，代码中使用了语句：String st=new(requestgetParameter(“name”)getBytes(“ISO8859_1”))， 而且也声明了charset=gb2312。

要处理Form中传递的中文参数，应该在JSP中加入下面的代码，另外定义一个专门解决这个问题的getStr类，然后对接收到的参数进行转换：

String keyword1=requestgetParameter(“keyword1”);

keyword1=getStr(keyword1);

这样就可以解决问题了，代码如下：

2 JDBC Driver的字符转换

目前大多数JDBC Driver采用本地编码格式来传输中文字符，例如中文字符“0x4175”会被转成“0x41”和“0x75”进行传输。因此需要对JDBC Driver返回的字符以及要发给JDBC Driver的字符进行转换。当用JDBC Driver向数据库中插入数据时，需要先将Unicode转成Native code; 当 JDBC Driver从数据库中查询数据时，则需要将Native code转换成Unicode。下面给出了这两种转换的实现:

String native2Unicode(String s) {

if (s == null || slength() == 0) {

return null;

}

byte[] buffer = new byte[slength()];

for (int i = 0; i slength(); i++) { if (scharAt(i)>= 0x100) {

c = scharAt(i);

byte []buf = (“”+c)getBytes();

buffer[j++] = (char)buf[0];

buffer[j++] = (char)buf[1];

}

else {buffer[j++] = scharAt(i);}

}

return new String(buffer, 0, j);

}

要注意的是，有些JDBC Driver如果通过JDBC Driver Manager设置了正确的字符集属性，以上方法就不需要了。具体情况可参考相关JDBC的资料。

是的，Oracle编码GBK加载UTF-8文件需要转码。由于Oracle数据库使用的是GBK编码，而UTF-8文件使用的是UTF-8编码，因此在加载UTF-8文件之前，需要将文件的编码从UTF-8转换为GBK。转码的过程非常简单，只需要使用Oracle的转换函数，将UTF-8文件转换为GBK编码，就可以加载到Oracle数据库中。

一、转码失败

在数据写入到表的过程中转码失败，数据库端也没有进行恰当的处理，导致存放在表里的数据乱码。

针对这种情况，前几篇文章介绍过客户端发送请求到服务端。

其中任意一个编码不一致，都会导致表里的数据存入不正确的编码而产生乱码。

比如下面简单一条语句：

set @a = "文本字符串";

insert into t1 values(@a);

变量 @a 的字符编码是由参数 CHARACTER_SET_CLIENT 决定的，假设此时编码为 A，也就是变量 @a 的编码。

2 写入语句在发送到 MySQL 服务端之前的编码由 CHARACTER_SET_CONNECTION 决定，假设此时编码为 B。

3 经过 MySQL 一系列词法，语法解析等处理后，写入到表 t1，表 t1 的编码为 C。

那这里编码 A、编码 B、编码 C 如果不兼容，写入的数据就直接乱码。

二、客户端乱码

表数据正常，但是客户端展示后出现乱码。

这一类场景，指的是从 MySQL 表里拿数据出来返回到客户端，MySQL 里的数据本身没有问题。客户端发送请求到 MySQL，表的编码为 D，从 MySQL 拿到记录结果传输到客户端，此时记录编码为 E（CHARACTER_SET_RESULTS）。

那以上编码 E 和 D 如果不兼容，检索出来的数据就看起来乱码了。但是由于数据本身没有被破坏，所以换个兼容的编码就可以获取正确的结果。

这一类又分为以下三个不同的小类：

1)字段编码和表一致，客户端是不同的编码

比如下面例子， 表数据的编码是 utf8mb4，而 SESSION 1 发起的连接编码为 gbk。那由于编码不兼容，检索出来的数据肯定为乱码。

2）表编码和客户端的编码一致，但是记录之间编码存在不一致的情形

比如表编码是 utf8mb4，应用端编码也是 utf8mb4，但是表里的数据可能一半编码是 utf8mb4，另外一半是 gbk。那么此时表的数据也是正常的，不过此时采用哪种编码都读不到所有完整的数据。这样数据产生的原因很多，比如其中一种可能性就是表编码多次变更而且每次变更不彻底导致（变更不彻底，我之前的篇章里有介绍）。举个例子，表 t3 的编码之前是 utf8mb4，现在是 gbk，而且两次编码期间都被写入了正常的数据。

3）每个字段的编码不一致，导致乱码和第二点一样的场景。不同的是：非记录间的编码不统一，而是每个字段编码不统一。举个例子，表 c1 字段 a1,a2。a1 编码 gbk，a2 编码是 utf8mb4。那每个字段单独读出来数据是完整的，但是所有字段一起读出来，数据总会有一部分乱码。

三、LATIN1

还有一种情形就是以 LATIN1 的编码存储数据

估计大家都知道字符集 LATIN1，LATIN1 对所有字符都是单字节流处理，遇到不能处理的字节流，保持原样，那么在以上两种存入和检索的过程中都能保证数据一致，所以 MySQL 长期以来默认的编码都是 LATIN1。这种情形，看起来也没啥不对的点，数据也没乱码，那为什么还有选用其他的编码呢？原因就是对字符存储的字节数不一样，比如 emoji 字符 "❤"，如果用 utf8mb4 存储，占用 3 个字节，那 varchar(12) 就能存放 12 个字符，但是换成 LATIN1，只能存 4 个字符。

以上就是关于mysql下，某数据库中有中文，但因为某种原因，需要转换为latin1编码，如果不进行转码，将会出现乱码.全部的内容，包括:mysql下，某数据库中有中文，但因为某种原因，需要转换为latin1编码，如果不进行转码，将会出现乱码.、中文字符转码并存取mysql、Linux系统下MYSQL数据库中文数据乱码问题等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！