Dev Talk

여기서 말하는 KSC-5601 이라는 것은, 엄밀하게 말해 KSC-5601-1987 완성형 한글코드 라고 불립니다.
위에 적힌 것처럼 *주요 쓰이는 한글 2350자* 와 일용한자, 각종 특수문자로 구성되어 있지요.

왜 이 이야기가 나오냐면..

"퓩" 이 주요 쓰이는 한글 2350자.. 에 들어있지 않기 때문입니다.. oTL

우리가 보통 윈도우에서 쓰이는 한글은 저 KSC-5601 의 확장판으로, 마이크로소프트 확장 완성형 혹은 CP949라고 불리는 코드입니다.
현대 한글 조합 11172자중 저 2350자만으로는 부족한 8천 몇개의 한자를 다른 부분에 할당한 것이죠.

뭐.. 이에 대해서는 정말 한글 엄마가 보면 미치고 환장할 스토리가 있으니 궁금하시면 저 KSC-5601 이나 확장 완성형 등으로 인터넷을 찾아보시고요, 문제가 생기는 정확한 이유는 다음과 같습니다.

* 단어 설명
리드 바이트 (lead byte) : 어떤 멀티바이트 문자의 첫번째 시작 바이트
트레일 바이트 (trail byte) : 어떤 멀티바이트 문자의 두번째 이후 바이트

* 원인
1. "퓩" 의 코드는 0xBF91 입니다. 이것은 KSC-5601의 2바이트 한글 코드 범위 (리드 0xA1-0xFE, 트레일 0xA1-0xFE) 에 들지 않습니다.
2. 따라서 이 코드는 KSC-5601 을 기준으로 만들어진 ENCODEKOR 로 변환이 안 됩니다.. (문제 1)
3. 그래서 0xBF91 그대로 게임 내 일본어 표시기로 넘어갑니다.
4. 그런데 Shift-JIS 의 코드 범위는 2바이트 코드 (리드 0x81-0x9F, 0xE0-0xEF, 트레일 0x40-0xFC), 1바이트 코드(0xA0-0xDF)이다.
5. 0xBF91 의 리드바이트 0xBF 는 1바이트 코드 (반각 카타카나) 로 취급된다.. (문제 2)
6. 따라서 0xBF 의 한 글자와 0x91~(다음 리드바이트) 로 되어있는 두 개의 글자로 취급된다.
7. 0x91~(다음 리드바이트)에서 문자가 하나 깨지기 시작했으니 그 뒤로 줄줄이 줄줄이 깨진다.. OTL (문제 3)
8. 마지막 # 바로 전 바이트가 리드바이트 취급을 당해 (전 바이트)~# 으로 한 문자 취급 받아 문자열 끝 코드 # 이 깨진다.
9. 리얼라이브 게임 특성상 바로 게임이 멈춰버린다...

* 해결 방법...
가장 좋은 방법은 ENCODEKOR 의 코드를 주물럭대어서 어떻게든 확장완성형의 코드를 이해시키는 방법입니다.
문제는.. ENCODEKOR 의 범위가 KSC-5601의 한글코드 부분이 딱 들어가도록만큼만 되도록 디자인되었다는 것입니다;
계산해 본 결과.. 한글 코드보다 조금 더 들어가게 생기긴 했는데.. 그래도 확장완성형의 코드가 다 들어가기는 너무 좁습니다;

두번째 방법은.. 에찌게에서 많이 쓰이는 몇몇 문자 (퓩 이라거나 츗 이라거나... ㄷㄷㄷ)만을 ENCODEKOR 의 약간 남는 부분에 강제 맵핑하는 방법이 있는데.. 이건 1) 몇몇 문자 라는 게 실제로 어떤것이 있는지 확실하지가 않고 2) 코드 테이블을 따로 만들어야 한다는 단점이 있습니다; 노가다라고 할까요;

마지막으로.. RLCmd 의 빈칸 입력 부분을 고쳐서 2바이트 빈칸 말고 1바이트 빈칸으로 채우는 방법이 있는데.. 이건 실제 게임에서 위의 문제로 인해 글자가 깨지기는 하지만 뒷부분에 1바이트 빈칸이 들어감으로서 줄줄이 깨지는 악순환을 끝내고 # 이 제대로 인식되도록 하는 방법이 있습니다. 하지만, 1) 이 방법은 실제로 문제를 해결하는 것이 아니라 *일단 이 부분만 넘기고 보자!* 라는 근시안적인 방법이고 2) 원문과 번역문의 길이가 같거가 길 경우 1바이트 빈칸이 들어갈 곳이 없다면 역시 게임이 진행 안된다는 문제가 있습니다. 단, 물론 구현은 가장 쉽습니다 orz

어쨌든.. 이 문제는 정말 골치아프군요; 일단 마지막 방법으로 해당 부분만 넘기도록 RLCmd 를 고쳐보도록 하겠습니다.