16. Internationalization

16장: 국제화

매일 수십억의 사람들이 수백가지의 언어로 문서를 작성한다. 
WWW의 진정한 비전에 부응하기 위해 HTTP는 여러 언어와 문자로된 국제 문서들의 처리 및 전송을 지원해야한다.

[2가지 주요 국제화 이슈]
- 문자 집합 인코딩: 여러 언어의 문자로 텍스트를 보여주고 요청하기 위해 사용.
- 언어 태그: 사용자가 이해할 수 있는 언어만으로 콘텐츠를 서술하기 위해 사용.

[etc]
- 여러 언어로 된 URI와 날짜에 대하여

1) 국제적인 콘텐츠를 다루기 위해 필요한 HTTP 지원

• HTTP 메시지는 이미지, 영화 또는 다른 종류의 미디어를 전달할 수 있는 것 처럼,

  모든 언어로 콘텐츠를 전달할 수 있다.

• HTTP에서 엔터티 본문은 비트들로 가득찬 상자에 불과하다.

• 국제 컨텐츠를 지원하기 위해 서버는 클라이언트에게 각 문서의 문자와 언어를 알려줘서

  클라이언트가 올바르게 문서를 이루고 있는 비트들을 문자들로 풀어내고,

  올바르게 처리해서 사용자에게 콘텐츠를 제공해줄 수 있도록 할 필요가 있다.

• 서버는 클라이언트에게 문서의 문자와 언어를 HTTP **Content-Type charse 매개변수**와,

  **Conent-Language 헤더**를 통해서 알려준다. 이 헤더들은 엔터티본문에 아래 3가지를 서술한다.

  • 무엇이 들어있는지

  • 어떻게 콘텐츠를 화면에 출력된 올바른 글자들로 바꾸는지

  • 그 텍스트가 어떤 언어에 해당하는지

• 동시에 클라이언트는 서버에게 사용자가 이해하는 언어 및 브라우저에 설치된 알파벳 코딩 알고리즘을 알려줄 필요가 있다.

  • Accept-Charset

  • Accept-Language

    ```markdown [헤더 사용 예시] Accept-Language: fr, en;q=0.8 Accept-Charset: iso-8859-1, utf-8

    [설명]

  • q 는 기본값이 1.0, 따라서 프랑스의 우선순위가 영어보다 높다.

  • 서유럽어(iso-8859-1) 차셋 인코딩과 UTF-8 유니코드 차셋 인코딩을 지원한다.

    ```

2) 문자집합(charset) 과 HTTP

① 차셋(charset)은 글자를 비트로 변환하는 인코딩이다.

• HTTP charset 값은 어떻게 엔터티 콘텐츠 비트들을 특정 문자 체계의 글자들로 바꾸는지 말해준다.

• 각 charset 태그는

  비트들을 글자로 변환하거나(디코딩)

  혹은 그 반대의 일을 해주는 알고리즘(인코딩)을 명명한다.

• charset 태그는 등록된 MIME 문자집합에 표준화되어있고, IANA가 관리: 링크

• 예 charset=iso-8859-6 : 수신자에게 비트들을 글자들로 디코딩하기 위해 iso-8859-6 (아랍 문자 집합) 디코딩 기법을 사용하라고 말해준다. 8bit 값(2^8=256개의 유일한 값 제공) 을 숫자와 구두점 그리고 다른 기호들을 포함한 라틴문자와 아랍문자로 매핑.

• 몇몇 문자 인코딩(UTF-8, iso-2022-jp )은 글자당 비트 수가 일정하지 않아 더 복잡한 가변길이 코드다.

• 중국어, 일본어와 같이 많은 글자들로 이루어진 문자체계를 지원하기 위해 추가적인 비트를 사용 가능케 한다.

② 문자 집합(character sets) 와 인코딩 동작방식

• 문서를 이루는 비트들을 화면에 보여줄 수 있는 글자들로 변하기를 원한다.

• 세상에는 여러종류의 문자가 있고,

  글자를 비트로 인코딩하는 여러 다른 방법(제각기 장단점을 가진)이 있기 때문에,

  비트들을 문자로 변환하는 디코딩 알고리즘을 지칭하고 적용하는 표준화된 방법이 필요하다.

