??xml version="1.0" encoding="utf-8" standalone="yes"?>
Everything的安装文件仅?34KBQ语a?73KB。别看n材小Q查找效率那是刚刚地Q安装之后,一q行Q包含了21万个文g的数据库徏立好了,?.4MBQ运行界面,是q么单:
q个y的东西,q可以支持正则表辑ּ的查找。但是,它只能根据文件名查找Q不是全文烦引的Q否则也不会q么yQ。但是,q已l够了。还有一些其他的高选项Q比如它提供一个简单的HTTP的服务器Q可以远E搜索和下蝲文g。总而言之,q东西,直就是键盘流的救世主啊!
下蝲地址Q?a >http://www.voidtools.com/download.phpQ安装包和语a包都在这里下载就可以了?/p>
现在的应用中Q文件下载的功能是很常见的。通常的做法是Q文件被存放在服务器的某个\径,然后由应用去d文gQ再通过讄响应头来让浏览器q行响应的动作。如果希望浏览器能够识别文g名,通常的做法是讄响应头中的Content-Disposition属性:
response.setContentType("application/octet-stream");
response.addHeader("Content-Disposition", "attachment; filename=xxx.xls");
如果要能够让IE正确的处理中文文件名Q则需要对中文文g名进行UTF-8~码Q?br>response.addHeader("Content-Disposition", String.format("attachment;filename=%s", java.net.URLEncoder.encode("中文.xls", "UTF-8")));
~码后的“中?xls”ؓQ?E4%B8%AD%E6%96%87.xls”?/p>
通常Q这U模式是没有问题的,但是如果文g名很长,׃出现“无法下载文件”的错误?/p>
l过查找资料Q在IE6上存在这L问题Q微软的文档Q?a >http://support.microsoft.com/kb/816868?LN=en-usQ中_
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.
也就是说Q对于Content-Dispositionq个响应_IE6仅能处理150字节左右Q再长了处理不了了。对于如何解册个问题,微Y的原文中也是闪烁其词Q说是有一个HotfixQ但是又说需要进一步测试…?/p>
如何解决问题呢?试在Web上放|一个很长中文名得文Ӟ然后直接在IE6地址栏中输入q个文g的全地址Q下载、直接打开都是正常的。因U情况下Q服务器l出的响应中不包含Content-DispositionD,估计是浏览器发现q是一个二q制,然后将URL中后面的部分当做文g名,所以文件名的处理都是浏览器在本地完成的Q所以就避免了上面文中提到的BUG。(此处U属猜想Q?/p>
所以,解决的思\如下Q?br>1. 在页面上生成的附仉接中Q包含附件的ID信息以及文g名。例如:<a href="/web/attachmentDownload/id/attachmentName.zip">附g</a>
2. 在服务器端做一个ServletQ映到路径 /attachmentDownload/*
3. Servlet获取到请求的URLQ解析出附g的ID信息及文件名
4. Servlet讄响应?response.setContentType("application/octet-stream") Q或者设|成附g对应的真实MIME-TYPE也可以。但是不讄Content-Disposition
5. ҎIDd文gQ向响应中写入文件流
6. flush
试了一下,是有效的一个办法。但是ؓ马觉得q个解决办法奇怪的很?直有点不像正思hcȝ思维方式?_-|||
p样吧Q神马都是Q云!
作ؓ一个IT民工Q咱不能说ؓ了一个传说中好看的文字渲染就去花大把的银子来C台Mac Book玩儿。嗯Q另外,我认识的人里面,买得起Mac Book的,基本上拿到货的第一件事儿就是找人给装一套Windows XPQ?/p>
无意间在众软g看到一个东东,叫做MacType的,很可能很多h都知道,是俺孤陋了。这个MacType是做啥子的呢?很简单,是在Win32上模仿Mac OS的文字效果。于是乎Q就?a target="_blank">MacType的官|下载一份儿来玩玩,免费的哦Q一开始用q个东西吧,q真是有点不习惯那种发虚的感觉。但是先不管他什么感觉,用上两天再说……两天之后Q再xMacType使用Windows 7的本渲染引擎,发现竟然有点不习惯Windows那种有点qӆ的ClearType了!
来一张对比图片吧
感受一下吧~~~~
遗憾的是QMacType对于宋体字的渲染不是很合我的胃口Q也可能是因为没有找到合适的讄。慢慢研I一下吧~~
初步判断肯定是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>
但是q是看不出问题。实在是百思不得其解了Q只好查看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)
......
看v来,是在试解析L域名/地址信息。可是我配置的是IP地址啊,为啥q去解析Q先不管q些了,先在本地hosts文g中配|一下LDAP服务器的别名吧。配|完本地hosts文g之后Q测试,一切OK了?/p>
回想hQ因为我的机器和试环境应用L上都有LDAP服务器的别名配置Q所以没有出现连接慢的问题,而新来的同事的hosts文g是干q净净的,所以,杯具?#8230;…
//------------------------------------
分析了Spring-ldap的代码以及关键的cInetSocketAddressQ过E大概是q样的:
spring-ldap的LdapContextSource会把讄的属性url的gQldap://和端口之间的字符串当做主机名Q注意,是当做主机名Q是String对象Q不是地址Q传入给LdapClientd立和LDAP服务器之间的q接。而LdapClient通过层层调用之后Q最l通过构造器InetSocketAddress(String hostname, int port) 创徏了InetSocketAddress对象?/p>
在JDK的文上关于InetSocketAddress(String hostname, int port)有如下描qͼ
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.
无需再解释什么了……
回头xQ介lspring-ldap的文章也好,CZ代码也好Q基本上都是在url上写域名Q很见写地址的,看来Qspring-ldap是鄙视IP地址的方式访问LDAP服务器的了?/p>
环境列表Q?/p>
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
先停止应用,然后两个文g都修ҎQ再启动应用卛_生效