Everything的安装文件仅有334KB，语言包173KB。别看身材小，查找效率那是刚刚地！安装之后，一运行，包含了21万个文件的数据库就建立好了，才1.4MB！运行界面，就是这么简单：

　　这个小巧的东西，还可以支持正则表达式的查找。但是，它只能根据文件名查找，不是全文索引的（否则也不会这么小巧）。但是，这已经足够了。还有一些其他的高级选项，比如它提供一个简单的HTTP的服务器，可以远程搜索和下载文件。总而言之，这东西，简直就是键盘流的救世主啊！

　　下载地址：http://www.voidtools.com/download.php，安装包和语言包都在这里下载就可以了。

现在的应用中，文件下载的功能是很常见的。通常的做法是，文件被存放在服务器的某个路径，然后由应用去读取文件，再通过设置响应头来让浏览器进行响应的动作。如果希望浏览器能够识别文件名，通常的做法是设置响应头中的Content-Disposition属性：

response.setContentType("application/octet-stream");
response.addHeader("Content-Disposition", "attachment; filename=xxx.xls");

如果要能够让IE正确的处理中文文件名，则需要对中文文件名进行UTF-8编码：
response.addHeader("Content-Disposition", String.format("attachment;filename=%s", java.net.URLEncoder.encode("中文.xls", "UTF-8")));

编码后的“中文.xls”为：“%E4%B8%AD%E6%96%87.xls”。

通常，这种模式是没有问题的，但是如果文件名很长，就会出现“无法下载文件”的错误。

经过查找资料，在IE6上存在这样的问题，微软的文档（http://support.microsoft.com/kb/816868?LN=en-us）中说：

This behavior occurs because the content disposition header for the file stream is greater than approximately 150 bytes and the Latin character set is equal to 150 characters. This behavior may occur if the content disposition header is formatted with a non-Latin character set, such as Japanese or Russian.

For example, a 17-character content disposition header in the Japanese character set is 153 bytes because the UTF-8 encoding scheme uses 9 bytes to represent a single Japanese character, but it uses only 1 byte in the Latin character set.

也就是说，对于Content-Disposition这个响应头，IE6仅能处理150字节左右，再长了就处理不了了。对于如何解决这个问题，微软的原文中也是闪烁其词，说是有一个Hotfix，但是又说需要进一步测试……

如何解决问题呢？尝试在Web上放置一个很长中文名得文件，然后直接在IE6地址栏中输入这个文件的全地址，下载、直接打开都是正常的。因为这种情况下，服务器给出的响应中不包含Content-Disposition段，估计是浏览器发现这是一个二进制流，然后就将URL中后面的部分当做文件名，所以文件名的处理都是浏览器在本地完成的，所以就避免了上面文档中提到的BUG。（此处纯属猜想）

