JSON

JSON和XML都是需要解析的

JSON是一种轻量级的数据格式，一般用于数据交互服务器返回给客户端的数据，一般都是JSON格式或者XML格式（文件下载除外）

JSON的格式很像OC中的字典和数组

{"name": "jack", "age": 10}

{"names": ["jack", "rose", "jim"]}

标准JSON格式的注意点：key必须用双引号

要想从JSON中挖掘出具体数据，得对JSON进行解析

JSON 转换为
OC数据类型

1.png

2.png

JSON解析方案(又叫序列解析)

在iOS中，JSON的常见解析方案有4种

第三方框架：JSONKit、SBJson、TouchJSON（性能从左到右，越右越差）

苹果原生（自带）：NSJSONSerialization（性能最好）

NSJSONSerialization的常见方法

JSON数据 à OC对象(必须掌握)

+(id)JSONObjectWithData:(NSData *)data options:(NSJSONReadingOptions)opt
error:(NSError **)error;

OC对象 à JSON数据

• (NSData *)dataWithJSONObject:(id)obj options:(NSJSONWritingOptions)opt
  error:(NSError **)error;

3.png

XML

什么是XML

全称是Extensible
Markup Language，译作“可扩展标记语言”

跟JSON一样，也是常用的一种用于交互的数据格式

一般也叫XML文档（XML
Document）

XML举例

<videos>

<video name="小黄人 第01部" length="30"/>

<video name="小黄人 第02部" length="19"/>

<video name="小黄人 第03部" length="33"/>

</videos>

XML语法

一个常见的XML文档一般由以下部分组成

文档声明

元素（Element）

属性（Attribute）

XML语法 – 文档声明

在XML文档的最前面，必须编写一个文档声明，用来声明XML文档的类型

最简单的声明

<?xml version="1.0"?>

用encoding属性说明文档的字符编码

<?xml version="1.0"encoding="UTF-8"?>

XML语法 – 元素（Element）

一个元素包括了开始标签和结束标签

拥有元素内容：<video>小黄人</video>

没有元素内容：<video></video>

没有元素内容的简写：<video/>

一个元素可以嵌套若干个子元素（不能出现交叉嵌套）

<videos>

<video>

    <name>小黄人 第01部</name>

     <length>30</length>

</video>

</videos>

规范的XML文档最多只有1个根元素，其他元素都是根元素的子孙元素

XML语法 –元素的注意

XML中的所有空格和换行，都会当做具体内容处理

下面两个元素的内容是不一样的

第1个

<video>小黄人</video>

第2个

<video>

小黄人

</video>

XML语法 – 属性（Attribute）

一个元素可以拥有多个属性

<video name="小黄人 第01部" length="30"/>

video元素拥有name和length两个属性

属性值必须用 双引号"" 或者 单引号'' 括住

实际上，属性表示的信息也可以用子元素来表示，比如

<video>

<name>小黄人 第01部</name>

    <length>30</length>

</video>

XML解析

要想从XML中提取有用的信息，必须得学会解析XML

提取name元素里面的内容

<name>小黄人 第01部</name>

提取video元素中name和length属性的值

<video name="小黄人 第01部" length="30"/>

XML的解析方式有2种

DOM：一次性将整个XML文档加载进内存，比较适合解析小文件

SAX：从根元素开始，按顺序一个元素一个元素往下解析，比较适合解析大文件

iOS中的XML解析

在iOS中，解析XML的手段有很多

苹果原生

NSXMLParser：SAX方式解析，使用简单

第三方框架

libxml2：纯C语言，默认包含在iOS SDK中，同时支持DOM和SAX方式解析

GDataXML：DOM方式解析，由Google开发，基于libxml2

XML解析方式的选择建议

大文件：NSXMLParser、libxml2

小文件：GDataXML

NSXMLParser

使用步骤

传入XML数据，创建解析器

NSXMLParser *parser = [[NSXMLParser
alloc] initWithData:data];

设置代理，监听解析过程

parser.delegate = self;

开始解析

[parser parse];

NSXMLParser采取的是SAX方式解析，特点是事件驱动，下面情况都会通知代理

当扫描到文档（Document）的开始与结束

当扫描到元素（Element）的开始与结束

NSXMLParserDelegate

当扫描到文档的开始时调用（开始解析）

-(void)parserDidStartDocument:(NSXMLParser *)parser

当扫描到文档的结束时调用（解析完毕）

-(void)parserDidEndDocument:(NSXMLParser *)parser

当扫描到元素的开始时调用（attributeDict存放着元素的属性）

-(void)parser:(NSXMLParser *)parser didStartElement:(NSString
*)elementName namespaceURI:(NSString
*)namespaceURI qualifiedName:(NSString
*)qName attributes:(NSDictionary
*)attributeDict

当扫描到元素的结束时调用

• (void)parser:(NSXMLParser *)parser didEndElement:(NSString *)elementName namespaceURI:(NSString
  *)namespaceURI qualifiedName:(NSString
  *)qName

GDataXML配置

GDataXML基于libxml2库，得做以下配置

导入libxml2库

4.png