• 비트를 문자열로 변환하는 2가지 단계 (MIME charset tag를 통해 결정)

  • 문서를 이루는 비트들은 '문자코드'로 변환된다.(⇒ 인코딩 구조를 사용해서 디코딩한다.)

    [문자코드: 특정 charset에서 특정 번호가 지정된, 문자를 식별하는 코드 예: 255]

  • '문자코드(예255)'는 코딩된 문자집합의 특정요소를 선택하기 위해 사용된다.

    [iso-8859-6에서 255는 'ARABIC LETTER FEH'를 의미한다.]

• HTTP의 '문자집합'은 인코딩구조와 코딩된 문자집합을 결합한 것을 뜻한다.

• 국제화된 문자 시스템의 핵심목표는 표현(시각적 표현방식)에서 의미(글자들)을 분리하는 것.

  따라서 HTTP는 문자 데이터 및 그와 관련된 언어와 차셋 라벨의 전송에만 관심을 둔다.

• 글자의 모양을 어떻게 표현할 것인가하는 건 사용자의 브라우저,운영체제, 글꼴이 결정한다.

③ 잘못된 차셋은 잘못된 글자를 낳는다.

만약 클라이언트가 잘못된 charset 매개변수를 사용한다면 클라이언트는 이상한 깨진 글자를 보여주게된다.

④표준화된 MIME 차셋값

• 특정 문자 인코딩과특정 코딩된 문자집합의 결합을 MIME 차셋이라고 부른다.

• HTTP는 표준화된 MIME 차셋 태그를 Content-Type과 Accept-Charset 헤더에 사용한다.

• 문서와 브라우저에 의해 사용되는 MIME 차셋 인코딩 구조(p.432참조)

  • 한글 문자 집합 및 인코딩 참조: http://forensic-proof.com/archives/615

  • cahracter set(euc-kr, utf8)에 대해 알아보자: 참조링크

    ```markdown

  • 컴퓨터는 알파벳권에서 처음 만들어졌고, 알파벳만 표시하면 됬었다.

  • 알파벳은 모든 문자를 포함해도 52(대소문자 포함)개 밖에 안된다.

  • 1byte(8bit, 2^8 = 256가지)로 모두 표현이 가능했다. (ASCII)

  • 각 나라별로 문자세트들이 생겼고, 한국의 경우에 euc-kr을 사용했다.

  • 다만 다른 나라들과 호환이 되지 않는 문제가 발생했고, 호환되는 것을 만들자는 취지로 유니코드를 만듬

  • 처음 고안된건 utf-16 (가변길이 인코딩)이었으나, 영어권에서는 용량을 2배나 증가시키는 것이 된다.

  • 그래서 기존 유럽권은 1byte를 표현하고 경우에따라 2~4byte로 표현가능한 유니코드(utf-8) 채택.

    (또한, 전송에 합리적인 방식이기 때문에 채택되었다.)

    ```

⑤ Content-Type charset 헤더와 Meta 태그

예시

Content-Type: text/html; charset=iso-2022-kr

• 웹 서버는 클라이언트에게 MIME 차셋태그를 charset 매개변수와 함께 Content-Type 헤더에 담아 보낸다.

• 만약 문자집합(charset) 이 명시적이지 않으면, 수신자는 문서의 콘텐츠로부터 charset을 추측 하려한다.

• 만약 클라이언트가 문자인코딩을 추측하지 못한 경우,

  iso-8859-1 로 가정(=서유럽 문자 시스템, ascii확장)

⑥Accept-Charset 헤더

• HTTP 클라이언트는 서버에게 정확히 어떤 문자체계를 지원하는지 Accept-Charset 헤더로 알린다.

• 클라이언트가 지원하는 문자 인코딩의 목록을 제공한다.

• 문자 인코딩 구조중 어떤 것으로 콘텐츠를 반환할지는 서버의 자유.

• 주의: Accept-Charset 요청 헤더에 대응하는 Content-Charset 은 없다!! (단, Content-Type 의 charset 매개변수를 통해 서버로부터 돌려받고, 대칭적이진 않지만 필요한 정보는 제공한다.)

3) 다중 언어 문자 인코딩에 대한 지침

① 문자집합 용어

• Character(문자): 글쓰기의 최소단위. (알파벳 글자, 숫자, 구두점, 기호, 표의문자 등)

• Glyph(글리프, 자체(字體)): 글씨 서체 (하나의 글씨에 대한 유일한 시각적 형태)

• Coded character(코딩된 문자): 글자를 다룰수 있도록 글자에 할당된 유일한 숫자.

• Coding Space(코드 공간): 문자 코드 값으로 사용하려고 계획해둔 정수 범위.

