[16장] 국제화

[eunbc]

No description provided.

[annahxxl]

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

• 국제 콘텐츠를 지원하기 위해, 서버는 클라이언트에게 각 문서의 문자와 언어를 알려줘서, 클라이언트가 올바르게 문서를 이루고 있는 비트들을 문자들로 풀어내고, 올바르게 처리해서 사용자에게 콘텐츠를 제공해줄 수 있도록 할 필요가 있다
• 서버는 클라이언트에게 문서의 문자와 언어를 HTTP Content-Type charset 매개 변수와 Content-Language 헤더를 통해 알려준다
• 클라이언트는 서버에게 자신이 어떤 차셋 인코딩 알고리즘들과 언어들을 이해하며 그 중 무엇을 선호하는지 말해주기 위해 Accept-Charset과 Accept-Language 헤더를 보낸다

문자집합과 HTTP

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

• HTTP 차셋 값은, 어떻게 엔터티 콘텐츠 비트들을 특정 문자 체계의 글자들로 바꾸는지 말해준다
• 각 차셋 태그는 비트들을 글자들로 변환하거나 혹은 그 반대의 일을 해주는 알고리즘을 명명한다
• 차셋 태그는 등록된 MIME 문자집합에 표준화되어 있고, IANA가 관리한다

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

1. 문서를 이루는 비트들은, 특정 코딩된 문자집합의 특정 문자로 식별될 수 있는 문자 코드로 변환된다 (디코딩)
2. 문자 코드는 코딩된 문자집합의 특정 요소를 선택하기 위해 사용된다
3. 1. 2 에서 사용되는 알고리즘은 MIME 차셋 태그를 통해 결정된다

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

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

표준화된 MIME 차셋 값

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

Content-Type charset 헤더와 META 태그

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

Accept-Charset 헤더

• 대부분의 클라이언트는 모든 종류의 문자 코딩과 매핑 시스템을 지원하지는 않는다
• Accept-Charset 헤더의 값은 클라이언트가 지원하는 문자 인코딩의 목록을 제공한다
• 이 문자 인코딩 구조 중 어떤 것으로 콘텐츠를 반환할지는 서버의 자유다

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

문자집합 용어

• 문자: 알파벳 글자, 숫자, 구두점, 표의문자, 기호 등 글쓰기의 최소 단위
• 글리프: 하나의 글자를 표현하기 위한, 획의 패턴이나 다른 것과 구분되는 유일한 시각적 형태
• 코딩된 문자: 우리가 글자를 다룰 수 있도록 각 글자에 할당된 유일한 숫자
• 코드 공간: 문자 코드 값으로 사용하려고 계획해 둔 정수의 범위
• 코드 너비: 각 문자 코드의 비트 개수
• 사용 가능 문자 집합: 글자들에 대한 특정한 작업 집합
• 코딩된 문자집합: 사용 가능 문자집합을 받아서 각 글자에 코드 공간의 코드를 할당해주는 코딩된 문자들의 집합
• 문자 인코딩 구조: 숫자로 된 문자 코드들을 콘텐츠 비트의 연속으로 인코딩하는 알고리즘

‘차셋(Charset)’은 형편없는 이름이다

• MIME 차셋 태그(Content-Type charset 매개변수와 Accept-Charset 헤더에서 쓰이는)는 문자집합을 의미하는 것이 결코 아니다
• MIME 차셋 값은 데이터 비트를 고유한 문자의 코드로 매핑하는 알고리즘의 이름이다
• 이것은 문자 인코딩 구조와 코딩된 문자집합의 개념을 합친 것이다

문자

• 문자는 글꼴이나 스타일에 독립적이다

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

• 글리프는 각 글자를 그리는 특별한 방법이다

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

• 코딩된 문자집합은 보통 코드 번호로 인덱싱된 배열로 구현된다

문자 인코딩 구조

• 문자 인코딩 구조들은 숫자로 된 문자 코드를 콘텐츠 비트들로 변환하고 다른 쪽에서는 그들을 다시 문자 코드로 환원한다
• 문자 인코딩 구조는 크게 세 종류로 분류할 수 있다.
  • 고정폭: 각 코딩된 문자를 고정된 길이의 비트로 표현한다
  • 가변폭(비모달): 다른 문자 코드 번호에 다른 길이의 비트를 사용한다
  • 가변폭(모달): 다른 모드로의 전환을 위해 특별한 ‘escape’ 패턴을 사용한다
• 인코딩 구조
  • UTF-8
    • 문자 코드의 값을 위해 비모달 가변길이 인코딩을 사용한다

언어 태그와 HTTP

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

Content-Laguage 헤더

