关于ios中的转码问题

一,历史介绍(不了解的值得一读)

1)GB2312、GBK与UTF-8的区别

首先，我们要明白，GB2312、GBK和UTF-8都是一种字符编码，除此之外，还有好多字符编码。只是对于我们中国人的网站来说，用这三种编码 比较多。简单的说一下，为什么要用编码，在计算机内，储存文本信息用ASC II码，每一个字符对应着唯一的ASCII码。最初计算机是由美国发明的，他们也用的是键盘和上面的字母，所以他们的字符ASCII好解决。但是我们中国 的就不同了，每个汉字要对应唯一的ASCII码。这样，就出来了国家制定的字符编码标准：GB2312、GBK等。其他国家，其他语言也有他们对应的编码 标准。

GB 就是国标的意思，GB2312和GBK主要用于汉字的编码，而UTF-8是全世界通用的。意思就是说，如果你的网页主要面对使用汉语的中国人的话，使用 GB2312和GBK非常好，文字储存体积要小，有一些优点。如果你的网页要面向世界的话，你再用GB2312和GBK作为网页编码的话，有些电脑上的浏览器没有这种编码，你的网页汉字内容就会变成无法识别的乱码。

它们通常用在网页的meta标签内，例如：<meta http-equiv=”Content-Type” content=”text/html; charset=gb2312″ />，表示这个页面使用的是GB2312编码。这个信息是给浏览器看的，浏览器会优先考虑使用从网页头部提取出来的编码信息对网页进行解码。当然， 我们也可以强制浏览器使用某种编码解释网页，这样我们就看到了传说中的乱码。请看下图IE浏览器：



百度首页使用的是GB2312编码，我们可以看到现在是正常的。我们右击页面，选择“编码”->“其他”->“Unicode（UTF-8)”，意思就是强制浏览器使用UTF-8的编码方式解析页面，我们可以看到奇迹发生了：



百度页面上所有的汉字都变成了乱码。如果你的网页使用了GB2312编码，却被一台没有GB2312编码的电脑访问了，里面所有的汉字都成了乱码。如果你使用UTF-8编码，在没有汉字的电脑里，仍然可以正常显示，因为UTF-8是通用的编码，所有电脑都有。

所以，在编写网页时，尽量使用UTF-8编码。

UTF-8：Unicode Transformation Format-8bit，允许含BOM，但通常不含BOM。是用以解决国际上字符的一种多字节编码，它对英文使用8位（即一个字节），中文使用24为（三个字节）来编码。UTF-8包含全世界所有国家需要用到的字符，是国际编码，通用性强。UTF-8编码的文字可以在各国支持UTF8字符集的浏览器上显示。如，如果是UTF8编码，则在外国人的英文IE上也能显示中文，他们无需下载IE的中文语言支持包。

GBK是国家标准GB2312基础上扩容后兼容GB2312的标准。GBK的文字编码是用双字节来表示的，即不论中、英文字符均使用双字节来表示，为了区分中文，将其最高位都设定成1。GBK包含全部中文字符，是国家编码，通用性比UTF8差，不过UTF8占用的数据库比GBD大。

GBK、GB2312等与UTF8之间都必须通过Unicode编码才能相互转换：

GBK、GB2312－－Unicode－－UTF8

UTF8－－Unicode－－GBK、GB2312

对于一个网站、论坛来说，如果英文字符较多，则建议使用UTF－8节省空间。不过现在很多论坛的插件一般只支持GBK

GB2312是GBK的子集，GBK是GB18030的子集

GBK是包括中日韩字符的大字符集合

如果是中文的网站 推荐GB2312 GBK有时还是有点问题

为了避免所有乱码问题，应该采用UTF-8，将来要支持国际化也非常方便

UTF-8可以看作是大字符集，它包含了大部分文字的编码。

使用UTF-8的一个好处是其他地区的用户（如香港台湾）无需安装简体中文支持就能正常观看你的文字而不会出现乱码。

gb2312是简体中文的码

gbk支持简体中文及繁体中文

big5支持繁体中文

utf-8支持几乎所有字符

unicode编码(也就是UTF编码)：俗称万国码，致力于使用统一的编码准则表达各国的文字。

为表达更多的文字，utf-8采用2/3混编的方式。目前容纳的汉字范围小于gbk编码。并且以

3字节的方式处理中文，带来了兼容性的问题，原有的gbk,G B2312,gb18030编码文件都不能正常的处理,还有很长的路要走。

2)GBK18030,GBK，GB2312三者的关系

中国大陆最常用的就是GBK18030编码，除此之外还有GBK，GB2312，这几个编码的关系是这样的。

