hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
고저 악센트 언어 언어
오래된 악센트 시스템은 성조적이고 자유롭다 (jágoda '딸기', malína '라즈베리', gospodár '주인, 영주'). 세 가지 종류의 악센트가 있다: 짧은 하강 (è), 긴 하강 (ȇ), 긴 상승 (é). 비최종 음절은 항상 긴 악센트를 가진다: rakîta '갑각류', tetíva '힘줄'. 짧은 하강 악센트는 항상 최종 음절에 있다: bràt '형제'. 악센트 간의 삼자 대립은 다음과 같은 경우에만 존재할 수 있다: deskà '판자' : blagọ̑ '상품, 물건' : gospá '숙녀'. 악센트는 굴절 패러다임 전체에서 이동할 수 있다: dȃr — darȗ, góra — gorẹ́ — goràm, bràt — bráta — o brȃtu, kráva — krȃv, vóda — vodọ̑ — na vọ̑do). 열린 -e-와 -o- (길거나 짧거나)와 닫힌 -ẹ-와 -ọ- (항상 길다) 사이의 구별이 이루어진다.
고저 악센트 언어 언어
스페인 북동부와 프랑스 남서부의 바스크어는 여러 가지 방언과 여러 가지 악센트 패턴을 가지고 있다. 서부 방언만이 성조 악센트를 가지고 있는 것으로 보이며, 동부 방언은 강세 악센트를 가지고 있다 (강세 악센트 방언도 서로 다르다). J.R. 후알데(J.R. Hualde)가 처음 제안한 분석에 따르면, 북부 비스카야 방언은 대부분의 명사가 절대격 단수 형태에서 악센트가 없지만, 첫 음절을 제외하고 단어 전체에 걸쳐 지속되는 기본 고음 성조 (아래 밑줄로 표시)를 가진다. 다음 예시는 게르니카 방언에서 가져온 것이다.
그러나 어휘 악센트가 있는 명사(종종 차용어)도 몇 개 있다. 일본어와 마찬가지로 악센트는 높은 음조 다음에 낮은 음조로 구성된다.
또한, 일부 접미사(모든 복수 접미사 포함)는 선행 악센트이며 접미사 앞 음절에 악센트를 유발한다.
다른 접미사들은 추가 악센트를 유발하지 않는다.
선행 악센트 접미사가 이미 악센트가 있는 단어에 추가될 경우, 첫 번째 악센트만 유지된다.
온다로아의 악센트는 유사하지만, 단어의 악센트가 있다면 항상 마지막에서 두 번째 음절에 나타난다.
고저 악센트 언어 언어
억양 연구에 따르면, 악센트가 없는 단어가 단독으로 발음되거나 동사 앞에 올 때, 마지막 음절(또는 온다로아에서는 마지막에서 두 번째 음절)에 악센트를 얻는다. 그러나 이는 어휘 악센트가 아니라 억양 악센트이다.
이러한 바스크어 방언에서 악센트 없는 단어 뒤에 악센트 있는 단어가 오면, 자동적인 고음은 악센트까지 고원(plateau) 형태로 계속된다.
악센트가 억양적일 때도 마찬가지이다. 다음 문장에서, 모든 단어는 동사 앞의 억양 악센트를 제외하고는 악센트가 없다.
악센트가 있는 단어가 강조될 때, 악센트가 있는 음절의 음높이가 높아지지만, 단어가 악센트가 없을 때는 해당 단어에 음높이 상승이 없고 악센트가 있는 단어에만 음높이 상승이 있다. 다음 구절에서 "존", "친구", "할머니" 중 어느 것을 강조하든 또는 아무것도 강조하지 않든, 오직 amúma "할머니"라는 단어만 악센트를 받는다.:{{{1}}}
고저 악센트 언어 언어
바스크어의 또 다른 고저 악센트 지역은 프랑스 국경 근처의 고이수에타와 레이차 마을이 있는 서부 나바라주에서 발견된다. 그곳에는 바스크어 중앙 방언처럼 모든 단어의 두 번째 또는 첫 번째 음절에 강한 강세 악센트가 있지만, 강세 위에 겹쳐진 음높이 대비도 있다. 즉, mendik (상승-하강-상승) "산" 대 mendik (상승-하강) "산들".
튀르키예어 악센트는 전통적으로 "강세"로 불려왔지만, 최근 연구에서는 어휘 악센트의 주요 상관관계가 실제로는 음높이라는 점을 지적했다. sözcükle "단어로"와 같은 단어에서, 강세가 있는 두 번째 음절은 다른 두 음절보다 음높이가 높지만, 강도(음량)는 낮다.(fig 8, p. 85)
고저 악센트 언어 언어
튀르키예어 단어 악센트는 특히 지리적 이름 (İstanbul, Ankara, Yunanistan "그리스", Adana), 외국 차용어 (salata "샐러드", lokanta "레스토랑"), 일부 고유 명사 (Erdoğan, Kenedi), 복합어 (başkent "수도"), 친척을 나타내는 일부 단어 (anne "어머니"), 특정 부사 (şimdi "지금", yalnız "오직")에서 발견된다. 또한 특정 접미사, 일부는 "선행 악센트"를 가지므로 앞선 음절에 악센트를 유발하는 접미사, 예를 들어 부정 접미사 -me-/-ma-, 의문 입자 mi?, 또는 연결 동사 -dir "이다" (gelmedi "그는 오지 않았다", geldi mi? "그가 왔는가?", güzeldir "아름답다")에 의해 발생하기도 한다.
악센트 음절은 다음 음절보다 음높이가 약간 높다. 다른 모든 단어는 단독으로 발음될 때 마지막 음절에 약간 높은 음높이를 갖거나 모든 음절이 평탄하게 발음된다.:{{{1}}}
고저 악센트 언어 언어
튀르키예어는 또한 구문 악센트와 초점 악센트를 가지고 있다. 구문의 첫 단어에 악센트가 있으면 보통 다음 단어 또는 접미사에 있는 악센트가 중화된다. 예를 들어, çoban salatası "양치기 샐러드", Ankara'dan da "앙카라에서도", telefon ettiler "그들은 전화했다"와 같이 하나의 악센트만 가진다.
튀르키예어에 일본어나 바스크어처럼 악센트 없는 단어가 있는지에 대한 논란이 있다. Levi (2005)와 Özçelik (2016)와 같은 일부 학자들은 arkadaş ("친구") 또는 geldi ("그가 왔다")와 같은 단어에서 때때로 들리는 마지막 높은 음높이를 단순한 구문 성조 또는 경계 성조로 본다.:{{{1}}} 반면 Kabak (2016)와 같은 다른 학자들은 이러한 단어의 마지막 악센트가 일종의 강세라는 전통적인 견해를 선호한다.
고저 악센트 언어 언어
페르시아어 단어의 악센트는 항상 "강세"로 불려왔지만, 최근 연구에서는 고저 악센트로 인식된다. 음향 연구에 따르면, 악센트 음절은 강세 악센트 언어의 강세 음절 특성(약간 더 높은 강도, 더 긴 길이, 더 열린 모음) 중 일부를 가지고 있지만, 그 효과는 강세 악센트 언어에서 일반적으로 예상되는 것보다 훨씬 적다. 주요 차이점은 음높이에 있으며, (L)+H* 윤곽을 가진다.
일반적으로 음높이는 음절의 끝(최종 음절인 경우) 또는 다음 음절에서 다시 하강한다.
페르시아어 명사와 형용사는 항상 마지막 음절에 악센트가 있다. 복수 접미사 -ha와 같은 특정 접미사는 악센트를 자신에게 이동시킨다.
소유격 및 부정 -i와 같은 다른 접미사는 접어이므로 악센트가 없다.
동사에서 과거 시제의 인칭 어미는 접어이지만 미래 시제에서는 악센트가 있다.
접두사가 추가되면 악센트는 첫 음절로 이동한다.
호격 (xânom! "부인!")과 때때로 다른 곳, 예를 들어 bale! "예" 또는 agar "만약"에서도 악센트는 첫 음절에 있다.
복합 동사에서는 악센트가 첫 번째 요소에 있다.
그러나 복합 명사에서는 악센트가 두 번째 요소에 있다.
고저 악센트 언어 언어
ezâfe 구성에서 첫 번째 명사는 선택적으로 악센트가 있지만 일반적으로 음높이를 잃는다.
단어가 강조될 때, 음높이가 높아지고, 뒤따르는 단어들은 보통 악센트를 잃는다.
그러나 다른 연구자들은 강조 후 단어의 음높이가 감소하지만 때때로 여전히 들릴 수 있다고 주장한다.
표준 일본어와 일본어의 특정 다른 변이형은 고저 악센트를 가지고 있는 것으로 기술되며, 방언마다 크게 다르다. 표준 일본어에서 "악센트"는 고저 악센트라기보다는 다운스텝으로 특징지을 수 있다. 단어의 음높이는 다운스텝에 도달할 때까지 상승하다가 급격히 하강한다. 두 음절 단어에서는 고-저와 저-고 사이에 대비가 발생한다. 악센트 없는 단어도 저-고이지만, 뒤따르는 접어의 음높이가 이들을 구별한다.
오사카시 악센트 (긴키 방언) (오른쪽 지도에서 빨간색으로 표시)는 일부 단어에서 단어의 첫 음절(도쿄 일본어에서는 악센트가 없으면 항상 낮음)이 높을 수 있다는 점에서 도쿄 악센트와 다르다. 따라서 단어 악센트의 전체 설명을 제공하려면 악센트(다운스텝)의 위치뿐만 아니라 첫 음절의 높이도 지정해야 한다.
고저 악센트 언어 언어
표준 (서울특별시) 한국어는 운율에만 음높이를 사용한다. 그러나 다른 몇몇 방언들은 중세 한국어의 고저 악센트 체계를 유지하고 있다.
대한민국 남동부 경상북도 방언에서는 어떤 음절이든, 그리고 첫 두 음절이 높은 음조의 형태로 고저 악센트를 가질 수 있다. 예를 들어, 삼음절 단어에는 네 가지 가능한 성조 패턴이 있다.:{{{1}}}
오어 (언어)의 상하이 방언은 고저 악센트의 특징을 가진 주변적으로 성조 언어이다.
닫힌 음절(성문 파열음으로 끝나는 음절)을 제외하면, 상하이어 단음절은 세 가지 성조 중 하나를 가질 수 있다: 고음, 중음, 저음. 성조는 단독으로 있을 때 윤곽을 가지지만, 다음 목적을 위해서는 무시할 수 있다. 그러나 저음 성조는 항상 유성음 뒤에만 나타난다. 따라서 유일한 성조 구별은 무성음 뒤와 모음으로 시작하는 음절에 있으며, 고음 성조와 중음 성조 사이의 이분법적 구별만 존재한다.
고저 악센트 언어 언어
다음절 단어에서 첫 음절의 성조가 단어 전체의 성조를 결정한다. 첫 성조가 고음이면 다음 음절은 중음이 된다. 중음 또는 저음이고 닫힌 음절이 아니면, 두 번째 음절은 고음이 되고, 다음 음절은 중음이 된다. 저음이고 닫힌 음절이면, 다음 음절은 중음이 된다. 따라서 상하이어의 성조를 나타내는 데는 고음 성조에 대한 표시만 필요하다.
반투어군은 약 550개의 언어로 구성된 큰 그룹으로, 아프리카 남부와 중부 대부분 지역에 퍼져 있다. 원시 반투어는 두 가지 성조, H와 L을 가졌다고 믿어진다. 위에서 정의된 고저 악센트 체계를 가졌던 것으로 보이지는 않는데, 이는 HL, HH, LH, LL과 같은 형태의 단어가 모두 발견되었기 때문이다: *káda "숯", *cómbá "물고기", *nyangá "뿔", *tope "진흙". 즉, *cómbá와 같은 단어는 두 개의 고음 성조를 가질 수 있었고, 다른 단어들은 하나의 성조를 가지거나 아예 가지지 않았다.:{{{1}}}
전각 문자와 반각 문자 (유니코드 영역)
전각 문자와 반각 문자(Halfwidth and Fullwidth Forms)는 U+FF00–FFEF 유니코드 영역으로, 전각 및 반각 문자를 모두 포함하는 이전 인코딩이 유니코드와 상호 손실 없이 변환될 수 있도록 제공된다. 이는 기본 다국어 평면의 마지막에서 두 번째 영역이며, U+FFF0–FFFF의 짧은 특수블록 영역이 뒤따른다. 유니코드 1.0에서의 블록 이름은 Halfwidth and Fullwidth Variants였다.
U+FF01–FF5E 범위는 ASCII 21부터 7E까지의 문자를 전각 형태로 재현한다. U+FF00은 전각 ASCII 20(공백 문자)에 해당하지 않는데, 그 역할은 이미 U+3000 "표의 공백"이 수행하고 있기 때문이다.
전각 문자와 반각 문자 (유니코드 영역)
U+FF61–FF9F 범위는 JIS X 0201 인코딩의 A1부터 DF까지를 전치한 형태로 가타카나의 반각 형태와 관련 문장 부호를 인코딩한다. 자세한 내용은 반각 가나를 참조한다.
U+FFA0–FFDC 범위는 한글에 대한 호환 자모 문자의 반각 형태를 1974 표준 레이아웃을 전치한 형태로 인코딩한다. 이는 한국어용 일부 IBM 인코딩(예: IBM 코드 페이지 933)의 매핑에 사용되며, 이는 시프트 아웃과 시프트 인 문자를 사용하여 겹 바이트 문자 집합으로 전환할 수 있게 한다. 겹 바이트 문자 집합에는 호환 자모가 포함될 수 있으므로, 왕복 호환성을 제공하기 위해 반각 변형이 필요하다.
U+FFE0–FFEE 범위는 전각 및 반각 기호를 포함한다.
전각 문자와 반각 문자 (유니코드 영역) 블록
이 영역에는 동아시아 문장 부호의 위치 변형을 위한 변이 시퀀스가 정의되어 있다. 이것들은 U+FE00 VARIATION SELECTOR-1 (VS01)과 U+FE01 VARIATION SELECTOR-2 (VS02)를 사용한다.
추가 변형은 짧은 대각선 획이 있는 전각 0에 대해 정의된다: U+FF10 FULLWIDTH DIGIT ZERO, U+FE00 VS1 (０︀).
전각 문자와 반각 문자 (유니코드 영역) 역사
다음 유니코드 관련 문서는 전각 및 반각 문자 영역의 특정 문자를 정의하는 목적과 과정을 기록한다.
문자 (유니코드)
유니코드에서 문자 또는 스크립트(script)는 하나 이상의 문자 체계에서 텍스트 정보를 나타내는 데 사용되는 자모 및 기타 서면 기호 모음이다. 일부 문자는 아르메니아어와 같이 하나의 문자 체계와 문자 언어만 지원한다. 다른 문자는 많은 다른 문자 체계를 지원한다. 예를 들어, 라틴 문자는 영어, 프랑스어, 독일어, 이탈리아어, 베트남어, 라틴어 자체 및 여러 다른 언어를 지원한다. 일부 언어는 여러 대체 문자 체계를 사용하므로 여러 문자도 사용한다. 예를 들어, 튀르키예어에서는 20세기 이전에 아랍계 문자가 사용되었지만 20세기 초에 라틴어로 전환되었다. 문자와 다소 보완적인 것은 기호와 유니코드 제어 문자이다.
문자 (유니코드)
통합 발음 구별 기호와 통합 문장 부호는 자주 "공통" 또는 "상속" 문자 속성을 가진다. 그러나 개별 문자는 종종 자체 문장 부호와 발음 구별 기호를 가지므로 많은 문자는 자모뿐만 아니라 발음 구별 기호 및 기타 표시, 문장 부호, 숫자 및 심지어 자체 특유의 기호와 공백 문자도 포함한다.
유니코드 는 102개의 현대 문자 및 70개의 고대 또는 역사적 문자를 포함하여 172개의 개별 문자를 정의한다. 더 많은 문자가 인코딩 과정에 있거나 로드맵에 잠정적으로 인코딩이 할당되었다.
문자 (유니코드) 정의 및 분류
여러 언어가 같은 문자를 사용할 때, 특히 발음 구별 기호 및 기타 표시에 있어서 자주 약간의 차이가 있다. 예를 들어, 스웨덴어와 영어는 모두 라틴 문자를 사용한다. 그러나 스웨덴어에는 문자 å (때로는 스웨덴어 O라고 불림)가 포함되어 있는 반면, 영어에는 그런 문자가 없다. 또한 영어는 어떤 문자에도 결합 링 위 발음 구별 기호를 사용하지 않는다. 일반적으로 같은 문자를 공유하는 언어는 많은 같은 문자를 공유한다. 스웨덴어와 영어 쓰기 체계의 이러한 주변적인 차이에도 불구하고, 이들은 같은 라틴 문자를 사용한다고 말한다. 따라서 유니코드 문자의 추상화는 기본적인 조직 기술이다. 다른 알파벳 또는 쓰기 체계 간의 차이는 여전히 존재하며 유니코드의 유연한 문자, 결합 표시 및 정렬 알고리즘을 통해 지원된다.
문자는 때때로 "문자"의 동의어로 취급된다. 그러나 이는 문자가 지원하는 특정 구체적인 문자 체계로도 사용될 수 있다. 예를 들어, 베트남어 문자 체계는 라틴 문자에 의해 지원된다. 문자 체계는 또한 하나 이상의 문자를 포함할 수 있다. 예를 들어, 일본어 문자 체계는 한자, 히라가나 및 가타카나 문자를 사용한다.
문자 (유니코드) 정의 및 분류
대부분의 문자 체계는 크게 여러 범주로 나눌 수 있다. 표어문자, 음절문자, 음소문자 (또는 분절문자), 아부기다, 아브자드 및 자질문자. 그러나 이들 중 어떤 기능도 주어진 문자 체계에서 다양한 비율로 발견될 수 있으며, 종종 시스템을 순수하게 분류하기 어렵게 만든다. 혼합물이 분류를 어렵게 만드는 시스템을 설명하기 위해 때때로 복잡계라는 용어가 사용된다.
유니코드는 수많은 문자를 통해 이러한 모든 유형의 문자 체계를 지원한다. 유니코드는 또한 다양한 문자와 유니코드 텍스트 처리 알고리즘 내에서 작동하는 방식을 구별하는 데 도움이 되는 추가 속성을 문자에 추가한다.
명시적 또는 특정 문자 속성 외에도 유니코드는 세 가지 특별한 값을 사용한다.
공통 (Common)
유니코드는 UCS의 문자를 단일 문자에만 할당할 수 있다. 그러나 많은 문자—정식 자연어 쓰기 체계의 일부가 아니거나 많은 쓰기 체계에 걸쳐 통합된 문자—는 둘 이상의 문자에 사용될 수 있다 (예: 통화 기호, 기호, 숫자 및 문장 부호). 이러한 경우 유니코드는 이들을 "공통" 문자 (ISO 15924 코드 "Zyyy")에 속하는 것으로 정의한다.
문자 (유니코드) 정의 및 분류
상속 (Inherited)
많은 발음 구별 기호 및 비간격 결합 문자는 둘 이상의 문자의 문자에 적용될 수 있다. 이러한 경우 유니코드는 이들을 "상속" 문자 (ISO 15924 코드 Zinh)에 할당한다. 이는 이들이 결합하는 기본 문자와 동일한 문자 클래스를 가지며, 따라서 다른 컨텍스트에서는 다른 문자에 속하는 것으로 처리될 수 있음을 의미한다. 예를 들어, U+0308  ̈  combining diaeresis는 U+0065 e latin small letter e와 결합하여 라틴어 ë를 생성하거나 키릴어 ё를 위해 U+0435 е cyrillic small letter ie와 결합할 수 있다. 전자의 경우, 기본 문자의 라틴 문자를 상속하는 반면, 후자의 경우, 기본 문자의 키릴 문자를 상속한다.
알 수 없음 (Unknown)
"알 수 없음" 문자 값 (ISO 15924 코드 Zzzz)은 할당되지 않은, 개인 사용, 비문자 및 대리 코드 포인트에 부여된다.
문자 (유니코드) 문자 내 문자 범주
유니코드는 각 문자에 대한 일반 범주 속성을 제공한다. 따라서 문자에 속하는 것 외에도 모든 문자는 일반 범주를 가진다. 일반적으로 문자는 대문자, 소문자 및 수정자 문자를 포함한 문자 문자를 포함한다. 일부 문자는 ǲ (U+01F2)와 같은 몇 가지 미리 구성된 합자체의 제목 대문자 문자로 간주된다. 이러한 제목 대문자 합자체는 모두 라틴어 및 그리스어 문자에 있으며 모두 호환성 문자이므로 유니코드는 작성자가 이들을 사용하지 않도록 권장한다. 미래에 새로운 제목 대문자 문자가 추가될 가능성은 낮다.
대부분의 문자 체계는 대문자와 소문자를 구별하지 않는다. 이러한 문자의 경우 모든 문자는 "기타 문자" 또는 "수정자 문자"로 분류된다. 유니한 한자와 같은 표의문자도 "기타 문자"로 분류된다. 그러나 라틴어, 키릴어, 그리스어, 아르메니아어, 조지아어 및 데저렛과 같이 대문자와 소문자를 구별하는 몇 가지 문자가 있다. 이러한 문자에서도 대문자도 소문자도 아닌 일부 문자가 있다.
문자 (유니코드) 문자 내 문자 범주
문자는 또한 표시 (발음 구별 기호 및 기타), 숫자 (숫자), 문장 부호, 구분자 (공백과 같은 단어 구분자), 기호 및 비그래픽 서식 문자와 같은 다른 일반 범주 문자를 포함할 수 있다. 이들은 해당 문자에 고유할 때 특정 문자에 포함된다. 이러한 다른 문자는 일반적으로 통합되어 문장 부호 또는 발음 구별 기호 블록에 포함된다. 그러나 어떤 문자 (공통 및 상속 문자 제외)의 문자 대부분은 자모이다.
문자 (유니코드) 인코딩된 문자 목록
version 16.0 기준 유니코드는 ISO 15924 목록을 기반으로 168개의 문자를 정의한다 ("별칭" 또는 "속성 값 별칭"이라고 함). 또한 유니코드는 미정 문자에 대한 ISO 15924의 Zyyy 코드에 "Common"을, 상속 문자에 대한 ISO 15924의 Zinh 코드에 "Inherited"를, 인코딩되지 않은 문자에 대한 ISO 15924의 Zzzz 코드에 "Unknown"을 할당한다. ISO 15924에 의해 정의되었지만 유니코드에서 사용되지 않는 문자 코드에는 Zsym (기호) 및 Zmth (수학 표기법)이 있다.
문자 (유니코드) 유니코드에 없는 문자
캘리포니아 대학교 버클리의 Mainz University of Applied Sciences, Nancy의 L’Atelier national de recherche typographique (ANRT)의 기여자들이 참여한 "Missing Scripts" 프로젝트는 현재 연구 상태에 따르면 총 294개의 인식된 문자 중에서 유니코드 표준에 아직 인코딩되지 않은 131개의 문자 목록을 작성했다.
문 타입
문 타입(moon type)은 라틴 문자에서 대부분 파생(그러나 단순화됨)된 돋을새김된 기호를 사용하여 맹인을 위한 문자이다. 지지자들은 점자보다 이해하기 쉽다고 주장하지만, 주로 성인이 되어 시력을 잃어 글자 모양에 대한 지식을 이미 가지고 있는 사람들이 사용한다.
문 타입 역사
문 타입은 이스트서식스주브라이턴에 거주하는 시각 장애인 영국인 윌리엄 문 (1818-1894)이 개발했다. 성홍열을 앓은 후, 문은 21세에 시력을 잃고 맹인 아동 교사가 되었다. 그는 그의 학생들이 기존의 양각 독서 코드를 배우는 데 큰 어려움을 겪고 있다는 것을 발견하고 "만지기에 개방적이고 명확한" 자신만의 시스템을 고안했다.
문은 1843년에 처음 자신의 아이디어를 구상하고 1845년에 이 체계를 발표했다. 문은 점자만큼 잘 알려져 있지는 않지만, 모든 연령대의 맹인이나 부분적으로 시력이 손상된 사람들을 위한 가치 있는 대체 촉각 독서 체계이다.
점자의 점 대신 문 타입은 돋을새김된 곡선, 각도 및 선으로 구성된다. 문자가 상당히 크고 절반 이상의 글자가 인쇄된 것과 강하게 유사하기 때문에 문 타입은 말년에 시력을 잃거나 촉각이 덜 예민한 사람들에게 특히 적합하다는 것이 밝혀졌다. 또한 추가적인 신체적 및 학습 장애가 있는 아동의 읽고 쓰는 능력을 위한 수단으로도 성공적이었다.
문 타입 역사
학교는 런던의 클리어비전 프로젝트에서 문 타입이 추가된 매우 간단한 어린이 도서를 빌릴 수 있다.
청나라 시대 중국 (닝포)에 있던 영국 기독교 선교사들은 문 타입을 사용하여 시각 장애인 현지인들에게 닝보를 읽는 법을 가르쳤다. 닝보 방언을 구사하는 선교사들은 수감자 대부분이 시각 장애인이었던 "가난한 노인을 위한 집"을 운영했다. 1874년에 한 영국 선교사가 젊은 시각 장애인에게 문 타입으로 쓰여진 로마자화된 닝보를 읽는 법을 가르쳤다. 그 후 루가의 복음서가 두 권의 큰 문 타입 책으로 필사되었다. 한 스위스 선교사는 닝보 전역에 방문하는 시각 장애인들에게 음식과 돈을 주겠다는 내용의 플래카드를 게시했다. 마르코의 복음서는 로마자화된 관화를 사용하여 문 타입으로 필사되었지만, 성조 표시는 없었다. 복음서 필사에 참여했던 선교사 허드슨 테일러는 로마자화된 닝보 방언은 성조 표시를 사용한 적이 없으므로 성조 표시가 필요하다고 생각하지 않았다. 그러나 유기음은 구별되었다.
문 타입 문자
점자와 마찬가지로 라틴 문자당 하나의 문 문자를 사용하는 1급과 축약형과 속기를 사용하여 텍스트를 더 간결하고 빠르게 읽을 수 있도록 하는 2급이 있지만, 더 많은 학습이 필요하다.
점자와 유사하게, 문 타입의 초기 버전은 "숫자 시작" 기호와 함께 처음 열 개의 문자를 숫자로 사용했다.
나중 버전에서는 각 숫자에 다른 기호를 사용했다(StaffsMaths). 이러한 기호는 인쇄하기에 더 복잡하다.
이 타입은 구두점도 포함한다.
선으로 형성된 원본 타입 외에도 특정 점자 엠보서를 사용하여 문 문자의 형태로 점 패턴(점자 문 또는 점선 문)을 생성할 가능성이 있다. 패턴은 5x5 그리드로 배치된다.
문 타입 방향
처음에는 텍스트 방향이 줄 끝에서 바뀌었다 (하지만 문자 방향은 바뀌지 않았다). 특별한 양각선이 줄의 끝과 다음 줄의 시작을 연결했다. 그러나 1990년경에 왼쪽에서 오른쪽으로 방향으로 바뀌었다.
문 타입 수용
영국 왕립 맹인 협회는 더 넓은 보편성을 위해 점자를 선호한다.
CESU-8
UTF-16용 호환 인코딩 체계: 8비트(Compatibility Encoding Scheme for UTF-16: 8-Bit, CESU-8)는 유니코드 기술 보고서 #26에 설명된 UTF-8의 한 변형이다. 기본 다국어 평면(BMP), 즉 U+0000부터 U+FFFF 범위의 유니코드 코드 포인트는 UTF-8과 동일한 방식으로 인코딩된다. 유니코드 보조 문자, 즉 U+10000부터 U+10FFFF 범위의 코드 포인트는 UTF-16에서처럼 먼저 서로게이트 쌍으로 표현된 다음 각 서로게이트 코드 포인트가 UTF-8로 인코딩된다. 따라서 CESU-8은 각 유니코드 보조 문자에 대해 6바이트(서로게이트당 3바이트)가 필요한 반면, UTF-8은 4바이트만 필요하다. 기술 보고서에는 명시되어 있지 않지만, 쌍을 이루지 않는 서로게이트도 각각 3바이트로 인코딩되며, CESU-8은 이전 UCS-2-UTF-8 변환기를 UTF-16 데이터에 적용하는 것과 정확히 동일하다.
CESU-8
유니코드 비BMP 문자의 인코딩은 11101101 1010yyyy 10xxxxxx 11101101 1011xxxx 10xxxxxx로 작동한다(yyyy는 문자에서 1을 뺀 상위 5비트를 나타낸다). UTF-8에서 사용되는 4바이트 인코딩을 시작하는 0xF0-0xF4 바이트 값은 CESU-8에 나타나지 않는다.
CESU-8은 유니코드 기술 보고서가 정보 문서일 뿐이므로 유니코드 표준의 공식적인 부분이 아니다. 내부 처리용으로만 사용해야 하며 외부 데이터 교환에는 사용해서는 안 된다.
W3C와 WHATWG HTML 표준은 HTML 문서에서 CESU-8을 지원하는 것을 금지한다. 이는 사이트 간 스크립팅 취약점을 야기할 수 있기 때문이다.
자바의 수정된 UTF-8은 NUL 문자(U+0000)를 두 바이트 시퀀스 C0 80으로 특수하게 오버롱 인코딩한 CESU-8이다.
오라클 데이터베이스는 "UTF8" 문자 집합에 CESU-8을 사용한다. 표준 UTF-8은 "AL32UTF8" 문자 집합을 사용하여 얻을 수 있다(오라클 버전 9.0부터).
유니코드 표준 압축 방식
유니코드 표준 압축 방식(Standard Compression Scheme for Unicode, SCSU)은 유니코드 텍스트를 표현하는 데 필요한 바이트 수를 줄이기 위한 유니코드 기술 표준이다. 특히 해당 텍스트가 주로 하나 또는 소수의 언어별 문자 블록의 문자를 사용하는 경우에 유용하다. 이 방식은 128~255 범위의 값을 특정 128개 문자 블록 내의 오프셋에 동적으로 매핑하는 방식으로 작동한다. 인코더의 초기 조건은 널, 탭, CR, LF 외의 C0 제어 코드를 포함하지 않는 ASCII 및 ISO-8859-1의 기존 문자열을 SCSU 문자열로 처리할 수 있음을 의미한다. 대부분의 알파벳이 연속적인 유니코드 코드 포인트 블록에 존재하므로, 소규모 알파벳과 ASCII 문장 부호 또는 주 알파벳의 창에 맞는 문장 부호를 사용하는 텍스트는 문자당 1바이트(설정 오버헤드 포함, 일반적인 언어의 경우 종종 1바이트에 불과함)로 인코딩될 수 있으며, 대부분의 다른 문장 부호는 비잠금 시프트를 통해 기호당 2바이트로 인코딩될 수 있다. SCSU는 또한 비알파벳 언어를 처리하기 위해 내부적으로 UTF-16으로 전환할 수 있다.
유니코드 표준 압축 방식 역사 및 사용
로이터는 원래 SCSU를 개발했으며, 당시에는 Reuters Compression Scheme for Unicode의 약어인 RCSU라는 이름으로 사용했다.
처음에는 유니코드 컨소시엄이 이를 문자 인코딩으로 간주했지만, 1999년에는 생각을 바꾸었다. 여전히 전송 인코딩 구문으로 간주되었지만, 잠시 동안은 다른 압축기가 동일한 텍스트에 대해 다른 출력을 생성할 수 있다는 이유로 더 이상 문자 인코딩으로 간주되지 않았다. 그러나 2004년에 이 결정은 번복되었고, 현재 SCSU는 단순 또는 복합 문자 인코딩 방식과 달리 압축 문자 인코딩 방식으로 간주된다.
로만 치보라(GNU 유니폰트의 저자)는 압축 해제기를 작성했다. IBM이 기여한 압축 해제기는 International Components for Unicode에서 자바로 작성된 압축기와 함께 찾을 수 있다. 더 간단한 참조 코덱은 TR6의 첨부 파일로 제공된다.
유니코드 표준 압축 방식 역사 및 사용
휴대폰 및 기타 모바일 장치를 위한 운영 체제인 심비안 OS는 SCSU를 사용하여 문자열을 직렬화한다.
SQL Server 2008 R2는 SCSU를 사용하여 nchar(n) 및 nvarchar(n) 열에 저장된 유니코드 값(여기서 UCS-2 인코딩의 문자열을 의미)을 압축하며, 데이터의 언어에 따라 15%에서 50% 사이의 공간 절약을 달성한다(UTF-8은 유니코드의 ASCII 부분 집합에 대해서만 50% 절감 효과를 제공한다).
유니코드 표준 압축 방식 방식
다음 섹션에서는 압축된 SCSU 스트림의 구성을 간략하게 설명한다. 전체 설명(압축 해제기와 일치)은 UTS #6 문서를 참조한다.
SCSU는 단일 바이트 모드에서 시작하며, 이 모드에서는 압축된 윈도우 인코딩을 사용한다. UTF-16BE "유니코드" 모드로 전환하고, 해당 모드에서 다시 단일 바이트 모드로 전환하는 명령이 존재한다.
SCSU의 핵심은 0x80-0xff 바이트의 의미가 정의되는 윈도우에 있다. 간단한 스크립트와 문장 부호를 위한 8개의 정적 윈도우와 더 많은 문자를 사용하는 스크립트를 위한 6가지 유형의 동적 윈도우(및 "하프 유니코드 블록" 윈도우와 보조 평면을 위한 사용자 정의 윈도우)가 있다.
간단한 윈도우와 동적 윈도우는 모두 특수 명령 문자를 통해 선택된다. 현재 블록에 맞지 않는 개별 문자의 경우, 인용을 위한 명령 문자가 제공된다.
유니코드 표준 압축 방식 범용 일반 텍스트 압축 방식과의 비교
UTF-16 또는 UTF-8 텍스트가 이전 유니코드 인코딩의 텍스트보다 더 많은 공간을 차지할 수 있기 때문에, 이 문제를 완화하기 위해 SCSU와 같은 압축을 사용할 수 있다. 범용 압축기와 비교할 때 SCSU를 사용하는 것이 반드시 유리한 것은 아니다. 또한, 텍스트 인코딩으로 사용될 수 있지만, 알고리즘의 상태 유지 특성 때문에 기본적인 텍스트 작업이 비자명해지므로 내부 텍스트 표현으로 사용할 때 어려움이 발생할 수 있다.
순수하게 압축 알고리즘으로 취급할 때, SCSU는 몇 킬로바이트 이상의 텍스트에 대해 대부분의 일반적으로 사용되는 범용 알고리즘보다 성능이 떨어진다.
SCSU는 길이가 몇 문자에 불과한 텍스트도 유용하게 압축할 수 있다는 장점이 있다. 반면 대부분의 대규모 압축기는 자체 오버헤드를 상쇄하기 위해 수백 바이트의 데이터가 필요하다. 심비안 OS에서는 작은 텍스트 문자열의 잘라내기, 복사 및 붙여넣기와 같은 클립보드 작업에도 SCSU가 사용된다.
유니코드 표준 압축 방식 HTML에서
W3C 및 WHATWG HTML 표준은 HTML 문서에서 SCSU 지원을 금지한다. 이는 HTML이 비 ASCII 호환 인코딩을 염두에 두고 설계되지 않았기 때문이다. 과거에는 브라우저의 이러한 인코딩 처리 미숙으로 인해 사이트 간 스크립팅 취약점이 시연된 바 있다.
유니코드와 전자우편
많은 이메일 클라이언트는 이제 유니코드에 대한 일부 지원을 제공한다. 일부 클라이언트는 메일 내용에 따라 레거시 인코딩과 유니코드 중에서 자동으로 선택하거나, 자동으로 또는 사용자가 요청할 때 선택한다.
비-ASCII 문자를 포함하는 메시지를 이메일로 보내기 위한 기술적 요구사항은 다음과 같다:
발신자 또는 수신자의 이메일 주소에 비-ASCII 문자가 포함된 경우, 메시지를 보내려면 이러한 문자를 메일 서버가 이해할 수 있는 형식으로 인코딩해야 한다.
유니코드와 전자우편 프로토콜 지원
RFC 6531은 SMTP 및 LMTP 프로토콜에서 UTF-8로 인코딩된 비-ASCII 이메일 주소를 허용하는 메커니즘을 제공한다.
유니코드와 전자우편 메시지 헤더
제목 줄, 발신자 및 수신자 이름과 같은 특정 이메일 헤더 필드에서 유니코드를 사용하려면 유니코드 텍스트를 문자 집합으로 유니코드 인코딩을 사용하여 MIME "인코딩된 단어"로 인코딩해야 한다. 이메일 주소의 도메인 부분에서 유니코드를 사용하려면 전통적으로 IDNA 인코딩을 사용해야 한다. 또는 SMTPUTF8은 이메일 주소(로컬 부분 및 도메인 이름 모두)와 메일 헤더 섹션에서 UTF-8 인코딩 사용을 허용한다. 원래 ASCII 전용 이메일 프로토콜에 비-ASCII 데이터 처리를 추가하기 위해 다양한 표준이 만들어졌다:
유니코드와 전자우편 메시지 본문
US-ASCII를 제외한 모든 인코딩과 마찬가지로 이메일에서 유니코드 텍스트를 사용할 때는 텍스트에 유니코드 변환 형식이 사용되고 있음을 지정하기 위해 MIME을 사용해야 한다.
구식 인코딩인 UTF-7은 구식의 비-8비트 클린 네트워크에서 유니코드 인코딩보다 이점이 있었다. 이는 레거시 인터넷 메일 서버의 7비트 한계 내에 맞추기 위해 전송 인코딩이 필요하지 않기 때문이다. 반면에 UTF-16은 SMTP 데이터 형식에 맞추기 위해 전송 인코딩되어야 한다. 엄격하게 요구되지는 않지만, UTF-8도 7비트 메일 서버에서 문제를 피하기 위해 일반적으로 전송 인코딩된다. UTF-8의 MIME 전송 인코딩은 이를 일반 텍스트로 읽을 수 없게 만들거나(베이스64의 경우), 일부 언어 및 텍스트 유형의 경우 크기 비효율적으로 만든다.
유니코드와 전자우편 메시지 본문
HTML, 포스트스크립트 및 서식 있는 텍스트 포맷과 같은 일부 문서 형식은 비-ASCII 문자에 대한 자체 7비트 인코딩 체계를 가지고 있으므로 특별한 이메일 인코딩을 사용하지 않고도 보낼 수 있다. HTML 이메일은 이메일의 HTML 원본 텍스트가 레거시 인코딩(예: 7비트 ASCII)일지라도 HTML 엔티티를 사용하여 유니코드의 어느 곳에서나 문자를 사용할 수 있다.
유니코드 글꼴
유니코드 글꼴 또는 유니코드 폰트(Unicode font)는 유니코드 표준에 정의된 코드 포인트에 자체를 매핑하는 컴퓨터 글꼴이다. 현대 컴퓨터 글꼴의 대부분이 유니코드 매핑을 사용하기 때문에 이 용어는 이제 구식이 되었다. 문자 단 하나에 대한 자체를 포함하거나 로마자 기본만 지원하는 글꼴도 마찬가지이다. 이 구분은 역사적인데, 유니코드 이전에는 대부분의 컴퓨터 시스템이 8비트 바이트만 사용하여 256자(또는 제어 코드) 이상을 인코딩할 수 없었기 때문이다. 이는 각 문자 레퍼토리가 자체 코드 포인트 할당을 가져야 함을 의미했으며 –  따라서 주어진 코드 포인트가 여러 의미를 가질 수 있었다. 유니코드는 고유한 할당을 보장함으로써 이 문제를 해결했다.
유니코드 글꼴
다양한 유니코드 문자열 및 유니코드 기호를 지원하는 글꼴은 "팬 유니코드 글꼴"이라고 불리기도 하지만, 트루타입 글꼴에서 정의할 수 있는 최대 자체 수는 65,535개로 제한되어 있으므로 단일 트루타입 글꼴이 정의된 모든 유니코드 문자에 대한 개별 자체를 제공할 수는 없다(유니코드 버전 17.0 기준 159,801자). 이 글은 비교적 많은 수의 광범위한 유니코드 문자를 지원하는 널리 사용되는 유니코드 글꼴(운영 체제와 함께 제공되거나 잘 알려진 상용 글꼴 회사에서 생산하는 글꼴)을 나열한다.
유니코드 글꼴 배경
유니코드  표준 자체는 자체라고 불리는 그래픽 모양의 모음인 어떤 글꼴(글꼴)도 지정하거나 생성하지 않는다. 오히려, 유니코드는 추상 문자를 특정 숫자(코드 포인트로 알려짐)로 정의하고, 자체(예: 결합 문자, 사전 구성된 문자 및 자모-발음 구별 기호 조합)가 사용되는 컨텍스트에 따라 필요한 모양 변경도 정의한다. 국제 문자 세트(UCS)의 추상 문자가 화면에 표시되거나 인쇄될 수 있는 비트맵 또는 벡터 출력으로 변환되는 방식을 결정하는 글꼴 선택은 사용자에게 달려 있다. 문서에 사용된 코드 포인트에 대한 자체를 포함하지 않는 글꼴이 선택되면, 일반적으로 물음표, 상자 또는 다른 치환 문자가 표시된다.
컴퓨터 글꼴은 문자를 표시하기 위해 다양한 기술을 사용한다. 비트맵 글꼴은 각 얼굴 및 크기의 각 자체 이미지를 형성하는 화소라고 알려진 점 그리드를 포함한다. 윤곽선 글꼴(또는 벡터 글꼴)은 각 자체를 설명하기 위해 그리기 지침 또는 수학 공식을 사용한다. 획 글꼴은 지정된 선(자체의 테두리용)과 프로필 또는 특정 얼굴 및 크기에서 선의 크기 및 모양을 정의하는 추가 정보를 사용하여 자체 모양을 설명한다.
유니코드 글꼴 배경
글꼴에는 특정 문자의 조합(및 동일한 문자에 대한 대체 기호)을 특수 합자 형태로 결합하기 위한 내장된 특수 맞춤법 규칙도 포함되어 있다. 운영체제, 웹 브라우저(사용자 에이전트), 및 기타 타이포그래피를 광범위하게 사용하는 소프트웨어는 화면이나 인쇄 매체에 텍스트를 표시하기 위해 글꼴을 사용하며, 이러한 내장 규칙을 사용하도록 프로그래밍될 수 있다. 또는 외부 스크립트 쉐이핑 기술(렌더링 기술 또는 "스마트 글꼴" 엔진)을 사용할 수 있으며, 큰 유니코드 글꼴을 사용하거나 다른 문자 또는 언어에 대해 여러 다른 글꼴을 사용하도록 프로그래밍될 수도 있다.
현행 개정판의 국제 문자 세트(유니코드) 표준에 정의된 모든 문자를 포함하는 단일 "유니코드 글꼴"은 없다. 이는 점점 더 많은 언어와 문자가 계속해서 추가되고 있으며, 일반적인 글꼴 형식은 65,535개 이상의 자체(유니코드에 인코딩된 문자 수의 약 절반)를 포함할 수 없기 때문이다. 결과적으로 글꼴 개발자와 글꼴 제작사는 글꼴의 최신 버전이나 개정판에 새 문자를 통합하거나 특정 언어 전용 보조 글꼴에 새 문자를 통합한다.
유니코드 글꼴 배경
UCS는 110만 개 이상의 코드 포인트를 가지고 있지만, 2000년 이전에는 처음 65,536개(평면 0: 기본 다국어 평면, 또는 BMP)만 일반적으로 사용되었다.
다른 평면에 대한 자세한 정보는 유니코드 평면 문서를 참조하라. 여기에는 평면 1: 보충 다국어 평면 (SMP), 평면 2: 보충 한자 평면 (SIP), 평면 14: 보충 특수 목적 평면 (SSP), 평면 15 및 16: 사설 사용 영역 (PUA)으로 예약됨이 포함된다.
최초의 유니코드 글꼴(매우 큰 문자 세트와 많은 유니코드 영역을 지원하는)은 루시다 산스 유니코드 (1993년 3월 출시), 유니한 글꼴 (1993), 그리고 에버슨 모노 (1995)였다.
유니코드 글꼴 문제점
유니코드에는 통합 한자 문자(중국어, 일본어, 한국어에서 볼 수 있는) 중 일부가 지역에 따라 서체적으로 달라지는 등의 타이포그래피적 모호성이 있다. 예를 들어, 유니코드 포인트 U+9AA8 骨 은 간체 중국어와 번체 중국어 사이에 서체적으로 다르다. 이는 단일 글꼴이 모든 로케일의 요구를 충족시킬 수 있다는 생각에 영향을 미친다.
유니코드의 디자인은 이러한 차이가 의미론적 모호성을 유발하지 않도록 보장하지만, 잘못된 형태의 사용은 종종 동아시아 언어의 원어민 독자들에게 시각적으로 어색하거나 미학적으로 부적절하게 간주된다.
유니코드 글꼴 유니코드 글꼴의 적용
유니코드는 이제 많은 새로운 표준 및 프로토콜의 표준 인코딩이며, 운영 체제(마이크로소프트 윈도우, 애플 매킨토시 OS, 그리고 많은 버전의 유닉스 및 리눅스), 프로그래밍 언어(에이다 (프로그래밍 언어), 펄, 파이썬, 자바 (프로그래밍 언어), 커먼 리스프, APL), 그리고 라이브러리(IBM 국제화 유니코드 구성 요소 (ICU)와 함께 Pango, 그래파이트, 스크라이브, 유니스크라이브, 그리고 ATSUI 렌더링 엔진), 글꼴 형식(트루타입 및 오픈타입) 등에 내장되어 있다. 다른 많은 표준들도 유니코드 준수를 위해 업그레이드되고 있다.
유니코드 글꼴 유틸리티 소프트웨어
다음은 글꼴 파일에 있는 문자를 식별할 수 있는 유틸리티 소프트웨어의 일부 선택 사항이다.
유니코드 글꼴 유니코드 글꼴 목록
사용 가능한 많은 유니코드 글꼴 중에서 아래 나열된 글꼴은 주류 컴퓨팅 플랫폼에서 전 세계적으로 가장 일반적으로 사용되는 글꼴이다.
비고
^‡ OTF+TTO: 오픈타입 글꼴 (트루타입 윤곽선 포함).
^‡ 오픈타입 글꼴은 때때로 일대일 커닝 쌍 테이블을 포함하지 않고, 유사한 문자 그룹이 하나의 커닝 그룹으로 간주되는 커닝-바이-클래스 테이블을 포함한다. 예를 들어, V와 W는 거의 동일한 왼쪽 및 오른쪽 기하학을 가진다. 따라서 "0"은 커닝이 지원되지 않음을 의미하지 않는다.
^⸶ "합리적인" 기간 (저자의 말) 후에 등록.
^⸷ WenQuanYi Bitmap Song 글꼴에서 27,000개 이상의 한자 자체를 포함한다.
유니코드 글꼴 유니코드 글꼴 목록
^⸸ Han Nom A는 주로 CJK U 상형 문자 확장 A를, Han Nom B는 주로 확장 B를 다룬다.
^§ Sun-Ext A는 102개의 다른 언어 블록을 다룬다. Sun-ExtB는 주로 CJK 보충, CJK U 상형 문자 확장 B, C, TaiXuan Jing을 다룬다.
^⸹ Zen Hei, Zen Hei Mono 및 Zen Hei Sharp는 단일 TTC 파일에 공존하며, 내장된 비트맵도 포함한다. 라틴어/한글은 UnDotum에서 파생되었고, 주음부호는 cwTeX에서 파생되었으며, 고정폭 라틴어는 M+ M2 Light에서 파생되었다. 전체 CJK 적용 범위. 페도라 리눅스, 우분투 리눅스에 포함됨.
유니코드 글꼴 글꼴 비교
아래에는 다양한 유니코드 영역에 대해 위에 언급된 글꼴 버전에 포함된 문자 수가 나열되어 있다. 로마자 기본 (128: 0000–007F)은 '로마자 기본'이라는 범위에 0부터 7F까지 번호가 매겨진 128개의 할당된 코드가 있음을 의미한다. 그런 다음 셀은 각 글꼴에 의해 다루어지는 코드의 수를 보여준다. 나열된 유니코드 영역은 유니코드 버전 8.0에 유효하다.
녹색으로 음영 처리된 셀은 완전한 범위를 나타낸다.
파란색으로 음영 처리된 셀은 완전하지는 않지만 나열된 글꼴 중 가장 완전한 글꼴이다.
빈 셀은 해당 블록에 문자가 없음을 나타낸다.
유니코드 글꼴 SMP 유니코드 글꼴 목록
나열된 유니코드 영역은 유니코드 버전 8.0에 유효하다.
유니코드 글꼴 SIP 유니코드 글꼴 목록
나열된 유니코드 영역은 유니코드 버전 8.0에 유효하다.
유니코드 글꼴 SSP 유니코드 글꼴 목록
나열된 유니코드 영역은 유니코드 버전 8.0에 유효하다.
양방향 텍스트
양방향 텍스트(bidirectional text)는 두 가지 텍스트 방향성, 즉 오른쪽에서 왼쪽으로 (RTL) 및 왼쪽에서 오른쪽으로 (LTR)를 포함한다. 일반적으로 다른 종류의 음소문자를 포함하는 텍스트를 의미하지만, 각 행의 텍스트 방향을 바꾸는 좌우 교대 서법을 지칭할 수도 있다.
예시는 RTL 히브리어 이름 사라(Sarah)이다: שרה. 오른쪽의 신(ש), 가운데의 레쉬(ר), 왼쪽의 헤(ה)로 철자가 쓰인다. 많은 컴퓨터 프로그램들은 텍스트를 한 방향으로만 표시하도록 설계되었기 때문에 이를 올바르게 표시하는 데 실패했다.
페르시아 문자 및 아랍어와 같은 소위 오른쪽에서 왼쪽으로 쓰이는 문자는 대부분, 그러나 전적으로 그렇지는 않지만, 오른쪽에서 왼쪽으로 쓰인다—수학적 표현, 숫자 날짜 및 단위가 있는 숫자는 왼쪽에서 오른쪽으로 삽입된다. 이는 영어와 같은 왼쪽에서 오른쪽으로 쓰이는 언어의 텍스트가 그 안에 삽입될 때도 발생하며, 반대로 아랍어가 영어와 같은 왼쪽에서 오른쪽으로 쓰이는 문자에 삽입될 때도 발생한다.
양방향 텍스트 양방향 스크립트 지원
양방향 스크립트 지원은 컴퓨터 시스템이 양방향 텍스트를 올바르게 표시하는 기능이다. 이 용어는 종종 "BiDi" 또는 "bidi"로 줄여서 쓰인다.
초기 컴퓨터 설치는 단일 문자 체계를 지원하도록 설계되었으며, 일반적으로 라틴 음소문자만을 기반으로 하는 왼쪽에서 오른쪽으로 쓰이는 문자에만 해당되었다. 새로운 문자 세트와 문자 인코딩을 추가하면 다른 여러 왼쪽에서 오른쪽으로 쓰이는 문자를 지원할 수 있었지만, 아랍계 문자 또는 히브리 문자와 같은 오른쪽에서 왼쪽으로 쓰이는 문자를 쉽게 지원하지 못했으며, 둘을 혼합하는 것은 실용적이지 않았다. 오른쪽에서 왼쪽으로 쓰이는 문자는 ISO/IEC 8859-6 및 ISO/IEC 8859-8과 같은 인코딩을 통해 도입되었으며, 글자를 (일반적으로) 쓰는 순서와 읽는 순서로 저장했다. 단순히 왼쪽에서 오른쪽으로의 표시 순서를 오른쪽에서 왼쪽으로의 표시 순서로 뒤집는 것이 가능하지만, 이렇게 하면 왼쪽에서 오른쪽으로 쓰이는 문자를 올바르게 표시하는 능력을 희생하게 된다. 양방향 스크립트 지원을 통해 쓰기 방향에 관계없이 같은 페이지에 다른 스크립트의 문자를 혼합할 수 있다.
양방향 텍스트 양방향 스크립트 지원
특히, 유니코드 표준은 왼쪽에서 오른쪽 및 오른쪽에서 왼쪽으로 쓰이는 스크립트의 혼합을 인코딩하고 표시하는 방법에 대한 자세한 규칙과 함께 완전한 BiDi 지원을 위한 기반을 제공한다.
양방향 텍스트 유니코드 bidi 지원
유니코드 표준은 문자가 '논리적으로', 즉 의도된 해석 순서대로 정렬되어야 하며, '시각적으로', 즉 보이는 순서대로 정렬되어서는 안 된다고 요구한다. 이 구분은 bidi 지원과 관련이 있는데, 어떤 bidi 전환에서도 시각적 표시는 '논리적'인 것이기를 멈추기 때문이다. 따라서 bidi 지원을 제공하기 위해 유니코드는 문자들의 논리적 순서를 올바른 시각적 표현으로 변환하는 알고리즘을 규정한다. 이를 위해 유니코드 인코딩 표준은 모든 문자를 '강한', '약한', '중립적인', '명시적 포맷팅'의 네 가지 유형 중 하나로 나눈다.
강한 문자는 명확한 방향을 가진 문자이다. 이 유형의 문자 예시에는 대부분의 알파벳 문자, 음절 문자, 한자, 비유럽 또는 비아랍 숫자, 그리고 해당 스크립트에만 특정적인 구두점 문자가 포함된다.
약한 문자는 모호한 방향을 가진 문자이다. 이 유형의 문자 예시에는 유럽 숫자, 동아랍어-인도 숫자, 산술 기호 및 통화 기호가 포함된다.
양방향 텍스트 유니코드 bidi 지원
중립 문자는 문맥 없이는 방향을 결정할 수 없는 문자이다. 예시에는 단락 구분 기호, 탭 및 대부분의 기타 공백 문자가 포함된다. 콜론, 쉼표, 마침표 및 줄 바꿈 없는 공백과 같이 여러 스크립트에 공통적인 구두점 기호도 이 범주에 속한다.
"방향성 포맷팅 문자"라고도 불리는 명시적 포맷팅 문자는 알고리즘이 기본 동작을 수정하도록 지시하는 특수 유니코드 시퀀스이다. 이러한 문자는 "마크", "포함", "격리" 및 "재정의"로 세분화된다. 그들의 효과는 단락 구분 기호 또는 "팝" 문자가 나타날 때까지 계속된다.
"약한" 문자가 다른 "약한" 문자 뒤에 오면 알고리즘은 첫 번째 인접한 "강한" 문자를 찾는다. 때때로 이것은 의도하지 않은 표시 오류로 이어진다. 이러한 오류는 "의사-강한" 문자로 수정되거나 방지된다. 이러한 유니코드 제어 문자를 마크라고 한다. 마크(U+200E  왼쪽에서 오른쪽으로 마크 (LRM) 또는 U+200F  오른쪽에서 왼쪽으로 마크 (RLM))는 묶인 약한 문자가 해당 쓰기 방향을 상속하도록 위치에 삽입되어야 한다.
양방향 텍스트 유니코드 bidi 지원
예를 들어, 아랍어(RTL) 구절에서 영어 상표명(LTR)에 대한 U+2122 ™ 상표 기호를 올바르게 표시하려면, 기호 뒤에 LTR 텍스트가 오지 않는 경우 상표 기호 뒤에 LRM 마크를 삽입한다 (예: "قرأ Wikipedia™‎ طوال اليوم."). LRM 마크를 추가하지 않으면 약한 문자 ™는 강한 LTR 문자와 강한 RTL 문자에 인접하게 된다. 따라서 RTL 문맥에서는 RTL로 간주되어 잘못된 순서로 표시된다 (예: "قرأ Wikipedia™ طوال اليوم.").
"포함" 방향성 포맷팅 문자는 명시적 포맷팅의 고전적인 유니코드 방법이며, 유니코드 6.3부터는 "격리"를 선호하여 사용이 권장되지 않는다. "포함"은 텍스트의 한 부분이 방향적으로 구별되게 처리되어야 함을 알린다. 포함 포맷팅 문자 범위 내의 텍스트는 주변 텍스트와 독립적이지 않다. 또한 포함 내의 문자는 외부 문자의 순서에 영향을 미칠 수 있다. 유니코드 6.3은 방향성 포함이 일반적으로 주변에 너무 강한 영향을 미쳐 불필요하게 사용하기 어렵다는 것을 인식했다.
양방향 텍스트 유니코드 bidi 지원
"격리" 방향성 포맷팅 문자는 텍스트의 한 부분이 주변 환경으로부터 방향적으로 격리되어 처리되어야 함을 알린다. 유니코드 6.3부터, 이들은 새 문서에서 사용이 권장되는 포맷팅 문자이다—대상 플랫폼이 이들을 지원하는 것으로 알려진 경우에 한해. 이 포맷팅 문자들은 방향성 포함이 일반적으로 주변에 너무 강한 영향을 미쳐 불필요하게 사용하기 어렵다는 것이 명확해진 후 도입되었다. 레거시 '포함' 방향성 포맷팅 문자와 달리 '격리' 문자는 범위 외부 텍스트의 순서에 영향을 미치지 않는다. 격리 문자는 중첩될 수 있으며, 포함 및 재정의 내에 배치될 수 있다.
"재정의" 방향성 포맷팅 문자는 부품 번호와 같은 특수한 경우에 사용될 수 있으며 (예: 영어, 숫자 및 히브리어 문자가 혼합된 부품 번호를 오른쪽에서 왼쪽으로 강제로 쓰도록), 가능한 한 사용을 피하는 것이 권장된다. 다른 방향성 포맷팅 문자와 마찬가지로 "재정의"는 서로 중첩될 수 있으며, 포함 및 격리 내에도 중첩될 수 있다.
양방향 텍스트 유니코드 bidi 지원
U+202D  를 사용하면 텍스트 방향이 왼쪽에서 오른쪽으로에서 오른쪽에서 왼쪽으로 전환된다. 마찬가지로 U+202E  를 사용하면 텍스트 방향이 오른쪽에서 왼쪽으로에서 왼쪽에서 오른쪽으로 전환된다. 유니코드 양방향 알고리즘을 참조하라.
U+202C  로 인코딩된 "팝" 방향성 포맷팅 문자는 가장 최근의 "포함", "재정의" 또는 "격리"의 범위를 종료한다.
알고리즘에서 연결된 강한 문자들의 각 시퀀스를 "실행(run)"이라고 한다. 동일한 방향을 가진 두 "강한" 문자 사이에 위치한 "약한" 문자는 그들의 방향을 상속한다. 다른 쓰기 방향을 가진 두 "강한" 문자 사이에 위치한 "약한" 문자는 주 문맥의 쓰기 방향을 상속한다 (LTR 문서에서는 문자가 LTR이 되고, RTL 문서에서는 RTL이 된다).
틀:Bidi Class (Unicode)
유니코드 양방향 문자는 트로이 목마 소스 취약점에 사용된다.
비주얼 스튜디오 코드는 2021년 10월에 출시된 버전 1.62부터 BiDi 제어 문자를 강조한다.
비주얼 스튜디오는 2021년 12월 14일에 출시된 버전 17.0.3부터 BiDi 제어 문자를 강조한다.