HTTP 국제화 & 내용 협상과 트랜스코딩

16장. 국제화 (Internationalization)

HTTP가 전 세계의 다양한 언어와 문자를 처리하기 위해 어떤 표준과 메커니즘을 지정하여 전 세계 사용자들에게 원활하게 제공될 수 있도록 프로토콜에서 지원하는 과정

 

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

HTTP 엔터티 본문은 그저 '비트들로 가득 찬 상자'

국제 콘텐츠를 올바르게 처리하려면 서버와 클라이언트가 서로 합의된 정보를 주고받아야 한다.

 

서버의 역할: 클라이언트에게 문서의 문자와 언어를 알려주어 비트들을 올바른 문자로 해독하게 한다.

• Content-Type: charset: 문서의 문자 인코딩 방식을 지정한다.
• Content-Language: 문서가 어떤 언어로 작성되었는지 명시한다.

클라이언트의 역할: 사용자가 이해할 수 있는 언어와 설치된 인코딩 알고리즘 정보를 서버에 보낸다.

• Accept-Charset: 지원하는 문자 집합 (예: iso-8859-1, utf-8).
• Accept-Language: 선호하는 언어. 품질 인자(q)를 사용해 선호도 순위를 매길 수 있다 (예: fr, en;q=0.8 → 프랑스어 1순위, 영어 2순위). 

16.2 문자집합(Charset)과 HTTP

차셋의 정의: HTTP에서 charset은 글자를 비트로 변환(인코딩)하거나 비트를 글자로 복원(디코딩)하는 알고리즘의 이름을 의미

 

동작 원리 (2단계 매핑)

비트를 문자로 바꾸는 과정은 두 단계로 이루어진다.

• 비트 → 문자 코드: 비트 패턴을 특정 문자를 가리키는 숫자(문자 코드)로 변환한다 (예: 비트 11100001 → 코드 225) .
• 문자 코드 → 유일한 문자: 문자 코드를 '코딩된 문자집합'에서 찾아 실제 글자(예: 아랍 문자 FEH)로 식별한다.

잘못된 차셋의 위험성

클라이언트가 서버와 다른 charset을 사용하면, 같은 비트라도 전혀 다른 글자로 해석되어 '깨진 글자'가 나타난다.

예를 들어, 코드 225는 iso-8859-1에서는 'á'이지만, iso-8859-6에서는 아랍 문자 'FEH'가 된다.

 

만약 Content-Type 헤더가 없다면, 수신자는 HTML 내부의 <META HTTP-EQUIV="Content-Type"> 태그를 찾아보거나 텍스트 패턴을 스캔하여 인코딩을 추측해야 한다.

 

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

• 글리프(Glyph): 글자의 구체적인 시각적 형상 (글꼴이나 스타일에 따라 달라짐).
• 코딩된 문자(Coded Character): 각 글자에 할당된 유일한 숫자.
• 코딩된 문자집합(Coded Character Set): 글자들과 그에 대응하는 코드 번호들의 집합 (예: US-ASCII, Unicode).

'Charset' 용어의 문제

MIME의 charset이라는 용어는 사실 '문자 인코딩 구조(비트화 알고리즘)'와 '코딩된 문자집합(번호 할당)'을 합친 개념이라 혼란을 줄 수 있다 .

 

문자 인코딩 구조의 종류

고정폭 인코딩: 모든 문자를 동일한 비트 수(예: 8비트)로 표현한다. 빠르지만 공간 낭비가 있을 수 있다.

 

가변폭(비모달) 인코딩

자주 쓰는 문자는 적은 비트, 복잡한 문자는 많은 비트를 사용한다.

UTF-8이 대표적이며, ASCII와 호환성을 유지하면서 전 세계 문자를 1~6바이트로 표현한다.

 

가변폭(모달) 인코딩