• Content-Language 엔터티 헤더 필드는 엔터티가 어떤 언어 사용자를 대상으로 하고 있는지 서술한다

Accept-Language 헤더

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

언어 태그의 종류

• 일반적인 언어의 종류 ex) es
• 특정 국가의 언어 ex) en-GB
• 방언 ex) no-bok
• 지방어 ex) sgn-US-MA
• 그 외의, 다른 언어의 변형이 아닌 표준 언어 ex) i-navajo
• 비표준 언어 ex) x-snowboarder-slang

서브태그

• 언어 태그는 하이픈으로 분리된 하나 이상의 서브태그로 이루어져 있다
  • 첫 번째 서브태그는 주 서브태그라 불린다
  • 두 번째 서브태그는 선택적이고 자신만의 이름 표준을 따른다
  • 세 번째부터의 서브 태그는 등록되어 있지 않다

대소문자의 구분 및 표현

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

IANA 언어 태그 등록

• 첫 번째와 두 번째 언어 서브태그의 값은 여러 가지 표준 문서와 그것들을 관리하는 조직에 의해서 정의된다

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

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

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

• 두 번째 서브태그는 보통 ISO 3166 국가 코드와 지역 표준 집합에서 선택된 표준화된 국가 토큰이다

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

• 8자 이하의 알파벳과 숫자로 이루어져야 한다는 것을 제외하면 다른 규칙은 없다

국제화된 URI

• 오늘날 URI는 국제화를 그다지 지원하지 않는다

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

• 리소스 식별자의 가독성과 공유 가능성의 보장이, 대부분의 의미있는 문자들로 구성될 수 있도록 하는 것보다 더 중요하다고 여겼다
• 그래서 오늘날 ASCII 문자들의 제한된 집합으로 이루어진 URI를 갖게 되었다

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

• URI에서 사용할 수 있는 US-ASCII 문자들의 부분집합은

  • 예약된 문자들,
  • 예약되지 않은 문자들,
  • 이스케이프 문자들

  로 나뉜다

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

• 예약된 문자나 다른 지원하지 않는 글자들을 안전하게 URI에 삽입할 수 있는 방법

기타 고려사항

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

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

날짜

• HTTP 애플리케이션은 명세에 맞지 않는 날짜를 관대하게 받아들이고, 충돌을 일으키지 말아야 한다
• 만약 날짜를 파싱할 수 없다면, 서버는 그것을 보수적으로 다루어야 한다

도메인 이름

• 국제화 문자를 포함하는 도메인 이름을 ‘국제화 도메인 이름’이라고 한다
• 오늘날 대부분의 웹브라우저가 퓨니코드를 이용해 이를 지원한다
• 웹브라우저들은 이 기법을 이용해 사용자가 입력한 다국어로 된 도메인 이름을 알파벳과 숫자 등으로 된 도메인 이름으로 변환한다

[byulcode]

국제화

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

HTTP 메시지는 어떤 콘텐츠든 담을 수 있다. HTTP의 엔티티 본문은 그저 비트 모음이다.

비트 모음을 콘텐츠로 만들기 위한 정보 제공

• 서버 → 클라이언트
  • Content-Type charset
  • Content-Language
• 클라이언트 → 서버
  • Accept-Charset
  • Accept-Language

문자집합과 HTTP

Charset은 글자를 비트로 변환하는 인코딩이다

• Charset 은 문자 변환 인코딩 알고리즘을 담고 있다. (비트 ←→ 글자)

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

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

• 비트 → 문자 변환은 크게 두 단계를 거친다.
  1. 비트 → 문자 코드 변환
  2. 문자 코드 → 문자 코드와 대응하는 문자집합의 특정 요소를 선택
• 문자집합의 문자열은 이후 글꼴과 포매팅 소프트웨어를 사용하여 화면에 표시할 모양을 찾는다.
• 국제화된 시스템은 표현과 의미를 분리한다.
  • HTTP는 문자 데이터와 언어, charset 라벨 전송에만 집중한다.
  • 글자의 모양, 표현은 디스플레이 소프트웨어의 역할이다.

잘못된 Charset은 잘못된 글자들을 낳는다

• 잘못된 charset 매개변수를 사용하면 엉뚱하거나 깨진 글자를 보여주게 될 수 있다

표준화된 MIME 차셋 값

• 표준에 따라 정의된 charset
• HTTP가 표준화된 MIME charset 태그를 사용하는 헤더:
  • Content-Type
  • Accept-Charset

Content-Type charset 헤더와 META 태그

• 서버는 클라이언트에게 MIME 차셋 태그를 charset 매개변수와 함께 Content-Type 헤더에 명시하여 전송한다.
• charset이 명시되어있지 않다면 문서의 콘텐츠로부터 charset을 추측한다
• 문자 인코딩을 추측하지 못했다면 iso-8859-1로 가정한다.

