온라인 URL 인코딩 형식으로 디코드
URL 디코드 및 인코드에 대하여
URL 디코드 및 인코드에 오신 것을 환영합니다. 이것은 URL을 손쉽게 인코딩하고 디코딩하기 위한 궁극적인 온라인 도구입니다. 우리의 플랫폼은 URL 인코딩 및 디코딩 프로세스를 단순화하도록 설계되어, 데이터를 URL 안전 형식으로 변환하거나 클릭 한 번으로 사람이 읽을 수 있는 상태로 되돌릴 수 있습니다.
URL 인코딩이란?
URL 인코딩은 종종 퍼센트 인코딩이라고 불리며, Uniform Resource Identifiers (URIs)를 형성하는 데 사용되는 중요한 메커니즘입니다. 일반적으로 URL 인코딩으로 알려진 이 기술은 URI 프레임워크 내에서 광범위하게 적용되며, Uniform Resource Locators (URLs)와 Uniform Resource Names (URNs) 모두를 포함합니다. 이는 문자를 인터넷을 통해 전송할 수 있는 형식으로 변환하여 웹 애플리케이션 및 HTTP 요청에서 데이터 제출에 필수적입니다.
기능 및 고급 옵션
우리 도구는 UTF-8, ASCII 및 다양한 ISO 형식을 포함한 여러 문자 집합을 지원하여 귀하의 요구에 맞는 호환성을 보장합니다. 다음을 사용자 정의할 수 있습니다:
- 문자 집합: 우리 웹사이트는 기본적으로 입력 데이터를 전송하기 위해 UTF-8 문자 집합을 사용합니다. 인코딩 전에 데이터를 다른 문자 집합으로 변환해야 하는 경우 이 옵션을 조정할 수 있습니다. 텍스트 데이터의 경우 인코딩 방식에 문자 집합이 포함되지 않음을 유의하세요.
- 줄바꿈 구분자: Unix 및 Windows 시스템은 줄바꿈을 위해 서로 다른 문자를 사용합니다. 인코딩 전에 선택한 옵션에 따라 이러한 문자를 교체하도록 데이터가 조정됩니다. 데이터에 맞게 Unix (LF) 및 Windows (CRLF) 줄바꿈 중에서 선택하세요.
- 각 줄 고유 인코딩: 줄바꿈 문자는 또한 그들의 퍼센트 인코딩된 동등물로 변환됩니다. 줄바꿈으로 나뉘어진 여러 개별 데이터 항목을 인코딩하려면 이 옵션을 사용할 수 있습니다.
- 줄을 76자 청크로 분할: 인코딩된 데이터는 공백 없이 연속적인 문자열로 변환됩니다. 여러 줄로 나누고 싶다면 이 옵션을 선택하세요. 문자 제한은 MIME (RFC 2045) 사양에 의해 설정되며, 각 인코딩된 줄은 76자를 초과할 수 없습니다.
안전성과 보안
우리는 귀하의 개인정보를 우선시합니다. 모든 통신은 SSL 암호화로 보호되며, 귀하의 업로드된 데이터를 저장하거나 검사하지 않습니다. 데이터는 우리의 서버에 저장되지 않으며, 귀하의 데이터는 처리 후 즉시 삭제되어 귀하의 정보가 기밀로 유지됩니다.
완전히 무료이며 사용자 친화적
우리의 URL 인코딩 및 디코딩 도구는 완전히 무료로 사용 가능합니다. 복잡한 소프트웨어 설치는 잊어버리세요—브라우저에서 바로 인코딩 작업을 수행하세요.
URL 인코딩의 세부 사항
URI 문자 유형
URI에서 문자는 두 가지 범주로 나뉩니다: 예약 문자와 비예약 문자, 그리고 인코딩에 사용되는 퍼센트 문자. 예약 문자는 특별한 의미를 가질 수 있습니다. 예를 들어, 슬래시는 URL(또는 더 넓게는 URI)의 서로 다른 섹션을 구분하는 데 사용됩니다. 반면, 비예약 문자는 특별한 의미를 갖지 않습니다. 퍼센트 인코딩을 사용할 때 예약 문자는 특정 시퀀스로 표현됩니다. 예약 문자와 비예약 문자의 정의, 그리고 특정 예약 문자가 중요한 맥락은 URIs와 URI 스킴을 규제하는 사양의 각 수정에 따라 진화해 왔습니다.
| ! | * | ' | ( | ) | ; | : | @ | & | = | + | $ | , | / | ? | # | [ | ] |
|---|
| A | B | C | D | E | F | G | F | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z |
| a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z |
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | - | _ | . | ~ |
퍼센트 인코딩 예약 문자
예약 집합의 문자 중 특정 맥락에서 특정 의미를 갖는 경우, URI 스킴이 다른 목적으로 이를 요구할 경우 퍼센트 인코딩이 필요할 수 있습니다. 퍼센트 인코딩은 문자를 해당하는 ASCII 바이트 값으로 변환한 다음, 그 값을 두 개의 16진수 숫자로 표현하며, 퍼센트 기호 ('%')로 접두사를 붙입니다. 비ASCII 문자의 경우, 문자는 일반적으로 UTF-8 바이트 시퀀스로 변환되며, 각 바이트는 같은 방식으로 표현됩니다.
예를 들어, 예약 문자 '/'는 URI의 'path' 구성 요소에서 구분 기호 역할을 합니다. URI 스킴이 '/'를 경로 세그먼트에 포함해야 한다고 지정하는 경우, 해당 세그먼트에서 문자를 직접 사용하는 대신 '%2F' (또는 '%2f')로 교체해야 합니다.
| ! | # | $ | & | ' | ( | ) | * | + | , | / | : | ; | = | ? | @ | [ | ] |
| %21 | %23 | %24 | %26 | %27 | %28 | %29 | %2A | %2B | %2C | %2F | %3A | %3B | %3D | %3F | %40 | %5B | %5D |
주어진 맥락에서 특정 목적이 없는 예약 문자도 퍼센트 인코딩될 수 있지만, 의미 측면에서 다른 문자와 동일하게 취급됩니다.
예를 들어, URI의 'query' 구성 요소('?' 문자 뒤의 부분)에서 '/' 문자는 예약으로 분류되지만, 특정 URI 스킴에 의해 지정되지 않는 한 일반적으로 특별한 기능이 없습니다. 따라서 예약 목적이 없을 때 퍼센트 인코딩이 필요하지 않습니다.
예약 문자가 퍼센트 인코딩 여부에 따라 차이가 나는 URI는 일반적으로 동등하다고 간주되지 않으며, 이는 동일한 리소스를 가리키지 않음을 의미합니다. 그러나 이는 해당 예약 문자가 지정된 목적이 없을 경우에만 적용됩니다. 예약 문자에 관한 구체적인 규칙은 개별 URI 스킴에 의해 정의됩니다.
퍼센트 인코딩 비예약 문자
비예약 집합의 문자는 퍼센트 인코딩이 필요하지 않습니다.
비예약 문자가 퍼센트 인코딩 여부로만 차이가 나는 URI는 정의상 동등하다고 간주됩니다. 그러나 실제로 URI 프로세서는 항상 동일하게 처리하지 않을 수 있습니다. 예를 들어, '%41'은 'A'와 동일하게 취급되어야 하며 ('%41'이 'A'의 퍼센트 인코딩이므로), '%7E'는 '~'와 동등해야 합니다. 그럼에도 불구하고 일부 시스템은 이를 구분할 수 있습니다. 최대 호환성을 보장하기 위해, URI 생성자는 비예약 문자의 퍼센트 인코딩을 피하는 것이 좋습니다.
퍼센트 인코딩 (%) 퍼센트 문자
퍼센트 ('%') 문자는 퍼센트 인코딩된 옥텟을 나타내는 데 사용되므로, URI에 데이터를 포함시킬 필요가 있을 때는 '%25'로 퍼센트 인코딩해야 합니다.
퍼센트 인코딩 임의 데이터
많은 URI 스킴은 IP 주소나 파일 시스템 경로와 같은 다양한 유형의 임의 데이터를 URI의 일부로 표현해야 합니다. URI 스킴의 사양은 이상적으로 URI 문자와 가능한 모든 데이터 값 간의 명확한 매핑을 제공하지만, 실제로는 그렇지 않은 경우가 많습니다.
이진 데이터
1994년 RFC 1738이 발표된 이후, URI에서 이진 데이터 표현을 허용하는 스킴은 데이터를 8비트 바이트로 나누고 각 바이트를 적절히 퍼센트 인코딩해야 한다고 규정되었습니다. 예를 들어, 바이트 값 0F(16진수)는 '%0F'로 표현해야 하며, 바이트 값 41은 'A' 또는 '%41'로 표시할 수 있습니다. 일반적으로는 알파벳 숫자 문자 및 기타 비예약 문자는 인코딩되지 않은 문자를 사용하는 것이 선호되며, 이는 더 짧은 URL을 생성합니다.
문자 데이터
이진 데이터의 퍼센트 인코딩 방법은 종종 명확한 지침 없이 문자 기반 데이터로 부적절하게 확장되었습니다. 월드 와이드 웹의 초기 시절, ASCII 집합의 문자로 작업할 때, 문자가 해당 바이트 값과 상호 교환 가능하게 퍼센트 인코딩될 수 있다고 일반적으로 가정되었습니다. 이 가정은 당시에는 크게 해롭지 않았습니다. 그러나 ASCII 범위를 넘어서는 문자를 표현할 필요성이 커지면서, URI 스킴과 프로토콜은 URI에 대한 문자 데이터를 준비하기 위한 표준화된 규칙이 부족했습니다.
그 결과, 웹 애플리케이션은 퍼센트 인코딩을 위해 다양한 다중 바이트 및 비ASCII 호환 인코딩을 사용하기 시작했으며, 이는 모호성을 초래하고 URI를 신뢰성 있게 해석하기 어렵게 만들었습니다.
예를 들어, RFC 1738 및 2396을 기반으로 한 많은 URI 스킴과 프로토콜은 데이터 문자가 비예약 문자 또는 퍼센트 인코딩된 바이트로 URI에 표현되기 전에 어떤 지정되지 않은 인코딩을 사용하여 바이트로 변환된다고 가정합니다. 스킴에서 사용된 인코딩을 지정하지 않거나 예약 문자와 비예약 문자의 ASCII 기반 퍼센트 인코딩과 충돌하는 경우, URI는 올바르게 해석하기 어려워집니다. 일부 스킴은 인코딩을 완전히 무시하고, 데이터 문자가 URI 문자에 직접 매핑되어야 한다고 제안합니다. 이는 사용자가 예약 또는 비예약 범주에 속하지 않는 문자를 어떻게 퍼센트 인코딩할지를 결정해야 하는 상황을 초래합니다.
| newline | space | " | % | - | . | < | > | \ | ^ | _ | ` | { | | | } | ~ |
| %0A or %0D or %0D%0A | %20 | %22 | %25 | %2D | %2E | %3C | %3E | %5C | %5E | %5F | %60 | %7B | %7C | %7D | %7E |
URL 인코딩의 간략한 역사
URL 인코딩은 인터넷 초기 시절에 뿌리를 두고 있으며, 1994년 RFC 1738의 발표로 공식화되었습니다. 이 사양은 임의 데이터를 URI에 적합한 형식으로 인코딩하는 기초를 마련하여 특별한 문자의 표현을 가능하게 하고 데이터가 올바르게 전송되도록 보장했습니다. 수년간 웹 표준이 발전함에 따라 퍼센트 인코딩을 둘러싼 관행도 진화하여, 비ASCII 문자와 다중 바이트 인코딩의 증가에 따라 더 넓은 범위의 문자 및 인코딩 스킴이 포함되었습니다. 이러한 진화는 URL 인코딩을 웹 개발자에게 필수적인 기술로 만들었으며, 다양한 플랫폼과 프로토콜에서 데이터가 온전하게 유지되고 올바르게 해석되도록 합니다.