数据库数据全是问号，怎么办？ (数据库存在表里的数据都是问号)

近来，很多数据库管理员经常会面对一个问题，就是在数据库中出现了大量的问号。这种情况通常发生在数据库中包含了一些非ASCII字符集的数据，如中文、日文、朝鲜文等，而且数据库所使用的编码格式不支持非ASCII字符。

在日常工作中，很多时候我们不可避免的需要在数据库中存储和处理不同语言的数据。而不同的语言有不同的字符和编码格式，这就给我们的数据库管理和数据处理带来了困难。本文将帮助您了解为什么数据库中出现问号，以及解决这个问题的方法。

一、为什么会出现问号

我们可以想象一下，在数据库中存储的数据就像是一本书，而这本书的内容是用特定的文字编写的。如果这本书用的文字不是常规的字母或数字，而是其他语言的特殊文字，那么在打开并读取这本书时，我们就需要借助一些工具，让计算机知道如何正确编码和解码这些特殊文字。

在许多情况下，数据库管理员会使用像UTF-8这样的标准编码格式，这种编码格式支持许多不同的语言和特殊字符。但是，如果我们的数据库使用的编码格式不支持某些特殊字符，那么在读取这些字符时，字符就会被转换成问号。

当我们遇到数据库中出现大量问号时，我们需要先确认问题的根源。最可能的原因是数据库的编码格式与输入的数据不匹配。当输入的数据包含数据库编码格式不支持的字符时，这些字符就会被转换成问号。

二、解决方法

为了解决数据库中出现问号的问题，我们可以尝试以下方法：

1、更改数据库编码格式

更改数据库的编码格式，以便支持输入数据中包含的特殊字符。UTF-8是一种常见的编码格式，可支持多种语言，并兼容大多数计算机平台。如果我们使用的数据库不支持UTF-8编码格式，我们可以尝试切换到支持该编码格式的数据库，并将数据从原始数据库转移到新数据库。

2、重新输入数据

如果我们无法更改数据库的编码格式或更改编码格式无效，我们可以尝试重新输入数据。在输入数据时，我们需要确保输入的字符与数据库编码格式兼容。为此，我们可以尝试更改数据源的编码格式，或者在导入数据时指定正确的编码格式。

例如，当我们从一个文本文件中导入数据时，我们需要确保文件的编码格式与数据库的编码格式相同。否则，导入的数据将可能包含大量的问号。

3、 使用工具转换数据

我们可以使用一些在线或本地的转换工具，将输入数据从原始编码格式转换为数据库支持的编码格式。这种解决方法比较简单，但需要确保转换工具可以正确识别和转换输入数据中的所有特殊字符。

4、 常规维护

除了以上方法外，我们还应该定期检查和维护数据库。例如，我们应该确保数据库对象（表、视图、存储过程等）不包含无法处理的字符，如果存在问题，应及时更正。

此外，我们还应定期备份数据库，以便在出现数据损坏或丢失的情况下能够快速恢复数据。

数据库中出现问号的问题可能会给我们的日常工作带来一定的困扰。为了避免这种情况的发生，我们需要在数据库的授权、配置和使用方面做好细节管理。在数据库编码格式上，我们应该选择支持多语言和特殊字符的编码格式，并定期进行维护和升级。这样才能确保数据库系统始终稳定运行，满足我们的业务需求。

相关问题拓展阅读：

• 数据库查询出来怎么是问号?
• mysql 数据库后台 乱码问题 全市问号 怎么办？

数据库查询出来怎么是问号?

把语句发上来看下

使用的编码最游伏好统哪脊一

有四处：

1.数据李磨渗库的编码

2. mysql_query(‘set NAMES XXXX’)

3. 文件的编码

4. header();

我找到了..把中文字符咐皮存入数据库前转换一下

String str=new String(“这里是你要插入的衡帆差中文文字”.getBytes(“ISO”),”GBK”);

再把str存轿好入数据库就可以了…

插入SQL不羡备段认识的字符

情况如下

1 简体和繁体的问题

2 从OFFICE中COPY过来的资料

3 从滚备其他软件中COPY过来的兄誉资料

T-SQL语句发上来撒～谁知道你是不是语句错误啦～

mysql 数据库后台 乱码问题 全市问号 怎么办？

最后用到的一句代码是：

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

一、P页面显示乱码

下面的显示页面(display.jsp)就出现乱码：

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

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

下面是一个提交页面(submit.jsp)，代码如下：

下面是处理页面(process.jsp)代码：

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

三、数据库连接出现乱码

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

四、数据库的显示乱码

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

public class Convert {

/** 把ISO码转换成GB2312

*/

public static String ISOtoGB(String iso){

String gb;

try{

if(iso.equals(“”) || iso == null){

return “”;

}

else{

iso = iso.trim();

gb = new String(iso.getBytes(“ISO”),”GB2312″);

return gb;

}

}

catch(Exception e){

System.err.print(“编码转换错误：”+e.getMessage());

return “”;

}

}

}

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

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

字符内码

每个国家（或区域）都规定了计算机信息交换用的字符编码集，如美国的扩展ASCII码、中国的GB、日本的 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，这需要系统在读取这些文件名时动态地将其转换为相应的语言编码。

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

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

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

不同开发平台的区别

1．Tomcat 4开发平台

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

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

2．Tomcat 3.x、Resin及Linux平台

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

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

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

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

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

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

P代码的中文处理

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

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

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

String name1=new String(request.getParameter(“user_id”).getBytes(“ISO8859_1”))。

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

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

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

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

处理方法实例

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

1．常见的字符转换方法

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

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

String keyword1=request.getParameter(“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 || s.length() == 0) {

return null;

}

byte buffer = new byte;