设置libxml2的头文件搜索路径（为了能找到libxml2库的所有头文件）

在Head Search Path中加入/usr/include/libxml2

设置链接参数（自动链接libxml2库）

在Other Linker Flags中加入-lxml2

GDataXML配置

5.png

GDataXML使用

GDataXML中常用的类

GDataXMLDocument：代表整个XML文档

GDataXMLElement

代表文档中的每个元素

使用attributeForName:方法可以获得属性值

6.png

补充（static）
全局变量的作用范围是整个程序（如果程序是多个文件，必须在其他的文件中说明
1 静态变量（static）存放在内存的数据区（堆）中的，在程序开始运行前就分配固定字节，在程序运行过程中被分配的字节大小是不变的。只有程序运行结束后，才释放所占用的内存。

2 它的作用域取决于静态变量的位置，若在函数里，作用域就是这个函数。在模块内（但在函数体外），静态变量可以被模块内的函数使用，但是不能被模块外的其他函数访问，是一个本地的全局变量。

3 静态全局变量，是定义存储类型为静态的全局变量，只有本文件可以用，虽然整个程序包含多个文件，但静态全局变量只能作用在它定义的那个文件里。

4 全局变量和静态变量都在堆里，局部变量存放在栈里。

1.0 JSON解析

• 1.1 JSON简单介绍

1 问：什么是JSON
答：
（1）JSON是一种轻量级的数据格式，一般用于数据交互
（2）服务器返回给客户端的数据，一般都是JSON格式或者XML格式（文件下载除外）

2 相关说明
（1）JSON的格式很像OC中的字典和数组
（2）标准JSON格式key必须是双引号

3 JSON解析方案
a.第三方框架 JSONKit\SBJSON\TouchJSON
b.苹果原生（NSJSONSerialization）

• 1.2 JSON解析相关代码

（1）json数据->OC对象

把json数据转换为OC对象
-(void)jsonToOC
{
1. 确定url路径
NSURL *url = [NSURL URLWithString:@"http://120.25.226.186:32812/login?username=33&pwd=33&type=JSON"];

2.创建一个请求对象
NSURLRequest *request = [NSURLRequest requestWithURL:url];

3.使用NSURLSession发送一个异步请求
[NSURLConnection sendAsynchronousRequest:request queue:[NSOperationQueue mainQueue] completionHandler:^(NSURLResponse * _Nullable response, NSData * _Nullable data, NSError * _Nullable connectionError) {
    
4.当接收到服务器响应的数据后，解析数据(JSON--->OC)    

第一个参数：要解析的JSON数据，是NSData类型也就是二进制数据
第二个参数: 解析JSON的可选配置参数
NSJSONReadingMutableContainers 解析出来的字典和数组是可变的
NSJSONReadingMutableLeaves 解析出来的对象中的字符串是可变的 iOS7以后有问题
NSJSONReadingAllowFragments 被解析的JSON数据如果既不是字典也不是数组, 那么就必须使用这
kNilOptions 默认写法优化性能

NSDictionary *dict = [NSJSONSerialization JSONObjectWithData:data
options:kNilOptions error:nil];
NSLog(@"%@",dict);
}];
}

（2）OC对象->JSON对象

1.要转换成JSON数据的OC对象*这里是一个字典
NSDictionary *dictM = @{
@"name":@"wendingding",
@"age":@100,
@"height":@1.72
};
2.OC->JSON

注意：可以通过+ (BOOL)isValidJSONObject:(id)obj;方法判断当前OC对象能否转换为JSON数据
具体限制：
1.obj 是NSArray 或 NSDictionay 以及他们派生出来的子类
2.obj 包含的所有对象是NSString,NSNumber,NSArray,NSDictionary 或NSNull
3.字典中所有的key必须是NSString类型的
4.NSNumber的对象不能是NaN或无穷大

第一个参数：要转换成JSON数据的OC对象，这里为一个字典
第二个参数：NSJSONWritingPrettyPrinted对转换之后的JSON对象进行排版，无意义

NSData *data = [NSJSONSerialization dataWithJSONObject:dictM options:NSJSONWritingPrettyPrinted error:nil];

3.打印查看Data是否有值

第一个参数：要转换为STring的二进制数据
第二个参数：编码方式，通常采用NSUTF8StringEncoding

NSString *strM = [[NSString alloc]initWithData:data encoding:NSUTF8StringEncoding];
NSLog(@"%@",strM);

（3）OC对象和JSON数据格式之间的一一对应关系

OC对象和JSON数据之间的一一对应关系
-(void)oCWithJSON
{
JSON的各种数据格式
NSString *test = @""wendingding"";
NSString *test = @"true";
NSString *test = @"{"name":"wendingding"}";

把JSON数据->OC对象,以便查看他们之间的一一对应关系
注意点：如何被解析的JSON数据如果既不是字典也不是数组（比如是NSString）, 那么就必须使用这NSJSONReadingAllowFragments
id obj = [NSJSONSerialization JSONObjectWithData:[test dataUsingEncoding:NSUTF8StringEncoding] options:NSJSONReadingAllowFragments error:nil];

NSLog(@"%@", [obj class]);


 JSON数据格式和OC对象的一一对应关系
 {} -> 字典
 [] -> 数组
 "" -> 字符串
 10/10.1 -> NSNumber
 true/false -> NSNumber
 null -> NSNull

}
}