最早制定的汉字编码是GB2312，包括6763个汉字和682个其它符号。95年重新修订了编码，命名GBK1.0，共收录了21886个符号。

之后又推出了GBK18030编码，共收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字，现在WINDOWS平台必需要支持GBK18030编码。

按照GBK18030、GBK、GB2312的顺序，３种编码是向下兼容，同一个汉字在三个编码方案中是相同的编码。

GB2312编码大约包含6000多汉字（不包括特殊字符）,编码范围为第一位b0-f7,第二位编码范围为a1-fe(第一位为cf时,第二位为a1-d3),计算一下汉字个数为6762个汉字。当然还有其他的字符。包括控制键和其他字符大约7573个字符编码

gbk编码是对G B2312编码的扩充，容纳的汉字更多，但仅仅是扩充，没有质的变化。保留了所有G B2312编码,在此基础上进行编码范围的扩充.容纳(包含特殊字符)共22014个字符编码.

gb18030编码是在gbk编码基础上的扩充，因为汉字更多，仅仅使用两位编码已经不能

容纳要求的汉字，所以采用了2\4位混和的办法，可以支持更多的汉字编码。并且保留了原有的gbk 2字节编码兼容G B2312和gbk编码的文件。大概容纳55657个编码(包含特殊字符)

3)ASCll编码和Unicode编码的区别

ASCII编码是1个字节，而Unicode编码通常是2个字节。

字母A用ASCII编码是十进制的65，二进制的01000001；

字符0用ASCII编码是十进制的48，二进制的00110000，注意字符'0'和整数0是不同的；

汉字中已经超出了ASCII编码的范围，用Unicode编码是十进制的20013，二进制的0100111000101101。

你可以猜测，如果把ASCII编码的A用Unicode编码，只需要在前面补0就可以，因此，A的Unicode编码是0000000001000001。

新的问题又出现了：如果统一成Unicode编码，乱码问题从此消失了。但是，如果你写的文本基本上全部是英文的话，用Unicode编码比ASCII编码需要多一倍的存储空间，在存储和传输上就十分不划算。

所以，本着节约的精神，又出现了把Unicode编码转化为“可变长编码”的UTF-8编码。UTF-8编码把一个Unicode字符根据不同的数字大小编码成1-6个字节，常用的英文字母被编码成1个字节，汉字通常是3个字节，只有很生僻的字符才会被编码成4-6个字节。如果你要传输的文本包含大量英文字符，用UTF-8编码就能节省空间.

二,IOS中url编码和解码问题

由于url支持26个英文字母、数字和少数几个特殊字符，因此，对于url中包含非标准url的字符时，就需要对其进行编码

有时,你在开发中可能遇到以下问题:比如说,@"http://s237.sznews.com/pic/2010/11/23/e4fa5794926548ac953a8a525a23b6f2/"竞赛资讯.png.明明可以在浏览器查看,用它来直接初始化NSURL,请求时出现报错. 还有url里面含有中文或特殊字符，ios客户端不能正确识别使用NSURLConnection进行网络请求的时候直接报错：bad URL...等等.

假如是含有特殊字符:

(1)网络访问请求:中文空格字符转码

stringByAddingPercentEscapesUsingEncoding(只对 `#%^{}[]|\"<> 加空格共14个字符编码，不包括”&?”等符号),

ios9将淘汰，

建议用stringByAddingPercentEncodingWithAllowedCharacters方法

URLFragmentAllowedCharacterSet  "#%<>[\]^`{|}
URLHostAllowedCharacterSet      "#%/<>?@\^`{|}
URLPasswordAllowedCharacterSet  "#%/:<>?@[\]^`{|}
URLPathAllowedCharacterSet      "#%;<>?[\]^`{|}
URLQueryAllowedCharacterSet     "#%<>[\]^`{|}
URLUserAllowedCharacterSet      "#%/:<>?@[\]^`

（2）网络访问请求：中文空格字符解码

stringByAddingPercentEscapesUsingEncoding

xcode7以后

stringByRemovingPercentEncoding

举例:

NSString * resourcePath = @"https://www.xiaocaobank.com";
NSString *encodePath ;
if (!IOS7_OR_LATER) {
encodePath = [resourcePath stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
}else{
encodePath = [resourcePath stringByAddingPercentEncodingWithAllowedCharacters:[NSCharacterSet characterSetWithCharactersInString:@"`#%^{}\"[]|\\<>"].invertedSet];
}

三,ios 汉字转码 （汉字与utf8、Unicode转与汉字）

1)汉字与utf8相互转化

UTF8码格式一般为"%E4%B8%AD%E5%9B%BD"

iOS7以前版本

//UTF8转成汉字

NSString* strA = [@"%E4%B8%AD%E5%9B%BD"stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];

结果:





//汉字转成UTF8

NSString *strA =@"中国"

NSString *strB = [strA  stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];

结果:



iOS7以后版本

//UTF8转成汉字

NSString* strA = [@"%E4%B8%AD%E5%9B%BD" stringByRemovingPercentEncoding];

//汉字转成UTF8

NSString *strB = @"中国";
NSString * strC =[strB stringByAddingPercentEncodingWithAllowedCharacters:[NSCharacterSet URLQueryAllowedCharacterSet]];

2)汉字和Unicode

