shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
홍콩식 영어의 어휘 단어에는 최소한 하나의 H(고음) 성조가 할당된다. 이음절 단어는 H-o (시계 방향), H-H (때때로), o-H (창조하다)와 같은 성조 패턴을 가질 수 있으며, 여기서 "o"는 무성조를 나타낸다. 삼음절 단어는 H-H-H (캥거루), H-H-o (필기), H-o-H (우회 도로), H-o-o (위협하다), o-H-H (180도 선회), o-H-o (필수적인), o-o-H (추천하다)와 같은 일곱 가지 가능한 성조 할당 중 하나를 받는다. 무성조 음절은 위치에 따라 다른 음높이 할당을 받는다. 단어 초성 무성조 음절은 M(중간) 성조이고, 발화 최종 무성조 음절은 저음이며, 단어 중간 무성조 음절은 커뮤니티의 두 주요 하위 방언에 따라 H 또는 M으로 나타난다. 홍콩식 영어 성조의 어휘적 규정이 {H, o} 배타적이므로, 홍콩식 영어를 고저 악센트 언어로 생각하기 쉽다. 그러나 홍콩식 영어를 어휘 성조를 가진 언어로 생각하는 것이 아마도 더 정확할 것이다.
남아프리카 영어.
광범위한 남아프리카 영어에서, (음성적으로 )는 종종 단어 초성 강세 음절(예: house)에서 삭제되지만, 적어도 그만큼 자주, 삭제된 것처럼 보여도 발음된다. 단어 초성 음절에서 뒤에 오는 모음은 종종 낮거나 낮게 상승하는 성조를 가진다. 빠른 발화에서는 이것이 삭제된 의 유일한 흔적일 수 있다. 잠재적인 최소 성조 쌍은 "oh" (중립적인 또는 고하강 ) 대 "hoe" (저음 또는 저상승 )와 같이 생성된다.
웨일스어에서는 강세 악센트가 보통 마지막에서 두 번째 음절에 온다 ( "웨일스어"와 같이 마지막 음절에 악센트가 있는 몇몇 예외는 있지만), 그리고 보통 낮은 음높이 뒤에 상승하는 음높이가 따라온다. "웨일스어에서 강세 음절은 덜 강세 받거나 강세 받지 않은 음절보다 낮은 음높이와 연관되어 있다... 그러나 웨일스어에서 강세 후 음절은 일반적으로 더 높은 음높이로 발음된다." 이는 웨일스어의 조상인 후기 브리튼어가 높은 음높이로 발음되는 마지막에서 두 번째 악센트를 가졌기 때문이라고 여겨진다. 단어의 마지막 모음이 사라지자 높은 음높이는 이제 마지막 음절에 남았지만, 강세는 새로운 마지막에서 두 번째 음절로 이동했다. 따라서 LHL은 LH로 변했으며, 강세는 낮은 음절에 있게 되었다.
고음이 단어의 마지막 음절에 있다고 흔히 말하지만, 앵글시 웨일스어에 대한 음향 연구에 따르면 적어도 그 방언에서는 음높이의 정점이 실제로는 마지막에서 두 번째 음절에 있었다고 한다. 따라서 마지막 두 음절은 L+H* L이었다.
야키어.
야키족은 주로 멕시코와 애리조나주에 거주하는 북아메리카 원주민이다. 약 17,000명의 사람들이 야키어를 구사한다고 알려져 있으며, 야키어는 유토아즈텍어족 언어이다.
야키어는 단어의 첫 번째 또는 두 번째 모라에 악센트가 있는 성조 악센트를 가지고 있다. 야키어에서 장모음은 두 모라를 가지며, 단모음이나 이중모음은 한 모라를 가진다. 악센트 후에 높은 성조는 단어 끝까지 매우 미세하게 하강하면서 계속된다.
단어의 약 3분의 2는 첫 번째 모라에 악센트가 있으며, 단어의 모든 성조는 높다.
일부 단어에서는 첫 모음이 길고 악센트가 두 번째 음절로 이동하며, 첫 음절의 모음은 짧아진다.
특정 종류의 중첩에서는 악센트가 첫 번째 모라로 이동하고, 다음 자음은 보통 두 배가 된다. 동시에 장모음은 악센트 뒤에 올 수 없으므로, 악센트 뒤의 모음도 짧아진다.
구의 끝에서는 음높이가 떨어지며, 낮은 경계 성조가 나타난다.
영어 사용자에게 야키어의 첫 고음은 "강세와 매우 비슷하게 들린다". 그러나 음향 연구에 따르면 악센트 음절의 진폭은 단어 내 다른 음절보다 실제로 크지 않다.
전각 문자와 반각 문자(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 범위는 전각 및 반각 기호를 포함한다.
이 영역에는 동아시아 문장 부호의 위치 변형을 위한 변이 시퀀스가 정의되어 있다. 이것들은 (VS01)과 (VS02)를 사용한다.
추가 변형은 짧은 대각선 획이 있는 전각 0에 대해 정의된다: U+FF10 FULLWIDTH DIGIT ZERO, U+FE00 VS1 ().
다음 유니코드 관련 문서는 전각 및 반각 문자 영역의 특정 문자를 정의하는 목적과 과정을 기록한다.
유니코드에서 문자 또는 스크립트(script)는 하나 이상의 문자 체계에서 텍스트 정보를 나타내는 데 사용되는 자모 및 기타 서면 기호 모음이다. 일부 문자는 아르메니아어와 같이 하나의 문자 체계와 문자 언어만 지원한다. 다른 문자는 많은 다른 문자 체계를 지원한다. 예를 들어, 라틴 문자는 영어, 프랑스어, 독일어, 이탈리아어, 베트남어, 라틴어 자체 및 여러 다른 언어를 지원한다. 일부 언어는 여러 대체 문자 체계를 사용하므로 여러 문자도 사용한다. 예를 들어, 튀르키예어에서는 20세기 이전에 아랍계 문자가 사용되었지만 20세기 초에 라틴어로 전환되었다. 문자와 다소 보완적인 것은 기호와 유니코드 제어 문자이다.
통합 발음 구별 기호와 통합 문장 부호는 자주 "공통" 또는 "상속" 문자 속성을 가진다. 그러나 개별 문자는 종종 자체 문장 부호와 발음 구별 기호를 가지므로 많은 문자는 자모뿐만 아니라 발음 구별 기호 및 기타 표시, 문장 부호, 숫자 및 심지어 자체 특유의 기호와 공백 문자도 포함한다.
유니코드 는 102개의 현대 문자 및 70개의 고대 또는 역사적 문자를 포함하여 172개의 개별 문자를 정의한다. 더 많은 문자가 인코딩 과정에 있거나 로드맵에 잠정적으로 인코딩이 할당되었다.
여러 언어가 같은 문자를 사용할 때, 특히 발음 구별 기호 및 기타 표시에 있어서 자주 약간의 차이가 있다. 예를 들어, 스웨덴어와 영어는 모두 라틴 문자를 사용한다. 그러나 스웨덴어에는 문자 å (때로는 스웨덴어 O라고 불림)가 포함되어 있는 반면, 영어에는 그런 문자가 없다. 또한 영어는 어떤 문자에도 결합 링 위 발음 구별 기호를 사용하지 않는다. 일반적으로 같은 문자를 공유하는 언어는 많은 같은 문자를 공유한다. 스웨덴어와 영어 쓰기 체계의 이러한 주변적인 차이에도 불구하고, 이들은 같은 라틴 문자를 사용한다고 말한다. 따라서 유니코드 문자의 추상화는 기본적인 조직 기술이다. 다른 알파벳 또는 쓰기 체계 간의 차이는 여전히 존재하며 유니코드의 유연한 문자, 결합 표시 및 정렬 알고리즘을 통해 지원된다.
문자 대 문자 체계.
문자는 때때로 "문자"의 동의어로 취급된다. 그러나 이는 문자가 지원하는 특정 구체적인 문자 체계로도 사용될 수 있다. 예를 들어, 베트남어 문자 체계는 라틴 문자에 의해 지원된다. 문자 체계는 또한 하나 이상의 문자를 포함할 수 있다. 예를 들어, 일본어 문자 체계는 한자, 히라가나 및 가타카나 문자를 사용한다.
대부분의 문자 체계는 크게 여러 범주로 나눌 수 있다. 표어문자, 음절문자, 음소문자 (또는 분절문자), 아부기다, 아브자드 및 자질문자. 그러나 이들 중 어떤 기능도 주어진 문자 체계에서 다양한 비율로 발견될 수 있으며, 종종 시스템을 순수하게 분류하기 어렵게 만든다. 혼합물이 분류를 어렵게 만드는 시스템을 설명하기 위해 때때로 복잡계라는 용어가 사용된다.
유니코드는 수많은 문자를 통해 이러한 모든 유형의 문자 체계를 지원한다. 유니코드는 또한 다양한 문자와 유니코드 텍스트 처리 알고리즘 내에서 작동하는 방식을 구별하는 데 도움이 되는 추가 속성을 문자에 추가한다.
특별 문자 속성 값.
명시적 또는 특정 문자 속성 외에도 유니코드는 세 가지 특별한 값을 사용한다.
문자 내 문자 범주.
유니코드는 각 문자에 대한 일반 범주 속성을 제공한다. 따라서 문자에 속하는 것 외에도 모든 문자는 일반 범주를 가진다. 일반적으로 문자는 대문자, 소문자 및 수정자 문자를 포함한 문자 문자를 포함한다. 일부 문자는 ǲ (U+01F2)와 같은 몇 가지 미리 구성된 합자체의 제목 대문자 문자로 간주된다. 이러한 제목 대문자 합자체는 모두 라틴어 및 그리스어 문자에 있으며 모두 호환성 문자이므로 유니코드는 작성자가 이들을 사용하지 않도록 권장한다. 미래에 새로운 제목 대문자 문자가 추가될 가능성은 낮다.
대부분의 문자 체계는 대문자와 소문자를 구별하지 않는다. 이러한 문자의 경우 모든 문자는 "기타 문자" 또는 "수정자 문자"로 분류된다. 유니한 한자와 같은 표의문자도 "기타 문자"로 분류된다. 그러나 라틴어, 키릴어, 그리스어, 아르메니아어, 조지아어 및 데저렛과 같이 대문자와 소문자를 구별하는 몇 가지 문자가 있다. 이러한 문자에서도 대문자도 소문자도 아닌 일부 문자가 있다.
문자는 또한 표시 (발음 구별 기호 및 기타), 숫자 (숫자), 문장 부호, 구분자 (공백과 같은 단어 구분자), 기호 및 비그래픽 서식 문자와 같은 다른 일반 범주 문자를 포함할 수 있다. 이들은 해당 문자에 고유할 때 특정 문자에 포함된다. 이러한 다른 문자는 일반적으로 통합되어 문장 부호 또는 발음 구별 기호 블록에 포함된다. 그러나 어떤 문자 (공통 및 상속 문자 제외)의 문자 대부분은 자모이다.
인코딩된 문자 목록.
유니코드는 ISO 15924 목록을 기반으로 168개의 문자를 정의한다 ("별칭" 또는 "속성 값 별칭"이라고 함). 또한 유니코드는 미정 문자에 대한 ISO 15924의 코드에 "Common"을, 상속 문자에 대한 ISO 15924의 코드에 "Inherited"를, 인코딩되지 않은 문자에 대한 ISO 15924의 코드에 "Unknown"을 할당한다. ISO 15924에 의해 정의되었지만 유니코드에서 사용되지 않는 문자 코드에는 (기호) 및 (수학 표기법)이 있다.
유니코드에 없는 문자.
캘리포니아 대학교 버클리의 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년경에 왼쪽에서 오른쪽으로 방향으로 바뀌었다.
영국 왕립 맹인 협회는 더 넓은 보편성을 위해 점자를 선호한다.
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 데이터에 적용하는 것과 정확히 동일하다.
유니코드 비BMP 문자의 인코딩은 codice_1로 작동한다(yyyy는 문자에서 1을 뺀 상위 5비트를 나타낸다). UTF-8에서 사용되는 4바이트 인코딩을 시작하는 0xF0-0xF4 바이트 값은 CESU-8에 나타나지 않는다.
CESU-8은 유니코드 기술 보고서가 정보 문서일 뿐이므로 유니코드 표준의 공식적인 부분이 아니다. 내부 처리용으로만 사용해야 하며 외부 데이터 교환에는 사용해서는 안 된다.
W3C와 WHATWG HTML 표준은 HTML 문서에서 CESU-8을 지원하는 것을 금지한다. 이는 사이트 간 스크립팅 취약점을 야기할 수 있기 때문이다.
자바의 수정된 UTF-8은 NUL 문자(U+0000)를 두 바이트 시퀀스 codice_2으로 특수하게 오버롱 인코딩한 CESU-8이다.
오라클 데이터베이스는 "UTF8" 문자 집합에 CESU-8을 사용한다. 표준 UTF-8은 "AL32UTF8" 문자 집합을 사용하여 얻을 수 있다(오라클 버전 9.0부터).
SCSU는 아래 뜻을 함의한다.
유니코드 표준 압축 방식(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 문자가 포함된 경우, 메시지를 보내려면 이러한 문자를 메일 서버가 이해할 수 있는 형식으로 인코딩해야 한다.
은 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)만 일반적으로 사용되었다.
최초의 유니코드 글꼴(매우 큰 문자 세트와 많은 유니코드 영역을 지원하는)은 루시다 산스 유니코드 (1993년 3월 출시), 유니한 글꼴 (1993), 그리고 에버슨 모노 (1995)였다.
유니코드에는 통합 한자 문자(중국어, 일본어, 한국어에서 볼 수 있는) 중 일부가 지역에 따라 서체적으로 달라지는 등의 타이포그래피적 모호성이 있다. 예를 들어, 유니코드 포인트 은 간체 중국어와 번체 중국어 사이에 서체적으로 다르다. 이는 단일 글꼴이 모든 로케일의 요구를 충족시킬 수 있다는 생각에 영향을 미친다.
유니코드의 디자인은 이러한 차이가 의미론적 모호성을 유발하지 않도록 보장하지만, 잘못된 형태의 사용은 종종 동아시아 언어의 원어민 독자들에게 시각적으로 어색하거나 미학적으로 부적절하게 간주된다.
유니코드 글꼴의 적용.
유니코드는 이제 많은 새로운 표준 및 프로토콜의 표준 인코딩이며, 운영 체제(마이크로소프트 윈도우, 애플 매킨토시 OS, 그리고 많은 버전의 유닉스 및 리눅스), 프로그래밍 언어(에이다 (프로그래밍 언어), 펄, 파이썬, 자바 (프로그래밍 언어), 커먼 리스프, APL), 그리고 라이브러리(IBM 국제화 유니코드 구성 요소 (ICU)와 함께 Pango, 그래파이트, 스크라이브, 유니스크라이브, 그리고 ATSUI 렌더링 엔진), 글꼴 형식(트루타입 및 오픈타입) 등에 내장되어 있다. 다른 많은 표준들도 유니코드 준수를 위해 업그레이드되고 있다.
유틸리티 소프트웨어.
다음은 글꼴 파일에 있는 문자를 식별할 수 있는 유틸리티 소프트웨어의 일부 선택 사항이다.
유니코드 글꼴 목록.
사용 가능한 많은 유니코드 글꼴 중에서 아래 나열된 글꼴은 주류 컴퓨팅 플랫폼에서 전 세계적으로 가장 일반적으로 사용되는 글꼴이다.
글꼴 비교.
아래에는 다양한 유니코드 영역에 대해 위에 언급된 글꼴 버전에 포함된 문자 수가 나열되어 있다. 로마자 기본 (128: )은 '로마자 기본'이라는 범위에 0부터 7F까지 번호가 매겨진 128개의 할당된 코드가 있음을 의미한다. 그런 다음 셀은 각 글꼴에 의해 다루어지는 코드의 수를 보여준다. 나열된 유니코드 영역은 유니코드 버전 8.0에 유효하다.
SMP 유니코드 글꼴 목록.
10000–1F9FF.
나열된 유니코드 영역은 유니코드 버전 8.0에 유효하다.
SIP 유니코드 글꼴 목록.
20000–2FFFF.
SSP 유니코드 글꼴 목록.
E0000–EFFFF.
양방향 텍스트(bidirectional text)는 두 가지 텍스트 방향성, 즉 오른쪽에서 왼쪽으로 (RTL) 및 왼쪽에서 오른쪽으로 (LTR)를 포함한다. 일반적으로 다른 종류의 음소문자를 포함하는 텍스트를 의미하지만, 각 행의 텍스트 방향을 바꾸는 좌우 교대 서법을 지칭할 수도 있다.
예시는 RTL 히브리어 이름 사라(Sarah)이다: . 오른쪽의 신(ש), 가운데의 레쉬(ר), 왼쪽의 헤(ה)로 철자가 쓰인다. 많은 컴퓨터 프로그램들은 텍스트를 한 방향으로만 표시하도록 설계되었기 때문에 이를 올바르게 표시하는 데 실패했다.
페르시아 문자 및 아랍어와 같은 소위 오른쪽에서 왼쪽으로 쓰이는 문자는 대부분, 그러나 전적으로 그렇지는 않지만, 오른쪽에서 왼쪽으로 쓰인다—수학적 표현, 숫자 날짜 및 단위가 있는 숫자는 왼쪽에서 오른쪽으로 삽입된다. 이는 영어와 같은 왼쪽에서 오른쪽으로 쓰이는 언어의 텍스트가 그 안에 삽입될 때도 발생하며, 반대로 아랍어가 영어와 같은 왼쪽에서 오른쪽으로 쓰이는 문자에 삽입될 때도 발생한다.
양방향 스크립트 지원.
양방향 스크립트 지원은 컴퓨터 시스템이 양방향 텍스트를 올바르게 표시하는 기능이다. 이 용어는 종종 "BiDi" 또는 "bidi"로 줄여서 쓰인다.
초기 컴퓨터 설치는 단일 문자 체계를 지원하도록 설계되었으며, 일반적으로 라틴 음소문자만을 기반으로 하는 왼쪽에서 오른쪽으로 쓰이는 문자에만 해당되었다. 새로운 문자 세트와 문자 인코딩을 추가하면 다른 여러 왼쪽에서 오른쪽으로 쓰이는 문자를 지원할 수 있었지만, 아랍계 문자 또는 히브리 문자와 같은 오른쪽에서 왼쪽으로 쓰이는 문자를 쉽게 지원하지 못했으며, 둘을 혼합하는 것은 실용적이지 않았다. 오른쪽에서 왼쪽으로 쓰이는 문자는 ISO/IEC 8859-6 및 ISO/IEC 8859-8과 같은 인코딩을 통해 도입되었으며, 글자를 (일반적으로) 쓰는 순서와 읽는 순서로 저장했다. 단순히 왼쪽에서 오른쪽으로의 표시 순서를 오른쪽에서 왼쪽으로의 표시 순서로 뒤집는 것이 가능하지만, 이렇게 하면 왼쪽에서 오른쪽으로 쓰이는 문자를 올바르게 표시하는 능력을 희생하게 된다. 양방향 스크립트 지원을 통해 쓰기 방향에 관계없이 같은 페이지에 다른 스크립트의 문자를 혼합할 수 있다.
특히, 유니코드 표준은 왼쪽에서 오른쪽 및 오른쪽에서 왼쪽으로 쓰이는 스크립트의 혼합을 인코딩하고 표시하는 방법에 대한 자세한 규칙과 함께 완전한 BiDi 지원을 위한 기반을 제공한다.
유니코드 bidi 지원.
유니코드 표준은 문자가 '논리적으로', 즉 의도된 해석 순서대로 정렬되어야 하며, '시각적으로', 즉 보이는 순서대로 정렬되어서는 안 된다고 요구한다. 이 구분은 bidi 지원과 관련이 있는데, 어떤 bidi 전환에서도 시각적 표시는 '논리적'인 것이기를 멈추기 때문이다. 따라서 bidi 지원을 제공하기 위해 유니코드는 문자들의 논리적 순서를 올바른 시각적 표현으로 변환하는 알고리즘을 규정한다. 이를 위해 유니코드 인코딩 표준은 모든 문자를 '강한', '약한', '중립적인', '명시적 포맷팅'의 네 가지 유형 중 하나로 나눈다.
강한 문자.
강한 문자는 명확한 방향을 가진 문자이다. 이 유형의 문자 예시에는 대부분의 알파벳 문자, 음절 문자, 한자, 비유럽 또는 비아랍 숫자, 그리고 해당 스크립트에만 특정적인 구두점 문자가 포함된다.
약한 문자.
약한 문자는 모호한 방향을 가진 문자이다. 이 유형의 문자 예시에는 유럽 숫자, 동아랍어-인도 숫자, 산술 기호 및 통화 기호가 포함된다.
중립 문자.
중립 문자는 문맥 없이는 방향을 결정할 수 없는 문자이다. 예시에는 단락 구분 기호, 탭 및 대부분의 기타 공백 문자가 포함된다. 콜론, 쉼표, 마침표 및 줄 바꿈 없는 공백과 같이 여러 스크립트에 공통적인 구두점 기호도 이 범주에 속한다.
명시적 포맷팅.
"방향성 포맷팅 문자"라고도 불리는 명시적 포맷팅 문자는 알고리즘이 기본 동작을 수정하도록 지시하는 특수 유니코드 시퀀스이다. 이러한 문자는 "마크", "포함", "격리" 및 "재정의"로 세분화된다. 그들의 효과는 단락 구분 기호 또는 "팝" 문자가 나타날 때까지 계속된다.
"약한" 문자가 다른 "약한" 문자 뒤에 오면 알고리즘은 첫 번째 인접한 "강한" 문자를 찾는다. 때때로 이것은 의도하지 않은 표시 오류로 이어진다. 이러한 오류는 "의사-강한" 문자로 수정되거나 방지된다. 이러한 유니코드 제어 문자를 마크라고 한다. 마크( 또는 )는 묶인 약한 문자가 해당 쓰기 방향을 상속하도록 위치에 삽입되어야 한다.
예를 들어, 아랍어(RTL) 구절에서 영어 상표명(LTR)에 대한 를 올바르게 표시하려면, 기호 뒤에 LTR 텍스트가 오지 않는 경우 상표 기호 뒤에 LRM 마크를 삽입한다 (예: "). LRM 마크를 추가하지 않으면 약한 문자 ™는 강한 LTR 문자와 강한 RTL 문자에 인접하게 된다. 따라서 RTL 문맥에서는 RTL로 간주되어 잘못된 순서로 표시된다 (예: ").
"포함" 방향성 포맷팅 문자는 명시적 포맷팅의 고전적인 유니코드 방법이며, 유니코드 6.3부터는 "격리"를 선호하여 사용이 권장되지 않는다. "포함"은 텍스트의 한 부분이 방향적으로 구별되게 처리되어야 함을 알린다. 포함 포맷팅 문자 범위 내의 텍스트는 주변 텍스트와 독립적이지 않다. 또한 포함 내의 문자는 외부 문자의 순서에 영향을 미칠 수 있다. 유니코드 6.3은 방향성 포함이 일반적으로 주변에 너무 강한 영향을 미쳐 불필요하게 사용하기 어렵다는 것을 인식했다.
"격리" 방향성 포맷팅 문자는 텍스트의 한 부분이 주변 환경으로부터 방향적으로 격리되어 처리되어야 함을 알린다. 유니코드 6.3부터, 이들은 새 문서에서 사용이 권장되는 포맷팅 문자이다—대상 플랫폼이 이들을 지원하는 것으로 알려진 경우에 한해. 이 포맷팅 문자들은 방향성 포함이 일반적으로 주변에 너무 강한 영향을 미쳐 불필요하게 사용하기 어렵다는 것이 명확해진 후 도입되었다. 레거시 '포함' 방향성 포맷팅 문자와 달리 '격리' 문자는 범위 외부 텍스트의 순서에 영향을 미치지 않는다. 격리 문자는 중첩될 수 있으며, 포함 및 재정의 내에 배치될 수 있다.
재정의.
"재정의" 방향성 포맷팅 문자는 부품 번호와 같은 특수한 경우에 사용될 수 있으며 (예: 영어, 숫자 및 히브리어 문자가 혼합된 부품 번호를 오른쪽에서 왼쪽으로 강제로 쓰도록), 가능한 한 사용을 피하는 것이 권장된다. 다른 방향성 포맷팅 문자와 마찬가지로 "재정의"는 서로 중첩될 수 있으며, 포함 및 격리 내에도 중첩될 수 있다.
유니코드를 사용하여 재정의.
를 사용하면 텍스트 방향이 왼쪽에서 오른쪽으로에서 오른쪽에서 왼쪽으로 전환된다. 마찬가지로 를 사용하면 텍스트 방향이 오른쪽에서 왼쪽으로에서 왼쪽에서 오른쪽으로 전환된다. 유니코드 양방향 알고리즘을 참조하라.
로 인코딩된 "팝" 방향성 포맷팅 문자는 가장 최근의 "포함", "재정의" 또는 "격리"의 범위를 종료한다.
알고리즘에서 연결된 강한 문자들의 각 시퀀스를 "실행(run)"이라고 한다. 동일한 방향을 가진 두 "강한" 문자 사이에 위치한 "약한" 문자는 그들의 방향을 상속한다. 다른 쓰기 방향을 가진 두 "강한" 문자 사이에 위치한 "약한" 문자는 주 문맥의 쓰기 방향을 상속한다 (LTR 문서에서는 문자가 LTR이 되고, RTL 문서에서는 RTL이 된다).
유니코드 양방향 문자는 트로이 목마 소스 취약점에 사용된다.
비주얼 스튜디오 코드는 2021년 10월에 출시된 버전 1.62부터 BiDi 제어 문자를 강조한다.
비주얼 스튜디오는 2021년 12월 14일에 출시된 버전 17.0.3부터 BiDi 제어 문자를 강조한다.
양방향 텍스트를 사용하는 문자.
신성문자.
이집트어 신성문자는 양방향으로 쓰였는데, 뚜렷한 "머리"나 "꼬리"를 가진 기호는 줄의 시작을 향했다.
한자 및 기타 CJK 문자.
한자는 특히 표지판(예: 명판)에서 어느 방향으로든 또는 수직으로(위에서 아래로, 그리고 오른쪽에서 왼쪽으로) 쓰일 수 있지만, 개별 문자의 방향은 변하지 않는다. 이는 중국의 관광 버스에서 흔히 볼 수 있는데, 회사 이름이 관례적으로 차량 앞쪽에서 뒤쪽으로—즉, 버스 오른쪽에서는 오른쪽에서 왼쪽으로, 버스 왼쪽에서는 왼쪽에서 오른쪽으로—쓰여 있다. 차량 오른쪽의 영어 텍스트도 종종 역순으로 쓰여 있다. (아래 관광 버스와 우편 차량 사진 참조.)
마찬가지로, 한중일 문자로 구성된 다른 CJK 문자들, 예를 들어 일본어 표기 체계와 한국어 표기 체계도 어떤 방향으로든 쓰일 수 있지만, 가로 왼쪽에서 오른쪽, 위에서 아래로, 그리고 세로 위에서 아래로 오른쪽에서 왼쪽으로가 가장 일반적인 두 가지 형태이다.
좌우 교대 서법.
좌우 교대 서법은 고대 그리스어 비문, 고대 사바어 (고대 남아랍어 언어) 및 로바쉬 문자에서 발견되는 쓰기 방식이다. 이 쓰기 방식은 방향을 번갈아 가며, 일반적으로 각 연속된 줄에서 개별 문자를 뒤집는다.
문 타입.
문 타입은 시각 장애인을 위한 촉각 알파벳으로 발명된 라틴 음소문자의 엠보싱 적응이다.
초기에는 줄 끝에서 텍스트 방향이 바뀌었다 (그러나 문자 방향은 바뀌지 않았다).
특수 엠보싱 선이 한 줄의 끝과 다음 줄의 시작을 연결했다.
1990년경에는 왼쪽에서 오른쪽으로 방향이 바뀌었다.
기능적 신경영상(functional neuroimaging)은 종종 특정 뇌 영역의 활동과 특정 정신 기능 간의 관계를 이해하려는 목적으로 뇌 기능의 한 측면을 측정하기 위해 신경영상 기술을 사용하는 것이다. 주로 인지신경과학, 인지심리학, 신경심리학, 사회신경과학 분야의 연구 도구로 사용된다.
기능적 신경영상의 일반적인 방법은 다음과 같다.
PET, fMRI, fNIRS 및 fUS는 신경 활동과 관련된 뇌 혈류의 국소적인 변화를 측정할 수 있다. 이러한 변화를 활성화라고 한다. 피험자가 특정 작업을 수행할 때 활성화되는 뇌 영역은 행동에 기여하는 신경 계산에서 역할을 할 수 있다. 예를 들어, 시각 자극이 포함된 작업(포함되지 않은 작업과 비교하여)에서는 후두엽의 광범위한 활성화가 일반적으로 관찰된다. 이 뇌 부분은 망막에서 신호를 받아 시각에 역할을 하는 것으로 여겨진다.
다른 신경영상 방법에는 EEG 및 MEG와 같이 전류 또는 자기장 기록이 포함된다. 서로 다른 방법은 연구에 다른 장점을 제공한다. 예를 들어, MEG는 높은 시간 해상도(밀리초 수준까지)로 뇌 활동을 측정하지만, 해당 활동의 위치를 파악하는 능력에는 한계가 있다. fMRI는 공간 해상도를 위한 뇌 활동 위치 파악에 훨씬 더 좋지만, 시간 해상도는 훨씬 낮다 반면 기능적 초음파 (fUS)는 흥미로운 시공간 해상도(전임상 모델에서 15 MHz로 100 마이크로미터, 100 밀리초까지)에 도달할 수 있지만, 신경혈관 결합에 의해 제한되기도 한다.
최근 자기 입자 이미징(Magnetic particle imaging)은 뇌 혈액량 증가를 기반으로 기능적 신경영상을 위한 충분한 시간 해상도를 가진 새로운 민감한 영상 기술로 제안되었다. 첫 전임상 시험에서 설치류의 기능적 영상이 성공적으로 입증되었다.
기능적 신경영상 주제.
특정 연구에서 사용되는 측정은 일반적으로 다루는 특정 질문과 관련된다. 측정 한계는 기술마다 다르다. 예를 들어, MEG와 EEG는 뉴런 집단이 활동할 때 발생하는 자기 또는 전기 변동을 기록한다. 이 방법들은 신경 사건의 시간 경과(밀리초 단위)를 측정하는 데 탁월하지만, 일반적으로 해당 사건이 발생하는 위치를 측정하는 데는 좋지 않다. PET와 fMRI는 신경 사건 근처의 혈액 구성 변화를 측정한다. 측정 가능한 혈액 변화는 느리기 때문에(초 단위) 이 방법들은 신경 사건의 시간 경과를 측정하는 데 훨씬 좋지 않지만, 일반적으로 위치를 측정하는 데 더 좋다.
전통적인 "활성화 연구"는 특정 작업과 관련된 뇌 활동의 분산된 패턴을 결정하는 데 중점을 둔다. 그러나 과학자들은 뇌의 여러 영역의 통합된 네트워크에 의해 많은 신경 처리가 수행되므로, 뚜렷한 뇌 영역 간의 상호 작용을 연구함으로써 뇌 기능을 보다 철저히 이해할 수 있다. 신경영상 연구의 활발한 분야는 공간적으로 멀리 떨어진 뇌 영역의 기능적 연결성을 조사하는 것을 포함한다. 기능적 연결성 분석은 특정 인지 또는 운동 작업 중 또는 단순히 휴식 중의 자발적 활동으로부터 지역 간 신경 상호 작용의 특성화를 가능하게 한다. fMRI와 PET는 기능적 네트워크라고 불리는 시간적으로 상관된 뇌 영역의 뚜렷한 공간 분포의 기능적 연결성 지도를 생성할 수 있다. 신경영상 기술을 사용한 여러 연구는 맹인 개개인의 후방 시각 영역이 점자 읽기, 기억 회상, 청각 위치 파악과 같은 비시각적 작업 및 기타 청각 기능 수행 중에도 활성화될 수 있음을 확립했다.
기능적 연결성을 측정하는 직접적인 방법은 뇌의 한 부분에 대한 자극이 다른 영역에 어떻게 영향을 미치는지 관찰하는 것이다. 이것은 PET, fMRI 또는 EEG와 같은 신경영상 도구 중 하나와 경두개자기자극술을 결합하여 인간에게 비침습적으로 수행할 수 있다. Massimini 등 (Science, 2005년 9월 30일)은 EEG를 사용하여 자극된 부위에서 활동이 어떻게 퍼지는지 기록했다. 그들은 비렘수면 동안 뇌가 자극에 활발하게 반응하지만, 기능적 연결성은 각성 상태보다 훨씬 약화된다고 보고했다. 따라서 깊은 수면 중에는 "뇌 영역들이 서로 소통하지 않는다"고 한다.
기능적 신경영상은 기술을 더욱 발전시키고 정교화하기 위해 인지신경과학 및 사회신경과학 외에도 신경해부학 및 신경생리학과 같은 다른 생물학 분야, 물리학 및 수학을 포함한 많은 분야의 데이터를 활용한다.
비판 및 신중한 해석.
기능적 신경영상 연구는 신중하게 설계되고 신중하게 해석되어야 한다.
통계적 매개변수 사상이라는 기술을 사용하여 통계적 분석이 종종 필요하여 뇌 내의 다양한 활성화 원천을 서로 구별할 수 있다.
이것은 개념화하기 어렵거나 쉽게 정의할 수 있는 작업이 없는 과정(예: 믿음 및 의식 (심리철학))을 고려할 때 특히 어려울 수 있다.
흥미로운 현상의 기능적 신경영상은 종종 언론에 인용된다.
한 경우에는 저명한 기능적 신경영상 연구자 그룹이 소위 신경정치학(neuropolitics) 연구에 대한 기명 논평 기사에 대한 응답으로 뉴욕 타임스에 편지를 쓰지 않을 수 없었다. 그들은 연구의 일부 해석이 "과학적으로 근거가 없다"고 주장했다.
해스팅스 센터는 2014년 3월 "신경영상 해석: 기술 및 그 한계에 대한 소개"라는 제목의 보고서를 발표했으며, 주요 신경과학자 및 생명윤리학자의 기사가 포함되었다. 이 보고서는 신경영상 기술을 간략하게 설명하고 주로 비판하지만, 현재 상태, 중요성 및 전망을 다소 옹호하기도 한다.
박막 광학(thin-film optics)은 다양한 재료의 매우 얇은 구조화된 층을 다루는 광학의 한 분야이다. 박막 광학을 나타내려면 재료 층의 두께가 결맞음 길이와 비슷해야 한다. 가시광선의 경우 두께 200~1000 nm 사이에서 가장 흔히 관찰된다. 이 규모의 층은 빛 파동의 간섭과 층, 공기 및 기판 사이의 굴절률 차이로 인해 현저한 반사 특성을 가질 수 있다. 이러한 효과는 광학 반사 및 투과 방식을 변경한다. 박막 간섭으로 알려진 이 효과는 비눗방울과 기름띠에서 관찰할 수 있다.
평면 층에 국한되지 않는 보다 일반적인 주기적 구조는 각도에 따라 더 복잡한 의존성을 갖는 구조색을 나타내며, 광결정이라고 알려져 있다.
제조에서 박막 층은 기판(보통 유리) 위에 하나 이상의 얇은 재료 층을 증착하여 얻을 수 있다. 이는 주로 증발 증착 또는 스퍼터 증착과 같은 물리 기상 증착 공정이나 화학기상증착과 같은 화학 공정을 사용하여 수행된다.
박막은 광학 코팅을 만드는 데 사용된다. 예로는 주택 및 자동차용 저방사율 유리창, 안경의 반사 방지 코팅, 자동차 헤드라이트의 반사 배플, 고정밀 광학 필터 및 거울 등이 있다. 이러한 코팅의 또 다른 응용 분야는 공간 필터링이다.
자연계의 예.
박막층은 자연계에서 흔하다. 그 효과는 비눗방울과 기름띠에서 볼 수 있는 색상뿐만 아니라 일부 동물의 구조색을 만들어낸다. 많은 곤충의 날개는 최소한의 두께 때문에 박막 역할을 한다. 이는 많은 파리와 말벌의 날개에서 명확하게 볼 수 있다. 나비의 경우, 박막 광학은 날개 자체가 날개 비늘로 덮여 있지 않을 때 눈에 띄는데, 이는 공작나비의 파란색 날개 반점과 청띠제비나비의 파란색-녹색 반점에서 볼 수 있다. 미나리아재비속의 꽃에서 꽃의 광택은 박막으로 인한 것으로, 수분하는 곤충에게 꽃의 가시성을 높이고 식물의 생식 기관의 온도 조절에 도움이 된다.
진주층(nacre 또는 mother-of-pearl)은 일부 연체동물이 조가비의 안쪽 층으로 생산하는 유기무기 복합 재료이다. 또한 진주가 구성되는 재료이기도 하다. 진주층은 강하고 탄력 있으며 훈색을 띤다.
진주층은 이매패류, 복족류 및 두족류의 가장 오래된 일부 계통에서 발견된다. 그러나 대부분의 연체동물 껍데기의 안쪽 층은 진주층이 아닌 도자기질이며, 이는 일반적으로 무지개색이 아닌 광택을 내거나, 고둥 진주에서 발견되는 불꽃 구조와 같은 비진주층성 훈색을 드물게 발생시킨다.
양식 진주의 바깥층과 진주 굴 및 담수진주 조개 껍데기의 안쪽 층은 진주층으로 만들어진다. 진주층 내부 껍데기 층을 가진 다른 연체동물과에는 전복과, 진주탑과 및 밤고둥과와 같은 해양 복족류가 포함된다.
구조와 외관.
진주층은 너비 10–20 μm, 두께 0.5 μm인 아라고나이트(탄산 칼슘의 한 형태)로 된 육각형의 판(tablets)으로 구성되어 연속적인 평행 엽상으로 배열되어 있다. 종에 따라 판의 모양은 다르다. 키조개에서는 판이 직사각형이며, 대칭적인 구역은 다소 용해성이 있다. 판의 모양에 관계없이, 판에 포함된 가장 작은 단위는 불규칙한 둥근 알갱이이다. 이 층들은 탄성 생체고분자(키틴, 루스트린 및 견섬유와 유사한 단백질 등)로 구성된 유기 매트릭스(계면) 층에 의해 분리된다.
진주층은 아라고나이트 판의 두께가 가시 빛의 파장과 비슷하여 훈색을 띤다. 이러한 구조는 다른 시야각에서 다른 파장의 빛과 건설적 및 파괴적으로 간섭하여 구조색을 생성한다.
결정학적 c-축은 껍데기 벽에 거의 수직이지만, 다른 축의 방향은 그룹마다 다르다. 인접한 판들은 c-축 방향이 상당히 다르며, 일반적으로 수직 방향에서 약 20° 이내로 무작위로 배열된 것으로 나타났다. 이매패류와 두족류에서는 b-축이 껍데기 성장 방향을 향하는 반면, 단판류에서는 a-축이 이러한 방식으로 기울어져 있다.