[4부 16장] 국제화 - Githubissues

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)

문자집합과 인코딩의 동작

1) 비트 -> 특정 문자로 식별될 수 있는 문자코드로 변환 2) 문자코드 -> 코딩된 문자집합의 특정 요소를 선택

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)

코딩된 문자집합

위의 사용 가능 문자집합을 받아서 각 글자에 코드 공간의 코드를 할당해주는 코딩된 문자의 집합 (실제 글자 -> 숫자로 된 문자 코드 대응)

문자 인코딩 구조

문자 인코딩: 숫자로 된 문자 코드들을 콘텐츠 비트의 연속으로 인코딩하는 알고리즘
종류

1) 고정폭 각 코딩된 문자들을 고정된 길이의 비트로 표현 예시) 8비트: 각 문자 코드를 대응하는 8비트 값으로 인코딩(iso-8859 에서 사용)

2) 가변폭(비모달) 다른 문자 코드 번호에 다른 길이의 비트를 이용

사용 빈도가 높은 글자는 적은 저장 공간을 차지하고 사용 빈도가 낮은 글자는 많은 저장 공간을 차지하게 하려고 만든 인코딩 방식.

3) 가변폭(모달)

다른 모드로의 전환을 위해 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

Effective-Java-Camp / http-the-definitive-guide

[4부 16장] 국제화 #15