（4）如何查看复杂的JSON数据

方法一：
在线格式化http://tool.oschina.net/codeformat/json
方法二：
把解析后的数据写plist文件，通过plist文件可以直观的查看JSON的层次结构。
[dictM writeToFile:@"/Users/文顶顶/Desktop/videos.plist" atomically:YES];

（5）视频的简单播放
0.需要导入系统框架

import <MediaPlayer/MediaPlayer.h>

1.拿到该cell对应的数据字典
XMGVideo *video = self.videos[indexPath.row];

NSString *videoStr = [@"http://120.25.226.186:32812" stringByAppendingPathComponent:video.url];

2.创建一个视频播放器
MPMoviePlayerViewController *vc = [[MPMoviePlayerViewController alloc]initWithContentURL:[NSURL URLWithString:videoStr]];
3.present播放控制器

[self presentViewController:vc animated:YES completion:nil];

• 1.3 字典转模型框架

（1）相关框架
a.Mantle 需要继承自MTModel
b.JSONModel 需要继承自JSONModel
c.MJExtension 不需要继承，无代码侵入性

（2）自己设计和选择框架时需要注意的问题

a.侵入性
b.易用性，是否容易上手
c.扩展性，很容易给这个框架增加新的功能

（3）MJExtension框架的简单使用

1.把字典数组转换为模型数组
使用MJExtension框架进行字典转模型
self.videos = [XMGVideo objectArrayWithKeyValuesArray:videoArray];

2.重命名模型属性的名称
第一种重命名属性名称的方法，有一定的代码侵入性
设置字典中的id被模型中的ID替换
+(NSDictionary *)replacedKeyFromPropertyName
{
return @{
@"ID":@"id"
};
}

第二种重命名属性名称的方法，代码侵入性为零
[XMGVideo setupReplacedKeyFromPropertyName:^NSDictionary *{
return @{
@"ID":@"id"
};
}];

3.MJExtension框架内部实现原理-运行时

2.0 XML解析

• 2.1 XML简单介绍

（1） XML：可扩展标记语言

a.语法
b.XML文档的三部分（声明、元素和属性）
c.其它注意点（注意不能交叉包含、空行换行、XML文档只能有一个根元素等）

（2） XML解析

a.XML解析的两种方式
1 SAX:从根元素开始，按顺序一个元素一个元素的往下解析，可用于解析大、小文件
2 DOM:一次性将整个XML文档加载到内存中，适合较小的文件
b.解析XML的工具
1 苹果原生NSXMLParser:使用SAX方式解析，使用简单
2 第三方框架
libxml2:纯C语言的，默认包含在iOS SDK中，同时支持DOM和SAX的方式解析
GDataXML:采用DOM方式解析，该框架由Goole开发，是基于xml2的

• 2.2 XML解析

（1）使用NSXMLParser解析XML步骤和代理方法

解析步骤：
4.1 创建一个解析器
NSXMLParser *parser = [[NSXMLParser alloc]initWithData:data];
4.2 设置代理
parser.delegate = self;
4.3 开始解析
[parser parse];

1.开始解析XML文档
-(void)parserDidStartDocument:(nonnull NSXMLParser *)parser

2.开始解析XML中某个元素的时候调用，比如<video>
-(void)parser:(nonnull NSXMLParser *)parser didStartElement:(nonnull NSString *)elementName namespaceURI:(nullable NSString *)namespaceURI qualifiedName:(nullable NSString *)qName attributes:(nonnull NSDictionary<NSString *,NSString *> *)attributeDict
{
if ([elementName isEqualToString:@"videos"]) {
return;
}
字典转模型
XMGVideo *video = [XMGVideo objectWithKeyValues:attributeDict];
[self.videos addObject:video];
}

3.当某个元素解析完成之后调用，比如</video>
-(void)parser:(nonnull NSXMLParser *)parser didEndElement:(nonnull NSString *)elementName namespaceURI:(nullable NSString *)namespaceURI qualifiedName:(nullable NSString *)qName

4.XML文档解析结束
-(void)parserDidEndDocument:(nonnull NSXMLParser *)parser

（2）使用GDataParser解析XML的步骤和方法

4.0 配置环境
001 先导入框架，然后按照框架使用注释配置环境
002 GDataXML框架是MRC的，所以还需要告诉编译器以MRC的方式处理GDataXML的代码

4.1 加载XML文档（使用的是DOM的方式一口气把整个XML文档都吞下）
GDataXMLDocument *doc = [[GDataXMLDocument alloc]initWithData:data options:kNilOptions error:nil];

4.2 获取XML文档的根元素，根据根元素取出XML中的每个子元素
NSArray * elements = [doc.rootElement elementsForName:@"video"];

