社区
Java SE
帖子详情
resultset.getString(Long Varchar字段)乱码
realcbb
2009-12-18 06:00:44
数据库: db2
用con.prepareStatement(sql, ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE)的话,取出来的long varchar 类型字段是乱码;
如果用con.prepareStatement(sql), 取出来就是正确的.
请问有没有谁碰到过这个问题, 指教一下.
...全文
913
9
打赏
收藏
resultset.getString(Long Varchar字段)乱码
数据库: db2 用con.prepareStatement(sql, ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE)的话,取出来的long varchar 类型字段是乱码; 如果用con.prepareStatement(sql), 取出来就是正确的. 请问有没有谁碰到过这个问题, 指教一下.
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
9 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
realcbb
2009-12-23
打赏
举报
回复
[Quote=引用 8 楼 crazylaa 的回复:]
引用 6 楼 realcbb 的回复:
引用 5 楼 crazylaa 的回复:
引用 4 楼 realcbb 的回复:
最新测试, 把ResultSet.TYPE_SCROLL_SENSITIVE换成TYPE_FORWARD_ONLY就不会出现乱码.
请教大家!
sensitive,数据库的更改会影响当前结果集且游标可以来回定位。。。。forward_only不会,且只能前滚。
是否数据库的更改影响了结果集的metadata?
楼主改为TYPE_SCROLL_INSENSITIVE看看有没有乱码?如果没有乱码就表明数据库更改导致结果集MetaData有更改,可能是DB2的一个bug。。
TYPE_SCROLL_INSENSITIVE也是乱码, 与CONCUR是否可以并发更新没有关系.
只要不是TYPE_FORWARD_ONLY就是乱码...但只是LONG VARCHAR字段是乱码, 普通的VARCHAR还是正确的.
ps: 另外我很奇怪的是, 数据库的编码是GBK, 配置weblogic连接池和数据源的时候都没有设置数据库编码的地方, 这样取出来的数据居然不需要转码. 难道不指定数据库的编码就是按照系统默认编码来算?
那就是只要游标滚动,LONG VARCHAR就会乱?奇怪之至,打IBM的800电话去问下,db2的Long Varchar是否对汉字进行了特殊处理还是怎么的。。
ps:连进DB2/Oracle等数据库不需要像mysql、postgres一样指定编码的,它会以数据库的编码方式返回数据给你。
[/Quote]
IBM 800电话是什么? 8008101818?
可是如果数据库编码是UTF-8, 而我在查询sql中有where中文条件, 它也能识别吗? 还是需要我在构造sql的时候进行转码?
crazylaa
2009-12-22
打赏
举报
回复
[Quote=引用 6 楼 realcbb 的回复:]
引用 5 楼 crazylaa 的回复:
引用 4 楼 realcbb 的回复:
最新测试, 把ResultSet.TYPE_SCROLL_SENSITIVE换成TYPE_FORWARD_ONLY就不会出现乱码.
请教大家!
sensitive,数据库的更改会影响当前结果集且游标可以来回定位。。。。forward_only不会,且只能前滚。
是否数据库的更改影响了结果集的metadata?
楼主改为TYPE_SCROLL_INSENSITIVE看看有没有乱码?如果没有乱码就表明数据库更改导致结果集MetaData有更改,可能是DB2的一个bug。。
TYPE_SCROLL_INSENSITIVE也是乱码, 与CONCUR是否可以并发更新没有关系.
只要不是TYPE_FORWARD_ONLY就是乱码...但只是LONG VARCHAR字段是乱码, 普通的VARCHAR还是正确的.
ps: 另外我很奇怪的是, 数据库的编码是GBK, 配置weblogic连接池和数据源的时候都没有设置数据库编码的地方, 这样取出来的数据居然不需要转码. 难道不指定数据库的编码就是按照系统默认编码来算?
[/Quote]
那就是只要游标滚动,LONG VARCHAR就会乱?奇怪之至,打IBM的800电话去问下,db2的Long Varchar是否对汉字进行了特殊处理还是怎么的。。
ps:连进DB2/Oracle等数据库不需要像mysql、postgres一样指定编码的,它会以数据库的编码方式返回数据给你。
liuahuilele
2009-12-22
打赏
举报
回复
db2不懂 所以顶好了
realcbb
2009-12-22
打赏
举报
回复
[Quote=引用 5 楼 crazylaa 的回复:]
引用 4 楼 realcbb 的回复:
最新测试, 把ResultSet.TYPE_SCROLL_SENSITIVE换成TYPE_FORWARD_ONLY就不会出现乱码.
请教大家!
sensitive,数据库的更改会影响当前结果集且游标可以来回定位。。。。forward_only不会,且只能前滚。
是否数据库的更改影响了结果集的metadata?
楼主改为TYPE_SCROLL_INSENSITIVE看看有没有乱码?如果没有乱码就表明数据库更改导致结果集MetaData有更改,可能是DB2的一个bug。。
[/Quote]
TYPE_SCROLL_INSENSITIVE也是乱码, 与CONCUR是否可以并发更新没有关系.
只要不是TYPE_FORWARD_ONLY就是乱码...但只是LONG VARCHAR字段是乱码, 普通的VARCHAR还是正确的.
ps: 另外我很奇怪的是, 数据库的编码是GBK, 配置weblogic连接池和数据源的时候都没有设置数据库编码的地方, 这样取出来的数据居然不需要转码. 难道不指定数据库的编码就是按照系统默认编码来算?
crazylaa
2009-12-21
打赏
举报
回复
[Quote=引用 4 楼 realcbb 的回复:]
最新测试, 把ResultSet.TYPE_SCROLL_SENSITIVE换成TYPE_FORWARD_ONLY就不会出现乱码.
请教大家!
[/Quote]
sensitive,数据库的更改会影响当前结果集且游标可以来回定位。。。。forward_only不会,且只能前滚。
是否数据库的更改影响了结果集的metadata?
楼主改为TYPE_SCROLL_INSENSITIVE看看有没有乱码?如果没有乱码就表明数据库更改导致结果集MetaData有更改,可能是DB2的一个bug。。
realcbb
2009-12-21
打赏
举报
回复
最新测试, 把ResultSet.TYPE_SCROLL_SENSITIVE换成TYPE_FORWARD_ONLY就不会出现乱码.
请教大家!
realcbb
2009-12-18
打赏
举报
回复
但的确是这样的,其他什么都没改,所以很奇怪...
crazylaa
2009-12-18
打赏
举报
回复
[Quote=引用楼主 realcbb 的回复:]
数据库: db2
用con.prepareStatement(sql, ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE)的话,取出来的long varchar 类型字段是乱码;
如果用con.prepareStatement(sql), 取出来就是正确的.
请问有没有谁碰到过这个问题, 指教一下.
[/Quote]
这这这。。。加了两个参数应该不会对编码有影响啊。。。难道IBM又捣鬼了???
第一个参数指定 ResultSet 的类型。其选项有:
TYPE_FORWARD_ONLY:缺省类型。只允许向前访问一次,并且不会受到其他用户对该数据库所作更改的影响。
TYPE_SCROLL_INSENSITIVE:允许在列表中向前或向后移动,甚至可以进行特定定位,例如移至列表中的第四个记录或者从当前位置向后移动两个记录。不会受到其他用户对该数据库所作更改的影响。
TYPE_SCROLL_SENSITIVE:象 TYPE_SCROLL_INSENSITIVE 一样,允许在记录中定位。这种类型受到其他用户所作更改的影响。如果用户在执行完查询之后删除一个记录,那个记录将从 ResultSet 中消失。类似的,对数据值的更改也将反映在 ResultSet 中。
第二个参数设置 ResultSet 的并发性,该参数确定是否可以更新 ResultSet。其选项有:
CONCUR_READ_ONLY:这是缺省值,指定不可以更新 ResultSet
CONCUR_UPDATABLE:指定可以更新 ResultSet
kernll
2009-12-18
打赏
举报
回复
如果是这样,那么你的操作系统和你的数据库的默认的字符编码是不同的。或者说你用的框架有的方法是没有是使用字符编码来进行校验的。所以重载的方法也可能实现的检验方式是不同的。小小浅见。。。
SM4数据库
字段
加密实战:国密算法集成、中文编码优化与MyBatis深度整合
数据加密是保障数据安全的核心技术手段,其原理是通过特定算法将明文信息转换为不可读的密文,防止未授权访问。在数据库安全领域,应用层
字段
级加密技术能在不改变数据库基础设施的前提下,为敏感数据提供精细化的保护。国密算法SM4作为我国认可的商用密码标准,在金融、政务等对数据安全合规性要求极高的场景中具有重要价值。针对实际开发中常遇到的中文
乱码
、与ORM框架集成困难、密钥管理复杂等痛点,本文聚焦于构建一个增强的SM4数据库加密工具。该工具通过显式统一字符集处理彻底解决中文编码问题,并利用MyBatis TypeHan
oracle char 中文
乱码
,关于jsp连接oracle char类型数据显示问题
在jsp中连接数据库当定义stmt=con.createStatement(
ResultSet
.TYPE_SCROLL_SENSITIVE,
ResultSet
.CONCUR_READ_ONLY);时,数据库中char型
字段
,不管是中文英文数字,都显示不出来比如fff变成0x6666662020202020202020202020202020202020改成stmt=con.create...
MyBatis-Plus
字段
加解密实战:保障MySQL敏感数据安全
数据安全是应用开发的核心议题,尤其在处理用户手机号、身份证等敏感信息时,防止数据泄露至关重要。在应用层对敏感
字段
进行加密存储是一种常见的安全实践,其原理是在数据写入数据库前进行加密,读取时再解密,从而确保即使数据库被非法访问,敏感信息也不易被直接获取。这项技术的核心价值在于将安全策略与业务逻辑解耦,提升代码的可维护性和安全性。在实际的工程实践中,ORM框架如MyBatis-Plus通过其拦截器或TypeHandler机制,能够以声明式、无侵入的方式自动完成
字段
的加解密,极大地简化了开发流程。然而,实现过程中
MyBatis-Plus
字段
自动加解密实践:无侵入保护敏感数据
数据安全是应用开发的核心关切,尤其在处理用户隐私与金融信息时,数据库
字段
加密成为必备手段。其原理是在数据持久化过程中,对特定敏感
字段
进行透明转换,存储密文而业务逻辑操作明文。这项技术的核心价值在于以对业务代码无侵入的方式,在数据进出数据库的‘最后一公里’自动完成加解密,平衡了安全性与开发效率。它广泛应用于需要合规(如等保、GDPR)的用户敏感信息(手机号、身份证号)存储场景。本文聚焦于利用MyBatis-Plus的插件机制实现这一目标,其中**TypeHandler**是实现
字段
级透明处理的关键组件,而**
MyBatis TypeHandler与Interceptor实现数据库
字段
自动加解密方案
数据安全是软件架构设计的核心考量之一,敏感信息如手机号、身份证号的加密存储是常见需求。其原理在于通过加密算法(如SM4、AES)在数据持久化层对特定
字段
进行转换,确保数据在存储态为密文,而在应用层为明文,从而在不泄露信息的前提下保障业务功能。这项技术的核心价值在于实现安全与业务的解耦,将加解密这类基础设施职责从业务代码中剥离。典型的应用场景包括金融、电商等涉及用户隐私数据的系统。本文聚焦于利用MyBatis的TypeHandler(类型处理器)和Interceptor(拦截器)这两个扩展点,在SQL执行前后
Java SE
62,621
社区成员
307,251
社区内容
发帖
与我相关
我的任务
Java SE
Java 2 Standard Edition
复制链接
扫一扫
分享
社区描述
Java 2 Standard Edition
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章