[16장] 국제화

janjanee·2022년 8월 1일
HTTP 완벽가이드http국제화
0

[스터디] HTTP 완벽 가이드

목록 보기
13/14
post-thumbnail

2020.12.13 작성글 이전

16장 국제화

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

서버는 클라이언트에게 문서의 문자와 언어를 HTTP Content-Type charset 매개변수와
Content-Language 헤더를 통해 알려준다.

동시에, 클라이언트는 서버에게 사용자가 어떤 언어를 이해할 수 있고 어떤 알파벳의 코딩 알고리즘이
브라우저에 설치되어 있는지 말해줄 필요가 있다. Accept-Charset과 Accept-Language 헤더를 보낸다.

다음 예시는 모국어를 선호하지만 피치 못할 경우에는 영어도 사용하는 프랑스어 사용자가 보낸 것이다.
브라우저는 iso-8859-1 서유럽어 차셋 인코딩과 UTF-8 유니코드 차셋 인코딩을 지원한다.

Accept-Language: fr, en;q=0.8
Accept-Charset: iso-8859-1, utf-8

16.2 문자집합과 HTTP

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

각 차셋 태그는 비트들을 글자들로 변환하거나 혹은 그 반대의 일을 해주는 알고리즘을 명명한다.

Content-Type: text/html; charset=iso-8859-6

위의 예시는 수신자에게 콘텐츠가 HTML 파일임을 말해주고, charset 매개변수는 수신자에게 콘텐츠 비트들을
글자들로 디코딩하기 위해 iso-8859-6 아랍 문자집합 디코딩 기법을 사용하라고 말해준다.

16.2.2 문자집합과 인코딩은 어떻게 동작하는가

비트들을 문자로 변환하는 것은 두 단계에 걸쳐 일어난다.

  1. 특정 코딩된 문자집합의 특정문자(각각 번호가 매겨져있음)로 식별될 수 있는 문자 코드로 변환된다.

    ex) 데이터 비트: 11100001 -> 문자코드: 225

  2. 문자 코드는 코딩된 문자집합의 특정 요소를 선택하기 위해 사용된다.

    ex) iso-8859-6에서, 값 225는 'ARABIC LETTER FEH'에 해당

HTTP는 문자 데이터 및 그와 관련된 언어 차셋 라벨의 전송에만 관심을 갖는다.
글자의 모양을 어떻게 표현할 것인가는 사용자의 그래픽 디스플레이 소프트웨어(브라우저, 운영체제, 글꼴)가 결정한다.

16.2.3 잘못된 차셋은 잘못된 글자들을 낳는다

만약 클라이언트가 잘못된 charset 매개변수를 사용한다면, 클라이언트는 이상한 깨진 글자를 보여주게 될 것이다.
값 225는 각 charset에 따라 다르게 표현되기 때문이다.

16.2.4 표준화된 MIME 차셋 값

특정 문자 인코딩과 특정 코딩된 문자집합의 결합을 MIME 차셋이라고 부른다.
HTTP는 표준화된 MIME 차셋 태그를 Content-Type과 Accept-Charset 헤더에 사용한다.

p.432 MIME 차셋 인코딩 태그 표 참조

16.2.5 Content-Type charset 헤더와 META 태그

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

웹 서버는 클라이언트에게 MIME 차셋 태그를 charset 매개변수와 함께 Content-Type 헤더에 담아 보낸다.
만약 문자집합이 명시적으로 나열되지 않았다면, 수신자는 문서의 콘텐츠로부터 문자집합을 추측하려 시도한다.

16.2.6 Accept-Charset 헤더

Accpet-Charset 헤더의 값은 클라이언트가 지원하는 문자 인코딩의 목록을 제공한다.

Accept-Charset: iso-8859-1, utf-8

Accept-Charset 요청 헤더에 대응하는 Content-Charset 응답 헤더는 존재하지 않는다.
응답 문자집합은 MIME과의 호환을 위해 Content-Type 응답 헤더의 charset 매개변수를 통해 돌려받는다.

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

