인코딩·디코딩 종류와 차이 - Base64·URL·HTML 엔티티 완벽 정리

인코딩이란 무엇인가?

인코딩(encoding)은 데이터를 한 표현 방식에서 다른 표현 방식으로 변환하는 작업입니다. 텍스트 인코딩(UTF-8, EUC-KR), 이진 인코딩(Base64), URL 인코딩, HTML 엔티티 등 여러 종류가 있는데, 각각 해결하려는 문제가 달라요. 공통점은 정보의 의미는 그대로 두고 표현만 바꾼다는 점입니다. 즉 인코딩은 암호화가 아니에요. 누구든 같은 알고리즘을 알면 디코딩해서 원본을 얻을 수 있습니다. 인코딩의 목적은 데이터가 어떤 환경(텍스트만 받는 채널, URL, HTML 등)에서도 깨지지 않고 전달되도록 하는 것이고, 그래서 종류별로 다른 환경에 맞춰져 있어요.

Base64 - 이진 데이터를 텍스트로

Base64는 임의의 이진 데이터(이미지, 파일, 암호화된 데이터)를 텍스트 64자(A~Z, a~z, 0~9, +, /)만으로 표현하는 방식입니다. 이메일이나 JSON처럼 텍스트만 받는 환경에 이미지나 파일을 담아 보내야 할 때 자주 써요. 알고리즘은 단순합니다. 3바이트의 이진 데이터를 6비트씩 4조각으로 나누고, 각 조각을 64자 알파벳에 매핑해 4글자를 만드는 거예요. 그래서 Base64로 변환하면 데이터 크기가 약 4/3배(33% 증가) 됩니다. 길이가 4의 배수가 안 맞으면 끝에 = 기호로 패딩해요. JWT 토큰, data URI(data:image/png;base64,...), 이메일 첨부 파일 인코딩 등에서 흔히 만납니다. URL 안전 변형으로 +, /를 -, _로 바꾼 Base64URL도 있어요.

URL 인코딩(퍼센트 인코딩)

URL에는 사용할 수 없는 문자들이 있습니다. 공백, 한글, 특수문자(?, &, #, /) 같은 것들이요. 그래서 URL의 query string이나 path 파라미터에는 퍼센트(%) 인코딩을 써요. 각 바이트를 %XX 형식의 16진수로 표현하는 방식입니다. 예를 들어 공백은 %20, 한글 한 글자(UTF-8 3바이트)는 %EC%84%9C%EC%9A%B8(서울)처럼 변환돼요. JavaScript의 encodeURIComponent(), Python의 urllib.parse.quote()가 이 작업을 담당합니다. 자주 하는 실수는 이중 인코딩이에요. 이미 인코딩된 URL을 다시 인코딩하면 %20이 %2520이 되면서 깨집니다. 또 encodeURI와 encodeURIComponent를 헷갈리는 경우도 흔한데, ?, &, = 같은 query 구조 문자를 처리하는 범위가 다릅니다. 일반적으로 파라미터 값에는 encodeURIComponent를 써야 안전해요.

HTML 엔티티 - HTML에 표시 안 되는 문자 다루기

HTML 안에 <, >, & 같은 문자를 그대로 적으면 태그로 해석되어 의도한 표시가 안 됩니다. 이런 문자를 HTML 엔티티로 변환해야 해요. <는 <, >는 >, &는 &, 큰따옴표는 "로 표기합니다. 또 사용자가 입력한 텍스트를 HTML로 그대로 출력하면 XSS(Cross-Site Scripting) 공격이 가능하니, 출력 전에 반드시 HTML 엔티티로 escape해야 합니다. 대부분의 현대 프레임워크(React, Vue, Angular)는 자동으로 해주지만, 직접 innerHTML이나 dangerouslySetInnerHTML을 쓰면 안전 처리가 빠질 수 있어요. 한국어처럼 ASCII가 아닌 문자도 일부 환경에서 숫자 엔티티로 변환할 수 있지만, UTF-8로 저장되는 현대 환경에서는 보통 그대로 두면 됩니다.

인코딩과 암호화는 다르다

가장 흔한 오해입니다. 인코딩은 누구나 디코딩해서 원본을 볼 수 있어요. Base64로 비밀번호를 변환했다고 해서 안전해지는 건 아닙니다. 단지 ASCII가 아닌 문자를 ASCII로 표현했을 뿐이에요. 보안이 필요한 데이터는 암호화(encryption) 또는 해시(hash) 가 필요합니다.

• 인코딩: 양방향. 알고리즘만 알면 누구든 원본 복원 가능. 목적은 데이터 호환성.
• 암호화: 양방향. 키가 필요. 목적은 데이터 보호.
• 해시: 단방향. 원본 복원 불가능. 목적은 데이터 검증·무결성.

비밀번호는 단방향 해시(bcrypt, Argon2)로 저장해야지 Base64나 암호화로 저장하면 안 됩니다.

자주 만나는 인코딩 실수

실무에서 자주 보는 인코딩 관련 실수 몇 가지예요.

• 이중 URL 인코딩: %20이 %2520이 되어 공백이 깨짐. 이미 인코딩된 값에 다시 encodeURIComponent를 호출.
• JSON에 그대로 이진 데이터: 이미지 바이너리는 JSON 문자열 안에 그대로 못 넣음. Base64 변환 필수.
• 텍스트 인코딩 혼동: UTF-8 파일을 EUC-KR로 열면 한글이 깨짐. 파일을 만들 때와 읽을 때 인코딩을 일치시켜야 함.
• Base64를 보안용으로 사용: 위에서 설명한 것처럼 디코딩이 너무 쉬움. 절대 보안 목적으로 쓰지 말 것.

도구로 빠르게 변환하기

툴박스의 인코딩 변환기는 Base64·URL·HTML 엔티티 등 주요 인코딩을 양방향으로 즉시 변환합니다. 인코딩된 값을 디코딩해서 원본을 확인하거나, 반대로 텍스트를 인코딩해 API에 넣어야 할 때 한 번에 처리할 수 있어요. 다만 위에서 강조한 것처럼 인코딩은 보안이 아니므로, 민감 정보를 다룰 때는 인코딩으로 끝내지 말고 적절한 암호화·해시를 같이 적용하세요.