Accpet-Charset 헤더

• 클라이언트는 지원할 수 있는 charset을 Accept-Charset 요청 헤더에 명시해 서버에 전달한다.
• Accept-Charset 요청 헤더에 대응하는 Content-Charset 응답 헤더는 존재하지 않는다.
  • Content-Type의 charrset 매개변수로 응답을 받음

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

문자집합 용어

• 문자 : 글쓰기의 최소 단위
• 글리프 (glyph) : 하나의 글자를 표현하기 위한 여러가지 패턴/방식. 같은 문자는 글리프가 바뀌어도 의미가 변하지 않는다.
• 코딩된 문자 (coded character) : 각 글자에 대응하는 유일한 숫자
• 코드 공간 (coding space) : 문자 코드 값으로 사용하려고 계획해 둔 정수의 범위
• 코드 너비 (code width) : 각 문자 코드의 (고정된 크기의) 비트 개수
• 사용 가능 문자집합 (character repertorie): 글자들에 대한 특정한 작업 집합
• 코딩된 문자집합 (coded character set) : 문자코드와 대응하는 실제 글자들의 집합
• 문자 인코딩 구조 : 숫자로 된 문자 코드를 콘텐츠 비트의 연속으로 인코딩하는 알고리즘

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

MIME 차셋 태그는 단순히 문자 집합 뿐 아니라 비트-문자 변환 인코딩 알고리즘의 개념을 포함한다

언어 태그와 HTTP

: 언어에 이름을 붙이기 위한 짧고 표준화된 문자열

Content-Language 헤더

• 엔터티가 어떤 언어 사용자를 대상으로 하는지 서술한다.
• 문서 뿐만 아니라 어떤 종류의 미디어라도 Content-Language 헤더를 사용할 수 있다.
• 한 번에 여러가지 언어를 나열할 수도 있다.

Accept-Language

• 클라이언트의 언어 제약과 선호하는 언어 정보를 서술한다.

서브태그

언어 태그는 하나 이상의 서브태그로 이루어진다

• 첫 번째 서브태그는 주 서브태그로 불리며, 표준화되어 있음
• 두 번째 서브태그는 선택적이며 자신만의 이름 표준을 가짐
• 세 번째 서브태그부터는 자유양식

언어 태그는 대소문자를 구별하지 않음
관용적으로 언어는 소문자, 국가는 대문자로 표기

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

• 일반적으로 ISO 639 표준 언어 집합에서 선택된 언어 토큰
• ‘i’일 경우 IANA에 등록된 태그
• ‘x’일 경우 특정 개인이나 집단 전용의 비표준 확장 서브태그

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

• 두 글자일 경우 ISO 3166 국가 코드와 지역 표준 집합에서 선택된 국가 토큰
• 3~8 글자일 경우 IANA 에 등록된 태그
• 그 외에는 잘못된 값

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

• 8자 이하의 알파벳과 숫자로 이루어지기만 하면 됨

국제화된 URI

URI는 국제화를 별로 지원하지 않음. 리소스 식별자의 가독성과 공유 가능성의 보장을 위해 ASCII 문자들의 제한된 집합으로 이루어지게 됨

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

US-ASCII 의 부분집합

• 예약된 문자
• 예약되지 않은 문자
• 이스케이프

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

• 이스케이프
  • 예약된 문자나 지원하지 않는 글자를 URI 에 삽입하기 위한 방법
  • % + 16진수 두 글자
  • 이스케이프 값들은 US-ASCII 코드 범위에 있어야 한다
• 역이스케이핑
  • URI 데이터가 필요할 때만 해야한다
  • 어떤 URI도 한 번만 해야한다. ⇒ 이스케이핑된 기호를 포함한 문자를 이스케이프 문자로 처리해 데이터의 손실이 발생할 수 있기 때문

기타 고려사항

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

• HTTP 헤더는 US-ASCII 문자집합의 글자로만 이루어져야 한다.
• 모든 문자 구분 라이브러리들이 ASCII 범위를 벗어난 글자를 지원하는 것은 아니기 때문에 범위를 벗어나면 부적절한 결과를 반환하거나 충돌을 일으킨다.

날짜

• HTTP 애플리케이션은 명세에 맞지 않는 날짜를 관대하게 받아들이고, 충돌을 일으키지 말아야 한다.
• 서버는 파싱할 수 없는 날짜 형식에 대해 보수적으로 다뤄야 한다.

도메인 이름

