ការឆ្លើយតបពី Requests មើលទៅខូចនៅពីក្រោយប្រូកស៊ី? ពិនិត្យការគាំទ្រ Brotli

Accept-Encoding:br ដែលចម្លងអាចលើសពីការគាំទ្ររបស់ឧបករណ៍ឌិកូដនៅក្នុងបរិស្ថាន Requests ដែលស្ថិតលើសេវា។

ប្រៀបធៀបកុំព្យូទ័រយួរដៃ និងដំណើរការដែលស្ថិតលើសេវានៅលើស្រទាប់ពីរផ្សេងគ្នា៖

ស្រទាប់សំណួរ
Content-Encodingតើអតិថិជនអាចឌីកុមព្រេសបៃ gzip/deflate/Brotli ដែលបានត្រឡប់មកវិញបានទេ?
Charsetតើបៃដែលបានឌីកុមព្រេសក្លាយជាអត្ថបទដោយរបៀបណា?

Requests ជាធម្មតាដោះស្រាយ gzip/deflate; Brotli ត្រូវការបណ្ណាល័យដែលបានតម្លើង និងគាំទ្រ។ Accept-Encoding ដែលចម្លងដោយដៃអាចប្រកាស br នៅពេលបរិស្ថាននេះមិនអាចឌិកូដវាបាន។ ការជ្រើសអត្ថបទ UTF-8 មិនឌីកុមព្រេស Brotli ទេ។

នៅពេលកំណត់ការចរចាដោយចេតនា៖

response = session.get(
    url,
    proxies={"https": "http://proxy.example:8080"},
    headers={"Accept-Encoding": "gzip, deflate"},
    timeout=30,
)
response.raise_for_status()

ប្រើ Session ដែលមានស្រាប់ URL HTTPS និងបឋមកថា/ការផ្ទៀងផ្ទាត់ដែលត្រូវការ។ ប្រៀបធៀប Accept-Encoding ចេញ Content-Encoding ចូល និងការគាំទ្រកញ្ចប់នៅលើម៉ាស៊ីនទាំងពីរ; អន្តរការីដែលបំប្លែងក៏អាចផ្តល់មេតាដាតាចាស់ដែរ។ ការប្រៀបធៀបទំព័រសាធារណៈដោយឡែកអាចប្រើ បញ្ជីប្រូកស៊ី HTTP សម្រាប់ URL ប្រូកស៊ីរបស់វា នៅកន្លែងដែលអនុញ្ញាតអន្តរការីសាធារណៈ ដោយគ្មានព័ត៌មានសម្គាល់ប្រូកស៊ីដែលទទួលមរតក បឋមកថាគណនីដែលចម្លង ឬទិន្នន័យតួសាធារណៈឯកជន។

បើមិនដូច្នេះ សូមជ្រើសរើសការចរចាធម្មតារបស់អតិថិជន។ ចំណុចប្រទាក់ content/text ងាយស្រួលរបស់ Requests ឌិកូដកូដដែលបានគាំទ្រ ដូច្នេះកុំឌីកុមព្រេសលទ្ធផលរបស់វាម្តងទៀត ដោយគ្រាន់តែព្រោះបឋមកថានិយាយឈ្មោះវា។

អត្ថបទពាក់ព័ន្ធ