16.3.1 문자집합 용어

  • 문자

    알파벳, 글자, 숫자, 구두점, 표의문자(중국어에서와 같은), 기호 등 글쓰기의 최소 단위.

    약식으로 유니코드(Unicode)라 불리는 국제 문자 세트(Universal Character Set, UCS) 계획에 따라

    여러 언어의 글자에게 알맞고 유일한 이름을 부여하기 위한 표준화된 이름 집합이 개발되어 왔다.

  • 글리프(glyph)

    하나의 글자를 표현하기 위한, 획의 패턴이나 다른 것과 구분되는 유일한 시각적 형태.

  • 코딩된 문자(coded character)

    우리가 글자를 다룰 수 있도록 각 글자에 할당된 유일한 숫자

  • 코드 공간(coding space)

    문자 코드 값으로 사용하려고 계획해 둔 정수의 범위

  • 코드 너비(code width)

    각 문자 코드의 (고정된 크기의) 비트 개수

  • 사용 가능 문자집합(character repertoire)

    글자들에 대한 특정한 작업 집합(세상에 존재하는 모든 글자의 부분집합)

  • 코딩된 문자집합(coded character set)

    사용 가능 문자집합을 받아서 각 글자에 코드 공간의 코드를 할당해주는 코딩된 문자들의 집합.

    실제 글자들에 숫자로 된 문자 코드를 대응

  • 문자 인코딩 구조

    숫자로 된 문자 코드들을 콘텐츠 비트의 연속으로 인코딩하는 알고리즘. 문자 인코딩 구조는 글자를 식별하기 위해

    필요한 데이터의 양을 줄이거나, 전송상의 어떠한 제약을 회피하거나, 중복된 코딩된 문자집합들을 통합하는데 사용

16.3.2 '차셋(Charset)'은 형편없는 이름이다

MIME 차셋 태그는 문자집합을 의미하는 것이 결코 아니다. MIME 차셋 값은 데이터 비트를 고유한
문자의 코드로 매핑하는 알고리즘의 이름이다. 이것은 문자 인코딩 구조와 코딩된 문자집합의 개념을 합친 것이다.
표준 문서를 읽을 때는 정확히 무엇이 정의되어 있는지 알 수 있도록 주의해야 한다.

16.3.3 문자

문자는 글꼴이나 스타일에 독립적이다. 한 글자는 여러 가지 다른 쓰기 형태를 가질 수 있다.
또한 같은 글자라도 그 글자가 단어에서 어디에 위치하느냐에 따라 각각 다른 모양을 갖는 표기 체계도 많다.

16.3.4 글리프(glyphs), 연자(ligatures) 그리고 표현 형태

각 문자는 미적인 양식과 스크립트에 따라 여러 가지 글리프를 가진다.
쓰기를 보다 멋지게 보이도록 하기 위해, 많은 필기체와 활자체가 인접한 글자들이 부드럽게 이어지는 연자(ligature)를 지원한다.

일반적인 규칙은, 글리프 하나를 다른 것으로 바꾸었을 때 텍스트의 의미가 바뀐다면,
그 두 글리프들은 서로 다른 글자다. 아니라면 그것들은 모양만 다를 뿐 같은 글자이다.

16.3.5 코딩된 문자집합(Coded Character Set)

코딩된 문자집합은 보통 코드 번호로 인덱싱된 배열로 구현된다.
그 배열의 원소들은 문자들이다.

US-ASCII: 모든 문자집합의 어머니

아스키는 1968년 ANSI 표준 X3.4 '정보교환을 위한 미국 표준 코드'로 표준화된 가장 유명한 코딩된 문자집합이다.
아스키는 오직 코드 값 0-127만 사용한다.

따라서 코드 공간을 전체로 표현하는데 7비트만이 필요하다. HTTP 메시지(헤더, URI 등등)는 US-ASCII를 사용한다.

iso-8859

US-ASCII의 8비트 확대집합들이다.
추가 비트에 의해 제공되는 추가 공간은 모든 유럽 글자를 담기에는 충분히 크지 않으므로,
iso-8859는 지역에 따라 커스터마이징 된 문자집합을 제공한다.

iso-8559-1 : 서유럽어(예: 영어, 프랑스어)
iso-8559-2 : 중앙 및 동유럽어(예: 체코어, 폴란드어)
iso-8559-3 : 남유럽어
iso-8559-4 : 북유럽어
...

Latin1로도 알려진 iso-8559-1은, HTML을 위한 기본 문자집합이다. 대부분의 유럽어 텍스트를 표현하기 위해
사용될 수 있다.

UCS

국제 문자 세트(Universal Character Set, UCS)는 전 세계의 모든 글자를 하나의 코딩된 문자집합으로
통합하려 노력하는 세계적인 표준이다. UCS는 ISO 10646으로 정의된다.
유니코드는 UCS 표준을 따르는 상업적인 컨소시엄이다.

