Postman使用-基础篇

前言

本教程将结合业界广为推崇和使用的RestAPI设计典范Github API,详细介绍Postman接口测试工具的使用方法和实战技巧。

在开始这个教程之前,先聊一下为什么接口测试在现软件行业如此重要? 为什么我们要学习Postman?

现代软件行业已经从传统的万维网发展到移动互联网,云计算,如今更进入到万物互联时代。软件和网络会连接我们生活的方方面面,不同的设备,不同的软件系统之间存在各式各样的联系。而接口就是不同设备、系统之间联系的桥梁,所以接口在现今和未来的软硬件产业当中都具有越来越高的重要性和地位。

什么是接口?

IT行业从WWW万维网时代的C/S,B/S架构,到移动互联网时代的大前端时代,发展到云计算时代以IaaS(基础架构即服务),PaaS(平台即服务),SaaS(软件即服务)为代表的云端架构,如今更是进入到万物互联的物联网时代,网络连接着我们生活的方方面面,而承载这些连接的连接点,就是网络接口,接口是不同网络应用之间联系、交互、相互作用的入口和桥梁

如下图,是接口在软件系统中所处位置的示意图
image
这里UI接口和API接口分别代表用户交互接口和应用程序接口

接口测试

了解了接口的概念,我们再看什么是接口测试?

以下是百度百科中给出的定义:

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。

可以看到,针对接口定义阐述后,说明了接口测试的重点包括交互的数据、过程以及背后的业务逻辑。

再进一步看更常用的API测试的定义,这个百度没有收录,可以看下Wiki百科的定义:

API testing is a type of software testing that involves testing application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security.[1] Since APIs lack a GUI, API testing is performed at the message layer.[2] API testing is now considered critical for automating testing because APIs now serve as the primary interface to application logic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps.[3][4]

它是直接针对API进行测试的一类集成测试,注意wiki把接口测试归类在集成测试阶段。也就是说它更多是在系统集成时实施。然后也说明了接口测试不单纯是功能测试,还需考虑可靠性、安全、性能等。API接口测试和GUI测试不同,更多体现在消息层,并且因为GUI层在自动化测试上的先天劣势,API自动化目前是自动化测试领域以及敏捷、DevOps等研发模式的关键实践。

下图是著名的测试金字塔,它根据不同测试类型对软件测试进行了分层,底层是针对的代码层面的单元测试,中间是service服务测试,而现今的应用服务更多是API形式来体现,服务测试也可以理解为API的测试,上层则是针对用户界面的GUI测试。

image

这个模型体现出在自动化测试中,越底层的自动化测试所占比重应该越大,才有更好的投入产出比。中间这一层的API测试它既不像UI层那样维护成本巨大,很难跟上快速迭代的要求,同时它又比单元测试更能在业务逻辑上进行质量验证。所以现在一般认为API测试是自动化测试实施上的优先选择

HTTP协议基础

在正式开始Postman的功能介绍前,首先还是要介绍Postman的测试对象。Postman主要是针对HTTP协议接口的测试工具,所以本章首先介绍一下HTTP协议的基础知识。

HTTP,即超文本传输协议(HyperText Transfer Protocol),是互联网上应用最为广泛的一种网络协议,目前主要使用的1.1版本,基于TCP/IP通信协议来传递数据(HTML,文件、数据、API接口消息等)

http协议工作于客户端-服务器即C/S架构上
image

HTTP消息组成

客户端发送一个HTTP请求到服务器,请求消息包括以下格式:

请求行(request line)、请求头部(header)、空行和请求数据四个部分。如图

image

如下是一个请求百度首页的请求示例:

GET https://www.baidu.com/ HTTP/1.1
#请求方法  URL HTTP协议版本
Host: www.baidu.com
#请求服务器地址
#以下是消息头内容
Connection: keep-alive
#连接方式:长连接
Cache-Control: max-age=0
#请求缓存控制,需确认请求内容是否有修改
Upgrade-Insecure-Requests: 1
#支持https协议
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
#请求客户端,浏览器版本
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
#支持的响应内容类型
Accept-Encoding: gzip, deflate, br
#支持的编码类型
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
#支持的语言
Cookie: BAIDUID=C0A2...
#携带的cookie信息
#未携带请求消息体,body为空

服务器接收并处理客户端发过来的请求,返回一个HTTP的响应消息。也由四个部分组成,分别是:

响应状态行、消息报头、空行和响应正文。 如图

image

如下是百度首页的响应示例

HTTP/1.1 200 OK
#协议版本 消息状态码 状态描述
Bdpagetype: 2
Bdqid: 0x8707d7d80001f34e
#自定义消息头
Cache-Control: private
#缓存控制策略
Connection: Keep-Alive
#长连接
Content-Type: text/html;charset=utf-8
#响应内容类型
Date: Sat, 22 Dec 2018 08:54:51 GMT
#响应时间
Expires: Sat, 22 Dec 2018 08:54:51 GMT
#过期失效时间
Server: BWS/1.1
#服务器系统及版本
Set-Cookie: BDSVRTM=372; path=/
Set-Cookie: BD_HOME=1; path=/
Set-Cookie: path=/; domain=.baidu.com
#设置客户端cookie
Strict-Transport-Security: max-age=172800
#严格安全传输,有效时间
X-Ua-Compatible: IE=Edge,chrome=1
#兼容浏览器版本
Content-Length: 191722
#消息体长度
#以下消息体内容
<!Doctype html>
<html xmlns=http://www.w3.org/1999/xhtml><head>
...
HTTP方法

HTTP方法是请求消息中携带的关键信息,告知服务器本次请求希望进行的操作类型。目前在HTTP1.1版本中常见以下方法