4.3 取出每个子元素的属性并转换为模型
for (GDataXMLElement *ele in elements) {

XMGVideo *video = [[XMGVideo alloc]init];
video.name = [ele attributeForName:@"name"].stringValue;
video.length = [ele attributeForName:@"length"].stringValue.integerValue;
video.url = [ele attributeForName:@"url"].stringValue;
video.image = [ele attributeForName:@"image"].stringValue;
video.ID = [ele attributeForName:@"id"].stringValue;

4.4 把转换好的模型添加到tableView的数据源self.videos数组中
[self.videos addObject:video];

}

• 2.3 多值参数和中文输出问题

（1）多值参数如何设置请求路径

多值参数

如果一个参数对应着多个值，那么直接按照"参数=值&参数=值"的方式拼接

-(void)test
{
1.确定URL
NSURL *url = [NSURL URLWithString:@"http://120.25.226.186:32812/weather?place=Beijing&place=Guangzhou"];
2.创建请求对象
NSURLRequest *request = [NSURLRequest requestWithURL:url];

3.发送请求
[NSURLConnection sendAsynchronousRequest:request queue:[NSOperationQueue mainQueue] completionHandler:^(NSURLResponse * _Nullable response, NSData * _Nullable data, NSError * _Nullable connectionError) {
    
    4.解析
    NSLog(@"%@",[NSJSONSerialization JSONObjectWithData:data options:kNilOptions error:nil]);
}];

}

（2）如何解决字典和数组中输出乱码的问题

答：给字典和数组添加一个分类，重写descriptionWithLocale方法，在该方法中拼接元素格式化输出。
-(nonnull NSString *)descriptionWithLocale:(nullable id)locale

***********************黑马笔记**********************

一、一个HTTP请求的基本要素
1.请求URL：客户端通过哪个路径找到服务器

2.请求参数：客户端发送给服务器的数据

• 比如登录时需要发送的用户名和密码

3.返回结果：服务器返回给客户端的数据

• 一般是JSON数据或者XML数据

二、基本的HTTP请求的步骤（移动客户端）
1.拼接"请求URL" + "?" + "请求参数"

• 请求参数的格式：参数名=参数值
• 多个请求参数之间用&隔开：参数名1=参数值1&参数名2=参数值2
• 比如：http://localhost:8080/MJServer/login?username=123&pwd=456

2.发送请求

3.解析服务器返回的数据

三、JSON解析
1.利用NSJSONSerialization类解析

• JSON数据（NSData） --> Foundation-OC对象（NSDictionary、NSArray、NSString、NSNumber）

• (id)JSONObjectWithData:(NSData *)data options:(NSJSONReadingOptions)opt error:(NSError **)error;

2.JSON解析规律

• { } --> NSDictionary @{ }
• [ ] --> NSArray @[ ]
• " " --> NSString @" "
• 10 --> NSNumber @10

四、NSURLConnection
1.发布异步请求01--block回调

• (void)sendAsynchronousRequest:(NSURLRequest) request
  queue:(NSOperationQueue) queue
  completionHandler:(void (^)(NSURLResponse* response, NSData* data, NSError* connectionError)) handler

• request : 需要发送的请求
• queue : 一般用主队列，存放handler这个任务
• handler : 当请求完毕后，会自动调用这个block

2.利用NSURLConnection发送请求的基本步骤
1> 创建URL
NSURL *url = [NSURL URLWithString:@"http://4234324/5345345"];

2> 创建request
NSURLRequest *request = [NSURLRequest requestWithURL:url];

3> 发送请求
[NSURLConnection sendAsynchronousRequest:request queue:queue completionHandler:
^(NSURLResponse *response, NSData *data, NSError *connectionError) {
4> 处理服务器返回的数据
}];

五、XML
1.语法
1> 文档声明
<?xml version="1.0" encoding="UTF-8" ?>

2> 元素
3> 属性
<videos>
<video name="小黄人 第01部" length="10"/>
<video name="小黄人 第01部" length="10"/>
</videos>

• videos和video是元素（节点）
• name和length叫做元素的属性
• video元素是videos元素的子元素

2.解析
1> SAX解析：逐个元素往下解析，适合大文件

• NSXMLParser

2> DOM解析：一口气将整个XML文档加载进内存，适合小文件，使用最简单

• GDataXML

六、HTTP的通信过程
1.请求
1> 请求行 : 请求方法、请求路径、HTTP协议的版本
GET /MJServer/resources/images/1.jpg HTTP/1.1

2> 请求头 : 客户端的一些描述信息

• User-Agent : 客户端的环境（软件环境）

3> 请求体 : POST请求才有这个东西

• 请求参数，发给服务器的数据

2.响应
1> 状态行（响应行）: HTTP协议的版本、响应状态码、响应状态描述
HTTP/1.1 200 OK

2> 响应头：服务器的一些描述信息

• Content-Type : 服务器返回给客户端的内容类型
• Content-Length : 服务器返回给客户端的内容的长度（比如文件的大小）

3> 实体内容（响应体）

• 服务器返回给客户端具体的数据，比如文件数据

七、HTTP的请求方法
1.GET
1> 特点

• 所有请求参数都拼接在url后面

2> 缺点

