我用的是JDK1.3，在操作数据库时中文出现乱码？？
请问各位大虾是如何处理的？？

转码就行
给你篇文章
ava 中文问题的表层分析及处理 
I. 取中文 
用 JDBC 执行 SELECT 语句从服务器端读取数据（中文）后，将数据用 APPEND 方法加到 TTextArea（TA） ，不能正确显示。但加到 List 中时，大部分汉字却可正确显示。  
将数据按"ISO-8859-1" 编码方式转化为字节数组，再按系统缺省编码方式 （Default Charracter Encoding） 转化为 STRING ，即可在 TA 和 List 中正确显示。   
程序段如下： 
dbstr2 = results.getString(1); 
//After reading the result from DB server，converting it to string. 
dbbyte1 = dbstr2.getBytes("iso-8859-1"); 
dbstr1 = new String(dbbyte1); 
在转换字符串时不采用系统默认编码方式，而直接采用" GBK" 或者 "GB2312" ,在 A 和 B 两种情况下，从数据库取数据都没有问题。 
II. 写中文到数据库 
处理方式与"取中文"相逆，先将 SQL 语句按系统缺省编码方式转化为字节数组，再按"ISO--8859-1"编码方式转化为 STRING ，最后送去执行，则中文信息可正确写入数据库。 
程序段如下： 
sqlstmt = tf_input.getText(); 
//Before sending statement to DB server，converting it to sql statement. 
dbbyte1 = sqlstmt.getBytes(); 
sqlstmt = newString(dbbyte1,"iso-8859-1"); 
_stmt = _con.createStatement(); 
_stmt.executeUpdate(sqlstmt); 
…… 
问题：如果客户机上存在 CLASSPATH 指向 JDK 的 CLASSES.ZIP 时（称为 A 情况），上述述程序代码可正确执行。但是如果客户机只有浏览器，而没有 JDK 和 CLASSPATH 时（称为 B 情况），则汉字无法正确转换。 
我们的分析： 
1.经过测试，在 A 情况下，程序运行时系统的缺省编码方式为 GBK 或者 GB2312 。在 B 乔 况下，程序启动时浏览器的 JAVA 控制台中出现如下错误信息： 
Can't find resource for sun.awt.windows.awtLocalization_zh_CN 
然后系统的缺省编码方式为"8859-1"。 
2.如果在转换字符串时不采用系统缺省编码方式，而是直接采用 "GBK" 或"GB2312"，则在 A 情况下程序仍然可正常运行，在 B 情况下，系统出现错误：  
UnsupportedEncodingException。 
3.在客户机上，把 JDK 的 CLASSES.ZIP 解压后，放在另一个目录中， CLASSPATH 只包含父 目录。然后一边逐步删除该目录中的 .CLASS 文件，另一边运行测试程序，最后发现在一千多个 CLASS 文件中，只有一个是必不可少的，该文件是： 
sun.io.CharToByteDoubleByte.class。 
将该文件拷到服务器端和其它的类放在一起，并在程序的开头 IMPORT 它，在 B 情况下程行 仍然无法正常运行。 
4.在 A 情况下，如果在 CLASSPTH 中去掉 sun.io.CharToByteDoubleByte.class ，则程序序运行时测得默认编码方式为"8859-1"，否则为 "GBK" 或 "GB2312" 。 
如果 JDK 的版本为1.2以上的话，在 B 情况下遇到的问题得到了很好的解决，测试的步骤屯希 兴趣的读者可以尝试一下。 
[/b]Java 中文问题的根源分析及解决[/b] 
在简体中文 MS Windows 98 + JDK 1.3 下，可以用 System.getProperties() 得到 Java 栽 行环境的一些基本属性，类 PoorChinese 可以帮助我们得到这些属性。 
类 PoorChinese 的源代码： 
  
public class PoorChinese { 
  
public static void main(String[] args) { 
  
System.getProperties().list(System.out); 
  
} 
  
} 
  
执行 java PoorChinese 后，我们会得到: 
  
系统变量 file.encoding 的值为 GBK ，user.language 的值为 zh ， user.region 的值挝?CN ，这些系统变量的值决定了系统默认的编码方式是 GBK 。 
  
在上述系统中，下面的代码将 GB2312 文件转换成 Big5 文件，它们能够帮助我们理解 Javva 中汉字编码的转化: 
  
  
  
import java.io.*; 
  
import java.util.*; 
  
  
  
public class gb2big5 { 
  
  
  
static int iCharNum=0; 
  
  
  
public static void main(String[] args) { 
  
System.out.println("Input GB2312 file, output Big5 file."); 
  
if (args.length!=2) { 
  
System.err.println("Usage: jview gb2big5 gbfile big5file"); 
  
System.exit(1); 
  
} 
  
String inputString = readInput(args[0]); 
  
writeOutput(inputString,args[1]); 
  
System.out.println("Number of Characters in file: "+iCharNum+"."); 
  
} 
  
  
  
static void writeOutput(String str, String strOutFile) { 
  
try { 
  
FileOutputStream fos = new FileOutputStream(strOutFile); 
  
Writer out = new OutputStreamWriter(fos, "Big5"); 
  
out.write(str); 
  
out.close(); 
  
} 
  
catch (IOException e) { 
  
e.printStackTrace(); 
  
e.printStackTrace(); 
  
} 
  
} 
  
  
  
static String readInput(String strInFile) { 
  
StringBuffer buffer = new StringBuffer(); 
  
try { 
  
FileInputStream fis = new FileInputStream(strInFile); 
  
InputStreamReader isr = new InputStreamReader(fis, "GB2312"); 
  
Reader in = new BufferedReader(isr); 
  
int ch; 
  
while ((ch = in.read()) > -1) { 
  
iCharNum += 1; 
  
buffer.append((char)ch); 
  
} 
  
in.close(); 
  
return buffer.toString(); 
  
} 
  
catch (IOException e) { 
  
e.printStackTrace(); 
  
return null; 
  
} 
  
} 
  
} 
  
  
  
