接着上一篇的势头，我再谈谈文献管理方面的应用软件或网站。

离线软件方面，我很早的时候，用过一段时间Reference Manager，当时我试用过Note Express，后来转到EndNote之后，就一直用到现在了。其实我很早就听说过EndNote，之所以一直用Reference Manager这么长时间，其实是懒得搬数据。所以我原本认为，其实用户转换文献管理软件的门槛是很高的，新软件很难抢到老用户。事实是不是这样呢，我没有统计数据，但我就很不明白为什么这么多人喜欢用Mendeley（Zotero我也用过，觉得不错，但是自从我浏览器改用Chrome之后我就不用Zotero了。我对它的喜爱不至于像某些人那样“装Firefox完全只是为了用Zotero）。

我还用过CiteULike、Connotea等网站，也都很快就弃用了。最近ACS出了一个ChemWorx，我也试用了一下。还有ReadCube我也用过。由于上述说的软件我很久都没用了，现在的情况是如何，我也不大清楚。

先讲所有这些应用最大的问题。EndNote的老用户往往已经把文献分成不同的Group了。所以，除非有软件能够直接破解EndNote的enl文件（以及同目录下的.data文件夹），实现“完美导入”，否则只要换软件，原来的Group分组信息就一定要丢失。我从读博士开始到现在，几乎所有文献，都放在一个库中，叫做gelation.enl（凝胶化）。它包括了流变学方面和胶体物理方面的所有文献。我也分了很多Group。不把这个库全导出来的话，我是没办法真正更换一个新的文献管理软件来工作的。但是，估计破解EndNote的文件格式是违法的，所以那些遵纪守法的老外是不会动这个心思，所以Group信息是永远无法顺利地导出的了。当然，有一些权宜的办法。例如对于Mendeley，可以先在EndNote里给同一个Group的文献添加相同的label（可以一次批量操作），再导出成bibtex格式。导入到Mendeley时，label项会导入成tag，然后在Mendeley中按tag来filter就可以看到原本属于同一个Group的文献了，这时再把这些文献搬到Mendeley相应的folder里。这个工作量至少是还可以接受的。

第二个也很普遍问题就是字符。这也应该是EndNote本身的错。EndNote导出的文本格式没有办法处理带重音符号的拉丁字母（很多人名会有，而且我还有一些文献是德语的），在EndNote软件里是正常显示的，但导出成文本文件之后就会变成一个中文乱码。这个中文乱码就会被导入到任何其他文献管理软件中。

第三个问题就是排序。除了Reference Manager、EndNote和NoteExpress（印象中）之外，其他的管理软件的排序功能都很局限。可能是因为我学过一点数据库原理，我明白无论界面多么傻瓜，文献管理软件其实都是一个数据库。一条文献包含这么多的属性，都是可以用来排序的，可以先按属性一升序、再按属性二降序、再按属性三升序……可是，除这三个软件之外的其他软件，最多只支持一按一个属性排序，而且只能在年份、作者、题目等属性中选择。

我在EndNote里是会使用Label项来进行一些标记。最常见的方式是标记了笔记本的页码。由于我阅读文献会有记笔记的习惯，在笔记本上会有页码。因此，一个文献记录，如果label上有个数字，就说明这个文献我看过，当时记过笔记，可以翻开笔记的相应页码来快速回顾，就不用重新看全文了；如果label上是空的，就说明我没有认真阅读过。所以，如果先对Label排个序，所有没记过笔记的文献就会全部集中在一起；再按年份排个序，这些没记过笔记的文献就会按年份来排序，我可以按此顺序一篇一篇地阅读和记笔记。

再有，由于我从读博开始的近三千篇文献都放在一个库中。如果我在阅读文献的时候，看到一篇被引文献我也需要，首先就要判断我是不是已经有这篇文献了，因为这么多篇文献我脑子是记不得某一篇我是否已经有了的。这时我就要在EndNote里，先后按期刊名、卷和页来排序，这样我一拉scroll bar就很快能够找到相同期刊相同卷的地方，有没有这一页就一目了然了。

总之，我会经常善用属性排序（而不是search）来查找定位，这也许是数据库的思维习惯使然。在添加条目操作时就具有一个杜绝重复和冗余的机制，而不是等产生了冗余之后再查重，这一原则可能也来自于数据库原理。因此对那些光有个search功能但排序功能很弱的文献管理软件我都觉得不适应。

有的文献数据库，文献多起来就反应慢，这是数据库引擎比较低级的反映，这些都比不上EndNote。