No.方法描述
1GET请求指定的页面信息,并返回实体主体。
2HEAD类似于get请求,只不过返回的响应中没有具体的内容,用于获取报头
3POST向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
4PUT从客户端向服务器传送的数据取代指定的文档的内容。
5DELETE请求服务器删除指定的页面。
6CONNECTHTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
7TRACE回显服务器收到的请求,主要用于测试或诊断。
8PATCH从客户端向服务器传送数据,取代指定文档的部分内容
HTTP状态码

HTTP状态码定义了服务器端处理HTTP请求的结果信息,主要包含以下五类:

状态码描述
1XX已接收,待处理
2XX请求处理成功
3XX重定向,资源位置发生变化
4XX客户端请求信息错误
5XX服务端处理发生错误
1xx 消息

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

2xx 成功

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

3xx 重定向

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

4xx 客户端错误

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

5xx 服务器错误

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

详细的状态码清单可参见附录

GitHub API

本教程后续将主要使用Github API作为实战介绍API。 本章会简要介绍Github网站以及Github API。

GitHub 是一个面向开源及私有软件项目的托管平台,因为只支持 Git 作为唯一的版本库格式进行托管,故名 GitHub。也是目前全球最大的代码托管平台,可以说是程序员的圣地,号称全球最大的同性交友平台😂
(Github 国内有时会间歇性无法访问,可能需要科学上网)

github 中的一些主要概念
  1. 提交(commit):提交更改到仓库(本地Git仓库与GitHub仓库是两码事)。
  2. 提交信息(commit message):每次提交的时候,需要提供一个信息,描述这次提交都做了什么。
  3. 分支(branch):像树状图一样,每个独立的分支都是项目的一个版本,分支都可以与master合并。
  4. 主分支(master branch):所有的Git项目在最初创建时,都会默认创建出一个分支,这就是主分支。在开发中,写一个新功能的时候,都是先建立一个分支,在该分支上完成功能并测试,通过后由项目leader将该分支merge到master上。
  5. 功能分支(feature branch):没怎么用过
  6. 发布分支(release branch):如果有一个手动QA(质量管理)流程,或者必须要支持旧版本的软件时,需要一个发布分支来存放必要的补丁与更新记录。功能分支和发布分支没技术区别,只是在团队间讨论的时候,有助于区分类别。
  7. 合并(merge):merge可以将一个分支上的全部内容归并到另一个分支上,一般就是将分支merge到主分支。
  8. 标签(tag):常用于记录发布版本,在版本发布的时候,给一个tag,这样就能够记录该版本的代码是何时生成的。
  9. 查看(check out):一般就是查看某一个分支上操作的记录。
  10. 拉取(pull request):一般用来从远程仓库拉取分支中的代码到本地,也可以从本地仓库中拉取分支代码到当前工程中。
  11. 提出问题(issue):GitHub的提出问题的功能,一般遇到问题,可以将出现问题的场合,通过issue的方式记录。
  12. 维基(WIKI):一个轻量级的Web页面创建方式,创建的Web页面之间可以通过链接互相联系。GitHub中的项目通常使用WIKi进行文档记录。
  13. 克隆(clone):从GitHub上下载一个副本到本地,操作后可以pull上去。
  14. 分叉(fork):A复制一个B的项目到自己的账户下,修改后再提交,B能看到A修改的内容,但是B原本的项目是不会有变动的。
github 主界面功能

image
图片转自george_zyf的博客

Github API

目前Github API最新的V4版本是基于GraphQL的API,但常用的还是V3的Restful API

github API中几类主要资源及对应操作

User 资源

user

Repo 操作

repos

issue 操作

issues

图片来自网络

github 中的时间格式

github 中时间格式如下:

YYYY-MM-DDTHH:MM:SSZ

github 限流规则

github 为包含服务端负载压力,会对请求流量进行限制。在每个 github 的响应消息头中都会携带 github 的限流设置。

头参数含义
X-RateLimit-Limit当前每小时最大请求限制,一般未鉴权请求60次,鉴权请求5000次
X-RateLimit-Remaining当前剩余请求次数
X-RateLimit-Reset剩余限制重置时间,毫秒
请求参数与分页

请求中可以携带参数,一般包含两种参数: 路径参数查询参数
image

github API中默认支持两个分页参数:

  • page 当前显示页数
  • per_page 每页显示结果数

Postman 基础

可以用于Rest接口测试的测试工具非常多,常见的有soapUI、Jmeter、fiddler等都经常用来做接口测试。但是目前在接口测试人员中最流行,最常见还是本章向大家介绍的Postman。

Postman 的安装

Postman最早的版本,以及很长一段时间都是以Chrome插件的形式存在的。以至很多人甚至认为postman就是google的官方工具插件,我们目前能看到的大量资料也都是基于chrome的插件形式来进行介绍的。

但是目前Postman其实已经推出了独立的本地App程序,并且官方已经宣布不再支持chrome的插件形式。虽然插件版本现在还能使用,可是毕竟相比Native版本,受限于chrome浏览器的功能,很多功能在插件版本中是欠缺的,比如cookie的内建支持,代理功能,控制台功能等等。所以此处就不再介绍插件版本的安装。

本地版本的安装,其实也非常简单。从官网根据自己操作系统的类型选择相应的版本下载即可。
image

这里还有一点要注意下,在postman的官网,我们最好注册一个账号,后续在使用postman的时候很多高级功能需要用这个账号登录后才可以使用。

安装完成,在桌面上出现Postman那个pose很帅的小人图标,则安装完成。

Postman 主界面

打开Postman进入,首次会提示选择希望创建的任务类型。

