先说说我遇到的问题：我们公司用了CDN服务，在按照上面的方法配置好Gzip后，不通过CDN，直接用Fidller或者FireFox Firebug看页面信息，都能看到已经通过Gzip压缩过了，但是在Linux下面使用wget、curl等 工具查看同样的页面信息时，却发现没有压缩。这个问题一直没有解决。最后在MetaBase.xml第三段IIsCompressionSchemes中发现了三个很重要的参数：

• HcNoCompressionForHttp10
• HcNoCompressionForProxies
• HcNoCompressionForRange

它们的默认值分别是：

• HcNoCompressionForHttp10="TRUE"
• HcNoCompressionForProxies="TRUE"
• HcNoCompressionForRange="FALSE" 

当把HcNoCompressionForHttp10的值设置成FALSE时，wget与curl就可以看到页面已经被gzip压缩了。

由此分析：虽然wget与curl在页面返回信息中写着其使用了http1.1，但实际上它们实际仍然在使用http1.0。禁止为http1.0启用压缩设为否，就可以解决这个问题了。

FCKeditor是使用非常广泛的HTML编辑器，本文从 ASP.NET 的使用场景对 FCKeditor 与 FCKeditor.NET 的配置、功能扩展（如自定义文件上传子目录、自定义文件名、上传图片的后期处理等）、以及安全性进行初步的阐述。

希望能帮助有同样需求的同仁节省一点时间；也希望各位能指正其中的不足。谢谢。

一、自定义 FCKeditor 的 BasePath

BasePath 即FCKeditor在网站中的相对路径，默认值是 /fckeditor/，最好在Web.config appSettings中对其进行配置：

这样做有诸多优点：

1. 开发环境与生产环境不同，开发环境一般是http://localhost/xxx.com/这种情况下FCKeditor就得放在一个虚拟目录http://localhost/fckeditor/中，若涉及多个网站的开发，而各网站的FCKeditor有差别时，这样显然不是最优；
   而且因为物理目录结构与逻辑目录结构不同，也会有发生错误的隐患；
   而如果采用Web.config的配置，就可以在开发环境采用不同的配置，FCKeditor的物理路径与生产环境保持一致；
2. 当升级FCKeditor时，只需要将新版本的FCKeditor放在相应版本号的目录里，修改一下配置即可。这样可以解决因为静态资源的客户端缓存问题，不同用户出现不同的错误的问题；
3. 可以直观地看到自己的FCKeditor的版本号。

二、配置文件上传的目录

FCKeditor的文件上传（如图片上传）目录可以通过Web.config appSettings进行配置，如：

也可以在 /FCKeditorBasePath/editor/filemanager/connectors/aspx/config.ascx 中进行配置，但我建议 FCKeditor 目录中的内容能不改就不改（fckconfig.js除外），这样日后升级可以放心地替换即可。

三、自定义文件上传的子目录的格式

我们知道，一个文件夹下面不能存放过多的文件（据称Windows下面的目录下2000为阈值），否则对该目录的访问会严重影响I/O性能。而FCKeditor的文件存储是在单一的一个目录进行的。我对FCKeditor进行了扩展，可以在Web.config appSettings对存储目录的格式自定义，如：

========================================
以今天的日期为例：这样产生的文件上传子目录格式为：2008/10-21/。
年月日格式的目录可以随意组合，如：

这样产生的文件上传子目录变成了2008/10/21/

========================================
还可以针对不同登录的用户，采用不同的上传子目录
Web.config 修改上传子目录的配置，增加%u表示不同用户使用基于其标识不同的上传子目录

<add key="FCKeditor:FolderPattern" value="%u/%y/%m/%d/"/>

FCKeditor_2.6.3\editor\filemanager\connectors\aspx\config.ascx 中增加获取当前登录用户标识的逻辑

public override void SetConfig()

{

#region Bochuh's Modification

    // Identifier for logined user

    // Leave blank for default user upload folder

    LoginedUserIdentifier = "44"; // 这里替换成获取当前登录用户表示的代码

#endregion



// ……此文件中原来的代码

}

这样可以对不同用户，根据其登录后的标识（一般是用户ID），来使用不同的目录进行存储，如：7394/2008/10/21/（7394是当前登录用户的ID）

参考：

• %u   代表 当前登录用户的标识
• %y    代表 当前时间的年份
• %m    代表 当前时间的月份
• %d    代表 当前时间的日

