Server.UrlEncode 대 HttpUtility.UrlEncode

Server.UrlEncode와 HttpUtility.UrlEncode의 차이점이 있습니까?

HttpServerUtility.UrlEncodeHttpUtility.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()