簡介這是一份面向C網(wǎng)絡(luò)編程學(xué)習(xí)者與Web開發(fā)歷史研究者的C CGI庫源碼資源作者windawn。庫內(nèi)封裝了CGI請(qǐng)求解析、字符串處理、MySQL數(shù)據(jù)庫訪問與Socket通信等模塊核心類包括CGI、MySQLConnection、StringUtil與Socket可用于構(gòu)建動(dòng)態(tài)網(wǎng)頁、后臺(tái)管理系統(tǒng)等場景幫助開發(fā)者理解早期Web服務(wù)的底層實(shí)現(xiàn)路徑。資源包共49個(gè)文件以17個(gè)cpp源文件與17個(gè)h頭文件為主體另含4個(gè)makefile構(gòu)建腳本及若干備份與輔助文件壓縮包約43KB目錄按libutils、libtcp、libcgi等模塊劃分結(jié)構(gòu)清晰便于按需查閱。目前已有324人學(xué)習(xí)下載。通過閱讀源碼讀者可掌握查詢字符串解析、HTML拼接、數(shù)據(jù)庫連接管理、Socket收發(fā)響應(yīng)等具體實(shí)現(xiàn)思路并對(duì)照Makefile理解多模塊編譯組織方式適合希望深入C網(wǎng)絡(luò)編程或探究CGI技術(shù)演進(jìn)的開發(fā)者參考。1. 一個(gè)C CGI庫從零手寫Web接口的另一種選擇如果你現(xiàn)在要寫一個(gè)Web接口第一反應(yīng)大概是上Spring Boot或者Flask。但有些場景偏偏不能這么干——比如嵌入式設(shè)備上跑一個(gè)配置頁面或者給一個(gè)已經(jīng)用C寫好的計(jì)算引擎套一層HTTP殼子。這時(shí)候引入一整套Web框架光是依賴就能把編譯時(shí)間拉長好幾倍。我最近拆的這個(gè)C CGI庫走的是完全不同的路子它不依賴任何Web框架直接實(shí)現(xiàn)CGI協(xié)議把HTTP請(qǐng)求解析成C里的環(huán)境變量和標(biāo)準(zhǔn)輸入你只需要寫一個(gè)main函數(shù)從環(huán)境變量里讀參數(shù)、往標(biāo)準(zhǔn)輸出里寫HTML一個(gè)接口就成了。整個(gè)庫的核心代碼量不大編譯出來就是一個(gè)可執(zhí)行文件扔進(jìn)cgi-bin目錄就能跑。適合誰適合那些需要在C項(xiàng)目里快速暴露HTTP接口、又不想引入重型依賴的開發(fā)者尤其是嵌入式、邊緣計(jì)算、或者老系統(tǒng)改造的場景。2. 核心架構(gòu)拆解CGI協(xié)議怎么在C里落地2.1 請(qǐng)求解析從環(huán)境變量到C對(duì)象CGI協(xié)議的核心思路很樸素Web服務(wù)器比如Apache、Nginx收到HTTP請(qǐng)求后把請(qǐng)求方法、路徑、查詢字符串、請(qǐng)求頭這些信息塞進(jìn)環(huán)境變量然后啟動(dòng)一個(gè)CGI進(jìn)程把請(qǐng)求體通過標(biāo)準(zhǔn)輸入傳進(jìn)去。CGI進(jìn)程處理完把響應(yīng)頭和響應(yīng)體寫到標(biāo)準(zhǔn)輸出服務(wù)器再轉(zhuǎn)發(fā)給客戶端。這個(gè)庫要做的第一件事就是把那些散落在environ里的環(huán)境變量收攏成一個(gè)結(jié)構(gòu)體。常見做法是定義一個(gè)Request類在構(gòu)造函數(shù)里遍歷environ把REQUEST_METHOD、QUERY_STRING、CONTENT_LENGTH、CONTENT_TYPE這些關(guān)鍵字段提取出來。// 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 請(qǐng)求體 Request() { // 從環(huán)境變量里抓請(qǐng)求方法 const char* m getenv(REQUEST_METHOD); method m ? m : GET; // 查詢字符串GET 請(qǐng)求的參數(shù)都在這里 const char* qs getenv(QUERY_STRING); queryString qs ? qs : ; // 內(nèi)容類型POST 請(qǐng)求靠它判斷怎么解析 body const char* ct getenv(CONTENT_TYPE); contentType ct ? ct : ; // 讀取標(biāo)準(zhǔn)輸入拿到 POST 的請(qǐng)求體 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); } } } };這段代碼里有兩個(gè)點(diǎn)值得注意。第一CONTENT_LENGTH必須判斷是否存在因?yàn)镚ET請(qǐng)求沒有請(qǐng)求體這個(gè)環(huán)境變量可能壓根不存在。第二std::cin.read讀取的是二進(jìn)制數(shù)據(jù)不能用操作符否則遇到空格就斷了。參數(shù)說明method決定后續(xù)走GET還是POST分支queryString是原始字符串需要進(jìn)一步解析成鍵值對(duì)body在POST場景下才有效。2.2 參數(shù)解析查詢字符串與表單數(shù)據(jù)拿到queryString和body之后下一步是解析成keyvalue的形式。GET請(qǐng)求的參數(shù)在queryString里格式是name張三age25POST請(qǐng)求如果是application/x-www-form-urlencoded格式一樣只是數(shù)據(jù)在body里。解析邏輯不復(fù)雜按分割再按分割注意URL解碼。URL解碼要處理%XX和號(hào)號(hào)在查詢字符串里代表空格。// 解析 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 轉(zhuǎn)字符 轉(zhuǎn)空格 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; }這里有個(gè)容易翻車的地方%后面必須跟兩個(gè)十六進(jìn)制字符如果請(qǐng)求里出現(xiàn)單獨(dú)的%substr會(huì)越界。我一般會(huì)在解碼前先檢查i 2 str.size()不滿足就原樣輸出。另外std::map會(huì)自動(dòng)按key排序如果業(yè)務(wù)對(duì)參數(shù)順序有要求得換成std::vectorstd::pair...。2.3 響應(yīng)構(gòu)造從標(biāo)準(zhǔn)輸出到HTTP響應(yīng)CGI進(jìn)程的輸出必須遵循固定格式先輸出Content-Type頭再輸出一個(gè)空行然后是響應(yīng)體。這個(gè)庫通常會(huì)封裝一個(gè)Response類提供setHeader、write、redirect這些方法最后在析構(gòu)或者顯式調(diào)用flush的時(shí)候統(tǒng)一輸出。// 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() { // 狀態(tài)行CGI 里通常寫 Status: 200 OK if (statusCode ! 200) { std::cout Status: statusCode OK\r\n; } // 默認(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服務(wù)器對(duì)換行符敏感用\n可能導(dǎo)致響應(yīng)頭解析失敗。另外Status頭只在非200的時(shí)候需要顯式寫200是默認(rèn)值。Content-Type如果不設(shè)置瀏覽器可能把HTML當(dāng)純文本渲染中文還會(huì)亂碼所以默認(rèn)給text/html; charsetutf-8比較穩(wěn)妥。3. 編譯與部署讓CGI程序在服務(wù)器上跑起來3.1 編譯參數(shù)與依賴管理這個(gè)庫本身沒有第三方依賴只需要C標(biāo)準(zhǔn)庫。編譯命令很直接g -stdc11 -O2 -o hello.cgi hello.cpp request.cpp response.cpp-stdc11是底線因?yàn)橛玫搅藄td::map的初始化列表和auto。-O2優(yōu)化在嵌入式場景下建議加上CGI進(jìn)程每次請(qǐng)求都要啟動(dòng)一次啟動(dòng)速度直接影響響應(yīng)時(shí)間。如果目標(biāo)機(jī)器是ARM架構(gòu)交叉編譯的時(shí)候記得加-static避免動(dòng)態(tài)庫缺失導(dǎo)致CGI進(jìn)程啟動(dòng)失敗。常見做法是把編譯產(chǎn)物直接放到Web服務(wù)器的cgi-bin目錄下。以Nginx為例需要配置fastcgi_pass或者用fcgiwrap來轉(zhuǎn)發(fā)CGI請(qǐng)求。Apache的話ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/這一行就夠了。3.2 一個(gè)完整的Hello World示例把前面的Request和Response串起來一個(gè)最小的CGI程序長這樣// hello.cpp #include request.h #include response.h int main() { Request req; Response res; // 解析 GET 參數(shù) 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請(qǐng)傳入 name 參數(shù)/p); } res.write(/body/html); res.flush(); return 0; }編譯后放到cgi-bin目錄訪問http://your-server/cgi-bin/hello.cgi?name張三就能看到頁面輸出。這個(gè)例子雖然簡單但已經(jīng)覆蓋了CGI的核心鏈路環(huán)境變量讀取、參數(shù)解析、響應(yīng)輸出。3.3 調(diào)試技巧日志往哪寫CGI程序的標(biāo)準(zhǔn)輸出被Web服務(wù)器拿走了所以std::cout不能用來打日志。調(diào)試信息只能往標(biāo)準(zhǔn)錯(cuò)誤寫或者寫文件。// 調(diào)試日志寫到 stderrWeb 服務(wù)器通常會(huì)記錄到 error_log std::cerr [DEBUG] method req.method query req.queryString std::endl;如果服務(wù)器配置了error_log這些信息會(huì)出現(xiàn)在日志里。另一個(gè)辦法是寫臨時(shí)文件但要注意權(quán)限問題——CGI進(jìn)程通常以www-data或nobody用戶運(yùn)行寫/tmp一般沒問題寫其他目錄可能被拒。4. 避坑與常見問題排查4.1 中文亂碼Content-Type 和 URL 編碼的雙重坑現(xiàn)象頁面上的中文顯示成亂碼或者參數(shù)里的中文變成%E5%BC%A0%E4%B8%89。原因兩個(gè)地方可能出問題。一是Content-Type沒指定charsetutf-8瀏覽器按默認(rèn)編碼解析二是URL編碼沒解碼參數(shù)值還是原始百分號(hào)形式。解決響應(yīng)頭里強(qiáng)制寫Content-Type: text/html; charsetutf-8參數(shù)解析時(shí)走一遍urlDecode。如果用的是std::cout輸出中文確保源文件保存為UTF-8編譯時(shí)不需要額外加-finput-charset但有些老編譯器默認(rèn)GBK那就得顯式指定。4.2 POST 請(qǐng)求體讀不全CONTENT_LENGTH 的陷阱現(xiàn)象POST請(qǐng)求提交的表單數(shù)據(jù)只讀到一半或者干脆是空的。原因CONTENT_LENGTH環(huán)境變量在某些服務(wù)器配置下可能不存在或者值不對(duì)。另外std::cin默認(rèn)是文本模式遇到\r\n會(huì)轉(zhuǎn)換讀二進(jìn)制數(shù)據(jù)要用std::cin.read。解決先判斷CONTENT_LENGTH是否存在不存在就按0處理。讀取的時(shí)候用read而不是getline。如果數(shù)據(jù)量特別大比如文件上傳要考慮分塊讀取避免一次性分配太大內(nèi)存。4.3 CGI 進(jìn)程啟動(dòng)失敗權(quán)限與路徑問題現(xiàn)象瀏覽器返回500錯(cuò)誤服務(wù)器日志顯示Permission denied或No such file or directory。原因CGI文件沒有執(zhí)行權(quán)限或者路徑配置不對(duì)。Web服務(wù)器通常以低權(quán)限用戶運(yùn)行如果CGI文件在用戶主目錄下可能沒有執(zhí)行權(quán)限。解決chmod x hello.cgi給執(zhí)行權(quán)限。路徑方面Apache的ScriptAlias和Nginx的fastcgi_param SCRIPT_FILENAME都要指向正確的絕對(duì)路徑。另外SELinux開啟的情況下CGI文件需要打上httpd_sys_script_exec_t標(biāo)簽這個(gè)坑在CentOS上特別常見。4.4 并發(fā)性能CGI 的天然短板現(xiàn)象并發(fā)請(qǐng)求一多響應(yīng)時(shí)間直線上升CPU占用飆升。原因CGI是“一個(gè)請(qǐng)求一個(gè)進(jìn)程”的模型每個(gè)請(qǐng)求都要fork一個(gè)新進(jìn)程進(jìn)程創(chuàng)建和銷毀的開銷在高并發(fā)下非常明顯。解決如果并發(fā)量確實(shí)大可以考慮FastCGI——它讓進(jìn)程常駐避免反復(fù)fork。但這個(gè)庫本身是CGI實(shí)現(xiàn)要上FastCGI得換一套接口。另一個(gè)思路是在前面加一層Nginx緩存把不常變的頁面緩存住減少CGI進(jìn)程啟動(dòng)次數(shù)。我一般會(huì)在壓測階段用ab或wrk跑一下看看QPS能不能接受不能接受就得上FastCGI或者換方案。5. 二次開發(fā)從能跑到好用的改造思路這個(gè)庫的代碼量不大正好適合拿來練手或者按自己的需求改造。我一般會(huì)從三個(gè)方向下手。第一個(gè)方向是路由系統(tǒng)。原生的CGI程序靠文件名區(qū)分接口hello.cgi、user.cgi、login.cgi各是一個(gè)可執(zhí)行文件。接口一多編譯產(chǎn)物就散得到處都是。改造思路是只保留一個(gè)入口index.cgi在里面根據(jù)PATH_INFO或者QUERY_STRING里的action參數(shù)做路由分發(fā)。比如/cgi-bin/index.cgi?actionuser.list在main函數(shù)里解析action然后調(diào)用對(duì)應(yīng)的處理函數(shù)。這樣編譯產(chǎn)物只有一個(gè)部署和升級(jí)都方便。// 簡易路由分發(fā) 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); }第二個(gè)方向是模板渲染。直接在C代碼里拼HTML字符串短頁面還行頁面一復(fù)雜就變成字符串地獄。常見做法是引入一個(gè)輕量級(jí)模板引擎比如inja或者自己寫一個(gè)簡單的占位符替換。模板文件放在templates/目錄下運(yùn)行時(shí)讀取、替換變量、輸出。這樣前端和后端能稍微解耦一點(diǎn)改樣式不用重新編譯C。第三個(gè)方向是JSON接口支持?，F(xiàn)在很多場景不需要返回HTML而是返回JSON給前端框架用。改造起來很簡單把Content-Type設(shè)成application/json然后手寫一個(gè)極簡的JSON序列化函數(shù)把std::map轉(zhuǎn)成JSON字符串。注意轉(zhuǎn)義雙引號(hào)和反斜杠中文不需要轉(zhuǎn)義成\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; }驗(yàn)證改造效果的方法也很直接寫一個(gè)test.cgi用curl發(fā)請(qǐng)求看返回的JSON能不能被jq解析。curl -s http://localhost/cgi-bin/index.cgi?actionuser.list | jq .如果能正常格式化輸出說明JSON結(jié)構(gòu)沒問題。從那以后我每次改完CGI程序都強(qiáng)制走一遍“curl測接口 → 瀏覽器看頁面 → 看error_log”這三步少一步都可能漏掉編碼或者權(quán)限的坑。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取