四、自定义文件上传的文件名格式

FCKeditor对文件名的处理规则是：如果当前目录下没有重名文件，则上传后的文件名与用户PC上的文件名一致；若存在n个重名文件，则加入用户PC上的文件名是Example.xxx，上传后的文件名变为：Example(n).xxx

我的项目里要求对用户上传的文件名变成Guid的格式，所以我对FCKeditor也做了扩展，在Web.config appSettings可以对上传后文件的格式自定义，如：

这样的文件名如：a299e63a-7d2d-493d-bbb9-99162ef5b6b8.gif

参考：

• %guid    代表 一个新的guid字符串
• %fnl    代表 源文件名的小写
• %fnu    代表 源文件名的大写
• %extl    代表 源文件扩展名的小写
• %extu    代表 源文件扩展名的大写

五、对上传图片进行缩放处理

用到FCKeditor图片上传功能的场景中，很多是内容的发表。内容中往往不需要几千像素大小的图片，比如我的项目中，文章区域最宽也就560像素，所以我做了一个扩展，在Web.config appSettings中可以对图片的最大宽度进行自定义：

有了这段配置，上传后的图片的宽度都控制在了560像素及以内

六、自定义上传后图片URL中的域名

为了加快页面的渲染，我们可以把图片等静态资源放在一个独立的域名当中。但FCKeditor默认的图片上传后URL是相对路径，如图：

我增加了这个扩展，在Web.config appSettings可以配置上传后图片URL的域名，如：

如图：

七、解决上传文件名含有中文的文件时提示 "invalid file type" 的问题

这个问题只需要在Web.config中增加一段配置即可解决：

注意：

1. responseEncoding是网站的默认编码
2. FCKeditor_2.6.3是FCKeditor的BasePath

八、FCKeditor的安全性

在FCKeditor的2.3.2版本里，曾有一个漏洞，可以通过 /editor/filemanager/browser/default/connectors/aspx/connector.aspx 往服务器上传任意文件，我的网站就曾经中招。

2.6.3虽然暂未发现类似的问题，但一般情况下用不到的文件最好还是删除比较好：

1. FCKeditor BasePath 根目录中除了保留：
   1. /editor
   2. /fckconfig.js
   3. /fckpackager.xml
   4. /fckstyles.xml
   5. /fcktemplates.xml
   6. /license.txt
   外，全部删除
2. /editor/filemanager/中除了保留：
   1. /connectors/aspx/config.ascx
   2. /connectors/aspx/upload.aspx
   外，全部删除
3. 删除 /editor/_source/
4. /editor/filemanager/connectors/aspx/config.ascx 的 CheckAuthentication() 方法中，增加验证用户是否登录的逻辑

注意：以上措施仅适用于ASP.NET的网站，其他语言版本的网站未考虑。

附：基于FCKeditor.Net_2.6.3修改后的源码

SOURCE: http://files.cnblogs.com/zhubo/FCKeditor.Net_2.6.3_20081111.rar
BIN(.NET 2.0): http://files.cnblogs.com/zhubo/FredCK.FCKeditorV2_20081111.rar

1. 对以下文件的指定行进行了修改，
   /FileBrowser/Config.cs  line 45, 116, 169
   /FileBrowser/FileWorkerBase.cs  line 68, 98, 110, 125, 278
2. 所有修改的地方均包含在名为 "ZhuBo's Modification" 的代码块中，也可以通过搜索整个项目中的 "ZhuBo's Modification" 快速看到改动的地方，方便自己的扩展（比如可以设定图片的最大高度）

更新 at 2008-11-11

新增可选的根据用户标识让不同用户使用独自的图片上传子目录，参见上文中“三、自定义文件上传的子目录的格式”的更新部分。

新的源码与dll文件也已更新。

日志的列表与分页分别会在下面的代码里：

1<div id="entryList">
2   <div style="line-height:100px;">正在加载日志数据</div>
3</div>
4<div class="item-info">
5   <div id="pageText"></div>
6</div>

经FireBug的分析，发现实际的日志列表内容是由：http://zouhengfu.blog.sohu.com/action/v_frag-ebi_c223f68792-pg_2/entry/ 提供的

在这个URL中，从左到右：

在做搜狐博客抓取时可以参考。

