잘은 모르지만 그럭저럭 어줍잖은 실력으로다가 주저리주저리 말씀 올리겠습니다. 이쪽 방면에 전문가이신 분들이 첨언해 주시면 더욱 감사하겠습니다.

일단, 국제 표준은 ISO-8859-1 입니다. 그리고 ANSI 는 이름과 걸맞지 않게도 Windows 전용 코드이며, MacRoman 은 이름에서 풍기는 냄새 그대로 Mac 전용 영문 코드입니다. 둘 다 기본적으로 7비트 ASCII 코드 영역은 동일하며, 8 비트 영역 (128~255) 에서 약간의 차이가 있습니다.

한글 인코딩 관련 문제는 아마도 우리의 한글 윈도우가 ANSI 위에 확장 완성형을 얹은 코드를 기본으로 쓰고 있기 때문이 아닐까 하는 추측입니다. 전 세계 모든 WWW  가 유니코드의 깃발 아래 통일된다면 더 이상 이런 문제로 골치를 썩을 일이 없을텐데 말입니다. ^^;

혹시 ISO-8859-1(Windows) 로 인코딩해 보셨는지요? 그래도 안 되었다면 좀 깝깝한데... ^^;

유니코드 중에서 UTF-16 이나 UTF-32 는 마이크로 프로세서의 바이트 오더링 문제로 인하여 Big Endian (높은 바이트 오더가 앞으로 오는 정렬, PowerPC 에서 쓰던 방식) 이나 Little Endian (낮은 바이트 오더가 앞으로 오는 정렬, Intel 프로세서가 애용하는 방식) 에 따라서 저렇게 방식이 나뉘어 있습니다. 제 입맛에는 역시 가장 속편하게 UTF-8 이 가장 속편한 것 같습니다.

CR (Carriage Return) 과 LF (Line Feed) 는 원래 타자기 용어로 알고 있습니다. 말 그대로 타자기 드럼을 원래 위치로 돌려놓는 작업, 그리고 종이를 한 줄 위로 올리는 작업을 나타내죠.

위에서 정리한 그대로 피씨에서는 CR+LF 를 모두 씁니다. 그리고 fopen( "filename.txt", "rt" ) ; 와 같이 't' 라는 예약어로 파일을 열 때에는 Line Feed 만 입력받으며, 라이브러리에서 LF 를 만나면 CR+LF 로 변환해 줍니다. 그 대신 바이너리 파일 'b' 로 열었을 때에는 CR 과 LF 를 모두 써 주어야 합니다. (옛날 터보C 책 보면 나오는 내용... -_-;;;)

하지만 유닉스, 리눅스 그리고 Mac OS 에서는 CR 만 있으면 CR+LF 로 인정되었고, 그래서 맥이나 리눅스에서 작성된 텍스트 파일을 피씨에서 열어보면 가끔 Return 이 하나도 안 먹혀있는 경우가 있지요. 어떤 경우는 CR+LF 를 모두 다 Return 으로 해석해서 두 줄씩 띄어져 있는 경우도 있고...

아무튼 표준화의 길은 멀고도 험합니다... (먼산... -_-;;;)

honguiny 님 답변 감사합니다. 오늘도 새로운 지식을 얻는군요..
테스트 해보니 textmate자체가 유니코드가 제대로 호환이 안된다는군요..

xcode에서 해봐도 역시 윈도우용 톰캣에서는 제대로 실행되지 않에요
그냥 윈도우에서 새로 ANSI로 인코딩하는 수밖에 없겠습니다. ㅠㅠ

BBEdit나 이클립스를 사용하셔서..  euc-kr 로 저장 하시면 잘 되실듯 합니다.
답변이 늦은 감이 있을듯 하네요.