当前位置：首页 > news >正文

由enctype-引出post与get的关系，最后深究至请求/响应报文

news 来源：原创 2025/6/1 10:11:53

本篇载自我的笔记，本次为第二次复习。我觉得我有能力理一下思路了。

--- 笔记截图。

enctype

HTML 表单的 enctype（Encode Type，编码类型）属性用于控制表单数据在提交到服务器时的编码方式，不同取值的详细解析如下：

1. enctype="application/x-www-form-urlencoded"（默认值）

编码方式：表单数据会被编码为 “名称 / 值” 对的形式，即 key=value，多个值之间用 & 符号连接（如 name=John&age=30）。所有非字母数字字符会被转义（例如空格转为 %20，特殊符号转为 %xx 形式）。
适用场景：
请求方法：支持 GET 和 POST。若为 GET，数据会拼接到 URL 中；若为 POST，数据会放在请求体中。

2. enctype="multipart/form-data"

编码方式：表单数据会被编码成 多个独立的数据块（消息部分），每个表单控件对应一个数据块，块与块之间用随机生成的边界字符串（如 --boundary）分隔。这种方式不会对数据进行 URL 编码，支持二进制数据（如文件）。
适用场景：
请求方法：必须使用 POST。因为数据量可能较大且包含二进制内容，不适合通过 URL（GET）传递。

3. enctype="text/plain"

编码方式：表单数据以 纯文本形式 编码，仅对空格进行简单处理（转换为加号 +），不对其他字符转义（如特殊符号保持原样）。
适用场景：
请求方法：支持 GET 和 POST，但因编码过于简单，无法处理复杂数据（如特殊符号、二进制文件），使用场景受限。

总结对比

enctype 值	编码特点	典型用途	请求方法限制
application/x-www-form-urlencoded	键值对，全面转义	普通文本表单（如登录、注册）	无（GET/POST均可）
multipart/form-data	分块传输，支持二进制数据	文件上传、含文件的表单	必须为POST
text/plain	纯文本，仅简单处理空格	极少用（简单文本调试）	无（GET/POST均可）

理解这些区别后，可根据表单内容（是否含文件、特殊字符等）选择合适的

enctype，确保服务器能正确解析数据。

GET与POST的区别

在 HTTP 协议中，GET 和 POST 是两种常用的请求方法，它们的作用及特点如下：

一、GET 的作用

核心作用：从指定服务器获取数据，本质类似 “读取” 操作，例如获取网页内容、查询信息、加载资源等。
数据传输方式：
- 将数据以键值对形式附加在 URL 末尾（如 https://example.com/search?q=keyword&page=1），通过 URL 传递给服务器。
- 数据会被编码为 application/x-www-form-urlencoded 形式（默认编码），非字母数字字符会被转义（如空格转 +，特殊符号转 %xx）。
典型场景：
- 搜索引擎搜索内容，浏览器通过 GET 请求获取搜索结果。
- 加载静态资源（如图片、CSS、JS 文件），或简单查询数据（如分页加载商品列表）。
特点：
- 请求可被缓存，生成的 URL 可保存为书签或被浏览器记录在历史中。
- 有长度限制（受 URL 长度制约，通常为 2048 字符左右），不适合传输大量或敏感数据（因参数暴露在 URL 中）。

二、POST 的作用

核心作用：向服务器提交数据，用于修改服务器状态，例如提交表单、上传文件、创建或更新资源等。
数据传输方式：
- 数据放在请求体（Request Body）中，与 HTTP 请求一同发送给服务器。
- 支持多种编码方式：
  - 若需上传文件或二进制数据，需用 multipart/form-data 编码（此时请求方法必须为 POST），数据被拆分为多个独立部分传输。
  - 普通文本数据也可用 application/x-www-form-urlencoded 编码（类似 GET，但数据在请求体中）；text/plain 编码则以纯文本传输（极少用）。
典型场景：
- 用户登录、注册时提交账号密码（数据在请求体，相对安全）。
- 上传文件、图片，或提交复杂表单（如含大量文本、多选框等）。
特点：
- 数据不暴露在 URL 中，相对安全（但仍需结合 HTTPS 进一步加密）。
- 无长度限制（理论上可传输大量数据），请求通常不会被缓存。

三、结合 enctype 理解 GET/POST 的适用场景

