Server.UrlEncode와 HttpUtility.UrlEncode의 차이점이 있습니까?
답변
HttpServerUtility.UrlEncode
HttpUtility.UrlEncode
내부적으로 사용 합니다. 특별한 차이는 없습니다. 존재하는 이유 Server.UrlEncode
는 클래식 ASP와의 호환성 때문입니다 .
답변
전에는 이러한 방법으로 두통이 심 했으므로 변형 을 피하고UrlEncode
대신Uri.EscapeDataString
이해할 수있는 행동을하는 것이 좋습니다 .
보자 …
HttpUtility.UrlEncode(" ") == "+" //breaks ASP.NET when used in paths, non-
//standard, undocumented.
Uri.EscapeUriString("a?b=e") == "a?b=e" // makes sense, but rarely what you
// want, since you still need to
// escape special characters yourself
그러나 개인적으로 가장 좋아하는 것은 HttpUtility.UrlPathEncode 여야 합니다.이 것은 실제로 이해할 수 없습니다. 다음을 인코딩합니다.
- “”==> “% 20”
- “100 % true”==> “100 %% 20true”(좋아요, URL이 깨졌습니다)
- “test A.aspx # anchor B”==> “test % 20A.aspx # anchor % 20B “
- “test A.aspx? hmm # anchor B”==> “test % 20A.aspx? hmm #anchor B “( 이전 이스케이프 시퀀스와의 차이점에 유의하십시오! )
또한 웹 사이트에서 클라이언트로 안정적인 HTTP 전송을 위해 URL 문자열의 경로 부분을 인코딩합니다. 실제로 무엇을 설명하지 않고. 당신은 Uzi로 발에 자신을 쏠 가능성이 적습니다 …
요컨대 Uri.EscapeDataString 을 고수하십시오 .
답변
.NET Core 및 .NET Standard의 세계에서는 URL 인코딩에 가장 일반적으로 사용되는 옵션은 WebUtility.UrlEncode (아래 System.Net
) 및 Uri.EscapeDataString 입니다. 여기와 다른 곳에서 가장 인기있는 답변으로 판단하면 Uri.EscapeDataString 이 선호되는 것으로 보입니다. 하지만 그렇습니까? 차이점을 이해하기 위해 몇 가지 분석을했으며 여기에 내가 생각해 낸 내용이 있습니다.
WebUtility.UrlEncode
공간을 다음과 같이 인코딩합니다+
.Uri.EscapeDataString
그것을 다음과 같이 인코딩%20
.Uri.EscapeDataString
퍼센트 인코딩!
,(
,)
, 그리고*
;WebUtility.UrlEncode
하지 않습니다.WebUtility.UrlEncode
퍼센트 인코딩~
;Uri.EscapeDataString
하지 않습니다.Uri.EscapeDataString
발생UriFormatException
이상 65,520 자 이상의 문자열에;WebUtility.UrlEncode
하지 않습니다. ( 특히 URL 인코딩 양식 데이터를 처리 할 때 생각보다 더 일반적인 문제 입니다.)Uri.EscapeDataString
던져UriFormatException
온 높은 대리 문자 ;WebUtility.UrlEncode
하지 않습니다. (UTF-16 일 가능성이 훨씬 적습니다.)
URL 인코딩을 위해 문자는 3 가지 범주 중 하나에 해당합니다. 예약되지 않은 (URL의 합법적); reserved (법적이지만 특별한 의미가 있으므로 인코딩하고 싶을 수도 있음); 그리고 다른 모든 것 (항상 인코딩되어야 함).
RFC 에 따르면 예약 문자는 다음과 같습니다.:/?#[]@!$&'()*+,;=
예약되지 않은 문자는 영숫자이며 -._~
판결
Uri.EscapeDataString 은 임무를 명확하게 정의합니다 : 예약 된 문자와 불법 문자를 모두 %-인코딩 WebUtility.UrlEncode 는 정의와 구현 모두에서 더 모호합니다. 이상하게도 일부 예약 문자를 인코딩하지만 다른 문자는 괄호로 묶지 말고 괄호로 묶지 말아야합니다. 그러나 낯선 사람은 여전히 무고한 예약되지 않은 ~
문자를 인코딩합니다 .
사용 – 따라서, 나는 인기 조언에 동의 Uri.EscapeDataString 가능한 경우, 그리고 같은 그 예약 문자를 이해 /
하고 ?
인코딩 얻을 것이다. 잠재적으로 큰 문자열, 특히 URL로 인코딩 된 양식 컨텐츠를 처리해야하는 경우 WebUtility.UrlEncode로 돌아가서 단점을 수용하거나 그렇지 않으면 문제를 해결해야합니다.
편집은 : 나는 한 시도 ALL에 위에서 언급 한 단점의 시정 Flurl 비아 Url.Encode
, Url.EncodeIllegalCharacters
그리고 Url.Decode
정적 메서드. 이것들은 핵심 패키지 (작고 HTTP가 포함되어 있지 않음)에 있거나 소스에서 자유롭게 추출 할 수 있습니다. 이에 대한 의견 / 의견을 환영합니다.
어떤 문자가 다르게 인코딩되는지 발견하는 데 사용한 코드는 다음과 같습니다.
var diffs =
from i in Enumerable.Range(0, char.MaxValue + 1)
let c = (char)i
where !char.IsHighSurrogate(c)
let diff = new {
Original = c,
UrlEncode = WebUtility.UrlEncode(c.ToString()),
EscapeDataString = Uri.EscapeDataString(c.ToString()),
}
where diff.UrlEncode != diff.EscapeDataString
select diff;
foreach (var diff in diffs)
Console.WriteLine($"{diff.Original}\t{diff.UrlEncode}\t{diff.EscapeDataString}");
답변
이러한 방법 중 하나를 사용하지 않아야 할 수도 있습니다. 마이크로 소프트의 안티 – 크로스 사이트 스크립팅 라이브러리 에 대한 교체를 포함 HttpUtility.UrlEncode
하고 HttpUtility.HtmlEncode
모두 더 많은 표준을 준수하고, 더 안전 것을. 보너스로 JavaScriptEncode
방법도 있습니다.
답변
Server.UrlEncode ()는 Classic ASP와의 호환성을 제공하기 위해 존재합니다.
Server.UrlEncode(str);
다음과 같습니다.
HttpUtility.UrlEncode(str, Response.ContentEncoding);
답변
동일, Server.UrlEncode()
전화HttpUtility.UrlEncode()