如何将 Outlook PST 文件内容导入 Gmail

如何将 Outlook 的备份文件( PST 格式)的内容，比如邮件、联系人等信息导入 Gmail 中? 这是我长期以来的一个需求。过去工作中使用 Outlook 备份的邮件，如果查找或者回溯的话，非常不便利。

因为微软的 Outlook PST 文件格式长期以来没有公开(现在似乎可以得到了)，所以可以使用的第三方迁移工具非常之少，后来采用了 Google 的工具，加上一次转发，基本达到目标。现将可行的解决方案分享一下。

首先要明确的是目前没有可靠的工具能直接把 Outlook PST 文件导入 Gmail，只得选择一个间接的办法来完成:

PST 文件(源数据) -> Google Apps for Business (中间邮件帐户中转) -> 转发到 Gmail (目标邮件)

Google 提供有 Google Apps Migration for Microsoft Outlook ，但这个工具只能导入到 Google Apps for Business 帐户中(如果你有的话)，既然能从 PST 导出，剩下的事情就好办了。

可以免费申请使用 Google App 面向个人与中小团队这个版本(参考地址) ，单个帐户的空间大小是 10GB 。

具体如何申请略过，假定你现在已经有了一个 Google Apps 帐户，在这个帐户中创建一个邮件地址；在迁移之前，还需要在 Google App 的 Domain Settings -> User Settings 里，选中 Enable provisioning API 选项，以便激活 Email 迁移 API 功能(参考此图)。

在前面创建的邮件中设置一个邮件转发(Forwarding)，转发到标准 Gmail 帐户(目标帐户)中。

下载并且安装 Google Apps Migration for Microsoft Outlook，然后输入前面在 Google Apps 创建的邮件用户名和密码，之后选择 PST 文件，定义要迁移哪些内容。迁移开始进行，迁移的速度取决于你的网络到 Gmail 服务器之间的速度。检查目标 Gmail 帐户邮件进来的情况。

一些注意事项：Google Apps 邮件的转发规则最好选择转发后删除，否则单个邮件 10GB 的空间可能不够用。而标准 Gmail 帐户可以购买额外的空间，价格也不贵。如果是 Google Apps 帐户购买就太贵了，承受不起。

在目标 Gmail 邮件地址中要配置好各种过滤器，否则大量涌进来的邮件可能带来较大的干扰。

或许个别人也有和我类似的需求，记录一下，希望对你有所参考。如果哪位知道更便利可行的办法，请留言告知。

–EOF–

更新: 有朋友留言说采用「PST 直接挂到 Outlook 里，Gmail 用 IMAP 方式也挂到 Outlook 里」然后同步，这个方式对正在使用 Outlook 的人是有用的(我已经不用 Outlook 了)，另外，要求内容相对较少，如果大量数据，基本上不太适合。

用常识做产品

新浪微博前段时间做了一个反人类的功能「智能排序」，验证了我以前喜欢说的一句话: 智能和弱智只有一步之遥。当然这个所谓的智能也是表现的绝对弱智，在几乎遭受了绝大多数用户的声讨之后，现在终于消停了，已经不是默认给用户设置智能排序了。

不过最近又有点故态重萌。以前曾公开私下里都夸过好几次新浪微博 WAP 版的团队，我也是少数用智能手机的… WAP 版本的重度用户，WAP 设计的够简朴，必备的功能都有，还没有那么多干扰。好景不长，WAP 版本微博评论现在这是按照什么顺序了? 怎么如此怪异?

还以为这个团队有点发昏了? 问了一下，有人告诉我现在评论顺序是「会员评论优先」(然后又有人告诉我，是所有客户端现在都「会员评论优先」了)。我想问，做这个决定的人，你长了一个猪脑袋么? 且不说这给用户带来多大的困扰，会员用户增加曝光率就一定能让更多用户购买会员资格么? 你以为你们是 CCTV 啊?

新浪为了赚钱，着急乱出王八拳情有可原，无独有偶，想起百度空间这个产品，做搜索起家的百度，用户的空间居然没有搜索功能，要查找一个用户写过的内容，必须要想点别的「技巧」。更为搞笑的是，前一段时间百度空间升级，估计是怕别人不知道他们终于升级得更为难用了，居然默认把用户的 RSS 直接插入一个产品升级通知，一打开 Google Reader，发现订阅的百度空间的内容齐刷刷的是这个产品通知……

建议新浪百度阿里腾讯这种大一点的互联网公司定期测试一下管理人员以及产品经理的智商，低于平均线的早点开除掉。对中国互联网有益，对人类也有益。另外，也测试一下管理人员以及产品经理的常识水平，低于平均线的立刻开掉。

有的时候想，为什么豆瓣的产品经常被人称道呢? 或许豆瓣团队也不都是聪明人，但他们能用正常人平常人的思维做事情，用常识做产品，而不是用「榨汁机」、「提款机」或「升职机」的脑袋做产品。

我们常说做产品要有点敬畏心，什么是敬畏心? 也就是说别没事卖弄你的智商，你一卖弄智商就暴露了你的智商；你越想着做点智能的东西就越显得产品弱智。

–EOF–

为什么我们在细节上做不好?