• 국제화 문자를 포함하는 도메인 이름을 '국제화 도메인 이름'이라고 한다
• 브라우저는 퓨니코드 (punycode)를 이용해 이를 지원한다.
  • Punycode : 유니코드 문자열을 호스트명에서 사용 가능한 문자만으로 이루어진 문자열로 변환하는 방법. RFC 3492

[eunbc]

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

• HTTP 메시지는 어떤 언어로 된 콘텐츠든, 이미지, 동영상 혹은 그 외 다른 종류의 미디어처럼 실어 나를 수 있다. HTTP 에서 엔터티 본문이란 그저 비트들로 가득 찬 상자이다
• 국제 콘텐츠를 지원하기 위해, 서버는 클라이언트에게 문서의 문자와 언어를 Content-Type charset 매개 변수와 Content-Language 헤더를 통해 알려준다
• 클라이언트는 Accept-Charset과 Accept-Language 헤더를 통해 서버에게 자신이 어떤 차셋 인코딩 알고리즘들과 언어들을 이해하며 무엇을 선호하는지 말해준다

문자 집합과 HTTP

차셋(Charset)

• HTTP charset 값은, 어떻게 엔터티 콘텐츠 비트들을 특정 문자 체계의 글자들로 바꾸는지 말해준다
  • Content-Type : text/html; charset=iso-2022-jp
• 각 차셋 태그는 비트들을 글자들로 변환하거나 혹은 그 반대의 일을 해주는 알고리즘을 명명한다
• 차셋 태그는 MIME 문자집합에 표준화되어 있고, IANA가 관리한다

문자집합과 인코딩

• 문서를 이루는 비트들은, 문자 집합의 특정 문자로 식별될 수 있는 문자 코드로 인코딩된다 (ex. 아 → 225)
• 문자 집합에서 글자를 찾고, 글꼴과 포매팅 소프트웨어를 사용하여 화면이 보여줄 모양을 찾는다 ( 255 → 아)
• charset 매개변수에 따라 같은 비트 값을 다른 문자로 보여준다

표준화된 MIME 차셋 값

• 특정 문자 인코딩과 특정 코딩된 문자집합의 결합을 MIME 차셋이라고 부른다
• us-ascii, iso-8859, utf-8, euc-jp…
• HTTP 클라이언트는 서버에게 정확히 어떤 문자 체계를 지원하는지 Accept-Charset 요청 헤더를 통해 알려준다

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

• 문자 : 알파벳 글자, 숫자, 구두점, 표의문자, 기호 등 글쓰기의 최소 단위, 글꼴이나 스타일에 독립적
• 글리프 : 하나의 글자를 표현하기 위한, 획의 패턴이나 다른 것과 구분되는 유일한 시각적 형태
• 코딩된 문자 : 각 글자에 할당된 유일한 숫자
• 코드 공간 : 문자 코드 값으로 사용하려고 계획해 둔 정수의 범위
• 코드 너비 : 각 문자 코드의 비트 개수
• 코딩된 문자 집합 : 각 글자에 코드 공간의 코드를 할당해주는 코딩된 문자들의 집합, 실제 글자들에 숫자로 된 문자 코드를 대응시킨 것
  • 문자들의 집합과 각 문자에 할당된 고유 번호를 정의
  • US-ASCII : 모든 문자 집합의 어머니, 0-127 만 사용하여 코드 공간 전체를 표현하는데 7비트 필요
  • iso-8859 : 국제적인 글쓰기를 위해 필요한 글자들을 하이 비트를 이용해서 추가한 US-ASCII의 8비트 확대 집합. 지역에 따라 커스터마이징된 문자 집합 제공
  • JIS X 0201, UCS …
• 문자 인코딩 구조 : 숫자로 된 문자 코드들을 콘텐츠 비트의 연속으로 인코딩하고, 다른쪽에서는 그들을 다시 문자 코드로 환원하는 알고리즘
  • 문자들을 컴퓨터가 이해하고 처리할 수 있는 실제 바이트 형태로 변환하는 방법을 정의
  • 인코딩 구조 종류
    • 고정폭 : 각 코딩된 문자를 고정된 길이의 비트로 표현
    • 가변폭(비모달) : 문자 코드 번호에 다른 길이의 비트 사용
    • 가변폭(모달) : 다른 모드로의 전환을 위해 이스케이프 패턴 사용
  • 8비트
  • UTF-8 : 비모달 가변길이 인코딩
  • iso-2022-jp
  • euc-jp, euc-kr

언어 태그와 HTTP

