언어 문제는 전세계 언어의 표시, 문자, 문법 및 형식상 규칙이 서로 다름으로 인해 발생합니다.
양방향 인식
대/소문자
코드 페이지
복잡한 스크립트 인식
글꼴 크기
IME(Input Method Editor)
키보드
줄 바꿈 및 단어 바꿈
미러링 인식
유니코드
양방향 인식
Bidi(양방향)은 LTR(왼쪽에서 오른쪽) 및 RTL(오른쪽에서 왼쪽) 모두로 읽기/쓰기가 가능한 스크립트를 가진 텍스트를 설명할 때 사용되는 용어입니다. 영어와 아랍어로 혼합된 텍스트가 좋은 예입니다.
응용 프로그램이 양방향 인식이 되도록 하기 위해 염두에 두어야 할 몇 가지 문제가 있습니다.
- 내부 데이터 저장 — 위에서 언급한 대로, 양방향 텍스트는 LTR 및 RTL 스크립트입니다. 두 스크립트의 방향이 서로 다르더라도 모두 첫 번째 문자에서 마지막 문자까지 동일한 순서로 저장됩니다. 이러한 상황은 버퍼의 위쪽에서 아래쪽으로 저장되는 데이터와 유사합니다.
- 표시 스트림 — 대부분의 라틴어 기반 언어의 경우 한 번에 하나의 문자가 표시됩니다. 스크립트 방향을 규정하고 아랍어 연결선이 앞뒤의 문자에 따라 모양이 변경되는 등 문자 위치에 대한 Bidi 텍스트의 서로 다른 속성으로 인해 이러한 표시 공식이 바뀌었습니다. 이제, 현재 표시된 텍스트 줄을 버퍼에 저장한 다음 텍스트 줄에서 문자를 수정 또는 추가할 때마다 전체 버퍼를 출력하는 것이 최선의 방법입니다.
- 줄 길이 — 위에서 언급한 대로 연결선이 변경되기 때문에 캐싱된 문자 길이를 합산하여 텍스트 줄의 길이를 계산하는 것은 좋은 방법이 아닙니다.
대/소문자
ASCII에 내장된 기능은 영어 알파벳에서 해당 코드 포인트에 0x0020을 추가 또는 제거하여 각 문자의 소문자 및 대문자를 만들 수 있다는 것입니다.
A[0x0041] + 0x0020 = a[0x0061]
따라서, 대/소문자를 변환하는 작업은 간단한 더하기 또는 빼기 알고리즘이었습니다.
if ((c >= 'a') && (c <= 'z')) upper = c - 0x0020;
악센트가 있는 라틴어 문자(A[U+0102], a[U+0103])의 경우는 그렇지 않습니다. 문자의 대/소문자를 표현하기 위해 모든 문자에서 동일한 값을 더하거나 뺄 수 없습니다.
대/소문자 처리와 관련하여 알고리즘 방식이 모든 경우를 해결하지 못하는 몇 가지 이유가 있습니다.
- 일부 언어에서는 대문자와 소문자간에 1:1 대응이 이루어지지 않습니다. 예를 들면 다음과 같습니다.
- 유럽의 프랑스어 악센트 문자는 대문자에서 악센트가 없어집니다(é가 E로 됨). 그러나 캐나다 프랑스어 악센트 문자는 악센트가 유지됩니다(é가 É로 됨).
- 독일어 ß의 대문자는 SS입니다.
- 라틴어 스크립트가 아닌 대부분의 언어에서는 대/소문자라는 개념도 없습니다. 다음과 같은 언어가 여기에 해당됩니다.
코드 페이지
코드 페이지는 일정한 순서의 선택된 문자 코드(코드 포인트로 나타낸 문자) 목록입니다. 코드 페이지는 일반적으로 공용 쓰기 시스템을 공유하는 특정 언어 또는 언어 그룹을 지원하기 위해 정의됩니다. 모든 Windows 코드 페이지에는 256개의 코드 포인트가 포함되어 있습니다. 처음 127개 코드 포인트의 대부분은 동일한 문자를 나타냅니다. 이것은 연속성을 제공하고 기존 코드를 계속 유지할 수 있도록 해줍니다. 코드 페이지가 서로 다른 위치는 상위 128개의 코드 포인트 128-255(0 기반)입니다.
예를 들어, 코드 페이지 1253은 그리스어 쓰기 시스템에서 필요한 문자 코드를 제공합니다. 코드 페이지 1250은 영어, 독일어 및 프랑스어를 포함하는 라틴어 쓰기 시스템을 위한 문자를 제공합니다. 악센트 문자 또는 그리스어 문자를 포함하는 곳은 상위 128개의 코드 포인트입니다. 결국, 참조된 코드 페이지를 나타내는 식별자를 포함시키지 않으면 동일한 코드 스트림에 그리스어와 독일어를 저장할 수 없습니다.
중국어, 일본어 및 한국어에는 256개 문자보다 많은 문자가 포함되기 때문에 256개의 코드 포인트를 포함하는 코드 페이지의 개념을 기준으로 다른 문자 체계를 고안해야 했습니다. 그 결과로 만들어진 것이 DBCS(더블바이트 문자 집합)입니다.
DBCS에서는 한 쌍의 코드 포인트(더블바이트)가 각 문자를 표현합니다. 프로그래밍 인식 측면에서 첫 번째 바이트를 표현하기 위한 한 쌍의 코드 포인트 뒤에 정의된 두 번째 바이트가 따라오지 않을 경우 값으로 인식하지 못합니다. DBCS에는 이러한 한 쌍의 코드 포인트를 하나의 문자로 취급하는 코드가 필요했습니다. 이에 따라, 동일한 더블바이트 코드 포인트가 코드 페이지에 따라 서로 다른 문자를 나타내므로 아직도 일본어와 중국어와 같이 두 언어가 동일한 데이터 스트림에 올 수 없습니다.
복잡한 스크립트 인식
복잡한 스크립트에 필요한 특별한 프로세싱에는 문자 순서 재배열, 컨텍스트에 따른 모양 변경, 조합 문자 및 분음 표시, 특별한 단어 분리 및 맞춤 규칙, 커서 위치 조정, 잘못된 문자 조합 필터링 특성 중 하나 이상이 포함됩니다. 복잡한 스크립트로 간주되는 언어는 아랍어, 히브리어, 태국어, 베트남어 및 인도어 어족입니다.
다음 사항을 고려하는 것이 중요합니다.
- 입력된 텍스트를 표시할 때 한 번에 하나의 텍스트를 출력하지 마십시오.
- 문자/상형 문자 버퍼를 할당하기 위해 하나의 문자가 하나의 상형 문자와 동일하다고 간주하지 마십시오.
- 텍스트 줄 길이를 측정하기 위해 캐싱된 문자 너비를 합산하지 마십시오.
글꼴
Windows에는 특정 스크립트를 표시할 적절한 글꼴을 선택하는 기능이 있습니다. Windows에서는 MS Shell Dlg라는 새로운 서체 이름을 사용하여 이 기능을 수행합니다. MS Shell Dlg는 Windows에서 코드 페이지 1252에 포함되지 않은 문자를 가진 문화/로케일을 지원할 수 있도록 한 대응 메커니즘입니다. 이것은 글꼴은 아니지만 존재하지 않는 글꼴에 대한 서체 이름입니다. MS Shell Dlg 서체 이름은 현재 문화/로케일과 연결된 기본 셸 글꼴에 대응됩니다. 예를 들어, 미국 영어 Windows 98에서 이것은 MS Sans Serif에 대응되는 반면, 그리스어 Windows 98에서는 MS Sans Serif Greek로 대응됩니다. 미국 영어 Windows 2000의 경우는 Tahoma로 대응되는 반면, MS Shell Dig가 동아시아 언어 버전의 Windows 9x에서는 작동하지 않습니다. 자세한 내용은 지역화 및 셸 글꼴을 참조하십시오.
하지만, 응용 프로그램 개발자들은 종종 지역화 대비 응용 프로그램을 만들 때 글꼴을 과소 평가합니다. 글꼴을 다룰 때 고려해야 할 두 가지 문제는 다음과 같습니다.
- 하드 코딩된 글꼴 이름 — 유니코드를 사용함으로써 이제 수백 개가 아닌 수천 개의 서로 다른 문자를 다루게 되었습니다. 대부분의 글꼴은 모든 유니코드 문자 집합을 처리하지 못합니다. 따라서, 영어 문자만 표시하고 일본어 문자는 표시하지 못하는 글꼴 이름을 하드 코딩할 경우 지역화된 모든 일본어 문자가 제대로 표시되지 않습니다. 글꼴 이름을 하드 코딩하지 말아야 할 다른 이유는 원하는 글꼴이 텍스트를 표시하는 시스템에 존재하지 않을 수도 있기 때문입니다.
- 하드 코딩된 글꼴 크기 — 일부 스크립트는 다른 스크립트보다 복잡합니다. 이러한 스크립트를 제대로 표시하기 위해서는 더 많은 픽셀이 필요합니다. 예를 들어, 대부분의 영어 문자는 5x7 모눈에 표시가 가능하지만 일본어 문자의 경우 제대로 보기 위해서는 적어도 16x16 모눈이 필요합니다. 중국어는 24x24 모눈이 필요한 반면, 태국어의 경우 너비는 8 픽셀만 있으면 되지만 높이는 적어도 22 픽셀이 되어야 합니다. 따라서, 일부 문자는 작은 글꼴 크기에는 맞지 않을 수도 있다는 사실을 쉽게 이해할 수 있습니다.
글꼴 이름 및 크기를 처리하는 가장 좋은 방법은 이러한 것들을 또 하나의 지역화 가능한 리소스로 간주하는 것입니다. MS Shell Dlg를 사용하면 (모든 언어의) Windows NT/Windows 2000에서 (모든 언어의) 응용 프로그램을 실행하는 문제가 해결됩니다. 글꼴을 지역화 가능한 리소스로 설정하면 지역화 담당자가 지역화된 UI에 맞도록 글꼴을 변경하도록 하는 문제를 해결할 수 있습니다.
IME(Input Method Editors)
프론트 엔드 프로세서라고도 하는 IME(Input Method Editor)는 사용자가 표준 101키 자판을 사용하여 동아시아 언어에서 사용되는 수천 개의 문자를 입력할 수 있도록 해주는 애플릿입니다.
사용자는 부수, 발음 표기 또는 문자의 숫자 코드 페이지 색인 입력 방식으로 각 문자를 작성할 수 있습니다. IME는 널리 사용되고 있으며, Windows에는 각 대상 지역에서 가장 보편적으로 사용되는 입력 방식을 기반으로 하는 IME가 포함되어 있습니다.
IME는 키 입력을 표음/표의 문자 및 일반적으로 사용되는 표의 단어 사전으로 변환하는 엔진으로 구성됩니다. 사용자가 키를 입력하면 IME 엔진이 키 입력을 표의 문자로 변환을 시도합니다.
많은 표의 문자가 동일한 발음을 가지기 때문에 IME 엔진의 첫 번째 추천 문자가 항상 맞지는 않습니다. 추천 문자가 틀릴 경우 사용자는 동음 이의어 목록에서 선택할 수 있습니다. 그러면, 사용자가 선택한 동음 이의어가 다음부터 IME 엔진의 첫 번째 추천 문자가 됩니다.
표의 문자를 입력하기 위해 지역화된 자판을 사용할 필요가 없습니다. 지역화된 자판이 표음 음절(가나 또는 한글 등)을 직접 생성할 수 있지만,사용자는 라틴어 문자를 사용하여 표음 음절을 표현할 수 있습니다.
일본어에서 romaji는 가나를 표현하는 라틴어 문자입니다. 일본어 자판에는 사용자가 romaji와 가나 입력을 상호 전환할 수 있는 별도의 키가 포함되어 있습니다. 일본어 자판이 아닌 자판을 사용하고 있는 경우에는 romaji로 입력하여 가나를 표현할 수 있습니다.
Windows에서 실행되는 응용 프로그램에 대한 IME 지원 수준에는 지원하지 않음, 일부 지원 및 완전 사용자 지정 지원 등 세 종류가 있습니다. 응용 프로그램은 간단한 방법(예: 창 위치 조정)으로 IME 지원을 사용자 지정하거나 IME 사용자 인터페이스의 모양을 완전히 바꿀 수 있습니다.
- 지원하지 않음 — IME를 인식하지 못하는 응용 프로그램은 모든 IME 관련 Windows 메시지를 무시합니다. 싱글바이트 언어를 대상으로 하는 대부분의 응용 프로그램에서는 IME를 인식하지 못합니다. IME를 인식하지 못하는 응용 프로그램은 미리 정의된 전역 클래스인 IME를 통해 활성 IME의 기본 사용자 인터페이스를 상속 받습니다. 각 스레드에 대해 Windows에서는 IME 전역 클래스를 기반으로 자동으로 창을 만듭니다. IME를 인식하지 못하는 모든 스레드 창은 이 기본 IME 창을 공유합니다.
- 부분 지원 - IME를 인식하는 응용 프로그램은 시스템 기본 인터페이스에 의존하지 않고 자체적인 IME 창을 만들 수 있습니다. IME에 대한 부분적인 지원 기능이 포함된 응용 프로그램에서는 이러한 함수를 사용하여 IME 사용자 인터페이스 창의 스타일 및 위치를 설정합니다. 그러나 IME DLL에서 여전히 IME를 그리는 역할을 수행하기 때문에 IME 사용자 인터페이스의 일반적인 모양은 변하지 않습니다.
- 전체 지원 — 반면, IME를 완벽하게 인식하는 응용 프로그램은 IME DLL에서 IME 창 그리기(상태, 작성 및 후보 창)에 대한 모든 임무를 가져옵니다. 각 응용 프로그램에서는 화면 위치 결정 및 응용 프로그램에서 문자를 표시하기 위해 사용되는 글꼴 및 글꼴 스타일 선택을 포함하여 이러한 창의 모양을 완전히 사용자 지정할 수 있습니다. 이러한 특성은 주요 기능이 텍스트 조작이고 결과적으로 IME와의 부드러운 상호 작용으로 인해 사용자와 "자연스러운" 인터페이스를 만들 수 있는 문서 작성 프로그램 등에서 특히 편리하고 효과적입니다.
자세한 내용은 IME(Input Method Editor)를 참조하십시오.
줄 및 단어 바꿈
줄 바꿈 및 단어 잘림 방지 알고리즘은 텍스트 표시는 물론 텍스트 구문 분석에도 중요합니다. 서유럽 언어는 일반적으로 하이픈 넣기 규칙 또는 단어 경계를 기준으로 줄 바꿈이 이루어지고 공백(스페이스, 탭, 줄끝, 구두점 등)을 기준으로 단어 구분이 이루어집니다.
하지만, 아사아 DBCS 언어는 서유럽 언어에 적용되는 규칙과 매우 다릅니다. 예를 들어, 대부분의 서유럽 텍스트 언어와 달리 중국어, 일본어, 한국어 및 태국어에서는 언제나 공백을 사용하여 한 단어와 다음 단어를 구분하지는 않습니다. 태국어에서는 구두점도 사용하지 않습니다.
이러한 언어에 대해서는 지역화 대비 소프트웨어 응용 프로그램이 공백 문자 또는 표준 하이픈 넣기 규칙에 따라 단순하게 줄 바꿈 및 단어 구분을 처리할 수 없습니다. 즉, 다른 지침을 따라야 합니다.
예를 들어, kinsoku 규칙은 일본어 줄 바꿈을 결정합니다. 이 규칙에서는 몇 가지 예외가 있지만 두 개의 문자 사이에서 줄 바꿈을 처리할 수 있습니다.
- 텍스트 줄은 후행 문자와 분리할 수 없는 선행 문자(시작 인용 부호, 왼쪽 괄호, 통화 기호 등)로 끝날 수 없습니다.
- 텍스트 줄은 선행 문자와 분리할 수 없는 후행 문자(끝 인용 부호, 오른쪽 괄호, 구두점 등)로 시작할 수 없습니다.
- 일부 넘쳐나는 문자(구두점 문자)는 가로 텍스트의 경우 오른쪽 여백, 수직 텍스트의 경우 아래쪽 여백을 넘어갈 수 있습니다.
자판
자판 배열은 문화/로케일에 따라 다릅니다. 일부 문자가 다른 로케일의 자판 배열에는 존재하지 않을 수 있습니다. 바로 가기 키 조합을 지정할 경우, 특히, 바로 가기 키 조합을 Windows 2000 MUI(다국어 사용자 인터페이스)에서 사용할 때는 다른 로케일의 자판에서도 사용할 수 있도록 해야 합니다.
각 문화/로케일에서 서로 다른 자판을 사용할 수도 있으므로 바로 가기 키 조합에서 문자 대신 숫자와 기능 키(F4, F5 등) 사용을 고려해 볼 수 있습니다.
숫자와 기능 키 조합은 지역화할 필요가 없는 반면 문자 조합만큼 사용자에게 직관적이지는 않습니다. 일부 바로 가기 키는 특정 문화/로케일의 각 자판 배열에서 작동하지 않을 수 있습니다. 예를 들어, 서유럽 및 대부분의 아랍어 사용 국가/지역과 같이 일부 문화/로케일에서는 둘 이상의 자판을 사용합니다.
미러링 인식
RTL(오른쪽에서 왼쪽) 언어의 경우 텍스트 정렬 및 텍스트 읽기 순서가 오른쪽에서 왼쪽 방향일 뿐 아니라 UI 레이아웃도 이러한 방향을 따라야 합니다. 물론, 이 레이아웃 변경은 지역화된 RTL 언어에만 적용됩니다.
참고 .NET Framework는 미러링을 지원하지 않습니다.
아랍어 및 히브리어 Windows 98에서는 좌우 대칭과 관련된 문제를 해결하기 위해 미러링 기술이 도입되었습니다. Windows 2000에서도 동일한 기술을 사용합니다. 이를 통해, UI에 대해 완벽한 RTL 모양과 느낌을 줄 수 있습니다. Windows 98의 경우, 이 기술은 지역화된 아랍어 및 히브리어 운영 체제에서만 사용할 수 있었습니다. 하지만, Windows 2000 이상에서는 모든 버전의 운영 체제에서 미러링 인식이 가능하여 미러링 응용 프로그램을 쉽게 만들 수 있습니다.
좌표에 대한 혼동을 피하려면 왼쪽/오른쪽 개념을 근거리/원거리 개념으로 바꾸어 생각해 보십시오. 사실 미러링은 좌표 변환에 불과합니다.
- 원점(0,0)은 창의 오른쪽 위 모서리에 있습니다.
- X 배율 인수 = -1(즉, X의 값은 오른쪽에서 왼쪽으로 증가합니다).
다음 그림은 LTR에서 RTL로의 좌표 변환을 나타낸 것입니다.
응용 프로그램이 미러링을 지원하도록 재작성해야 하는 코드의 양을 최소화하기 위해서는 "GDI" 및 "User"와 같은 시스템 구성 요소를 수정하여 소유자가 직접 작성한 컨트롤 및 비트맵과 관련된 몇 가지 고려 사항 이외에는 추가적인 코드 변경 없이 미러링을 설정 및 해제할 수 있도록 합니다.
자세한 내용은 Window Features의 Window Layout and Mirroring을 참조하십시오.
유니코드
특정 시간에 모든 응용 프로그램은 텍스트 또는 숫자 데이터를 처리합니다. 과거에는 서로 다른 문화/로케일 언어가 요구될 경우 응용 프로그램에서 이 데이터를 내부적으로 표현하기 위해 다양한 인코딩을 사용했습니다. 하지만, 이러한 인코딩으로 인해 운영 체제 및 응용 프로그램에 따라 서로 다른 코드(유럽어를 위한 싱글바이트 버전, 동아시아 언어를 위한 더블바이트 버전 및 중동 언어를 위한 양방향 버전)가 필요했습니다. 이렇게 분리된 코드는 결국 데이터 공유 및 다국어 UI 지원을 어렵게 만들었습니다.
전역화의 목적은 지원되는 모든 문화/로케일에서 동일하게 잘 동작하는 코드를 작성하는 것이므로 제품에 필요한 모든 문화/로케일의 각 문자를 고유하게 표현할 수 있는 데이터 인코딩 방식이 반드시 필요합니다. 유니코드는 이러한 요구 사항을 만족합니다.
유니코드를 사용하면 동일한 언어 스트림에 서로 다른 언어를 저장할 수 있습니다. 이 하나의 인코딩은 64,000개 이상의 문자를 표현할 수 있습니다. 서로게이트를 활용하면 1,000,000,000개 이상의 문자 표현이 가능합니다. Windows에서 유니코드를 사용하면 한 문자를 표현하기 위해 더 이상 코드 페이지 또는 그룹 문자점을 참조할 필요가 없으므로 더 쉽게 지역화 대비 코드를 만들 수 있습니다.
유니코드는 45,000개 이상의 문자(1백만 개 문자 이상의 여유 공간 포함)에 대한 값을 표현할 수 있는 16비트 국제 표준 문자 인코딩입니다. 유니코드 텍스트는 일반적으로 다른 인코딩의 텍스트보다 처리가 쉽습니다. 또한, 인코딩할 문자를 추적하거나 해당 문자를 만든 인코딩 방식을 추적할 필요가 없습니다.
참고 유니코드를 사용하는 제품이 완전히 지역화 대비를 갖춘 것은 아닙니다. 사실, 코드에서 유니코드를 사용하도록 만든 것은 전체 작업의 10%에 불과합니다.
전세계 모든 문자를 표현하는 유니코드 인코딩을 사용함으로써 Windows 2000에서는 64개 이상의 스크립트와 수백 개의 언어를 지원할 수 있게 되었습니다.
참고 항목
전역화 및 지역화 문제