• Code width(코드 너비): 각 문자 코드의 (고정된 크기의) 비트 갯수

• Character repertoire(사용가능한 문자집합): 세상에 존재하는 모든 글자의 부분집합

• Coded character set(코딩된 문자집합): 실제 글자들에 숫자로된 문자코드를 대응시킨 것

  • US-ASCII: 정보교환을 위한 미국 표준 코드.(ascii code 값은 오직 0-127만 사용).

    따라서, 코드 공간 전체를 표현하는데 7bit만 필요.

  • iso-8859: 국제적인 글쑤기를 위해 필요한 글자들을 추가한 US-ASCII의 8bit 확대집합.

• Character encoding scheme(문자 인코딩 구조): 숫자로 된 문자 코드들을 콘텐츠 비트의 연속으로 인코딩하고, 원래대로 디코딩하는 알고리즘.

  • Fixed width(고정폭)

    • 각 코딩된 문자를 고정된 길이의 비트로 표현한다. 빠르게 처리 가능하나, 공간 낭비 발생 가능.

  • Variable width(non modal) (가변폭(비모달))

    • 다른 문자 코드 번호에 다른 길이의 비트를 사용한다.

    • 자주 사용하는 글자의 비트길이를 줄이고, 국제 문자에 대해 여러 바이트를 사용함으로써 이전 8bit 문자집합과의 호환성도 유지가능하다.

  • Variable width(modal) (가변폭(모달))

    • 다른 모드로의 전환을 위해 특별한 'escape' 패턴을 사용한다.

② 몇가지 인코딩 구조

• 8bit

  • 8비트 고정폭 아이덴티티 인코딩은 간단히 각 문자 코드를 그에 대응하는 8bit 값으로 인코딩한다.

  • 256개 문자의 코드 범위에 대한 문자집합만을 지원한다.

  • iso-8859 문자 집합군은 8 비트 아이덴티티 인코딩을 사용한다.

• UTF-8

  • 비모달 가변길이 인코딩을 사용.

  • 첫 바이트(=하이비트)의 선두 비트들은 인코딩된 문자의 길이를 바이트단위로 나타내고

  • 이후의 바이트들은 각각 6비트의 코드값을 담는다.

  • 아스키와의 호환성이 확보된다. iso-8859 와 호환되는건 아님.

• euc-kr

  • euc: extended unix code의 약자로, 유닉스 운영체제에서 아시아 문자들을 지원하기위해 개발되어짐.(가변폭, 비모달) 모드간의 전환을 위한 이스케이프 문자열이 존재하지 않는다.

  • KSX1003, KSX1001 두가지 문자집합 지원한다.

4) 언어 태그와 HTTP

• 언어태그란, 언어에 이름을 붙이기 위한 짧고 표준화된 문자열이다.

• 영어(en), 독일어(de), 한국어(ko), 그리고 많은 다른 언어에 대한 언어 태그가 존재한다.

• 지역에 따라 변형된 언어나 방언을 표현할 수도 있다.

① Content-Language 헤더

• 엔터티가 어떤 언어 사용자를 대상으로 하고 있는지 서술한다. (서버 ⇒ 클라이언트)

• 주로 프랑스어 사용자 대상일 경우 : Content-Language: fr

• Content-Language 헤더는 텍스트 문서만을 위한게 아니다.

• 오디오 클립, 동영상, 애플리케이션도 특정 언어 사용자를 대상으로 할 수 있다.

• 만약 콘텐츠가 여러 언어 사용자를 대상으로 한다면 여러 언어를 나열할 수 있다.

• 한국어, 영어가 모두 사용되는 경우?: Content-Language: ko, en

• 단, 여러 언어가 하나의 엔터티에 동시 사용되었다 해서 여러 언어 사용자들을 대상으로 하는 의미는 아니다.

② Accept-Language 헤더

• HTTP는 언어제약과 선호도를 웹서버에 전달할 수 있게 해준다.

• 만약 웹 서버가 어떤 자원에 대해 여러 언어로 된 버전을 가지고 있다면, 웹 서버는 우리가 선호하는 언어로 된 콘텐츠를 줄 수 있다.

• 또한, 사용자의 언어로 된 동적 콘텐츠를 생성하거나, 이미지를 선택하거나, 대상 언어에 맞는 상품 광고를 보여주기 위해 Accept-Language 헤더의 값을 읽을 수 있다.

③ 언어 태그의 종류 ([RFC 3066] 기준)

