Dev Talk

오.. 막강한 신기능이 생겼네요.

2바이트 문자중 1바이트로 변환가능한 문자는 변환 이라니..

다양한 분야에 적용될 수 있을것 같습니다.

감사합니다 바로 써봐야 겠어요..

후 기본 언팩에 프로텍터 뚫고 주소를 건져올려야하는군요..

그래서 우선 8월신작 체험판에 적용해봤습니다.

역시나 쪼개서 찾아야할듯 싶은데 찾아봐야 옮겨심기 못하니 여기서 포기

이름 미번역 부분에 대해

9XXX 로 시작되는 한문영역 부분에서 코필터가 약간 어리버리하는것같으니

코필터에서 한문영역으로만 구성된 문장은 패스시켜버리면 커버 될듯도 싶네요.

머 피시님야매로 하면야 코필터 자체가 필요없긴하던데.. 유니코드 코필터에 관해서는 이러면 어떨까하는 의견입니다.

하루하루 수고가 많으십니다.

9xxx 어떻게 어리버리 하시다는 소리인가요?

자세히 설명 부탁드립니다...;;

이름 한문 영역부분에서만 걸러내버릴때가 있어서요..

리라이트때나 하츠코이때 봐보니 특별히 이름영역에서만 번역을 안해버릴때가

코필터 한단계 올렸을때 로카 << 걸러내 버리드라구요.

리라이트때도 이름이 한문이었던 녀석이 걸러졌던것같아요.

9XXX 로 구성된 이름이 번역되는 놈들도 있고 번역 안되는 놈들도 있는것같아서

차라리 9XXX 로만 구성된 문장은 코필터 통과해버리면 어떨까 해서요.

음.. 코필터 단계가 몇단계에서 몇단계로 올릴때 안되신다는건가요?

ex. 한글 > 일어 에서 한글 > 일어 x2    후자에서 번역안됨..

걸러낸다는건 번역이 안된다는 소리 맞지요?

9xxx .. 너무 어중간한 범위를 해버리면 차후 곤란하기 때문에

정확한 범위를 특정지어서 사용하려고 합니다.

1단계 올렸을때입니다

일본어 1글자

그렇다는것은 로카 9680 96eb 요놈을 일본어로 안봤다는것 같더군요. 그래서

조금 보니 9xxx 로 한문영역은 코드값이 주어지는것 같더군요. 그래서 9xxx 로만 구성된 문장 무시 제안을 했었습니다.

코드표를 구해볼려 했으나 여간힘들군요.

일어1일때 81을 상위바이트로 갖는 특문을 일어로 인식해서 안걸러질때..

81을 상위바이트로 갖는 특문같은 경우가 이런 8163 포함 중복번역

리라이트때 8176포함된 중복번역 이 걸러지지않을때가 있었습니다. 요것도 일어체크 무시해버리면 어떨까하는 생각 

코필터 일어 1글자일때 입니다.

그냥 생각나는데로 적어본겁니다.

적고나서 생각해보니 적용여부도 힘들겠고

범용성 여부도 의심이 되긴하는군요.

머 한번 읽어보시고 버리시면 되겠습니다.

어라라... 이상하군요..

else if((0x81 == szBuf[0])&&(

((0x40 <= szBuf[1])&&(szBuf[1] <= 0x51))||

((0x5A <= szBuf[1])&&(szBuf[1] <= 0xFF))))

i++;

제대로 8163 범위까지 감싸 있는데 말이지요;;

9680 96eb 가.. 안받아 들였다라...

한글 필터하고 충돌이려나요.

확실히 EncodeKor 코드범위에 포함되있긴 합니다만..

한번 일어에서는 저부분만 제거해서 반영해보겠습니다.

조금있다 업데이트 되면 확인해주세요.

업데이트 했습니다.

유니코드 코필터는 한글 > 일어x2, 한글 > 일어x3 이 더 잘동작하는 이유가.. 참으로;; 아이러니

포맷하고 이거저거 까느라 피드백이 늦었군요.

9680 96eb  이름 정상 출력됩니다.

8163 포함 중복번역문장 정상적으로 걸러져서 출력됩니다.

일어1문장 번역 // 요거 보다 한단계만더 올려도 미번역문장 쫙쫙 뽑아버리네요...

아무래도 문장이 나눠져서 오는곳이라 그런가봅니다.

리라이트하베스트는 내일에나 테스트해보고 보고드릴게요.