Oracle库采用的是ascii编码，也就是英文字符集库。java通过jdbc查询出来如何转码？
new String(str.getBytes("ISO-8859-1"), "GBK")此方法已试过，转码失败。。。
ASCII 码不支持多字节的字符嘛，保存的过程可能已经失真了而无法还原。
Oracle 文档上是说它会自动转换字符，但：
有额外时间开销，可能有些数据丢失。
数据丢失的情况出现在：当原来的 GBK 中文 Windows 中的字符（一个汉字）在 US7ASCII 字符集中不存在时会被替换成一个点位符（一般是问号或与目标语言相关的字符），也就是我们说的乱码。
从这句话看，Oracle 在保存我们的数据时就已经错了，再去读取时是无法还原的。
因此为了让我们的数据正常地保存和还原，需要自己来编码数据。
直接用 "汉".getBytes("ASCII") 只拿到了一个字节，很明显，这是错误的结果 63 是指问号？这个测试是说如果我们给一个”汉“字，Oracle 当成 ASCII 去解码的话它把一个问号保存在数据库中。
使用 ASCII 7bit 当中间缓存字符集，我们无法保存汉字编码的 8bit 数据，最终显示成问号，这步已经失真了。这里面我们要想到我们的 GB2312 或 UTF8 这样的字符集本身都是假设一个字节的最高位 (8bit 中的第1个 bit）是有特殊意义的，当我们用 US7ASCII 是它忽略掉这个位只处理后面7-bit 的。
再试下用 ISO-8859-1 8-bit 做中间缓存字符集，我们看到它能保证数据依然是8bit 未失真，我们能准确地还原出来。
从上面的测试看出来，如果数据库是 ISO-8859-1 这种 8 bit 字符集的话，它是能通过代码：
stmt.setString(1, new String(name.getBytes(), "ISO-8859-1"));来保存，最后在读取的时候：
来还原的。但是很不幸的是 US7ASCII 字符集是没办法无损地保存汉字的，因此我们需要自己来编码那些像名字地址这样的有中文的数据，这里假设我们是用 GB2312 这种双字节的 16-bit，换成 US7-ASCII（每字节只有7-bit 有意义)，需要3个字节，如果是 GBK 的话，你需要把它改一改，如果你想让程序保存所有出现在 Unicode 中的字符的话，那就用5字节 (int 32位的，32 = 7bit * 5 把一个 int 表示的 Unicode code point 整数保存下来就好了，保证它能处理全地球上所有已经编码成 unicode 的字符：
String us7ascii = null;
int codePoint = name.codePointAt(0);
int decoded = 0;
{
PreparedStatement stmt = null;
byte[] encoded = new byte[3];
encoded[2] = (byte) (codePoint & 0x7F);
encoded[1] = (byte) ((codePoint >> 7) & 0x7F);
encoded[0] = (byte) ((codePoint >> 14) & 0x7F);
us7ascii = new String(encoded);
stmt.setString(1, us7ascii);
}
{
ResultSet rs = null;
// for single byte, us7ascii is same as utf8, encoding is optional
byte[] encoded = rs.getString(1).getBytes("US-ASCII");
decoded |= encoded[0] << 14;
decoded |= encoded[1] << 7;
decoded |= encoded[2];
String read = new String(new int[] { decoded }, 0, 1);
System.out.println("汉字：" + name + " => code point(" + codePoint + ") => US7-ASCII (" + us7ascii + ") => "
+ read);
}
输出如下，注意，在数据库它已经不是原来的样子，像是加密一样，所以我们直接用 SQL 查看数据库时是不正确的：
你可以考虑把你的列改成 nvarchar2 试下，看它是否正常。
这样做看起来很奇怪对吧，不如我们直接把包括汉字的列当成 blob 算之类的二进制类型来保存算了，这样反正更简单，只是这些办法都没办法再通过 SQL 客户端来查数据确认你的程序正确，只能通过程序来编解码。
追问AMERICAN_AMERICA.US7ASCII这个是我所用库的编码
追答看上去 7-bit 的字符集没办法保存 8-bit 的字符集中的字符。汉字在 GB2312 和 UTF8 这种字符集中都是把每个字节的最高位设定为特殊用途来识别“哪几个字节凑在一起是一个汉字”。但 US7ASCII 这个 7-bit 的字符集的处理方法就是“只知道有后面7-bit 是有意义的” 而忽略掉那个最高位，因此无法准确的还原汉字，只有字母数字和常见英文标点符号才能正常地处理。
追问意思是没办法咯。
追答我的理解是 US7ASCII 不能用来正确地保存汉字，我们至少要求8bit 的 ISO-8859-1 (Latin - 1) 这种字符集（虽然它也是单字节的字符集，但它能完整地保持所有8个bit位上的信息而不丢失让事后可以无损地还原出来）。
在 US7ASCII 中只有字母数字和常见英文标点符号才能正常地处理。比如 ASCII 中才有的字符的最高位都是0，但当有汉字和字母混合在一起时，每个汉字对应的多个字节的高位都是1 而不是0这就让程序知道以0开头的是单字节的字母和标点数字，而以1开头的是汉字。当 ASCII 7-bit 在处理时会忽略掉这个规则，它在假设所有的都是以0开头的。
在前面你看到
new String(new String("汉".getBytes(), "US-ASCII").getBytes("US-ASCII"))得到的是全是63 （63代表问号）；而当我们换成：
new String(new String("汉".getBytes(), "ISO-8859-1").getBytes("ISO-8859-1"))就正常了。
因为字符集编码规则都是一样，用 C++ 还是用 Java 结果是一样的。尝试换 OCI 驱动试试它是 native 的，但理论上说按 ANSI 8-bit ASCII 就正常的，或许这是客户端能看到汉字的原因。
另外，如果你的数据库原来本身是 US7ASCII 应该是可以无损地转换成 ISO-8859-1 的，因为这个转换是不丢失精度的，不会导致数据转换出错，因为你原来的数据只有7bit 的字符嘛，根本就没有那种 ASCII 码介于 128 到 255 之间的字符。就好像把一个 byte 能转换成 int 但反过来不成立一样的道理。或许考虑让数据库管理员把已经存在的数据库字符集转换成 ISO-8859-1，这不会导致数据库磁盘使用量增加（都是单字节的，而且是无损地转换）。
管理员可以考虑把一个数据库从 US7ASCII 导出再导入到另一个 Latin 1 的实例中：
本回答被提问者采纳AMERICAN_AMERICA.US7ASCII数据库字符集，plsql直接查询库中，是正常的汉字，通过javajdbc查询出来就是乱码的。
追答你用的是Orcale 么，那就不用考虑字符集的问题啊，你把sql 在数据库里 试试，JDBC 不涉及字符集啊，你从 DAO 到Service 到action 逐层排查
本回答被网友采纳