定义一个用户控件：CssGlobal.aspx：

1<link rel="stylesheet" type="text/css" href="http://demo.com/CSS/Global.css?v=yyyyMMddv" />

1<%@ Register Src="~/CssGlobal.aspx" TagName="CssGlobal" TagPrefix="uc1" %>
2
3<head runat="server">
4    <title>Title</title>
5    <uc1:CssGlobal ID="CssGlobal1" runat="server" />
6</head>

以后凡是有Global.css的更改，只需要修改用户控件CssGlobal.aspx中Global.css的URL即可

对于JS、图片等其他静态资源，我们也可以用同样的方法实现良好的版本控制

本方案的缺点

1、无法在“设计”视图里看到实时的效果。不过如果美工与程序分离的不错的情况下，相信这不是大的问题；

——《精通ASP.NET程序设计 Programming Microsoft ASP.NET》第12章

如上面所述，我们在修改配置文件Web.config时，因为所有页面都会重新编译，会导致短暂的服务中断。这里有一个方法可以避免：

将常用且有可能发生改变的配置都放在appSetting节中，如：

<appSettings>
    <add key="SMTPServerAddress" value="0.0.0.0"/>
</appSettings>

Web.config中appSettings节有个属性：configSource，这个属性可以指定一个存储appSettings的外部文件路径（只支持相对路径），而这个外部文件的修改是不会引起页面的重新编译的，同时它的改动也能立即被ASP.NET运行库检测到。可谓一举两得。

Web.config中的appSettings的配置：

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <appSettings configSource="Settings\WebAppSettings.config" />
</configuration>

外部文件Settings\WebAppSettings.config的内容：

<?xml version="1.0" encoding="utf-8"?>
<appSettings>
    <add key="SMTPServerAddress" value="0.0.0.0"/>
</appSettings>

?xml version="1.0" encoding="utf-8"?><appSettings>

    <add key="SMTPServerAddress" value="0.0.0.0"/></appSettings>

*注1、Web.config配置文件

• Opening 开始
  • 女士优先：Google第一位女工程师介绍讲座的概要
• Open Social
  • 三个重要概念
  • 幕后英雄
  • Open Social之我见
  • Google对Open Social的发展态度
• Lunchtime
  • 看看人数的盛况吧
• Clound Computing 云计算
  • Google Gears
    • 通过Web App的几个弱点看Google Gears能给我们带来什么激动人心的功能
  • App Engine
    • 这是云计算的核心，这一节可以看到云计算具体是怎么使用的
• Ending 结尾
  • Google合作伙伴中的SNS网站
  • 值得一看的是奥体中心的疑似曲棍球国家队训练场景
• 总结
  1. 英文很重要！
  2. 云计算很强大！
  3. OpenSocial现阶段很脆弱！

期待已久的Google Developer Day 2008终于召开了，可惜去晚了，没有拿到绿色的来宾胸牌，少了个留念的东西，不过也没关系，能了解到Google最新的技术及其应用，并一睹这些技术幕后英雄的风范才是此行的目的。

Opening 开始

刚开始是一个全部讲座内容概要，由Google第一位女工程师主持，女士优先嘛：）

我对OpenSocial和云计算很感兴趣：OpenSocial很有可能对价值中国的社区发展起到非常大的促进作用；而云计算很有可能成为未来中小企业，甚至是大企业Web开发的一个平台，从而根本上能解决Web开发面临的各种性能瓶颈、性能调优、硬件成本问题。

OpenSocial

接下来就直接奔赴OpenSocial分会场：

Open Social的主讲Chris Schalk很风趣，长得很像Microsoft的Steve Ballmer，讲起来身体一颠一颠的，且PPT遥控器时而在身前切换，时而在身后切换，时不时说一句半生不熟的英文，逗得满场欢笑。

OpenSocial有几个很重要三个概念：

1、Container 容器
每一个有会员的网站都可以说是一个容器，容器，顾名思义，就是容纳东西的器皿，这里的容器容纳的就是会员，以及会员没产生的内容，还有会员之间的关系，这是每一个SNS网站赖以生存的根本，或者说是SNS网站的全部。