• 언어 태그는 언어에 이름을 붙이기 위한 짧고 표준화된 문자열이다
• Content-Language 헤더는 엔터티가 어떤 언어 사용자를 대상으로 하는지 서술한다, 여러 언어 나열 가능
• Accept-Language 헤더는 클라이언트의 언어 제약과 선호도를 나타낸다
• 언어 태그는 하이픈으로 분리된 하나 이상의 서브태그로 이루어져 있다
  • 모든 태그는 대소문자가 구분되지 않는다
  • IANA 는 RFC 3066 규칙에 따라 표준 언어 태그의 목록을 관리한다

국제화된 URI

• 오늘날의 URI는 US-ASCII의 부분집합으로 구성되어 있다
• URI 저자들은 공유하기 쉽게 하기 위해 매우 제한된 문자집합을 선택했다
  • 예약된 문자들
  • 예약되지 않은 문자들
  • 이스케이프
• URI는 예약된 문자나 다른 지원하지 않는 글자들을 안전하게 URI에 삽입할 수 있는 방법을 제공한다
  • % + 16진수 글자 둘
  • 두 번 언이스케이핑 되지 않도록 주의해야 한다
  • ASCII는 0x7F(십진수 127) 까지의 코드만을 정의한다

기타 고려사항

• HTTP 헤더는 반드시 US-ASCII 문자집합의 글자들로만 이루어져야 한다. 하지만 때때로 잘못된 문자를 받게 될 수도 있으므로 운영체제와 라이브러리 루틴을 사용한다.
• HTTP 어플리케이션은 명세에 맞지 않는 날짜를 관대하게 받아들이고, 받아들이면서 충돌을 일으키지 말아야 한다
• 국제화 문자를 포함하는 도메인 이름을 국제화 도메인 이름이라고 하는데, 오늘날 대부분의 웹브라우저가 퓨니코드를 이용해 이를 지원한다. 이 기법을 이용해 웹 브라우저는 다국어로 된 도메인 이름을 알파벳과 숫자로 변환한다.

[park0jae]

주요 국제화 이슈인 문자집합 인코딩 & 언어태그에 대해 알아보자.

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

• 국제 콘텐츠 지원을 위해 서버는 클라이언트에게 각 문서의 문자와 언어를 알려준다.
• 클라이언트는 제공받은 정보를 바탕으로 문서를 이루고 있는 비트들을 올바르게 문자들로 풀어내고, 처리해 사용자에게 제공
• 서버는 클라이언트에게 문서의 문자와 언어를 HTTP Content-Type charset 매개변수와 Content-Language 헤더를 통해 알려줌
• 클라이언트는 서버에게 자신이 어떤 charset 인코딩 알고리즘들과 언어들을 이해하며 무엇을 선호하는지 Accept-Charset & Accept-Language 헤더 보냄

문자집합과 HTTP

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

• HTTP Charset 값은 어떻게 엔터티 콘텐츠 비트들을 특정 문자 체계의 글자들로 바꾸는지 말해줌
• Content-Type: text/html; charset=iso-8859-6
  • Content-Type 헤더는 수신자에게 콘텐츠가 HTML 파일임을 말해줌
  • charset 매개변수는 수신자에게 콘텐츠 비트들을 글자들로 디코딩하기 위해 iso-8859-6 아랍 문자집합 디코딩 기법을 사용하라고 명시해줌
• 만약 클라이언트가 문자 인코딩을 추측하지 못하면, iso-8859-1인 것으로 가정

[ Accept-Charset 헤더 ]

• 클라이언트는 서버에게 정확히 어떤 문자 체계를 그들이 지원하는지 Accept-Charset 요청 헤더를 통해 알림
• Accept-Charset 헤더의 값은 클라이언트가 지원하는 문자 인코딩의 목록을 제공
• Accept-Charset: iso-8859-1, utf-8
  • 클라이언트가 서유럽 iso-8859-1 문자 시스템을 잘 받아들일 수 있음을 말함

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

[ 문자 집합 용어 ]

• 문자 : 글쓰기 최소 단위 (= 하나의 알파벳, 숫자, 수학 기호 등)

• 글리프 : 하나의 글자를 표현하기 위한, 획의 패턴이나 다른 것과 구분되는 유일한 시각적 형태 (= 각 글자를 그리는 특정한 방법)

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

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

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

• 사용 가능 문자 집합 : 글자들에 대한 특정한 작업 집합

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

  → 실제 글자들에 숫자로 된 문자 코드를 대응시킨 것

• 문자 인코딩 구조 : 숫자로 된 문자 코드들을 콘텐츠 비트의 연속으로 인코딩하는 알고리즘 (UTF-8, ISO-2022-jp , euc-jp)

  → 글자를 식별하기 위해 필요한 데이터의 양을 줄이거나(압축), 중복되는 코딩된 문자집합들을 통합하는데 사용될 수 있음