接下来就是关于PDF文件的管理问题。我一直都很不明白为什么这么多人会青睐这一功能。稍微有点常识的人就会知道这一功能是超出目前技术水平的，是绝对做不好的。首先，PDF文件有两种情况，一种情况就是里面的文字和图象都是基于元数据重新渲染的，另一种情况就是完全是未进行OCR的图象。要从PDF文件中识别出年份作者标题等信息，就需要PDF文件是前一种情况，能从中读出文字信息。而我这个人是喜欢看上世纪中叶的文献的，这些PDF都是影印版或者不良OCR版。再加上，这样的过刊很多时候网络数据库没有全文全限，我都是通过中科院文献互助系统从别的图书馆影印回来的，连字都是歪的，很难指往有什么OCR能把这些字识别好。光这一条满足不了就基本没戏了。我的库可能有一小半都是这种情况。ReadCube的设计似乎是要让用户完全依赖于从PDF识别来导入信息的。它的PDF导入功能确实比我想象中的要出色（主要是它充份利用了PubMed和Google Scholar的api，只要能从PDF中识别出任何最少的足够信息就直接可以在PubMed或Google Scholar上获得其他信息），但也难免有很多无法识别的PDF。ReadCube对这些PDF的处理方式是：仍然要用户从PubMed或Google Scholar上找到相应的条目来应用到PDF上，不允许自己输入！问题是有很多PDF，我自己在浏览器上Google Scholar是能查得到条目的，但是在ReadCube里面上Google Scholar却查不到。我猜这可能是Google Scholar的API有问题，但ReadCube就自愿受API问题的限制了？事实上，如果ReadCube对这类PDF可以支持像Zotero那样，访问文献网页抓取信息，就能够很好地解决此问题。除了PDF识别问题之外，识别出来的信息，也需要分类编排。学术文献是有很多种的，有Book、Book chapter、journal、patent、dissertation等等，这些都以是PDF文件。ReadCube的PDF识别好像默认了这个库里只能有journal这一类型的文献。可是至少我在写论文的时候我不会只引用journal。假如我工作完全用ReadCube，我要引用book的时候我岂不是要另外再打开我的EndNote？要求一个软件把PDF的文字识别出来之后，从排版和页眉页脚信息的特征识别出这是一个book还是book chapter还是journal还是dissertation，要求实在太高了，在可以预见的将来这一点都肯定是做不到的。无论如何，想要直接从PDF中识别信息，愿望很美好，但只要它不是接近100%可行，我就不想依赖它。为什么说这个愿望很美好而又要求它100%呢？因为，假如能从PDF中识别所有信息，我下载任何PDF就不用重命名，也不用记得同时导出RIS并导入到EndNote库中以保持一一对应了，以上的好习惯一旦不遵循，我的PDF文件夹将会是一团糟，这时就真的要完完全全地依赖数据库的PDF识别功能了。假如这一功能还不是100%有效，想想我有几千篇文献（和PDF），有个那么1%我就要手动输入十几篇了，还找不到源PDF在哪儿（因为命名全是乱的）。正因为如此，我根本就不会对文献管理软件的PDF自动识别管理功能抱有任何期望。像ReadCube这种完全依赖在这个功能上的产品，用处就相当于零了。

至于像Mendeley这样（以及EndNote X5以上版本），把已有文献数据跟硬盘中的PDF文件链接起来，可以直接在文献数据库中打开PDF文件来阅读的功能，我觉得也没必要。我对一个PDF阅读器产品本来就另有要求。首先，你有没有给我的电脑添加一个PDF打印机？如果没有，我岂不仍然要另外再装一个Acrobat Professional吗？假如我反正要装一个Acrobat Pro我有啥为何不在那儿看？Acrobat Pro支持画下划线（而不仅仅是高亮。我讨厌用高亮，偏好用下划线），而且还可以设置成波浪形的下划线。Acrobat还支画圈画框画箭头，有时一个公式我框一下，曲线有一个转折点我用箭头指一下。Acrobat还支持基本的窗口操作例如把同一个文件的窗口分成两半，这样的话，我上一半看正文，下一半看参考文献列表，那就不用在正文和参考文献头尾两种来回拖动了。如果可以的话我恨不得分三半，第三半看图，解决文中说“see Fig. 3(b)”结果Fig. 3(b)在下一页的问题。对于一些较新的PDF文件Acrobat还可以进行搜索。可以对PDF进行修改。例如有的paper会另外有一个supporting information文件，我就会把原文和supporting information合并为一个PDF文件，类似这样的操作在Acrobat里都可以解决。相比之下，那些文献管理器附带的PDF阅读功能实在是鸡肋，不明白为什么这么多人青睐，还作为一个卖点了。是不是像我这种哪类软件都成为深度用户的人就注定不幸福，可我也不见得是什么深度用户啊？果粉们不是说，品味高的用户必然会不约而同地选用苹果产品吗？我都没有选用苹果产品，用Windows用得这么爽，我一定是个坏品味的吊丝。为什么我仍然不满呢？我还要补充一下，学术文献的文件格式，不仅仅只有PDF文件。中文文献会需要用CAJViewer来阅读（就算期刊论文在CNKI可以选择下载为PDF格式，但博士和优秀硕士论文只能下载为.nh格式文件，必须在CAJViewer里看），光整合PDF阅读功能，也并没有100%。不是100%的话，我就不敢全依赖在它上面。