2、Web Developer 网站开发者
为什么Google要推OpenSocial？这还得从FaceBook的成功说起，Facebook成功地把自己的网站会员、会员产生的所有内容，会员之间的关系开放给开发者，开发者们开发了许许多多的有意思或有用的小程序，让Facebook成为了仅次于Myspace的第二大社交网站，Google与Microsoft竞购Facebook失败后，就推出了OpenSocial。由此可见，没有有了WebDeveloper，OpenSocial就没有任何存在的意义

3、Web Users 用户
从Google推OpenSocial的背景能看到，用户、用户产生的内容、用户之间的关系是Web Developers开发的“素材”，没有用户，没有用户产生的内容，Web Developers会面临巧妇难为无米之炊的困境。

利用OpenSocial，我们可以很简单地实现像FaceBook那样的接口，让有能力、有兴趣的开发人员进行开发，让网站本身的数据“活”起来，更为重要的是，因为OpenSocial接口的统一性，以价值中国为例：在价值中国做好的小程序，可以很简单地添加到任何一个符合OpenSocial标准的网站！

在我看来，现阶段，在中国的推广还不容易，还只能停留在一个概念的阶段，中国的程序员水平不低，但普遍生活压力过大，大部分公司也不提倡程序员花费太多精力在非公司业务上，程序员们自然没有时间来开发各种丰富的应用，缺少了上面提到过OpenSocial三大重要概念中的一个，怎么可能做好呢？

Open Social是由Google发起的，但Google更希望它能独立于Google运作，由开源社区来主导，演讲结束后的一个提问涉及到的Open Social的功能问题，产品经理的回答就表明了这一点：他说我们要由社区里的开发人员决定是否要增加这个功能，你也可以加入我们的社区，一起改进。

OpenSocial幕后英雄

右侧是OpenSocial的产品经理，左侧的职务不清楚，他们的名字都忘记了，很抱歉。

SNS展望（个人意见）

我们现在我们可以想象，未来的SNS，将不再需要我们记住需要去哪个网站，应该是随时、随地、随设备、随便哪个入口，可以获取到任何我们需要的内容，这一天，不远了。有人说过：最好的技术是感觉不到它的存在；那么最好的SNS，就是不需要去特定的网址，整个互联网却都是他的踪迹。

Lunchtime 午餐时间

参会的人真多，偌大一个餐厅，都得分批进入，看看餐厅入口的盛况吧：

午餐还算不错，除了2荤1素，还有一个琵琶鸡腿，外带一瓶鲜橙多，参会时的水、软饮料也是不限量供应，这比起Google公司员工的待遇来说，当然还是差一截，但对于我们这些参会的人来说，很少有会议能提供这么好的条件。

Cloud Computing 云计算

Google Gears

Chris Prince的Google Gears演讲令人印象深刻

我们对Google Gears的印象大多都停留在离线功能上，但它的功能远不止这样，Chris通过Web App的几个Pain Point（直译为痛点，叫弱点应该更合适）来介绍了一下Google Gears的功能：

Pain Point #1：启动一个Web Application要多做一些本不该的工作
比如我们要浏览价值中国的解读频道，我们需要：

1、打开浏览器；
2、输入价值中国网址或者在收藏夹中打开价值中国
3、点击解读频道的链接进入，完成

使用Google Gears，我们可以很方便地给一个Web App生成快捷方式，想象一下，在桌面上点击价值中国解读频道的快捷方式，是一种多么酷的体验！

Pain Point #2：Web Application的通知方式不够友好
我们一定很熟悉警告框、确认框等常见的通知方式，使用Google Gears，我们可以很简单地实现下图的通知方式，注意：这不是用在Web页面里面用HTML代码构造的通知样式，而是像Gtalk那样，有新邮件时桌面的通知方式，Logo，格式等都可以自定义。

Pain Point #3：上传多个文件难以置信地乏味
我们应该都有过在网页中需要上传多个文件的时候，一个一个地浏览、选择；使用Google Gears，我们可以很轻松在资源管理器里面选择所有我们需要上传的文件，然后只需要点击一下上传，即可：

Pain Point #4：上传大文件（比如50M）失败时，只能从头开始
这更是很常见的问题了，像土豆等需要上传大文件的网站，基本都是开发了自己的客户端实现断点续传等高级上传功能，利用Google Gears，我们不需要投入资源来开发客户端，只需要短短几行代码，断点续传、进度显示等功能就可以实现：

