0x0001 符合标准的 JSON 格式，\u7f57 之类的就是这里说的 six-character sequence 了，既然都是6个字符，iconv 怎么转都不会有变化。
的确是这样的，我大概也了解了JSON的RFC讲什么了。。。其实就是在原本定义的Unicode编码前面加上\u的前缀。
（左边的文件）自定义文本文件（含ASCII与UTF-8）
我在编辑器上面写入英文字母与空格，仿照（右边文件的）00000030写的四个空格加上对应的ASCII，事实证明其实就是获取的文本格式就是ASCII。
而在00000020的位置，e7 bd 97是罗中文在十六进制的UTF-8编码，后文进行了转换与验证。
（右边的文件）获取的JSON文件
相比较从网上获取到的JSON中编码的Unicode字符(\u7f57)，UTF-8相对来说还是比较麻烦的。。。。
Unicode转UTF-8方式
UTF-8使用一至六个字节为每个字符编码（尽管如此，2003年11月UTF-8被RFC 3629重新规范，只能使用原来Unicode定义的区域，U+0000到U+10FFFF，也就是说最多四个字节）：
- 128个US-ASCII字符只需一个字节编码（Unicode范围由U+0000至U+007F）。
- 带有附加符号的拉丁文、希腊文、西里尔字母、亚美尼亚语、希伯来文、阿拉伯文、叙利亚文及它拿字母则需要两个字节编码（Unicode范围由U+0080至U+07FF）。
- 其他基本多文种平面（BMP）中的字符（这包含了大部分常用字，如大部分的汉字）使用三个字节编码（Unicode范围由U+0800至U+FFFF）。
- 其他极少使用的Unicode 辅助平面的字符使用四至六字节编码（Unicode范围由U+10000至U+1FFFFF使用四字节，Unicode范围由U+200000至U+3FFFFFF使用五字节，Unicode范围由U+4000000至U+7FFFFFFF使用六字节）。
UTF-8 的编码规则很简单，只有二条：
1）对于单字节的符号，字节的第一位设为0，后面7位为这个符号的 Unicode 码。因此对于英语字母，UTF-8 编码和 ASCII 码是相同的。
2）对于n字节的符号（n > 1），第一个字节的前n位都设为1，第n + 1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的 Unicode 码。
使用罗作为Unicode转为UTF-8的例子
这里可以看到罗的Unicode编码为7F57，这个我们后面会用到。
根据U+7F57所在的范围，这个字占用三个字节编码。
三个字节编码的格式为：1110 XXXX 10XX XXXX 10XX XXXX。
再将7F57从后往前填入字节编码中，就变成了：1110 0111 1011 1101 1001 0111也就是E7 BD 97。对应到我们上文往文本文件中写入中文，在十六进制编码下是相同的。
总结
- Unicode是一种编码方式，负责给每一个字符独一无二的编码。
- 传回来的文件没有问题，格式为JSON，它是按照JSON的RFC中定义的对Unicode编码的一种实现。即在原有的Unicode编码前面加上前缀
\u。
- UTF-8是Unicode的一种另外一种实现，具体转换规则见上文。