'이스케이프 문자열'을 사용해 처리 모드를 전환한다. 예를 들어 iso-2022-jp는 이스케이프 시퀀스를 통해 ASCII 모드에서 일본어 모드로 전환한다.

 

인코딩 구조

8비트 : 간단히 각 문자 코드를 그에 대응하는 8비트 값으로 인코딩

UTF-8 : 인기있는 UCS를 위해 설계된 문자 인코딩. 비모달 가변길이 인코딩을 사용

iso-2022-jp : 일본어 인터넷 문서를 위해 사용되는 인코딩

euc-jp : 유닉스 운영체제에서 아시아 문자들을 지원하기 위해 개발된 일본어 인코딩

euc-kr : 한글 인터넷 문서를 위해 사용되는 가변길이 인코딩

 

16.4 언어 태그와 HTTP

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

Content-Language 헤더

엔터티가 어떤 언어 사용자를 대상으로 하고있는지 서술.

Accept-Language 헤더

클라이언트에서 자신이 이해할 수 있는 콘텐츠를 요청하기위해 사용.

언어 태그의 구조: 언어 태그는 하이픈으로 구분된 하나 이상의 '서브태그'로 구성된다.

• 첫 번째 서브태그 (주 태그): 언어의 종류를 나타낸다 (표준화됨). 예: en(영어), ko(한국어).
• 두 번째 서브태그: 선택적이며, 특정 국가나 지역을 나타낸다. 예: en-US(미국 영어), en-GB(영국 영어).

IANA에 등록된 표준 태그를 사용해야 하며, 사용자의 선호 언어 설정이나 문서의 대상 독자를 명시할 때 쓰인다.

 

16.5 국제화된 URI

URI의 한계: URI 설계자들은 가독성과 호환성을 위해 URI를 제한된 문자 집합(US-ASCII)으로만 구성하도록 했다.

이스케이핑(Escaping)

URI에 허용되지 않는 문자(비 ASCII 문자나 공백 등)를 포함하려면, 해당 문자를 안전한 형태로 변환해야 한다.

이를 퍼센트 인코딩이라고 한다.

• 문자의 바이트 코드를 16진수로 변환하고 앞에 %를 붙인다. (예: 스페이스(코드 32) → %20).

국제 문자 이스케이핑 주의점

이스케이핑은 ASCII 범위(0-127) 내의 문자 코드를 표현하기 위한 것이므로, 그 범위를 벗어나는 국제 문자를 단순히 이스케이핑하는 것은 문제가 될 수 있다. 보통은 UTF-8 등으로 먼저 인코딩한 뒤 각 바이트를 이스케이핑한다 .

 

16.6 기타 고려사항

헤더: HTTP 헤더의 명칭과 값은 반드시 US-ASCII 문자들로만 이루어져야 한다. 잘못된 문자가 포함되면 서버나 프락시가 오작동할 수 있다.

 

도메인 이름: 국제화 도메인 이름(IDN)은 '퓨니코드(punycode)'를 사용해 변환된다. 예를 들어 한글.com은 xn--... 형태의 ASCII 문자열로 변환되어 DNS에서 처리된다.

 

 

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

같은 URL이라도 사용자(클라이언트)의 환경에 따라 가장 적절한 형태의 리소스를 제공하는 기술

 

17.1 내용 협상 기법 개요

서버가 클라이언트에게 맞춤형 콘텐츠를 제공하는 방법은 크게 세 가지가 있음

1. 클라이언트 주도: 클라이언트가 요청을 보내면 서버는 선택지를 보내주고 그 중 직접 선택.
2. 서버 주도: 서버가 클라이언트의 요청 헤더를 분석해 선택해서 제공.
3. 투명 협상: 중개자(프락시)가 서버를 대신하여 선택.

17.2 클라이언트 주도 협상

동작: 서버가 요청을 받으면, 사용 가능한 페이지 목록(링크)이 담긴 HTML을 보내주거나 300 Multiple Choices 응답을 보낸다.

