[4부 16장] 국제화 #15
Description
HTTP는 여러 언어와 문자로 된 국제 문서들의 처리 및 전송을 지원해야한다.
국제화 관련 헤더
서버 -> 클라이언트: 각 문서의 문자와 언어를 알려준다.
Content-Type charset 파라미터, Content-Language(요청 & 응답 헤더 모두에 사용)
클라이언트 -> 서버: 클라이언트가 어떤 Charset 인코딩 알고리즘과 언어를 이해하는지(선호하는지) 알려준다.
Accept-Charset, Accept-Language
Content-Type: text/html; charset=UTF-8
Content-Language: en-US
Accept-Langague: fr, en;q=0.8 //q는 품질 인자. 프랑스어는 1.0, 영어는 0.8으로 프랑스어에 우선순위가 있다.
Accept-Charset: iso-8859-1, utf-8
+👀) Content-Language VS. Accept-Lanague
https://stackoverflow.com/questions/6157485/what-are-content-language-and-accept-language
문자집합과 HTTP
Charset
- entity 콘텐츠 비트들을 특정 문자 체계의 글자로 바꾸는 법(알고리즘)을 나타낸다.
- 글자 당 비트 수가 일정하지 않은 문자 인코딩도 있다. (UTF-8, iso-2022-jp)
문자집합과 인코딩의 동작
- 비트 -> 특정 문자로 식별될 수 있는 문자코드로 변환
- 문자코드 -> 코딩된 문자집합의 특정 요소를 선택
MIME Charset
- 특정 문자 인코딩과 특정 코딩된 문자 집합의 결합
- HTTP는 표준화된 MIME Charset 태그를 Content-Type, Accept-Charset 헤더에 사용
- 예시) us-ascii, iso-8859-1, utf-8
웹 서버는 Content-Type 헤더에서 Charset 매개변수를 찾거나, 콘텐츠에서 문자집합을 추측한다(HTML의 태그 등. 추측 못하면 ios-8859-1 가정)
다중 언어 문자 인코딩에 대한 지침
문자
- 알파벳 글자, 숫자, 구두점, 표의문자, 기호 등 글쓰기의 최소 단위
- 글꼴이나 스타일에 독립적 (같은 글자라도 단어에서 어디에 위치하느냐에 따라 다른 모양을 가질 수도 있다)
글리프
- 각 글자를 그리는 특정한 방법
- 글리프 하나를 다른 것으로 바꾸었을 때 텍스트의 의미가 변하면 두 글리프는 서로 다른 글자
코딩된 문자
- 각 글자에 할당된 유일한 숫자
US-ASCII: 코드 값 0-127만 사용 (코드 공간 전체를 7비트로 표현, HTTP 메세지(헤더, URI)가 사용)
iso-8859:
국제적인 글쓰기를 위해 필요한 글자들을 하이 비트로 추가한, US-ASCII의 8비트 확대 집합들
지역에 따라 문자집합을 제공 (iso-8859-1: 서유럽어(HTML을 위한 기본 문자집합), iso-8859-2: 중앙/동유럽어 등)
USC(Unicode):
국제 문자 세트로 전 세계 글자를 하나의 코딩된 문자집합으로 통합하기 위해 만들어진 표준
코드 공간
- 문자 값으로 사용하려고 계획해 둔 정수의 범위
코드 너비
- 각 문자 코드의 고정된 크기의 비트 개수
사용 가능 문자 집합
- 글자들에 대한 특정한 작업 집합 (글자의 부분집합을 의미하는 듯?)
(https://dev.mysql.com/doc/refman/5.7/en/charset-repertoire.html)
코딩된 문자집합
- 위의 사용 가능 문자집합을 받아서 각 글자에 코드 공간의 코드를 할당해주는 코딩된 문자의 집합 (실제 글자 -> 숫자로 된 문자 코드 대응)
문자 인코딩 구조
- 문자 인코딩: 숫자로 된 문자 코드들을 콘텐츠 비트의 연속으로 인코딩하는 알고리즘
종류
-
고정폭
각 코딩된 문자들을 고정된 길이의 비트로 표현
예시) 8비트: 각 문자 코드를 대응하는 8비트 값으로 인코딩(iso-8859 에서 사용) -
가변폭(비모달)
다른 문자 코드 번호에 다른 길이의 비트를 이용
- 사용 빈도가 높은 글자는 적은 저장 공간을 차지하고 사용 빈도가 낮은 글자는 많은 저장 공간을 차지하게 하려고 만든 인코딩 방식.
- 가변폭(모달)
- 다른 모드로의 전환을 위해 escape 패턴을 사용.
- 뭔지 잘 모르겠음...
+👀) UTF-8 / EUC-KR
UTF-8
가변폭 문자 인코딩
인코딩 과정
+) 왜 prefix로 '10'을 사용할까?
https://stackoverflow.com/questions/53009692/utf-8-encoding-why-prefix-10
- self-synchronization, 읽는 사람이 어디서부터 어디까지가 한 문자를 나타내는지 알기 쉽다. 시작 문자와 이어지는 문자를 구분하기 쉽고, 전송 오류를 발견할 수 있다.
EUC-KR
- 한글을 2바이트로 표기. 완성형 (https://uic.io/ko/charset/show/euc-kr/)
- euc-kr은 모든 한글을 포함하지는 않아서, 보완해서 마이크로소프트에서 만든것이 CP949
+👀) 간단한 인코딩 역사 변화
CP 문자셋(2바이트)는 자국에서만 쓸 수 있고, 다른 나라와 호환이 되지 않는다.
그래서 모든 언어를 나타내기 위해 유니코드 만듦.
유니코드 인코딩하기 위해 UTF-16이라는 가변 길이 인코딩을 썼는데, 기본 다국어 평면(https://ko.wikipedia.org/wiki/%EC%9C%A0%EB%8B%88%EC%BD%94%EB%93%9C_%ED%8F%89%EB%A9%B4#%EA%B8%B0%EB%B3%B8_%EB%8B%A4%EA%B5%AD%EC%96%B4_%ED%8F%89%EB%A9%B4)에 속하는 문자는 2바이트, 다른 건 4바이트로 인코딩.
기존에 1바이트로 문자를 나타낼 수 있던 미국/유럽권에서는 용량이 2배로 늘어난셈.
그래서 UTF-8 등장. 유럽권은 기존 1바이트, 나머지는 2,3,4 바이트로 (한국어는 3바이트)
언어 태그와 HTTP
언어 태그: 언어에 이름을 붙이기 위한 표준화된 문자열
하이픈으로 분리된 하나 이상의 서브태그로 이루어져 있다. 언어는 소문자, 국가는 대문자를 관용적으로 쓰지만 모든 태그는 대소문자 구분이 없다.
(한국 ko-KR, 미국 en-US)
Content-Language 헤더
엔티티가 어떤 언어 사용자를 대상으로 하는지
Accept-Language 헤더
클라이언트가 웹 서버에게 언어 제약/선호도를 전달하기 위해 사용
국제화된 URI
조작하고, 공유하기 쉽게 하기 위하여 URI 설계자들은 매우 제한된 공통 문자집합을 선택했다(기본적인 라틴 알파벳 문자, 숫자, 특수문자)
URI에서 사용할 수 있는 US-ASCII 문자들의 부분집합:
예약된 문자들은 URI에서 특별한 의미를 가지며, 일반적으로는 사용될 수 없다.
예약되지 않은 문자: [A-Za-z0-9] - _ . ! ~ * ' ( )
예약된 문자: ; / ? : @ & = + $ ,
이스케이프: % <HEX> <HEX>
+👀)
브라우저 URL에 한글이 들어갈 때
실제로 URL이 인코딩된 결과
https://search.naver.com/search.naver?where=nexearch&sm=top_hty&fbm=1&ie=utf8&query=%EA%B0%80
가 => %EA%B0%80