image
这里有六种任务类型,我们再下面的实战中都会详细讲解,这里先简单说明一下:

  • Request是Postman软件的基础和核心,也就是通过这个功能来创建request请求,完成接口测试的核心工作。
  • Collection其实是个集合,我们可以认为是一批Request请求的集合,或者说测试集。它也是Postman一些进阶功能的基本单位
  • Environment,字面理解就是环境,其实可以认为是一些配置变量的集合,实际应用中可以起到通过不同配置区分不同测试环境的效果
    后面这三个都是Postman的高级功能
  • API documention,是通过我们调试通过的request来自动生成接口文档,便于团队的共享和接口的交付。
  • Mock server
    在我们进行接口测试或开发的时候,很多时候是需要模拟对端的接口服务器的,Mock server就起到的模拟服务器端的作用。
  • Monitor
    这是个监控功能,通过monitor我可以监控我的接口是不是正常。说白了,这其实就是个定时的接口执行功能。

大致了解下几种不同的任务类型,我们先关掉这个界面,我们再来看看主界面的功能区间
image

Banner 区域

首先是上面的菜单栏,对应功能区的各项功能,在菜单栏上都能找到对应的菜单。然后是下面的banner区域。
从左到右依次介绍:

image会打开启动时的创建窗口,用于创建六种类型的任务。

image按钮,可以用于导入外部文件,外部文件可以是postman的Collection格式文件,数据文件,以及其他的API定义文件

image则会启动Collection runner,它是一个运行器,用于运行已经建立的测试任务。我们后面会有详细介绍

image第四个按钮,可以新建tab,或者多开一个postman程序,或者runer程序。

中间image是选择使用的workspace,但这个需要账号登录,会同步云端的workspace设置。每个账号会有一个默认的workspace,workspace它是一个工作空间,大家可以理解成类似项目或者工程。

banner条右侧还有几个按钮image

  • 第一个是同步,也是在有账号的情况下,可以在多个电脑间同步workspace内的相关接口测试设计。
  • 第二个proxy,则类似前面介绍过的fiddler,提供代理抓取API功能。当然这个功能postman不像Fiddler那样丰富
  • 第三个按钮包括setting以及文档指南。 setting里是软件的本地配置
  • 第四个按钮是消息通知,很好理解,会显示一些提醒信息
  • 然后是postman的twitter,在墙后面就不要去看了
  • 最后是登录,可以用postman的账号的登录
Setting 设置

Postman 工具的使用属性和应用设置我们可以在Setting 中国进行设置。以下分别说明:

General

image

Themes

image

Shortcuts

工具快捷键
image

Data

工具数据导入导出
image

add-ons

Newman 插件下载方法
image

Sync

同步设置
image

certificates

本地证书设置
image

Proxy

本地网络代理设置
image

update

升级设置
image

about

工具**关于…**等版本信息
image

左侧边栏

image

  • filter筛选栏,筛选显示不同的消息
  • history是操作消息记录清单
  • collection如前面介绍,显示请求集合
底边状态栏

image

  • 最左面,显示和关闭左侧边栏
  • 然后是搜索功能,这个容易理解
  • 第三个是控制台,可以在这里看到消息相互的详细信息

image

  • 用户指南
  • 调整功能区显示样式
  • 快捷键清单参考
  • 帮助相关的连接
主功能区

image

主要包括上下两部分,上面是request区,下面是response区。也可以分成左右显示。

Request区域

image

request部分默认开启了一个选项卡,可以新开多个选项卡便于同时编辑。

image

默认使用的是GET方法,这也是使用最多的HTTP方法,下拉可以选择其他的方法,常用的还有哪些? POST、PUT、Delete等。

image
URL部分输入请求的地址。比如我们输入GithubAPI的根地址。

image
param是参数管理界面,在这里我们可以添加参数(有key-value,块编辑模式)。

image

Send发送请求,小箭头下send and download,会在发送以后把响应消息导出成json保存。旁边的save,保存功能,其实是把这个request作为一个case保存到collection里。

image

鉴权部分,虽然request编辑器已经足够强大可以处理鉴权消息,但是很多时候鉴权是个使用频率很高的功能,所以Postman单独把鉴权部分抽取出来,并且封装了目前的绝大部分鉴权方式

  • 继承,默认鉴权方式
  • 不鉴权
  • bearer token鉴权,一般也叫Json web token,其实就是发送一个json格式的token令牌,服务端会针对token进行解密验证
  • Basic Auth基础验证,提供用户名密码验证,postman 会自动生成authorization,常用鉴权方式
  • digest auth,摘要式认证
    在基本身份认证上面扩展了安全性,服务器为每一个连接生成一个唯一的随机数,客户端用这个随机数对密码进行MD5加密,然后返回服务器,服务器也用这个随机数对密码进行加密,然后和客户端传送过来的加密数据进行比较,如果一致就返回结果。
    它是一个二次验证的过程,会有两次认证交互消息
    客户端请求资源->服务器返回认证标示->客户端发送认证信息->服务器查验认证
  • Oauth,一般用于第三方认证,有1,2两个版本,需要提供的信息不太一样。也是常用的鉴权方式
  • Hawk 认证,是另一种认证方案,采用的叫消息码认证算法,和Digest认证类似,它也是需要二次交互的
  • AWS签名认证,是针对亚马逊的AWS公有云用户签名的认证方式
  • NTLM是微软的局域网管理认证协议

大家有个基本了解即可,一般比较常用的就是basic以及OAuth2了。

image

header就是消息头管理,可以定义头部信息。

image
Body,请求消息体。一般Post、put、patch等会更新内容的请求才会携带消息体,

image

旁边pre-script,是指在请求发送前,可以做一些预处理的工作,类似junit等单元测试框架中的setup方法,支持js脚本语法

