简介这是一份面向C网络编程学习者与Web开发历史研究者的C CGI库源码资源作者windawn。库内封装了CGI请求解析、字符串处理、MySQL数据库访问与Socket通信等模块核心类包括CGI、MySQLConnection、StringUtil与Socket可用于构建动态网页、后台管理系统等场景帮助开发者理解早期Web服务的底层实现路径。资源包共49个文件以17个cpp源文件与17个h头文件为主体另含4个makefile构建脚本及若干备份与辅助文件压缩包约43KB目录按libutils、libtcp、libcgi等模块划分结构清晰便于按需查阅。目前已有324人学习下载。通过阅读源码读者可掌握查询字符串解析、HTML拼接、数据库连接管理、Socket收发响应等具体实现思路并对照Makefile理解多模块编译组织方式适合希望深入C网络编程或探究CGI技术演进的开发者参考。1. 一个C CGI库从零手写Web接口的另一种选择如果你现在要写一个Web接口第一反应大概是上Spring Boot或者Flask。但有些场景偏偏不能这么干——比如嵌入式设备上跑一个配置页面或者给一个已经用C写好的计算引擎套一层HTTP壳子。这时候引入一整套Web框架光是依赖就能把编译时间拉长好几倍。我最近拆的这个C CGI库走的是完全不同的路子它不依赖任何Web框架直接实现CGI协议把HTTP请求解析成C里的环境变量和标准输入你只需要写一个main函数从环境变量里读参数、往标准输出里写HTML一个接口就成了。整个库的核心代码量不大编译出来就是一个可执行文件扔进cgi-bin目录就能跑。适合谁适合那些需要在C项目里快速暴露HTTP接口、又不想引入重型依赖的开发者尤其是嵌入式、边缘计算、或者老系统改造的场景。2. 核心架构拆解CGI协议怎么在C里落地2.1 请求解析从环境变量到C对象CGI协议的核心思路很朴素Web服务器比如Apache、Nginx收到HTTP请求后把请求方法、路径、查询字符串、请求头这些信息塞进环境变量然后启动一个CGI进程把请求体通过标准输入传进去。CGI进程处理完把响应头和响应体写到标准输出服务器再转发给客户端。这个库要做的第一件事就是把那些散落在environ里的环境变量收拢成一个结构体。常见做法是定义一个Request类在构造函数里遍历environ把REQUEST_METHOD、QUERY_STRING、CONTENT_LENGTH、CONTENT_TYPE这些关键字段提取出来。// request.h class Request { public: std::string method; // GET / POST std::string queryString; // URL 里的 ? 后面那串 std::string contentType; // application/x-www-form-urlencoded 或 multipart/form-data std::string body; // POST 请求体 Request() { // 从环境变量里抓请求方法 const char* m getenv(REQUEST_METHOD); method m ? m : GET; // 查询字符串GET 请求的参数都在这里 const char* qs getenv(QUERY_STRING); queryString qs ? qs : ; // 内容类型POST 请求靠它判断怎么解析 body const char* ct getenv(CONTENT_TYPE); contentType ct ? ct : ; // 读取标准输入拿到 POST 的请求体 const char* lenStr getenv(CONTENT_LENGTH); if (lenStr) { int len std::atoi(lenStr); if (len 0) { body.resize(len); std::cin.read(body[0], len); } } } };这段代码里有两个点值得注意。第一CONTENT_LENGTH必须判断是否存在因为GET请求没有请求体这个环境变量可能压根不存在。第二std::cin.read读取的是二进制数据不能用操作符否则遇到空格就断了。参数说明method决定后续走GET还是POST分支queryString是原始字符串需要进一步解析成键值对body在POST场景下才有效。2.2 参数解析查询字符串与表单数据拿到queryString和body之后下一步是解析成keyvalue的形式。GET请求的参数在queryString里格式是name张三age25POST请求如果是application/x-www-form-urlencoded格式一样只是数据在body里。解析逻辑不复杂按分割再按分割注意URL解码。URL解码要处理%XX和号号在查询字符串里代表空格。// 解析 keyvaluekey2value2 格式 std::mapstd::string, std::string parseParams(const std::string data) { std::mapstd::string, std::string params; std::stringstream ss(data); std::string pair; while (std::getline(ss, pair, )) { auto pos pair.find(); if (pos std::string::npos) continue; std::string key urlDecode(pair.substr(0, pos)); std::string value urlDecode(pair.substr(pos 1)); params[key] value; } return params; } // URL 解码%XX 转字符 转空格 std::string urlDecode(const std::string str) { std::string result; for (size_t i 0; i str.size(); i) { if (str[i] ) { result ; } else if (str[i] % i 2 str.size()) { int hex; std::stringstream ss; ss std::hex str.substr(i 1, 2); ss hex; result static_castchar(hex); i 2; } else { result str[i]; } } return result; }这里有个容易翻车的地方%后面必须跟两个十六进制字符如果请求里出现单独的%substr会越界。我一般会在解码前先检查i 2 str.size()不满足就原样输出。另外std::map会自动按key排序如果业务对参数顺序有要求得换成std::vectorstd::pair...。2.3 响应构造从标准输出到HTTP响应CGI进程的输出必须遵循固定格式先输出Content-Type头再输出一个空行然后是响应体。这个库通常会封装一个Response类提供setHeader、write、redirect这些方法最后在析构或者显式调用flush的时候统一输出。// response.h class Response { public: void setHeader(const std::string key, const std::string value) { headers[key] value; } void write(const std::string content) { body content; } void redirect(const std::string url) { setHeader(Location, url); statusCode 302; } void flush() { // 状态行CGI 里通常写 Status: 200 OK if (statusCode ! 200) { std::cout Status: statusCode OK\r\n; } // 默认 Content-Type if (headers.find(Content-Type) headers.end()) { headers[Content-Type] text/html; charsetutf-8; } for (auto kv : headers) { std::cout kv.first : kv.second \r\n; } std::cout \r\n; // 空行分隔头和体 std::cout body; } private: std::mapstd::string, std::string headers; std::string body; int statusCode 200; };注意\r\n不能写成\n有些Web服务器对换行符敏感用\n可能导致响应头解析失败。另外Status头只在非200的时候需要显式写200是默认值。Content-Type如果不设置浏览器可能把HTML当纯文本渲染中文还会乱码所以默认给text/html; charsetutf-8比较稳妥。3. 编译与部署让CGI程序在服务器上跑起来3.1 编译参数与依赖管理这个库本身没有第三方依赖只需要C标准库。编译命令很直接g -stdc11 -O2 -o hello.cgi hello.cpp request.cpp response.cpp-stdc11是底线因为用到了std::map的初始化列表和auto。-O2优化在嵌入式场景下建议加上CGI进程每次请求都要启动一次启动速度直接影响响应时间。如果目标机器是ARM架构交叉编译的时候记得加-static避免动态库缺失导致CGI进程启动失败。常见做法是把编译产物直接放到Web服务器的cgi-bin目录下。以Nginx为例需要配置fastcgi_pass或者用fcgiwrap来转发CGI请求。Apache的话ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/这一行就够了。3.2 一个完整的Hello World示例把前面的Request和Response串起来一个最小的CGI程序长这样// hello.cpp #include request.h #include response.h int main() { Request req; Response res; // 解析 GET 参数 auto params parseParams(req.queryString); res.write(htmlbody); res.write(h1Hello, CGI!/h1); if (params.count(name)) { res.write(p你好, params[name] /p); } else { res.write(p请传入 name 参数/p); } res.write(/body/html); res.flush(); return 0; }编译后放到cgi-bin目录访问http://your-server/cgi-bin/hello.cgi?name张三就能看到页面输出。这个例子虽然简单但已经覆盖了CGI的核心链路环境变量读取、参数解析、响应输出。3.3 调试技巧日志往哪写CGI程序的标准输出被Web服务器拿走了所以std::cout不能用来打日志。调试信息只能往标准错误写或者写文件。// 调试日志写到 stderrWeb 服务器通常会记录到 error_log std::cerr [DEBUG] method req.method query req.queryString std::endl;如果服务器配置了error_log这些信息会出现在日志里。另一个办法是写临时文件但要注意权限问题——CGI进程通常以www-data或nobody用户运行写/tmp一般没问题写其他目录可能被拒。4. 避坑与常见问题排查4.1 中文乱码Content-Type 和 URL 编码的双重坑现象页面上的中文显示成乱码或者参数里的中文变成%E5%BC%A0%E4%B8%89。原因两个地方可能出问题。一是Content-Type没指定charsetutf-8浏览器按默认编码解析二是URL编码没解码参数值还是原始百分号形式。解决响应头里强制写Content-Type: text/html; charsetutf-8参数解析时走一遍urlDecode。如果用的是std::cout输出中文确保源文件保存为UTF-8编译时不需要额外加-finput-charset但有些老编译器默认GBK那就得显式指定。4.2 POST 请求体读不全CONTENT_LENGTH 的陷阱现象POST请求提交的表单数据只读到一半或者干脆是空的。原因CONTENT_LENGTH环境变量在某些服务器配置下可能不存在或者值不对。另外std::cin默认是文本模式遇到\r\n会转换读二进制数据要用std::cin.read。解决先判断CONTENT_LENGTH是否存在不存在就按0处理。读取的时候用read而不是getline。如果数据量特别大比如文件上传要考虑分块读取避免一次性分配太大内存。4.3 CGI 进程启动失败权限与路径问题现象浏览器返回500错误服务器日志显示Permission denied或No such file or directory。原因CGI文件没有执行权限或者路径配置不对。Web服务器通常以低权限用户运行如果CGI文件在用户主目录下可能没有执行权限。解决chmod x hello.cgi给执行权限。路径方面Apache的ScriptAlias和Nginx的fastcgi_param SCRIPT_FILENAME都要指向正确的绝对路径。另外SELinux开启的情况下CGI文件需要打上httpd_sys_script_exec_t标签这个坑在CentOS上特别常见。4.4 并发性能CGI 的天然短板现象并发请求一多响应时间直线上升CPU占用飙升。原因CGI是“一个请求一个进程”的模型每个请求都要fork一个新进程进程创建和销毁的开销在高并发下非常明显。解决如果并发量确实大可以考虑FastCGI——它让进程常驻避免反复fork。但这个库本身是CGI实现要上FastCGI得换一套接口。另一个思路是在前面加一层Nginx缓存把不常变的页面缓存住减少CGI进程启动次数。我一般会在压测阶段用ab或wrk跑一下看看QPS能不能接受不能接受就得上FastCGI或者换方案。5. 二次开发从能跑到好用的改造思路这个库的代码量不大正好适合拿来练手或者按自己的需求改造。我一般会从三个方向下手。第一个方向是路由系统。原生的CGI程序靠文件名区分接口hello.cgi、user.cgi、login.cgi各是一个可执行文件。接口一多编译产物就散得到处都是。改造思路是只保留一个入口index.cgi在里面根据PATH_INFO或者QUERY_STRING里的action参数做路由分发。比如/cgi-bin/index.cgi?actionuser.list在main函数里解析action然后调用对应的处理函数。这样编译产物只有一个部署和升级都方便。// 简易路由分发 std::string action params[action]; if (action user.list) { handleUserList(req, res); } else if (action user.detail) { handleUserDetail(req, res); } else { res.setHeader(Status, 404 Not Found); res.write(h1404/h1); }第二个方向是模板渲染。直接在C代码里拼HTML字符串短页面还行页面一复杂就变成字符串地狱。常见做法是引入一个轻量级模板引擎比如inja或者自己写一个简单的占位符替换。模板文件放在templates/目录下运行时读取、替换变量、输出。这样前端和后端能稍微解耦一点改样式不用重新编译C。第三个方向是JSON接口支持。现在很多场景不需要返回HTML而是返回JSON给前端框架用。改造起来很简单把Content-Type设成application/json然后手写一个极简的JSON序列化函数把std::map转成JSON字符串。注意转义双引号和反斜杠中文不需要转义成\uXXXX直接输出UTF-8就行。std::string toJson(const std::mapstd::string, std::string data) { std::string json {; bool first true; for (auto kv : data) { if (!first) json ,; json \ escapeJson(kv.first) \:\ escapeJson(kv.second) \; first false; } json }; return json; }验证改造效果的方法也很直接写一个test.cgi用curl发请求看返回的JSON能不能被jq解析。curl -s http://localhost/cgi-bin/index.cgi?actionuser.list | jq .如果能正常格式化输出说明JSON结构没问题。从那以后我每次改完CGI程序都强制走一遍“curl测接口 → 浏览器看页面 → 看error_log”这三步少一步都可能漏掉编码或者权限的坑。希望帮到你。本文还有配套的精品资源点击获取
