FE/BOOK

[HTTP 완벽가이드] 16장 국제화

<zinny/> 2025. 2. 5. 20:35
728x90

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

HTTP 메시지는 어떤 언어로된 콘텐츠, 이미지, 동영상 혹은 그외 다른 종류의 미디어를 상자처럼 실어 나를 수 있어, HTTP에서 엔터티 본문이란 그저 비트들로 가득 찬 상자에 불과하다. 

 

국제 콘텐츠를 지원하기 위해, 서버는 클라이언트에게 각 문서의 문자와 언어를 알려주어, 클라이언트가 올바르게 풀어내고, 처리해서 제공하도록 할 필요가 있다. 

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

클라이언트는 서버에게 자신이 어떤 차셋 인코딩 알고리즘들과 언어들을 이해하며, 어떤 것을 선호하는지 Accept-Charset과 Accept-Language 헤더를 보내 알려준다. 

2. 문자집합과 HTTP

2.1 차셋은 글자를 비트로 변환하는 인코딩이다.

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

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

차셋 태그는 등록된 MIME 문자집합에 표준화되어있고, IANA가 관리한다.

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

더보기

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

 

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

 

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

  1. 데이터의 비트를 인코딩 구조를 사용하여 디코딩 한다. 
  2. 코딩된 문자집합을 사용하여 글자를 찾는다.
  3. MIME 차셋 태그는 문자 인코딩 구조와 코딩된 문자집합 매핑의 결합을 서술한다.
  4. 글꼴과 포매팅 소프트웨어를 사용하여 화면이 보여줄 모양을 찾는다.

2.3 표준화된 MIME 차셋 값

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

만약 문자집합이 명시적으로 나열되지 않았다면, 수신자는 문서의 콘텐츠로부터 문자집합을 추측하려 시도한다. HTML에서는 <META HTTP-EQUIV="Content-Type'> 태그에서 찾을 수 있다. 

 

클라이언트가 문자 인코딩을 추측하지 못했다면, iso-8859-1인 것으로 가정한다.

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

3.1 문자집합 용어

  • 문자 : 알파벳글자, 숫자, 구두점, 표의문자, 기호 등 글씨에 최소 단위, 약식으로 유니코드
  • 글리프: 하나의 글자를 표헌하기 위한, 획의 패턴이나 다른 것과 구분되는 유일한 시각적 형태
  • 코딩된 문자: 우리가 글자를 다룰 수 있도록 각 글자에 할당된 유일한 숫자
  • 코드 공간: 문자 코드 값으로 사용하려고 계획해 둔 정수의 범위
  • 코드 너비: 각 문자 코드의(고정된 크기의) 비트 개수 
  • 사용 가능 문자집합: 세상에 존재하는 모든 글자의 부분집합
  • 코딩된 문자집합: 실제 글자들에 숫자로 됨 문자 코드를 대응시킨 것
  • 문자 인코딩 구조: 숫자로 된 문자코드들을 콘텐츠 비트의 연속으로 인코딩(또는 디코딩)하는 알고리즘
MIME 차셋 값은 데이터 비트를 고유한 문자의 코드로 매핑하는 알고리즘의 이름이다. 이것은 문자 인코딩 구조와 코딩된 문자집합의 개념을 합친 것이다. 

 

3.2 글리프, 연자

글리프는 각 글자를 그리는 특정한 방법으로, 각 문자는 미적 양식과 스크립트에 따라 여러가지 글리프를 가진다. 

글자들이 부드럽게 이어지는 연자를 지원한다.

 

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

  • US-ASCII: 정보교환을 위한 미국 표준 코드로 표준화된 가장 기본적인 문자집합으로 코드공간 전체를 표현하는데 7비트만이 필요하다. HTTP메시지에 사용된다.
  • ISO-8859: 국제적 글쓰기를 위해 필요한 글자들을 하이 비트를 이용해서 추가한 US-ASCII의 8비트 확대집합들이다. 추가 비트에 의해 제동되는 추가 공간은 모든 글자를 담기엔 작아 지경에 따라 커스터마이징된 문자집합을 제공한다.
  • JIS X 0201: 아스키를 일본어 가타카나 반각문자를 더해 확장한 극잔덕으로 작은 문자집합이다.
  • JIS X 0208: 최초의 멀티바이트 일본어 문자집합이다.
  • JIS X 0212: 0208에 6,607개의 문자를 추가한 문자집합이다. 
  • UCS: 전 세계의 모든 글자를 하나의 코딩된 문자집합으로 통합하려 노력하는 세계적인 표준이다.

3.4 문자 인코딩 구조

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

 

문자 인코딩 구조 종류

  • 고정폭: 각 코딩된 문자를 고정된 길이릐 비트로 표현한다. ( 빠르지만 공간낭비 )
  • 가변폭(비모달): 다른 문자 코드 번호에 다른 길이의 비트를 사용한다. ( 자주 사용하는 글자의 비트 길이를 줄이고, 이전 8비트 호환성 유지가 가능 )
  • 가변폭(모달): 다른 모드로의 전환을 위해 특별한 escape 패턴을 사용한다. 처리는 복잡하지만 복잡한 표기 체계를 효과적으로 지원한다. 

 

