Chaos

Starting from the "Scam Links" on Bilibili

Sun, 15 Mar 2026 00:00:00 GMT

:::important[想法来源] 观看二叉树树的视频【B站评论惊现诈骗链接！！！这是怎么做的？？？？】后，想要更深入地了解这个现象，从而有了这期博客。 :::

引言：关于“诈骗链接”

在浏览 BiliBili 评论区时，常会发现 B 站的视频链接以标题的形式显现，如下图：

但会遇到点击的视频标题与跳转到的视频页标题不一致的现象，也就是我们所说的诈骗链接。具体情形可以从二叉树树的视频中看到。

他也给出了制作这样的“诈骗链接”的方法：

模板：https://www.bilibili.com/video/BV_X/../BV_Y
BV_X 替换为显示标题的 BV 号，BV_Y 替换为跳转的 BV 号
使用任意B站短链接生成器（例如：B站短链接生成工具）生成短链接（符合^https://b23\.tv/[A-Za-z0-9]{7}$），并发布于B站评论区

以及漏洞的剖析：前端在渲染链接时，读取第一个合法 BV 号获取标题，在这里就是 BV_X 对应的标题，而点击会去跳转到原始的 url（包含/../），从而实际跳转到 https://www.bilibili.com/video/BV_Y。

这样的解释固然合乎道理，但于我而言，我还想要了解更多——为什么会造成这样的结果呢？

下文就记录了我的一些探索的所得。

📺关于 B 站评论区链接的渲染

据我观察，在B站发布评论时，输入文本是 B 站相关链接 则会被渲染为超链接；其中，若链接指向的是某个 B 站视频，则会被渲染为对应视频标题。当然，B站评论区还会存在其他类型的超链接，比如：跳转站外的蓝链(广告...)、BV号、av号、@用户昵称 …… 而其中BV号、av号等也会替换为其对应的title进行超链接的渲染。

总结该现象：

有的链接直接显示原始 URL；
有的链接显示成更友好的标题（例如视频标题）；
同一条评论里，可能两种显示方式同时出现。

从根本来说，前端 HTML 中，<a href="https://developer.mozilla.org/en-US/docs/Learn_web_development/Core/Structuring_content/Creating_links" title="了解超链接" target="blank">创建超链接</a> 通过 <a>标签实现，这里同样如此。问题在于：如何确认评论中某段文本是超链接？超链接的url如何得来？以及，如何确认渲染内容不是url而是对应视频标题？该视频标题如何得来？

观察网络请求，或查看<a href="https://sessionhu.github.io/bilibili-API-collect/docs/comment/" target="blank">文档</a>可得：

GET 请求 https://api.bilibili.com/x/v2/reply/wbi/main 懒加载获取评论区明细

<img src="https://cdn.jsdelivr.net/gh/lvjianchaos/Images/note/bilibili%E8%AF%88%E9%AA%97%E9%93%BE%E6%8E%A5%E8%AF%B4%E5%BC%80%E5%8E%BB/screenshot-of-the-reply-response.png" style="zoom: 67%;" />
评论主体通常在 content 中，常见字段包括：
- message：用户输入的原始文本；
- jump_url：可跳转片段的映射表（键通常是某个可识别 token，如 BV...）；
- members：@用户 的映射；
- emote：表情映射；
- pictures: 图片映射；
一个典型的 jump_url 结构是：
```
{
  "BV12ecbz1EUZ": {
    "title": "【Seedance 2.0】星野露比也要跳蕾塞舞ヾ(≧▽≦*)o",
    "state": 0,
    ...
  },
  "BV1fscqz9EHs": {
    "title": "【Seedance 2.0】伊什塔尔-蕾塞舞★彡",
    "state": 0,
    ...
  }
}
```
注意：jump_url 的 key 是否与文本切片后的内容“精确一致”，决定了能否显示标题。

简单地浏览B站前端关于comment的js代码，对于整体渲染的流程应该可以概括为 4 步：

参照：<a href="https://s1.hdslb.com/bfs/seed/jinkela/commentpc/bili-comments.e0090ab8af.js" target="blank">bili-comments.e0090ab8af.js</a>

拉取评论数据
前端请求评论接口，得到 replies 列表及每条 content。
文本解析为富文本节点
核心解析函数会把 message 切成片段，并生成节点数组（例如 span、a、img）。
节点渲染为 HTML
富文本组件把节点数组转换成真实 DOM，例如：
- <a href="..." data-type="link">...</a>
- ...
```
Hv = function (t, e, n, i, r) {
 return {
 tag: "a",
 style: i,
 dataset: r || {
 type: "link"
 },
 a: {
 text: uv(e || "网页链接"),
 href: t,
 icon: n,
 target: "_blank"
 }
 }
}
```
上述是源码中构造链接节点的一个逻辑，可见：超链接在数据层就是一个 tag: "a" 节点，dataset.type 默认是 link。
点击事件分流
点击链接后，根据 data-type（link/search/goods/seek 等）执行不同逻辑和埋点。

而其中最关键的机制是：

先“切片”，再“按片段匹配 jump_url”

1. 先做分片

解析器会按照多类规则切片，包括但不限于：

URL（白名单/正则）；
AV/BV/CV/EP/SS；
@用户名；
时间点（如 01:23）；
普通文本；
......

源码中有这样的一些正则匹配（已添加注释）：

// 匹配B站AV号：匹配以AV/av/Av/aV开头，后面跟一串数字的格式（如AV123456、av7890）
p = new RegExp("(AV|av|Av|aV)[0-9]+", "ug"), 

// 匹配B站BV号：B站视频的新标识符，规则是BV/bv/Bv/bV开头，
// 接着是1，然后跟9个字符（范围：1-9、A-N、P-Z、a-k、m-z，排除了O和l等易混淆字符）
f = new RegExp("(BV|bv|Bv|bV)1[1-9A-NP-Za-km-z]{9}", "ug"), 

// 匹配B站CV号/专栏移动端链接：
// 第一种：CV/cv开头+数字（如CV12345）；第二种：mobile/开头+数字（移动端专栏链接）
m = new RegExp("((CV|cv)[0-9]+|(mobile/[0-9]+))", "ug"), 

// 匹配B站EP号：番剧的剧集编号，EP/ep/Ep/eP开头+数字（如EP12、ep34）
y = new RegExp("(EP|ep|Ep|eP)[0-9]+", "ug"), 

// 匹配B站SS号：番剧的季度编号，SS/ss/Ss/sS开头+数字（如SS1、ss2）
b = new RegExp("(SS|ss|Ss|sS)[0-9]+", "ug"), 

