0xxxxxxx

110xxxxx 10xxxxxx

1110xxxx 10xxxxxx 10xxxxxx

11110zzz 10zzxxxx 10xxxxxx 10xxxxxx


UTF-8을 보면 아스키 코드와 혼동되지 않게 위해 저런식으로 한다는데 어차피 아스키 코드 맨 앞자리가 0인이상

그냥 시작코드가 1이면 2바이틀 읽고 10이면3바이트를 읽는 식으로 하면 되지 않나요? 굳이 왜 110,1110으로 하고 뒤에 이어지는 바이트들의 앞에 10을 붙이는 걸까요?


컴퓨터는..

0xxxxxxx

1xxxxxxx xxxxxxxx

10xxxxxx xxxxxxxx xxxxxxxx

11xxxxxx xxxxxxxx xxxxxxxx xxxxxxxx

..로 하면 혼동을 한다는 소린데 글자처리를 할때 '앞숫자가 1이면 2바이트로 끊고 10이면 3바이트로 끊어서 처리해라'가 사람인 제 눈으로 보기엔 오히려 더 알아보기 쉽고 효율적인데 도대체 무엇때문에 컴퓨터는 이것을 혼동한다는 건가요?


한글조합형 코드도 1xxxxxxx xxxxxxxx 이런식으로 앞 비트를 1로해서 2바이트씩 한글을 처리하는 방식인데 단점 중 하나가 2번째 바이트 첫자리에 0이 올 경우 아스키 코드랑 헷갈릴 수 있다고..


그런데 제가 한글97을 잘만 사용했었습니다. 그 단점이라는 것이 일종의 버그로 초창기에나 있었을 수 있던일이 아닐까 생각했는데 그래서 그걸 아는 사람이 단점으로 적어놓은 거라고요. 그런데 한참 뒤에 나온 UTF-8이 저런식으로 처리하는 것을 보면 진짜 컴퓨터가 혼동할 수도 있다는 건데 어차피 글자를 쓰면 여기서부터 여기까지는 글자다 라고 선언을 하지 않습니까. 따로 구분을 하는데 다른것과 뒤섞이는 것도 아니고. 1,2바이트를 섞어서 가져온다고 하더라도 어차피 아스키가 먼저오든 2바이트 코드가 먼저오든 첫자리숫자보고 판단하면 되는 거고


컴퓨터에서 데이터가 들어올때 8+8 8 8+/8 8 8+8/8 8... 뭐 이렇게 중간에 끊어진다해도 앞에 1붙었으니 그 다음에 오는 데이터 가지고 합쳐서 처리하면 될 것 같은데 말이죠.


한글97은 조합형으로 에러없이 잘만 사용되었는데 도대체 아스키랑 혼동될 수 있다는 것은 우리나라 얘기가 아니라 다른 나라 사람들이 그렇게 읽을 수 있다는 걸까요. 당시에는 각자 나라마다 인코딩도 종류별로 있었으니까요. 그나라 사람들 컴퓨터는 한글조합형에 대해 모르니 1xxxxxxx xxxxxxxx 의 첫번째 바이트는 자기나라가 쓰는 아스키 확장으로 읽고 2번째 바이트는 아스키코드나, 아스키 확장으로 읽는다. 그래서 혼동될 수 있다는 것은 애초에 한글조합형을 구현할 수 없는 컴퓨터의 얘기니 단점일 수 없다???????\