• 在url中暴露了所有的请求数据，不太安全
• url的长度有限制，不能发送太多的参数

3> 使用场合

• 如果仅仅是向服务器索要数据，一般用GET请求

4> 如何发送一个GET请求

• 默认就是GET请求
  1.URL
  NSURL *url = [NSURL URLWithString:@"http://www.baidu.com"];
  2.请求
  NSURLRequest *request = [NSURLRequest requestWithURL:url];
  3.发送请求
  [NSURLConnection sendAsynchronousRequest:request queue:[NSOperationQueue mainQueue] completionHandler:^(NSURLResponse *response, NSData *data, NSError *connectionError) {
  }];

2.POST
1> 特点

• 把所有请求参数放在请求体（HTTPBody）中
• 理论上讲，发给服务器的数据的大小是没有限制

2> 使用场合

• 除开向服务器索要数据以外的请求，都可以用POST请求
• 如果发给服务器的数据是一些隐私、敏感的数据，绝对要用POST请求

3> 如何发送一个POST请求
1.创建一个URL ： 请求路径
NSURL *url = [NSURL URLWithString:@"http://localhost:8080/MJServer/login"];

2.创建一个请求
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];
3.设置请求方法
request.HTTPMethod = @"POST";
4.设置请求体 : 请求参数
NSString *param = [NSString stringWithFormat:@"username=%@&pwd=%@", usernameText, pwdText];
5.NSString --> NSData
request.HTTPBody = [param dataUsingEncoding:NSUTF8StringEncoding];

八、NSMutableURLRequest的常用方法
1.设置超时
request.timeoutInterval = 5;
NSURLRequest是不能设置超时的，因为这个对象是不可变的

九、URL转码
1.URL中不能包含中文，得对中文进行转码(加上一堆的%)
NSString *urlStr = [NSString stringWithFormat:@"http://localhost/login?username=喝喝&pwd=123"];
urlStr = [urlStr stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
urlStr == @"http://localhost/login?username=%E5%96%9D%E5%96%9D&pwd=123"

十、数据安全
1.网络数据加密
1> 加密对象：隐私数据，比如密码、银行信息
2> 加密方案

• 提交隐私数据，必须用POST请求
• 使用加密算法对隐私数据进行加密，比如MD5
  3> 加密增强：为了加大破解的难度
• 对明文进行2次MD5 ： MD5(MD5($pass))
• 先对明文撒盐，再进行MD5 ： MD5($pass.$salt)

2.本地存储加密
1> 加密对象：重要的数据，比如游戏数据

3.代码安全问题
1> 现在已经有工具和技术能反编译出源代码：逆向工程

• 反编译出来的都是纯C语言的，可读性不高
• 最起码能知道源代码里面用的是哪些框架

2> 参考书籍：《iOS逆向工程》

3> 解决方案：发布之前对代码进行混淆

• 混淆之前
  @interface HMPerson :NSObject

• (void)run;
• (void)eat;
  @end

• 混淆之后
  @interface A :NSObject

• (void)a;
• (void)b;
  @end

十一、监测网络状态
1.主动监测监测网络状态
是否WIFI

• (BOOL)isEnableWIFI {
  return ([[Reachability reachabilityForLocalWiFi] currentReachabilityStatus] != NotReachable);
  }

是否3G

• (BOOL)isEnable3G {
  return ([[Reachability reachabilityForInternetConnection] currentReachabilityStatus] != NotReachable);
  }

2.监控网络状态
1> 监听通知
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(networkStateChange) name:kReachabilityChangedNotification object:nil];

2> 开始监听网络状态
获得Reachability对象
self.reachability = [Reachability reachabilityForInternetConnection];
开始监控网络
[self.reachability startNotifier];

3> 移除监听
[self.reachability stopNotifier];
[[NSNotificationCenter defaultCenter] removeObserver:self];

**********************状态码*************************
1xx消息

这一类型的状态码，代表请求已被接受，需要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。由于HTTP/1.0协议中没有定义任何1xx状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送1xx响应。 这些状态码代表的响应都是信息性的，标示客户应该采取的其他行动。

100 Continue
客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。
101 Switching Protocols
服务器已经理解了客户端的请求，并将通过Upgrade消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后，服务器将会切换到在Upgrade消息头中定义的那些协议。: 只有在切换新的协议更有好处的时候才应该采取类似措施。例如，切换到新的HTTP版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。
102 Processing
由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。

2xx成功

这一类型的状态码，代表请求已成功被服务器接收、理解、并接受。

