쿼리 문자열 퇴화 사례

Question

나는 URI 쿼리 문자열의 유효성을 검사하기 위해 올바른 정규 표현식을 찾고 있습니다. here 또는 here 답변을 찾았지만 여전히 키 또는 값이 비어있을 수있는 가장자리 경우에 의문이 생깁니다. 예를 들어, 다음을 유효한 쿼리 문자열로 취급해야합니까?

?&& 
?= 
?a= 
?a=& 
?=a 
?&=a 

Answer 1

내가 찾고 있어요 [...] [유효] URI 쿼리 문자열에 대한 올바른 정규 표현식합니다.

물론, 문제가 없습니다. RFC 3986, appendix B에 따라, 여기있다 : 당신이 더 정교한 무언가를 원하는 경우에, 당신은 %로 인코딩 된 엔티티에 추가로 허용 된 문자 section 3.4을 확인할 수 있습니다

^([^#]*)$ 

. 정규식은 다음과 같습니다.

^(%[[:xdigit:]]{2}|[[:print:]])*$ 

RFC 3986에 관한 한 모든 예제는 지금까지 유효합니다. 쿼리 문자열이 으로 인코딩 된 방법에 대해 RFC를 설명하는 동안 RFC는 구조화 된이어야합니다. 이전 RFC는 공식적으로 문법을 지정하지 않고 계속해서 CGI와 HTTP 간의 쿼리 문자열 구조에 대한 권한을 이동시키고 있습니다 (예 : RFC 3875, sec. 4.1.7, RFC 2396, sec. 3.4, RFC 1808, sec. 2.1, & hellip; 참조).

흥미로운 참고

는 RFC 7230, section 2.4에서 찾을 수 있습니다 :이 쿼리의 특정 형태를 지원하지 않는 배포 운영의 어려움의 원인이 될 수 있습니다

응용 프로그램은 직접 쿼리 구문을 지정해서는 안된다. [& hellip;] HTML은 양식 제출에 사용 된 쿼리 문자열의 구문을 제한합니다. 새로운 형태의 언어를 모방, 대신에 URI를 같은 쿼리 문자열에서 전체 유효성 검사에 대한

의 폭 넓은 다양성의 생성을 허용해서는 안, 당신은 W3C에서 권장하는 algorithm for decoding formdata을 구현해야합니다. 정규식에서 할 수 있지만, 나는 그것을 정당성의 이유로 들겠습니다.

귀하의 예와 관련하여 : 나는 그것이 모두 유효하다고 믿습니다. 그들이 어떻게 해석되는지는 수신 신청서에 남겨 두어야합니다. 일부는 생각할 수있는 것처럼 프린지 케이스가 아닙니다. ?&&은 단순히 빈 사전이고 ?=a은 { "": "a" }으로 매핑 될 수 있습니다.