에헴, 구체적인 링크 주소를 좀 더 일찍 공개했어야 했는데, 제가 방법을 자세히 알아보고 코드를 넣어두겠습니다.

결과:

req.encoding이 대상의 인코딩 방법을 추측하도록 하면 됩니다.
requests 모듈의 models.py 769행에 있는 주석은 사람들이 자동으로 대상의 인코딩 유형을 감지할 수 있음을 분명히 합니다. 대상 웹 페이지의 콘텐츠와 인코딩 감지를 담당하는 특정 코드는 여기에 universaldetector.py
있으므로 이 기능을 사용하여 인코딩한 다음 utf-8을 눌러 디코딩하면 됩니다.

결과:

모든 헤더를 표시하고 charset 속성이 있어야 합니다.

업데이트

실제로는 유니코드에서 이스케이프된 URI 인코딩입니다.
디코딩 예시는 다음과 같습니다.

결과:

짱벶믵색
한국 사람~~

추가 업데이트

곰곰이 생각해보니 또 다른 인코딩 형식일 수도 있어서 gb2312로 한번 시도해 봤습니다.

결과는 다음과 같습니다.

이게 더 믿을만한 것 같아요~
urllib에서 다음 메소드를 사용할 수 있습니다. quote, unquote
예:

결과는 다음과 같습니다.

3가지 업데이트

원리를 설명하고 있어요~
charset모를 때는 추측만 할 수 있고, chardet을 사용하여 추측할 수도 있습니다.
또한 @ferstar가 req.encoding라고 한 것은 响应体(Response.content)이 아닌 headers을 위한 것입니다.
Asker가 코드와 웹 링크를 제공하지 않기 전에는 Asker에서 제공하는 데이터만 사용할 수 있었습니다.

파일 이름=%C9%F1%BC%B6%BB%F5%C0%C9.txt

자세히 보세요. 이건 字符串가 아니라 bytes입니다! 따라서 req.encoding은 유효하지 않습니다.
앞서 언급했듯이 이것은 실제로 URI라는 문자로, 원래 문자 의 특정 인코딩 에서 탈출된 %입니다. URI은 의 이스케이프 문자
입니다.

질문자가 질문을 업데이트하고 개선한 후 시간 내에 답변을 확인했고, 질문자가 내 답변을 수락하기 전에도 올바른 결과를 얻을 수 있었고 문제를 해결할 수 있었습니다. , 귀하의 대답은 업데이트가 없는 것 같습니다. 이는 이전에 해당 소스 코드의 특정 구현을 게시한 것도 사실이며, 이는 제가 언급한 req.encoding 방법이 훨씬 더 사실입니다. 역할이고, 말씀하신대로 헤더로는 쓸모가 없는 것 같습니다

@ferstar님 댓글 인용 완료

SF 콘텐츠 업데이트에는 과거 버전 기록
이 있으니 확인하고 비교해 보세요.
질문: ider
답변: 동의 및 수락

3采纳 정답 #r3을 업데이트한 지 몇 시간 후, @ider는 질문 #r4를 업데이트하고
@ferstar의 오답 #r1의 첫 번째 버전을 다시 게시했습니다. 采纳그 후
댓글로 이의를 제기했고 @ferstar가 답변 #r2의 두 번째 버전을 업데이트했습니다. 그리고 @ferstar의 두 번째 답변은 여전히 ​​틀렸습니다

그런데 @ferstar 답변의 두 번째 버전이 올바른 결과를 제공하는 이유는 무엇입니까? gb2312이전에 올바른 인코딩gbk을 찾았기 때문에 호환되는 인코딩

또한 req.encoding은 headers에 대해 조치를 취할 수 없습니다.
이 결론에는 변함이 없습니다. 이는 headers가 body보다 앞에 오는 http 원칙에 따라 결정됩니다.

이 프로그램을 작성하는 올바른 방법에 대해 설명하고 업데이트하기에는 너무 게으르고 피곤합니다!
@ider가 내 답변을 다시 채택하지 않는 한 고려할 수도 있습니다~~

파일 이름은 gb2312를 사용하여 인코딩되었으며, utf-8에 따라 디코딩되도록 디코딩도 설정해야 합니다. 문자가 깨져 나타납니다. 어쩌면 기본적으로 utf-8에 따라 디코딩하도록 디코딩을 설정했을 수도 있습니다.