• 언어태그는 다음을 표현하기 위해 사용될 수 있다.

  • 일반적인 언어의 종류 ex_es (스페인어)

  • 특정 국가의 언어 ex_en-GB (영국 영어)

  • 방언 ex_no-bok (노르웨이어의 Book Language를 의미)

  • 지방어 ex_sgn-US-MA (마서스 비니어드 섬의 수화)

  • 그외의 다른 언어의 변형이 아닌 표준언어 (ex_i-navajo)

  • 비표준 언어 ex_x-snowboarder-slang (스노우보드 타는 사람..)

④ 서브태그

• 언어 태그는 하이픈으로 분리된 하나 이상의 서브태그로 이루어져 있다.

[예시]

sgn-US-MA

1. 주 서브태그(sgn) : 표준화되어 있다. - 알파벳만

   1. sgn(sign language): 수화

   2. 표준 언어 집합에서 선택된 표준화된 언어 토큰

   3. 두글자의 경우(ISO639, 639-1 표준 언어코드)

   4. 세글자의 경우(ISO 639-2 표준과 확장)

   5. 글자 'i' 이면 IANA에 등록된것. 글자 'x'면 특정 개인이나 집단 전용의 비표준확장 서브태그

2. 두번째 서브태그(US): 자신만의 이름 표준을 따름 (선택적) - 알파벳 + 숫자가능 (최대 8글자)

   1. US: united state

   2. 보통 ISO3166 국가 코드와 지역 표준집합에서 선택된 표준화된 국가 토큰

   3. 두글자면 ISO3166에 정의된 국가/지역

   4. 3~8글자면 IANA에 등록된것

   5. 한글자면 뭔가 잘못된거

3. 세번째 서브태그(MA)는 등록되어 있지 않다.

   1. 8자 이하의 알파벳과 숫자로 이뤄져야한다는것 외에 정해진 규칙은 없음.

⑤ 대소문자 구분 및 표현

• 모든 태그는 대소문자가 구분되지 않는다. (fr=FR=Fr=fR)

• 관용적으로 언어를 의미할때는 소문자(fr), 국가를 나타낼때는 (FR)

⑥ 선호 언어 설정

• 웹 브라우저 프로필에서 선호 언어를 설정할 수 있다.

5) 국제화된 URI

• 오늘날 URI에 대한 최신명세(RFC 3986, 책 쓰여진시점)는 URI에 UTF-8 문자를 사용할 수 있는 방법을 명시적으로 제시하고 있으므로, 다양한 문자들을 별 문제 없이 사용할 수 있다. URI가 국제적으로 지원되지 않았을 때에는 US-ASCII의 부분집합으로 URI를 구성했다.

① 국제적 가독성 vs 의미 있는 문자들

• URI 설계자의 목표

  • 전세계의 모두가 URI를 통해 다른이들과 공유할 수 있기를 원함.

  • URI가 사용하기 쉽고 기억하기 쉽길 바람

• 이 2가지 목표는 서로 충돌한다.

• URI 저자들은 리소스 십결자의 가독성과, 공유가능성의 보장이 대부분의 의미있는 문자들로 구성될 수 있도록 하는것 보다 더 중요하다고 여겼다.

② URI 에서 사용될 수 있는 문자들

01

③ 이스케이핑과 역이스케이핑

• URI 이스케이프는 예약된 문자나 다른 지원하지 않는 글자들을 안전하게 URI에 삽입할 수 있는 방법을 제공한다.

• 이스케이프는 % 하나와 뒤이은 16진수 글자 2개로 이루어진 세글자 문자열이다.

• 16진수 2개의 글자는 US-ASCII문자의 코드를 나타낸다.

• 예

  • 공백(스페이스, 아스키32)를 삽입하고 싶을 때 이스케이프 '%20' 을 사용할 수 있다.

• 내부적으로 HTTP 애플리케이션은 URI를 데이터가 필요로할때만 언이스케이핑 해야한다.

• 또한 애플리케이션은 어떤 URI도 결코 두번 언이스케이핑 되지 않도록해야한다.

  이스케이핑된 퍼센트기호를 포함한 URI를 언이스케이핑하면 퍼센트기호가 포함된 URI 가 만들어지는데, 여기서 잘못해서 한번 더 언이스케이핑하면 퍼센트 기호 뒤에 문자들이 이스케이프의 일부인것처럼 처리되면서 데이터 손실이 유발될 수 있다.

④ 국제 문자 이스케이핑

• 이스케이프값은 US-ASCII코드범위(0-127)에 있어야만 한다.