我需要使用python的requests 下载一些文件,但是文件是中文名的
chrome调试看出来的文件名是
Content-Disposition:attachment; filename=%C9%F1%BC%B6%BB%F5%C0%C9.txt
requests 下载显示的却是乱码
import requests
url = 'http://www.23us.so/modules/article/txtarticle.php?id=156'
req = requests.head(url)
headers = req.headers
print( headers.get('Content-Disposition'))
>> attachment; filename=ÇàÔÆÏÉ·.txt
我试过设置req.encoding 没有效果
怎么把header中的文字恢复出来,requests中似乎没有相关方法
各位可以调试一下
咳咳, 你應該早點放出具體連結地址的, 我跟進下方法, 放碼:
結果:
你讓
req.encoding
自己猜目标的编码方式即可.requests
模块的models.py
第 769 行注释说的很清楚, 人家可以自动检测目标网页内容的编码类型, 而具体负责检测编码的代码在这里universaldetector.py
所以我们只需要利用下这个特性编码然后再按
utf-8
解碼即可, 看代碼:結果:
你把 headers 全部顯示出來看看,應該有個 charset 屬性。
更新
這個其實是 URI encode,是從 unicode轉義得來的。
解碼範例如下:
結果:
짱벶믵색
是韓文~~
再更
後來仔細想了想,也可能是別的程式設計格式,就拿
gb2312
試試看。結果是:
覺得這個比較可靠~
這些方法,在urllib都有,分別是:
quote
,unquote
範例:
結果是:
三更
我在講解原理~
提問者 filename=%C9%F1%BC%B6%BB%F5%C0%C9.txt在不知道
charset
的情況下,只能charset
的情况下,只能猜;requests也是用chardet
进行猜测。而且,@ferstar 所说的
req.encoding
是用于响应体(Response.content)
的,并不能用于headers
猜;requests也是用
chardet
進行猜測。 而且,@ferstar 所說的req.encoding
是用於響應體(Response.content)
的,並不能用於headers
。 在提問者沒提供程式碼和網頁連結之前,我只能用
而來。字符串
,不是bytes
!所以req.encoding
是无效的。前面我也提到过,这其实是个
URI
,从原字符的某个编码转义而来。%
是URI
仔細看,這是個字串
,不是bytes
!所以req.encoding
是無效的。 前面我也提到過,這其實是個URI
,從原字元的某個編碼轉義
%
是URI
的轉義符
。還原的方法在上面我已經寫了,結果也是正確的。
為什麼不採納正確的答案呢?
為什麼不採納正確的答案呢?
在題主更新完善問題後我正好在所以及時跟進了答案,可以得到正確結果解決了題主的問題,這是事實;題主採納我的答案之前你這個答案好像並沒有更新,這也是事實;我之前貼出了相應源碼的具體實現,也是在講道理,這更是事實;我說的req.encoding方法確實起到了作用,而不是像你說的對headers無用,貌似也是事實
引用@ferstar 的評論,完成
的,翻出來對比一下。SF的內容更新是有
歷史版本記錄
提問者:ider
,我在評論中提出異議,@ferstar 更新了第二版答案#r2。3
小时,@ider 更新了问题#r4,并采纳
了@ferstar 的第一版错误答案#r1。采纳
回答:同意並接受回答:ferstar在我更新了正確答案#r3之後
3
小時,@ider 更新了問題#r4,並採納
了@ferstar 的第一版錯誤答案#r1。採納
之後而且,@ferstar 的第二版答案
🎜但是,為什麼@ferstar 的第二版答案會得到正確的結果呢? 🎜因為之前我找到了正確編碼🎜,他不過是替換成相容編碼依然是錯的
gb2312
,他不过是替换成兼容编码gbk
gbk
而已。 🎜再說說
req.encoding
不能作用于headers
。这个结论依然没变。这是由http原理决定的,
headers
先于body
。至於這個程序正確的寫法,我也懶得解釋和更新了,累!
除非,@ider 重新採納我的答案,還有可能考慮~~
你的檔案名稱是使用 gb2312編碼的,你解碼也需要設定 按照gb2312 解碼,如果按照utf-8解碼,就會出現亂碼。可能你設定過的解碼,預設按照utf-8解碼的