16.3.6 문자 인코딩 구조

문자 인코딩 구조들은 숫자로 된 문자 코드를 콘텐츠 비트들로 변환하고 다른 쪽에서는 그들을 다시 문자 코드로 환원한다.

고정폭

고정폭 인코딩은 각 코딩된 문자를 고정된 길이의 비트로 표현한다. 빠르게 처리될 수 있지만 공간을 낭비할 우려가 있다.

가변폭(비모달)

가변폭 인코딩은 다른 문자 코드 번호에 다른 길이의 비트를 사용한다. 자주 사용하는 글자의 비트 길이를
줄일 수 있고, 국제 문자에 대해서는 여러 바이트를 사용하도록 함으로써 이전의 8비트 문자집합과의 호환성도 유지할 수 있다.

가변폭(모달)

모달 인코딩은 다른 모드로의 전환을 위해 특별한 'escape' 패턴을 사용한다.
중첩된 여러 가지 문자집합 간의 전환을 위해 사용될 수 있다. 처리하기 복잡하지만, 복잡한 표기 체계를 효과적으로 지원한다.

다음은 몇 가지 인코딩 구조이다.

8비트

  • 8비트 고정폭 아이덴티티 인코딩은 간단히 각 문자 코드를 그에 대응하는 8비트 값으로 인코딩한다.
  • 256개 문자의 코드 범위에 대한 문자집합만을 지원한다.
  • iso-8859 문자집합군은 8비트 아이덴티티 인코딩을 사용한다.

UTF-8

  • UTF-8은 문자 코드의 값을 위해 비모달 가변길이 인코딩을 사용한다.
  • 첫 바이트의 선두 비트들은 인코딩된 문자의 길이를 바이트 단위로 나타내고, 그 이후의 바이트들은 각각 6비트의 코드 값을 담는다.
  • 아스키와의 호환성이 확보된다.

euc-kr

  • 한글 인터넷 문서를 위해 널리 사용되는 가변길이 인코딩
  • KS X 1003과 KS X 1001 두 가지 문자 집합을 지원

16.4 언어 태그와 HTTP

영어(en), 독일어(de), 한국어(ko) 등 언어에 대한 태그가 존재한다.
언어 태그는 브라질 포르투갈어(pt-BR), 미국 영어(en-US) 등과 같이 지역에 따라 변형된 언어나 방언도 표현 가능하다.

16.4.1 Content-Language 헤더

엔터티가 어떤 언어 사용자를 대상으로 하는지 서술한다.
주로 프랑스어 사용자를 대상으로 하고 있다면, Content-Language 헤더 필드는 다음을 포함할 것이다.

Content-Language: fr

이 헤더는 텍스트 문서만을 위한 것은 아니다. 오디오 클립, 동영상, 애플리케이션 특정 언어 사용자를 대상으로 할 수 있다.
콘텐츠가 여러 언어 사용자를 대상으로 하고 있다면, 여러 언어를 나열할 수 있다.

16.4.2 Accept-Language 헤더

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

한국어로 된 콘텐츠에 대한 클라이언트 요청은 다음과 같다.

Accept-Language: ko

16.4.3 언어 태그의 종류

  • 일반적인 언어의 종류(한국어 'ko')
  • 특정 국가의 언어(영국 영어를 의미하는 'en-GB')
  • 방언(노르웨이어의 'Book Language'를 의미하는 'no-bok')
  • 지방어(마서스 비니어드 섬의 수화를 의미하는 'sgn-US-MA')
  • 그 외의 다른 언어의 변형이 아닌 표준 언어('i-navajo')
  • 비표준 언어('x-snowboarder-slang')

16.4.4 서브태그

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

  • 첫 번째 서브태그는 주 서브태그라 불린다. 이 값들은 표준화되어있음.
  • 두 번째 서브태그는 선택적이고 자신만의 이름 표준을 따른다.
  • 세 번째부터의 서브 태그는 등록되어 있지 않다.

주 서브태그는 오직 A부터 Z까지의 글자만을 포함한다. 다음 서브태그는 알파벳이나 숫자를 포함할 수 있으며,
최대 8자까지 가능하다.

16.4.5 대소문자의 구분 및 표현

모든 태그는 대소문자가 구분되지 않는다. 태그 'en'과 'eN'은 같다.
관용적으로 언어를 나타낼 때는 소문자를 사용하고, 국가를 나타낼 때는 대문자를 사용한다.

