왜 인코딩은 euckr과 UTF-8로 나뉘어 있을까요..?

kelven의 이미지

조합형한글이 표준이었다면.. 하고 생각해봅니다.

10월 9일은 한글날입니다.

KS-C-5601 사건 아직도 기억하시는분 많으시리라 생각합니다.

아는 분 중에.. '뷁'이 uhc가 아닌 euckr에서 구현된다고 하는분이 있더군요..

euckr에서 구현되는게 맞는건가요?

그리고 nkp 소스를 구하고 싶습니다.

perky의 이미지

kelven wrote:
조합형한글이 표준이었다면.. 하고 생각해봅니다.

10월 9일은 한글날입니다.

KS-C-5601 사건 아직도 기억하시는분 많으시리라 생각합니다.

조합형 한글은 물론 장점도 많이 있지만, 완성형에 비해 단점이 무척 많습니다. 결과론적으로 볼 때, 완성형 한글이 표준으로 채택된 것도 그런대로 좋은 선택이었다고 봅니다. 조합형을 표준으로 썼더라도 상당한 불이익이 있었기 때문에, 어차피 완전한 선택이 없었으므로 어느 정도는 희생을 감수 해야 했었습니다.

kelven wrote:
아는 분 중에.. 'ㅤㅂㅞㄺ'이 uhc가 아닌 euckr에서 구현된다고 하는분이 있더군요..

euckr에서 구현되는게 맞는건가요?

그리고 nkp 소스를 구하고 싶습니다.

구현이 가능하기는 하지만 실제로 구현된 곳은 제가 본 적은 한 번도 없습니다. 표준에서는 완성형 한글을 보완하기 위한 방법으로 두 가지를 정의하고 있는데, 그 중의 하나가 첫가끝 코드이고, 이것은 완성형 코드와 같이 쓸 수 있는 장점이 있는 반면에, 가변폭 코드이기 때문에 처리가 어려워지고 호환성이 떨어지는 단점이 있습니다. 첫가끝은 KS X 1002에 정의되어 있습니다.

그리고, KS X 1001에도 부록에 조합형 코드가 정의되어 있는데, 완성형 한글코드와 같이 쓸 수는 없지만 하여간 조합형이 많은 분들이 표준이 아니라고 생각하시는데, 조합형도 KS X 1001의 부록에 분명히 들어 있긴 합니다. 널리 쓰이지를 않아서 그렇지.. :)

표준 변천사에서 하나 아쉬운 것은, EUC-KR에서 UHC를 덧붙이는 과정에서 MS가 쉽게 하느라 EUC 영역이 아닌 곳에다가 넣은 것인데, 이 부분이 기왕 EUC로 간 김에, EUC-TW나 EUC-JP처럼 페이징을 넣었으면 더 낫지 않을까 생각합니다. 물론 아무도 안 쓰게 됐겠지만..

하여간 이 부분에 대해서는 많은 분들이 조금 고려를 하셔야하지 않을까 싶군요.

  • 조합형을 대중적 표준으로 만들었더라도 그에 따르는 불이익이 상당히 많이 있다.
  • UHC도 세계의 여러 레거시 인코딩들을 살펴 봤을 때, 그렇게 나쁜 편은 아니다.
  • EUC-KR은 결과론적으로는 생각보다 90년대를 위한 좋은 선택이었다.

ara wrote:
KS C 5601 에 따른 ㅤㅂㅞㄺ이란 글자는 euc-kr 로 표현 가능합니다.

euc-kr 에 표현할 수 없는 문자로는 음...

ㅤㄸㅗㅁ, ㅤㅍㅔㅍ, ㅤㅆㅠㅍ 같은 글자들.....

ㅤㅂㅞㄺ, ㅤㄸㅗㅁ, ㅤㅍㅔㅍ, ㅤㅆㅠㅍ 모두 KS X 1001 (KS X 5601)의 완성형 코드로는 표현 불가능합니다. 이를 표현하기 위해서는 KS X 1002의 첫가끝을 쓰거나 KS X 1001의 조합형 확장을 쓰거나, KS X 1002의 추가한글을 쓰거나, UHC를 쓰거나, KS X 1005 등을 쓰면 됩니다.

[/]

You need Python

kelven의 이미지

답변 너무 감사드립니다.

Linux를 쓰면서 하면 안 될 것들
1. 데스크탑을 윈도우나 맥스럽게 꾸미지 말자.
2. 리눅스가 최고라고 떠들지 말자.
3. 윈도우 잘 쓰는 사람한테 리눅스 쓰라고 강요하지 말자.
4. 명령어 몇개 안다고 잘난체 하지 말자.
5. 리눅스니까 어렵게 쓰지 말자.