题目可能有些容易引起误会。作为中国人，我们在日常生活中当然要使用中文，这是没有疑问的。然而，在程序员的世界中，我会在很多情况下尽量远离中文。前几天有朋友问我一个有关 GBK 编码的问题，我不愿意回答，他很不理解。但这是我自己思考以后做出的选择。

我并无意让其他人都接受我的意见。不过还是有必要说明一下我做出这些选择的理由，是否认同就是你的事情了。我相信读者的背景和知识范围会对他的选择有极大的影响。所以，觉得百度是世界上最好的搜索引擎的同学可以 Alt + F4 了，这篇文章不是为你写的。

接下来我会说明，在哪些地方尽量不要使用中文，以及为什么要这样做。

不要在文件路径中使用中文

有些“上古”软件，比如比较早的 Delphi，如果你在程序路径中包含了中文，那么整个程序都会出错，连补救的机会都没有。现在情况会好一些，很多软件对中文的支持还不错，但还是存在相当数量的软件不能正常处理包含中文的文件名或路径。

你应当理解一个客观事实，那就是：很多优秀的软件是外国人开发的。他们会很努力的保证自己的程序没有 bug，可是他们根本想象不到自己的程序在中文下会出现什么问题。多年来，我看到不断有人吐槽操作系统的 IME 会导致各种奇怪的问题，我看到了也只能苦笑一下，因为我知道很多以英文为母语的程序员甚至都不知道有 IME 这个东西的存在，更别指望他们解决问题了。这并不是他们的错。我们能做到的，只有尽力避免这种情况的发生。

程序员之所以用中文命令目录，通常是因为觉得这样容易理解其含义。然而只要你有良好的命名规则，用纯英文也是很容易理解的。如果目录数量非常多的话，那么你或许用错了工具——像 EverNote、有道笔记或者为知笔记等等才是整理大量资料的专业软件，它们在分类管理和检索方面比单纯的文件夹分类好得多，而且支持多终端同步。

有些同学还觉得，那我们都用中国人开发的软件不久好了吗。抱歉，我只能说你 Too young too simple 了。

不要用中文做用户名

这和上面其实是类似的问题——用中文做用户名，意味着你的用户专属文件夹就是中文的。这种操作比一两个目录命名为中文更加危险。因为按照操作系统的规范，绝大多数程序都会访问你的个人目录来获取设置以及保存数据。这意味着如果使用有编码兼容性问题的软件，你遇到麻烦的可能性几乎是百分之百。

绝对不要这么做。

不要英文社区里用中文留言

最近发生过这样的消息：有国人在 Github 上用中文留言，吃瓜群众里面有人觉得很不礼貌，有人则坚持认为这是自己的权利。最后当然是吵的不可开交，谁都无法说服谁。

我的意见倾向于前者。虽然留言本身不见得什么出格的地方，但是从礼貌上说，客随主便。人家用英文发言，你却用中文回复，那说明你根本就没有与外国人沟通的意思，人家干嘛要理你呢？

在其他英文社区也见到过一些英文帖子里突然插入几条中文回复的情况。基本上，这些中文是无人理睬的，这已经足够说明别人对你的态度了。我实在不能理解为什么某些国人能把这些粗鲁的行为做的这么理直气壮。我自己的英文也不怎么样，但提 issue 的时候从来坚持用英文，庆幸的是技术问题基本上老外都听得懂，实在难以表述的话，搬出 Show me the code 大法均能顺利解决。

不要用中文版软件

这可能是我在平时遇到最多的问题。比如，从前我们项目组其他人全都用中文版 Visual Studio，只有我宁可自己下一个英文版来用。也有同事问过我为什么这么做。我简单的回答，用习惯了，不想换。他们也就不再问了。现在想来，或许也有人在心里暗骂我装 B 吧（当然没有明说）。