언어 태그와 HTTP

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

[ Content-Language 헤더 ]

• 엔터티가 어떤 언어 사용자를 대상으로 하고 있는지 서술
• 텍스트 문서 이외의 오디오 클립, 동영상, 애플리케이션도 특정 언어 사용자를 대상으로 할 수 있음
• 콘텐츠가 여러 언어를 대상으로 한다면, 언어들을 나열할 수 있다. (Content-Language: fr,en)

[ Accept-Language 헤더 ]

• 웹 서버가 자원에 대해 여러 언어로 된 버전을 갖고 있다면, 사용자에게 선호하는 언어로 된 콘텐츠를 제공
• 클라이언트는 자신이 이해할 수 있는 콘텐츠 요청을 위해, Accept-Language와 Accept-Charset을 사용

[ 대소문자 구분 및 표현 ]

• 모든 태그는 대소문자가 구분되지 않음
• 관용적으로 언어를 나타낼 때 소문자(= fr) , 국가를 나타낼 때는 대문자(= FR)를 사용함

국제화 된 URI

• 오늘날 URI는 국제화를 지원하지 않는다.
• 오늘날의 URI는 US-ASCII의 부분집합으로 구성되어 있다.

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

• 첫 째, URI 설계자들은 전 세계 모두가 URI를 이메일, 전화 등을 통해 다른 이들과 공유할 수 있기를 원했음

• 둘 째, URI 설계자들은 URI가 사용하기 쉽고 기억하기 쉽길 바랐다.

• 따라서, 설계자들은 매우 제한된 공통 문자 집합을 선택함 (이 작은 문자집합은 전 세계 대부분의 소프트웨어와 키보드에서 지원)

• 문자집합에는 제한이 있기 때문에, URI는 비영어권 사름들도 쉽게 사용하고 기억할 수 있도록 설계 되지 못함

• URI 저자들은 리소스 식별자의 가독성과 고유 가능성의 보장이 중요하다고 여겼다.

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

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

• US-ASCII 문자들의 부분집합은 예약된 문자들 , 예약되지 않은 문자들, 이스케이프 문자들로 나뉜다.
• 예약된 문자 : “;”|”/“|”?”|”:”|”@”|”&”|”=”|”+”|”$”|”,”
• 예약되지 않은 문자 : [A-Za-z0-9] |”-“|”_”|”.”|”!”|”~”|”*”|”‘“|”(“|”)”
• 이스케이프 : “%”

[ 이스케이핑과 역이스케이핑 ]

• 이스케이프는 예약된 문자나 다른 지원하지 않는 글자들을 안전하게 URI에 삽입할 수 있는 방법을 제공
• 이스케이프는 퍼센트 글자 하나와 뒤이은 16진수 글자 둘로 이루어진 세 글자 문자열
• http://www.joes-hardware.com/big%20sale.txt ( 이스케이프 - %20 = 32 - 언이스케이프 )
• 애플리케이션은 어떤 URI도 두 번 언이스케이핑 되지 않도록 해야 한다.
  • 이스케이핑 된 퍼센트 기호를 포함한 URI를 언이스케이핑하면 퍼센트 기호가 포함된 URI가 만들어짐
  • 잘못하여 한 번 더 언이스케이핑 하게 되면, 이스케이프의 일부처럼 처리되어 데이터의 손실을 유발함

기타 고려사항

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

• HTTP 헤더는 반드시 US-ASCII 문자집합의 글자들로만 이루어져야 한다.
• HTTP 애플리케이션은 글자들을 처리하기 위해 운영체제와 라이브러리 루틴을 사용

[ 날짜 ]

• HTTP 명세는 올바른 GMT 날짜를 명확히 정의하지만, 모든 웹 서버와 클라이언트가 규칙을 따르지 않는다.
• 명세에 맞지 않는 날짜를 관대하게 받아들이고, 받아들이면서 충돌을 일으키지 말아야 함

[ 도메인 이름 ]

• 국제화 문자를 포함하는 도메인 이름을 국제화 도메인 이름(Internationalizing Domain Name)이라 한다.
• 웹 브라우저는 퓨니코드를 사용해 사용자가 입력한 다국어로 된 도메인 이름을 알파벳과 숫자 등으로 된 도메인 이름으로 변환
• 퓨니코드란 유니코드 문자열을 호스트 명에서 사용가능한 문자만으로 이루어진 문자열로 변환하는 방법
• ex) ‘한글.com’ → ‘xn—bj0bj06e.com’으로 변환

[kimday0326]

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

• HTTP의 엔티티 본문은 그저 비트들로 가득 찬 상자이다.

