課程
/前端開發(fā)
/Node.js
/進(jìn)擊Node.js基礎(chǔ)(二)
有時候Node.js爬蟲采集到的數(shù)據(jù)有少數(shù)漢字亂碼,不知道怎么解決?
2016-06-11
源自:進(jìn)擊Node.js基礎(chǔ)(二) 1-4
正在回答
亂碼原因是傳輸數(shù)據(jù)時 buffer 的拼接問題!
例如以下寫法:
var?data?=?""; res.on("data"?,?function(chunk){ ????data?+=?chunk; });
如果爬取的數(shù)據(jù)的中文數(shù)據(jù)量比較小,一般顯示是正常的。但當(dāng)爬取的數(shù)據(jù)量較大時,很有可能出現(xiàn)部分漢字會亂碼現(xiàn)象。
產(chǎn)生原因:在默認(rèn)的情況下 trunk 是一個 Buffer 對象,而
data?+=?trunk
的實(shí)質(zhì)上隱藏了 toString 的變換的:
data?=?data.toString()?+?trunk.toString();
由于漢字不是用一個字節(jié)來存儲的,如果某一塊 buffer 傳輸?shù)那『貌煌暾?,將會?dǎo)致有被截破的漢字的存在,于是出現(xiàn)亂碼。解決方法:先用一個數(shù)組把所有 buffer 保存起來,同時記錄 buffer 的總長度。數(shù)據(jù)傳輸完畢的時,再通過 Buffer.concat 方法把所有 buffer 拼接。最后,用 toString 方法轉(zhuǎn)成字符串,這時獲取的 data 數(shù)據(jù)就是正確的了。
var?chunks?=?[],?size?=?0; res.on("data"?,?function(chunk){ ????chunks.push(chunk); ????size?+=?chunk.length; }); res.on("end"?,?function(){ ????var?buffer?=?Buffer.concat(chunks,?size); ????var?html?=?buffer.toString(); });
// 在更細(xì)膩的?buffer?連接方式:
res.on('end',?function?()?{ ????var?buffer?=?null; ????switch(buffers.length)?{ ????????case?0: ????????????buffer?=?new?Buffer(0); ????????????break; ????????case?1: ????????????buffer?=?buffers[0]; ????????????break; ????????default: ????????????buffer?=?new?Buffer(size); ????????????for?(var?i?=?0,?pos?=?0,?l?=?buffers.length;?i?<?l;?i++)?{ ????????????????var?chunk?=?buffers[i]; ????????????????chunk.copy(buffer,?pos); ????????????????pos?+=?chunk.length; ????????????} ????????break; ????} ????var?html?=?buffer.toString(); });
好像不是編碼問題,如果是編碼問題,每次爬去的中文應(yīng)該全部是亂碼。我的現(xiàn)象是連續(xù)爬取多次,只有其中某一的幾個中文亂碼。應(yīng)該和數(shù)據(jù)流或緩沖有關(guān)系。
var iconv = require('iconv-lite');
安裝 ?iconv-lite
在獲取Body之后轉(zhuǎn)碼
body = iconv.decode(body, 'gbk');
舉報
本教程帶你攻破 Nodejs,讓 JavaScript流暢運(yùn)行在服務(wù)器端
Copyright ? 2025 imooc.com All Rights Reserved | 京ICP備12003892號-11 京公網(wǎng)安備11010802030151號
購課補(bǔ)貼聯(lián)系客服咨詢優(yōu)惠詳情
慕課網(wǎng)APP您的移動學(xué)習(xí)伙伴
掃描二維碼關(guān)注慕課網(wǎng)微信公眾號
2016-06-11
亂碼原因是傳輸數(shù)據(jù)時 buffer 的拼接問題!
例如以下寫法:
如果爬取的數(shù)據(jù)的中文數(shù)據(jù)量比較小,一般顯示是正常的。但當(dāng)爬取的數(shù)據(jù)量較大時,很有可能出現(xiàn)部分漢字會亂碼現(xiàn)象。
產(chǎn)生原因:
在默認(rèn)的情況下 trunk 是一個 Buffer 對象,而
的實(shí)質(zhì)上隱藏了 toString 的變換的:
由于漢字不是用一個字節(jié)來存儲的,如果某一塊 buffer 傳輸?shù)那『貌煌暾?,將會?dǎo)致有被截破的漢字的存在,于是出現(xiàn)亂碼。
解決方法:
先用一個數(shù)組把所有 buffer 保存起來,同時記錄 buffer 的總長度。
數(shù)據(jù)傳輸完畢的時,再通過 Buffer.concat 方法把所有 buffer 拼接。
最后,用 toString 方法轉(zhuǎn)成字符串,這時獲取的 data 數(shù)據(jù)就是正確的了。
// 在更細(xì)膩的?buffer?連接方式:
2016-06-11
好像不是編碼問題,如果是編碼問題,每次爬去的中文應(yīng)該全部是亂碼。我的現(xiàn)象是連續(xù)爬取多次,只有其中某一的幾個中文亂碼。應(yīng)該和數(shù)據(jù)流或緩沖有關(guān)系。
2016-06-11
var iconv = require('iconv-lite');
安裝 ?iconv-lite
在獲取Body之后轉(zhuǎn)碼
body = iconv.decode(body, 'gbk');