Unicode码格式一般为"\\U6df1\\U5733\\U56fd\\U5f00\\U884c01\\U673a\\U623"

iOS7以前版本

//Unicode转化为汉字

- (NSString *)replaceUnicode:(NSString *)unicodeStr {
NSString *tempStr1 = [unicodeStr stringByReplacingOccurrencesOfString:@"\\u" withString:@"\\U"];
NSString *tempStr2 = [tempStr1 stringByReplacingOccurrencesOfString:@"\"" withString:@"\\\""];
NSString *tempStr3 = [[@"\"" stringByAppendingString:tempStr2] stringByAppendingString:@"\""];
NSData *tempData = [tempStr3 dataUsingEncoding:NSUTF8StringEncoding];
NSString* returnStr = [NSPropertyListSerialization propertyListFromData:tempData
mutabilityOption:NSPropertyListImmutable
format:NULL
errorDescription:NULL];
return [returnStr stringByReplacingOccurrencesOfString:@"\\r\\n" withString:@"\n"];
}

结果:



iOS7以后版本

- (NSString *)replaceUnicode:(NSString *)unicodeStr {
NSString *tempStr1 = [unicodeStr stringByReplacingOccurrencesOfString:@"\\u" withString:@"\\U"];
NSString *tempStr2 = [tempStr1 stringByReplacingOccurrencesOfString:@"\"" withString:@"\\\""];
NSString *tempStr3 = [[@"\"" stringByAppendingString:tempStr2] stringByAppendingString:@"\""];
NSData *tempData = [tempStr3 dataUsingEncoding:NSUTF8StringEncoding];
NSString * returnStr = [NSPropertyListSerialization propertyListWithData:tempData options:NSPropertyListImmutable format:NULL error:NULL];
return [returnStr stringByReplacingOccurrencesOfString:@"\\r\\n" withString:@"\n"];
}

结果:

四, iOS NSDictionary 输出中文字符”乱码”（Unicode编码）

比如:简单定义一个字典，输出结果：

NSDictionary *dic = @{

@"我是中文字符": @"223333",

@"aaa": @{

@"aaa": @"啦啦啦"

}

};

NSLog(@"%@", dic);

将会看到这样的“乱码”，这种现象经常在调试服务端返回 JSON 结果的时候遇到：

2015-02-25 19:23:40.346 XXXX[13273:417921] {

aaa = {

aaa = "\U5566\U5566\U5566";

};

"\U6211\U662f\U4e2d\U6587\U5b57\U7b26" = 223333;

}

其实这个是 Unicode 编码的表示方法。顺便简单了解下 Unicode 编码：

\uxxxx这种格式是Unicode写法，表示一个字符，其中xxxx表示一个16进制数字，范围所0～65535. Unicode十六进制数只能包含数字0～9、大写字母A～F或者小写字母A～F。需要注意到是：Unicode的大小端问题，一般都是小端在前，例如 \u5c0f 表示汉语中的 ‘小’字，转换成10进制就是9215，所以在byte数组中应该是1592.

解决的方案

将输出的字符串重新编码。为了一劳永逸，可以直接使用 Method swizzing 替换原函数。操作如下：

定义文件 NSDictionary+Unicode.m

@implementation NSDictionary (Unicode)
- (NSString*)my_description {
NSString *desc = [self my_description];
desc = [NSString stringWithCString:[desc cStringUsingEncoding:NSUTF8StringEncoding] encoding:NSNonLossyASCIIStringEncoding];
return desc;
}
@end

首先在项目导入 JRSwizzle 库，在 AppDelegate.m 的 didFinishLaunchingWithOptions 方法中添加代码，替换原有 description 方法：

[NSDictionary jr_swizzleMethod:@selector(description) withMethod:@selector(my_description) error:nil];

完成替换，在调试时使用 po 命令输出即可看到中文输出：

(lldb) po dic{
aaa ={
aaa = "啦啦啦";
};
"我是中文字符" = 223333;
}