200 OK
请求已成功，请求所希望的响应头或数据体将随此响应返回。
201 Created
请求已经被实现，而且有一个新的资源已经依据请求的需要而创建，且其URI已经随Location头信息返回。假如需要的资源无法及时创建的话，应当返回'202 Accepted'。
202 Accepted
服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了。:返回202状态码的响应的目的是允许服务器接受其他过程的请求（例如某个每天只执行一次的基于批处理的操作），而不必让客户端一直保持与服务器的连接直到批处理操作全部完成。在接受请求处理并返回202状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息，以及指向处理状态监视器或状态预测的指针，以便用户能够估计操作是否已经完成。
203 Non-Authoritative Information
服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。例如，包含资源的元数据可能导致原始服务器知道元信息的超集。使用此状态码不是必须的，而且只有在响应不使用此状态码便会返回200 OK的情况下才是合适的。
204 No Content
服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。响应可能通过实体头部的形式，返回新的或更新后的元信息。如果存在这些头部信息，则应当与所请求的变量相呼应。
如果客户端是浏览器的话，那么用户浏览器应保留发送了该请求的页面，而不产生任何文档视图上的变化，即使按照规范新的或更新后的元信息应当被应用到用户浏览器活动视图中的文档。
由于204响应被禁止包含任何消息体，因此它始终以消息头后的第一个空行结尾。
205 Reset Content
服务器成功处理了请求，且没有返回任何内容。但是与204响应不同，返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后，立即重置表单，以便用户能够轻松地开始另一次输入。
与204响应一样，该响应也被禁止包含任何消息体，且以消息头后的第一个空行结束。
206 Partial Content
服务器已经成功处理了部分GET请求。类似于FlashGet或者迅雷这类的HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。
该请求必须包含Range头信息来指示客户端希望得到的内容范围，并且可能包含If-Range来作为请求条件。
响应必须包含如下的头部域：

    Content-Range用以指示本次响应中返回的内容的范围；如果是Content-Type为multipart/byteranges的多段下载，则每一multipart段中都应包含Content-Range域用以指示本段的内容范围。假如响应中包含Content-Length，那么它的数值必须匹配它返回的内容范围的真实字节数。
    Date
    ETag和／或Content-Location，假如同样的请求本应该返回200响应。
    Expires, Cache-Control，和／或Vary，假如其值可能与之前相同变量的其他响应对应的值不同的话。

假如本响应请求使用了If-Range强缓存验证，那么本次响应不应该包含其他实体头；假如本响应的请求使用了If-Range弱缓存验证，那么本次响应禁止包含其他实体头；这避免了缓存的实体内容和更新了的实体头信息之间的不一致。否则，本响应就应当包含所有本应该返回200响应中应当返回的所有实体头部域。
假如ETag或Last-Modified头部不能精确匹配的话，则客户端缓存应禁止将206响应返回的内容与之前任何缓存过的内容组合在一起。
任何不支持Range以及Content-Range头的缓存都禁止缓存206响应返回的内容。

207 Multi-Status
由WebDAV(RFC 2518)扩展的状态码，代表之后的消息体将是一个XML消息，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码。

3xx重定向

这类状态码代表需要客户端采取进一步的操作才能完成请求。通常，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的Location域中指明。

当且仅当后续的请求所使用的方法是GET或者HEAD时，用户浏览器才可以在没有用户介入的情况下自动提交所需要的后续请求。客户端应当自动监测无限循环重定向（例如：A→B→C→……→A或A→A），因为这会导致服务器和客户端大量不必要的资源消耗。按照HTTP/1.0版规范的建议，浏览器不应自动访问超过5次的重定向。

300 Multiple Choices
被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。
除非这是一个HEAD请求，否则该响应应当包括一个资源特性及地址的列表的实体，以便用户或浏览器从中选择最合适的重定向地址。这个实体的格式由Content-Type定义的格式所决定。浏览器可能根据响应的格式以及浏览器自身能力，自动作出最合适的选择。当然，RFC 2616规范并没有规定这样的自动选择该如何进行。
如果服务器本身已经有了首选的回馈选择，那么在Location中应当指明这个回馈的URI；浏览器可能会将这个Location值作为自动重定向的地址。此外，除非额外指定，否则这个响应也是可缓存的。
301 Moved Permanently
被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个URI之一。如果可能，拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定，否则这个响应也是可缓存的。
新的永久性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。
如果这不是一个GET或者HEAD请求，因此浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。
注意：对于某些使用HTTP/1.0协议的浏览器，当它们发送的POST请求得到了一个301响应的话，接下来的重定向请求将会变成GET方式。
302 Found
请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。
新的临时性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。
如果这不是一个GET或者HEAD请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。
注意：虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法，但是很多现存的浏览器将302响应视作为303响应，并且使用GET方式访问在Location中规定的URI，而无视原先请求的方法。状态码303和307被添加了进来，用以明确服务器期待客户端进行何种反应。
303 See Other
对应当前请求的响应可以在另一个URI上被找到，而且客户端应当采用GET的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的URI不是原始资源的替代引用。同时，303响应禁止被缓存。当然，第二个请求（重定向）可能被缓存。
新的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。
注意：许多HTTP/1.1版以前的浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动，302状态码应该可以胜任，因为大多数的浏览器处理302响应时的方式恰恰就是上述规范要求客户端处理303响应时应当做的。
304 Not Modified
如果客户端发送了一个带条件的GET请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。304响应禁止包含消息体，因此始终以消息头后的第一个空行结尾。
该响应必须包含以下的头信息：

    Date，除非这个服务器没有时钟。假如没有时钟的服务器也遵守这些规则，那么代理服务器以及客户端可以自行将Date字段添加到接收到的响应头中去（正如RFC 2068中规定的一样），缓存机制将会正常工作。
    ETag和／或Content-Location，假如同样的请求本应返回200响应。
    Expires, Cache-Control，和／或Vary，假如其值可能与之前相同变量的其他响应对应的值不同的话。