UTF-8이 이런 성질을 가지도록 설계한 까닭은 어떤 경우에도 한 문자에 대한 바이트 표현이 다른 문자에 대한 바이트 표현의 일부가 되는 경우가 없도록 하기 위함이다. 따라서 텍스트 안에 들어 있는 다른 텍스트를 찾는 데 쓰이는 바이트 단위의 부문자열 매칭이 UTF-8 문자열에서도 쓰일 수 있다. 통합 완성형, 상용 조합형, Shift JIS, Big5과 같이 ISO 2022 체계에 부합하지 않는 이전의 가변 길이 인코딩은 그런 성질을 지니지 않았고 (기존 인코딩 가운데 EUC-KR이나 EUC-JP 등은 이 점에서는 UTF-8과 비슷한 성질을 지닌다.), 더 복잡한 알고리즘을 써야 했다. 왜냐하면, 이들 인코딩은 ASCII 영역의 글자를 나타내는 바이트를 2바이트로 나타내는 다른 글자의 두 번째 바이트로 사용하기 때문이다. 또한, UTF-8에서 하나 이상의 바이트들이 손실되었을 때도, 다음의 정상 문자를 찾아서 동기화할 수 있기 때문에 피해를 줄일 수 있다.

그 설계 때문에 어떤 바이트들이 올바른 UTF-8로 확인되면, 그 문자열이 실제로 UTF-8로 인코딩되었을 가능성이 매우 높다. 임의의 바이트들이 순수한 ASCII 인코딩이 아닌 UTF-8 문자열일 가능성은 2바이트 문자의 경우 1/32, 3바이트 문자의 경우 5/256으로 매우 낮다. 또한 ISO-8859-1과 같은 기존의 인코딩으로 표현된 자연어 문자열이나 문서를 UTF-8로 표현된 것으로 오인할 가능성도 매우 낮다.


위키피디아의 내용인데 아스키 영역의 글자를 아스키 영역으로 사용한다는 1xxxxxxx은 7비트 아스키 코드의 영역이 아닌데 왜 10xxxxxx로 한걸까요? 


그리고 문자열 문자열 매칭의 경우 확실히 1xxxxxxx xxxxxxxx로 시작하는 글자의 경우 쉽게 찾을 수 있겠지만찾으려는 글자가 아스키코드0xxxxxxx일 경우 두번째 바이트와 중복될 수 있어서 분명 더 복.잡.한 알고리즘이 필요할 것입니다. 


그런데 저 써야 했다!!라는 것을 보니 되긴 된다는 것이고 도대체 그놈의 알고리즘이 얼마나 복잡해 컴퓨터에 부담을 준다는 건지 모르겠네요. 90년대 일반컴퓨터는 그랬다는 것인지. 일단 아래아한글 잘 사용했으니 별 문제는 없을 것 같다는 생각이 드네요. 그리고 기존 아스키 확장의 경우도 그냥 인코딩 방식 구분도 제대로 안하고 막 쓰다보니 생기는 문제같고요. 


그리고 10xxxxxx 잘만 사용하는데 2바이트 첫번째 바이트를 왜 110xxxxx으로 했는지 궁금하네요. 

10xxxxxx 10xxxxxx 하면 또 이건 이거대로 헷갈릴수 있다는 건가요?


----

쓰다보니 많이 길어졌습니다.

1xxxxxxx xxxxxxxx 만 된다면 utf-8에서 현대에 사용한는 한중일 문자를 2바이트로 내로 전부 집어넣는게 가능할 것 같은데 왜 저런 방식을 사용해서 3바이트를 사용하게 하는게 궁금해서 질문드렸습니다. 이제는 이미지나 영상에 비하면 별거 아니지만 글자들에 한해서는 평균적으로 약 1.5배로 뻥튀기 된다는 소리기도 하니까요. 개인적으로 동양권을 기준을로 생각했을때는 그냥 utf-16으로 넘어갔으면 좋겠네요.


프로그래밍도 유니코드로 많이 한다는데 영어는 아스키코드랑 utf-8쓰면 1바이트씩 소모하니 2바이트 소모하는 유니코드보다 얼마나 정확히 빠를지는 모르겠지만 어는 정도 수준인지는 몰라도 차이가 있기는 있을 것 같네요. 영어를 주로 잔뜩 많이 엄청 사용하기도 하니까요.

이 게시물을...