博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
使用JPA储存Text类型的时候 出现乱码的问题
阅读量:7155 次
发布时间:2019-06-29

本文共 984 字,大约阅读时间需要 3 分钟。

     以前遇到这类问题第一个反应就是觉得客户端和服务端的编码不一样导致的。所以一开始也是那么认为的。以为我们项目使用的是pgsql,默认的就是utf-8,然后我们使用了字符也是utf-8,并且还有一个问题就是说一般的string类型(数据库映射为varchar)显示的是正常的,然后我就有些抓不着头脑了,去google和百度都没有找到合适的答案。都没有解决。

   问题是我们在JPA项目中使用了@Lob注解。这个注解的解释是这样的:

@Lob 注解属性将被持久化为 Blog 或 Clob 类型。

  • Clob(Character Large Ojects)类型是长字符串类型,具体的java.sql.Clob, Character[], char[] 和 java.lang.String 将被持久化为 Clob 类型。
  • Blob(Binary Large Objects)类型是字节类型,具体的java.sql.Blob, Byte[], byte[] 和 serializable type 将被持久化为 Blob 类型。
  • @Lob 持久化为Blob或者Clob类型,根据get方法的返回值不同,自动进行Clob和Blob的转换。
  • 因为这两种类型的数据一般占用的内存空间比较大,所以通常使用延迟加载的方式,与@Basic标记同时使用,设置加载方式为FetchType.LAZY

但是很可惜,我明明是String类型的,但是还是乱码

@Lob    @Basic(fetch=FetchType.LAZY)    private String content;

,我们再去看数据库,发现数据库中的类型是text的,那估计应该是@Lob注解影响到了,也就是说我们要让数据库生成text类型的字段,但是同时又不能够使用这个注解,所以自然想到@Column中有一个columnDefinition属性,可以指定类型,那么ok,我们现在把@Lob注解去掉,改成

@Basic(fetch=FetchType.LAZY)    @Column(columnDefinition="TEXT")    private String content;

,然后我们再来看的时候发现,乱码就没有了。

转载于:https://www.cnblogs.com/zr520/p/5588441.html

你可能感兴趣的文章
关于跨域的what,why,how
查看>>
k8s :kube-apiserver 启动流程 - 2
查看>>
不使用任何额外变量判断回文数字
查看>>
配置永久生效(登陆shell和非登陆shell)、I/O重定向、Here Docunmet 此处文档、管道、tee...
查看>>
PHP设计模式- Decorator 装饰器模式
查看>>
密码提示强弱的正则表达式
查看>>
惨遭红帽弃用,MongoDB要凉凉了吗?
查看>>
停止过度设计,开发客户需要的软件
查看>>
混沌实践访谈:混沌工程和系统可观测性密不可分
查看>>
量子计算竞速时代,如何拨动时间的指针
查看>>
Gremlin发布混沌工程实验平台免费版,开放了“故障即服务”功能
查看>>
构建一个运行在Azure虚拟机上的MySQL Spring Boot应用程序
查看>>
面试算法实践与国外大厂习题指南
查看>>
新的UWP和Win32应用程序分发模型
查看>>
对自组织的实验
查看>>
微软宣布Azure Migrate和Site Recovery服务增强功能
查看>>
Nexus指南已经发布
查看>>
Scrapy入门程序点评
查看>>
MYSQL修改存储过程的访问权限
查看>>
# iOS 使用 InjectionIII 注入动态库实现快速调试
查看>>