소개
URL 디코딩 및 인코딩이란 이름 그대로 간단하게 디코딩과 인코딩을 할 수 있는 온라인 도구를 만나보세요! URL인코딩에서 쉽고 빠르게 인코딩하거나 디코딩할 수 있습니다. URL은 사용자의 데이터를 번거러움 없이 인코딩하거나 사람이 읽을 수 있는 형식으로 디코딩합니다.
'퍼센트-인코딩'으로도 알려진 URL 인코딩은 통합 리소스 식별자(URI)에서 정보를 인코딩하기 위한 메커니즘입니다. URL 인코딩이라고 알려져 있지만 사실 통합 리소스 주소(URL)와 통합 리소스 이름(URN)을 포함한 주요 통합 리소스 식별자(URI) 세트 내에서 일반적으로 사용됩니다. HTTP 요청 내 HTML 제출 형식의 데이터로 쓰이는 것처럼 "application/x-www-form-urlencoded" 매체 종류의 데이터의 준비에서도 마찬가지로 사용됩니다.
고급 설정
강력한 보안'퍼센트-인코딩'으로도 알려진 URL 인코딩은 통합 리소스 식별자(URI)에서 정보를 인코딩하기 위한 메커니즘입니다. URL 인코딩이라고 알려져 있지만 사실 통합 리소스 주소(URL)와 통합 리소스 이름(URN)을 포함한 주요 통합 리소스 식별자(URI) 세트 내에서 일반적으로 사용됩니다. HTTP 요청 내 HTML 제출 형식의 데이터로 쓰이는 것처럼 "application/x-www-form-urlencoded" 매체 종류의 데이터의 준비에서도 마찬가지로 사용됩니다.
고급 설정
- 문자 세트: 데이터가 텍스트일 때 인코딩 체계는 문자 세트를 갖추고 있지 않습니다. 그러므로 사용자가 직접 어떠한 문자 세트가 사용되었는지를 설정해야 합니다. 일반적으로 문자 세트가 UTF-8이지만 다른 문자 세트일 가능성도 있습니다. 만일 어떤 문자 세트인지 확실하지 않을 경우 사용 가능한 설정을 선택하거나 자동 감지 설정을 사용해보시면 됩니다. 이 정보는 모든 문자와 기호들이 잘 보여지도록 디코딩된 데이터를 저희 웹사이트의 문자 세트에 맞도록 변환합니다. 하지만 파일들에 경우 웹세이프 변환이 적용될 필요가 없으므로 파일들은 문자 세트와 상관이 없습니다.
- 각 행 개별적 디코딩: 인코딩된 데이터는 일반적으로 연속된 텍스트로 구성이 되어 있기 때문에 새로운 행의 문자도 Base64 인코딩 형식으로 변환이 됩니다. 디코딩하기 전에 모든 인코딩되지 않은 빈칸은 무결성 입력 항목을 보존하기 위해서 제외됩니다. 이 설정은 여러분이 개별적인 여러 데이터 항목을 디코딩해야 할 때 유용합니다.
- 라이브 모드: 이 옵션을 켜면 브라우저의 자체 JavaScript 기능을 사용하여 저희 서버 쪽으로 전송하지 않고 즉시 인코딩됩니다. 현재는 UTF-8 문자 세트만 지원됩니다.
저희 서버와의 모든 통신은 안전한 암호화된 SSL 연결(https)을 통해 제공됩니다. 저희 웹사이트는 처리 직후 처음 다운로드가 시도된 파일이나, 15분 동안 자리를 비웠을 때 즉시 서버로부터 업로드된 파일을 지웁니다(둘 중 더 짧게 걸리는 방식으로 처리). 저희는 전송되었거나 업로드된 파일을 절대 보관하거나 검열하지 않습니다. 자세한 정보를 원하신다면 아래의 개인 정보 보호 정책을 읽어주세요.
완전 무료
저희 도구는 무료로 사용 가능합니다. 앞으로는 이런 간단한 작업을 위해 소프트웨어를 다운로드하실 필요가 없습니다.
URL 인코딩에 대한 세부 설명
URI 문자의 종류
URI에서 허용된 문자는 예약어거나 비예약어 중 하나입니다(또는 퍼센트 문자가 퍼센트-인코딩의 일부분). 예약어 문자는 가끔 특별한 의미를 가진 문자들입니다. 예로, 사선 문자들은 URL(더 일반적으로는 URI)의 다른 부분을 분리하기도 했었습니다. 비예약어 문자들은 그러한 특별한 의미를 가지고 있지 않습니다. 예약된 문자인 퍼센트-인코딩을 사용하는 것은 특별한 문자 순서들을 사용하는 것에 해당합니다. 예약어 세트와 비예약어 세트, 그리고 특별한 의미를 가진 특정한 예약어 내 결과가 URI와 URI의 체계를 관리하는 사양의 신규 개정판마다 조금씩 바뀌어 왔습니다.
| 섹션 2.2 예약어 문자 RFC 3986(2005년 1월식) | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
! |
* |
' |
( |
) |
; |
: |
@ |
& |
= |
+ |
$ |
, |
/ |
? |
# |
[ |
] |
| 섹션 2.3 비예약어 문자 RFC 3986(2005년 1월식) | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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 |
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에 포함된 다른 문자들은 무조건 퍼센트-인코딩이 되어 있어야 합니다.
퍼센트-인코딩 예약어 문자
예약어 세트(예약 문자)에서 나온 문자가 특별한 일부 문맥에서특별한 의미를 가지고(예약 목적) URI 체계가 그 문자를 사용해야 할 필요가 있는 다른 목적이 있다고 한다면 그 문자는 무조건 퍼센트-인코딩이 되어 있어야 합니다. 한 예약어 문자를 퍼센트-인코딩한다면 그것은 그 문자를 그것에 일치하는 ASCII 바이트 값으로 변환하는 것입니다. 그리고 나면 그것은 16진수 숫자 한 쌍의 값에 해당하는 것을 의미합니다. 퍼센트 기호("%")에 의해 앞서는 그 숫자들은 예약어 문자를 대신하는 URI에서 사용됩니다. (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 프로세서는 관행적으로 항상 동등하게 대하지 않을 수도 있습니다. 예로, URI 사용자는 "%41"를 "A"와 다르게 대해서는 안됩니다("%41"는 "A"가 퍼센트-인코딩된 것입니다). 또는 "%7E"는 "~"와 다릅니다. 하지만 몇 개는 동등할 수도 있습니다. URI 제작자는 퍼센트-인코딩된 비예약어 문자로부터 최대의 상호 정보 교환이 가능하기 위해 그런 경향을 줄입니다.
퍼센트 문자를 퍼센트-인코딩
퍼센트("%") 문자가 퍼센트-인코딩된 8비트를 표시하는 역할을 하는 이유로 해당 8비트는 해당 URI의 데이터로 사용하기 위해 "%25"으로 퍼센트-인코딩이 되어야 합니다.
임의 데이터 퍼센트-인코딩
대부분의 URI 체계는 IP 주소나 URI의 요소로서 파일 시스템 경로와 같은 임의의 데이터를 나타내는 것에 관여하고 있습니다. URI 체계 사양은 URI 문자와 해당 문자로 나타낼 수 있는 모든 가능한 데이터 값의 특정한 맵핑을 제공해야 합니다만 대부분은 그러지 않습니다.
2진수 데이터
1994년 RFC 1738의 발표 이후로 URI에서 2진수 데이터의 묘사를 제공하는 체계는 데이터를 8비트 바이트로 나누고 각 바이트를 위와 같은 방식으로 퍼센트-인코딩을 하여야만 하는 것이 명시되었습니다. 예로 바이트 값 0F(16진수)는 "%0F"로 표시되어야 하지만 바이트 값 41(16진수)은 "A" 또는 "%41"로 표시될 수 있습니다. 알파벳 숫자 조합이나 다른 비예약 문자는 인코딩되지 않은 문자들의 사용에서 더 짧은 URL들을 만들어낼 수 있으므로 특별히 더 선호됩니다.
문자 데이터
퍼센트-인코딩된 2진수 데이터를 위한 절차는 문자 베이스 데이터를 적용하기 위해 가끔씩 부적절하게나 완전히 명시되지 않은 상태로 대부분 추측되어 왔습니다. 이러한 관행은 월드 와이드 웹이 형성되던 시기, ASCII 문자 세트를 다룰 때나 ASCII에서 상응하는 바이트를 퍼센트-인코딩 시퀀스를 알아내기 위한 기초로 사용할 때 상대적으로 위험하지 않습니다. 많은 사람들이 문자와 바이트는 1대 1로 맵핑이 되고 호환이 된다고 생각합니다. 하지만 ASCII 영역을 표현해야 하는 니즈가 빠르게 커지고 URI 체계와 프로토콜이 자주 URI를 포함한 문자 데이터를 준비하는 기본적인 규칙을 제공하는 것을 실패했습니다. 웹 애플리케이션들은 결과적으로 다른 다양한 바이트적이고 상태 유지가 가능한 ASCII와 호환이 가능하지 않은 인코딩을 기본적인 퍼센트-인코딩으로 사용함에 따라 모호해지고 신뢰할 만한 해석이 어려워졌습니다.
그 예로, 많은 URI 체계와 프로토콜은 RFC 1738과 RFC 2396을 기본으로 그 데이터 문자들이 비예약어 문자들 또는 퍼센트-인코딩된 바이트들로 인해 URI에서 표현되기 전에 몇몇 명시되지 않은 문자 인코딩에 의해 바이트로 전환될 것이라고 예상합니다. 만약 체계가 URI가 어떤 인코딩이 사용된 것인지에 대한 힌트를 제공하는 것을 허용하지 않는다거나 인코딩이 ASCII를 사용하여 예약어와 비예약어 문자를 퍼센트-인코딩하는데 충돌이 발생한다면 그 URI는 신뢰성 있게 해석될 수 없습니다. 몇몇 체계는 인코딩을 설명하는데 실패합니다. 몇몇 체계는 인코딩에 대해 설명하는 것을 실패합니다. 그리고 데이터 문자를 직접적으로 URI 문자들에게 맵핑하는 것을 제안하는 대신 각 사용자에게 예약어 또는 비예약어 세트가 아닌 퍼센트-인코딩을 어떻게 할 것인지 맡겨둡니다.
| 퍼센트-인코딩 된 후의 공용 문자(ASCII 또는 UTF-8의 베이스로) | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 새 줄 | 공간 | " |
% |
- |
. |
< |
> |
\ |
^ |
_ |
` |
{ |
| |
} |
~ |
%0A 또는 %0D 또는 %0D%0A |
%20 |
%22 |
%25 |
%2D |
%2E |
%3C |
%3E |
%5C |
%5E |
%5F |
%60 |
%7B |
%7C |
%7D |
%7E |
임의 문자 데이터는 때때로 암호 숨기기 프로그램이나 다른 시스템 특정 변환 프로토콜에서 처럼, 퍼센트-인코딩되고 URI가 아닌 상황에서 사용됩니다.