java ucs2转utf8_软件中的字符串编码, UCS2, UTF8哪个更优？

我觉得你对编码的了解，有些信息是不正确的。

既然是涉及到了编码问题，如果是保存文本，或者是资源文件，那么一定建议是UTF-8，不要用其他格式，省得将来麻烦，总体来说，UTF-8基本上已经占据了主流，没有特殊原因，至少不应该在文本文件当中使用其他编码。

你说的是界面库开发，字符串处理，这是指读入内存以后的处理了吧，这一块的编码，按理说，应该由不得你来控制，要看你用的什么系统，用的什么语言平台才是。

至于说utf8比usc2内存占用大，我不知道这一说法从何而来。正常情况下，程序读入文件，会通过编码把文件转化“内码”表示的字符串，这时候，不同编码的文件，只要内容一样，占用的内存大小应该是一样的。你的意思，是不是要以二进制的方式读取utf-8编码保存的中文文本文件？如果是这样，utf8保存中文基本上要占用3个字节，确实比GBK等格式占用更多。但是，ucs-2也不能直接存在文件里啊，还是要考虑一种具体的保存编码的。如果是要用utf-16，那你就得谨慎了，会有很多0x00字符，如果你的文件不是仅仅给自己内部用的，那会存在潜在的问题。

至于你说到的“遍历效率”问题，我的理解，可能是说：1)因为utf-8是变长码，所以做统计字符这一类操作时，需要额外的处理吧？2)随机访问某个序号的字符不好定位？对于这两个问题，问题1)，应该不存多少差别，utf8的文件，只要忽略10开头的字节，就行了，这点开销，完全可以忽略。问题2)，确实有，但是，看你后面的意思，是要支持unicode BMP之外的其他字符的，那么你就不可能不面对这个问题，除非你只准备支持BMP，那么才可以定宽做随机访问。或者你用utf-32，这个，我觉得没人会这么干吧。。。。

另外，UTF-8和UTF-16都是可以表示全部unicode字符的，你既然需要处理BMP之外的字符，那肯定不能考虑UCS2啊。我觉得你这里可能没有了解清楚什么是USC2，你可以把它看成unicode的早期阶段，或者把UCS2当成现在 unicode 的 BMP就行了。

PS：就算UTF-8编码保存中文会比UTF-16或者GBK多出来50%的磁盘占用，我也不认为这是什么大问题，以目前计算机的能力，需要对文本当中多出来这些空间，有多么在意么？