Eshell V5.9  (abort with ^G)
1> mochiutf8:codepoint_to_bytes(20320).
<<"ä½ ">>
2> io:format("~ts",[v(1)]).
你ok
3> mochiutf8:codepoint_to_bytes(22909).
<<"好">>
4> io:format("~ts",[v(3)]).
好ok
5> mochiutf8:codepoint_to_bytes([20320,22909]).
** exception error: no function clause matching mochiutf8:codepoint_to_bytes([20320,22909]) (src/mochiutf8.erl, line 20)
6> mochiutf8:codepoints_to_bytes([20320,22909]).
<<"ä½ å¥½">>
7> io:format("~ts",[v(6)]).
你好ok

最后:Windows下不省心啊

在官方文档中,对于windows环境中Erlang shell的描述是"The interactive Erlang shell, when started towards a terminal or started using the werl command on windows, can support Unicode input and output."即:如果是在windows中启动werl可以支持Unicode的输入输出,

Eshell V5.9  (abort with ^G)
1> "国家".
[22269,23478]
2> io:format("~p~n",["国家"]).
[22269,23478]
ok
3> io:format("~w~n",["国家"]).
[22269,23478]
ok
4>
4> io:format("~ts~n",["国家"]).
国家
ok
5>
5> lists:keyfind(encoding,1,io:getopts()).
{encoding,unicode}
6> 

类似的代码在Centos中执行:

同样的代码在Centos中:
Eshell V5.9  (abort with ^G)
1> "你好".
[20320,22909]
2> list_to_binary(v(1)).
** exception error: bad argumentin function  list_to_binary/1called as list_to_binary([20320,22909])
3>

貌似,在windows中unicode的问题解决的看上去很美啊,好吧,看下面的这张图:

2012-6-1 12:09:49更新: 关于上面的截图,我还是误解了,看下面的讨论

深圳-燕尘(6108770) 11:45:04
Shell
在 unicode 环境下，中文会被编译为 [20013,22269,20154] 这样的双字节数字，
在 latin1 环境下，中文会被编译为 [228,184,173,229,155,189,228,186,186] 这样的单字节数字，

所以在 unicode 环境下需要用 [\x{4e00}-\x{9fff}] 来匹配，是双字节的表达式，
latin 环境下需要用 [\x81-\xfe][\x40-\xfe] 来匹配，是单字节的表达式。
然后 windows 下面，cmd 默认是 latin1 环境，werl.exe 默认是 unicode 环境。

深圳-燕尘(6108770) 11:47:01
windows 的默认字符集是各国的本地语言，像中文是 GBK ，都会被 erlang 视为 latin1 环境。

北京-坚强2002 11:47:58
windows里面的事情就诡异了 看上面的截图
深圳-燕尘(6108770) 11:48:11
然后在 unicode 环境下，不能用 list_to_binary 来转换 unicode 字符，
要用 list_to_binary(unicode:character_to_list())
doc 里面的 unicode 文档讲了这个问题。

北京-坚强2002 11:49:14
深圳-燕尘(6108770) 11:45:04
在 unicode 环境下，中文会被编译为 [20013,22269,20154] 这样的双字节数字，
在 latin1 环境下，中文会被编译为 [228,184,173,229,155,189,228,186,186] 这样的单字节数字

这个是在shell还是在module?

深圳-燕尘(6108770) 11:50:05
shell
在 module 环境下，估计是会跟文件的编码有关。

北京-坚强2002 11:51:34
shell中这样说是对的
深圳-燕尘(6108770) 11:51:58
我用的默认 ANSI 格式保存，所以无论在 unicode 或者在 latin1 的 shell 下调用，它们都能正确运行。
北京-坚强2002 11:52:40
我们都是使用UTF-8