假如本响应请求使用了强缓存验证，那么本次响应不应该包含其他实体头；否则（例如，某个带条件的GET请求使用了弱缓存验证），本次响应禁止包含其他实体头；这避免了缓存了的实体内容和更新了的实体头信息之间的不一致。
假如某个304响应指明了当前某个实体没有缓存，那么缓存系统必须忽视这个响应，并且重复发送不包含限制条件的请求。
假如接收到一个要求更新某个缓存条目的304响应，那么缓存系统必须更新整个条目以反映所有在响应中被更新的字段的值。

305 Use Proxy
被请求的资源必须通过指定的代理才能被访问。Location域中将给出指定的代理所在的URI信息，接收者需要重复发送一个单独的请求，通过这个代理才能访问相应资源。只有原始服务器才能创建305响应。
注意：RFC 2068中没有明确305响应是为了重定向一个单独的请求，而且只能被原始服务器创建。忽视这些限制可能导致严重的安全后果。
306 Switch Proxy
在最新版的规范中，306状态码已经不再被使用。
307 Temporary Redirect
请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。
新的临时性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。因为部分浏览器不能识别307响应，因此需要添加上述必要信息以便用户能够理解并向新的URI发出访问请求。
如果这不是一个GET或者HEAD请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。

4xx客户端错误

这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。除非响应的是一个HEAD请求，否则服务器就应该返回一个解释当前错误状况的实体，以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容。

如果错误发生时客户端正在传送数据，那么使用TCP的服务器实现应当仔细确保在关闭客户端与服务器之间的连接之前，客户端已经收到了包含错误信息的数据包。如果客户端在收到错误信息后继续向服务器发送数据，服务器的TCP栈将向客户端发送一个重置数据包，以清除该客户端所有还未识别的输入缓冲，以免这些数据被服务器上的应用程序读取并干扰后者。

400 Bad Request
由于包含语法错误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。
401 Unauthorized
当前请求需要用户验证。该响应必须包含一个适用于被请求资源的WWW-Authenticate信息头用以询问用户信息。客户端可以重复提交一个包含恰当的Authorization头信息的请求。如果当前请求已经包含了Authorization证书，那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问，且浏览器已经至少尝试了一次验证，那么浏览器应当向用户展示响应中包含的实体信息，因为这个实体信息中可能包含了相关诊断信息。参见RFC 2617。
402 Payment Required
该状态码是为了将来可能的需求而预留的。
403 Forbidden
服务器已经理解请求，但是拒绝执行它。与401响应不同的是，身份验证并不能提供任何帮助，而且这个请求也不应该被重复提交。如果这不是一个HEAD请求，而且服务器希望能够讲清楚为何请求不能被执行，那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应，假如它不希望让客户端获得任何信息。
404 Not Found
请求失败，请求所希望得到的资源未被在服务器上发现。没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话，应当使用410状态码来告知旧资源因为某些内部的配置机制问题，已经永久的不可用，而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。
405 Method Not Allowed
请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow头信息用以表示出当前资源能够接受的请求方法的列表。
鉴于PUT，DELETE方法会对服务器上的资源进行写操作，因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法，对于此类请求均会返回405错误。
406 Not Acceptable
请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。
除非这是一个HEAD请求，否则该响应就应当返回一个包含可以让用户或者浏览器从中选择最合适的实体特性以及地址列表的实体。实体的格式由Content-Type头中定义的媒体类型决定。浏览器可以根据格式及自身能力自行作出最佳选择。但是，规范中并没有定义任何作出此类自动选择的标准。
407 Proxy Authentication Required
与401响应类似，只不过客户端必须在代理服务器上进行身份验证。代理服务器必须返回一个Proxy-Authenticate用以进行身份询问。客户端可以返回一个Proxy-Authorization信息头用以验证。参见RFC 2617。
408 Request Timeout
请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。
409 Conflict
由于和被请求的资源的当前状态之间存在冲突，请求无法完成。这个代码只允许用在这样的情况下才能被使用：用户被认为能够解决冲突，并且会重新提交新的请求。该响应应当包含足够的信息以便用户发现冲突的源头。
冲突通常发生于对PUT请求的处理中。例如，在采用版本检查的环境下，某次PUT提交的对特定资源的修改请求所附带的版本信息与之前的某个（第三方）请求向冲突，那么此时服务器就应该返回一个409错误，告知用户请求无法完成。此时，响应实体中很可能会包含两个冲突版本之间的差异比较，以便用户重新提交归并以后的新版本。
410 Gone
被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。这样的状况应当被认为是永久性的。如果可能，拥有链接编辑功能的客户端应当在获得用户许可后删除所有指向这个地址的引用。如果服务器不知道或者无法确定这个状况是否是永久的，那么就应该使用404状态码。除非额外说明，否则这个响应是可缓存的。
410响应的目的主要是帮助网站管理员维护网站，通知用户该资源已经不再可用，并且服务器拥有者希望所有指向这个资源的远端连接也被删除。这类事件在限时、增值服务中很普遍。同样，410响应也被用于通知客户端在当前服务器站点上，原本属于某个个人的资源已经不再可用。当然，是否需要把所有永久不可用的资源标记为'410 Gone'，以及是否需要保持此标记多长时间，完全取决于服务器拥有者。
411 Length Required
服务器拒绝在没有定义Content-Length头的情况下接受请求。在添加了表明请求消息体长度的有效Content-Length头之后，客户端可以再次提交该请求。
412 Precondition Failed
服务器在验证在请求的头字段中给出先决条件时，没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息（请求头字段数据）中设置先决条件，以此避免该请求方法被应用到其希望的内容以外的资源上。
413 Request Entity Too Large
服务器拒绝处理当前请求，因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下，服务器可以关闭连接以免客户端继续发送此请求。
如果这个状况是临时的，服务器应当返回一个Retry-After的响应头，以告知客户端可以在多少时间以后重新尝试。
414 Request-URI Too Long
请求的URI长度超过了服务器能够解释的长度，因此服务器拒绝对该请求提供服务。这比较少见，通常的情况包括：

    本应使用POST方法的表单提交变成了GET方法，导致查询字符串（Query String）过长。
    重定向URI“黑洞”，例如每次重定向把旧的URI作为新的URI的一部分，导致在若干次重定向后URI超长。
    客户端正在尝试利用某些服务器中存在的安全漏洞攻击服务器。这类服务器使用固定长度的缓冲读取或操作请求的URI，当GET后的参数超过某个数值后，可能会产生缓冲区溢出，导致任意代码被执行[1]。没有此类漏洞的服务器，应当返回414状态码。