16.4.6 IANA 언어 태그 등록

첫 번째와 두 번째 언어 서브태그의 값은 여러 가지 표준 문서와 그것들을 관리하는 조직에 의해서 정의된다.
IANA는 RFC 3066의 규칙에 따라 표준 언어 태그의 목록을 관리한다.

16.4.7 첫 번째 서브태그: 이름공간

첫 번째 서브태그는 보통 ISO 639 표준 언어 집합에서 선택된 표준화된 언어 토큰이다.

첫 번째 서브태그가,

  • 두 글자라면, ISO 639와 639-1 표준의 언어코드
  • 세 글자라면, ISO 639-2 표준과 확장에 열거된 언어코드
  • 글자 i 라면, 이 언어 태그는 틀림없이 IANA에 등록된 것
  • 글자 x 라면, 이 언어 태그는 특정 개인이나 집단 전용의 비표준 확장 서브태그

16.4.8 두 번째 서브태그: 이름공간

ISO 3166 국가 코드와 지역 표준 집합에서 선택된 표준화된 국가 토큰이다.

두 번째 서브태그는,

  • 두 글자라면, ISO 3166에 정의된 국가/지역
  • 3~8 글자라면, IANA에 등록된 것
  • 한 글자라면, 뭔가 잘못된 것

16.4.9 나머지 서브태그: 이름공간

세 번째와 그 이후의 서브태그에 대해서는, 8자 이하의 알파벳과 숫자로 이루어져야 한다는 것을 제외하면 규칙이 없다.

16.5 국제화된 URI

URI는 US-ASCII의 부분집합으로 구성되어 있었다. 오늘날 URI에 대한 최신 명세인 RFC 3986은
URI에 UTF-8 문자를 사용할 수 있는 방법을 명시적으로 제시하고 있으므로, 다양한 문자들을 문제 없이 사용할 수 있다.

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

URI 설계자들은 두 가지 목표가 있었다.

  • 전 세계의 모두가 URI를 다른 이들과 공유
  • URI가 사용하기 쉽고 기억하기 쉽길 바람

그러나 이 두 목표는 서로 충돌한다. URI 저자들은 가독성과 공유 가능성의 보장이 더 중요하다
판단하였고, 그래서 ASCII 문자들로 이루어진 URI를 갖게되었다.

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

URI에서 사용할 수 있는 ASCII 문자들의 부분집합은 아래와 같이 나뉜다.

  • 예약되지 않음

    URI의 어떤 구성요소에서든 일반적으로 사용가능

  • 예약됨

    ; / ? : @ & = + $ ,

  • 이스케이프

    %

16.5.3 이스케이핑과 역이스케이핑(unescaping)

이스케이프는 퍼센트 글자(%) 하나와 뒤이은 16진수 글자 둘로 이루어진 세 글자 문자열이다.

  • URL에 스페이스(아스키 32)를 삽입하려면, 이스케이프 '%20'을 사용한다.
  • HTTP 애플리케이션은 URI를 데이터가 필요할 때만 언이스케이핑 해야한다.

16.6 기타 고려사항

16.6.1 헤더와 명세에 맞지 않는 데이터

  • HTTP 헤더는 반드시 US-ASCII 문자집합의 글자들로만 이루어져야 한다.

HTTP 메시지를 처리하기 위해 문자 구분 라이브러리를 사용하기 전에, 메시지에 잘못된 데이터가
포함되어 있을 경우를 대비해 그 라이브러리의 문서를 주의 깊게 읽자.

16.6.2 날짜

  • HTTP 명세는 GMT 날짜 형식을 명확히 정의하고 있지만 모든 웹 서버와 클라이언트가 규칙을 따르지 않음을 주의

16.6.3 도메인 이름

  • 국제화 문자를 포함하는 도메인 이름을 국제화 도메인 이름(Internationalizing Domain Name) 이라고 한다.
  • 오늘날 대부분의 웹브라우저가 퓨니코드(punycode)를 이용해 이를 지원
  • 퓨니코드 -> 유니코드 문자열을 호스트 명에서 사용 가능한 문자만으로 이루어진 문자열로 변환 (RFC 3492)
  • 예를들어 한글.com -> xn--bj0bj06e.com 으로 변환
profile
janjanee
얍얍 개발 펀치
이전 포스트

[14장] 보안 HTTP

다음 포스트

[17장] 내용 협상과 트랜스코딩

0개의 댓글