2012年 二月 01日 周三 | tags: itext, java, code, -- (permalink)

这篇文章是很早之前写的,是我在去第一个公司的时候遇到的问题

这里说的IText中文处理问题,是指两种生成PDF文档是对中文处理的问题:

  1. 是直接通过从数据库查询或者自己拼接中文字符串生成PDF文档。
  2. 第二种是将一个HTML文档转换成PDF文档时的中文处理。

首先说第一种: 这种很简单,我们只需为加上这样一句:

BaseFont bf = BaseFont.createFont("STSong-Light","UniGB-UCS2-H",BaseFont.NOT_EMBEDDED);

在之后的给Document添加节点是为Paragraph设置字体时设置成BF就可以,如下:

document.add(new Paragraph("混沌之神", new Font(bf)));

源码:

/**
 * 生成PDF文件解决中文的例子
 *
 * @throws DocumentException
 * @author <b>Innate Solitary</b><br />
 *         创建时间:<b>2008-6-4 下午09:47:37</b><br />
 * @throws IOException
 */
public static void ...

2012年 一月 13日 周五 | tags: java, morphia, mongo, code, -- (permalink)

前天和昨天一直都在忙后台CMS树的优化和一些bug的修改,不过主要精力放在了树的优化上。

后台数据较多的树有两个,都是和视频相 关的,我们的树用的是dwz的树,但是这是一个同步树,也就是说,这个树是一次性取出数据,通过freemarker构建成html代码,然后在由dwz 渲染成树,在数据量小的时候还不觉得有什么,但是数据量一大就会发现,后台服务端数据查询还不用什么,但是dwz渲染那是一个慢啊,后来我一个同事找了个 jquery的一个异步树,然后由我来对树进行更换。

在换掉dwz的树之后发现,虽然加载数据的速度提升很大,但是在某些数据量略大的节点上依然会有查询很慢的问题,长一点的有要到7-8秒的时间。这样长的时间主要是因为3个方面:

  1. 第一个就是dwz的树是同步树,在接收完数据之后,才进行树的渲染,在数据量略微大的话,渲染的效率就很低,而且我们的树是5级的,五层循环下来,基本上要循环过百万次,在firefox和chrome下测试发现,虽然chrome的js渲染速度快,但是效果并不明显
  2. 第二个就是mongodb的问题,但是问题不在与mongodb上,而在于我们的查询上,几个树加载慢的表都冗余了大量的数据,这些数据在树的显示上都没有用,一个树需要的只有一个id和name两个字段,所以在查询上带出了太多的无用数据。
  3. 第三个就是在网络传输上,这个问题其实和第二个是一样的,从mongodb带出了太多的无用数据,而且是一次性全部数据都查寻来,这样就会造成数据越多查询越慢,网络的传输上压力就越大,到最后就是服务器崩掉 ...

2012年 一月 05日 周四 | tags: java, morphia, code, mongo, -- (permalink)

昨天中午临吃午饭前,我对系统的业务功能代码进行重构之后,准备测试一下,通过就去吃饭,但是发生了一个让我很意外的问题,就是在存储的时候,系统 报出来,类型转换异常(java.lang.ClassCaseException)或者是这么一个错误信息(object is not an instance of declaring class),很纠结因为之前这里测试都好好的,而且给内容组,视频组和测试组部署的测试环境,还在正常运行,一时想不通那里出了问题。

在 经过几次debug跟踪之后发现,每次报错都是在,存储FreeCourse和FreeVideo两个类是发生的问题,我仔细回忆 了,从上次重部署测试环境到出问题之间修改的代码,中间都没有什么问题,只有一个地方和其他人写的代码略有不一样,就是:其他人在写list类型的属性 时,默认是给空值的,但是我会给他们new一个size为0的ArrayList,这是我的一个喜欢,是为了避免出现一些因为疏忽而发生的问题,但是如果 只是这样不应该会有问题。

我 又仔细的看了一边相关业务代码和实体类的代码,所有代码中都没有问题,但是有一点和其他人的不同,就是我的FreeVideo下有个字段 videoInfos他的类型是 ...


« Page 2 / 2