当 enctype="application/x-www-form-urlencoded"（默认值）：
- GET 和 POST 都可使用这种编码，但 GET 数据在 URL，POST 数据在请求体。简单文本数据提交两者皆可，但涉及敏感信息或稍大量数据时更适合 POST。
当 enctype="multipart/form-data"：
- 必须使用 POST。因为该编码用于上传文件、二进制数据等复杂场景，数据量通常较大且需分块传输，只有 POST 支持这种方式（GET 无法处理）。
当 enctype="text/plain"：
- GET 和 POST 也可使用，但该编码过于简单（仅简单处理空格），实际中很少用，仅在极简单文本传输时考虑。

HTTP报文

HTTP 消息结构 | 菜鸟教程 --- 通过这个深入了解报文

直接看菜鸟，你可以获得与众不同的体验。

一、什么是 HTTP 报文？（核心总览）

定义

HTTP 报文是客户端（如浏览器）与服务器之间通信的数据载体，分为两种：

请求报文（客户端→服务器，比如你输入网址时发送的消息）
响应报文（服务器→客户端，比如服务器返回的网页数据）

通用结构（无论是请求还是响应，都遵循这个格式）：

起始行（First Line）头部（Headers）空行（必须有，分隔头部和主体）主体（Body，可选）

可以类比为一封 “信”：

起始行：像信封上的 “收信地址”（请求）或 “回信状态”（响应）
头部：像信封上的 “邮编、寄件人信息”（附加说明）
主体：像信的 “正文”（真正的内容）

1、响应报文的三大核心部分（重点！）

1. 响应行（Status Line）

位置：响应报文的第一行，唯一且必须存在。
作用：告诉客户端 “服务器处理请求的结果如何”。
结构：由三个部分组成，用空格分隔：

HTTP版本号 状态码 状态消息

示例（来自之前的天气 API 响应）：

HTTP/1.1 200 OK

- HTTP 版本号：如 HTTP/1.1、HTTP/2，表示使用的 HTTP 协议版本。
- 状态码（关键！）：三位数，分类如下：
  - 1xx：临时响应（如 101 切换协议）
  - 2xx：成功（如 200 OK 表示请求成功）
  - 3xx：重定向（如 301 永久重定向）
  - 4xx：客户端错误（如 404 Not Found 表示资源不存在）
  - 5xx：服务器错误（如 500 Internal Server Error 表示服务器崩了）
- 状态消息：对状态码的简短描述（如 OK、Not Found），方便人类阅读，服务器可自定义（但状态码是固定的）。

2. 响应头部（Headers）

位置：响应行之后，空行之前，由多行键: 值组成。
作用：附加说明 “如何处理响应体” 或 “服务器的额外信息”。
常见示例：

Content-Type: application/json // 响应体的格式（如JSON、HTML、图片）Content-Length: 150 // 响应体的字节长度Date: Tue, 29 Apr 2025 12:00:00 GMT // 服务器生成响应的时间 Server: Apache/2.4.52// 服务器软件名称

关键头部 Content-Type：必须存在，告诉客户端 “用什么方式解析响应体”（比如 text/html 表示 HTML 网页，image/png 表示图片）。

3. 响应体（Body）

位置：空行之后，可选（有些响应没有体，比如 204 No Content 状态码）。
作用：服务器返回的具体数据内容，是响应的 “正文”。
常见内容：
- 网页 HTML（如你访问百度时，服务器返回的 HTML 代码）
- 接口数据（如 JSON、XML，比如天气 API 返回的天气信息）
- 二进制文件（如图片、视频、PDF，直接传输字节数据）
示例（天气 API 的响应体，JSON 格式）：

{ "city": "北京","temperature": "25°C" 
}

注意：
- 响应体是否存在，由状态码决定（如 200 OK 通常有体，302 重定向可能没有体）。
- 响应体的长度由 Content-Length 头部指定，或通过 Transfer-Encoding: chunked 分块传输（用于大文件）。

2、请求报文

请求报文大体上与响应报文差不多。

3、对比请求报文和响应报文（避免混淆）

部分	请求报文	响应报文
起始行	请求行（Method URL Version）例：GET /weather?city=北京 HTTP/1.1	响应行（Version StatusCode StatusMessage）例： HTTP/1.1 200 OK
头部	包含客户端信息（如 User-Agent、Cookie）	包含服务器信息（如 Server、Content-Type）
主体（Body）	可选（GET请求没有体， POST请求有体）	可选（部分状态码没有体，如204）

通过浏览器开发者工具观察真实的报文，是理解这些概念的最快方式！有了这个基础，后续学习 HTTP 协议会更轻松～

二、以报文的视角分析get与post

GET 和 POST 方法的核心区别，以及它们在响应报文中的关联逻辑。以下是系统化讲解：

一、核心本质：GET 和 POST 是什么？

