撸王之王：除了上面楼主说的那 8 个字符（实际上一共有 14 个），
在 Windows 里是严格按 GB18030 规范，和 GBK 一样，继续映射到 Unicode 的私用区，
而在 libiconv 里，是和其他几十个有俩 Unicode 编码...回到原帖

你说的没错，但这毕竟是中文输入法，GB18030于我来说方便得多

dgod：linux版的编码转换是自己开发的，不存在问题。windows提供的调用也是对的。我自己开发的版本可能更好点，gb私有区的汉字有非私有区的unicode时，就不转到unicode的私有编码上。
vim的问题可能是你设置了文件编码为gbk而...回到原帖

后加的 U+9FB4 在 GBK 里没有对应编码。应该不会是设成 GBK 的原因。

dgod：你说的没错，但这毕竟是中文输入法，GB18030于我来说方便得多回到原帖

刚才还忘说了一点。用 GB18030 好像可以省一点内存……不知道能省多少，可能不会太多（猜 10%）。

撸王之王：后加的 U+9FB4 在 GBK 里没有对应编码。应该不会是设成 GBK 的原因。回到原帖

没有对应编码但同一个汉字在私有区中有

dgod：没有对应编码但同一个汉字在私有区中有回到原帖

我的 vim 设的是 GB18030，不是 GBK。但是看起来 vim 不是用的 Windows 提供的编码转换，而是和 libiconv 一样的。
我总结一下几个软件的编码转换行为吧：

软件	Unicode -> GB18030		GB18030 -> Unicode
	9FB4 -> ?	E81E -> ?	FE59 -> ?	82359037 -> ?
Windows / Python	82359037	FE59	E81E	9FB4
libiconv / vim	FE59	FE59	9FB4	9FB4
小小	---		E81E (Windows上) 9FB4 (Linux上)	9FB4

看起来82359037总是可以被正确地解码，所以现在一个变通的办法是避免使用GB18030字符集中的FE59等编码，都用82359037等。
至于E81E等Unicode被吞了，那也没办法了，因为GB18030本来就占用了这些码位。