• 유니코드에 대해 . . . . 34 matches
       #keywords BOM,UCS-2,UTF-16,UTF-8,유니코드
       ''이 문서를 주의 깊게 읽으면 유니코드에 대한 이해를 크게 높일 수 있을 것입니다.''
       == 유니코드 개요 ==
       유니코드는 전 세계 모든 문자에 대해 플랫폼에 상관 없이, 프로그램에 상관 없이, 언어에 상관 없이 컴퓨터에서 일관되게 표현하고 다룰 수 있도록 설계된 산업 표준이다. 유니코드 컨소시엄에서 제정하며 유니코드 표준에는 ISO 10646 문자 집합, 문자 인코딩 방법, 문자 정보 데이터베이스, 문자들을 다루기 위한 알고리즘 등을 포함하고 있다.
       유니코드의 목적은 현존하는 모든 문자 인코딩 방법들을 유니코드로 교체하려는 것이다. 기존의 인코딩들은 그 규모나 범위 면에서 한정되어 있고, 나라마다 달라 서로 호환되지 않는 문제점이 있었다. 유니코드가 다양한 문자 집합들을 통합하는데 성공하면서 유니코드는 컴퓨터 소프트웨어의 국제화와 지역화에 널리 사용되게 되었다.
       {{{+1 유니코드 평면 }}}
       유니코드는 110만개 이상의 코드 포인트를 지정할 수 있다. 유니코드는 이 110만개 이상의 코드 포인트를 17개의 '평면(Plane)'으로 나누고 각 평면에서 256*256=65,536개의 문자를 지정할 수 있다. 0번 평면은 일반적으로 BMP(Basic Multilingual Plane)라고 부르는 평면으로 BMP에는 거의 모든 근대 문자와 특수 문자가 포함되어 있으며, 그 중 대부분은 한글과 한중일 통합 한자들로 이루어져 있다.
       < BMP(평면 0)의 유니코드 문자 배치 >
       2번 평면은 보조 상형 문자 평면(Supplementary Ideographic Plane, SIP)으로 초기 유니코드에 포함되지 않은 한중일 통합 한자를 주로 담고 있다.
       3번 평면인 3차 상형 문자 평면(Tertiary Ideographic Plane, TIP)은 갑골 문자, 금문, 소전 따위의 문자나 추가 한중일 통합 한자, 기타 옛 상형 문자 등을 위해 예약된 영역이다. 유니코드 7.0 현재 3번 평면에는 아무 문자도 지정되지 않았다.
       유니코드 4번 평면부터 13번 평면은 미지정 평면으로 현재 아무 문자나 기호도 지정되지 않았다.
       {{{+1 유니코드의 인코딩 방식들 }}}
       유니코드의 표현 방식은 유니코드 컨소시엄과 ISO 10646에 정의되어 있다. 대표적인 인코딩 방식은 UCS-2, UTF-8, UTF-16이 있다.
       UCS는 ISO/IEC 10646으로 정의된 문자 인코딩의 국제 표준이다. UCS는 유니코드 값을 그대로 표현하는 인코딩이다. 유니코드는 110만 개 이상의 사용 가능한 코드 영역이 있지만 일반적으로 첫 65535개(Basic Multilingual Plane, BMP, 기본 다국어 평면)만이 사용된다. 그리고 많은 코드 영역, 심지어 BMP 영역에서도 서로 다른 인코딩 형태와 미래의 확장성을 고려하여, 일부러 문자를 할당하지 않았다.
       UCS-2는 초기 유니코드 표현 방식 중 하나로 각 문자들을 0 ~ 65535(0xFFFF) 사이의 코드 값으로 매겨놓고, 각 문자를 두 바이트로 표현한다. BMP 코드 영역만 표현할 수 있고, BMP 밖의 영역은 표현이 불가능하다. UCS-2를 확장하여 BMP 밖의 영역도 표시가 가능하게 한 인코딩으로 UTF-16이 있다.
       UCS-4는 0xFFFFFFFF 까지의 코드 즉 4 바이트로 한 문자를 표현한다. 유니코드 값을 그대로 32비트로 표현한다. UTF-32도 같은 방식을 사용하는 인코딩이며 따라서 __USC-4와 UTF-32는 같다.__
       BMP를 벗어나는 문자는 서러게이트(Surrogate) 문자 영역에 해당하는 두 개의 16비트 문자로 변환되어 한 쌍(즉 32비트)이 그 문자를 표현한다. 유니코드의 기본 다국어 평면에 문자가 전혀 배정되어 있지 않은 영역이 2군데가 있는데 하나는 110110으로 시작하는 영역으로 U+D800부터 U+DB7F까지이고 다른 하나는 110111으로 시작하는 영역으로 U+DC00부터 U+DFFF까지의 영역이다. 전자는 High Surrogate 영역, 후자는 Low Surrogate 영역이라고 부른다. 따라서 UTF-16에서 110110이나 110111로 시작하는 경우 기본 다국어 평면 이외 문자라고 확신할 수 있을 것이다.
       UTF-8 인코딩은 유니코드 한 문자를 나타내기 위해 1바이트에서 4바이트까지를 사용한다. U+0000부터 U+007F범위에 있는 ASCII 문자는 UTF-8에서 1바이트 만으로 표시된다. 7비트 이상이 필요한 글자들은 다음 방식으로 바이트 수를 늘려간다.
       == 유니코드 정규화 ==
       유니코드 정규화(Unicode normalization 또는 Unicode equivalence)는 모양이 같은 문자가 여러 개 있을 경우, 이를 기준에 따라 하나로 통합해주는 일을 가리킨다. 예를 들어 유니코드는 미리 합쳐진(precomposed) 문자와 결합하는(combining) 문자가 공존하고 있다(예: 한글 자모 영역 [ㅎㅏㄴ]과 한글 음절 영역 [한]). 그리고 각 나라 마다 같은 한자에 대한 다른 코드 값을 가지고 있다(예: 한국어 亮 U+F977, CJKV 통합 한자 亮 U+4EAE). 이들을 적절한 방법으로 정규화하지 않으면 여러가지 문제가 생겨날 수 있다.
