URL 인코딩 형식을 다루어야 하나요? 그러면 여러분에게 이 웹사이트가 딱 맞네요! 저희 웹사이트의 아주 편리한 온라인 도구를 사용하여 데이터를 인코딩하거나 디코딩해보세요.

URL 인코딩 형식으로 인코딩

2진수를 인코딩을 하실 경우(이미지, 문서 등), 이 페이지 아래쪽으로 약간 더 내려가셔서 파일 업로드 양식을 사용해보세요.

URL 인코딩 형식으로 파일을 인코딩

0 여기를 클릭(또는 터치)하여 파일 선택
최대 파일 크기는 192MB입니다.
작업 중...
인코딩 프로세스가 완료될 때까지 기다리세요.
성공!
{{ output }} 인코딩된 파일을 다운로드하려면.
참고로, 이 파일은 첫 번째 다운로드 시도 또는 15 분간의 무활동 시간 직후에 시스템에서 삭제됩니다.
오류!오류가 발생했습니다:{{ error }}

소개

URL 디코딩 및 인코딩이란 이름 그대로 간단하게 디코딩과 인코딩을 할 수 있는 온라인 도구를 만나보세요! URL인코딩에서 쉽고 빠르게 인코딩하거나 디코딩할 수 있습니다. URL은 사용자의 데이터를 번거러움 없이 인코딩하거나 사람이 읽을 수 있는 형식으로 디코딩합니다.

'퍼센트-인코딩'으로도 알려진 URL 인코딩은 통합 리소스 식별자(URI)에서 정보를 인코딩하기 위한 메커니즘입니다. URL 인코딩이라고 알려져 있지만 사실 통합 리소스 주소(URL)와 통합 리소스 이름(URN)을 포함한 주요 통합 리소스 식별자(URI) 세트 내에서 일반적으로 사용됩니다. HTTP 요청 내 HTML 제출 형식의 데이터로 쓰이는 것처럼 "application/x-www-form-urlencoded" 매체 종류의 데이터의 준비에서도 마찬가지로 사용됩니다.

고급 설정
  • 문자 세트: 저희 웹사이트는 UTF-8 문자 세트를 사용하며 입력한 데이터는 UTF-8 형식으로 전송됩니다. 다른 문자 세트로 변환하고 싶은 경우 인코딩 전에 이 옵션을 변경해주세요. 참고로, 텍스트 데이터의 경우 인코딩 체계에는 문자 세트가 포함되어 있지 않으므로 디코딩 과정에서 적절한 세트를 지정해야 합니다. 파일의 경우, 이진수 옵션이 기본으로 설정되어 있어 변환을 생략합니다. 이 옵션은 일반 텍스트 문서를 제외한 모든 파일에 필요합니다.
  • 새로운 행 분리자: 유닉스와 윈도우 시스템은 서로 다른 식으로 행 분리를 하므로 인코딩 이전에 둘 중 하나의 옵션이 사용자의 데이터에서 사용될 것입니다. 파일 섹션에 경우 파일 자체에 해당 분리자가 포함이 되어 있으므로 이것은 부분적으로 무관합니다. 하지만 "각 행 개별 인코딩" 또는 "행을 세트로 분리" 기능에 대해서는 분리자를 설정할 수 있습니다.
  • 각 행을 개별적으로 인코딩: 새로운 행의 문자조차도 퍼센트-인코딩 형식으로 변환이 됩니다. 행을 쪼개서 여러 개의 독립적인 데이터를 인코딩할 때 이 옵션을 사용하세요. (*)
  • 행을 세트로 분리: 인코딩된 데이터는 빈칸 없는 연속된 텍스트가 됩니다. 그러므로 여러 행으로 나누려면 이 옵션을 선택하세요. 적용된 문자 한계는 인코딩된 행이 76자 이상이 되지 않도록 하라고 MIME(RFC 2045) 규격에 정의 되어 있습니다. (*)
  • 라이브 모드: 이 옵션을 켜면 브라우저의 자체 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가 아닌 상황에서 사용됩니다.
모바일 버전으로 전환
2012-2024 urlencoder.org
개인 정보 보호 정책 문의하기
이 웹사이트는 쿠키를 사용합니다. 당사는 쿠키를 사용하여 사용자에게 최적화된 콘텐츠 및 광고를 보여주고, 트래픽을 분석하는데 사용됩니다.