bencode是一种专为bittorrent设计的二进制安全序列化格式，非json/xml，需递归下降解析；其字符串无引号、不支持浮点数，pieces为原始二进制、info字典须字典序排列且sha-1校验基于序列化后字节。
什么是Bencode，为什么不能直接用JSON库解析
Bencode不是JSON、也不是XML，它没有引号包裹字符串，不区分null/undefined，也不支持浮点数——bdecode函数遇到4:spam必须返回字节数组"spam"，而不是字符串对象。C++里若用std::string粗暴读取整个文件再正则切分，会栽在嵌套字典的边界判断上：比如d3:cow3:moo4:spam4:eggs中，第二层d和结尾e必须严格配对，靠计数器容易漏掉中间的l/d嵌套。
实操建议：
- 必须递归下降解析，每层函数只负责识别当前起始字符（
i、d、l、数字）并消费对应结构 - 不要预分配大缓冲区——种子文件里的
pieces字段是二进制SHA-1哈希串，长度固定20字节×文件块数，但可能长达几MB，应按需提取 - 用
std::string_view避免重复拷贝，尤其处理长info字典时
如何安全提取info字典并验证SHA-1校验和
info字典是种子核心，其序列化后（不含外层d和e）的原始字节必须做SHA-1，结果存入info_hash。常见错误是把整个.torrent文件当info内容算哈希，或忽略info字典内部键的字典序要求（Bencode规定d内键必须字典升序排列，否则客户端拒绝加载）。
实操建议：
- 先完整解析顶层字典，检查是否存在
"info"键且值为dict类型 - 调用
serialize_dict函数（非to_string！）将info子字典按Bencode规则重新编码为std::string，确保键排序、无多余空格 - 用OpenSSL的
EVP_Digest或libsodium的crypto_hash_sha1计算该字节流哈希，结果是20字节二进制，不是hex字符串 - 注意：某些种子含
name.utf-8键，优先于name，但解析时不需解码UTF-8，原样保留字节即可
解析pieces字段时为何得到乱码而非数组
pieces在Bencode里是20:xxxxxxxxxxxxxxxxxxxx这种形式——开头数字是总长度（20字节×块数），后面紧跟连续二进制数据，**不是字符串数组**。用std::string存储时若误判为UTF-8文本，遇到\x00就截断；用std::vector<uint8_t></uint8_t>则能保真。
实操建议：
- 解析到
pieces键时，强制走“二进制字符串”分支：跳过长度声明后的冒号，按声明长度read_raw_bytes，不经过任何编码转换 - 校验块数：用
(file_size + piece_length - 1) / piece_length算出理论块数，再验证pieces.length() == 20 * expected_pieces - 别试图用
std::string::c_str()打印pieces——它包含大量不可见控制字符，调试时用printf("%02x", (unsigned char)bytes[i])逐字节输出
libtorrent或mbedtls能否直接复用解析逻辑
libtorrent的lazy_entry可解析Bencode，但它是惰性求值：访问info字段时才真正解码，且内部用std::vector<char></char>存原始数据，修改后需手动调用write重序列化；mbedtls只提供SHA-1，不碰Bencode。硬集成会引入整套构建依赖，而纯解析只需200行以内代码。
实操建议：
- 若仅需读取种子元数据（如显示文件列表、大小），手写递归下降解析器更轻量、可控性强
- 若需构造新种子（如添加tracker），必须保证
info字典键严格字典序，libtorrent的entry类会自动排序，此时可借力 - 警惕libtorrent版本差异：
v2.0+默认启用BEP-52（v2 torrents），其meta version=2结构完全不同，老解析器直接崩溃
最易被忽略的是encoding字段：它声明整个文件的文本编码（如UTF-8），但Bencode规范未定义其作用范围，实际中多数客户端忽略它——解析时读到就存下来，别拿它去转码其他字段。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