• bidi(Bidirectional)란 무엇인가 . . . . 12 matches
       초기 컴퓨터는 오직 한 가지 쓰기 체계를 지원하도록(일반적으로 오직 라틴 알파벳의 left-to-right 기반으로) 설정되었다. 새로운 문자셋과 문자 인코딩이 추가되면서 다른 left-to-right 언어 문장이 지원되었지만, 아랍어나 히브리어와 같은 right-to-left 문장을 지원하는 것은 쉽지 않은 일이었고, 두 가지를 섞어 쓰는 것은 실용적이지도 않았다. Right-to-left 문장 지원은 문자 안에 읽기 쓰기 순서를 저장하는 ISO/IEC 8859-6 과 ISO/IEC 8859-8 같은 인코딩에서 소개되었다. 이것은 간단하게 left-to-right 텍스트 방향을 반대로 바꿀 수 있었지만, 대신 left-to-right 문장을 정확히 보여주는 능력을 희생하게 되었다. 그리고 마침내 유니코드의 Bidirectional 문장 지원으로, 다른 텍스트 방향 문장이 같은 텍스트에 있어도 원래 언어의 텍스트 방향을 고려하지 않고 문장을 섞는 것이 가능해졌다. 유니코드 표준은 어떻게 RTL과 LTR이 섞인 문장을 인코딩하고 보여주는 방법에 대한 자세한 규칙과 완전한 BiDi 지원을 위한 기반을 제공한다.
       ## 유니코드 BiDi 지원
       유니코드 표준은 '논리적'으로 정렬된 문자들을 메모리에 가진다. 이는 '시각적'으로 나타나는 순서와 다른, 해석될 예정의 순서가 된다. 그리고 bidi 지원을 제공하기 위해 유니코드는 논리적 문자 순서를 어떻게 정확한 시각적 순서로 변환할 수 있는지에 대한 알고리즘을 규정했다. 이를 위해, 유니코드 인코딩 표준은 모든 문자를 네 가지 타입( 'strong', 'weak, 'neutral', 그리고 'explicit') 중 하나로 나눈다.
       명시적 포맷팅 문자("방향성 포맷팅 문자"라고 불리기도 한다.)는, 유니코드 알고리즘의 기본 동작에서 직접 순서를 수정할 수 있는 문자다. 이 문자들은 "marks", "embeddings", "isolates", 그리고 "overrides"로 세분화된다. 이 문자들의 효과는 단락 구분이 나오거나 "pop" 문자가 나올 때까지 지속된다.
       약한 문자가 다른 약한 문자 뒤에 오는 경우, 알고리즘은 첫번째 강한 이웃 문자를 본다. 때때로 이것은 의도하지 않은 표시 오류로 이어진다. 이러한 오류는 "의사 강한(pseudo-string)" 문자로 수정될 수 있는데, 이런 유니코드 제어 문자를 "mark" 라고 부른다. 마크 U+200E left-to-right mark, U+200F right-to-left mark 는 약한 문자가 쓰기 방향을 상속받는 위치에 삽입될 수 있다.
       "embedding" 방향성 포맷팅 문자는 고전적인 명시적 포맷팅의 유니코드 방식이며, 유니코드는 대신 "isolates" 를 권장하고 있다. 텍스트 일부의 "embeddings" 신호는 방향성이 다른 것으로 간주된다. embedding 포맷팅 범위 내의 문자는 주위의 텍스트와 독립적이지 않다. 또한, embedding 된 문자는 문자 바깥 순서에 영향을 줄 수 있다. 유니코드 6.3에서는 방향성 embedding은 대개 주위에 너무 강한 효과를 가져오며 따라서 필요 이상으로 사용하기 어렵다는 것을 밝혔다.
       "isolate" 방향성 포맷팅 문자는 텍스트 일부의 방향성을 주위와 분리되면서 다르게 처리되도록 신호한다. 유니코드 6.3은 새 문서는 방향성 embedding 대신 이것을 사용하도록 권장한다. "embedding" 방향성 포맷팅 문자와는 달리 "isolate" 문자는 텍스트 범위 바깥의 순서에 영향을 주지 않는다.
• Blog/2011-10 . . . . 5 matches
       {{{#!blog hyacinth 2011-10-18T16:57:52 유니코드
       윈도우는 유니코드를 사용할 때 UNICODE 매크로를 정의한다. Visual Studio는 C++ 프로젝트를 생성하면 UNICODE와 함께 _UNICODE를 정의한다.
       '' 유니코드 문자 집합 사용 구성 속성의 차이는 UNICODE와 UNICODE_ 매크로를 정의하는 것 뿐이다. ''
       텍스트를 읽고 처리해야하는 애플러케이션의 경우 파일을 읽고나서 텍스트가 ANSI 문자인지 유니코드 문자인지 판별할 수 있으면 매우 편리할 것이다.
       텍스트 파일의 경우 그 내용이 ANSI 문자인지 유니코드 문자인지 판단할 수 있는 안정적이고 빠른 방법이 없다. 그렇기 때문에 어떤 문자를 담고 있는지 판별하는 것은 매우 어려운 일이다. IsTextUnicode()는 전달된 버퍼의 내용을 통해 확률적statistical이고 규정deterministic에 의거한 방법을 활용한다. 이는 당연히 비과학적인 방법이고 잘못된 결과를 반환할 수 있다. 윈도우 API로는 드문 알고리즘으로 동작하는 함수이기에 재미있다. 버퍼 크기가 충분히 주어지면 더 정확한 값을 기대할 수 있다.
• Blog/2014-11 . . . . 5 matches
       {{{#!blog hyacinth 2014-11-23T18:00:30 유니코드 U+3000
       유니코드 U+3000에 대해서. 유니코드 U+3000[[footnote(WikipediaKo:유니코드_3000~3FFF)]]은 '　'라는 문자이고 보이는 대로 공백이다. 유니코드에 의미 없이 이런 문자를 넣은 건 아니고 일반적으로 쓰이는 공백 U+0020(Space)과 함께 U+3000은 한자문화권에서 공백이라는 설명이 붙어있다[[footnote(http://www.fileformat.info/info/unicode/char/3000/index.htm)]]. 띄어쓰기 용법이 없는 한자 문맥에서 이 공백은 '나대(挪擡)'를 나타내기 위한 문자이기도 하다.
• Blog/2015-02 . . . . 4 matches
       [16:24] 18<Yurumechan18> 유니코드 문자 체크라서
       파이썬 isnumeric()은 문자열이 유니코드 상에서 숫자 문자(u'四', u'¾' 분수, u'𐅉' 고대 그리스 숫자 (...) 등)로만 이루어져 있는지 판단하는 것이었는데 내가 의미를 잘못 생각했다. 쓸모있는 기능이긴 하지만 내가 필요했던 건 아니었다. 음수까지 대응할 수 있는 대안을 찾아봤는데 형 변환 할 때 예외처리를 사용하는 방법이 나아 보인다.
       다음은 C#에서 비동기로 HTTP 요청를 보내는 코드의 일부다. 머리 노란 애들이 작성한 코드를 볼 때 유니코드 인코딩 부분은 가장 찾기 흔한 실수 중 하나다.
       UTF-8에서 영어 알파벳은 1바이트기 때문에 postData.Length도 문제가 없었겠지만 바이트 스트림이라면 문자열 길이보다 길어질 수 있기 때문에 바이트 길이로 보내야 한다. 기껏 문자열에서 유니코드 바이트로 바꿔놓고 프로래머가 쓰다가 졸았나보다.
• LocalKeywords . . . . 2 matches
       dir 윈도 유니코드 커맨드
       BOM UCS-2 UTF-16 UTF-8 유니코드
• irc logs/2002-2010 . . . . 2 matches
       [14:05] <04hyacinth> 21세기를 살아가는 전문 개발자인 여러분이 문자, 문자집합, 인코딩, 유니코드를 모른다면 당신을 체포한 다음에 잠수함에서 6개월 동안 양파 껍질을 까는 벌칙을 줄 겁니다.
       [14:06] <04hyacinth> "에이, 설마하니 현대인 중에 유니코드도 지원하지 않는 걸 만드는 프로그래머가 있겠어요?"
• 정규표현식 . . . . 2 matches
       # 유니코드 환경에서는 \d 가 ASCII 숫자가 아닌 문자에도 매치될 수 있다.
       *이 코드는 유니코드 환경에서만 유효하다. 따라서 euckr로 인코딩 된 구문에서는 동작하지 않는다.
• 폰트에 대해 . . . . 2 matches
       ### 유니코드 폰트
       MS 오피스를 설치할 때 "다국어 기능 지원" 옵션을 선택하면 __Arial Unicode MS__ 라는 커다란 폰트 파일이 설치되는데, 이것이 유니코드 폰트다. 이 안에 전세계 모든 글자들이 다 들어있다.
• Blog/2014-09 . . . . 1 match
       ["유니코드에 대해"]
• C++/(Shell)바탕화면 아이콘 개체들 조회 . . . . 1 match
        case STRRET_WSTR: // 획득 문자열이 pOleStr 멤버에 있다. (유니코드)
• FrontPage . . . . 1 match
       ["유니코드에 대해"] [[HTML(<span class="blog-user">)]]September 23, 2014[[HTML(</span>)]]
• SAMISync . . . . 1 match
       Add: 유니코드 자막 지원
• Windows Via C/C++ . . . . 1 match
       * 윈도우(비스타 이상)는 유니코드 문자를 UTF-16으로 인코딩한다(UTF: Unicode Transformation Format).
• Windows dir 커맨드 유니코드 출력 . . . . 1 match
       #keywords dir,윈도,유니코드,커맨드
• irc logs/2013-2017 . . . . 1 match
       [18:51] 18<a3r018> 근데 MSSQL이나 오라클 같은건 유니코드같은경우 NCHAR 형 같은 별도형이 있는데
• omr1/3/001 . . . . 1 match
       유니코드, Unicode
• string wstring 상호 변환 . . . . 1 match
       마지막으로 안시와 유니코드 문자열의 간단한 변환은 vc 에서는 A2W(), W2A() 매크로를 이용하는 방법이 있습니다.

You can also click here to search title.