我坚持用英文版原因有这么几点。首先，我曾经在 Eclipse 和 Visual Studio 的早期版本都遇到过中文语言包引起的问题（Eclipse 过去也曾提供过多语言界面，现在似乎没有了）。作为程序员，我对这种问题表示理解，因为字符串格式化是所有程序中极其普遍的操作，以至于不太可能去捕获这种用法的异常。但从用户的角度说，一个字符串格式失败就直接跳到了全局异常处理点，正常的动作无法再执行下去了，这样的产品简直没法用。我在看到异常界面跳出来的时候还觉得莫名其妙，直到发现新版本的 Release Note 有这么一条，才知道语言包也会引发错误。从那以后，我就养成了坚持用英文版的习惯。因为英文版一定是最核心的版本、也经过了最为严格的测试，基本不可能有这方面的问题。而对于语言包，事实证明对它的测试力度是不足的，在有条件的情况下，何必去踩这个坑呢？

原因之二是，翻译出来的中文未必总是方便理解。一方面是部分翻译者的水平有限，有些内容简直是硬译，看的驴唇不对马嘴；有些则是因为没有统一的翻译规则，同一个英文单词到不同的人那里就是不同的译法，让人绞尽脑汁才能明白对应的原文到底是什么。正应了那种讽刺的说法：“每一个字我都认识，合在一起就是不知道你想说什么”。在这种情况下，我宁愿去阅读原文。

原因之三是，我经常会阅读一些英文内容的新闻或博客内容。英文版的界面能和读到的内容直接对应起来，而用中文版的话，还需要在脑内先翻译一遍，才能对得上，反而增加了认知负担。

原因之四，如果你到英文版网站上去提问题，并且截图说明，但是老外根本看不懂你图里的中文内容，等于白费功夫。

总之，我坚持使用英文版软件（当然是对外国软件而言）。还是有同学认为中文版好理解的，那么我只想说，这是你愿不愿意坚持的问题。技术软件的英文本来并不难理解，然而对于特别复杂的软件，比如 Visual Studio 和 JetBrains IDE，内容非常多，要上手的话的确有一定难度，这个我承认。但只要你坚持用几个月，这个问题就不成为障碍了。现在我反而是去看 VS 中文版的时候，有时需要思考半天才知道这个菜单或工具说的是什么意思。

不要在代码中使用中文

我在编译 Qt 时曾遇到过很多问题，其中之一就是：部分源代码中包含了可能是某种西欧语言的字符，必须修改掉源代码，整个库才能编译通过。这个问题曾经搞得我特别痛苦。编译过 Qt 的人都知道，这个库极其庞大，编译一次几乎要花一整天时间，如果机器配置不高的话更加可怕。如果编译到一半的时候出现错误，那大半天时间就白费了。我甚至有一次花了整整一星期时间才把某个版本的 Qt 编译通过。

如果你有过类似的经历，换位思考一下，你就能理解为什么不应该在源代码中包含中文了。那样意味着其他国家的人去编译你的程序时，他会遇到和你（编译包含欧洲字符的源文件）同样的麻烦。注释可以用纯英文书写。对于包含本地内容的字符串，正规的做法时把它提取到外部资源文件中，现代语言和框架应该都支持这种资源外部化的做法，不用担心编码出问题。

有些现代化的编程语言，特别是 Go，强制你使用 UTF-8 作为源文件编码。这意味着你可以在 Go 源文件中使用中文而无需担心编译器解析失败。即便如此，如果你写的是开源代码且有可能被外国人读到，那么使用中文也是不恰当的行为。

在某些特殊情况下我也会在源码中使用中文。比如，我曾经在单元测试中用中文作为测试方法的名称。这是因为有些业务概念确实不容易找到对应的英文单词，并且我们这个项目是内部软件，开发工具统一，不用考虑编码问题。对于开源代码，我还是建议你不要使用中文。

不要再继续支持 GBK/GB2312/GB18030

回到开头那个问题。我知道有很多历史项目还是需要面对 GBXX 的编码问题，但是我还是要呼吁，只要你还有选择，请在新项目中使用 Unicode/UTF-8，不要再继续 GB 编码，给后人留坑了。

