현재 영문 윈도우에 유니코드 비지원 프로그램의 경우 일본어로 작동하도록 해 두었습니다.
아무래도 한국어가 아닌 일본어이다 보니, 기존에 있던 프로그램을 확 갈아 버려야 했습니다. (당최 국내 프로그램은 유니코드를 지원하는게 하나도 없다 싶이 하는군요... 특히 한글을 재대로 지원하지 않는 아래한글이 가장 충격적 이었습니다.)
파폭은 유니코드를 완전히 지원하리라고 믿고 안심하고 쓰고 있었지만, 오늘에서야 파일과 관련된 기능은 유니코드를 지원하지 않는다는 것을 알았습니다.
웹 페이지를 한글 이름으로 저장하면 '____.htm'처럼 한글이 있던 부분은 밑줄로 변신을 해 버립니다. -_-
또한 하드디스크 내의 한글로된 파일을 읽지 못해서, 한글로 된 파일을 읽을 때 마다 익스플로러를 사용해야 했습니다.
파이어폭스에게 실망 실망 대실망 입니다. ㅜ.ㅜ
파이어폭스는 유니코드를 완전히 지원하지 않나요
-
- 서포터즈
- Posts: 85
- Joined: 2004 11 25 08:07 31
- Contact:
Re: 파이어폭스는 유니코드를 완전히 지원하지
XPCOM 의 파일 입출력 루틴이 유니코드를 지원하지 않기 때문에 발생하는 문제입니다. 제가 알기로는 빛알갱이 님이 이 문제점을 열심히 수정하고 계십니다. 맞죠?마소리스 wrote:파폭은 유니코드를 완전히 지원하리라고 믿고 안심하고 쓰고 있었지만, 오늘에서야 파일과 관련된 기능은 유니코드를 지원하지 않는다는 것을 알았습니다.
웹 페이지를 한글 이름으로 저장하면 '____.htm'처럼 한글이 있던 부분은 밑줄로 변신을 해 버립니다. -_-
또한 하드디스크 내의 한글로된 파일을 읽지 못해서, 한글로 된 파일을 읽을 때 마다 익스플로러를 사용해야 했습니다.
파이어폭스에게 실망 실망 대실망 입니다. ㅜ.ㅜ
중요한 기능이라서 실망도 크겠지만, 그런 기능이 수정되어 가는 역사의 현장에서 우리는 파이어폭스를 사용하고 있는 것입니다. 그런 문제를 직접 수정하시는 유능하고 헌식적인 모질라 해커와 함께 이 게시판에서 논다는 것은 또 얼마나 영광스러운 일입니까?
언능 실망을 거두시지요~
-
- 해커
- Posts: 1146
- Joined: 2004 01 15 20:06 36
Re: 파이어폭스는 유니코드를 완전히 지원하지
실망하신 게 당연합니다만, 속사정이 있답니다. 그렇다고 해도 firefox 1.0은 아니라도 1.5 출시 전에는 해결했어야 했는데, 그렇게 하질 못 했습니다.
Win 9x/ME용과 Win 2k/XP용을 따로 만들지 않는 상황에서 Win 2k/XP에서 유니코드를 완벽하게 지원하는 일은 그리 만만한 일이 아닙니다. 왜 MS IE나 MS Word는 잘 하느냐
고요? 그들은 MSLU(Microsoft layer for Unicode)를 씁니다. 이것을 쓸 경우 소스 코드에서는 Windows API 이름을 'A'나 'W' 접미사 없이 그냥 쓰고 빌드할 때 UNICODE를
정의해 주면 알아서 'W' API (유니코드를 지원하는)를 사용합니다. Win 2k/XP에는 'W' API가 모두 존재하므로 알아서 유니코드를 지원하게 되고, 그렇지 않은 Win 9x/ME에
서는 MSLU가 W API를 A API로 전환해서 현재 시스템 코드 페이지 범위만 지원합니다.
왜 firefox는 MSLU를 안 쓰느냐? MSLU의 라이선스를 자세히 검토해 본 결과 firefox의
라이선스와 어울리지 않아서 firefox와 함께 배포할 수 없다는 결론이 내려졌습니다. 따라서, 다른 대안을 찾다가 시일이 지체되었고, 금년 3-4월에 와서야 다른 방법으로
해결했습니다. firefox 1.5에서 해결을 했으면 좋았겠지만, 늦었고 firefox 2 기차도
놓칠 뻔 했는데, 겨우 탔습니다. 올 후반기에 나올 firefox 2에서는 많은 부분에서 문제가 해결되어 있을 것입니다. 자세한 것은 다음을 보세요
http://bugzilla.mozilla.org/show_bug.cgi?id=162361
이런 라이선스 문제가 없으므로 MSLU를 쓰는 게 자유로운 아래아 한글이나 국내의 수
많은 MS IE용 ActiveX 모듈이 위에서 말한 방법을 쓰지 않고 그냥 'A' API만 지원하는
것은 한심한 일입니다. 그 사람들은 자신이 개발하는 플랫폼의 개발자 문서도 제대로
안 읽나 봅니다. MSDN에 가면 이에 대한 정보가 아주 오래 전부터(아무리 늦게 잡아>도 1990년대 말) 올라와 있었습니다.
Win 9x/ME용과 Win 2k/XP용을 따로 만들지 않는 상황에서 Win 2k/XP에서 유니코드를 완벽하게 지원하는 일은 그리 만만한 일이 아닙니다. 왜 MS IE나 MS Word는 잘 하느냐
고요? 그들은 MSLU(Microsoft layer for Unicode)를 씁니다. 이것을 쓸 경우 소스 코드에서는 Windows API 이름을 'A'나 'W' 접미사 없이 그냥 쓰고 빌드할 때 UNICODE를
정의해 주면 알아서 'W' API (유니코드를 지원하는)를 사용합니다. Win 2k/XP에는 'W' API가 모두 존재하므로 알아서 유니코드를 지원하게 되고, 그렇지 않은 Win 9x/ME에
서는 MSLU가 W API를 A API로 전환해서 현재 시스템 코드 페이지 범위만 지원합니다.
왜 firefox는 MSLU를 안 쓰느냐? MSLU의 라이선스를 자세히 검토해 본 결과 firefox의
라이선스와 어울리지 않아서 firefox와 함께 배포할 수 없다는 결론이 내려졌습니다. 따라서, 다른 대안을 찾다가 시일이 지체되었고, 금년 3-4월에 와서야 다른 방법으로
해결했습니다. firefox 1.5에서 해결을 했으면 좋았겠지만, 늦었고 firefox 2 기차도
놓칠 뻔 했는데, 겨우 탔습니다. 올 후반기에 나올 firefox 2에서는 많은 부분에서 문제가 해결되어 있을 것입니다. 자세한 것은 다음을 보세요
http://bugzilla.mozilla.org/show_bug.cgi?id=162361
이런 라이선스 문제가 없으므로 MSLU를 쓰는 게 자유로운 아래아 한글이나 국내의 수
많은 MS IE용 ActiveX 모듈이 위에서 말한 방법을 쓰지 않고 그냥 'A' API만 지원하는
것은 한심한 일입니다. 그 사람들은 자신이 개발하는 플랫폼의 개발자 문서도 제대로
안 읽나 봅니다. MSDN에 가면 이에 대한 정보가 아주 오래 전부터(아무리 늦게 잡아>도 1990년대 말) 올라와 있었습니다.
Who is online
Users browsing this forum: Semrush [Bot] and 0 guests