장점: 서버 구현이 가장 쉽고, 사용자가 원하는 것을 정확히 고를 수 있다.

단점: 리소스를 얻기 위해 최소 두 번의 요청(목록 받기 → 선택하기)이 필요해 대기 시간이 길어지며, 사용자에게 선택의 번거로움을 준다.

 

17.3 서버 주도 협상

동작: 서버가 클라이언트가 보낸 Accept-* 관련 헤더들을 검사하여 가장 적절한 버전을 결정해 보내준다.

 

품질값(q-value): 클라이언트는 선호도를 0.0에서 1.0 사이의 q 값으로 표현해 서버에 힌트를 준다.

Accept-Language: en;q=0.5, fr;q=0.0, nl;q=1.0 → 네덜란드어(1.0)를 제일 선호, 영어(0.5)는 차선, 프랑스어(0.0)는 거부.

아파치(Apache)의 지원

• type-map 파일: 특정 리소스의 여러 변형(언어, 포맷 등)과 품질 값을 명시해 둔 파일.
• MultiViews: 파일 확장자를 생략하고 요청해도(예: joes-hardware), 서버가 알아서 적절한 파일(예: joes-hardware.fr.html)을 찾아주는 기능.

17.4 투명 협상

클라이언트 입장에서 협상하는 중개자 프락시를 두어, 메시지 교환을 최소화하면서도 서버 주도 협상의 부하를 줄이는 방법.

프락시는 클라이언트의 기대가 무엇인지 알고있고, 클라이언트의 입장에서 협상을 수행할 수 있는 것으로 가정.

 

캐시와 얼터네이트

캐시(cache)

서버의 응답을 저장해 두었다가 재사용하며, 다시 돌려줄 때는 원본 응답에 포함된 중요한 헤더를 그대로 사용해야 함.

얼터네이트(alternate) 또는 베리언트(variant)

하나의 URL이라도 프랑스어·영국(영어) 버전처럼 서로 다른 문서가 존재할 수 있는데, 이러한 동일 URL의 여러 문서 형태.

 

따라서 캐시는 첫 응답뿐 아니라 이후의 모든 다른 버전도 저장해두고, 요청자가 스페인어를 원하면 스페인어 문서를 주는 식으로 요청 조건에 맞는 올바른 얼터네이트를 선택해 전달해야 함

 

 

Vary 헤더

동일한 URL에 대한 요청이라도 클라이언트의 특징(User-Agent, Accept-Encoding, Cookie 등)에 따라 서버가 다른 응답을 보낸다는 것을 캐시에게 알려주는 HTTP 응답 헤더

(캐시된 응답을 올바르게 제공하기 위해 매우 중요)

서버는 응답 시 Vary: User-Agent, Accept-Language와 같이 이 응답은 이 헤더들에 따라 달라진다. 라고 알려줌

캐시는 이후 요청이 들어올 때, Vary에 명시된 헤더 값이 저장된 응답과 일치하는지 확인한 후 콘텐츠를 내어준다 .

 

17.5 트랜스코딩 (Transcoding)

서버가 클라이언트의 요구에 딱 맞는 리소스를 가지고 있지 않을 때, 즉석에서 변환을 수행하는 기술

• 포맷 변환 (Format Conversion): 데이터를 다른 포맷으로 바꾼다.
  • 예: HTML 문서를 모바일용 WML로 변환하거나, 고해상도 이미지를 저해상도로 축소해 전송.
• 정보 합성 (Information Synthesis): 문서에서 핵심 내용만 추려내는 것.
  • 예: 긴 본문에서 개요를 생성하거나, 광고 및 로고를 제거하여 텍스트만 추출.
• 콘텐츠 주입 (Content Injection): 문서의 양을 늘리는 변환.
  • 예: 자동으로 광고를 생성해 삽입하거나, 사용자 추적 시스템 코드를 페이지에 동적으로 추가.