저건 그냥 1:1 로 한글 대치 시킨것입니다.
_dicKOR.php 에 가나다 가 한글코드로 들어있고,
_dicUTF.php 에 가나다 가 UTF-8 로 들어있는거죠.
저쪽에도 글을 남겼지만,
한문이 포함되면 용량이 엄청 늘기 때문에 좋은 방법이 아니고요.
한글만 있기 때문에 UTF-8 이 3Byte 로 통일이 되었지만,
잠깐 확인해본 바로는 한글코드에 있는것 중 UTF-8로 변환하면 2Byte 가 되는것이 있기 때문에, 완전한 변환기가 되려면 성능이 극도로 나빠질겁니다.
// 정태영
하여간 제 말씀이 그 말씀 ^^
하지만, 위의 소스가 PHP로 구현되어서리,, 조금 어렵지 않을까요?
php라고 바이너리 서치를 구현 못 할 게 있겠나요 :) 그렇게 비효율적인 것도 아니고요 (php interpreter 자체의 부하가 있을 지는 몰라도)
EUC-KR은 94x94 평면을 사용하기 때문에 사용자 정의 영역 따위를 다 합하면 8836개의 문자를 쓸 수 있습니다. 마이크로소프트의 cp949는 EUC-KR의 2350개의 한글에 8822개의 나머지 한글을 더 추가하였는데, 이걸 토대로 글자 수를 계산하면 94*94 - 2350 + 11172 = 17658 글자가 나옵니다. 바이너리 서치의 시간 복잡도는 O(lg n)이고, lg 17658 = 14.11 정도이므로 15번 안에 탐색이 가능합니다. (사실은 바이너리 서치를 쓸 게 아니라 php의 배열을 쓰는 것이 더 나을 것 같아 보입니다만)
어렵군 wrote:
아참, 그리고 UTF-8 코드를 한글로 단순히 1대1 대치가 가능한가요?
그렇지 않습니다
직접 구현해 보지 않고서는 예단하기 힘듭니다
EUC-KR과 유니코드 사이에는 round trip(변환 후 역변환해도 문자열에 변함이 없음)이 성립합니다. cp949는 제 기억으로 EUC-KR에서 빠진 글자만 넣은 걸로 기억하기 때문에 cp949도 round trip이 성립해야 할 겁니다. 물론, 유니코드 2.x 이후에는 현대 한글 11172자가 모두 들어 있습니다.
저건 그냥 1:1 로 한글 대치 시킨것입니다._dicKOR.php 에
저건 그냥 1:1 로 한글 대치 시킨것입니다.
_dicKOR.php 에 가나다 가 한글코드로 들어있고,
_dicUTF.php 에 가나다 가 UTF-8 로 들어있는거죠.
저쪽에도 글을 남겼지만,
한문이 포함되면 용량이 엄청 늘기 때문에 좋은 방법이 아니고요.
한글만 있기 때문에 UTF-8 이 3Byte 로 통일이 되었지만,
잠깐 확인해본 바로는 한글코드에 있는것 중 UTF-8로 변환하면 2Byte 가 되는것이 있기 때문에, 완전한 변환기가 되려면 성능이 극도로 나빠질겁니다.
밑에 달린 김정균님것 코드를 분석하는게 차라리 좋습니다.
아니면 차라리 iconv 소스를...
https://xenosi.de/
한자가 4888글자밖에 안되는데 성능이 나빠질 이유가 뭔지를 모르겠군요
한자가 4888글자밖에 안되는데 성능이 나빠질 이유가 뭔지를 모르겠군요
그리고 단순한 1대1 매치는 아닙니다
빠른 인덱스 탐색 구조를 가지고 있어야 합니다
단순한 배열 탐색으로는 당연히 성능이 극도로 나빠지겠죠
윗글에 추가
아참, 그리고 UTF-8 코드를 한글로 단순히 1대1 대치가 가능한가요?
그렇지 않습니다
직접 구현해 보지 않고서는 예단하기 힘듭니다
[quote="어렵군"]한자가 4888글자밖에 안되는데 성능이 나빠질 이
사이즈가 고정되있지 않은 것도 아니고... 매핑 테이블을 메모리에 올리지 못할정도로 무지막지한 사이즈인 것도 아닌데 ;)
빠른 인덱스 탐색 구조까지는 필요없을거 같군요..
배열로 잡고... 바이너리 서칭을 하면 되니까요...
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
// 정태영하여간 제 말씀이 그 말씀 ^^하지만, 위의 소스가 P
// 정태영
하여간 제 말씀이 그 말씀 ^^
하지만, 위의 소스가 PHP로 구현되어서리,, 조금 어렵지 않을까요?
[quote="어렵군"]// 정태영하여간 제 말씀이 그 말씀 ^^
php라고 바이너리 서치를 구현 못 할 게 있겠나요 :) 그렇게 비효율적인 것도 아니고요 (php interpreter 자체의 부하가 있을 지는 몰라도)
EUC-KR은 94x94 평면을 사용하기 때문에 사용자 정의 영역 따위를 다 합하면 8836개의 문자를 쓸 수 있습니다. 마이크로소프트의 cp949는 EUC-KR의 2350개의 한글에 8822개의 나머지 한글을 더 추가하였는데, 이걸 토대로 글자 수를 계산하면 94*94 - 2350 + 11172 = 17658 글자가 나옵니다. 바이너리 서치의 시간 복잡도는 O(lg n)이고, lg 17658 = 14.11 정도이므로 15번 안에 탐색이 가능합니다. (사실은 바이너리 서치를 쓸 게 아니라 php의 배열을 쓰는 것이 더 나을 것 같아 보입니다만)
EUC-KR과 유니코드 사이에는 round trip(변환 후 역변환해도 문자열에 변함이 없음)이 성립합니다. cp949는 제 기억으로 EUC-KR에서 빠진 글자만 넣은 걸로 기억하기 때문에 cp949도 round trip이 성립해야 할 겁니다. 물론, 유니코드 2.x 이후에는 현대 한글 11172자가 모두 들어 있습니다.
- 토끼군
솔라리스의 iconv 버전이 너무 낮아서,SJIS-WIN 을 지원하지
솔라리스의 iconv 버전이 너무 낮아서,
SJIS-WIN 을 지원하지 않더군요.
하고싶지 않은 일이었지만,
SJIS-WIN -> UTF-8
UTF-8 -> SJIS-WIN
의 배열을 만들어서 굴렸습니다.
vim 으로 보면 SJIS-WIN 쪽이 <f8><d4> 이런식으로 깨져 나오게
그냥 쑤셔 넣었습니다.
이런식으로요. (예제는 맞는 코드가 아닙니다.)
빠르군요+_+
php 의 배열이 이렇게 빠르다니 놀랐습니다.
UTF-8 과 UCS-2 는 계산만으로 변환이 되는것도 좋네요.
기존 사이트에 ncr 코드 변환에 적용했더니 속도가 더 빨라졌습니다. ㅠㅠ
https://xenosi.de/
댓글 달기