image
Test则是在响应以后,对响应进行校验或其他处理的,类似junit框架中的teardown方法,同样支持js脚本语法

image

cookie管理postman本地cookie信息

image
code是一个方便程序员的功能,可以自动将接口请求转化成相关语言编码,可以看到支持的语言非常丰富,基本涵盖了各种主流编程语言。

Response区域

image

响应消息右上角是状态码,悬停可以看到详细解释。另外是响应时间(从发出请求到返回客户端接收的时间),以及消息大小(含消息头和消息体)。

image
响应body部分,即消息体。包括以下几个按钮

  • pretty,可以根据表现类型进行格式化显示,默认json,如果是其他格式类型,可以选择对应形式进行格式化。
  • Raw则是未格式化的形式
  • preview则是预览,就是在浏览器里渲染后呈现的样子,比如返回的是html就很直观。
  • 旁边是自动换行按钮。

右边是拷贝到剪切板和查询按钮(正则,大小写敏感、全词匹配)

其他的几个tab:

  • cookie:响应消息的cookie信息
  • header:响应消息的header头部信息
  • Test Results:在请求中添加test Script后,这里会显示测试脚本的校验结果
Postman中完成Github鉴权

从Github API文档中,我们可以看到Github API支持多种鉴权方式

  • Basic authentication
curl -u "username" https://api.github.com

这是基本鉴权方式

  • OAuth2 token (sent in a header)
curl -H "Authorization: token OAUTH-TOKEN" https://api.github.com

也支持通过在Header中携带Oauth2的token进行鉴权。在github用户设置中可以生成这个token。

个人设置 > Settings > Developer settings > Personal access tokens
image
生成后会获得一个token字串
image

  • OAuth2 token (sent as a parameter)
curl https://api.github.com/?access_token=OAUTH-TOKEN

或者通过在URL中携带token参数鉴权。

Postman中,可以在Collection中设置鉴权
image
在具体的请求消息中,可以选择Inherit auth from parent,即继承上一层的鉴权。发送请求后,可以看到已经在header中携带了鉴权的token信息
image

根据Github API的定义,对于请求有访问限制,即未鉴权的请求限制访问为每分钟60次,对于已鉴权的请求访问每分钟5000次。

我们从响应消息的消息头中可以看到这个设置,如:

X-RateLimit-Limit →5000
X-RateLimit-Remaining →4999
X-RateLimit-Reset →1546528838
Postman实现基本HTTP方法

再来看如何在Postman中实现常用的HTTP方法。还是以GithubAPI为例:

GET方法 - 获取Repo信息

GET /repos/:owner/:repo

这里是获取Github上Repo信息的API,这里有两个路径参数,owner代表用户账号,repo指需要获取的repo信息。
如图是在postman中设置路径参数的方法。
image

POST方法 - 创建Repo