共同点：都是 HTTP 请求方法（用于告诉服务器 “客户端想做什么”）。
核心区别：
- GET：获取资源（从服务器 “拿” 数据）。
- POST：提交资源（向服务器 “发送” 数据，让服务器处理或存储）。

二、在请求报文中的具体区别（重点！）

1. 请求行（第一行）的差异

方法

请求行格式

示例（以获取 / 提交天气数据为例）

GET

GET URL?参数 HTTP版本

GET /weather?city=北京 HTTP/1.1

（参数在 URL 中）

POST

POST URL HTTP版本

POST /submit-weather HTTP/1.1

（参数在请求体中）

关键区别：
- GET 的参数必须附加在 URL 中（如 ?city=北京&type=today），直接可见。
- POST 的参数放在请求体（Body）中，URL 中没有参数（或仅有无关的路径）。

2. 请求体（Body）的存在性

GET 请求：没有请求体（规范规定不允许有 Body，虽然某些客户端可能支持，但服务器通常忽略）。
POST 请求：必须有请求体（用于存放提交的数据，如表单、JSON 等）。

3. 请求头部（Headers）的差异

GET 请求：头部中可能包含 User-Agent、Cookie 等客户端信息，但无需声明请求体格式（因为没有体）。
POST 请求：必须包含 Content-Type 头部，告诉服务器请求体的数据格式，例如：

Content-Type: application/x-www-form-urlencoded  // 表单数据（键值对）
Content-Type: application/json                    // JSON数据

4. 参数的安全性与可见性

GET：参数暴露在 URL 中，会被浏览器记录、服务器日志留存，不安全（如密码不能用 GET 传递）。
POST：参数在请求体中，URL 干净，相对安全（但数据是否加密取决于是否用 HTTPS）。

5. 幂等性与安全性（HTTP 规范特性）

幂等性：多次调用效果是否一致。
- GET：幂等（多次获取同一资源，结果不变，如刷新网页）。
- POST：非幂等（多次提交可能创建多个资源，如重复提交表单会生成多条数据）。
安全性：
- GET：安全（理论上不会修改服务器数据，仅读取）。
- POST：不安全（会修改服务器数据，如提交订单、发布评论）。

6. 常见使用场景

GET：
- 搜索（如百度搜索，参数在 URL 中）。
- 获取文章、图片、API 数据（如天气 API：GET /api/weather?city=上海）。
POST：
- 登录（提交用户名密码，避免暴露在 URL）。
- 提交表单（如注册信息、上传文件）。
- 接口数据提交（如向服务器发送 JSON 格式的用户信息）。

三、完整请求 - 响应流程对比（以 “获取天气” 和 “提交天气” 为例）

场景 1：GET 请求（获取北京天气）

请求报文：

GET /weather?city=北京 HTTP/1.1       // 请求行：GET方法，参数在URL
Host: api.weather.com                 // 头部：指定域名
User-Agent: Mozilla/5.0 (Windows)...   // 头部：客户端信息

响应报文：

HTTP/1.1 200 OK                       // 响应行：成功
Content-Type: application/json         // 头部：体是JSON格式{                                      // 响应体：天气数据"city": "北京","temp": "25°C"
}

场景 2：POST 请求（提交上海天气数据）

请求报文：

POST /submit-weather HTTP/1.1          // 请求行：POST方法，URL无参数
Host: api.weather.com                  // 头部：域名
Content-Type: application/json         // 头部：声明体是JSON
Content-Length: 50                     // 头部：体的长度{                                      // 请求体：提交的数据"city": "上海","temp": "28°C"
}

响应报文：

HTTP/1.1 201 Created                   // 响应行：资源已创建
Location: /weather/123                 // 头部：新资源的URL
Content-Type: text/plain               // 头部：体是纯文本提交成功，数据已存储！                 // 响应体：处理结果

四、核心总结（对比表格）

对比项	GET	POST
请求目的	获取资源（读操作）	提交资源（写操作）
请求行方法	GET URL?参数 HTTP/版本	POST URL HTTP/版本
请求体	无（不允许有 Body）	有（必须包含提交的数据）
参数位置	URL 中（可见，不安全）	请求体中（相对安全）
幂等性	幂等（多次请求结果一致）	非幂等（多次请求可能创建多个资源）
安全性	安全（理论上不修改服务器数据）	不安全（会修改服务器数据）
常见状态码	200 OK （成功获取）	201 Created （成功创建）或 200 OK
缓存支持	支持缓存	通常不缓存
典型场景	搜索、获取数据、访问网页	登录、提交表单、上传文件、创建资源