Pain Point #5：总要输入自己的地址不太舒服
这里的Demo可以用Amazing来形容，举个例子，比如我们想找附近的咖啡馆，一般情况下，我们需要搜索“咖啡”在“亚运村国际会议中心（Google Developer Day 2008 会址）”附近。使用了Google Gears后，我们只需要输入想要找的内容，当前地址就由Google Gears代劳了：

注意：图中的搜索框只输入了“咖啡”，而结果却精确地显示了北四环中路附近的咖啡馆，很让人震惊！

最后的展望中，有一点值得注意：Open Source, Open Standards，像Open Social一样，Google已经不想只有自己进行Google Gears的开发了，而是要将其开源，标准开放，由开源社区来一起努力，这一点，从Google Gears的官方网站上已经初露端倪：

注意：Gears前面的 Google去掉了！

App Engine

App Engine是Google Cloud Computing (云计算)的一个重要组成部分。

我很喜欢App Engine 的 Logo，像一个飞机引擎，让企业的业务能在App Engine的帮助下飞翔

要做一个好的网站，我们得考虑多种因素：带宽够不够？CPU资源怎么样了？要不要分布式存储？要不要数据库集群？成本是不是太高？预算够不够？……，这真不是一件容易的事情：

有了Google App Engine，我们就不需要考虑那么多，只需要专心把程序写好。

Google App Engine已经把网站需要的绝大多数功能都准备好了，只需要我们写很少的代码调用：

1、数据存储：我们不再需要担心数据库的性能问题了，使用Google提供给我们的BigTable，无论多大的数据量，都没有问题；使用Gql进行数据查询，速度像Google搜索那么快！
2、图片存储、处理：我们有时候会需要把会员上传的图片进行裁剪、缩放都处理，Images API is ready!
3、邮件发送：会员注册或者其他需要通知会员的时候，会需要给用户发邮件，Mail API is ready!

还有Memcache API、URL Fetch API、Users API，如此强大、可定制的功能，真的可以满足绝大部分需求了，我在构想，如果可以，价值中国都可以直接搬到Google App Engine上！

我的确是想过把价值中国搬到Google App Engine上，由此，我问了这一节的演讲者Tom Stocky两个问题：
问：Google App Engine是否可以使用自己的域名，而不是现在的xxx.appspot.com？
答：可以，要先注册Google Apps（企业应用套件）
问：Google App Engine是否有对中国带宽的优化？
答：没有，因为中国用户还不够多，需要继续观察，最终得出优化方案。

很遗憾，不能让我们的用户“享受”很慢的速度，所以，现在还不是时候，再加上现在只有Python Runtime，而价值中国使用的技术是ASP.NET，迁移的成本技术是无法承受的，这就作为自己的一个研究吧。

费用

Google App Engine这么强大的功能，竟然是免费的，但并不是无限制的免费，只要符合以下条件，就可以享受永久的免费：
 
存储空间低于500M、带宽每天低于2G（平均每秒流量不超过23k）、PV每月低于500万（平均每天PV不超过16万6千）

至于超出限制后如何收费，请随时关注http://code.google.com/appengine/terms.html的“4. Fees for Use of the Service”

Advanced Gadget and UI Development Using Google AJAX APIS

听了几乎一天的英文（以前也听过，看原版电影，但好歹有字幕，理解起来不那么吃力），接下来Derek Collison的Advanced Gadget and UI Development Using Google AJAX APIS我已经觉得听起来很吃力了，没有太多的感受，对Derek Collison的辛苦表示歉意。

Ending 结尾

准备走的时候，看到了不少Google的合作伙伴展台：

这里仅是SNS网站部分

值得一提的是天际网，我们一直觉得天际网只做社交太单薄，但如果他们能和Google合作，我们假想一个应用场景：假设在Google里面搜索人名，如果天际有此人，优先显示天际的话，这对天际规模扩大的作用是不可估量的！价值中国需要加油了！

还有和金山展台的那位男士聊了一小会儿（姓名、职务不详），本来是去打听WPS和Google合作的小道消息，结果没有打听着，但有一点共同认识，协同办公在国内的需求还不大，他们最新版的WPS就没有考虑开发协同办公的功能。Google Doc支持协同办公，但在中国用的人不多；Office也支持，但需要安装额外的SharePoint服务，这在中国的应用也很少。中国，要加油！

在去车站的路上，在奥体中心曲棍球场正好有人在训练，不知是不是曲棍球国家队：