编码转化的过程如下： 
  
ByteToCharGB2312 CharToByteBig5 
  
GB2312------------------>Unicode------------->Big5 
  
执行 java gb2big5 gb.txt big5.txt ，如果 gb.txt 的内容是"今天星期三"，则得到的文文件 big5.txt 中的字符能够正确显示；而如果 gb.txt 的内容是"情人节快乐"，则得到的文件 big5.txt 中对应于"节"和"乐"的字符都是符号"？"（0x3F），?
见 sun.io.ByteToCharGB2312 和 
附一个用于从数据库和网络中取出中文乱码的处理函数，入参是有问题的字符串，出参是问问题已经解决了的字符串。 
正如上例一样， Java 的基本类也可能存在问题。由于国际化的工作并不是在国内完成的，，所以在这些基本类发布之前，没有经过严格的测试，所以对中文字符的支持并不像 Java Soft 所声称的那样完美。前不久，我的一位技术上的朋友发信给我说 
 他终于找到了 Java Servlet 
中文问题的根源。两周以来，他一直为 Java Servlet 
的中文问题所困扰，因为每面对一个含有中文字符的字符串都必须进行强制转换才能够得到到正确的结果（这好象是大家公认的唯一的解决办法）。后来，他确实不想如此继续安分下去了，因为这样的事情确实不应该是高级程序员所要做的工作，他就?
出 Servlet 
解码的源代码进行分析，因为他怀疑问题就出在解码这部分。经过四个小时的奋斗，他终于于找到了问题的根源所在。原来他的怀疑是正确的， Servlet 的解码部分完全没有考虑双字节，直接把 %XX 当作一个字符。（原来 Java Soft 也会犯这幺低级 
 错误！） 
  
如果你对这个问题有兴趣或者遇到了同样的烦恼的话，你可以按照他的步骤对 Servlet.jarr 进行修改： 
  
找到源代码 HttpUtils 中的 static private String parseName ，在返回前将 sb（StrinngBuffer） 复制成 byte bs[] ，然后 return new String(bs,"GB2312")。作上述修改后就需要自己解码了： 
  
HashTable form=HttpUtils .parseQueryString(request.getQueryString())或者 
  
form=HttpUtils.parsePostData(……) 
  
千万别忘了编译后放到 Servlet.jar 里面。 
  
五、 关于 Java 中文问题的总结 
  
Java 编程语言成长于网络世界，这就要求 Java 对多国字符有很好的支持。 Java 编程语蜒允视α 计算的网络化的需求，为它能够在网络世界迅速成长奠定?坚实的基础。 Java 的缔造者 （Java Soft） 已经考虑到 Java 
附一个用于从数据库和网络中取出中文乱码的处理函数，入参是有问题的字符串，出参是问问题已经解决了的字符串。 
  
String parseChinese(String in) 
  
{ 
  
String s = null; 
  
byte temp []; 
  
if (in == null) 
  
{ 
  
System.out.println("Warn:Chinese null founded!"); 
  
return new String(""); 
  
} 
  
try 
  
{ 
  
temp=in.getBytes("iso-8859-1"); 
  
temp=in.getBytes("iso-8859-1"); 
  
s = new String(temp);  
}  
{   
System.out.println("Warn:Chinese null founded!");  
return new String("");   
}   
try   
{  
temp=in.getBytes("iso-8859-1");   
s = new String(temp);   
}   
catch(UnsupportedEncodingException e)   
{   
System.out.println (e.toString());   
}   
return s; 
}

简单地说，就是
从数据库中取出，如果是乱码，可以这样转：
msgTxt=new String (msgTxt.getBytes("ISO-8859-1"),"gb2312");//code convertation
如果是存入数据库成乱码，则
msgTxt=new String (msgTxt.getBytes("gb2312"),"ISO-8859-1");//code convertation

你用的什么数据库啊，一般设置jdbc驱动程序的属性就可以了，
比如mysql：
con_url="jdbc:mysql://"+ip+"/"+m_DB_Name+"?useUnicode=true&characterEncoding=GB2312";DriverManager.getConnection(con_url, m_DB_User, m_DB_Password);
如果是sql Server7
 con_url="jdbc:inetdae:" + ip + ":"+m_DB_Port+"?database="+m_DB_Name+ "&charset=GB2312";
如果是sql server2000就不存在中文问题。

我不知道你使用的是JAVA还是JSP。

我以前碰到JSP操作数据库的中文乱码问题。使用重新构造字符串的方法都不能解决问题。后来在控制面板的区域设置里面把区域设置成美国英语，然后去掉构造字符串的代码，中文问题就解决了。

其实我也觉得这样很奇怪，但是这样就能解决问题。呵呵。。。
希望能帮上你的忙。

用JDK1。3吗？
在DOS下，输入PDOS95
试试！