我在ireport设计的时候，内嵌有网站logo图和一个条形码，结果调试的时候，图形都无法显示，查了网上资料
才知道是
request.getSession().setAttribute(
ImageServlet.DEFAULT_JASPER_PRINT_SESSION_ATTRIBUTE,
jasperPrint);
需要把jasperPrint放入session，这样，ireport的图片显示服务器才能访问jasperPrint对象，显示出相应的图像出来
ireport显示外部图片的具体步骤：
1.在web-bin设置ireport图片显示服务：
<servlet>
<servlet-name>ImageServlet</servlet-name>
<servlet-class>net.sf.jasperreports.j2ee.servlets.ImageServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ImageServlet</servlet-name>
<url-pattern>/servlets/image</url-pattern>
</servlet-mapping>
2.设置ImageServlet.DEFAULT_JASPER_PRINT_SESSION_ATTRIBUTEsession
request.getSession().setAttribute(
ImageServlet.DEFAULT_JASPER_PRINT_SESSION_ATTRIBUTE,
jasperPrint);
3.设置图片servlet服务的路径：
exporter.setParameter(
JRHtmlExporterParameter.IMAGES_URI,
"/servlets/image?image=");
今天中午在http://news.ycombinator.com/news看到一篇文章标题：
Saved 10 billion DNS queries per month by disabling DNS Prefetching (pinkbike.com)
禁用DNS 预读取能节省每月100亿的DNS查询
顿时吸引了我的注意力。
首先作者说了自己最近因为DNS查询数比之前增加了4亿个，逼着要订一个每个月1600美元的DNS查询服务
然后又说了什么叫DNS 预读：
DNS prefetching is a fairly recent (added in Safari 7 months ago) enhancement to all the major browsers. After a page loads, the browser looks at all the hosts in the links on the page and in the background proceeds to issue DNS queries to resolve those hostnames.
大意就是浏览器为了加快域名DNS解析速度，会对网页的所有链接先做域名解析
为了证明是浏览器预读所导致作者网站一个月增加800%的DNS查询，作者一一排除了导致增加DNS查询个数的其它因素：
1.DNS TTLs
2.Lots of links/images on other sites（被其他网站盗链）
3.Misconfigured internal services hitting the DNS
然后用Dynect platform平台得出一个作者网站的DNS各种数据统计图，然后与本网站每秒动态网页生成的次数做对比，发现多处了120的DNS查询；也就是每秒多出120次DNS查询是无意义的
然后终于剑指浏览器的DNS预存取技术
然后举例证明，讲了一大堆反思的话，最后说好在可以使用meta 可以设置禁止DNS的预存。
但是我翻遍整个网站，都没有看看怎么设置DNS，只好查看作者网页的源代码
才发现，禁止的代码：<meta http-equiv="x-dns-prefetch-control" content="off" />（作者说测试过程IE8/9没有DNS预读取行为）
不过，浏览器DNS预读其实也是为了我们点击链接的时候省了解析DNS的时间，算是提速吧；除了作者网站动不动就上百评论链接带来的
DNS查询浪费，平常网站一个页面不超过数十个链接，也就没必要禁止DNS预读了。
刚刚发现关于这篇文章的很多有趣的评论：http://news.ycombinator.com/item?id=2306319
编写java web的程序，不可避免都要处理编码问题，最常见的问题就是中文乱码
大概的思路就是重新编码为gbk或者gb2312，分两种情况
一是get和post形式
二是AJax 形式
第一种：GET和POST，取决于你的页面编码，如果你的页面编码为iso8859_1
使用：String str= new String(req.getParameter("str").toString().getBytes("iso8859_1"), "GBK");
或者 String str= new String(req.getParameter("str").toString().getBytes("iso8859_1"), "GB2312");
但是，这里要注意，必须保证你的页面编码也是iso8859_1的，因为，上面的代码的意思是先将你的字符串变为iso8859_1字节流，
然后再转化为GBK编码，如果你页面传过来的编码是utf-8，那么按照上面的方法就会出现：???乱码
你页面是utf-8的，就要使用如下编码：
String str= new String(req.getParameter("str").toString().getBytes("utf-8"), "GBK");
或者 String str= new String(req.getParameter("str").toString().getBytes("utf-8"), "GB2312");
总之get post 原则很简单，页面什么编码就转化什么字节流转化编码
第二：Ajax传值
这个比较麻烦，据测试，不同的浏览器有不同的对中文编码，怎么办呢？
我们可以采用js的encodeURI()进行统一的编码，然后在后台进行统一的解码
对应的java解码代码：
str= java.net.URLDecoder.decode(str, "UTF-8");
当然，因为他是utf-8编码，所以也可以采用第一种get post 介绍的方法解码(据测试，用 String(req.getParameter("str").toString().getBytes("utf-8"), "GB2312")解码js的encodeURI()时，会出现乱码，所以还是老老实实的使用java.net.URLDecoder.decode(str, "UTF-8");)
不好意思，刚刚查了资料，上面讲的Get方式有错：
Tomcat对于GET请求并不会考虑使用request.setCharacterEncoding方法设置的编码，而会永远使用iso-8859-1编码，而这位朋友使用的正好是GET请求，因此，tomcat将会使用iso-8859-1将提交的字节转换成字符串。
所以，对于使用get方式传值的时候，统一使用String str= new String(req.getParameter("str").toString().getBytes("iso8859_1"), "GBK");当然，前提是你服务器是tomcat