문자열
2010년도 이후에 우리는 유니코드라고 불리는 인코딩방식으로 통일된 시대를 살아가고 있습니다.
문자열을 다루는 디테일한 방식에 대해 전부 알 필요는 없지만, 프로그래밍 언어마다 문자열을 다루는
자료형의 차이는 분명히 있기 때문에 그것을 이해하기 위해 문자열을 다루는 방식을 조금은 알고 있어야 합니다.
문자열 하나는 몇 바이트 (byte) 인가요?
영어의 경우는 알파벳 하나가 1 byte 를 차지하는 시절이 있었습니다,
하지만 지금 글로벌 시대에는 유니코드를 사용해야 텍스트를 정확하게 저장할 수 있습니다.
프로그래밍 언어마다 문자열을 저장하는 자료형이 다 다르므로 "문자열 하나가 몇 byte 냐?" 에 대한 답변은
해당 자료형이 차지하고 있는 byte 를 이해할때 답변이 가능할겁니다.
문자표 (Character Set)
예전, 컴퓨터라는것이 처음 등장했을때는 문자열을 표시하는 용도보다는 수학적인 계산을 하기위한 용도로
많이 사용되고 있었습니다. 하지만 그런 수학적인 계산을 하고나서도 사람들에게 그 결과값이 보여져야 했기
때문에 컴퓨터는 사용자들에게 모니터, 프린터 등의 출력기기 들을 통해서 결과값을 전달해야 했습니다.
하지만 모니터나 프린터기 역시 기계, 가나다 등의 문자는 알아보지 못합니다.그래서 컴퓨터에게 약속된
문자열을 지급합니다. " '가' 는 '1' 이야, 그러니까 1이라는 숫자가 들어가면 가를 출력해 " 라는 식으로
컴퓨터에 이런 정보들을 입력해 놓는겁니다. 하지만 이때는 이런 규칙을 딱 정해놓고 만들지 않았기에
개개인마다 사용되는 규칙들이 달랐습니다, 혼란스럽겠죠, 그래서 공식적인 약속을 정하게 됩니다.
"자, 이건 이제 국제표준입니다, 가는 1, 나는 2, 다는 3... " 이런식으로 모든 컴퓨터에서 똑같은
규칙을 가지고 숫자와 문자를 매칭시키는 문자표를 만들게 됩니다.
이것에 대한 가장 대표적인 예가 ASCII 문자표가 되겠습니다.
유니코드
위의 상황에서 만들어진 약속된 표준화 문자표인 ASCII 문자표, 하지만 이 문자표에는 큰 문제가 있었습니다.
바로 '영어권' 사람들만 사용할 수 있다는 점이었습니다, ASCII의 풀네임은
미국정보교환표준부호( American Standard Code for Information Interchange ) 입니다.
이름만 들어도 딱 느낌이 오죠? 미국에서 사용하기 위해 만든 표준문자표라는겁니다.
실제로 ASCII 문자표에서는 영어만 사용이 됩니다, 다른언어는 존재하지 않죠.
그렇기때문에 뭐 미국이 아니더라도 영어를 표준어로 사용하는 나라에서는 크게 문제될건 없었습니다.
하지만 영어가 표준어가 아닌 나라들은? 당장도 우리나라가 있겠죠, 영어권 나라를 제외한 다른 나라들은
미국에 ASCII 코드라는것이 생기기 전같은 상황이 여전히 발생하고 있는거였습니다.
그래서이제 영어권이 아닌 나라에서도 ASCII 처럼 표준화된 문자열을 만들기 위해 연구가 시작됩니다.
하지만 또다시 문제가 발생합니다. ASCII 코드를 만들 당시에는 개발 엔지니어의 수가 그리 많지 않았고.
영어라는 문자에만 집중하면 됬기에 빠르게 문자표를 표준화시키고 배포하는데 어려움이 없었지만.
새로운 문자표를 만들고자 할 당시에는 국제적으로 다양한 문자가 존재했고, 그것을 연구하려는 엔지니어들도
많아지다보니까 이 역시 통일되지 않고 같은문자를 가지고 나라마다 다른 표준을 제시하게 된겁니다.
그렇게 되면 컴퓨터입장에선 다시 난처해질 수 밖에 없겠지요, 한국에서 쓰던 표준이 일본에선 통하지 않으니까요.
가끔 어떤 프로그램을 설치할때 명령프롬프터에서 꿝둙뀕깕깕 같은 이상한 문자를 보신적이 있을겁니다.
이것들이 바로 문자를 제대로 해석하지못하여 출력하는 결과값인겁니다.
그래서 여전히 혼란스러웠기 때문에 이번에는 아예 싹다 모아서 하나의 통일된 문자표를 만들게 됩니다.
미국도 예외는 아니겠죠. 전세계의 거의 모든 언어를 가지고 하나의 통일된 문자표를 만들게 되는데,
바로 이것이 유니코드 입니다.
유니코드는 인코딩되는 데이터의 데이터 유형에 따라 두 개의 인코딩 양식(8비트 및 16비트)을
사용합니다. 기본 인코딩 양식은 16비트로, 각 문자는 16비트(2바이트)이며 보통 U+hhhh로 표시됩니다.
(여기서, hhhh는 문자의 16진 코드 포인트입니다.) 65,000개 이상의 코드 요소 결과로도
세계 주요 언어의 문자 대부분을 인코딩할 수 있을 정도로 충분하지만 유니코드 표준은 무려 백만 개가
넘는 문자를 인코딩할 수 있는 확장 메커니즘도 제공합니다. 확장 메커니즘은 한 쌍의 상/하위
대리 문자를 사용하여 하나의 확장 또는 보조 문자를 인코딩합니다.
첫 번째(또는 상위) 대리 문자는 U+D800에서 U+DBFF 사이의 코드 값을 가지며,
두 번째(또는 하위) 대리 문자는 U+DC00에서 U+DFFF 사이의 코드 값을 갖습니다.
출처: https://www.ibm.com/docs/ko/db2/11.1?topic=support-unicode-character-encoding
인코딩
이렇게 유니코드를 만들어서 먹고살만해졌나 싶었더니 얼마안가 문제점들을 발견하기 시작합니다.
바로 유니코드가 영어를 표현할때는 1 byte로, 한글을 표현할때는 2 byte로, 또 다른 언어나 특수한언어를
표현할때는 3 byte로 표현는것을 확인하게 됩니다, 이것이 왜 문제가 되냐면 가변적이라는 겁니다.
이것이 컴퓨터 입장에서는 굉장한 혼란을 주게 됩니다. 정확한 기준이 없기때문에
어쩔때는 1byte로, 어쩔땐 2byte로.. 이렇게 되버리니 아무리 컴퓨터라도 혼동이 일어날 수 밖에 없는거였죠,
그래서 1byte일때는 따로 어떤 표시를 해두고, 2byte 일때는 또 다른 표시를, 3byte에도 표시를 해놔서
컴퓨터가 혼동이 없게끔 저장하는 방식을 약속하게 됩니다.
해당 표시에 따라 이것이 1byte로 읽어야 하는지 3byte로 읽어야 하는지를 판단이 가능하게 만든 것을
인코딩 이라고 합니다. 이 인코딩 방식은 여러개가 있습니다, 우리가 코딩을 하면서 봐왔지만 그다지 크게
궁금해하지 않았었을건데요, UTF-8, UTF-16 등 많은 종류가 있습니다. 다들 한번쯤은 보셨을겁니다.
정리
자, 이렇게 되면 우리는 이제 문자열로 인해 생기는 오류에 대해서 그 원인을 생각해 볼 수 있게 되었습니다.
문자열이 깨지는 경우. 어떤 문제인지를 파악하여 신속하게 대응할 수 있는 실력을 갖춰야겠습니다.