为什么我反复提到如果不是100%我就不敢全依赖呢？所谓“依赖”是什么意思呢？我在知乎上说过，我的工作思维是，先花专门的时间把规则设计和定义好，然后不加思索地按规则办；先编程再运行；先把CSS样式表设置好，再在编写HTML应用相应的样式；在Word里先把样式表定义好了，再按要求应用样式；而不是在打字的过程中，这里要加粗就加粗，那里要斜体就斜体。如有修改，就是修改定义，同时应用在所有实体上。按照相似的思维，在工作上，我一定要保证我所遵循的workflow是比较合理，能够适应大多数情况的，因为之后我做的事情就是不假思索地按照这个workflow去操作，就好像电脑严格按照已编好的程序来运行一样。因为，如果你的工作流程是每步都需要你看当时的情况来取舍，每步都要“随机应变”；工作流程也不固定，一会儿这样一会儿那样的话，你工作的需时就不好估计，你对你的工作进度就容易失去控制。你的workflow越是连个机器人都能完成，就越高效。越是要你时时处处都用模糊智慧去取舍、去回味、去条件判断分支，就越低效。所以如果一个工具给到我的功能不是100%能实现，这就等于在我的workflow中种下一个不可靠因素，一个隐患；我的workflow就定义得不严密。真按它那样长期运行，很容易就栽在这个隐患上，到时我就要很麻烦地脱离机器人状态，花时间研究解决临时发生的问题，很拖进度。

最后就说到整合Word软件了。但这个功能，我只有EndNote的经验，其他软件因为在以上指标都有各种不适之处，所以我都没有长期使用。但我有一个印象比较深，就是Mendeley和Zotero都采用CSL，采用啥我不管，CSL想开源通用化我原则上也欢迎。但你必须同时提供有一个可视化的编辑器以便用户自行定义citation style啊。现在我再搜，似乎有一些第三方的编辑器了，也不知道好不好用。但在我当年使用Zotero和Mendeley的时候，我是找不到第三方编辑器的，我也没有精力去自己学习CSL语法。

最后就是“云”功能。“云”的概念大家都欢迎。大家都希望啥都能“云”。但是中国大陆目前的带宽和访问国外网络的状况，限制了我们不是什么东西都适合“云”。就好像我上一篇关于笔记软件的文章那样，我的笔记，以及我的文献数据库，都可能会占用一个比较大的文件空间。同步这样的文件往往需要很长的时间。假如我使用一个软件，工作的时间花掉了，还要花额外的时间等它同步完毕，那谈何提高工作效率呢？如果我用Mendeley识别我的PDF文件夹（2734个PDF文件），它会死。如果不识别PDF文件夹光导入文献数据（2.8k+），倒还可以（反应还是会慢些），但如果仅仅是这样我干嘛不用EndNote呢？EndNote更明快，前面也提到了还有排序功能的问题。再者，我为何啥软件都要自带云同步？现在已经有dropbox了。就好像我在上一篇文章里谈到的那样，OneNote就算没有整合SkyDrive，由于它的笔记文件是很清晰可以找得到的，也可以按用户意愿来修改存放位置。想要云同步的话，把文件放在Dropbox里就解决了。但若像Evernote这样，数据存在神秘的文件组合里，你还真只能依赖它自己的云功能，碰上恰好它的服务器很烂你每次同步都很痛苦，那就只好跟它说88了。EndNote的数据库文件也不算复杂，一个.enl文件带一个同名的.data文件夹，我习惯把这个跟我的PDF文件放在Dropbox的同一个文件夹里，就一起同步掉了，何需EndNote自带什么同步功能？我知道还有个EndNoteWeb，但我从来不用。EndNote是收钱的软件，当然做得好。Mendeley和Zotero是免费的，很多人说这很难得，做得不好情有可原。事实上如果它做得好，收费我也不是不愿意花钱，做得不好，我才不管它是不是免费。既然做免费软件压力这么大，我觉得花时间开发网上同步的功能框架就是完全浪费时间。有Dropbox用户不会用吗？你只需要把数据库文件做得简单易找些就行了。多花点资金和精力放在软件本身的细节上岂不更好？

注：距离我上一次使用EndNote之外的其他文献管理软件，已经好一段时间了。在写完这篇文章之后我又调查了一下。Zotero有standalone版本和一个Chrome的connector，我也重新安装了新版本的Mendeley试用，同时我还了解到一个叫Docear的，以前没听说过，也安装试用。ReadCube还是老样子，就不再试用了。试用之后也许会有新的看法，也许不会。