415 Unsupported Media Type
对于当前请求的方法和所请求的资源，请求中提交的实体并不是服务器中所支持的格式，因此请求被拒绝。
416 Requested Range Not Satisfiable
如果请求中包含了Range请求头，并且Range中指定的任何数据范围都与当前资源的可用范围不重合，同时请求中又没有定义If-Range请求头，那么服务器就应当返回416状态码。
假如Range使用的是字节范围，那么这种情况就是指请求指定的所有数据范围的首字节位置都超过了当前资源的长度。服务器也应当在返回416状态码的同时，包含一个Content-Range实体头，用以指明当前资源的长度。这个响应也被禁止使用multipart/byteranges作为其Content-Type。
417 Expectation Failed
在请求头Expect中指定的预期内容无法被服务器满足，或者这个服务器是一个代理服务器，它有明显的证据证明在当前路由的下一个节点上，Expect的内容无法被满足。
418 I'm a teapot
本操作码是在1998年作为IETF的传统愚人节笑话, 在RFC 2324 超文本咖啡壶控制协议中定义的，并不需要在真实的HTTP服务器中定义。
421 There are too many connections from your internet address
从当前客户端所在的IP地址到服务器的连接数超过了服务器许可的最大范围。通常，这里的IP地址指的是从服务器上看到的客户端地址（比如用户的网关或者代理服务器地址）。在这种情况下，连接数的计算可能涉及到不止一个终端用户。
422 Unprocessable Entity
请求格式正确，但是由于含有语义错误，无法响应。（RFC 4918 WebDAV）
423 Locked
当前资源被锁定。（RFC 4918 WebDAV）
424 Failed Dependency
由于之前的某个请求发生的错误，导致当前请求失败，例如PROPPATCH。（RFC 4918 WebDAV）
425 Unordered Collection
在WebDav Advanced Collections草案中定义，但是未出现在《WebDAV顺序集协议》（RFC 3658）中。
426 Upgrade Required
客户端应当切换到TLS/1.0。（RFC 2817）
449 Retry With
由微软扩展，代表请求应当在执行完适当的操作后进行重试。

5xx服务器错误

这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD请求，否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。浏览器应当向用户展示任何在当前响应中被包含的实体。

这些状态码适用于任何响应方法。

500 Internal Server Error
服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器的程序码出错时出现。
501 Not Implemented
服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。
502 Bad Gateway
作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
503 Service Unavailable
由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。如果能够预计延迟时间，那么响应中可以包含一个Retry-After头用以标明这个延迟时间。如果没有给出这个Retry-After信息，那么客户端应当以处理500响应的方式处理它。
504 Gateway Timeout
作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。
注意：某些代理服务器在DNS查询超时时会返回400或者500错误
505 HTTP Version Not Supported
服务器不支持，或者拒绝支持在请求中使用的HTTP版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。
506 Variant Also Negotiates
由《透明内容协商协议》（RFC 2295）扩展，代表服务器存在内部配置错误：被请求的协商变元资源被配置为在透明内容协商中使用自己，因此在一个协商处理中不是一个合适的重点。
507 Insufficient Storage
服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。WebDAV（RFC 4918）
509 Bandwidth Limit Exceeded
服务器达到带宽限制。这不是一个官方的状态码，但是仍被广泛使用。
510 Not Extended
获取资源所需要的策略并没有没满足。