// 匹配中括号包裹的任意Unicode字符：
// 匹配[]内包含的所有合法Unicode字符（涵盖基本多文种平面和扩展平面字符），
// 包括常见字符、emoji、生僻字等，是B站评论区常见的内容包裹格式
w = /\[(?:[\0-'\+-Z\\\^-\uD7FF\uE000-\uFFFF]|[\uD800-\uDBFF][\uDC00-\uDFFF]|[\uD800-\uDBFF](?![\uDC00-\uDFFF])|(?:[^\uD800-\uDBFF]|^)[\uDC00-\uDFFF])+\]/g, 

// 匹配B站及相关域名：
// 包含bilibili主域名（com/tv/cn）、衍生域名（esheep、biligame、b23.tv等）、
// 合作/关联域名（苏宁sugs、人民网、考拉、央视等），$v和Gv是外部变量（可能是协议/参数前缀）
x = new RegExp("".concat($v, "?([a-z0-9A-Z-]{1,15}.)?(bilibili\\.(com|tv|cn)|esheep\\.(com|cn|net)|biligame\\.(com|cn|net)|(bilibiliyoo|im9)\\.com|biliapi\\.net|b23\\.tv|bili22\\.cn|bili33\\.cn|bili23\\.cn|bili2233\\.cn|(sugs\\.suning\\.com)|jueze2021\\.peopleapp\\.com|kaola\\.com|bigfun\\.cn|mcbbs\\.net|mp\\.weixin\\.qq\\.com|static\\.cdsb\\.com|bjnews\\.com\\.cn|720yun\\.com|\\.cctv\\.com)($|/|)").concat(Gv), "ug"),

// 匹配B站视频链接：
// 包含bilibili主站/video路径、b23.tv等短链接，匹配AV号或BV号格式的视频链接
k = new RegExp("".concat($v, "?(((uat-)?www\\.bilibili\\.com)|(b23\\.tv|bili22\\.cn|bili33\\.cn|bili23\\.cn|bili2233\\.cn))(/video)?/((av[0-9]+)|((BV)1[1-9A-NP-Za-km-z]{9}))($|/|)").concat(Gv), "ug"), 

// 匹配B站番剧播放链接：
// 包含bangumi/play路径，匹配EP号或SS号的番剧播放链接
A = new RegExp("".concat($v, "?(((uat-)?www\\.bilibili\\.com/bangumi/(play/|media/)|(b23\\.tv|bili22\\.cn|bili33\\.cn|bili23\\.cn|bili2233.cn)/)(ss|ep)[0-9]+)($|/|)").concat(Gv), "ug"),

// 匹配B站专栏/文章链接：
// 包含read路径，匹配CV号、native?id、app/、mobile/等格式的专栏链接
_ = new RegExp("".concat($v, "?(uat-)?www\\.bilibili\\.com/read/((cv[0-9]+)|(native?id=[0-9]+)|(app/[0-9]+)|(native/[0-9]+)|(mobile/[0-9]+))($|/|)").concat(Gv), "ug"), 

// 匹配时间戳格式：
// 支持 数字#数字:数字:数字（如1#12:34:56）、数字:数字:数字（如12:34:56）、数字：数字：数字（中文冒号）
// 最少匹配 数字:数字:数字（如1:2:3），是视频评论区常见的时间点格式
E = /(\d+#)?(\d+(:|：)){1,2}\d\d/g

2. 对每个“候选片段”再检查 `jump_url`

命中 jump_url[片段]：用对应信息组装链接节点；
未命中：走默认链接逻辑（通常保留原文本显示）

3. 标题显示规则

当命中 jump_url 时，显示文案通常是：

title || 原片段文本

即：有标题就显示标题，否则退回原文本。

这个应该是 jump_url 命中后的标题选择的函数：

L = function (t, e) {
    var r = e.pc_url
       , o = e.app_url_schema
       , a = e.title
       , s = e.prefix_icon
       , l = e.match_once
       , c = e.icon_position
       , u = e.extra;
    if (l && N[t])
       return Wv(t);
    N[t] = !0;
    var d = 1 === c
       , h = "";
    if (r ? h = dv(r) : (C(x),
       x.test(t) ? (h = dv(t, !0),
          i && (C(k),
             k.test(h) && (h = Mv(h, i)))) : (C(f),
                C(p),
                C(m),
                f.test(t) ? (h = Ch({
                   bvid: t
                }),
                   i && (h = Mv(h, i))) : p.test(t) ? (h = Ch({
                      avid: Eu(t)
                   }),
                      i && (h = Mv(h, i))) : m.test(t) ? (h = Th(Eu(t)),
                         i && (h = Mv(h, i))) : h = function (t) {
                            if (t.startsWith("http")) {
                               var e = t.match(/www.bilibili.com\/h5\/note-app\/view\?cvid=(\d+)/);
                               return null != e && e[1] ? Th(e[1]) : t
                            }
                            return ""
                         }(t))),
       !h)
       return Wv(t);
    var y = a || t
       , b = ""
       , g = !1
       , w = "";
    (null != u && u.goods_item_id || null != u && u.goods_prefetched_cache) && (g = !0,
       null != u && u.goods_pc_click_urls && Array.isArray(u.goods_pc_click_urls) && (w = u.goods_pc_click_urls.join(",")),
       C(x),
       x.test(t) && (b = t));
    var A = g ? {
       type: "goods",
       "goods-url": w,
       "raw-url": b
    } : null != u && u.is_word_search ? {
       type: "search",
       keyword: uv(y)
    } : {
       type: "link"
    };
    return n === Uf.DESKTOP_APP ? A = v(v({}, A), {}, {
       link: h
    }) : n === Uf.MOBILE_BROWSER && o && (A = v(v({}, A), {}, {
       link: o
    })),
       Hv(h, y, s, d ? {
          display: "inline-flex",
          "flex-direction": "row-reverse",
          "--icon-width": "0.65em",
          "--icon-height": "1.2em"
       } : {
          "--icon-width": "1.2em",
          "--icon-height": "1.2em"
       }, A)
 }

简化并语义化后，关键逻辑如下：

var L = function (token, config) {
   var title = config.title
   // ...省略 url 解析
   var renderText = title || token
   return Hv(resolvedHref, renderText, prefixIcon, style, dataset)
}

可见：命中时明确是 title || token，也就是“有标题显示标题、否则显示原片段文本”。

案例

上述的论述仍有不足之处，但能够分析出我们这一小节最开始的问题。就拿我们上面的截图作为案例：

message是：

https://bilibili.com/video/BV12ecbz1EUZ/../../opus/1035673329881579520/../../video/BV1fscqz9EHs/

并且 jump_url 里有两个键并有对应的标题：
- BV12ecbz1EUZ
- BV1fscqz9EHs

最终渲染应该是：

第一段显示原始 URL 链接：https://bilibili.com/video/BV12ecbz1EUZ/
中间 ../../opus/.../../../video/ 显示为普通文本
第二段 BV1fscqz9EHs 显示为标题链接

与我们的实际渲染相符：

在这里为什么第一个 BV号 没有替换 title，是 jump_url 失效了吗？不然，是切片结果不同：

前半段先被识别为一个 URL 片段，片段文本是完整 URL，不是 BV12... 本身；
jump_url 的 key 是 BV12...，与该 URL 片段不精确相等，因此无法直接命中；
后半段在后续分片中切出了独立 token：BV1f...，这时与 jump_url 的 key 精确匹配，所以能替换成标题。

还有类似这样的： <img src="https://cdn.jsdelivr.net/gh/lvjianchaos/Images/note/bilibili%E8%AF%88%E9%AA%97%E9%93%BE%E6%8E%A5%E8%AF%B4%E5%BC%80%E5%8E%BB/example_2.png" alt="example_2" style="border-radius: 1em; zoom: 60%" />

message: "https://www.bilibili.com/video/BV1fscqz9EHs/../BV12ecbz1EUZav116057901629925cv1035673329881579520"
jump_url 仅有一个：
- https://www.bilibili.com/video/BV1fscqz9EHs/../BV12ecbz1EUZav116057901629925cv1035673329881579520: {title: "【Seedance 2.0】伊什塔尔-蕾塞舞★彡", state: 0,…}

为什么没有渲染标题，就是”切片“后的无法精准匹配 jump_url 的键。当然，jump_url的计算是后端服务进行的操作，所以问题应该是后端并不是按前端切片后的数据进行 jump_url 的计算，而自有一套算jump_url的方法。而若要提高渲染 jump_url 为标题的“<s>命中率</s>”(:不知道这样说是否合理:)，后端的 jump_url 计算方法就必须更改，比如按照前端同样的逻辑先对消息进行分片后处理是否有要显示 title 的链接，或者前后端这一块的逻辑代码一起重构以互相匹配。

那么，回到疑问：如何确认评论中某段文本是超链接？超链接的url如何得来？以及，如何确认渲染内容不是url而是对应视频标题？该视频标题如何得来？

通过各种正则匹配
输入的是全的链接自然是全的，而若是 BV 号，av 号等由于其 url 的规律性，自然可以拼接得到
通过后端传来的数据，核心是 jump_url 的键值对

同样，B站短链是按照上述流程被渲染，如若能够匹配 jump_url 也就会被渲染为 title 的形式；而若跳转的视频标题与其不同，就造成“诈骗”；可以见得，问题就出现在这个 jump_url 计算出的 title 出错了，即：对于改模板的 url https://www.bilibili.com/video/BV_X/../BV_Y 计算出的 title 是 BV_X 的标题。

补充：流程图与对应代码锚点

解析入口（qv）

function qv(t, e, n, i) {
   var a = t.content
   var s = a.message, l = a.emote, c = a.members, u = a.jump_url, d = a.vote
   // ... 分片与节点构造
}

命中 jump_url 时优先走 L()

var M = Vf(function (token) {
   return null != u && u[token] ? L(token, u[token]) : Hv(Sh(token), token)
}, ...)

渲染层将节点数组变成 HTML

setContents(nodes) {
   const html = nodes.map(/* node -> html */).join("")
   this.contents.innerHTML = html
}

点击事件基于 dataset 分流

this.disposables.addEventListener(this.contentsElement, "click", function (e) {
   var n = v({}, e.target.dataset)
   t.dispatchEvent(new CustomEvent("text-click", { detail: n }))
})

🔗浅谈短链接

在说明为什么 https://www.bilibili.com/video/BV_X/../BV_Y 跳转到的是 BV_Y 之前，先来简单了解一下短链接技术。

简述

短链接是一种 URL 缩短技术，通过重定向将较长的原始链接映射到简短的地址。当用户访问短链接时，服务端返回 301/302 状态码，并在 Location 响应头中携带真实目标地址，浏览器随即跳转。

例如，以下这个冗长的 B 站链接：

https://www.bilibili.com/video/BV12ecbz1EUZ/?spm_id_from=333.999.0.0&vd_source=xxx...

可以缩短为：https://b23.tv/X8QkDCP

上图是短链接请求的结果，可见其核心是一次 302 重定向，Location 字段即为原始的长地址。

简单的说，短链接服务就是一个键值对数据库加上一个重定向服务器。核心为两个过程：

生成时：你将一个长链接（如 https://www.example.com/very/long/path?with=many&parameters）提交给服务，它返回一个短码（如 abc123），并在数据库中记录 短码 -> 长链接 的映射。
访问时：当用户点击 https://short.url/abc123，短链接服务器接收到请求，根据 abc123 查到对应的长链接，然后向浏览器返回一个 HTTP 301（永久重定向）或 302（临时重定向） 响应，其中 Location 头部就是那个原始长链接。浏览器收到后，会自动跳转过去。

`b23.tv` 短链生成

我们可以通过第三方的 B站短链接生成工具来使用哔哩哔哩的短码服务，当然也可以通过 B站的API 生成 b23.tv 短链，这里给出一个脚本代码：

"""
b23_generator.py - Bilibili b23.tv 短链生成工具

基于B站 API实现：
接口：https://api.bilibili.com/x/share/click
方法：POST
功能：为视频、动态、专栏、文集、用户、课程、站内链接生成短链
"""

import requests
import json
import re
import sys
from typing import Optional, Dict, Any, Union

class B23Generator:
    """B站短链生成器"""

    # API 端点
    API_URL = "https://api.bilibili.com/x/share/click"

    # 不同类型内容的参数映射表（基于文档）
    TYPE_MAP = {
        "video": {
            "share_id": "main.ugc-video-detail.0.0.pv",
            "share_origin": "",
            "description": "视频"
        },
        "dynamic": {
            "share_id": "dt.dt-detail.0.0.pv",
            "share_origin": "dynamic",
            "description": "动态/图文"
        },
        "article": {
            "share_id": "read.column-detail.roof.8.click",
            "share_origin": "",
            "description": "专栏"
        },
        "collection": {
            "share_id": "read.column-readlist.share.0.click",
            "share_origin": "",
            "description": "文集"
        },
        "user": {
            "share_id": "main.space-total.more.0.click",
            "share_origin": "",
            "description": "用户空间"
        },
        "course": {
            "share_id": "pugv.pugv-video-detail.0.0.pv",
            "share_origin": "vinfo_player",
            "description": "课程"
        },
        "link": {
            "share_id": "public.webview.0.0.pv",
            "share_origin": "",
            "description": "站内链接"
        }
    }

    def __init__(self, buvid: str = "b23_generator", build: int = 7710300, platform: str = "linux"):
        self.buvid = buvid
        self.build = build
        self.platform = platform

    def _post_request(self, data: Dict[str, Any]) -> Optional[str]:
        headers = {
            "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36",
            "Content-Type": "application/x-www-form-urlencoded"
        }
        try:
            response = requests.post(self.API_URL, data=data, headers=headers, timeout=10)
            response.raise_for_status()
            result = response.json()
            if result.get("code") == 0 and result.get("data", {}).get("content"):
                content = result["data"]["content"]
                short_url_match = re.search(r'(https?://b23\.tv/[^\s]+)', content)
                if short_url_match:
                    return short_url_match.group(1)
                return content
            else:
                print(f"API返回错误: {result}")
                return None
        except Exception as e:
            print(f"请求失败: {e}")
            return None

    def generate_video(self, oid: Union[int, str]) -> Optional[str]:
        if isinstance(oid, str) and oid.startswith(('BV', 'bv')):
            print("注意：请传入AV号数字（aid），而非BV号")
            return None
        data = {
            "buvid": self.buvid,
            "build": self.build,
            "platform": self.platform,
            "share_channel": "COPY",
            "share_mode": 4,
            "share_id": self.TYPE_MAP["video"]["share_id"],
            "oid": int(oid)
        }
        print(f"正在为视频 (aid={oid}) 生成短链...")
        return self._post_request(data)

    def generate_dynamic(self, dynamic_id: int) -> Optional[str]:
        data = {
            "buvid": self.buvid,
            "build": self.build,
            "platform": self.platform,
            "share_channel": "COPY",
            "share_mode": 4,
            "share_id": self.TYPE_MAP["dynamic"]["share_id"],
            "share_origin": self.TYPE_MAP["dynamic"]["share_origin"],
            "oid": dynamic_id
        }
        print(f"正在为动态 (id={dynamic_id}) 生成短链...")
        return self._post_request(data)

    def generate_article(self, cvid: int) -> Optional[str]:
        data = {
            "buvid": self.buvid,
            "build": self.build,
            "platform": self.platform,
            "share_channel": "COPY",
            "share_mode": 4,
            "share_id": self.TYPE_MAP["article"]["share_id"],
            "oid": cvid
        }
        print(f"正在为专栏 (cvid={cvid}) 生成短链...")
        return self._post_request(data)

    def generate_collection(self, rlid: int) -> Optional[str]:
        data = {
            "buvid": self.buvid,
            "build": self.build,
            "platform": self.platform,
            "share_channel": "COPY",
            "share_mode": 4,
            "share_id": self.TYPE_MAP["collection"]["share_id"],
            "oid": rlid
        }
        print(f"正在为文集 (rlid={rlid}) 生成短链...")
        return self._post_request(data)

    def generate_user(self, mid: int) -> Optional[str]:
        data = {
            "buvid": self.buvid,
            "build": self.build,
            "platform": self.platform,
            "share_channel": "COPY",
            "share_mode": 4,
            "share_id": self.TYPE_MAP["user"]["share_id"],
            "oid": mid
        }
        print(f"正在为用户空间 (mid={mid}) 生成短链...")
        return self._post_request(data)

    def generate_course(self, course_id: int, origin: str = "vinfo_player") -> Optional[str]:
        data = {
            "buvid": self.buvid,
            "build": self.build,
            "platform": self.platform,
            "share_channel": "COPY",
            "share_mode": 4,
            "share_id": self.TYPE_MAP["course"]["share_id"],
            "share_origin": origin,
            "oid": course_id
        }
        print(f"正在为课程 (id={course_id}) 生成短链...")
        return self._post_request(data)

    def generate_link(self, url: str) -> Optional[str]:
        if not re.match(r'^https?://([\w-]+\.)*bilibili\.com/', url):
            print("错误：仅支持 bilibili.com 域名下的站内链接")
            return None
        data = {
            "buvid": self.buvid,
            "build": self.build,
            "platform": self.platform,
            "share_channel": "COPY",
            "share_mode": 4,
            "share_id": self.TYPE_MAP["link"]["share_id"],
            "oid": url
        }
        print(f"正在为站内链接生成短链: {url}")
        return self._post_request(data)


def main():
    """命令行入口"""
    import argparse
    parser = argparse.ArgumentParser(
        description="Bilibili b23.tv 短链生成工具",
        epilog="示例:\n  python b23_generator.py video 80433022\n  python b23_generator.py link 'https://www.bilibili.com/video/BV1GJ411x7h7'",
        formatter_class=argparse.RawTextHelpFormatter 

    )
    parser.add_argument("type", choices=["video", "dynamic", "article", "collection", "user", "course", "link"],
                        help="内容类型")
    parser.add_argument("id", help="内容ID或链接（视频请传aid数字）")
    parser.add_argument("--buvid", default="b23_generator", help="设备标识（任意非空字符串）")
    parser.add_argument("--build", type=int, default=7710300, help="客户端版本号（需>5520400）")

    args = parser.parse_args()

    generator = B23Generator(buvid=args.buvid, build=args.build)

    # 根据类型调用相应方法
    if args.type == "video":
        result = generator.generate_video(args.id)
    elif args.type == "dynamic":
        result = generator.generate_dynamic(int(args.id))
    elif args.type == "article":
        result = generator.generate_article(int(args.id))
    elif args.type == "collection":
        result = generator.generate_collection(int(args.id))
    elif args.type == "user":
        result = generator.generate_user(int(args.id))
    elif args.type == "course":
        result = generator.generate_course(int(args.id))
    elif args.type == "link":
        result = generator.generate_link(args.id)
    else:
        result = None

    if result:
        print(f"\n✅ 生成成功！短链: {result}")
    else:
        print("\n❌ 生成失败，请检查参数和网络")


if __name__ == "__main__":
    main()

需要说明的是，短链接依赖服务端主动返回重定向；而本文将要分析的 ../ 路径跳转，属于浏览器对 URL 路径的自动规范化处理，下文将详细展开。

🌐URL 的演进与规范

回到诈骗链接的现场：短链跳转到的原始长链明明是类似这样的 https://www.bilibili.com/video/BV_X/../BV_Y，我们可以尝试直接在浏览器输入类似这样的网址，会发现路径中的 /BV_X/.. 消失了，是谁篡改了这个 URL—— URL路径规范化。

回顾 URL 起源与演进

1990年，蒂姆·伯纳斯·李在发明万维网时，需要一种方式标识互联网上的资源。他借鉴了当时Unix文件系统的路径表示法：

这种设计让早期开发者能够直观地理解和链接资源。比如，/docs/../images/logo.png 显然指向 /images/logo.png。在当时，这只是一个实用的约定，而非严格的标准。

随着Web的爆炸式发展，这种“野路子”带来了问题：同一个资源可以有无数个别名（如 /a/b/c 和 /a/b/../b/c），这导致缓存、爬虫和安全都面临挑战；并且，URL 的解析方式在不同浏览器、服务器间出现了分歧。例如，对 http://example.com/a/../b 的处理：

有的系统会直接发送原始路径
有的会在服务器端做规范化
有的甚至会把 .. 当作普通目录名

这导致了兼容性灾难和安全漏洞（如目录遍历攻击）。于是，互联网工程任务组（IETF）开始推动标准化。

时间	规范	关键贡献
1994	RFC 1630	首次定义“通用资源标识符”，但只是总结现有用法
1994	RFC 1738	正式定义绝对/相对URL，明确相对解析规则
1998	RFC 2396	URI语法独立成规范，“U”从“通用”改为“统一”
2005	RFC 3986	现行标准，详细定义解析、规范化、相对引用规则

**RFC 3986**是里程碑式的。它明确要求：任何符合标准的URI处理器，在解析路径时必须对 . 和 .. 进行规范化处理。这意味着：

浏览器在发送请求前，必须规范化路径
服务器在路由匹配前，必须规范化路径
任何网络库、框架在处理URL时，都必须遵循这一规则

之所以要求路径规范化，主要基于两点：

资源定位的唯一性

在Web中，一个资源应该只有一个规范URL。规范化确保了无论用户如何构造链接（/a/b/../c 还是 /a/c），最终都指向同一资源。这对于缓存、SEO、权限控制至关重要。
基础安全防线

规范化是防御目录遍历攻击的第一道关卡。通过解析 ..，服务器可以判断最终路径是否在Web根目录内。例如，攻击者提交 ../../etc/passwd，规范化后服务器能检测到目录遍历，直接拒绝请求。

规范化

显而易见的，规范化的发生在底层的基础设施，且往往不止一次：

浏览器端

当你在地址栏输入URL并回车时，浏览器内核在构造HTTP请求之前，就会进行路径规范化。也就是为什么我们开始在浏览器输入：https://www.bilibili.com/video/BV_X/../BV_Y，回车，就已经是：https://www.bilibili.com/video/BV_Y
服务器端

即使浏览器因某些原因未规范化（如构造特殊请求），请求到达诸如Nginx的服务器时，在路由匹配前同样会执行路径规范化。
…………

核心：`.` 与 `..` 的处理

URL 标准有明确的规范化算法，简化后的逻辑如下：

初始化一个空列表 output 作为规范化后的路径
遍历原始路径的每个 segment：
- 若 segment 为 .（或编码形式 %2e）→ 跳过，不加入 output
- 若 segment 为 ..（或编码形式 %2e%2e、%2e. 等）→ 若 output 非空，移除最后一个 segment
- 否则 → 将 segment 加入 output

以我们的链接为例：

原始 segment	操作	当前 output
`video`	加入	`["video"]`
`BV_X`	加入	`["video", "BV_X"]`
`..`	移除最后一个	`["video"]`
`BV_Y`	加入	`["video", "BV_Y"]`

最终规范化后的路径为 /video/BV_Y，因此浏览器实际请求的是 https://www.bilibili.com/video/BV_Y。

示例代码 demo：

// 功能：规范化URL路径，移除 "." 和 ".."
static void normalize_path(char *path) {
    char *p = path;
    char *q = path;
    // 核心逻辑：遍历路径段
    while (*p) {
        if (p[0] == '.' && (p[1] == '/' || p[1] == '\0')) {
            p += (p[1] == '/') ? 2 : 1;  // 跳过 "."
        } else if (p[0] == '.' && p[1] == '.' && (p[2] == '/' || p[2] == '\0')) {
            // 回退上一级
            while (q > path && *--q != '/');
            p += (p[2] == '/') ? 3 : 2;
        } else {
            // 复制普通段
            while (*p && *p != '/') *q++ = *p++;
            if (*p == '/') *q++ = *p++;
        }
    }
    *q = '\0';
}

不止于路径

值得注意的是，URL规范化远不止处理 ..。RFC 3986及其实践通常包括以下操作：

操作	示例	说明
Scheme转小写	`HTTP://` → `http://`	协议名不区分大小写
Host转小写	`EXAMPLE.com` → `example.com`	域名不区分大小写
移除默认端口	`:80`（HTTP）、`:443`（HTTPS）	减少冗余
路径解析	`/a/./b/../c` → `/a/c`	移除 `.` 和 `..`
百分号解码	`%7E` → `~`	解码安全字符
移除片段标识	`#section` 在发送请求时丢弃	片段不发送到服务器

示例：URI.js（JavaScript 库）的规范化

// https://www.npmjs.com/package/uri-js
const URI = require("uri-js");
let rawUrl = "HTTP://ABC.COM:80/%7Esmith/home.html";
let normalized = URI.normalize(rawUrl);
console.log(normalized); 
// 输出: "http://abc.com/~smith/home.html"
// 功能：scheme/host转小写，移除默认端口80，解码安全的百分号编码

结尾：回到“诈骗链接”

现在我们可以完整解释 B 站诈骗链接的机制了：

使用B站短链服务，将一个未规范化的 URL 生成短链接，而这个 URL 在短链服务里没有被规范化；
后端计算该短链接 jump_url 的键值对，在解析这个未规范化的 URL 时，导致提取的是第一个 BV_X 的 title；
前端渲染这个 b23.tv 短链，对应的 title 是第一个 BV_X；
点击跳转，浏览器重定向原始 URL，由于自身执行 URL 的标准化，将路径规范化为 /video/BV_Y，于是“诈骗”发生了。

所以，实际上，https://www.bilibili.com/video/BV_X/../../后可加任意的路径（B站）。例如：https://www.bilibili.com/video/BV_X/../../opus/1035673329881579520跳转的实际上是：https://www.bilibili.com/opus/1035673329881579520。

而若要解决这个“诈骗链接”问题：

短链接生成服务，注意对原始链接进行规范化

后端 jump_url 的计算逻辑，注意对 URL 进行规范化

:::tip[😋] 本文有些知识其实不需要大段论述，但实际上我就是为了这个“饺子”，才端出这个“B站诈骗链接”的“醋”喵~ :::

姥爷

Fri, 31 Oct 2025 00:00:00 GMT

在我心里，姥爷是需要仰头看的人。这份敬意，像院子里那棵老树的根，悄悄扎得很深。他不怎么夸人，话语也不多，但看他眼角的纹路怎样聚散，就能猜到几分他对我们的心思。

家里人都说，姥爷是水做的骨架，身子弱，性子也软。他的父亲，我叫老太的，听说是个富农。姥爷生在四九年，天地变色的当口。家道是落了，日子却还算安稳，像秋后的水塘，波澜不惊。姥爷就像那水塘边小心护着的秧苗，没经过多少风雨，就这么长大了。

人一辈子要遇上什么，好像冥冥中都有定数。软和的姥爷，偏就遇上了硬朗的姥娘。姥娘是石头缝里长出的草，不光身板结实，心思也硬，遇事有决断，像个老谋深算的将军。跟人掰扯起来，她从不落下风。姥爷呢，像是怕沾染上那份争斗的尘土，总在一旁默着，像株田埂上割了的麦子。他们俩，一软一硬，竟也磕磕绊绊地走过了五十多年，像河里的两块石头，被水冲刷着，磨圆了棱角，依偎在一起。如今添了重孙丞丞，拌嘴也少了，更多的是笑，那笑纹从眼角一直漾开，快要盛不下了。

都说姥爷柔弱，确实，他一辈子没怎么碰过泥土，那双手，比起姥娘那双饱经风霜、如同老树皮的手，要细嫩得多。可在我眼里，姥爷那份软和里，藏着不易察觉的韧劲，像水底的青苔，不显眼，却牢固。他不愿在人前示弱，有时会偷偷背过身去抹眼睛，但一转过脸对着我们这些小的，眼里就又有了光，像夜里的星子。他常鼓励我们多认几个字。姥爷是念过书的人，写一手好字，听说年轻时是想考出去，只是后来文革耽搁了。

这几年，姥爷的身子像老屋的墙，渐渐有些松动了。一点不舒服就让他心慌，往看病的地方也跑得勤了。可只要抱起丞丞，那小小的、暖烘烘的身子一挨着他，他的眼睛就又笑成了一条缝，好像所有忧虑都被这新生的气息给冲散了。他舍不得，舍不得我们这些他看着出生、又看着长大的人。

还记得很小的时候，上幼儿园。姥爷刚退下来，却闲不住，弄了辆三轮车去拉人。那车在他手里，像匹温顺的老马。在我眼里，那车斗是那样宽大，能装下好多东西。可我一天天长高，那三轮车却在我眼里一天天变小、变旧，铁皮生了锈，轮子也不再光亮。后来有一天，它就彻底不动了，像累极了的老牛，卧在那里。再后来，它就不见了，不知去了哪里。它的颜色，它的模样，在我记忆里也模糊了，像南堰上空飘过的一缕炊烟，散了。

那辆载着姥爷奔波过的三轮车不见了，姥爷也彻底停了下来，守在了家里。像是飞倦了的鸟，落回了巢。那些向外伸展的枝桠，也被时间一根根修剪，最后，只剩下守着根的那份安稳。

如今，姥爷坐在院子里，看着儿孙们各自忙碌，看着重孙在地上爬。生命像门前的小河，流过他，又流向更远的地方。他感受着这绵延不绝，脸上是满足的，像秋日晒谷场上的阳光。我站在旁边，看着他，也看着落在他身上的夕阳，那光线，暖暖的，却也带着几丝凉意。

姥爷是真的老了。

他心里的那些事，那些年轻时的奔波，那些没能写完的字，怕是也要像那辆三轮车一样，慢慢沉寂下去，只有他自己，在无人的时候，默默回想吧。

而我，好像还是那个跟在他身后的孩子，却也到了要推开家门，走向自己那片南堰的时候了。

姥爷还是那个姥爷，只是，再也蹬不动那辆三轮车了。

盛夏、死蝉与逝去的友人

Tue, 28 Oct 2025 00:00:00 GMT

一

蝉鸣渗过玻璃窗，那声音不似振动，倒像一种介于树脂与电波之间的存在，粘稠地裹挟着破碎的回忆。当搬家工人第八次撞击门框时，某根被空调冷气冻僵的神经突然一颤——一本破旧的笔记本掉落在门旁，封皮上依稀可见2008年梅雨季的霉斑。

指尖轻掠泛黄的纸页，家乡学校后的新代桥尚未清晰，十六岁那年生物实验室里福尔马林的气味已率先漫溢开来。吕游的白衬衫如往常一样带着水族箱藻类的腥甜味，当他把解剖剪刺入蝉的腹节时，睫毛在夏末的光晕中抖落了细碎的金粉。我看不清他的脸。

“节间膜，要完整剥离。”他的声音，透着昆虫标本般的透明感。我们并排蹲在实验室前的走廊上，拾起那些被同学踩碎的蝉尸。窗外的合欢树，散发着最后的绒花，粉色的雪片在他肩胛骨上停驻，像是永远飞不起来的残翅。

二

空调压缩机发出垂死的嗡鸣。此刻，凝结在2023年的尘埃，漂浮在十五年前解剖剪上微弱的光影中，如同两个时节的蝉鸣在记忆的共振腔里共鸣。读到“吕游死了”那行稚嫩的笔迹时，鼻腔内竟涌上一股腥腥的凉意——这不是文字，而是2008年九月十七日黄昏，警用探照灯在河面上划出的那道惨白伤痕。

记忆的菌丝开始蔓延：他的橡皮擦总被削去一个尖，生物课本第三十七页夹着风干的蜉蝣翅脉，还有葬礼那天停在他母亲发髻上的红蜻蜓（那深如鲜血的红，至今仍在视网膜背面闪烁）。穿黑袈裟的僧侣摇动法铃时，蝉群突然噤声，仿若整个宇宙的振动都坍缩进桐木骨灰盒的缝隙。

三

搬运工踩过地板的吱呀声，撕开了记忆的茧房。我发现自己正用拇指反复摩挲日记本上某处皱褶——那是被泪水浸泡过的地形图，标记着一个已不复存在的地方。吕游消失前夜，他留给我的玻璃标本瓶，此刻与纸箱深处的颠簸共振。七百二十只蝉的复眼在黑暗中睁开，折射出我们在时光褶皱里遗落的对话：

“知道吗？蝉若虫要在土里蛰伏十七年。”

“比我们的年纪还大呢。”

“可破土后的成虫，只有七天。”

我们笑得像两个偷饮了时光酒的僭越者。

四

电梯下降的失重感中，某只垂死的蝉突然在耳膜内振翅。它的鸣叫穿透十五年光阴，与卡车引擎的轰鸣编织成赋格曲。后视镜中，渐远的公寓楼褪色，像浸泡在显影液中的旧相片。当高速公路的风撕开记忆的结痂，我突然听见吕游的声音在时空间隙里低语：

“不是十七年，也不是七天。”

“我们都在各自的甬道里，等待破土的那一刻。”

挡风玻璃上爆开的虫尸，绽放成星云，盛夏正以光年速度向我们袭来。

始写于22年秋

姥娘，大黄。

Mon, 27 Oct 2025 00:00:00 GMT

雪停了些日子，去看姥娘。如今多是在丞丞家见她。丞丞是她的重孙子，刚落到这世上四月，像雪后地里钻出的一点新绿。姥娘抱着他，脸上沟壑纵横，笑起来时，眼睛便眯成一道弯弯的缝，露出补过的瓷牙，亮晃晃的，像冬日薄冰反射的日光。丞丞也跟着笑，咯咯咯的声音，干净得像刚洗过的天空。

姥娘老了，七十多年，风尘仆仆。丞丞小，嫩得能掐出水。看着他们，一个生命的尾声，一个生命的开端，挨得那么近，像河的两岸，中间是奔流不息的时间。这时间的水声，有时听着让人心安，有时，却又觉得它带着寒气，能悄无声息地浇熄一些东西。比如，人心里那点微弱的火苗。

姥娘年轻时，守着南堰上的猪场。那时的南堰，天高地阔，路是土的，风是硬的。姥娘的身板也硬朗，走起路来，脚下生风。我跟在她身后，她走一步，我得跑两步。家还没拆，南堰还在，猪在圈里哼哼，日子像南堰上的草，不声不响地长着，也黄着。记不清多少个夜晚，妈上夜班，姥娘屋里的灯昏黄，像粘稠的蜜。她的大手拍着我的背，哼着不成调的歌谣，哄我睡去。那时的她，笑起来是暖的，像南堰夏天的阳光。如今，她笑的样子也没变，只是皱纹深了，像被岁月犁过的土地。

那时，是她立在南堰坡上等我。如今，我早已跑出了她的视线，跑过了那片她将来要躺下的土地。她看着我们这些小的，一代代往前跑，身子越来越沉，脚步越来越慢，却好像还想跟着，再送一程。可我们跑得太快了，快得让她只能留在原地，望着一个个背影，消失在路的尽头，消失在时间的尘埃里。

南堰坡上，姥娘曾捡回一只小黄狗，叫大黄。她陪了我好些年，算起来，比我大两岁。如今，我的年纪，已是她活过的两倍了。她走了有十年了吧？死在哪一天，记不清了。只记得那天心里空了一下，像被风吹过，第二天，就忘了那阵风。可现在，这风又不知从哪里吹回来，带着点凉意，和一种说不清的慌。她是在哪里咽下最后一口气的？为什么要自己跑出去？我最后一次唤她，她有没有回头看我一眼？像南堰秋天早上的雾，都模糊了。

她死前几天，就卧在窝里不动了。那天却忽然有了精神，在院子里跑了几圈。我以为她好了，没多想。谁知道，只是回光返照，用尽最后的气力，跑回了她来的地方，南堰。找了个谁也不知道的角落，把自己埋葬了。

记忆这东西，靠不住，像漏了的筛子。只记得一些零碎的，不相干的。有一次，姥娘扔给大黄一块肉，她老了，牙不行了，叼着，却咬不动，呜咽了一声，把肉吐在地上。她的儿孙，早被送给了左邻右舍，只剩下她一个。姥娘看着她，叹了口气，“都老了……” 把肉切成小薄片，再扔给她。她吃没吃，忘了。只记得我蹲下去，看着她的眼睛。那眼睛黑黢黢的，像两口深不见底的枯井，要把人的魂吸进去。在她眼里，我是什么样子的？那个时候的她，和那个时候的我，心里头都转着些什么念头？怕是只有南堰的风，南堰的土才知道了。这些东西，不说出来，就只能烂在心里，跟着人和狗，一起回到土里去。

大黄最后还是回到了南堰。那是姥娘捡到她的地方，也是她最后望着的家。或许，那片土地，才是所有生命的根，无论跑得多远，最终都要回去。就像姥娘，守着南堰大半生，如今看着重孙，眼神里还是南堰的影子，有暖阳，也有挥之不去的，落雪的寂静。

刷题日志

Sat, 30 Aug 2025 00:00:00 GMT

刷题日志记录着我平日解决过的算法题与对应的题解（它们有些业已在我博客中发表），通常是有趣的😊，或对我而言有挑战性的😱，有时也记录着我在进行算法竞赛中的思考🤔。

:::important 你可以在我的GitHub上找到它们！ :::

::github{repo="lvjianchaos/Algorithm-Problem"}

卡住的文章，“永不抵达”的“我”

Mon, 25 Aug 2025 00:00:00 GMT

:::note[前面的话] 如果这篇文章没有卡在发表的咽喉里，某种意义上我或许有了些改变…… ::: 这个博客其实早在1年前就已搭建并部署了，不过当时是基于Hexo框架。

显而易见，截至今日我并未发表数量可观的博文，而这些屈指可数的博文也只是我平日里学习得以整理的知识类笔记等等(比如：关于编程、关于开发、关于算法)。

可最近我总会陷入想要分享自己写下的小说、散文以及对书籍、电影、番剧等的体验、感受、评价与思考等这类偏私人化的写作的矛盾漩涡。可这仅仅是“想”，我并未付诸行动。

究其原因，我这个人一个人时总会考虑自己种种行为、思想的正当性或思考我为什么会这样做及这样想（发生原理与意义）。

所以，对于前者知识类文章的发表/分享我并未“卡住”，因为在我看来：在撰写这些博文时，我总会有意无意地预想一个正在阅读这篇文章的人，从而尽可能写得有逻辑、准确性与结构化，以至于以输出的方式更好地巩固我所学的知识；But，对于后者私人化的写作，我似乎无法接收同样的理由或者找到如前者那样的“正当性”（虚荣心（炫耀自己的小说有多么高深、散文有多么哲思？对书影音的感受评价有多么深刻？从而获得某种对我的好处（物质的利益/心理的快乐）？）？孤独（想要获得认同？希望有人发现我的存在？）？），或许真的是这样或许不是，但就算是，我也会以不成熟（虚荣、寻求认同）的动机而终止这一行为。故称“卡住的文章”。

The Art of Naming the Variable Names

Tue, 29 Apr 2025 00:00:00 GMT

:::important[学习笔记] 原B站up micro_frank 的视频课程，现已更名为零界世访，且该视频已被其删除或隐藏。 :::

一、总论

身为IT行业的小白，我们不能仅仅沉浸于代码语言的层次上或算法与数据结构的快感中，我们应该思考：但在这些基本都搞定了呢！？我们又该何去何从？

实际上，最高深的层次往往不是代码的算法与数据结构的构建本身，而是编程的艺术。一些大师级别的人物，他们在谈到编程或软件构建上绝不仅停留在代码、语言、算法和数据结构上，而是提升到一个极高的层次——编程的艺术。也就是说：思维和艺术将会决定你写代码的高度。

而编程的艺术其中一个重要的点便是——变量名命名。

变量名命名的重要性

变量名真正的命名往往直接决定软件构建的效果、代码的性能，甚至可能影响到软件的安全和效益，以及所出现的问题一半都可能源于变量名命名。

我们为何如是说呢？“一个好的变量名命名不是一个即时的效果，而是一个长期的效益。”一个例子：我们设想下列情景：

（1）我养了一只狗🐕，它叫小黑，小黑死去之后，我又养了一只叫小白的狗🐕；这样并无问题，我们都能分清楚。

（2）可是，如果我养了10000只不同（这里说不同只是方便假设，因为这里不能用数组，而是无联系的10000个变量）的鸡，那么一万只鸡我该是这样命名吗？：a,b,c,d…aa,ab,………当第二天我们说鸡chicken下蛋了，那么鸡chicken是谁呢？我们还能搞清吗？所以说变量名命名的方式直接决定变量名的所带来的后果/效果。没有好的变量名命名，会导致程序难以理解和维护。

变量名命名的规范

我们这里以C语言来进行代码部分的编写，以进行具体阐释。

关于常见的错误命名(🔺注意：这是在具有实际开发情景下的代码，不是无实际意义的语法展示示例)：

#include <stdio.h>
// 不明所以，不知其意
int main(void)
{
    int a,b;
    char c;
    
    int a[10];
    
    int ss = s1 + s2;
    
    int i;
    for(i = 0;i < 10;i++)
    {
        //……
    }
    
    return 0;
}

void f() {
    
}
void fff() {
    
}
void havesex() {
    
}
void qian() {
    
}

一些规范示范：

#include <stdio.h>
#include <stdbool.h>
int main(void)
{
    double balance = 100.00;
    // double a = 100.00; X错；如果使用这样的代码，过一段时间后，当回看代码时，你还会知道a是余额的意思吗？
    
    return 0;
}

bool is_leap_year(int year) {
    // TODO  ==》 意思是:这里还有代码要写
    return false;
}

// 当然，这是下划线命名，有些命名是使用驼峰命名法，这异曲同工：bool isLeapYear(int year){}

我们很容易发现，不同的变量名命名直接会导致阅读体验的分野。

而一个标准规范的变量名命名应具备什么样的特质呢？

可读性好、便于记忆、见名知意；或者更直白的说：一眼就可以看出这是在干什么。我们应心怀这样一句话去命名变量——“优秀的代码命名都是自解释的”。

仍是上述的例子：判断是否为闰年 -is_leap_year()，(关于为何不用中文拼音命名而采用英语命名，这是由语言自身和历史传统影响的，这里不做阐释)，我们能否将其改为is_leap()呢？不能。leap还有跳跃之意，若是如此命名，必会造成歧义；而一个好的变量或函数名应准确表达含义，便于阅读与理解。

变量名命名的注意

但是，准确表达含义并不是要求名字严格按照英文使其变得特别长。举个例子，我们定义一个变量unsigned int the_max_country_number_of_the_olympic_team = 20；如此定义变量名，我们一定会理解这样的变量是何种意思，但我们不难发现这样的问题：太长了！长到难以使用了！所以说，长度问题也是变量名的一个重要问题；如何对变量名的长度和完整性进行取舍，这是我们亟需掌握的能力。

上述论断中，我们认识到一个优秀的变量名可以使人“一眼就可以看出这是在干什么”，也就是说给予人最最直观的体验。所以说，一些变量名往往以动词开头，如：double checkTotal(User user){return 0.00;}；但是一些诸如double CHECK(User user){return 0.00}、double checks(User user){return 0.00}、double havemoney(){}是不合常识与规范的。

这里，我们写一些好的变量名命名(驼峰命名法)。

// 关于速度
double trainVelocity = 310.25;  // 高铁运行时速(km/h)
double velocityInMph = ;  //
// 关于日期
Date currentDate = ;
// 一些行号
int lines;
int linesPerPage;  // 每一页的行数

一个小结：我们的首要认识——变量名命名十分重要，乃至直接决定着我们代码的质量、性能；甚至如果我们的变量命名是有问题的，那么我们的项目到最后总是难以重构与维护。可谓说问题之大了。

我们不妨看看一些著名的项目如Linux的源码，向大师级别的人物学习。

二、更为恰当地命名

我们肯定会有这样的疑问：使用像英语这样的语言，我们所要表达一个相同的意思常常会有不同的表述（比如说：表示钱💴，可能有人表示为double wallet = 100.00，而有些人表示为诸如 money balance等其他名称）。所以说，这种命名方式是否为规范或恰当呢？或者说我们是否有更好的命名方式呢？而当我们面对上述这样不同单词表达相同意思的情况，又该如何选择呢？

这里引入这样的”暴论“——一个好的名字应有2个意思：1. 表达了什么(如：double balance; //表达的就是(用户/账户的)余额)；2. 单词的立意(上述balance具有多个意思:平衡、保持平横、抵消……)，单词的立意本质上说，它就是与前面的类型等因素相称，不造成歧义即仅表现出一种明确的意思。当一个变量名具备这两种性质，那么就会知道它所要表达的本意。

注意：关于变量，我们所要表达的东西一定不能是怎样的；如果是，那么问题出现，因为变量根本不是“怎样的”，而是表达一个”什么“。

// 日常生活用语
studentData;
// input计算机界的学术语==》是更凸显IT界特指的变量
input_stu_data;

inputRec;

double sum;  
// sum的意思？虽然名词词性上是金额总数；但实际上它是属于一种计算机术语还是其他的呢？我们的立意并不清晰
// 假设这个sum变量定义在财务报告系统，那么这个sum是什么？是求和函数还是要干什么？所以会产生歧义，会引起混淆
// 因此为了准确表达总额的含义，我们不妨可以这样定义：double calcValue;这样就会很清晰的知道这是一个值、一个计算总值

所以，我们还是回到上述的2个意思：1. 表达了什么；2. 单词的立意。单词有各种各样的意思，在学术界它是怎样？它是否会有歧义？这是我们所要在乎与考虑的。

三、讲究长度的变量

大家都知道像unsigned int the_max_country_number_of_the_olympic_team = 20；这样的变量名长度一定是有问题的。我们参考以下论文：Debugging effort estimation using software metrics和这个网站IFSQ:SP-5—Poor Choice of Name的概述。

Research Findings: The effort required to debug a program is minimized when variables had names averaging 10 to 16 characters long.

实际情况，在国内的企业命名长度要求大多为：9-15、10-16或8-20，还有些是8-16个。我们平常选取最大范围8-20的长度，可以说是问题不大。

这里，我们还可以参阅这篇文章博客Data Scientists Your Variable Names Are Awful Heres How To Fix Them的论述。

于是，我们对上述极长的代码修改为numTeamMembers。

注意，变量名往往和其所处的作用域来进一步补充完备意思，所以这里虽不呈现奥林匹克之意，但它应该仅作用于奥林匹克的命名空间之下。这是我们之后要谈的。

四、变量作用域与长度及规范

以for语句为例

  // 变量作用域

  // 函数（OOP 方法） 类
 for(int i = length - 1;i >= 0;i --)
 {
     for(int j = 0;j < i;j ++)
     {
        
     }
 }
  // 我们会发现i和k的作用域或者说适用范围只在for语句中，这时候准确说来并无问题。
  // 这时变量范围被局限住了

  // 但是
 int i;
 for(i = length - 1;i >= 0;i --)
 {
     for(int j = 0;j < i;j ++)
     {
        
     }
 }

 i ++;
 i --;
 // 若i超出for的作用范围，这时我们就不能定义为i，因为没人知道这个i是啥；
 // 当我们定义在for循环内我们都知道这是计数器，但脱离for之后，我们的i++,i--又表示什么含义呢？
 // 不得而知，所以不能这样命名。

因此，我们会发现，变量名命名在什么地方会决定变量名该如何命名，函数（OOP 方法）、类、作用域都会决定你如何去命名变量。

这里，我们或可以参阅这本书Software psychology: Human factors in computer and information systems。

结果简要概述：特别短的名字(<8)我们常定义为局部变量，在for循环内可能会更短；它的作用域可能会决定它的长和短：当一个变量名越短，可能它的作用域就越小，甚至小到i,k这样的单字符。

但一些防御性编程会可能刻意绕开这些短的变量名。

变量名可能一样，我们会使用命名空间等所处的域不同来进行划分以区分变量。

// 1. wallet
package com.goolgle.user;
// mysql sql引入要正确
public class Wallet {
    
}
// 2. wallet  
package com.goolgle.dog;
public class Wallet {
    
}

更为学术的说，我们称作这为：划分全局命名空间

namespace User {
    // Wallet
}

namespace Dog {
    // Wallet
}

对于一些不支持上述划分全局命名空间的操作的语言如：C语言。我们可以:

design_Emp
dev_Emp

而对于可以使用package的Java语言，则更为简便:

package com.goolgle.design;
// mysql sql引入要正确
public class Employee {
    
}

package com.goolgle.dev;
public class Employee {
    
}

五、细化:关于变量计数词

我们首先要明确：所要讨论的计数词是什么——这个计数不是循环中的i、j 、k，而是我们经常所用的计数，如：总共的人数、总分数和平均数、最大及最小值等各种各样的东西。我们在设计这些涉及到计算的意思的变量名，我们该怎样比较确恰地命名，这是此段所要探讨的。

#include <stdio.h>
int main(void)
{
    // sum，avg/average，max，min，total……
    // num
    // 这些单词的表述都很好，但我们要注意一些点 
    
    // 举例：员工总数
    // 不建议使用sum，更建议total(总计)
    // int total_emp; // 或直接写全:total_employees

    // 为什么不用num呢？歧义的风险
    // int num_employees; // =》员工数量
    // int employee_num; // =》员工号？
    // 我们将其倒错会产生截然不同的意思
    // 所以，以上命名都不合理
    // 因此，我们可以对其进行规定约束：基本上，将计数词放在后面，除非特殊要求
 // 我们这样写：名词提前-计数词放后
    // 注意：这是为了好看的一种约束，这不是死板的。
    // 对错并无分别，取决于企业的规范
    int employee_total;
   // 若要表达员工号，也是尽可能不用num
    int employee_index;
    // 我们把计数单词放在前面，就意味者它的中心义或内涵
    return 0;
}

结论：常进行一种约束：名词提前-计数词放后

六、细化:对立词选择建议

在计算机术语中，常有一些有意思的词，他们总是对立的，然后这些对立的词常相匹配组成一些完整的变量。

#include <stdio.h>
int main(void)
{
    up/down
    old/new
 first/last
    min/max
    opened/closed
    locked/unlocked
    ...
    begin/end
    return 0;
}

七、细化:常量、宏与指针

建议直接参考伟大的项目linux的源码。

#define NUM_FIVE 5  // × 表示具体数字错误也就是说不能出现FIVE 可以改为数组的容量

// C++的常量：Google常声明常量以k开头
// constant
const int kDaysInYear = 100;
// 题外话：匈牙利命名法
int *pSize;

这只是一个约定

八、细化:循环计数器i,j,k

#include <iostream>
int main(void)
{
    for(int i = 0;i < totalEmp.count;i++)
    {
        data[i] = j;
    }
}

从编程艺术来考虑，循环当中使用i,j,k是否规范？实际情况是允许的（前提是必须定义在循环里面，即作用域的界定范围在循环中，不会污染到其他东西）。例：JavaScript这门语言若定义为全局，它就会造成变量的污染。

但是，如果i定义在循环之外，这么写是存在问题的，因为这样的i很可能被循环之后的代码运用到，那此时这个i是什么数据？它是垃圾数据，它并没有得到有效的管理。

如果我们的i不仅在循环内用到，还在其外用到，那么它就不能定义为i，而应定义为一个更具体的名称。

#include <iostream>
int main(void)
{
    int record_count = 0;
    
    while ( condition ) {
        record_count ++;
    }
    
    record_count ++;
    cout << record_count << endl;
    
    return 0；
}

还有一种情况

#include <iostream>
int main(void)
{
    for(int i = 0;i < 9;i ++) {
        for(int j = 0;j < i;j ++) {
            // TODO
        }
    }
    // 这样写，并不是很好
    // 如果for循环多且嵌套或数组二维或更高维，那就不要再i,j,k了
    // 因为：我们很可能会不知道谁是谁了
    // 而要规避掉这样的风险，或者说更好一些，只需要对变量名规范命名就可以了；这样在逻辑上，我们可以直接清晰的明白所循环的是什么

    return 0；
}

需要指明：项目工程的开发与维护不可能仅一个人搞，团队协作是常态，因此好的变量命名会带给其他人对你代码直观的理解，别人才更易接手这样的项目。

九、细化:枚举命名的讲究

给人的感觉与常量相似，因为也是大写。

#include <stdio.h>
int main(void)
{
    enum AlternateurlTableErrors {
        OK = 0,
        OUT_OF_MEMORY = 1,
        MALFORMED_INPUT = 2
    };
    return 0；
}

也有些语言、企业会规定加前缀等东西。

十、细化:临时变量的讲究

#include <stdio.h>
int main(void)
{
    // 如果说后面还会用到temp这个变量，那么最好不要定义为temp
    // 它不像在for循环中的，定义作用域在内
    for(int i = 0;i < 19;i ++) {
        int temp = array[i];
        ..
        ...
    }
    // 但是如果后面还要被使用，那就不要定义为temp
    // 比如求三角形周长
    // int temp = a + b + c; ×错 有些随意 缺乏描述
    int triangle_perimeter = a + b + c;
    
    return 0；
}

HTTP协议初探

Sun, 26 Jan 2025 00:00:00 GMT

初识HTTP

Before Reading : An overview of HTTP

背景知识

Q: 从浏览器的地址栏输入URL()按下回车到页面展示出来,发生了什么? A: 简而言之,包括 ==URL 解析、DNS 解析、TCP 连接建立、HTTP 请求发送、服务器处理请求、HTTP 响应发送、浏览器接收响应、浏览器渲染页面、加载资源和 JavaScript 执行==。其中每个步骤又包含多个子步骤和复杂的处理逻辑.

先回想一下TCP/IP 协议栈(应用层;传输层;网络层;网络接口层),在这里,我们呢主要关注最上层的应用层中HTTP相关内容.

什么是HTTP?

HTTP（HyperText Transfer Protocol，超文本传输协议）是互联网上应用最广泛的一种网络协议。它是客户端和服务器之间进行通信的基础协议，用于传输超文本（如 HTML 文档）和其他资源（如图像、视频、JSON 数据等）。

概念

超文本传输协议：HTTP 是一种应用层协议，用于在客户端和服务器之间传输超文本（如 HTML 文档）和其他资源。
基于 TCP 协议：HTTP 建立在 TCP/IP 协议栈之上，使用 TCP 协议进行数据传输。默认情况下，HTTP 使用 80 端口，HTTPS 使用 443 端口。
请求-响应模型：HTTP 采用请求-响应模型，客户端发送 HTTP 请求，服务器返回 HTTP 响应。
简单可扩展：HTTP 协议设计简单，易于实现和扩展。它支持多种请求方法（如 GET、POST、PUT、DELETE 等）和头部字段，可以根据需要进行扩展。
无状态：HTTP 协议是无状态的，即服务器不会保存客户端的请求状态。每个请求都是独立的，服务器不会记住之前的请求。

特点

1. 请求-响应模型

HTTP 采用请求-响应模型，客户端发送 HTTP 请求，服务器返回 HTTP 响应。请求和响应都包含以下几个部分：

请求行/状态行：包含请求方法（如 GET、POST）、请求路径（如 /index.html）和 HTTP 协议版本（如 HTTP/1.1）。
请求头/响应头：包含各种头部字段，如 User-Agent、Accept、Content-Type、Content-Length 等。
请求体/响应体：包含请求或响应的数据，通常是 HTML、JSON、XML 等格式的数据。

2. 简单可扩展

HTTP 协议设计简单，易于实现和扩展。它支持多种请求方法（如 GET、POST、PUT、DELETE 等）和头部字段，可以根据需要进行扩展。例如：

请求方法：HTTP 定义了多种请求方法，如 GET（获取资源）、POST（提交数据）、PUT（更新资源）、DELETE（删除资源）等。
头部字段：HTTP 支持多种头部字段，如 User-Agent（客户端标识）、Accept（客户端接受的媒体类型）、Content-Type（请求或响应的数据类型）等。

3. 无状态

HTTP 协议是无状态的，即服务器不会保存客户端的请求状态。每个请求都是独立的，服务器不会记住之前的请求。这种设计简化了服务器的设计和实现，但也带来了一些问题，如需要通过其他方式（如 Cookie、Session）来维护客户端状态。

4. 基于 TCP 协议

HTTP 建立在 TCP/IP 协议栈之上，使用 TCP 协议进行数据传输。TCP 协议提供了可靠的、面向连接的通信服务，确保数据在网络中的可靠传输。

5. 支持多种资源类型

HTTP 不仅用于传输超文本（如 HTML 文档），还支持传输多种资源类型，如图像、视频、音频、JSON 数据、XML 数据等。通过 Content-Type 头部字段，服务器可以指定响应数据的类型，客户端可以根据类型进行处理。

协议分析

发展

HTTP/0.9 (1991) - The One Liner

特点：
- 最早的 HTTP 版本，非常简单。
- 只支持 GET 请求方法。
- 没有请求头和响应头，只有请求行和响应体。
- 响应体只能是 HTML 文档。
*示例:
请求

Get /index.html

响应

(response body)
(connection closed)

HTTP/1.0（1996）

特点：
- 引入了请求头和响应头，支持多种请求方法（如 GET、POST、HEAD）
- 添加了状态码(Status code) 以标识响应
- 支持多种资源类型（如 HTML、图像、视频、纯文本等）。
- 每个请求都需要建立一个新的 TCP 连接，请求完成后立即关闭连接。
  - 引入了字符集支持, 包括多部分类型、授权、缓存、内容编码等
示例:
请求如下所示:
- 除了请求,
- 客户端还发送了它的个人信息,
- 要求的响应类型
- 等等等等

GET / HTTP/1.0
Host: cs.fyi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

响应如下所示:
- 响应的开头是吧友版本号的HTTP,接着一个状态码和一个描述它的词或原因

HTTP/1.0 200 OK 
Content-Type: text/html
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84

(response body)
(connection closed)

在这一版本,请求和响应仍然保持着ASCII编码, 但是响应体课包含图片,视频,纯文本和其他内容类型, 比起"Hyper Text", HMTP(Hypermedia transfer protocol)或许是更恰切的描述,不过...

HTTP/1.0的一个主要缺点是不能为每此连接提供多个请求。也就是说，无论何时客户机需要从服务器获得什么东西，它都必须打开一个新的 TCP 连接，在这个单个请求完成之后，连接将被关闭。对于任何下一个需求，它必须在一个新的连接上。 So,Why is it BAD? 让我们假设您访问了一个包含10个图像、5个样式表和5个 javascript 文件的网页，当请求该网页时，总共需要获取20个项目。由于服务器在请求完成后立即关闭连接，因此将有一系列20个独立的连接，其中每个项目将在其各自的连接上逐个提供服务。这种大量的连接会导致严重的性能损失，因为需要一个新的 TCP 连接会造成严重的性能损失，这是由于三路握手后缓慢启动造成的

Three-way Handshake

客户端发送 SYN 包：客户端向服务器发送一个 SYN（同步）包(由客户机拾取一个随机数假设为x 组成)，请求建立连接。
服务器发送 SYN-ACK 包：服务器收到 SYN 包后，向客户端发送一个 SYN-ACK（同步-确认）包(由服务器拾取的 y 和数字 x+1，其中 x 是客户端发送的数字组成)，表示同意建立连接。
客户端发送 ACK 包：客户端收到 SYN-ACK 包后，向服务器发送一个 ACK（确认）包(由 y+1 组成)，表示连接已建立。

三次握手完成后，客户端和服务器之间的数据共享就可以开始了。值得注意的是，客户端可以在调度最后一个 ACK 数据包后立即开始发送应用程序数据，但服务器仍然必须等待收到 ACK 数据包才能完成请求。

当然, 严重的性能损耗, 不仅仅是由于 TCP 连接的建立过程（三次握手）造成的，还包括 TCP 连接的关闭、连接的重复建立和关闭、并发请求的限制以及缺乏缓存机制等因素。

HTTP/1.1（1997）

特点：
- 引入了持久连接（Keep-Alive），允许多个请求和响应复用同一个 TCP 连接，减少了连接建立和关闭的开销。要关闭连接，请求上必须有标题 Connection: close。客户端通常在最后一个请求中发送此标头以安全地关闭连接。
- 支持管道化（Pipelining），允许客户端在一个 TCP 连接上发送多个请求，服务器按顺序返回响应。那么,客户机如何知道这是第一个响应下载完成和下一个响应的内容开始的地方? 要解决这个问题，必须有 Content-Length 头，客户端可以使用它来确定响应的结束位置，并且可以开始等待下一个响应。
  
  It should be noted that in order to benefit from persistent connections or pipelining, Content-Length header must be available on the response, because this would let the client know when the transmission completes and it can send the next request (in normal sequential way of sending requests) or start waiting for the the next response (when pipelining is enabled).
  
  But there was still an issue with this approach. And that is, what if the data is dynamic and server cannot find the content length before hand? Well in that case, you really can’t benefit from persistent connections, could you?! In order to solve this HTTP/1.1 introduced chunked encoding. In such cases server may omit content-Length in favor of chunked encoding (more to it in a moment). However, if none of them are available, then the connection must be closed at the end of request.
  - 分块传输(Chunked Transfers) , 在动态内容的情况下，当服务器在传输开始时无法真正找到 Content-Length 时，它可能会开始分块发送内容（逐块），并在发送时为每个块添加 Content-Length。当所有 chunk 都发送完毕时，即整个传输已完成，它会发送一个空 chunk，即 Content-Length 设置为零的 chunk，以识别传输已完成的客户端。为了通知客户端有关分块传输的信息，服务器包含标头 Transfer-Encoding： chunked
- 引入了缓存机制（如 Cache-Control、ETag），提高了性能。
- 支持虚拟主机（Virtual Hosts），允许多个域名共享同一个 IP 地址。
- 引入了更多的请求方法（如 PUT、DELETE、OPTIONS、PATCH）和状态码。
  - 客户端 Cookie
  - 增强的压缩支持
  - ......

HTTP/2（2015）

特点：
- 基于 Google 的 SPDY 协议，改进了性能和安全性。
- 引入了多路复用（Multiplexing），允许多个请求和响应在同一个 TCP 连接上并行传输，解决了 HTTP/1.1 的队头阻塞问题, 即客户端不必等待需要时间的请求，而其他请求仍将得到处理。
- 引入了头部压缩（Header Compression），减少了传输的数据量。它的本质是，当我们不断从同一个客户端访问服务器时，我们会一遍又一遍地在标头中发送大量冗余数据，有时可能会有 cookie 增加标头大小，从而导致带宽使用和延迟增加
  
  与请求和响应不同，标头不是以 gzip 或 compress 等格式压缩的，但有一种不同的标头压缩机制，即使用霍夫曼代码对文本值进行编码，并且标头表由客户端和服务器维护，客户端和服务器在后续请求中省略任何重复的标头（例如用户代理等），并使用由两者维护的标头表引用它们。
补充: 当我们谈论 Headers 时，Headers 仍然与 HTTP/1.1 中相同，除了添加了一些伪 Headers，即 ：method、：scheme、：host 和 :p ath
- 支持服务器推送（Server Push），服务器可以在客户端请求之前主动推送资源，减少了客户端的等待时间。例如，假设浏览器加载了一个网页，它会解析整个页面以找出它必须从服务器加载的远程内容，然后向服务器发送后续请求以获取该内容
服务器推送允许服务器通过推送它知道客户端将需要的数据来减少往返。它是如何完成的呢? 服务器发送一个名为 PUSH_PROMISE 的特殊帧通知客户端，“嘿，我即将将此资源发送给您！不要向我要。” PUSH_PROMISE 帧与导致推送发生的流相关联，并且它包含承诺的流 ID，即服务器将发送要推送的资源的流。
- 使用二进制帧（Binary Framing） 代替了文本格式，提高了解析效率。作为二进制协议，它更容易解析，但与 HTTP/1.x 不同的是，它不再能被人眼读取。HTTP/2 的主要构建块是帧和流
```
HTTP 消息现在由一个或多个帧组成。元数据有一个 HEADERS 帧，有效负载有一个  DATA 帧，并且存在几种其他类型的帧（HEADERS、DATA、RST_STREAM、SETTINGS、PRIORITY 等），您可以通过 [HTTP/2 规范](https://http2.github.io/http2-spec/#FrameTypes)进行检查。
```
每个 HTTP/2 请求和响应都有一个唯一的流 ID，并被划分为帧。帧只不过是二进制数据片段。帧的集合称为 Stream。每个帧都有一个 stream id，用于标识它所属的流，并且每个帧都有一个通用的标头。此外，除了 stream ID 唯一之外，值得一提的是，客户端发起的任何请求都使用奇数，而来自服务器的响应具有偶数 stream ID。

除了 HEADERS 和 DATA 之外，这里值得一提的另一个帧类型是 RST_STREAM。这是一种特殊的帧类型，用于中止某些流，即客户端可以发送此帧以让服务器知道我不再需要此流。在 HTTP/1.1 中，让服务器停止向客户端发送响应的唯一方法是关闭连接，这会导致延迟增加，因为必须为任何连续请求打开新连接。在 HTTP/2 中，客户端可以使用 RST_STREAM 并停止接收特定流，而连接仍将打开，而其他流仍将处于活动状态。
- 请求优先级(Request Prioritization)
客户端可以通过在打开流的 HEADERS 帧中包含优先级信息来为流分配优先级。在任何其他时间，客户端都可以发送 PRIORITY 帧来更改流的优先级。

在没有任何优先级信息的情况下，server 异步处理请求，即没有任何顺序。如果为流分配了优先级，则根据此优先级信息，server 决定需要提供多少资源来处理哪个请求。
示例：
- HTTP/2 使用二进制帧传输数据，无法直接查看文本格式。

HTTP/3（2020）

特点：
- 基于 Google 的 QUIC 协议，改进了性能和安全性。
- 使用 UDP 协议代替 TCP 协议，减少了连接建立和拥塞控制的开销。
- 引入了多路复用（Multiplexing），允许多个请求和响应在同一个 UDP 连接上并行传输，解决了 TCP 的队头阻塞问题。
- 引入了头部压缩（QPACK），减少了传输的数据量。
- 支持 0-RTT（Zero Round Trip Time）连接建立，减少了连接建立的时间。
- 使用 TLS 1.3 进行加密，提高了安全性。
示例：
- HTTP/3 使用 QUIC 协议传输数据，无法直接查看文本格式。

总结

HTTP/0.9：最早的版本，非常简单，只支持 GET 请求。
HTTP/1.0：引入了请求头和响应头，支持多种请求方法和资源类型。
HTTP/1.1：引入了持久连接、管道化、缓存机制、虚拟主机等，提高了性能和功能。
HTTP/2：基于 SPDY 协议，引入了多路复用、头部压缩、服务器推送等，进一步提高了性能。
HTTP/3：基于 QUIC 协议，使用 UDP 代替 TCP，引入了多路复用、头部压缩、0-RTT 连接建立等，进一步提高了性能和安全性。

报文

以 ==HTTP/1.1== 为例

请求方法 Method

1. GET

用途：获取资源。
特点：
- 请求参数通过 URL 传递，通常用于获取数据。
- 请求是幂等的，即多次请求不会改变服务器状态。
- 请求体为空。
示例：

GET /index.html HTTP/1.1
Host: www.example.com

2. POST

用途：提交数据，通常用于创建资源。
特点：
- 请求参数通过请求体传递，通常用于提交表单数据或上传文件。
- 请求不是幂等的，即多次请求可能会改变服务器状态。
- 请求体可以包含数据。
示例：

POST /submit HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded

name=John&age=30

3. PUT

用途：更新资源，通常用于替换现有资源。
特点：
- 请求参数通过请求体传递，通常用于更新资源。
- 请求是幂等的，即多次请求不会改变服务器状态。
- 请求体可以包含数据。
示例：

PUT /user/123 HTTP/1.1
Host: www.example.com
Content-Type: application/json
{
  "name": "John",
  "age": 30
}

4. DELETE

用途：删除资源。
特点：
- 请求参数通过 URL 传递，通常用于删除资源。
- 请求是幂等的，即多次请求不会改变服务器状态。
- 请求体为空。
示例：

DELETE /user/123 HTTP/1.1
Host: www.example.com

5. HEAD

用途：获取资源的元数据，不返回响应体。
特点：
- 请求参数通过 URL 传递，通常用于获取资源的元数据（如响应头）。
- 请求是幂等的，即多次请求不会改变服务器状态。
- 响应体为空。
示例：

HEAD /index.html HTTP/1.1
Host: www.example.com

6. OPTIONS

用途：获取服务器支持的请求方法和功能。
特点：
- 请求参数通过 URL 传递，通常用于获取服务器支持的请求方法和功能。
- 请求是幂等的，即多次请求不会改变服务器状态。
- 响应体通常包含服务器支持的请求方法和功能。
示例：

OPTIONS /user HTTP/1.1
Host: www.example.com

7. PATCH

用途：部分更新资源。
特点：
- 请求参数通过请求体传递，通常用于部分更新资源。
- 请求不是幂等的，即多次请求可能会改变服务器状态。
- 请求体可以包含数据。
示例：

PATCH /user/123 HTTP/1.1
Host: www.example.com
Content-Type: application/json
{
  "age": 31
}

8. CONNECT

用途：建立隧道，通常用于代理服务器。
特点：
- 请求参数通过 URL 传递，通常用于建立隧道。
- 请求不是幂等的，即多次请求可能会改变服务器状态。
- 请求体为空。
示例：

CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com

9. TRACE

用途：回显请求，用于调试。
特点：
- 请求参数通过 URL 传递，通常用于调试。
- 请求是幂等的，即多次请求不会改变服务器状态。
- 响应体包含请求的原始数据。
示例：

TRACE /index.html HTTP/1.1
Host: www.example.com

==总结==

方法	用途
GET	获取资源
POST	提交数据，通常用于创建资源
PUT	更新资源，通常用于替换现有资源
DELETE	删除资源
HEAD	获取资源的元数据，不返回响应体
OPTIONS	获取服务器支持的请求方法和功能
PATCH	部分更新资源
CONNECT	建立隧道，通常用于代理服务器
TRACE	回显请求，用于调试

补充:

Safe(安全的) : 不会修改服务器的数据的方法 GET HEAD OPTIONS
Idempotent(幂等的) : 同样的请求被执行一次与连续执行多次的效果是==一样==的, 服务器的状态也是==一样==的, 所有的safe方法都是Idempotent的 GET HEAD OPTIONS DELETE

状态码 Status Code

Status Code	解释
1xx	信息性状态码，表示请求已被接收，继续处理
2xx	成功状态码，表示请求已成功处理
3xx	重定向状态码，表示需要进一步操作才能完成请求
4xx	客户端错误状态码，表示客户端请求有误
5xx	服务器错误状态码，表示服务器处理请求时出错

常见的例子

100 Continue：服务器已接收到请求头，客户端应继续发送请求体
200 OK：请求成功，服务器返回请求的资源
301 Moved Permanently：请求的资源已永久移动到新位置，客户端应使用新的 URL
302 Found：请求的资源临时移动到新位置，客户端应继续使用原 URL
401 Unauthorized：请求需要身份验证，客户端未提供有效的身份验证信息
404 Not Found：请求的资源不存在
500 Internal Server Error：服务器内部错误，无法完成请求
502 Bad Gateway：服务器作为网关或代理时，从上游服务器收到无效响应
504 Gateway Timeout：服务器作为网关或代理时，等待上游服务器的响应超时

RESTful API

RESTful API（Representational State Transfer,表现层状态转化 API）是一种基于 HTTP 协议的 Web 服务设计风格它通过标准的 HTTP 方法（如 GET、POST、PUT、DELETE）来操作资源，并使用统一的接口来访问和操作这些资源。RESTful API 的设计理念是简单、轻量、易于扩展和维护。

核心概念

资源（Resource）

资源是 RESTful API 的核心概念，表示系统中的任何对象或数据。资源可以是用户、订单、产品、文章等。
每个资源都有一个唯一的标识符（URI），用于在系统中唯一标识该资源。

统一接口（Uniform Interface）

统一接口是指 RESTful API 使用标准的 HTTP 方法来操作资源。常见的 HTTP 方法包括：
- GET：获取资源。
- POST：创建资源。
- PUT：更新资源。
- DELETE：删除资源。
通过统一接口，客户端可以使用相同的接口来访问和操作不同的资源，简化了 API 的设计和使用。

状态转移（State Transfer）

状态转移是指客户端和服务器之间的交互过程中，资源的状态会发生变化。RESTful API 通过 HTTP 方法来实现状态转移。
例如，客户端发送一个 POST 请求来创建一个新资源，服务器接收到请求后，资源的状态从“不存在”变为“存在”。

无状态（Stateless）

无状态是指服务器不会保存客户端的请求状态。每个请求都是独立的，服务器不会记住之前的请求。
这种设计简化了服务器的设计和实现，但也带来了一些问题，如需要通过其他方式（如 Cookie、Session）来维护客户端状态。

RESTful API 的设计原则

使用名词表示资源

资源应该使用名词来表示，而不是动词。例如，使用 /users 表示用户资源，而不是 /getUsers。

使用 HTTP 方法操作资源

使用标准的 HTTP 方法来操作资源：
- GET：获取资源。
- POST：创建资源。
- PUT：更新资源。
- DELETE：删除资源。

使用 URI 标识资源

每个资源都有一个唯一的 URI，用于在系统中唯一标识该资源。例如，/users/123 表示 ID 为 123 的用户资源。

使用 JSON 或 XML 表示资源

资源通常使用 JSON 或 XML 格式表示，便于客户端和服务器之间的数据交换。

使用状态码表示请求结果

使用标准的 HTTP 状态码表示请求的结果，如 200 OK、404 Not Found、500 Internal Server Error 等。

示例

==用户管理==

获取所有用户

请求方法：GET
URI：/users
示例：

GET /users HTTP/1.1
Host: api.example.com

响应：

[
  {
 "id": 1,
 "name": "Alice",
 "email": "alice@example.com"
  },
  {
 "id": 2,
 "name": "Bob",
 "email": "bob@example.com"
  }
]

获取单个用户

请求方法：GET
URI：/users/{id}
示例：

GET /users/1 HTTP/1.1
Host: api.example.com

响应：

{
  "id": 1,
  "name": "Alice",
  "email": "alice@example.com"
}

创建用户

请求方法：POST
URI：/users
示例：

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json
{
  "name": "Charlie",
  "email": "charlie@example.com"
}

响应：

{
  "id": 3,
  "name": "Charlie",
  "email": "charlie@example.com"
}

更新用户

请求方法：PUT
URI：/users/{id}
示例：

PUT /users/1 HTTP/1.1
Host: api.example.com
Content-Type: application/json
{
  "name": "Alice Smith",
  "email": "alice.smith@example.com"
}

响应：

{
  "id": 1,
  "name": "Alice Smith",
  "email": "alice.smith@example.com"
}

删除用户

请求方法：DELETE
URI：/users/{id}
示例：

DELETE /users/1 HTTP/1.1
Host: api.example.com

响应：

{
  "message": "User deleted successfully"
}

常用请求头

1. Host

用途：指定请求的目标主机和端口。
示例：

Host: www.example.com

2. User-Agent

用途：标识客户端的类型和版本。如:UA头部等
示例：

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36

3. Accept

用途：指定客户端可以接受的响应内容类型。
示例：

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8

4. Accept-Language

用途：指定客户端可以接受的自然语言。
示例：

Accept-Language: en-US,en;q=0.9,zh-CN;q=0.8,zh;q=0.7

5. Accept-Encoding

用途：指定客户端可以接受的编码方式（如 gzip、deflate）。
示例：

Accept-Encoding: gzip, deflate, br

6. Content-Type

用途：指定请求体的 MIME 类型。 MIME 类型（Multipurpose Internet Mail Extensions Type）是一种标准，用于表示文档、文件或字节流的性质和格式。MIME 类型由两部分组成：类型（Type）和子类型（Subtype），中间用斜杠（/）分隔。例如：
- text/plain：表示纯文本文件。
- text/html：表示 HTML 文件。
- application/json：表示 JSON 数据。
- image/jpeg：表示 JPEG 图像文件。
- audio/mpeg：表示 MP3 音频文件。
- video/mp4：表示 MP4 视频文件。
示例：

Content-Type: application/json

7. Content-Length

用途：指定请求体的长度（以字节为单位）。
示例：

Content-Length: 1234

8. Authorization

用途：指定客户端的身份验证信息。
示例：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

9. Cookie

用途：指定客户端发送的 Cookie 信息。有Cookie并且同域访问时会自动带上
示例：

Cookie: session_id=abc123; user_id=456

10. Referer

用途：指定请求的来源 URL(适用于所有类型的请求, 会精确到详细页面地址, csrf拦截长常到这个字段)。
示例：

Referer: https://www.example.com/previous-page

11. Origin

用途：指定请求的来源域名，通常用于跨域请求。Origin比Refer更尊重隐私
示例：

Origin: https://www.example.com

12. Cache-Control

用途：指定缓存策略。
示例：

Cache-Control: no-cache

13. If-Modified-Since

用途：指定请求资源的最后修改时间，用于条件请求。对应服务器的Last-Modified, 用来匹配看文件是否变动,只能精确到1s之内
示例：

If-Modified-Since: Sat, 29 Oct 2022 19:43:31 GMT

14. If-None-Match

用途：指定请求资源的 ETag，用于条件请求。对应服务器的ETag, 用来匹配文件内容是否改变(非常精确)
示例：

If-None-Match: "abc123456789"

15. Connection

用途：指定连接的管理方式，如保持连接（Keep-Alive）或关闭连接（Close）。
示例：

Connection: keep-alive

16. Upgrade

用途：指定客户端希望升级的协议，如 WebSocket。
示例：

Upgrade: websocket

17. X-Requested-With

用途：标识请求是否为 AJAX 请求。
示例：

X-Requested-With: XMLHttpRequest

18. X-Forwarded-For

用途：指定客户端的真实 IP 地址，通常用于代理服务器。
示例：

X-Forwarded-For: 192.0.2.1

19. X-Forwarded-Proto

用途：指定客户端请求的协议（如 HTTP 或 HTTPS），通常用于代理服务器。
示例：

X-Forwarded-Proto: https

20. X-CSRF-Token

用途：指定 CSRF（跨站请求伪造）令牌，用于防止 CSRF 攻击。
示例：

X-CSRF-Token: abc123456789

常见响应头

1. Content-Type

用途：指定响应体的 MIME 类型。
示例：

Content-Type: text/html; charset=UTF-8

解释：Content-Type 响应头用于指定响应体的 MIME 类型，如 text/html 表示 HTML 文档，application/json 表示 JSON 数据。charset 参数用于指定字符编码，如 UTF-8。

2. Cache-Control

用途：指定缓存策略。
示例：

Cache-Control: max-age=3600, public

解释：Cache-Control 响应头用于指定缓存策略，如 max-age=3600 表示资源可以在 3600 秒（1 小时）内使用缓存，public 表示资源可以被任何缓存存储。

3. Last-Modofied

用途：指定资源的最后修改时间。
示例：

Last-Modified: Wed, 21 Oct 2025 07:28:00 GMT

解释：Last-Modified 响应头用于指定资源的最后修改时间，客户端在后续请求中可以通过 If-Modified-Since 请求头来判断资源是否已修改。

4. Expires

用途：指定资源的过期时间。
示例：

Expires: Wed, 21 Oct 2025 07:28:00 GMT

解释：Expires 响应头用于指定资源的过期时间，表示资源在指定时间之前可以使用缓存，而不需要重新请求服务器。

5. Max-age

用途：指定资源的缓存时间（以秒为单位）。
示例：

http
Cache-Control: max-age=3600

解释：Max-Age 是 Cache-Control 响应头的一个指令，用于指定资源的缓存时间（以秒为单位）。它告诉客户端在指定时间内可以使用缓存的资源，而不需要重新请求服务器。

6. Set-Cookie

用途：设置 Cookie。
示例：

http
Set-Cookie: session_id=abc123; Expires=Wed, 21 Oct 2025 07:28:00 GMT; Path=/; Secure; HttpOnly

解释：Set-Cookie 响应头用于设置 Cookie，客户端在后续的请求中会将该 Cookie 发送回服务器。Expires 参数用于指定 Cookie 的过期时间，Path 参数用于指定 Cookie 的路径，Secure 参数表示 Cookie 只能通过 HTTPS 协议发送，HttpOnly 参数表示 Cookie 不能通过 JavaScript 访问。

7. Server

用途：指定服务器软件的名称和版本。
示例：

http
Server: Apache/2.4.46 (Unix)

解释：Server 响应头用于指定服务器软件的名称和版本，如 Apache/2.4.46 表示服务器使用的是 Apache 2.4.46 版本。

8.Access-Control-Allow-Origin

用途：指定允许访问资源的源（域名）。
示例：

Access-Control-Allow-Origin: *

解释：Access-Control-Allow-Origin 响应头用于指定允许访问资源的源（域名）。* 表示允许所有域名访问资源，也可以指定具体的域名，如 https://www.example.com。

缓存

HTTP 缓存（HTTP Caching）是一种用于减少网络请求和提高网站性能的技术。通过缓存，客户端（通常是浏览器）可以在本地存储资源的副本，并在后续请求中使用这些缓存的资源，而不需要重新请求服务器。HTTP 缓存可以显著减少网络延迟和带宽消耗，提高网站的响应速度和用户体验。

HTTP 缓存的类型

强缓存

强缓存是指客户端在缓存有效期内直接使用本地缓存的资源，而不需要向服务器发送请求。强缓存通过以下响应头来控制：

Cache-Control：指定缓存策略，如 max-age、public、private、no-cache、no-store 等。
Expires：指定资源的过期时间，表示资源在指定时间之前可以使用缓存。

Cache-Control 指令到期
max-age：指定资源的缓存时间（以秒为单位）。例如，Cache-Control: max-age=3600 表示资源可以在 3600 秒（1 小时）内使用缓存。可缓存性
public：表示资源可以被任何缓存存储，包括代理服务器。
private：表示资源只能被客户端缓存，不能被代理服务器缓存。
no-cache：表示资源在使用缓存之前必须向服务器验证，即使缓存未过期。
no-store：表示资源不能被缓存，每次请求都必须从服务器获取最新的资源。重新验证/重新加载
must-revaliable: 一旦资源过期，在成功向原始服务器验证之前，不能使用

Expires 响应头

Expires 响应头的值是一个具体的日期和时间，表示资源的过期时间。例如，Expires: Wed, 21 Oct 2025 07:28:00 GMT 表示资源在 2025 年 10 月 21 日 07:28:00 之前可以使用缓存。

协商缓存

协商缓存是指客户端在缓存过期后，向服务器发送请求，询问资源是否有更新。服务器通过比较资源的最后修改时间和客户端的缓存时间，决定是否返回新的资源。协商缓存通过以下响应头和请求头来控制：

Last-Modified 和 If-Modified-Since：通过资源的最后修改时间来判断资源是否有更新。
ETag 和 If-None-Match：通过资源的唯一标识符（ETag）来判断资源是否有更新。

Last-Modified 和 If-Modified-Since

Last-Modified：服务器在响应头中返回资源的最后修改时间。例如，Last-Modified: Wed, 21 Oct 2025 07:28:00 GMT。
If-Modified-Since：客户端在请求头中发送资源的最后修改时间，服务器通过比较这个时间和资源的实际修改时间，决定是否返回新的资源。

ETag 和 If-None-Match

ETag：服务器在响应头中返回资源的唯一标识符（ETag）。例如，ETag: "abc123456789"。
If-None-Match：客户端在请求头中发送资源的 ETag，服务器通过比较这个 ETag 和资源的实际 ETag，决定是否返回新的资源。

HTTP 缓存的工作流程

强缓存的工作流程
客户端请求资源：客户端向服务器发送请求，请求某个资源。
服务器返回资源和缓存策略：服务器返回资源，并在响应头中设置 Cache-Control 和 Expires 等缓存策略。
客户端缓存资源：客户端根据缓存策略缓存资源。
客户端使用缓存资源：在缓存有效期内，客户端直接使用本地缓存的资源，而不需要重新请求服务器。
协商缓存的工作流程
客户端请求资源：客户端向服务器发送请求，请求某个资源。
服务器返回资源和缓存策略：服务器返回资源，并在响应头中设置 Last-Modified 和 ETag 等缓存策略。
客户端缓存资源：客户端根据缓存策略缓存资源。
客户端缓存过期：在缓存过期后，客户端向服务器发送请求，并在请求头中设置 If-Modified-Since 和 If-None-Match。
服务器验证资源：服务器通过比较 If-Modified-Since 和 If-None-Match 与资源的实际修改时间和 ETag，决定是否返回新的资源。
服务器返回响应：如果资源未修改，服务器返回 304 Not Modified 响应，客户端继续使用缓存的资源；如果资源已修改，服务器返回新的资源。

缓存的最佳实践

使用 Cache-Control 和 Expires

对于静态资源（如图片、CSS 文件、JavaScript 文件），可以设置较长的 max-age 和 Expires，以减少客户端对服务器的请求，提高网站的性能。
对于动态内容（如 API 响应），可以设置较短的 max-age 和 Expires，以确保客户端能够及时获取最新的内容。

使用 Last-Modified 和 ETag

对于经常更新的资源，可以使用 Last-Modified 和 ETag 进行协商缓存，减少带宽消耗。
对于不经常更新的资源，可以使用强缓存策略，减少客户端对服务器的请求。

避免缓存敏感数据

对于包含敏感数据的响应（如用户个人信息、支付信息等），应设置 Cache-Control: no-store，确保数据不会被缓存。

使用 CDN

使用内容分发网络（CDN）可以进一步提高缓存的效果，减少服务器的负载和网络延迟。

Cookie

Cookie 是一种在客户端（通常是浏览器）和服务器之间传递的小型文本数据。服务器可以通过 HTTP 响应头（Set-Cookie）将 Cookie 发送给客户端，客户端在后续的请求中通过 HTTP 请求头（Cookie）将 Cookie 发送回服务器。Cookie 通常用于存储用户会话信息、用户偏好设置、购物车内容等。

Cookie 的用途

会话管理

会话管理是 Cookie 最常见的用途之一。服务器可以通过 Cookie 来识别用户的会话，从而实现用户登录状态的保持。
例如，当用户登录网站时，服务器会生成一个唯一的会话 ID，并将其存储在 Cookie 中。客户端在后续的请求中会将该 Cookie 发送回服务器，服务器通过会话 ID 识别用户。

个性化设置

个性化设置是指根据用户的偏好设置，提供个性化的内容和服务。服务器可以通过 Cookie 存储用户的偏好设置，并在后续的请求中根据这些设置提供个性化的内容。
例如，网站可以根据用户的语言偏好设置，提供不同语言的页面内容。

购物车

购物车是电子商务网站中常见的功能。服务器可以通过 Cookie 存储用户的购物车内容，并在用户浏览网站时保持购物车的状态。
例如，当用户将商品添加到购物车时，服务器会将商品信息存储在 Cookie 中。用户在浏览其他页面时，购物车内容会保持不变。

跟踪用户行为

跟踪用户行为是指通过 Cookie 记录用户的浏览行为，从而进行用户行为分析和广告投放。
例如，广告平台可以通过 Cookie 记录用户的浏览历史，从而向用户展示相关的广告。

Cookie 的属性

Cookie 可以通过多个属性来控制其行为和生命周期。以下是一些常见的 Cookie 属性：

Name 和 Value

Name：Cookie 的名称，用于在客户端和服务器之间唯一标识该 Cookie。
Value：Cookie 的值，存储在 Cookie 中的数据。

Domain

Domain：指定 Cookie 可以发送给哪些域名。默认情况下，Cookie 只能发送给设置它的域名。
例如，如果 Domain 设置为 example.com，则 Cookie 可以发送给 www.example.com 和 blog.example.com。

Path

Path：指定 Cookie 可以发送给哪些路径。默认情况下，Cookie 只能发送给设置它的路径及其子路径。
例如，如果 Path 设置为 /blog，则 Cookie 可以发送给 /blog 和 /blog/post。

Expires 和 Max-Age

Expires：指定 Cookie 的过期时间，表示 Cookie 在客户端的存储时间。过期后，Cookie 会被删除。
Max-Age：指定 Cookie 的最大存活时间（以秒为单位）。过期后，Cookie 会被删除。
例如，Expires=Wed, 21 Oct 2025 07:28:00 GMT 表示 Cookie 在 2025 年 10 月 21 日 07:28:00 过期。

Secure

Secure：指定 Cookie 只能通过 HTTPS 协议发送。如果设置为 Secure，则 Cookie 不会通过 HTTP 协议发送。
例如，Secure; 表示 Cookie 只能通过 HTTPS 协议发送。

HttpOnly

HttpOnly：指定 Cookie 不能通过 JavaScript 访问。如果设置为 HttpOnly，则 Cookie 只能通过 HTTP 请求发送，不能通过 JavaScript 访问。
例如，HttpOnly; 表示 Cookie 不能通过 JavaScript 访问。

SameSite

SameSite：指定 Cookie 在跨站请求时的行为。有三个可选值：
- Strict：Cookie 只能发送给同站请求，不能发送给跨站请求。
- Lax：Cookie 可以发送给同站请求和部分跨站请求（如 GET 请求）。
- None：Cookie 可以发送给同站请求和跨站请求，但必须设置 Secure 属性。
例如，SameSite=Lax; 表示 Cookie 可以发送给同站请求和部分跨站请求。

设置 Cookie

服务器可以通过 HTTP 响应头（Set-Cookie）设置 Cookie。以下是一个设置 Cookie 的示例：

HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; Expires=Wed, 21 Oct 2025 07:28:00 GMT; Domain=example.com; Path=/; Secure; HttpOnly; SameSite=Lax
Content-Type: text/html

<html>
  <head>
    <title>Example</title>
  </head>
  <body>
    <h1>Hello, World!</h1>
  </body>
</html>

发送 Cookie

客户端在后续的请求中会通过 HTTP 请求头（Cookie）将 Cookie 发送回服务器。以下是一个发送 Cookie 的示例：

GET /index.html HTTP/1.1
Host: www.example.com
Cookie: session_id=abc123

Cookie 的安全性

防止 CSRF 攻击

**CSRF（跨站请求伪造）**攻击是指攻击者通过诱导用户访问恶意网站，利用用户的身份发送恶意请求。
通过设置 SameSite=Strict 或 SameSite=Lax，可以防止 CSRF 攻击。

防止 XSS 攻击

**XSS（跨站脚本）**攻击是指攻击者通过注入恶意脚本，窃取用户的 Cookie 信息。
通过设置 HttpOnly，可以防止 JavaScript 访问 Cookie，从而防止 XSS 攻击。

防止中间人攻击

中间人攻击是指攻击者通过拦截网络通信，窃取用户的 Cookie 信息。
通过设置 Secure，可以确保 Cookie 只能通过 HTTPS 协议发送，从而防止中间人攻击。

Cookie 是一种在客户端和服务器之间传递的小型文本数据，通常用于存储用户会话信息、用户偏好设置、购物车内容等。Cookie 可以通过多个属性来控制其行为和生命周期，如 Domain、Path、Expires、Max-Age、Secure、HttpOnly 和 SameSite。服务器可以通过 HTTP 响应头（Set-Cookie）设置 Cookie，客户端在后续的请求中通过 HTTP 请求头（Cookie）将 Cookie 发送回服务器。通过合理使用 Cookie，可以实现各种网络应用的功能需求，同时确保安全性。

HTTPS概述

HTTPS（HyperText Transfer Protocol Secure）是 HTTP 的安全版本，使用 SSL/TLS 协议对数据进行加密和认证，确保数据在传输过程中的安全性和完整性。HTTPS 通过加密通信内容，防止数据被窃听和篡改，同时通过数字证书对服务器进行认证，确保客户端连接到的是合法的服务器。

HTTPS 的工作原理

1. 加密通信

HTTPS 使用 SSL/TLS 协议对数据进行加密，确保数据在传输过程中不会被窃听和篡改。SSL/TLS 协议使用对称加密和非对称加密相结合的方式，对数据进行加密和解密。

对称加密：使用相同的密钥对数据进行加密和解密。对称加密速度快，但密钥传输存在安全风险。
非对称加密：使用公钥和私钥对数据进行加密和解密。公钥可以公开，私钥必须保密。非对称加密安全性高，但速度较慢。

2. 数字证书

HTTPS 使用数字证书对服务器进行认证，确保客户端连接到的是合法的服务器。数字证书由受信任的第三方机构（CA，Certificate Authority）签发，包含服务器的公钥、服务器信息和 CA 的签名。

公钥：用于加密数据，客户端使用服务器的公钥对数据进行加密。
私钥：用于解密数据，服务器使用自己的私钥对数据进行解密。
CA 签名：用于验证数字证书的真实性，客户端使用 CA 的公钥验证证书的签名。

3. 握手过程

HTTPS 的握手过程包括以下几个步骤：

客户端发送 ClientHello：客户端向服务器发送 ClientHello 消息，包含支持的 SSL/TLS 版本、加密算法列表和随机数。
服务器发送 ServerHello：服务器选择 SSL/TLS 版本和加密算法，并生成随机数，发送 ServerHello 消息。
服务器发送证书：服务器将自己的数字证书发送给客户端，包含服务器的公钥和 CA 的签名。
客户端验证证书：客户端使用 CA 的公钥验证证书的签名，确保证书的真实性。
客户端生成 Pre-Master Secret：客户端生成 Pre-Master Secret，并使用服务器的公钥进行加密，发送给服务器。
服务器解密 Pre-Master Secret：服务器使用自己的私钥解密 Pre-Master Secret。
客户端和服务器生成 Master Secret：客户端和服务器使用 Pre-Master Secret 和之前的随机数，生成 Master Secret。
客户端和服务器生成会话密钥：客户端和服务器使用 Master Secret 生成会话密钥，用于对称加密通信内容。
客户端发送 Finished：客户端发送 Finished 消息，使用会话密钥加密，表示握手过程完成。
服务器发送 Finished：服务器发送 Finished 消息，使用会话密钥加密，表示握手过程完成。

HTTPS 的优点

1. 数据加密

HTTPS 使用 SSL/TLS 协议对数据进行加密，确保数据在传输过程中不会被窃听和篡改。

2. 服务器认证

HTTPS 使用数字证书对服务器进行认证，确保客户端连接到的是合法的服务器。

3. 数据完整性

HTTPS 使用消息认证码（MAC）确保数据在传输过程中不会被篡改。

HTTPS 的缺点

1. 性能开销

HTTPS 的握手过程和加密解密操作会引入一定的性能开销，尤其是在低带宽和高延迟的网络环境中。

2. 部署成本

HTTPS 需要购买和配置数字证书，部署和维护 HTTPS 服务器的成本较高。

例子

1. 使用 HTTPS 访问网站

客户端请求：

GET /index.html HTTP/1.1
Host: www.example.com

服务器响应：

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
<html>
  <head>
    <title>Example</title>
  </head>
  <body>
    <h1>Hello, World!</h1>
  </body>
</html>

在这个例子中，客户端使用 HTTPS 协议访问 www.example.com 网站，服务器返回一个 HTML 文件。HTTPS 协议确保数据在传输过程中被加密，防止数据被窃听和篡改。

2. 使用数字证书认证服务器

服务器证书：

{
  "subject": {
    "commonName": "www.example.com",
    "organization": "Example Inc.",
    "country": "US"
  },
  "issuer": {
    "commonName": "DigiCert SHA2 Secure Server CA",
    "organization": "DigiCert Inc.",
    "country": "US"
  },
  "publicKey": "-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----",
  "signature": "..."
}

在这个例子中，服务器使用数字证书对自身进行认证。数字证书包含服务器的公钥、服务器信息和 CA 的签名。客户端使用 CA 的公钥验证证书的签名，确保证书的真实性。

HTTP协议应用场景分析 —— 以今日头条为例

静态资源

第一次进入页面：

刷新一次后：此时，状态码200一定发起了请求（指 client请求—server响应的完整过程）吗？（来自磁盘缓存）=》这次的请求是从本地缓存拿到的观察缓存策略： Cache-Control: max-age=2592000

强缓存
Cache-Control: 一月别的信息：
Access-Control-Allow-Origin: * => 允许所有域名访问
Content-Type: text/css => 资源类型： css

静态资源在部署上有没有什么方案呢？为了性能优化/用户体验优化，即：让用户更快地看到页面和做一些可交互的行为。而影响到这些的可能是，整个页面里的静态资源的访问速度。那我们提高静态资源的访问速度也一定程度上加强了用户体验。

静态资源方案：缓存 + CDN + 文件名hash

CDN：Content Delivery NetWork，内容分发网络
通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务。

除了保证用户拿到的资源更快，我们还要保证用户拿到文件更新！所以一般我们在文件名上做一些手脚，在我们这里就是文件名哈希。可以看到上述图片中的文件名的中间：index.7f8dc804.css 。

业务场景
- 表单登录
- 扫码登录
技术方式
- SSO
账号密码登录
打开控制台 - network - 勾选 preserve log - 过滤quick_login 观察请求，这两个有什么区别呢？最大的区别：Method不同第一个请求： 发起的是：OPTIONS请求，为什么呢？
跨域， cross-origin 什么是跨域？ 一个域名由：scheme+host name+port 组成，只要是不同的话，我们都认为是跨域。一般来说， *- https 默认使用端口号 443
- http 默认使用端口号 80* 跨域
CORS(Cross-Origin Resource Sharing)
预请求：获知服务端是否允许该跨域资源请求（复杂请求）
- 简单请求
- 复杂请求：只有在复杂请求才会发起跨域请求，生产生活场景中大部分都是复杂请求
相关协议头
- Access-Control-Allow-Origin
- Access-Control-Allow-Origin
- Access-Control-Expose-Headers
- Access-Control-Max-Age
- Access-Control-Allow-Credentials
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
- Access-Control-Request-Method
- Access-Control-Request-Headers
- Origin

跨域解决方案

CORS
代理服务器
- 同源策略是浏览器的安全策略，不是HTTP
Iframe通信
- 限制较多，诸多不便

想什么地址做了什么动作？

使用POST方法
目标域名：https://sso.toutiao.com
目标：quick_login/v2/

携带了那些信息？返回了哪些信息？

携带：
Post body，数据格式为form
希望获取的数据格式为json
已有的cookie
返回信息
数据格式json
set-cookie信息

刷新一下页面或下次进入页面问什么能够记住登陆状态呢？

鉴权

Session + cookie
JWT(JSON web token) 各自的优劣，和应用场景

点击右上角发文章，跳转后的网站为什么自动登录？

SSO：单点登录（Single Sign On）

HTTP协议实战分析

在实际开发中，HTTP协议的应用非常广泛，涵盖了从浏览器到服务器的各个层面。以下是详细的实战分析，包括浏览器中的AJAX请求（XHR和Fetch）、Node.js中的HTTP/HTTPS标准库和常用请求库（axios），以及如何通过网络优化和稳定性提升用户体验。

浏览器

AJAX之XHR

XMLHttpRequest（XHR）是浏览器中最早用于进行AJAX请求的技术。虽然现在有更现代的Fetch API，但XHR仍然在一些旧项目中使用。

readyState

编号	状态	含义
0	UNSENT	代理被创建，但尚未调用open()方法
1	OPENED	open()方法已经被调用
2	HEADERS_RECEIVED	send()方法已经被调用，并且头部和状态已经可获得
3	LOADNING	下载中；responseText属性已经包含部分数据
4	DONE	下载操作已完成

封装XHR请求方法

function ajax(options) {
    // 默认配置
    const defaults = {
        method: 'GET', // 默认请求方法为GET
        url: '', // 请求的URL
        async: true, // 默认异步请求
        data: null, // 请求数据
        headers: {}, // 请求头
        success: function() {}, // 请求成功回调
        error: function() {} // 请求失败回调
    };

    // 合并用户配置和默认配置
    const settings = Object.assign({}, defaults, options);

    // 创建XMLHttpRequest对象
    const xhr = new XMLHttpRequest();

    // 配置请求
    xhr.open(settings.method, settings.url, settings.async);

    // 设置请求头
    for (let header in settings.headers) {
        xhr.setRequestHeader(header, settings.headers[header]);
    }

    // 设置回调函数
    xhr.onreadystatechange = function() {
        if (xhr.readyState === 4) {
            if (xhr.status === 200) {
                // 请求成功，调用success回调
                settings.success(xhr.responseText);
            } else {
                // 请求失败，调用error回调
                settings.error(xhr.statusText);
            }
        }
    };

    // 发送请求
    xhr.send(settings.data);
}

// 使用示例
ajax({
    url: 'https://api.example.com/data',
    success: function(response) {
        console.log('GET请求成功:', response);
    },
    error: function(error) {
        console.error('GET请求失败:', error);
    }
});

AJAX之Fetch

Fetch API是现代浏览器中用于进行网络请求的一种更简洁、更强大的方式。它基于Promise，提供了更直观和灵活的API。

XML的升级版
使用Promise
模块化设计，Response，Request，Header对象
通过数据流处理对象，支持分块读取

封装Fetch请求方法

function fetchRequest(url, options = {}) {
    // 默认配置
    const defaults = {
        method: 'GET', // 默认请求方法为GET
        headers: {
            'Content-Type': 'application/json' // 默认请求头
        },
        credentials: 'same-origin' // 默认凭据模式
    };

    // 合并用户配置和默认配置
    const settings = Object.assign({}, defaults, options);

    // 发送请求
    return fetch(url, settings)
        .then(response => {
            if (!response.ok) {
                throw new Error(`HTTP error! status: ${response.status}`);
            }
            return response.json(); // 将响应解析为JSON
        })
        .catch(error => {
            console.error('Fetch error:', error);
            throw error;
        });
}

// 使用示例
fetchRequest('https://api.example.com/data')
    .then(data => console.log('GET请求成功:', data))
    .catch(error => console.error('GET请求失败:', error));

Node.js

标准库：HTTP/HTTPS

Node.js提供了内置的http和https模块，用于创建HTTP和HTTPS服务器以及发送HTTP请求。

默认模块，无需安装其他依赖
功能有限/不是十分友好

使用HTTP模块发送请求

const http = require('http');

function httpRequest(options, data) {
    return new Promise((resolve, reject) => {
        const req = http.request(options, (res) => {
            let responseData = '';

            res.on('data', (chunk) => {
                responseData += chunk;
            });

            res.on('end', () => {
                resolve(responseData);
            });
        });

        req.on('error', (error) => {
            reject(error);
        });

        if (data) {
            req.write(data);
        }

        req.end();
    });
}

// 使用示例
const options = {
    hostname: 'api.example.com',
    port: 80,
    path: '/data',
    method: 'GET'
};

httpRequest(options)
    .then(data => console.log('GET请求成功:', data))
    .catch(error => console.error('GET请求失败:', error));

常用请求库：axios

axios是一个基于Promise的HTTP客户端，适用于浏览器和Node.js。它提供了更简洁的API，并且支持拦截器、取消请求等功能。

支持浏览器，nodejs环境
丰富的拦截器

安装axios

npm install axios

使用axios发送请求

const axios = require('axios');

function axiosRequest(url, options = {}) {
    return axios({
        url,
        ...options
    })
        .then(response => response.data)
        .catch(error => {
            console.error('Axios error:', error);
            throw error;
        });
}

// 使用示例
axiosRequest('https://api.example.com/data')
    .then(data => console.log('GET请求成功:', data))
    .catch(error => console.error('GET请求失败:', error));

用户体验

网络优化

网络优化是提升用户体验的关键。以下是一些常见的网络优化策略：

压缩资源：使用Gzip或Brotli压缩静态资源（如HTML、CSS、JavaScript），减少传输数据量。
缓存策略：通过设置HTTP响应头（如Cache-Control、Expires），利用浏览器缓存减少重复请求。
CDN加速：使用内容分发网络（CDN）将静态资源分发到全球多个节点，减少延迟和提高加载速度。
减少HTTP请求：合并CSS和JavaScript文件，减少页面加载时的HTTP请求数量。
使用HTTP/2：HTTP/2支持多路复用、头部压缩等特性，可以显著提升页面加载速度。

稳定性

稳定性是确保应用可靠运行的关键。以下是一些提升稳定性的策略：

错误处理：在请求失败时，提供友好的错误提示，并记录错误日志以便后续分析。
超时设置：为请求设置合理的超时时间，避免长时间等待导致用户体验下降。
重试机制：在请求失败时，自动重试请求，提高请求成功率。
监控和报警：使用监控工具（如Prometheus、Grafana）实时监控应用性能，并在异常时发送报警通知。

总结

通过封装XHR和Fetch请求方法，我们可以在浏览器中实现简洁、可复用的AJAX请求。在Node.js中，可以使用内置的HTTP/HTTPS模块或第三方库（如axios）进行网络请求。通过网络优化和稳定性提升，我们可以显著改善用户体验，确保应用的可靠运行。在实际开发中，可以根据需求进一步优化和扩展这些方法，以满足复杂的业务需求。

Multipliers

Tue, 27 Aug 2024 00:00:00 GMT

Cf Round 338 (Div. 2)

D. Multipliers

2 seconds / 256 megabytes

standard input / standard output

题目

Ayrat has number n, represented as it's prime factorization pi of size m, i.e. n = p1·p2·...·pm. Ayrat got secret information that that the product of all divisors of n taken modulo 1e9 + 7 is the password to the secret data base. Now he wants to calculate this value.

输入

The first line of the input contains a single integer m (1 ≤ m ≤ 200 000) — the number of primes in factorization of n.

The second line contains m primes numbers pi (2 ≤ pi ≤ 200 000).

输出

Print one integer — the product of all divisors of n modulo 1e9 + 7.

样例

输入

2 2 3

输出

36

输入

3 2 3 2

输出

1728

解释

In the first sample n = 2·3 = 6. The divisors of 6 are 1, 2, 3 and 6, their product is equal to 1·2·3·6 = 36.

In the second sample 2·3·2 = 12. The divisors of 12 are 1, 2, 3, 4, 6 and 12. 1·2·3·4·6·12 = 1728.

题解

题意

将一个数n用素数因式p[i]表示（p可能相等），大小为m.要你求出n的所有因子的乘积取模1e9+7。即：所有质数p相乘等于的n的所有因子的乘积取模1e9+7。

思路

由于限时2s、数据范围较大，所以暴力破解一定会TLE。

那么我们如何去解这道题呢？

题目为什么将所有的质因子交予我们呢？没错，我们先在知道这个数n的质因子及其个数。

这时，就需要具备质因数分解定理的知识了。

何为质因数分解定理？

质因数分解定理，也称为唯一分解定理，是数论中的一个基本定理，它说明了每一个大于1的自然数都可以唯一地分解成几个质数的乘积。这个定理的正式表述如下：

任何一个大于1的自然数N都可以唯一地表示为几个质数乘积的形式，即： $$ n = p_1^{e_1} * p_2^{e_2}*···p_k^{e_k} $$ 其中，p1,p2,···,pk是质数，而e1,e2,···,ek是正整数，这个表示称为N的质因数分解。 $$ Number\ of\ factors=(e_1+1)×(e_2+1)×(e_3+1)×...×(e_k+1) $$ 在这个基础上，我们或可知道这个数的因数个数如何求；即：通过分解这个数为质因数的乘积来计算。公式如上：这是因为每个质因数可以选择从0到其指数的任意次数来相乘，形成一个因数。因此，对于每个质因数的每个指数，都有指数加1种选择。

例如，如果一个数n的质因数分解为 n=2^2×3^1×5^1，那么它的因数个数就是：(2+1)×(1+1)×(1+1)=3×2×2=12(2+1)×(1+1)×(1+1)=3×2×2=12

所以，这个数有12个因数。

因数个数定理可以利用数学归纳法证明，本蒟蒻并不太会严格的数学证明，如有需要，还请自行查阅相关资料。

那么我们可以分析每个素因子p对于答案的贡献：

只含有p的因子有p,p^2,^p^3,……,p^e，而不含p的因子个数为sum/(e + 1)(我们不妨设总因数个数为sum)。每一个含有p的因子都会和不含p的因子组合，则每一个组合出现的次数为sum/(e + 1)，那么这个p对答案的贡献就是: $$ p^{sum/(e + 1)}p^{2[sum/(e + 1)]}·····p^{k[sum/(e + 1)]}=p^{[sum/(e + 1)](1+2+···+e)}=p^{[e*(1+e)/2][sum/(e + 1)]}=p^{[(esum)/2]} $$ (另外，我们可能会想到/2会出现问题，但我们发现，如果e[1-k]中全为偶数，那么e可被2整除；若e[1~k]中出现一个奇数，那么那个e+1可被2整除，它组成了sum。所以如果是此时关于/2就不会产生问题。)

这样，loop求出每个质数的贡献相乘并记得过程中取模即可？真的是这样吗？

记得我们的sum是啥吗？ $$ sum=(e_1+1)×(e_2+1)×(e_3+1)×...×(e_k+1) $$ 它太大了！

所以问题来了，我们如何处理“指数爆炸”呢，或者说怎么降低指数呢？

费马小定理

定理的内容是：

如果p是一个素数，那么对于任何整数a，都有 $$ a^{p-1}≡1(modp) $$ 换句话说，当p是一个素数时，a的p−1次幂除以p的余数总是1。

证明本蒟蒻就不自讨苦吃了，还请各位佬另寻它路orz。

这个定理可以被用来简化指数运算。例如，假设我们想要计算a^n模p的值，其中n是一个非常大的数，而p是一个素数。如果n不是p−1的倍数，直接计算a^n可能会非常困难。但是，如果我们能够将n表示为k*(p−1)+m，其中m<p−1，那么我们可以利用费马小定理来简化计算： $$ a^{p-1}≡a^{k*(p-1)+m}≡(a^{p-1})^k*a^m(mod p)≡a^m(mod p) $$ 所以在这里，我们可以将p的指数[e*sum)/2] MOD (p-1)。

那我们就进而考虑[e*sum)/2] MOD (p-1)该如何计算。

这个/2很影响我们边取余边除，分类讨论：

只会有两种情况：奇/偶

1）e[i~k]只要存在一个奇数，那么在求sum的过程中将第一个遇到的奇数/2再取余，其他照样即可；

2）若全为偶数，那么我们sum照算，只要将每个e/2即可。

剩下的就交给快速幂(若不知道ksm可看代码注释~~板子如下~~)了。

代码

#include <bits/stdc++.h>
using namespace std;
using ll = long long;
const int M = 2e5 + 9;
const int MOD = 1e9 + 7;
ll p[M],c_p[M]; // 分别表示质因子，质因子个数
vector<ll> v; // 存储质因子，无重复，方便后续操作
// 快读
inline int read(){
    int x = 0, f = 1; char ch = getchar();
    while(ch < '0' || ch > '9'){ if(ch == '-') f = -1; ch = getchar(); }
    while(ch >= '0' && ch <= '9'){ x = x * 10 + (ch ^ 48); ch = getchar(); }
    return x * f;
}
// 快速幂=>倍增思想
ll ksm(ll base,ll power)
{
    // base => 底
    // power => 幂
    ll res = 1;
    while(power)
    {
        if(power & 1) res = res * base % MOD; // power为奇数，
        base = base * base % MOD;
        power >>= 1; // 必然会有power变为1的时刻，此时base即为所求
        // power有两种情况：偶数时，底数平方，power整除2；
        //       奇数时，底数平方，幂整除2向下取整，还有1项在此过程中被搞没了，所以在此之前还要在原基础上乘以底数
    }
    return res;
}
int main(void)
{
 ios::sync_with_stdio(0),cin.tie(0),cout.tie(0); // 关闭同步流
    // 初始化与输入
 int m = read();
 ll sum = 1; // 因子总数
    ll ans = 1; // 答案
    bool fg = 1; // 用于判断质因子数中是否存在奇数
 for(int i = 1;i <= m;++ i)
 {
  p[i] = read();
  if(!c_p[p[i]]) v.push_back(p[i]); // 如果未出现过，push入vector中
  c_p[p[i]] ++; // 个数++
 } 
 
 for(auto &i :v) if(c_p[i] & 1) fg = 0; // 判断出现过奇数
    
 if(fg) // 如果不存在奇数，即c_p[i]都是偶数
 {
  for(auto &i :v)
        {
            sum = sum * (c_p[i] + 1) % (MOD - 1); // 求因子总数，注意一定要在修改c_p[i]前
            c_p[i] >>= 1;// 相当于整除2
        }
  for(auto &i :v) ans = ans * ksm(i,sum * c_p[i] % (MOD - 1)) % MOD;
 }
 else // 存在奇数
 {
  sum = 1;
  bool wc = 1; // 只是随便找一个奇数在算sum时整除2
  for(auto &i :v)
  {
   if(c_p[i]&1 && wc)
   {
    wc = 0;
    sum = sum * (c_p[i] + 1) / 2 % (MOD - 1);
   }
   else sum = sum * (c_p[i] + 1) % (MOD - 1);
  }
  for(auto &i :v) ans = ans * ksm(i,sum * c_p[i] % (MOD - 1)) % MOD;
 }
 cout << ans << '\n';
 return 0;
}

快速分解素因数

Fri, 21 Jun 2024 00:00:00 GMT

参考：

分解质因数

引入

给定一个正整数 $N∈N^+$，试快速找到它的一个非平凡因数 ( 除了1和数本身以外的因数 )。

朴素算法

考虑朴素算法——试除法，因数是成对分布的，$N$ 的所有因数可以被分成两块，即 $[2,\sqrt{N}]$ 和 $[\sqrt{N}+1,N]$ 。只需要把 $[2, \sqrt {N}]$) 里的数遍历一遍，再根据除法就可以找出至少两个因数了。这个方法的时间复杂度为 $O(\sqrt {N})$。

最简单的算法即从 $[2,\sqrt{N}]$ 进行遍历。

vector<int> breakdown(int N) { 
 vector<int> result; 
 for (int i = 2; i * i <= N; i++) { 
  if (N % i == 0) { 
  // 如果 i 能够整除 N，说明 i 为 N 的一个质因子。 
   while (N % i == 0) N /= i; 
   result.push_back(i); 
  } 
 } 
 if (N != 1) { 
  // 说明再经过操作之后 N 留下了一个素数 
  result.push_back(N); 
 } 
 return result; 
}

我们能够证明 result 中的所有元素均为 N 的素因数。

首先证明元素均为 $N$ 的素因数：因为当且仅当 N % i == 0 满足时，result 发生变化：$i$ 储存，说明此时 $i$ 能整除 $\frac{N}{A}$ ，说明了存在一个数 $p$ 使得 $pi = \frac{N}{A}$ ，即（其中，$A$ 为 $N$ 自身发生变化后遇到 $i$ 时所除的数。我们注意到 result 若在 $push\ i$ 之前就已经有数了，为 $R_1,R_2,...,R_n$ ，那么有 $N = \frac{N}{R_1^{q_1}·R_2^{q_2}...R_n^{q_n}}$，被除的乘积即为 $A$ ）。所以 i 为 N 的因子。

其次证明 result 中均为素数。我们假设存在一个在 result 中的合数 $K$ ，并根据算术基本定理，分解为一个素数序列 $K = K_1^{e_1}·K_2^{e_2}·...·K_n^{e_n}$ ，而因为 $K_1 < K$，所以它一定会在 $K$ 之前被遍历到，并令 while(N % k1 == 0) N /= k1，即让 N 没有了素因子 $K_1$ ，故遍历到 $K$ 时，N 和 K 已经没有了整除关系了。

值得指出的是，如果开始已经打了一个素数表的话，时间复杂度将从 $O(\sqrt{N})$ 下降到 $O(\sqrt \frac{N}{ln N})$。具体可以去了解筛法的相关知识。【埃筛欧筛】

但是，当 $N$ 是个大整数时( $\ge 10^{18}$ )，这个算法的运行时间是不优秀的。我们期望一个更优秀的算法。

这里给出一种想法，即：通过随机的方法，猜测一个数是不是 $N$ 的因数，如果运气好可以在 $O(1)$ 的时间复杂度下求解答案，但是对于的数据 $N$ 是个大整数时( $\ge 10^{18}$ )，成功猜测的概率是 $\frac{1}{10^{18}}$ , , 期望猜测的次数是 $10^{18}$ 。如果是在$[2, \sqrt {N}]$) 里进行猜测，成功率会大一些。

template <class T>
T randint(T l, T r = 0) // 生成随机数建议用<random>里的引擎和分布，而不是rand()模数，那样保证是均匀分布
{
   static mt19937 eng(time(0));
   if (l > r)
       swap(l, r);
   uniform_int_distribution<T> dis(l, r);
   return dis(eng);
}
int find_factor(int n)
{
   if (is_prime(n)) // 特判素数
       return n;
   int x, d;
   do
   {
       x = randint(2, n - 1); // 生成2和n-1之间的随机数
       d = gcd(n, x);       // 求gcd
   } while (d == 1);
   return d;
}

在最差的情况下，$n = p^2$ (p是质数)，这时 $[1,p^2-1]$ 里只有 1 个 p 是 n 的因数；然而，当 $x$ 取 $p,2p,3p,...,(p-1)p$ 时，都有 $gcd(x,n) = p > 1$ ，而公因数自然是 n 的因数。所以此时最差期望时间复杂度可以降到 $O(\sqrt{n}logn)$ (gcd的复杂度log，根号来自 $x$ 有约 $p - 1 ≈ \sqrt{n}$ 种满足条件的选择) ，当然，它连朴素的试除法都比不过。

因此，我们仍希望有方法来优化猜测。

Pollard Rho 算法

生日悖论

为了尝试优化，我们或许需要了解生日悖论。

生日悖论不算严格意义上的悖论，只是反直觉罢了。

这里给出一个简易的表述：一个房间里有23个人，则他们中有两人生日相同的概率超过一半（不考虑闰年）。关于证明：即 $\frac{365}{365} × \frac{364}{365} × \frac{363}{365} × ... \frac{365 - 22}{365} < \frac{1}{2}$。

为了破除旧的生日悖论的直觉，建立新的认识，我们尝试去解决生日悖论的提问：一个房间中至少多少人，才能使其中两个人生日相同的概率达到 $50%$ ?

解：假设一年有 n 天，房间中有 k 人，用整数 1，2，...，k 对这些人进行编码。假定每个人的生日均匀分布于 n 天之中，且两个人的生日相互独立。设 k 个人生日互不相同为事件 A，则事件 A 的概率为：$P(A) = \prod \limits_{i=0}^{k-1} \frac{n-i}{n}$ ，至少有两个人生日相同的概率为 $P(\bar{A})=1-P(A)$。根据题意得$P(\bar{A})\ge \frac{1}{2}$，那么有 $P(A)= \prod \limits_{i=0}^{k-1} \frac{n-i}{n}\le \frac{1}{2}$ 由不等式 $1+x\le e^x$ 可得：$P(A)=\prod \limits_{i=0}^{k-1}exp(-\frac{i}{n})=exp(-\frac{k(k-1)}{2n})$
因此，$exp(-\frac{k(k-1)}{2n})\le \frac{1}{2} => P(A)\le\frac{1}{2}$ 将 $n=365$ 带入得：$k\ge23$。所以一个房间中至少23人，使其中两个人生日相同的概率达到 $50%$。

而当 $k>56,n=365$ 时，出现两个人同一天生日的概率将大于一 $99%$ 。那么在一年有 $n$ 天的情况下，当房间中有 $\frac{1}{2}(\sqrt{8nln2 + 1}+1)≈\sqrt{2nln2}$个人时，至少有两个人的生日相同的概率约为 $50%$。

这时，我们可以建立这样一个直觉：如果我们不断在某个范围内生成随机整数，很快便会生成到重复的数，期望大约在根号级别。精确地说，对于一个 $[1,𝑁]$ 内整数的理想随机数生成器，生成序列中第一个重复数字前期望有 $\sqrt{\frac{π𝑁}{2}}$ 个数。证明参见知乎问答

这里我们回归到原题，对于最坏的情形 $n=p^2$，如果我们不断在 $[1,n-1]$ 间生成随机数，那么期望在生成大约 $\sqrt{p}=n^{\frac{1}{4}}$ 个数后，可以出现 $2$ 个在模 $p$ 下相同的数（注意 $[1,n-1]$间的随机数模 $p$ 大致是 $[0,p-1]$ 间的随机数）。那么这 $2$ 个数的差的绝对值 $d$，就一定满足 $d \equiv 0\ (mod\ p)$ ，也就满足 $gcd(d,n)>1$ 。

但是知晓这件事的意义并不是那么大。正如生日悖论虽然正确，但你不一定等在班上遇到和自己生日相同的人，因为这个高概率是在两两比较下才成立的。对于这 $n^{\frac{1}{4}}$ 个数两两验证，复杂度还是立刻回到 $O(\sqrt{n}logn)$，这并没有什么进步，所以我们需要一些技巧。

利用最大公约数求出一个因数 || 伪随机数序列

我们再次回顾一下这个性质：$n$ 和某个数的最大公约数一定是 $n$ 的因数，即 $\forall k ∈ N_+,gcd(k,n)|n$，只要选择恰当的 $k$ 使得 $1 <gcd(k,n)<n$，就可以求得 $n$ 的一个约数 $gcd(k,n)$。满足这样条件的 $k$ 不少， $n$ 有若干个质因子，每个质因子及其大部分倍数都是可行的。

我们通过 $f(x)=(x^2+c)\ mod\ n$ 来生成一个序列 ${x_i}$：随机取一个 $x_1$ ，令 $x_2 = f(x_1),x_3 = f(x_2),...,x_i=f(x_{i-1})$ 。其中 $c$ 是一个随机选取的常数。

举个例子，取 $n=9400,c=24,x_1=0$，$f(x)$ 生成数据为： $0,24,600,2824,3800,1624,5400,1224,3600,6824,8800,2824,3800,1624,...$

可以发现数据在 $x_4$ 以后都在 $2824,3800,1624,5400,1224,3600,6824,8800$ 之间循环。如果将这些数如上图一样排列起来，会发现这个图像酷似一个𝜌，算法也因此得名 $rho$。不难发现这是显然的，因为每个数都是由前一个数决定的，可生成的数又是有限的，那么迟早会进入循环。当然，这个循环极大可能是混循环。

而之所以选择 $f(x)=(x^2+c)\ mod\ n$ 这个函数生成序列，是因为它有一个性质： $\forall x \equiv y\ (mod\ p),\ f(y)$