[스프링부트] 39. UTF-8, Base64, Json

백하림

May 15, 2025

💡

왜 베이스64를 사용했는가 ?

Base64 인코딩을 통해 이미지를 텍스트 문자열로 변환하여 JSON 데이터 내에 안전하게 담을 수 있음

아스키코드도 할 수 있는데 왜 안 했는지 ?

아스키코드는 0부터 127까지 밖에 표현 할 수 없기 때문에, 바이너리 데이터의 모든 가능한 값을 ASCII 문자로 일대일 대응시킬 수 없음

아스키코드 표

베이스64 표

💡

UTF-8 (조합형)

유니코드에서 만든 전세계 공통 문자 인코딩 방식

1~4Byte 가변 크기 (영어 1Byte, 한글 3Byte, 이모지 4Byte)

MySQL에서 설계한 UTF-8은 3Byte만 허용

이후에 UTF-8mb4를 다시 설계하여 도입. 4Byte까지 허용

💡

Base64

Json에 이미지를 포함시키려고 (데이터 한 방 전송)

Json에 Byte를 포함할 수 없다.

이미지 → 문자 (255 값 → 아스키코드에서 못 찾음)

6bit씩 잘라서 Base64표에서 문자를 찾아냄

그 문자를 다시 아스키코드에서 찾아냄

비효율적으로 보이지만 안전함.

결국 전송은 8bit로 한다. (Byte Stream)

💡

전자서명

양방향(Encoding, Decoding), 단방향(Encoding)

양방향 방식 (대칭키, 공개키)

단방향 방식 (해시 → 서명할 때)

1234 → 5A3D (해시) → 전자서명 → O

1234 → 38A7(대칭키) → 1234 → O

1234 → 89P5(상대방 공개키) → 암호화 → X → 누구나 공개키로 잠글 수 있다.

1234 → 89P5(나의 개인키) → 전자서명 → O

로그인

토큰생성

SHA 256

ID : 1 해시(SHA256-ID:1-Metacoding) → 98AB3

JWT 완성

(SHA256).(ID:1).(98AB3)

클라이언트가 토큰을 가지고 인증이 필요한 API 요청

(SHA256).(ID:1) + 시크릿 이걸로 해시

(98AB3)과 동일한지 검증

💡

ㄱ ㄴ ㄷ 은 1~2바이트

이유 : 자음이나 모음 단독으로 쓰이는 글자는 완성된 음절보다 작은 코드 포인트 값을 가짐.

가 나 다 는 3바이트

이유 : 자음과 모음이 결합하여 하나의 완전한 음절을 이루는 글자는 UTF-8에서 3바이트 차지.

스프링부트