我们开始使用 Java 的时候，为了让 Web 服务器支持中文，必须自己写一个过滤器，然而有一个网上广泛流传的版本却使用 iso-8859-1 作为编码。当时我就认为，这会给那些只知道无脑抄代码的人留下更多的坑。以前我们没有办法，因为 Unicode 没有出来，各个国家的人各自使用不同的编码，犹如那个巴别塔的传说。到了今天，我们已经有统一的全球编码规范，应该是解决这个问题的时候了。

我不希望再看到那么多文章长篇大论的解释各种编码的区别，我也不希望这么多程序员前仆后继的在编码问题上浪费这么多青春和生命。有很多人勤奋的写文章、写库、帮忙解答问题，我尊重他们的努力，但我认为这个方向是错误的。解决问题最好的办法是在冒出来之前就彻底消灭，而不是在出现以后再去花费大量的精力解决。我更不希望你在今天还要创建使用本地编码的项目，为你的后人继续挖坑下去。作为现代程序员，你应该做的是坚持使用全球通用编码，让沟通无障碍，让编码问题不再成为问题。

请使用 UTF-8。重要的事情我只说一遍。

尽量用类 Unix 系统编程

上面我说到你应该使用 UTF-8 的问题。但是贯彻这个原则还有一个最大的拦路虎，那就是 Windows。

Windows 最早出现的时候还没有什么 Unicode 规范，所以这个问题似乎是不可避免的。但无论有多合理的历史原因，现实情况就是： Windows 使用本地编码是一个错误的结果，这个结果使得不同国家的人们在信息编码这件事情上吃尽了苦头。

Windows 生态体系，包括操作系统本身、cmd 控制台、用来处理常规文件的 notepad、用来编译程序的 Visual C++，这些组成部分全部都在鼓励你使用本地编码，妨碍你使用 UTF-8，甚至有些地方的设计使得你几乎完全无法使用 UTF-8。微软自作主张的 BOM 使得这个问题更加复杂化了。所以有些微软鼓吹者希望你一切按照微软的要求来。我能够理解他们的逻辑，如果你不得不呆在微软的体系内，那么使用微软方案确实是最简单、有时候甚至是唯一可行的办法。但是照这条路走下去的话，你会和开源的体系越来越难以兼容。当然，现在微软声称 love Linux，但在我看来这是一个有点精神分裂的声明，因为 Windows 和 Linux 在很多方面是无法兼容的。微软怎样做才能两面讨好，我愿意听其言观其行，但是我不认为这个局面在目前能够有一个皆大欢喜的解决办法。

虽然我个人从感情上倾向于 Linux，但是实话实说，在桌面这一块要完全使用 Linux 对于大多数人来说还是不太现实的事情（主要是各种驱动问题）。 我目前的办法是，办公和娱乐的事情在 Windows 上完成，编程工作绝大多数在虚拟机上的 Linux Mint 或者 Ubuntu Server 中完成。我不排斥 Windows，只是认为作为编程开发的平台，它比不上 Linux 那样理想。也曾用过一段时间 的 Mac，但在很多细节问题上还是和 Linux 不一样，不适应，放弃了。

这是我的个人经验。再说一遍，我从来不认为没有编程要求的普通人应该脱离 Windows，用 Linux 工作。但是对于以程序为职业的同行来说，我建议你严肃的考虑 Linux（或 MacOS 也可）。现在的 Linux 有图形化的安装界面、已经支持不少硬件驱动、大多数情况下不需要你手工 mount 外设、足够傻瓜化的包管理工具，甚至如果你不想自己安装的话，还有很多云平台可以免费试用。比起十多年前什么都要自己去弄的情况，简直是好用到让人想哭啊。我相信在今天，掌握 Linux 对普通程序员来说已经不是什么无法逾越的障碍了，没有必要一听就打退堂鼓。

另外也有一句《黑客与画家》里的名言我很认同：如果必须要做什么事情的话，你应该选择比较困难的做法。不明白？那就去看原书吧，这是一本很棒的书，不会让你失望的。