在项目中，因为字符编码的问题，踩了不少坑，之前踩，现在还接着踩，现在把它们总结出来，只希望以后不要再踩这坑了，我把我踩过的坑总结一下：
1.将数组转成json数据，json数据为null或为空字符串；
2.将数组转成json数据，json中的汉字乱码；
3.当json数据嵌套时（数组是个json，数组中的某个字段，也是个json字符串），json_decode失败；
1 基本概念
Unicode：（统一码、万国码、单一码）是计算机科学领域里的一项业界标准，包括字符集、编码方案等。
UTF-8：是一种针对Unicode的可变长度字符编码，又称万国码，UTF-8用1到4个字节编码Unicode字符。
GBK：汉字编码字符集。
json_encode：PHP中将数组转成json数据，只支持utf8格式的数据；
json_decode：PHP中将json数据转换成数组，转换后的数组是utf8格式；
2 UTF-8/GBK与json_encode
情况1：GBK–>UTF-8–>json_encode
代码如下：
$strTest = '测试用例';
$strConvet = iconv('GBK', 'UTF-8', $strTest);
var_dump($strConvet);
$strJson = json_encode($strConvet);
var_dump($strJson);
这里需要分两种情况讨论，当数据$strTest为gbk格式，输出结果：
string(12) "测试用例" string(26) ""\u6d4b\u8bd5\u7528\u4f8b""
这里没有问题，数据是从gbk–>utf8–>json_encode，流程完全正确（说明一下，”\u6d4b\u8bd5\u7528\u4f8b”是unicode格式，也就是php进行json_encode时，会自动将utf8格式的汉字转为unicode格式，除汉字以外，其它的还是按照utf8格式输出，专门将汉字转为unicode，这样其实有个很大的好处，后面会讲）。
如果数据$strTest为utf8格式，输出结果：
string(18) "娴嬭瘯鐢ㄤ緥" string(38) ""\u5a34\u5b2d\u762f\u9422\u3124\u7de5""
出现乱码了！！！数据是从utf8->utf8–>json_encode，也就是数据$strTest为utf8格式，然后把按照gbk的方式强转为utf8，就出现乱码了，虽然是乱码，但这些乱码仍然是utf8格式，所以json_encode后，仍然会有输出结果。
情况2：UTF-8–>GBK–>json_encode
代码如下：
$strTest = '测试用例';
$strConvet = iconv('UTF-8', 'GBK', $strTest);
var_dump($strConvet);
$strJson = json_encode($strConvet);
var_dump($strJson);
同上，这里也需要分两种情况讨论，当数据$strTest为utf8格式，输出结果：
string(8) "测试用例" string(4) "null"
没有出现乱码，但是json_encode后的数据为null！！！数据是从utf8–>gbk–>json_encode，因为json_encode只接受utf8格式的数据，gbk的数据不能直接转成json，只会输出null。
如果数据$strTest为utf8格式，输出结果：
string(0) "" string(2) """"
啥都没有了！！！数据是从gbk->gbk–>json_encode，也就是将utf8格式的数据，按照utf8的方式强转为gbk，直接转成空字符串。然后空的字符串json_encode后还是空字符串。（可能你会说，这个空字符串是gbk格式的啊，按照上面说的，json_encode后应该是null，我试了一下，英文字符是不区分utf8个gbk格式的，不管怎么转，输出的还是英文字符）
通过上面的2种情况，准确来说是4种情况，就基本知道为什么转码后，会出现各种各样的问题，总结一下，其实就是没有按照标准去使用转码函数。
3 UTF-8/GBK与json_decode
其实核心的东西，上面都已经讲了，只是json_decode的入参也必须是utf8格式的，只要保证这一点，json_decode后的数据就不会存在问题，但是在项目中，经过多次转码后，就不能保证json_decode的入参是utf8格式了，很容易出现乱码，我举个项目中遇到的例子。
项目示例：调用第三方的接口，会吐给我一个json串，这个json串是个数组，然后数组中有一个字段也是个json串，更恐怖的时，这个json串中的汉字居然不是unicode格式，而是个纯粹的utf8格式，示例数据如下：
{"ret":0,"msg":"OK","content":{"user_name":"","true_name":"{\"materialType\":\"测试数据类型\",\"materialFormat\":\"image\"}"}}
json_decode后的数据：
{
"ret": 0,
"msg": "OK",
"content": {
"user_name": "",
"true_name": "{\"materialType\":\"测试数据类型\",\"materialFormat\":\"image\"}"
}
}
因为项目中，我们这边处理数据的格式是GBK，所以第三方的数据会马上转成GBK格式，但是后续如果需要用到字段true_name中的数据materialType，需要将true_name单独json_decode，因为之前我们已经将其转为gbk格式，所以这里使用json_decode肯定会出现问题（这就是为什么json数据中的汉字，一般会转为unicode，如果汉字为unicode，就不会出现上述问题了）。为了解决这个问题，我们是先将第三方给我们的json数据，先转成数组，然后单独对字段true_name进行json_decode，这样所有字段就不存在json数据了，再统一将所有数据转成GBK格式。
最后补充一点，json_encode方法会自动将汉字转成unicode格式，如果因为一些特殊要求，需要将将里面的汉字保留为utf8格式（一般不要这样，会给自己埋坑，我指的是因为特殊要求，不得已才这么处理），使用方法如下：
json_encode($arrInput, 'GBK', 'UTF-8'), JSON_UNESCAPED_UNICODE)
但是这里又有个坑，看一下php帮助文档：
这个参数JSON_UNESCAPED_UNICODE，只有php5.4.0以上的版本（包括5.4.0）才能使用，如果你线下机器是php5.4.0，线上机器是php5.4.0一下版本，这个坑估计会被踩的很冤！
总结：这些坑是我一路踩过来的，估计以后还会有坑，不过我想应该不会很多了，如果还会踩到其它坑，会在该片博文中补充。
看看