문자 인코딩 구조 예시

  • 8비트 고정폭 아이덴티티: 각 문자 코드를 그에 대응하는 8비트 값으로 인코딩 한다.
  • UTF-8: 문자 코드의 값을 위해 비모달 가변길이 인코딩을 사용한다. 선두 비트들은 인코딩된 문자의 길이를 바이트 단위로 나타내고, 이후의 바이트들은 각각 6비트의 코드 값을 담는다 
  • iso-2022-jp: 일본어 인터넷 문서를 위해 널리 사용되는 인코딩으로, 8비트 문자를 지원하지 않는 소프트웨어와 문제점을 방지하기 위해 128보다 작은 값으로만 이루어진 가변길이 모달 인코딩 이다.
  • euc-jp: 유닉스 운영체제에서 아시아 문자들을 지원하기 위해 개발 되었다. 여러 표준 일본어 문자집합을 사용할 수 있도록 해주는 가변길이 인코딩이다. 비모달 방식이며, 모드 간 전환을 위한 이스케이프 문자열이 존재하지 않는다. 
  • euc-kr: 한글 인터넷 문서를 위해 사용되는 가변길이 인코딩으로 KS X 1003 과 KS X 1001 의 두자기 문자 집합을 지원한다.
    • KS X 1003은 1바이트로 인코딩되는 로마자 문자 집합으로, 아스키에서 역슬래시를 원화 기로고 치환하기만 한 것
    • KS X 1001은 2바이트로 인코딩되는 한글,한자 그외 특수문자로 이루어진 한국어 문자 집합이다.

4. 언어 태그와 HTTP

4.1 Content-Language 헤더 

content-Language 엔터티 헤더 필드는 엔터니가 어떤 언어 사용자를 대상으로 하고 있는지 서술한다. 텍스트 문서만을 위한 것이 아니며, 오디오 클립, 동영상 그리고 어플리케이션도 특정 언어 사용자를 대상으로 할 수 있다. 

여러 언어 사용자를 대상으로 하고 있다면, 콤마로 나열 할 수 있다. 

- Content-Language: en, mi

4.2 Accept-Language 헤더

HTTP는 언어의 제약과 선호도를 웹 서버에 전달할 수 있게 해준다. 클라이언트는 자신이 이해할 수 있는 콘텐츠를 요청하기 위해 Accpet-Language와 Accept-Charset을 사용 할 수 있다.

- Accept-Language: es

4.3 언어 태그의 종류

언어 태그는 RFC 3006 'Tags for the Identification of Languages'로 문서화된 표준화된 문법을 갖고 있다. 

표현 할수 있는 종류에는 

  • 일반적인 언어 종류 
  • 특정 국가의 언어 ( 영국 영어 )
  • 방언
  • 지방어
  • 변형이 아닌 표준 언어
  • 비표준 언어

4.4 서브태그

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

  • 첫번째 서브태그: 주 서브태그라고 불리며, 표준화 되어있다. 
  • 두번째 서브태그: 선택적이며 자신만의 이름 표준을 따른다. 
  • 세번째부터의 서브태그는 등록되어있지 않다. 
마서스 비니어드 섬의 수화
첫번째 서브태그-두번째 서브태그-세 번째 서브태그

sgn-US-MA
수화-미국-매사추세츠 지역 변종

 

모든 태그는 대소문자가 구분되지 않지만, 언어를 나타낼 때는 소문자를 사용하고, 국가를 나타낼 때는 대문자를 사용한다.

 

4.5 IANA 언어 태그 등록

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

만약 언어 태그가 표준 국가와 언어 값으 조합이라면, 등록되지 않아도 무방하다. 표준 국가 언어 값으로 구성될 수 없는 언어 태그들만이 IANA에 의해 등록될 필요가 있다. 

 

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

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

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

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

두 번째 서브태그는 ISO 3166 국가 코드와 지역 표준 집합에서 선택된 표준화된 국가 토큰이다. IANA에 등록된 다른 문자열일 수도 있다. 

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

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

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

5. 국제화된 URL

5.1 국제적 가독성 VS 의미 있는 문자들

URI에 접근하기 쉽게 설계자들은 제한된 공통 문자집합을 선택했다. 제한이 있기 때문에 URI는 비영어권 사람들도 쉽게 사용하고 기억할 수 있도록 그들의 문자로 만들 수 있게 설계되지 못했다. 

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

그래서 오늘날 ASCII 문자들의 제한된 집합으로 이루어진 URI를 갖게 되었다. 

 

URI에서 사용할 수 있는 US_ASCII문자들의 부분집합은 예약된 문자들, 예약되지 않은 문자들 이스케이프 문자들로 나뉜다.

 

5.2 이스케이핑과 역익스케이핑

이스케이프는 예약된 문자나 다른 지원하지 않는 글자들을 URI에 삽입할 수 있는 방법을 제공한다. 이스케이프는 퍼센스 글자 하나와 뒤이은 16진수 글자 둘로 이루어진 세 글자 문자열이다. 

(16진수 두 글자 = US-ASCII 문자의 코드)

예를 들어 스페이스(아스키 32)를 추가하고 싶다면 이스케이프 %20을 사용할 수 있다. 
20은 32의 16진법 표현이기 때문이다. 

 

내부적으로 HTTP는 URI를 데이터가 필요할 때만 언이스케이핑 해야 하며, 중요한 것은 두번 언이스케이핑 되지 않아야 한다.

 

이스케이프 값들은 US-ASCII코드의 범위(0-127)에 있어야 함에 주의해야 한다.

6. 기타 고려사항

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

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

6.2 날짜

HTTP 명세는 올바른 GMT날짜 형식을 정의하고 있지만, 모든 웹 서버와 클라이언트가 규칙을 따르고 있지 않음에 주의 해야한다.

6.3 도메인 이름

국제화 문자를 포함하는 도메인 이름을 국제화 도메인 이름 이라고 하는데, 대부분의 브라우저가 퓨니코드를 이용해 이를 지원한다.

 

이런 고려 사항을 생각하며 충돌이 일어나지 않도록 주의 해야 한다.

728x90