python用于url解碼和中文解析的小腳本（續(xù)） by 不求東西

之前寫過一篇關(guān)于處理url里中文字符解碼文章，后來看到原文中TL的回復(fù)，發(fā)現(xiàn)原來那一篇文章存在著幾個(gè)問題，覺得這些問題可能別的同學(xué)也會(huì)遇到，就續(xù)寫一篇吧。

非默認(rèn)編碼的轉(zhuǎn)換
1
2
3
4
5
import

urllib
a="http://zh.wikipedia.org/wiki/%BD%F0%B6"
b="http://zh.wikipedia.org/wiki/%E9%97%A8"
de=urllib.unquote
print

de(a),de(b)

之前的文章里的這段代碼，我沒有考慮到gbk和utf編碼的問題，以為不帶有%5Cu這種unicode標(biāo)志字符的漢字解碼只要unquote就萬事大吉了呢，但對(duì)于與“默認(rèn)編碼環(huán)境”不同的編碼來說，還需要再多一步處理，所以上述的代碼是無法對(duì)a正確解碼的

TL給出了一種解決辦法，可以處理a這種殘疾的編碼形式（殘疾的原因，下面就會(huì)解釋）

1
2
de(a).decode("gbk","ignore")
de(b).decode("utf8","ignore")

再print就可以打印出中文字符了~

殘疾的編碼

可是，問題又來了，為什么還需要“ignore”這個(gè)參數(shù)呢，我發(fā)現(xiàn)如果不加這個(gè)參數(shù)，這樣使用，會(huì)報(bào)錯(cuò)的。

1
de(a).decode("gbk")

檢查了一下a在gfwlist中的出處以后，我發(fā)現(xiàn)自己犯了一個(gè)挺低級(jí)的錯(cuò)誤的（汗。）

事實(shí)是：a里那個(gè)網(wǎng)站本來應(yīng)該是zh.wikipedia.org*%BD%F0%B6%DC%B9%A4%B3%CC這樣的，我誤以為漢字編碼都是3個(gè)“百分號(hào)+2個(gè)十六進(jìn)制數(shù)”（3個(gè)字節(jié)）這樣的樣式，所以只取了前3個(gè)字節(jié)，也就是“%BD%F0%B6″。

而問題在于，gbk編碼和utf編碼所需的字節(jié)數(shù)是不一樣的，gbk只需2個(gè)字節(jié)即可編碼一個(gè)漢字，而a是用gbk編碼的，1個(gè)漢字的解碼不需要3個(gè)字節(jié)，多出來的這1個(gè)殘疾的字節(jié)就成為了decode異常的來源，刪掉這個(gè)多余的字節(jié)以后，解碼順利通過：

1
2
3
4
5
6
7
8
import

urllib
a="http://zh.wikipedia.org/wiki/%BD%F0"
#
gbk, 2 bytes per Chinese character
b="http://zh.wikipedia.org/wiki/%E9%97%A8"
#
utf8, 3 bytes per Chinese character
de=urllib.unquote
print

de(a).decode("gbk")
print

de(b).decode("utf8")定義解碼方式的優(yōu)先級(jí)

最后，我將TL的腳本中以優(yōu)先級(jí)的形式處理多種中文編碼的函數(shù)代碼copy了過來，同時(shí)將中文編碼的字節(jié)下限由3字節(jié)改為了2個(gè)字節(jié)以后，發(fā)現(xiàn)原來gfwlist中所有不能正常解碼的中文，現(xiàn)在都可以顯示出來了，哈哈，不錯(cuò)~

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<code class="py keyword" style="border-width:0px!important; margin:0px!important; p