总结

1、英文很重要！

世界上百分之八十的知识是用英文写成的，虽然中国的人多，说汉语的人数不见得比说英文的人少，但由于世界分工不同，英语国家从事的工作更多是知识创造、知识出口，只要这种分工一天不变，英语的地位就不会变。

都说大学毕业和四级挂钩没有道理，我部分同意，有些领域的确是使用到英文的地方不多，但就我自己的专业：计算机来说，我手脚并举支持教育部这样的规定，这样可以强制我们去学习英文，不管应试教育是不是对学习英文有多大帮助，在日后的工作中学了总比不学进步要快。

可喜的是，到场的各位英文水平都不错，很多人都踊跃地使用英文提问，不管说的是chilish还是什么，起码能让人听懂，并达到基本的交流目的。中国的应试教育导致了大部分人的口语不好，但这并不妨碍我们利用一切机会去练习我们的口语，不能觉得说的不标准丢人，老外们操着一口蹩脚的中文是好学，我么操一口蹩脚的英文一样是好学，我觉得参加这样的会议很大的好处之一就是联系英文，尤其是听力与口语。

2、云计算很强大！

参会以前，对云计算的理解一直不够深入，。参会完毕，有了一定的进步。我们先想想云的特点：漂亮，可随意组合成随意大小，看上去是个整体。Google的云计算也是这样，他提供理论上没有限制的计算、存储能力，供理论上无限的客户在他的平台上部署不同的应用程序，Google给我们提供的就是云，随意组合、整体、漂亮！

听老板说过，Intel不支持云计算，他当然不支持，如果有了Google这样的基础计算服务提供商，可以精确地调整CPU的使用，CPU的销量必然会大幅下降（这基于一个事实，我们每个人的个人电脑，每个网站的服务器，CPU大部分时间都是很少的资源使用，虚拟化技术的盛行就是这个原因）。

有人说过，世界上最终只剩下两家互联网技术企业，我相信其中一家肯定是Google，Google的角色就是一切互联网企业的技术基础，和我一起来参会的同事讲得好，Google就是卖石油的，所有的汽车都离不开石油（现阶段，新能源应该能解决这个问题），所有的互联网企业都离不开Google，Google就是在卖他的技术，在出口他的技术，这一点，又印证了我的第一点总结，起码短时间内，中国很难成为知识出口国，中文也就别想在世界占重要地位，我们还是静下心来，学习英文，学习先进的知识吧。

3、OpenSocial现阶段很脆弱！

和天极网负责市场的一位女士聊天谈到了OpenSocial，我感觉他们支持OpenSocial的营销意义远远大于实际使用价值。包括其他实现或者已经实现了OpenSocial标准的中国网站，我想都是这样。OpenSocial在中国，目前还只是一个伟大的梦，它总有实现的一天，但不会是现在，也不会很快，原因我前面有提到（参照OpenSocial一节），这依赖于中国的软件行业的健康发展，依赖于企业对于技术管理的改善，甚至依赖于CPI的涨幅不要那么高。我们都希望有OpenSocial这样的标准盛行，除了努力做，别无他法。

“天道酬勤”，与所有奋战在SNS网站开发的一线“指战员”们共勉！

对于数据量大（索引文件大于50M）的索引，尽量不要用索引中的字段排序，要用索引ID排序（INDEXORDER）；两者效率相差近10倍，以下从内存占用与CPU处理时间来比较：

内存占用比较：
图一：使用整型的唯一标识字段排序


图二：使用索引ID（INDEXORDER）排序


拿占用内存最多的对象来比较：我们可以看到，图一比图二多 2,900,766 bytes（索引文件大小：61M）

处理时间比较：
使用整型的唯一标识字段排序的处理时间是3016ms，使用索引ID（INDEXORDER）排序的时间是303ms

解决方法：
为了能够使索引ID倒序等同于时间倒序：在建立索引时，就要按照数据的时间顺序建立，老的数据先索引，新的数据后索引
倒序代码：

//以下代码基于Incubating-Apache-Lucene.Net-2.0-004-11Mar07

Hits hits = searcher.Search(query, new Sort(new SortField(null, SortField.DOC, true)));

参考：http://markmail.org/message/noq4kohwipx5wzfo#query:Sort.INDEXORDER+page:1+mid:4ydkfgdj6kbvhq2x+state:results