• 서버는 클라이언트에게 문서의 문자와 언어를 알려줄 필요가 있다.
  -> Content-Type charset 매개변수와 Content-Language 헤더

• 클라이언트는 서버에게 사용자가 어떤 언어를 이해할 수 있고, 어떤 알파벳 알고리즘을 사용하는지 알려줄 필요가 있다.
  -> Accept-Charset과 Accept-Language 헤더

  문자집합과 HTTP

Charset

어떻게 엔티티 콘텐츠 비트들을 특정 문자 체계의 글자들로 바꾸는지 알려준다.
Content-type: text/html; charset=iso-8859-6

=> iso-8859-6 디코딩 기법을 사용해라!
이런 차셋 태그들은 등록된 MIME 문자집합에 표준화되어있고, IANA가 관리한다.

문자 집합과 인코딩

비트를 디코딩하는 과정

1. 비트를 문자 코드로 변환한다.
2. 문자코드를 문자 집합의 문자코드와 대응하는 문자로 변환한다.

다만, HTTP는 문제 데이터 및 관련된 차셋 라벨의 전송만 신경쓰고, 글꼴 등은 브라우저가 담당한다. 또한 같은 문자 코드이더라도 잘못된 차셋을 사용하면 잘못된 글자로 변환될 수 있다.

MIME Charset Names

Charset과 META 태그

HTML에서 문자집합은 META 태그에서 찾을 수 있다.

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-2022-jp">

기본은 iso-8859-1로 가정한다.

Accept-charset 헤더

클라이언트는 자신이 어떤 문자 체계를 지원하는지 Accept-charset 헤더를 통해 알려준다.
Accept-Charset: iso-8859-1, utf-8
이에 대응되는 Content-Charset 응답은 존재하지 않고, Content-Type 헤더의 charset 매개변수를 통해 응답을 받는다.

다중언어 문자 인코딩

문자 집합 용어

1. 문자

   • 글쓰기의 최소 단위. '유니코드' 라는 여러 언어의 여러 글자에게 알맞고 유일한 이름을 부여하기 위한 표준화된 집합이 존재한다.
   • 글꼴이나 스타일에 독립적이다.

2. 글리프(glyph)

   • 하나의 글자를 표현하기 위한 여러 방식(시각적 형태)
   • 보다 멋지게 보이도록 하기 위해, 연자(ligatures)를 지원한다.

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

   • 각 글자에 대응하는 유일한 숫자
   • 대표적으로 US-ASCII, iso-8859, JIS X 0201, UCS 등이 있다.

4. 문자 인코딩 구조

   • 콘텐츠 비트들과 문자코드를 트랜스 코딩하는 알고리즘
   • 고정폭: 코딩된 문자를 고정된 길이의 비트로 표현. 공간을 낭비할 우려가 있다.
   • 가변폭(비모달): 다른 문자 코드번호에 다른 길이의 비트를 사용한다.
   • 가변폭(모달): 다른 모드로의 전환을 위해 'escape' 패턴을 사용한다. 이를 통해 복잡한 표기 체계를 효과적으로 지원해 줄 수 있다.
   • 8비트, UTF-8

5. 코드 공간(coding space)
   문자 코드 값으로 사용하려고 계획해 둔 정수의 범위

6. 코드 너비(coding width)
   각 문자 코드의 비트 개수

7. 사용가능한 문자 집합(character repertoire)
   글자들에 대한 특정한 작접 집합

8. 코딩된 문자 집합(coded character set)
   문자코드와 대응하는 실제 글자들의 집합

[Charset은 형편없는 이름이다]
엄밀히 말하면, MIME 차셋 값은 데이터 비트를 고유한 문자의 코드로 매핑하는 알고리즘의 이름이다. (문자 인코딩 구조 + 코딩된 문자 집합)

언어 태그와 HTTP

헤더를 통한 명시

• Content-Language
  해당 엔터티가 어떤 언어 사용자들을 대상을 하고있는지 서술하며, 여러 언어를 나열할 수도 있다.
• Accept-Language
  클라이언트가 선호하는 언어를 나타낸다.

언어 태그의 종류

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

  1. 첫 번째 서브태그는 주 서브태그라 불리며, 표준화 되어있다.
  2. 두 번째 서브태그는 선택적이고, 자신만의 이름 표준을 따른다.
  3. 세 번째부터는 등록되어있지 않다.
     

• 대소문자의 구분 및 표현
  무든 태그는 대소문자를 구분하지 않지만, 관용적으로 국가를 나타낼 때는 대문자, 언어는 소문자를 의미한다.

• IANA 언어 태그 등록
  첫 번째와 두 번째 언어 서브태그 값은 표준 문서들과 조직에 의해 정의되며, 표준 국가와 언어 값으로 구성될 수 없는 언어 태그들만이 등록될 필요가 있다.