深圳-燕尘(6108770) 11:52:46
如果文件是 UTF-8 格式，估计就会把中文给编译成 双字节的数字了。
就是这样，如果实在 Module 里用，跟你的文件编码相关，挑选不同的表达式。
你自己测试测试好了，另存为 ANSI 看看
深圳-燕尘(6108770) 11:54:14
调用 MODULE 的时候，结果跟 shell 的语言环境无关。
北京-坚强2002 11:54:53
不会的 和文件编码没有关系 erlang编译器编译的时候使用latin编码 中文会编译成单字节数字

深圳-燕尘(6108770) 11:55:48
测试测试啊
深圳-燕尘(6108770) 11:57:06
哟，我测试了。不管文件是啥编码，latin1 那个表达式都能用
北京-坚强2002 11:57:21
是的
北京-坚强2002 11:58:39
不去管windows下的怪异情况 一切都能理顺了

深圳-燕尘(6108770) 11:59:16
无论shell是什么字符集，结果都是能匹配：

但是可以从匹配的位置看到，erlang把“中国人”三字编译成不同的长度了。

4> test:run().
{match,[{0,12},{8,4}]}

6> test:run().
{match,[{0,16},{12,4}]}

北京-坚强2002 11:59:36
是的 是的

深圳-燕尘(6108770) 11:59:49
windows 下不怪异啊。 windows 下就是 ，cmd 是 latin1 字符集， werl 是 unicode 字符集
深圳-燕尘(6108770) 12:01:37
我装了一个 latin1 的 suse 和 unicode 的 arch ，虚拟机。
北京-坚强2002 12:02:34
明白 我被表面忽悠了 对的
1> "中国人".
"中国人"
2> hd(v(1)).
214
3>
对的

测试数据:Rec = "^[\x{4e00}-\x{9fff}]+$",          % 中文正则1Rec = "^([\x81-\xfe][\x40-\xfe])+$",      % 中文正则2re() ->re:run("hello 中国 ren", "[\x{4e00}-\x{9fff}]+", [unicode]).re1(C) ->re:run(C,"[\x{4e00}-\x{9fff}]+", [unicode]).re3()->re:run("中国人", "([\x81-\xfe][\x40-\xfe])+", [unicode]).re4(C)->re:run(C, "([\x81-\xfe][\x40-\xfe])+", [unicode]).环境1:Centos {encoding,unicode}Eshell V5.9  (abort with ^G)
1> text:re3().
{match,[{0,16},{12,4}]}
2> L="中国人".
[20013,22269,20154]
3> text:re4(L).
nomatch
4> io:getopts().
[{expand_fun,#Fun<group.0.33302583>},
{echo,true},
{binary,false},
{encoding,unicode}]
5>
5> text:re1(L).
{match,[{0,9}]}
6>
7> text:re().
nomatch
8> 环境2 :Centos {encoding,unicode}
启动命令: LC_CTYPE=en_US.ISO-8859-1 erl
Eshell V5.9  (abort with ^G)
1>
1>  L="中3".  %%L的内容是"中国人" 显示问题
[228,184,173,229,155,189,228,186,186]
2>  text:re3().
{match,[{0,16},{12,4}]}
3>  text:re4(L).
{match,[{0,4},{0,4}]}
4> io:getopts().
[{expand_fun,#Fun<group.0.33302583>},
{echo,true},
{binary,false},
{encoding,latin1}]
5>  text:re1(L).
nomatch
6>  text:re().
nomatch
7>

附录二 数据类型内存分配对照表

附录三  一个小测试代码 2012-9-28 16:38:28更新

Eshell V5.9  (abort with ^G)
1>
1>
1> L=[228,189,160,231,154,132].
[228,189,160,231,154,132]
2>
2> list_to_binary(L).
<<228,189,160,231,154,132>>
3> io:format("~ts",[v(2)]).
你的ok
4> io:format("~ts",[unicode:characters_to_list([20320,30340])]).
你的ok5> unicode:characters_to_binary([20320,30340]).
<<228,189,160,231,154,132>>