最近团队遇到一个案例。看似很小的事情，但仔细研究起来，彻底分析，每一个环节都没做好，细节部分糟糕得一塌糊涂，最后导致一件事情的结果：完全失败。

经常有人在聊起公司的时候问我，你现在最担心的事情有哪些? 我当然会重点提到团队。不过在谈及团队的时候，我又最担心在「细节」问题上做不好。

细节就是竞争力，尤其是对小团队来说，小团队更应该注重细节问题。大一点的公司可以追究责任人，靠流程、靠制度，靠各级评审等等一系列的「成本」来提升细节能力。小一点的公司或者团队怎么办? 恐怕只有依赖每个人的能力和责任心了。

细节也是锻炼人的能力的地方，搞清楚每一个细节，将每一个细节涉及到的背景知识和技能掌握好，能力自然也就会得到提升。继而，着手做更大的事情也不会手忙脚乱。相反，做不好细节和小事的人，如果总嚷着要做「重要」的事情，做更有「挑战」的事情，这样的事情真的到你面前，真的能接住么?

为什么我们在细节上做不好?

对细节问题不够重视 一件事情到了自己这里，头脑中先入为主认为只是一件小事，是一件简单的事情。这样，当然就不会给予足够的重视。小事不一定不重要，小事不一定意味着做起来就简单。

对事情复杂度缺乏认知 不就是给客户写一封电子邮件么? 不就是用 HTML 写一个页面么? 不就是做一则横幅广告么? 那么，这些事情真的简单么? 为什么别人为客户写的邮件打开率更高? 为什么别人写的页面更容易被搜索引擎收录? 为什么别人做的广告转化率更好? 背后涉及到哪些知识? 不想研究一下么? 不能研究一下么?

对细节缺乏耐心 草草了事，应付了事，遇到问题马马虎虎，轻易得放过了很多可以让自己得到成长的机会。「这问题我没想过」「这事情我没遇到过」「设计稿都改过两次了」… 这类借口在任何一个团队都很常见。

缺少责任心 常常觉得自己这里做不好，还有别人会把关呢。担心什么? 可如果所有人都这么想呢? 「文案是产品经理的事情，关我甚么事?」如果你能对文案也有改进意见，谁说以后你就不能做产品经理做的事情呢?

主观上不认可自己的工作 就给我这么一点钱，要我做这么多工作? 问题是我们如果不多做一点工作，不提升一下自己，又怎么能多一点钱呢?

为什么细节上做不好? 不同人不同的角度还会有不同的看法。不过有一点我能肯定，细节不会决定成败，但做不好细节，一定会失败。

做好细节，百事可作。

–EOF–

扎克伯格的错误

今天业界热议的事情是Facebook创始人兼CEO马克·扎克伯格在接受采访的时候承认「专注在 HTML 5上面是他有史以来犯过的最大的错误。」然后，透露出来的数据是：用户浏览的 Feed 信息流是之前的 2 倍。

Facebook 最初使用 HTML 5 的主要原因是什么呢？一次开发，跨平台发布肯定是其中考虑的一个因素，当然，开发上可以做到快速迭代，这和 Facebook 的工程文化也是相符的。不过，这样实际上是节约了开发成本，获得了开发上的「速度」，这样做也牺牲了用户的体验上的「速度」，牺牲了「性能」。

为什么 Facebook 过度在移动上压注 HTML 5 是不对的？最大可能的原因或许就是「性能」的问题，没有更好的速度就没有更好的用户体验，而用户体验一直是扎克伯格最看重的东西。

扎克伯格从 Facebook 创建之初就认识到，对 Facebook 这样的的网络服务而言，「性能表现就是关键。假如向用户传送新页面的速度开始减缓，那就是致命的一击。」从技术的角度看，Facebook 一向在网站优化上不遗余力，无论是 BigPipe 还是 HipHop for PHP，这些不遗余力的优化实践以及技术创新为 Facebook 带来了绝佳的用户体验，而移动端押注 HTML 5 则恰恰是无形中背离了 Facebook 的这一准则。

iOS 原生应用发布之后，浏览信息是原来的两倍意味着什么？用户会在意你用 HTML 5 开发还是用的本地原生应用？绝大多数用户都不在乎这个，甚至都不知道，用户更关心的是「应用的速度」，App 是否足够快? 是否可以更流畅的阅读信息，没有人愿意在手机上等待某个应用慢吞吞的打开，就这么简单。

接下来面对 Facebook 的挑战是能否像在 Web 产品上进行的那些最佳实践那样也在移动产品上建立起更有效的研发机制，毕竟这是另外一个战场，一个互联网巨头在移动领域是否还是绝对的统治者? 没有人能知道。

事后诸葛亮一样来评价这个事情的对错本身并不重要，重要的是，我们是否可以从中学到某些教训?

–EOF–

对 HTML 5 来说，谈不上是什么「打击」，或许是好事情也说不定，让更多人认识 HTML 5 的优点和缺点，而不是一窝蜂的冲上去。

我在去年这个时间曾经说过这样一句话「我的两个固执的观点：1 HTML 5 不是移动开发的救星，至少现在不是；2 因为有 1 , 所以类似 PhoneGap 之类的解决方案还不靠谱，没有银弹。还需要再等 18 个月再看。」

现在看起来，还要再等 18 个月了。

本文首发: 福布斯中文网 (URL)。