• 유니코드에 대해 . . . . 13 matches
       #keywords BOM,UCS-2,UTF-16,UTF-8,유니코드
       유니코드의 표현 방식은 유니코드 컨소시엄과 ISO 10646에 정의되어 있다. 대표적인 인코딩 방식은 UCS-2, UTF-8, UTF-16이 있다.
       UCS-2는 초기 유니코드 표현 방식 중 하나로 각 문자들을 0 ~ 65535(0xFFFF) 사이의 코드 값으로 매겨놓고, 각 문자를 두 바이트로 표현한다. BMP 코드 영역만 표현할 수 있고, BMP 밖의 영역은 표현이 불가능하다. UCS-2를 확장하여 BMP 밖의 영역도 표시가 가능하게 한 인코딩으로 UTF-16이 있다.
       == UTF-16 ==
       UTF-16은 기본 다국어 평면(BMP)에 해당하는 문자들은 그대로 16비트 값으로 인코딩된다[[footnote(이 경우 인코딩된 바이트 스트링의 엔디언만 조심하면 된다.)]]. 그리고 BMP에 포함되지 않는 문자들은 특별히 정해진 방식으로 32비트 인코딩된다.
       BMP를 벗어나는 문자는 서러게이트(Surrogate) 문자 영역에 해당하는 두 개의 16비트 문자로 변환되어 한 쌍(즉 32비트)이 그 문자를 표현한다. 유니코드의 기본 다국어 평면에 문자가 전혀 배정되어 있지 않은 영역이 2군데가 있는데 하나는 110110으로 시작하는 영역으로 U+D800부터 U+DB7F까지이고 다른 하나는 110111으로 시작하는 영역으로 U+DC00부터 U+DFFF까지의 영역이다. 전자는 High Surrogate 영역, 후자는 Low Surrogate 영역이라고 부른다. 따라서 UTF-16에서 110110이나 110111로 시작하는 경우 기본 다국어 평면 이외 문자라고 확신할 수 있을 것이다.
       UCS와 UTF-16의 문제점은 지나치게 많은 공간이 필요하다는 점과 기존 ASCII 체계와 호환성이 없다는 점이다. 첫 번째 문제는 컴퓨터 상에 존재하는 많은 글자들이 1바이트로 표현할 수 있는 글자들인데 이 글자들에 2바이트를 사용하는 것은 너무 낭비라는 지적이다. 두 번째 문제는 UCS-2나 UTF-16과 호환성을 위해서는 기존 문서들을 모두 변환해야하는데 이 역시 문제라는 지적이다. 이 두 가지 문제를 동시에 해결하는 인코딩 방식이 UTF-8이다.
       위 패턴을 사용하면 더 큰 코드 범위도 표시할 수도 있다. 하지만 원래 UTF-8은 6바이트까지의 코드 범위도 표현할 수 있었으나, 2003년 11월 RFC 3629에서 UTF-16으로 표현 가능한 상한선인 U+10FFFF 까지의 글자만 표시할 수 있도록 제한하게 되었다.
       유니코드 인코딩에서 문제가 되는 것은 바이트 순서 또는 엔디언이다. 즉 'A'를 00 48로 표현할 것인가 48 00으로 표현할 것인가? UTF-16, UTF-32 같은 인코딩에서는 엔디언의 종류에 따라 문자열의 값이 완전히 달라지므로, 문서의 엔디언을 구별할 수 있는 표식이 필요하다. 이에 따라 유니코드 문서 앞에 BOM 문자를 붙여, 엔디언을 구별한다.
       ||UTF-16 빅 엔디언||FE FF||
       ||UTF-16 리틀 엔디언||FF FE||
       http://ko.wikipedia.org/wiki/UTF-16
• LocalKeywords . . . . 1 match
       BOM UCS-2 UTF-16 UTF-8 유니코드
• Windows Via C/C++ . . . . 1 match
       * 윈도우(비스타 이상)는 유니코드 문자를 UTF-16으로 인코딩한다(UTF: Unicode Transformation Format).
• Windows dir 커맨드 유니코드 출력 . . . . 1 match
       open fList, '-|:encoding(UTF-16LE)', 'cmd /U /C dir /ad/s/w';

You can also click here to search title.