• [첫 번째 서브태그: 이름공간]
  일반적으로 ISO 639 표준 언어 집합에서 선택된 언어 토큰
  'i' 일 경우 IANA에서 등록한 이름의 태그를 의미
  'x' 일 경우 특정 개인이나 집단의 비표준 확장 서브태그

• [두 번째 서브태그: 이름공간]
  두 글자일 경우 ISO 3166 국가 코드와 지역 표준 집합에서 선택된 국가 토큰
  3~8 글자일 경우 IANA 에 등록된 태그
  그 외에는 잘못된 값

• [나머지 서브태그: 이름공간]
  8자 이하의 알파벳과 숫자로 이루어지기만 하면 된다.

국제화된 URI

URI는 국제화를 별로 지원하지 않는다.

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

리소스 식별자의 가독성과 공유 가능성의 보장을 위해 ASCII 문자들의 제한된 집합으로 이루어 지게 되었다. -> 국제적 가독성은 떨어진다.

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

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

지원하지 않는 글자를 안전하게 URI에 삽입할 수 있는 방법

% + 두 개의 16진수 값

• 언 이스케이핑은 한 번만 해야하며, 이스케이프로 사용되지 않은 문자를 이스케이프 문자로 처리해 데이터의 손실이 발생할 수 있다.
• 또한, 이스케이프 값들은 US-ASCII 코드 범위에 있어야 한다.
• ASCII 문자열을 사용하여 URI 상의 다른 문자집합 글자를 표현할 수도 있으며, 이를 모달 전환이라고 한다.

기타 고려사항

국제화된 HTTP 애플리케이션을 작성할 때 명심해야 할 사항들

1. 헤더와 명세에 맞지 않는 데이터
   -> 헤더는 US-ASCII 문자집합의 글자로만 이루어져야 한다. (오래된 라이브러리들은 이 범위 밖을 지원하지 않을 수도 있다)
2. 날짜
   -> 올바른 GMT 형식을 따라야 한다. 다만, 이에 대해 클라이언트는 관대하게 처리할 필요가 있고, 서버는 보수적으로 다룰 필요가 있다.
3. 도메인 이름
   -> 국제화 문자를 포함하는 도메인 이름을 '국제화 도메인 이름'이라고 하며, 브라우저는 퓨니코드를 활용해 이를 지원한다.

[KarmaPol]

여러 언어와 문자로 된 국제 문서들의 처리 및 전송을 지원

국제적인 콘텐츠

클라이언트는 서버에게 어떤 언어를 이해할 수 있고, 어떤 알파벳의 코딩 알고리즘이 있는지 알려준다

• Accept-Language : fr, en; q=0.8 -> q는 품질 인자, fr = 1(기본값)로 프랑스어를 더 선호
• Accept-Charset : iso-8859-1, utf-8

문자집합과 HTTP

• HTTP charset
  엔터티 콘텐츠 비트를 특정 문자 체계의 글자들로 바꾸라고 지시
  데이터 비트 --인코딩-> 문자코드 --문자집합에서 검색-> 글자
• MIME charset
  특정 문자 인코딩과 특정 코딩된 문자 집합의 결합
  us-ascii, utf-8, euc-kr
• Content-Type: charset 헤더
  서버는 클라이언트에 MIME 차셋 태그 보냄
• Accept-Charset 헤더
  클라이언트는 서버에 어떤 문자체계 지원하는지 보냄

코딩된 문자집합

• US-ASCII - 모든 문자집합의 어머니
  코드 값 0~127만 사용, 7비트
• iso-8859
  국제적인 글쓰기를 위해 하이비트를 이용, 8비트
  iso-8859-1 서유럽어
• UTF-8
  아스키와의 호환성 확보
  비모달 가변길이
• euc-kr
  한글 인터넷 문서를 위한 가변길이 인코딩

언어 태그

• Content-Language 헤더
  서버가 제공하는 컨텐츠의 언어 표시
• Accept-Language 헤더
  클라이언트가 선호하는 언어 설정을 서버에 제공

하이픈으로 서브태그 (sgn-US-MA)
대소문자 구분 x, 관용적으로 대문자는 국가

국제화된 URI

URI는 국제화를 거의 지원 X -> US-ASCII의 부분집합으로 구성
URI에 한글이 포함되어있으면 아스키화 해야한다

이스케이핑

URI에 스페이스를 삽입하고 싶다면 아스키 코드 '%20'를 삽입해야한다

스프링 URI 아스키 변환

URI uri = new URI(originalUrl);  
String encodedUrl = uri.toASCIIString();