当下，应用程序的国际化（或本地化）的要求逐步显现。支持unicode，也就逐步成为应用程序（特别是那些应用广泛的程序）的必然趋势，例如，GNU就将（更好的）支持unicode作为emacs23的一个亮点。这些变化，对我们中国的程序员以及软件用户来说，都是上好的消息。

问题的另一方面是，不是所有的现有程序都（很好）的支持unicode。很多应用程序，还是主要面向ASCII编码的。能够支持unicode编码的程序，为了提供向后兼容性，其中一些提供了一个启动参数、或配置参数，来启动对unicode的支持。如果没有应用这个特定的参数，程序将不支持unicode。

一些应用程序，特别是那些有较久历史的程序，默认配置通常是面向ASCII编码的，如GCC。这样的话，一些unicode编码的文本，就显示为乱码。如果你在LANG=en_US.utf8的Linux系统上使用过gcc4.2.4（3?）及以上版本的话，你就肯定会有这方面的经历。GCC产生的编译错误和警告消息里，包含一堆乱码，有时候几乎可以让你无法阅读理解。

如果你想要一个支持unicode的工作环境，在Linux系统中，有标题所示的3个全局环境变量：LANG, LC_CTYPE, LC_ALL。通过设置这些环境变量，可以在系统范围中启动应用程序对unicode的支持（至少向所有应用程序表达了这个愿望）。但是，这里有一个糟糕的问题：如果系统中一些应用程序对unicode的支持并不全面（甚至不支持unicode，而只面向ASCII），那么通过设置这些环境变量，特别是LANG，就可能给这些程序带来一些干扰。

例如，如果将LANG=zh_CN.UTF-8，当你使用svn的时候，就可能有如下警告：

       svn: warning: cannot set LC_CTYPE locale

       svn: warning: environment variable LANG is zh_CN.UTF-8

       svn: warning: please check that your locale name is correct

事实上，我们可以分别设置LANG, LC_CTYPE, LC_ALL，以求取得一个影响最小的解决方法，使得：1）能够启动应用程序对unicode的支持，如果他们真的支持的话；2）不干扰那些对unicode支持不全面的应用程序。

我的经验是，尽量不去改动LANG，而根据系统的具体配置，设置LC_CTYPE及LC_ALL。例如，将LC_ALL=C，而保留LANG=en_US.UTF-8，那么就能使GCC产生用户友好的编译错误及警告消息，又能与svn等相安无事。