所以，解决的思路如下：
1. 在页面上生成的附件链接中，包含附件的ID信息以及文件名。例如：<a href="/web/attachmentDownload/id/attachmentName.zip">附件</a>
2. 在服务器端做一个Servlet，映射到路径 /attachmentDownload/*
3. Servlet获取到请求的URL，解析出附件的ID信息及文件名
4. Servlet设置响应头 response.setContentType("application/octet-stream") ，或者设置成附件对应的真实MIME-TYPE也可以。但是不设置Content-Disposition
5. 根据ID读取文件，向响应中写入文件流
6. flush

测试了一下，是有效的一个办法。但是为神马觉得这个解决办法奇怪的很？简直有点不像正常人类的思维方式了-_-|||
就这样吧，神马都是浮云！

作为一个IT民工，咱不能说为了一个传说中好看的文字渲染就去花大把的银子来买一台Mac Book玩儿。嗯，另外，我认识的人里面，买得起Mac Book的，基本上拿到货的第一件事儿就是找人给装一套Windows XP！

无意间在小众软件看到一个东东，叫做MacType的，很可能很多人都知道，是俺孤陋了。这个MacType是做啥子的呢?很简单，就是在Win32上模仿Mac OS的文字效果。于是乎，就在MacType的官网下载一份儿来玩玩，免费的哦！一开始用这个东西吧，还真是有点不习惯那种发虚的感觉。但是先不管他什么感觉，用上两天再说……两天之后，再关掉MacType使用Windows 7的本尊渲染引擎，发现竟然有点不习惯Windows那种有点干涩的ClearType了！

来一张对比图片吧

感受一下吧~~~~

遗憾的是，MacType对于宋体字的渲染不是很合我的胃口，也可能是因为没有找到合适的设置。慢慢研究一下吧~~

初步判断肯定是LdapTemplate做操作的时候花费了很长的时间。LdapTemplate的配置如下：

<bean id="contextSource" class="org.springframework.ldap.core.support.LdapContextSource">
        <property name="url" value="ldap://192.168.1.77:389/dc=cn,dc=earth"/>
        <property name="userDn" value="cn=root"/>
        <property name="password" value="tjmc123"/>
</bean>
<bean id="ldapTemplate" class="org.springframework.ldap.core.LdapTemplate">
        <property name="contextSource" ref="contextSource"/>
</bean>    
 

但是还是看不出问题。实在是百思不得其解了，只好查看Thread dump了，在这里花费了很长的时间：

"qtp22172629-23" prio=5 tid=0x1741d1d0 nid=0x1760 runnable [0x17f9e000..0x17f9fd68]
        at java.net.Inet4AddressImpl.getHostByAddr(Native Method)
        at java.net.InetAddress$1.getHostByAddr(InetAddress.java:842)
        at java.net.InetAddress.getHostFromNameService(InetAddress.java:532)
        at java.net.InetAddress.getHostName(InetAddress.java:475)
        at java.net.InetAddress.getHostName(InetAddress.java:447)
        at java.net.InetSocketAddress.getHostName(InetSocketAddress.java:210)
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:341)
        at java.net.Socket.connect(Socket.java:507)
        at java.net.Socket.connect(Socket.java:457)
        at java.net.Socket.(Socket.java:365)
        at java.net.Socket.(Socket.java:178)
        at com.sun.jndi.ldap.Connection.createSocket(Connection.java:346)
......

看起来，是在尝试解析主机域名/地址信息。可是我配置的是IP地址啊，为啥还去解析？先不管这些了，先在本地hosts文件中配置一下LDAP服务器的别名吧。配置完本地hosts文件之后，测试，一切OK了。

回想起来，因为我的机器和测试环境应用主机上都有LDAP服务器的别名配置，所以没有出现连接慢的问题，而新来的同事的hosts文件是干干净净的，所以，杯具了……

//------------------------------------

分析了Spring-ldap的代码以及关键的类InetSocketAddress，过程大概是这样的：

spring-ldap的LdapContextSource会把设置的属性url的值中，ldap://和端口之间的字符串当做主机名（注意，是当做主机名，是String对象，不是地址）传入给LdapClient去建立和LDAP服务器之间的连接。而LdapClient通过层层调用之后，最终通过构造器InetSocketAddress(String hostname, int port) 创建了InetSocketAddress对象。

在JDK的文档上关于InetSocketAddress(String hostname, int port)有如下描述：

Creates a socket address from a hostname and a port number.
An attempt will be made to resolve the hostname into an InetAddress. If that attempt fails, the address will be flagged as unresolved.

无需再解释什么了……

回头想想，介绍spring-ldap的文章也好，示例代码也好，基本上都是在url上写域名，很少见写地址的，看来，spring-ldap是鄙视IP地址的方式访问LDAP服务器的了。

环境列表：

Sun HotSpot JDK 1.5.0_05

Spring-ldap: 1.3.0

Spring: 3.0.4

config/cells/cell_name/applications/ear_name/deployements/app_name/war_name/WEB-INF/web.xml

先停止应用，然后两个文件都修改掉，再启动应用即可生效