Python 3.12 parse_qsl의 strict_parsing: 오류 필드를 조용히 넘길지 검토 목록에 남길지
Python 3.12의 parse_qsl은 기본 설정에서 쿼리 해석 오류를 조용히 무시할 수 있습니다. strict_parsing=True를 쓰면 해당 오류가 ValueError로 드러납니다. 링크 목록을 만들 때는 일부 결과만 남기지 말고, 원본 쿼리와 오류 항목을 함께 보존하세요.
1. 같은 쿼리를 두 설정으로 비교하기
다음은 Python 3.12에서 실행해 확인한 작은 예시입니다. broken에는 =로 나눈 값이 없습니다. 기본 호출에서는 a와 b의 쌍이 나오지만, strict_parsing=True에서는 예외가 발생합니다.
from urllib.parse import parse_qsl
raw = 'a=1&broken&b=2'
print(parse_qsl(raw))
# [('a', '1'), ('b', '2')]
try:
pairs = parse_qsl(raw, strict_parsing=True)
except ValueError as exc:
review = {'original_query': raw, 'error': str(exc)}
print(review)
# {'original_query': 'a=1&broken&b=2',
# 'error': "bad query field: 'broken'"}기본 호출의 결과가 있다는 사실과 원본의 모든 필드가 보존됐다는 사실은 다릅니다. 추출한 주소를 다시 정리할 때 결과만 보고 원래 쿼리가 완전했다고 판단하지 마세요.
2. strict_parsing과 빈 값 옵션은 다른 질문입니다
| 설정 | 확인하는 질문 |
|---|---|
| strict_parsing | 해석 오류를 조용히 넘길지 예외로 드러낼지 |
| keep_blank_values | 값이 빈 항목을 결과에 남길지 |
| max_num_fields | 읽을 필드 수의 상한을 둘지 |
옵션 이름이 비슷한 결과를 만들더라도 목적은 다릅니다. 예를 들어 값이 비어 있는 정상적인 a=와, 위 예시의 broken을 같은 문제로 기록하면 원인을 좁히기 어렵습니다. 사용할 정책을 정한 뒤 원본과 결과를 함께 비교하세요.
strict_parsing=True가 URL 전체의 유효성·접속 가능성·신뢰성을 검사하는 것은 아닙니다. 쿼리 해석 단계에서 예외가 없다는 사실을 보안 검사 완료로 표시하지 않습니다.
3. 링크 하나의 오류가 목록 전체를 지우지 않도록
목록 처리에서는 정상 결과와 검토 항목을 분리할 수 있습니다. 다만 오류가 난 링크를 임의로 고쳐 정상 목록에 넣기보다, 원래 쿼리·오류 메시지·적용한 설정을 남기고 의도한 주소를 확인하는 편이 좋습니다.
| 검토 기록 | 적을 내용 |
|---|---|
| 원본 | 추출 당시의 쿼리 문자열 |
| 오류 | 해석 단계에서 나온 ValueError 메시지 |
| 설정 | strict_parsing·빈 값·필드 수 옵션 |
| 다음 확인 | 작성자가 의도한 필드인지, 추출 과정의 손상인지 |
로그에는 전체 주소에 포함된 개인정보나 인증값을 그대로 남기지 않도록 별도의 가림 기준을 두세요. 이 예시는 a·b라는 가상 필드를 사용합니다. 실제 비공개 링크를 공개 보고서에 복사하라는 뜻은 아닙니다.
4. 자주 묻는 질문
기본값으로 결과가 나오면 오류가 없다는 뜻인가요?
아닙니다. 공식 문서는 기본값에서 오류를 조용히 무시한다고 설명합니다. 원본과 결과를 대조하세요.
ValueError가 나오면 링크를 삭제해야 하나요?
그 자체로 삭제 결론을 내릴 필요는 없습니다. 검토 목록에 보존하고 주소의 의도를 확인하는 절차를 정하세요.
Python 3.12 parse_qsl 공식 옵션 설명 읽기
공식 자료 확인일 2026년 10월 16일: Python 3.12 urllib.parse 공식 문서.
대표 삽화는 AI로 제작했으며, 본문 설명 도표는 확인 순서에 맞춰 직접 구성했습니다.