创建Repo的示例(https://developer.github.com/v3/repos/#create)

POST /user/repos

这里是一个创建hello world的Repo的请求消息体示例

{
  "name": "Hello-World",
  "description": "This is your first repository",
  "homepage": "https://github.com",
  "private": false,
  "has_issues": true,
  "has_projects": true,
  "has_wiki": true
}

这里name是必填字段,其他是repo的属性设置。
在Postman中如图提交,返回状态码201 created,即可创建一个Hello world的Repo
image

在Github中,可以看到账号下新增了一个hello world的repo,并且包含有已设置的issue、projects、wiki这几个栏目
image

PATCH方法 - 修改Repo

GitHub可以通过PATCH方法来对Repo进行修改.PATCH方法和PUT方法都是update的修改方法,但PATCH方法更多用在部分修改的场景下,PUT方法则更多是整体替换。

PATCH /repos/:owner/:repo

比如上例中hello world这个repo修改Repo中的部分信息,可以去除projects和wiki这两个栏目
消息体:

{
  "name": "Hello-World",
  "description": "This is your first repository",
  "homepage": "https://github.com",
  "has_projects": false,
  "has_wiki": false
}

Postman中如图:
image

回到Github,可以看到Repo中对应的栏目已经不见了
image

PUT方法 - 设置或替换Topic

Topic是Github上Repo的搜索关键字,便于用户进行repo查询。

PUT /repos/:owner/:repo/topics

Github API设置topic的api是使用put方法提交一个topic数组,如

{
  "names": [
    "restapi",
    "atom",
    "chengxiaqiucao"
  ]
}

这时在Postman中提交,会发现有如下报错:
image

这是因为Github API要求设置topic时,需要在header中设置accept字段,取值:

application/vnd.github.mercy-preview+json

正确设置后,则可以看到设置成功,返回200 OK
image

image

大家可能会发现一个小bug,当设置的topic存在大写字符时,会出现格式报错。比如大家参照官方示例设置"API"这样的topic,会发现设置不成功。大家可以尝试一下。

DELETE方法 - 删除Repo

Github API中,使用delete方法可以删除repo

DELETE /repos/:owner/:repo

删除成功后,返回204.
image
此时再查询账号,应该发现Hello-World这个repo已经被删除了

结语及预告

至此,我们通过Github API中几个实际的例子,学习了如何通过Postman来完成一些基本的HTTP方法的请求发送和响应查看,通过查看结果状态码或响应内容来判断结果正确性。

当然Postman的功能远不止于此,API接口测试中也还有很多复杂的场景需要特别处理。
欢迎大家继续关注 《玩转Postman - 进阶篇》。在进阶篇中我们将继续深入讲解Postman的进阶功能,并结合一些复杂的实例场景来学习:

  • Postman 的变量类型及其作用域
  • 环境与 Collection;
  • Postman 如何通过内建脚本实现接口预处理
  • Postman 实现测试结果的脚本校验;
  • 如何实现接口的关联测试
  • Postman 中的 JavaScript 扩展

附录

HTTP状态码详解(译自Wiki百科,目前所见最全面的解释)
外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

1xx 消息

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

100 Continue

服务器已经接收到请求头,并且客户端应继续发送请求主体(在需要发送身体的请求的情况下:例如,POST请求),或者如果请求已经完成,忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。要使服务器检查请求的头部,客户端必须在其初始请求中发送Expect: 100-continue作为头部,并在发送正文之前接收100 Continue状态代码。响应代码417期望失败表示请求不应继续。

101 Switching Protocols

服务器已经理解了客户端的请求,并将通过Upgrade消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后,服务器将会切换到在Upgrade消息头中定义的那些协议。
只有在切换新的协议更有好处的时候才应该采取类似措施。例如,切换到新的HTTP版本(如HTTP/2)比旧版本更有优势,或者切换到一个实时且同步的协议(如WebSocket)以传送利用此类特性的资源。

102 Processing(WebDAV;RFC 2518)

WebDAV请求可能包含许多涉及文件操作的子请求,需要很长时间才能完成请求。该代码表示​​服务器已经收到并正在处理请求,但无响应可用。[6]这样可以防止客户端超时,并假设请求丢失。

2xx 成功

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

200 OK

请求已成功,请求所希望的响应头或数据体将随此响应返回。实际的响应将取决于所使用的请求方法。在GET请求中,响应将包含与请求的资源相对应的实体。在POST请求中,响应将包含描述或操作结果的实体。

201 Created

请求已经被实现,而且有一个新的资源已经依据请求的需要而创建,且其URI已经随Location头信息返回。假如需要的资源无法及时创建的话,应当返回’202 Accepted’。

202 Accepted

服务器已接受请求,但尚未处理。最终该请求可能会也可能不会被执行,并且可能在处理发生时被禁止。

203 Non-Authoritative Information(自HTTP / 1.1起)

服务器是一个转换代理服务器(transforming proxy,例如网络加速器),以200 OK状态码为起源,但回应了原始响应的修改版本。

204 No Content

服务器成功处理了请求,没有返回任何内容。

205 Reset Content

服务器成功处理了请求,但没有返回任何内容。与204响应不同,此响应要求请求者重置文档视图。

206 Partial Content(RFC 7233)

服务器已经成功处理了部分GET请求。类似于FlashGet或者迅雷这类的HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。

207 Multi-Status(WebDAV;RFC 4918)

代表之后的消息体将是一个XML消息,并且可能依照之前子请求数量的不同,包含一系列独立的响应代码。

208 Already Reported (WebDAV;RFC 5842)

DAV绑定的成员已经在(多状态)响应之前的部分被列举,且未被再次包含。

226 IM Used (RFC 3229)

服务器已经满足了对资源的请求,对实体请求的一个或多个实体操作的结果表示。

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

要求客户端执行临时重定向(原始描述短语为“Moved Temporarily”)。由于这样的重定向是临时的,客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下,这个响应才是可缓存的。
新的临时性的URI应当在响应的Location域中返回。除非这是一个HEAD请求,否则响应的实体中应当包含指向新的URI的超链接及简短说明。
如果这不是一个GET或者HEAD请求,那么浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。
注意:虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法,但是很多现存的浏览器将302响应视作为303响应,并且使用GET方式访问在Location中规定的URI,而无视原先请求的方法。因此状态码303和307被添加了进来,用以明确服务器期待客户端进行何种反应。

303 See Other

对应当前请求的响应可以在另一个URI上被找到,当响应于POST(或PUT / DELETE)接收到响应时,客户端应该假定服务器已经收到数据,并且应该使用单独的GET消息发出重定向。[23]这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的URI不是原始资源的替代引用。同时,303响应禁止被缓存。当然,第二个请求(重定向)可能被缓存。
新的URI应当在响应的Location域中返回。除非这是一个HEAD请求,否则响应的实体中应当包含指向新的URI的超链接及简短说明。
注意:许多HTTP/1.1版以前的浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动,302状态码应该可以胜任,因为大多数的浏览器处理302响应时的方式恰恰就是上述规范要求客户端处理303响应时应当做的。

304 Not Modified

表示资源未被修改,因为请求头指定的版本If-Modified-Since或If-None-Match。在这种情况下,由于客户端仍然具有以前下载的副本,因此不需要重新传输资源。

305 Use Proxy

被请求的资源必须通过指定的代理才能被访问。Location域中将给出指定的代理所在的URI信息,接收者需要重复发送一个单独的请求,通过这个代理才能访问相应资源。只有原始服务器才能创建305响应。许多HTTP客户端(像是Mozilla和Internet Explorer)都没有正确处理这种状态代码的响应,主要是出于安全考虑。
注意:RFC 2068中没有明确305响应是为了重定向一个单独的请求,而且只能被原始服务器建立。忽视这些限制可能导致严重的安全后果。

306 Switch Proxy

在最新版的规范中,306状态码已经不再被使用。最初是指“后续请求应使用指定的代理”。

307 Temporary Redirect

在这种情况下,请求应该与另一个URI重复,但后续的请求应仍使用原始的URI。 与302相反,当重新发出原始请求时,不允许更改请求方法。 例如,应该使用另一个POST请求来重复POST请求。

308 Permanent Redirect (RFC 7538)

请求和所有将来的请求应该使用另一个URI重复。 307和308重复302和301的行为,但不允许HTTP方法更改。 例如,将表单提交给永久重定向的资源可能会顺利进行。

4xx 客户端错误

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

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

400 Bad Request

由于明显的客户端错误(例如,格式错误的请求语法,太大的大小,无效的请求消息或欺骗性路由请求),服务器不能或不会处理该请求。

401 Unauthorized(RFC 7235)

参见:HTTP基本认证、HTTP摘要认证
类似于403 Forbidden,401语义即“未认证”,即用户没有必要的凭据。该状态码表示当前请求需要用户验证。该响应必须包含一个适用于被请求资源的WWW-Authenticate信息头用以询问用户信息。客户端可以重复提交一个包含恰当的Authorization头信息的请求。如果当前请求已经包含了Authorization证书,那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问,且浏览器已经至少尝试了一次验证,那么浏览器应当向用户展示响应中包含的实体信息,因为这个实体信息中可能包含了相关诊断信息。
注意:当网站(通常是网站域名)禁止IP地址时,有些网站状态码显示的401,表示该特定地址被拒绝访问网站。

402 Payment Required

该状态码是为了将来可能的需求而预留的。该状态码最初的意图可能被用作某种形式的数字现金或在线支付方案的一部分,但几乎没有哪家服务商使用,而且这个状态码通常不被使用。如果特定开发人员已超过请求的每日限制,Google Developers API会使用此状态码。

403 Forbidden

主条目:HTTP 403
服务器已经理解请求,但是拒绝执行它。与401响应不同的是,身份验证并不能提供任何帮助,而且这个请求也不应该被重复提交。如果这不是一个HEAD请求,而且服务器希望能够讲清楚为何请求不能被执行,那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应,假如它不希望让客户端获得任何信息。

404 Not Found

主条目:HTTP 404
请求失败,请求所希望得到的资源未被在服务器上发现,但允许用户的后续请求。[35]没有信息能够告诉用户这个状况到底是暂时的还是永久的。假如服务器知道情况的话,应当使用410状态码来告知旧资源因为某些内部的配置机制问题,已经永久的不可用,而且没有任何可以跳转的地址。404这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。

405 Method Not Allowed

请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow头信息用以表示出当前资源能够接受的请求方法的列表。例如,需要通过POST呈现数据的表单上的GET请求,或只读资源上的PUT请求。
鉴于PUT,DELETE方法会对服务器上的资源进行写操作,因而绝大部分的网页服务器都不支持或者在默认配置下不允许上述请求方法,对于此类请求均会返回405错误。

406 Not Acceptable

参见:内容协商
请求的资源的内容特性无法满足请求头中的条件,因而无法生成响应实体,该请求不可接受。[36]
除非这是一个HEAD请求,否则该响应就应当返回一个包含可以让用户或者浏览器从中选择最合适的实体特性以及地址列表的实体。实体的格式由Content-Type头中定义的媒体类型决定。浏览器可以根据格式及自身能力自行作出最佳选择。但是,规范中并没有定义任何作出此类自动选择的标准。

407 Proxy Authentication Required(RFC 2617)

与401响应类似,只不过客户端必须在代理服务器上进行身份验证。[37]代理服务器必须返回一个Proxy-Authenticate用以进行身份询问。客户端可以返回一个Proxy-Authorization信息头用以验证。

408 Request Timeout

请求超时。根据HTTP规范,客户端没有在服务器预备等待的时间内完成一个请求的发送,客户端可以随时再次提交这一请求而无需进行任何更改。

409 Conflict

表示因为请求存在冲突无法处理该请求,例如多个同步更新之间的编辑冲突。

410 Gone

表示所请求的资源不再可用,将不再可用。当资源被有意地删除并且资源应被清除时,应该使用这个。在收到410状态码后,用户应停止再次请求资源。但大多数服务端不会使用此状态码,而是直接使用404状态码。

411 Length Required

服务器拒绝在没有定义Content-Length头的情况下接受请求。在添加了表明请求消息体长度的有效Content-Length头之后,客户端可以再次提交该请求。

412 Precondition Failed(RFC 7232)

服务器在验证在请求的头字段中给出先决条件时,没能满足其中的一个或多个。这个状态码允许客户端在获取资源时在请求的元信息(请求头字段数据)中设置先决条件,以此避免该请求方法被应用到其希望的内容以外的资源上。

413 Request Entity Too Large(RFC 7231)

前称“Request Entity Too Large”,表示服务器拒绝处理当前请求,因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下,服务器可以关闭连接以免客户端继续发送此请求。
如果这个状况是临时的,服务器应当返回一个Retry-After的响应头,以告知客户端可以在多少时间以后重新尝试。

414 Request-URI Too Long(RFC 7231)

前称“Request-URI Too Long”,表示请求的URI长度超过了服务器能够解释的长度,因此服务器拒绝对该请求提供服务。通常将太多数据的结果编码为GET请求的查询字符串,在这种情况下,应将其转换为POST请求。这比较少见,通常的情况包括:
本应使用POST方法的表单提交变成了GET方法,导致查询字符串过长。
重定向URI“黑洞”,例如每次重定向把旧的URI作为新的URI的一部分,导致在若干次重定向后URI超长。
客户端正在尝试利用某些服务器中存在的安全漏洞攻击服务器。这类服务器使用固定长度的缓冲读取或操作请求的URI,当GET后的参数超过某个数值后,可能会产生缓冲区溢出,导致任意代码被执行。没有此类漏洞的服务器,应当返回414状态码。

415 Unsupported Media Type

对于当前请求的方法和所请求的资源,请求中提交的互联网媒体类型并不是服务器中所支持的格式,因此请求被拒绝。例如,客户端将图像上传格式为svg,但服务器要求图像使用上传格式为jpg。

416 Requested Range Not Satisfiable(RFC 7233)

前称“Requested Range Not Satisfiable”。客户端已经要求文件的一部分(Byte serving),但服务器不能提供该部分。例如,如果客户端要求文件的一部分超出文件尾端。

417 Expectation Failed

在请求头Expect中指定的预期内容无法被服务器满足,或者这个服务器是一个代理服显的证据证明在当前路由的下一个节点上,Expect的内容无法被满足。

418 I’m a teapot(RFC 2324)

本操作码是在1998年作为IETF的传统愚人节笑话, 在RFC 2324超文本咖啡壶控制协议’中定义的,并不需要在真实的HTTP服务器中定义。当一个控制茶壶的HTCPCP收到BREW或POST指令要求其煮咖啡时应当回传此错误。这个HTTP状态码在某些网站(包括Google.com)与项目(如Node.js、ASP.NET和Go语言)中用作彩蛋。

420 Enhance Your Caim

Twitter Search与Trends API在客户端被限速的情况下返回。

421 Misdirected Request (RFC 7540)

该请求针对的是无法产生响应的服务器(例如因为连接重用)。

422 Unprocessable Entity(WebDAV;RFC 4918 )

请求格式正确,但是由于含有语义错误,无法响应。

423 Locked(WebDAV;RFC 4918)

当前资源被锁定。

424 Failed Dependency(WebDAV;RFC 4918)

由于之前的某个请求发生的错误,导致当前请求失败,例如PROPPATCH。

425 Unordered Collection

在WebDAV Advanced Collections Protocol中定义,但Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol中并不存在。

426 Upgrade Required(RFC 2817)

客户端应当切换到TLS/1.0,并在HTTP/1.1 Upgrade header中给出。

428 Precondition Required (RFC 6585)

原服务器要求该请求满足一定条件。这是为了防止“‘未更新’问题,即客户端读取(GET)一个资源的状态,更改它,并将它写(PUT)回服务器,但这期间第三方已经在服务器上更改了该资源的状态,因此导致了冲突。”

429 Too Many Requests (RFC 6585)

用户在给定的时间内发送了太多的请求。旨在用于网络限速。

431 Request Header Fields Too Large (RFC 6585)

服务器不愿处理请求,因为一个或多个头字段过大。

444 No Response

Nginx上HTTP服务器扩展。服务器不向客户端返回任何信息,并关闭连接(有助于阻止恶意软件)。

450 Blocked by Windows Parental Controls

这是一个由Windows家庭控制(Microsoft)HTTP阻止的450状态代码的示例,用于信息和测试。

451 Unavailable For Legal Reasons

该访问因法律的要求而被拒绝,由IETF在2015核准后新增加。

494 Request Header Too Large

在错误代码431提出之前Nginx上使用的扩展HTTP代码。

5xx 服务器错误

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

500 Internal Server Error

通用错误消息,服务器遇到了一个未曾预料的状况,导致了它无法完成对请求的处理。没有给出具体错误信息。

501 Not Implemented

服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法,并且无法支持其对任何资源的请求。(例如,网络服务API的新功能)

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版本。[63]这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。

506 Variant Also Negotiates(RFC 2295)

由《透明内容协商协议》(RFC 2295)扩展,代表服务器存在内部配置错误,被请求的协商变元资源被配置为在透明内容协商中使用自己,因此在一个协商处理中不是一个合适的重点。

507 Insufficient Storage(WebDAV;RFC 4918)

服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。

508 Loop Detected (WebDAV;RFC 5842)

服务器在处理请求时陷入死循环。 (可代替 208状态码)

510 Not Extended(RFC 2774)

获取资源所需要的策略并没有被满足。

511 Network Authentication Required (RFC 6585)

客户端需要进行身份验证才能获得网络访问权限,旨在限制用户群访问特定网络。(例如连接WiFi热点时的强制网络门户)

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:/a/898889.html

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

电子木鱼小游戏小程序源码系统 带完整的安装代码包以及搭建部署教程

系统概述 在快节奏的生活中&#xff0c;人们越来越注重内心的平静与放松。电子木鱼小游戏小程序正是基于这一需求而诞生的&#xff0c;它将传统的木鱼文化与现代科技相结合&#xff0c;为用户提供了一个简单、方便、有趣的冥想与放松工具。通过敲击屏幕上的虚拟木鱼&#xff0…

Windows 下 golang 多版本管理

三年前的旧文&#xff0c;最新要切版本&#xff0c;翻了出来&#xff0c;现在依然有用&#xff0c;分享出来~ 当前 golang 的各个版本还有些不兼容的问题&#xff0c;最近遇到 go-micro 框架只能运行在 go1.13~1.14 的版本情况&#xff0c;而我本地 windows 环境安装的 Golang …

C++ [项目] 愤怒的小鸟

现在才发现C游戏的支持率这么高&#xff0c;那就发几篇吧 零、前情提要 此篇为 制作,由于他没有CSDN,于是由我代发 一、基本介绍 支持Dev-C5.11版本(务必调为英文输入法),基本操作看游戏里的介绍,怎么做的……懒得说,能看懂就看注释,没有的自己猜,如果你很固执……私我吧 …

蘑菇书(EasyRL)学习笔记(1)

1、强化学习概述 强化学习&#xff08;reinforcement learning&#xff0c;RL&#xff09;讨论的问题是智能体&#xff08;agent&#xff09;怎么在复杂、不确定的环 境&#xff08;environment&#xff09;里面去最大化它能获得的奖励。如下图所示&#xff0c;强化学习…

huggingface的数据集下载(linux下clone)

1. 安装lfs sudo apt-get install git-lfs 或者 apt-get install git-lfs 2. git lfs install git lfs install 3. git clone dataset包 第2&#xff0c;3步骤的截图如下&#xff1a;

Kubernetes学习笔记

Kubernetes学习笔记 API格式前缀API组API版本 Pod概念优势局限性创建Pod ReplicationController概念配置Pod模板 Kubernetes架构概述节点定义管理节点名称唯一性节点自注册手动节点管理节点状态节点心跳节点控制器逐出速率限制资源容量跟踪 API Kubernetes把其管理的资源均视为…

现代数字信号处理I-P4 CRLB+LMMSE 学习笔记

目录 学习资料视频链接&#xff1a; 1. 估计参数的CRLB回顾 2. 参数变换下的CRLB拓展 3. 矢量参数下的CRLB扩展 3.1 矢量参数下的CRLB公式 3.2 两个矩阵不等式关系的意义说明 3.3 矢量参数下CRLB公式的证明过程 4. 线性估计 重点注意事项&#xff1a;此处的线性估计&am…

零磁通电流探头的原理

在电力电子和自动化控制领域&#xff0c;电流测量的准确性至关重要。传统的开环式电流探头&#xff0c;尽管在交流电流测量中表现出色&#xff0c;但在直流或大电流测量时&#xff0c;常面临磁芯饱和、剩磁及温度变化带来的测量误差问题。为此&#xff0c;零磁通电流探头&#…

​​Spring6梳理17——基于XML的自动装配

以上笔记来源&#xff1a; 尚硅谷Spring零基础入门到进阶&#xff0c;一套搞定spring6全套视频教程&#xff08;源码级讲解&#xff09;https://www.bilibili.com/video/BV1kR4y1b7Qc 目录 ①引入 ②场景模拟 2.1 创建UserController类文件 2.2 创建UserService接口文件 2…

同济大学计算机考研

文章目录 一、初试1.院校情况1.复试名单2.报录比3.学硕人数 二、复试(一) 数据库2016复试题一、选择题 &#xff08;Multiple Choices&#xff09;二、简答题 2018复试题一、选择题&#xff08;一&#xff09;数据库&#xff1a;1-10&#xff08;二&#xff09;C语言&#xff1…

植物大战僵尸杂交版游戏分享

植物大战僵尸杂交版游戏下载&#xff1a;夸克网盘分享 无捆绑之类的隐形消费&#xff0c;下载即玩

【软件工程】过程和生命周期的建模

&#x1f308; 个人主页&#xff1a;十二月的猫-CSDN博客 &#x1f525; 系列专栏&#xff1a; &#x1f3c0;软件开发必练内功_十二月的猫的博客-CSDN博客 &#x1f4aa;&#x1f3fb; 十二月的寒冬阻挡不了春天的脚步&#xff0c;十二点的黑夜遮蔽不住黎明的曙光 目录 1. 过…

springboot整合xxl-job实现定时任务

搭建调度中心xxl-job-admin 下载调度中心项目 gitee github 注&#xff1a; 下载项目的版本应与集成项目pom引用xxl-job版本号对应上。 执行初始化数据库SQL sql路径&#xff1a; doc/db/tables_xxl_job.sql XXL-JOB调度模块基于自研调度组件并支持集群部署&#xff0c;调…

flv格式如何转换mp4?将flv转换成MP4格式的9种转换方法

flv格式如何转换mp4&#xff1f;在进行flv转MP4的转换之前&#xff0c;了解两种格式的基本特点和差异也是至关重要的。flv格式以其流媒体传输的高效性和对Flash Player的依赖而闻名&#xff0c;而MP4则以其广泛的兼容性、高质量的音视频同步以及灵活的编码选项而著称。通过对比…

vue mixins使用示例

混入 (mixins)&#xff1a; 是一种分发 Vue 组件中可以复用功能灵活的方式。混入对象可以包含任意组件的选项。当组件使用混入对象的时候&#xff0c;所有混入对象的选项将被混入该组件本身的选项。 使用示例: 定义使用的mixins对象 export const HelloWorldMixin {data() {r…

Chromium 沙盒Sandbox源码介绍(3)

本篇主要说下沙箱的环境变量策略【Environment】&#xff1a; 一、环境变量&#xff1a; getEnvironmentStrings 函数返回指向内存块的指针&#xff0c;该内存块包含调用进程的环境变量 (系统和用户环境变量) getEnvironmentStrings 函数 (processenv.h) - Win32 apps | Mic…

ubuntu2204配置cuda

ubuntu2204配置cuda ✅系统版本&#xff1a;ubuntu22.04 LTS ✅显卡&#xff1a;英伟达2070S ✅CPU&#xff1a;i9 10900 ✅主板&#xff1a;戴尔品牌机 教程&#x1f4a8;&#x1f4a8;&#x1f4a8;&#x1f4a8;&#xff1a; ps&#xff1a;本人按照该方法一遍成功&#…

EasyX:初始化绘图窗口initgraph() 的使用

前言 学习使用EasyX图形库的initgraph窗口函数。 一、创建新项目 二、创建C空项目 三、找个地方存一下&#xff0c;创建 四、如果左边的框框找不到 五、点视图&#xff0c;然后点解决方案管理器&#xff0c;左边的框框就出来了 六、源文件添加新建项 七、给文件取个名&#x…

qt QPushButton详解

QPushButton是Qt Widgets模块中的一个基本控件&#xff0c;用于提供可点击的按钮。它是用户界面中最为常见和常用的控件之一&#xff0c;通过点击按钮&#xff0c;用户可以触发特定的应用程序操作。 重要方法 QPushButton(const QIcon &icon, const QString &text, QWi…

数据通信与网络课程展示图谱问答展示系统

&#x1f4a1; 你是否在学习“数据通信与网络”时感觉知识点分散&#xff0c;难以整理&#xff1f;学了后面忘记前面&#xff0c;知识点的关联也难以梳理&#xff1f;别担心&#xff01;我们公司推出的【数据通信与网络课程展示图谱问答系统】帮你一次性解决所有问题&#xff0…