ko_KR.UTF-8 불편한 점 및 문제점
사로 구한 랩탑은 ko_KR.UTF-8 로케일로 세팅했습니다.
그 이유는 ko_KR.eucKR 로케일로 사용할 경우 리눅스에서 USB 드라이브의 한글 파일명을 제대로 읽지 못하기 때문입니다. 물론 이건 로케일 자체의 문제가 아니라 아니라 파일시스템 드라이버의 문제일 것입니다만, 어쨌든 ko_KR.UTF-8 로케일을 사용하면 USB 를 사용하는 데 지장이 없습니다. 로케일 지원은 매킨토시나 윈도우즈 등 상용 OS가 확실히 뛰어납니다. 아무래도 리눅스 커뮤니티 자체가 영어권 등의 개발자들이 많고 2byte 문자권의 개발자들의 참여는 적기 때문일 것입니다.
하지만 그로 인해 생기는 몇 가지 불편한 점이 있습니다. 제가 아직 직접 겪어보지는 못했지만 이전에 작성된 인코딩 정보가 없는 한글 문서나 도움말을 볼 때 불편할 수 있고, 인코딩 정보가 없는 오래 된 프로토콜을 오래 된 애플리케이션으로 사용할 때 애로사항이 있을 수 있다는 것 말고도 한두 가지 불편한 것이 있었습니다.
1. 데비안 기본 패키지의 hanterm-xf 를 사용하지 못합니다.
hanterm-xf 는 불행히도 UTF-8 을 지원하지 않더군요. hanterm-classic 은 UTF-8 을 지원하지만 데비안 패키지에서 사라져 버렸습니다. hanterm-xf 용 UTF-8 패치가 있다고는 하는데, 귀찮아서 rxvt-unicode 로 갈아탔습니다. 하지만 한글 사용은 한텀이 정말로 제일 편리합니다. 특히 vi 를 사용할 때 입력 모드로 한글로 입력하다가 Esc 키를 눌러서 ex 모드로 빠져나갈 때 자동으로 영문 입력으로 전환된다는 점이 정말로 좋습니다. 아직까지 다른 터미널에서는 이러한 기능을 찾아보지 못했습니다. 혹시 이러한 기능을 설정할 수 있는 유니코드 지원 터미널이 있다면 알려주시면 감사하겠습니다.
2. 한글 윈도우즈에서 압축된 압축 파일에 한글명 파일이 들어 있을 경우 압축을 풀었을 때 파일명이 깨져 버립니다.
예를 들어 한겨레결체를 다운로드받아서 zip 파일 압축을 풀면 나오는 '한겨레결체.TTF' 파일의 이름이 제대로 보이지 않습니다. 이것은 정말로 불편합니다. vmware 에다 한글 윈도우즈 깔아 인코딩 문제를 잘 처리해 주는 samba 를 통해서 사용하는 방법 말고 또 다른 방법이 있는지는 모르겠습니다. 혹시 인코딩 변환 기능이 있는 압축파일 관리 프로그램이 있다면 그런 것을 사용하거나 할 수도 있을지 모르지만 그런 소프트웨어가 있나요? 하여간 한글 윈도우즈에서 작성된 한글 파일명 파일들을 압축 파일로 교환하며 작업을 진행해야 하는 분들은 ko_KR.UTF-8 이 불편할 수도 있을 것입니다.
압축파일이 고질적인 문제군요
http://kr.openblog.com/View.aspx?ContentID=609502&OpenBlogID=0&Rp=32&Link=http://barosl.com/blog/entry/unzip-552-encoding-patch
http://kr.openblog.com/View.aspx?ContentID=368234&OpenBlogID=0&Rp=32&Link=http://barosl.com/blog/entry/kio-zip-encoding-patch
http://www.perlmania.or.kr/upload/upload.html?mode=read&num=82
몇 가지 패치나 그런 것이 검색이 됩니다만, 이건 한글 사용자들이나 개발자들이 강하게 어필을 하고 패치를 보내서 인코딩 처리가 적어도 많이 쓰는 zip, gzip, tar 관련 유틸리티들은 인코딩 처리가 가능하도록 하거나, 아니면 새로 프로젝트를 fork 해서 multi language 압축 처리 유틸리티 프로젝트를 진행하거나 하면 좋겠습니다.
아직까지는 파일명은 ASCII 로만 쓰는 것이 현실적으로 가장 좋은 선택인 것 같습니다.
참고로 우분투에서는 unzip 에 인코딩을 설정해 줄 수 있는 패치를 적용하기 시작했다는 얘기도 있군요.
https://blueprints.launchpad.net/unzip/+spec/unzip-detect-filename-encoding
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
nabi와 scim에서 ESC를 누르면
nabi의 NEWS를 보면 0.2부터 ESC를 누르면 영문으로 바뀌는 기능이 들어갔습니다.
XIM을 지원하는 아무 터미널에나 붙여서 쓰면 될 겁니다.
scim에도 그렇게 설정을 할 수가 있다고 http://kldp.org/node/71378 에 나와 있습니다.
좋은 정보 대단히 감사합니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
윈도우에서도
윈도우에서도 인코딩에 따른 zip 안의 아시아권 파일 이름 문제는 여전히 존재합니다. 일본산 zip압축파일이 주로 문제가 되지요.
근본적인 해결책은 파일명을 유니코드로 처리하는 rar이나 7z 같은 발전된 압축 포맷을 쓰는 것이고, 임시 방편으로는 인코딩을 설정할 수 있는 압축 해제 프로그램을 만드는 것입니다. 근데 윈도우에서도 파일명의 인코딩을 설정 가능한 압축 해제 프로그램은 찾아보기 힘듭니다. 저는 DarkUnpack 딱 하나 봤군요.
그나마 소스가 공개되어 있고 피드백이 활발한 오픈 소스 쪽은 해결의 여지가 더 큰 편입니다. 무엇보다 리눅스는 굳이 재부팅 안해도 로케일 변경이 가능하지요?
맥이 한글처리가
맥이 한글처리가 잘된다는 이야기는 처음 들어봅니다.
적어도 USB 드라이브에서 파일명은 제대로 읽어들입니다
리눅스는 현재 UTF 로케일이 아닌 다른 로케일에서는 USB 드라이브의 vfat 파일시스템에서 멀티바이트 파일 이름을 제대로 못 읽습니다. 물론 ko_KR.eucKR 같이 비 UTF-8 로케일의 경우에 한해서 이런 문제가 있다는 것입니다. 리눅스도 로케일을 UTF-8 로 하면 USB 사용 문제 없습니다.
적어도 맥은 USB에다 파일 복사해서 옮길 때 파일 이름이 깨져서 잘 안 보이고 그런 일은 없습니다. OS X 파일시스템은 기본적으로 UTF-8 을 사용하니까요. 하지만 OS X 파일시스템도 좀 이상하긴 하더군요. 그냥 UTF-8 이 아니라 UTF-8-MAC 이라고 약간 특이한 걸 사용하더라고요. 그래서 Finder 에서는 잘 보이던 한글 이름 파일을 바탕화면에 복사해 놓으면 자음 모음이 분리되어서 보이기도 하고 귀찮은 문제들이 있습니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
1. UTF-8-mac 이 아니라
1. UTF-8-mac 이 아니라 UTF-8 의 한글 조합형 영역인 첫가끝 코드(U+1100)를 사용합니다. 하지만 iconv 에서 UTF-8 첫가끝 코드를 cp949 등으로 변환할 수 없으므로 rar 등의 유니코드를 사용하는 압축 프로그램을 이용하더라도 리눅스등에서 압축을 풀 때 문제가 생길 수 있습니다.
2. usb 메모리 등을 사용하는 경우를 얘기하셨는데 이는 시스템을 어느 언어로 설정해놓았느냐와 상관이 있습니다. '한글 상위' 로 사용하는 경우 리눅스의 커널에서 iocharset 을 'cp949' 로 설정해놓았을 경우와 거의 유사하게 동작합니다.
또한 stuffit expander 등의 압축 해제 프로그램에서는 윈도우에서 압축한 zip 아카이브를 제대로 처리하지 못합니다. (파일이름이 깨집니다.) 다행히도 The unarchiver 라는 프로그램이 있고, 이 프로그램에서는 시스템 인코딩을 따라서 파일이름을 유동적으로 처리해주기 때문에 문제를 피해갈 수 있습니다.
또한 리눅스에서도 마운트 옵션으로 -o iocharset=cp949,codepage=949 등으로 주게 되면 ko_KR.eucKR 를 사용하는데 문제가 없습니다.
마지막으로 The unarchiver 는 GNU GPL 이고, 압축 해제를 위한 라이브러리 + GUI 로 구성되어 있으므로 누군가 관심있는 사람이 있다면 리눅스 쪽으로 포팅을 하는 것이 나쁘지 않을 것 같네요. (단 고양이 목에 방울달기라 누가 나서서 해줄지는...)
--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
입력기 scim에서
입력기 scim에서 esc(혹은 Ctrl+[)키를 '끄기'키로 설정하셔서 vim(gvim) 사용시에 효과를 볼 수 있습니다.
zip 파일 포맷 자체에 인코딩 정보를 담는 기준이 정해져 있지 않아 근본적으로 해결하기 힘든 문제로 알고 있습니다.
한글 사용자를 위한 패치가 된 unzip 우분투용 패키지를 첨부합니다. 어디선가 받아 두었던건데 출처가 기억나지를 않습니다.
언급하신 문제점들의 가장 좋은 해결책은 한글 윈도우를 계속 사용하시는 것 입니다. 문제 자체가 안생깁니다.
--
마잇
--
마잇
잘못 알고 계신 것 같습니다?
이상합니다?
1. 리눅스의 로케일 설정과 파티션의 파일은 아무런 상관 관계가 없습니다.
iocharset, codepage를 설정해주면 잘 됩니다. 말씀하신 VFAT도 잘 읽습니다.
2. 맥의 한글 처리는 전혀 이상하지 않습니다.
반대로 지구상에서 유일하게, 첫가끝(조합형)을 사용합니다. 유니코드로 넘어 와서 까지 완성형 한글에 묶여 있는 지금의 작태가 어이 없을 따름입니다. 여하튼 유니코드를 사용하는데 그것을 조합형으로 사용해서 조합형 유니코드를 지원하지 못하는 기존의 운영체제에서 보면 글자가 낱낱이 분해 되어서 나옵니다.
리눅스 vfat 제대로 못처리해요. 맥에서도 한글 문제 있습니다.
맥에서의 한글 조합형 유니코드 사용에 대한 좋은 정보를 지적해 주셔서 감사합니다.
조합형을 사용하는 것은 좋은데, 뭔가 몇 군데 변환하는 과정에서 빼먹은 곳이 있는지 버그가 눈에 띄더군요. 맥에 있던 파일을 다른 곳으로 옮길 때 그런 문제가 발생하는지 어쩐지는 모르겠지만, 다른 파일을 맥으로 옮기었을 때의 문제를 말씀드리는 것입니다.
vfat 에 있는 한글 파일 이름을 가진 파일을 한번 OS X 바탕화면에다 끌어다 놓아 보시거나, 아니면 웹에서 한글 이름을 가진 파일을 바탕화면으로 다운로드 받아 보십시오. OS X 바탕화면에는 자모가 분리되어 나올 것입니다. 재미있는 것은 이 파일을 Finder 로 보면 또 제대로 보여요. OS X tiger 에서는 확실히 그렇습니다. leopard 에서 이 문제가 고쳐질지 어떨지 모르겠군요.
리눅스에서 vfat 을 읽는 데 문제가 있다는 것은 컹커러 등 널리 사용되는 데스크탑 환경의 파일 탐색기들이 vfat USB 를 제대로 처리하고 있지 못하다는 것입니다. 또한 콘솔에서도 수동으로 로케일을 바꿔 가면서 ls 를 하던가 해야 겨우 제대로 보이지요.
그러면 브라우징은 어떻게 해서 가능합니다. "읽기"야 어떻게든 이런 식으로 할 수 있습니다만, 이렇게 되면 문제는 vfat 에 있는 파일을 로칼 파일시스템으로 복사할 때 또 난감해집니다. USB 의 vfat 은 UTF-8 이고 로칼 하드 디스크는 ko_KR.eucKR 이라는 것을 콘솔에서 따로 설정할 수가 없잖습니까? cp 나 mv 같은 거 할 때 인코딩 옵션을 줄 수 있나요?
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
바탕화면용 글꼴을
바탕화면용 글꼴을 임의로 다른 글꼴로 설정해놓았는지요?
맥에서 첫가끝코드를 지원하지 않는 글꼴(아마 맥에서는 애플고딕만이 첫가끝 코드를 지원할껍니다.)을 사용하면 위와 같은 현상이 나타나는 걸로 알고 있습니다.
타이거 베타시절에는 아무 글꼴에서나 위의 버그가 있었던걸로 알고 있습니다만 지금은 멀쩡하게 잘됩니다. (지금 tiger의 firefox에서 글 쓰고 있는 중입니다.)
그리고 vfat의 경우에는 특별한 설정없이 잘 쓰고 있는지 5년 넘어갑니다. 메이져 배포판일 경우에는 전혀 걱정없이 쓸 수 있을텐데요? (그런데 추석날에 글들이 많이 올라오는군요 -ㅅ-)
----
Do not feed troll!
----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러
애플고딕을 대체하여
애플고딕을 대체하여 좀더 예쁘게 보인다는 굴비고딕을 깔았던 기억이 있는데 아마 그것 때문에 그럴지도 모르겠습니다.
리눅스도 ko_KR.UTF-8 로케일이면 USB 사용이 아무 문제가 없지만, ko_KR.eucKR 로케일일 경우는 USB 드라이브의 한글 파일명이 깨져 보입니다. 콘솔에서도, 컹커러 등 GUI 파일 관리자에서도 마찬가지입니다. 다른 배포판은 모르겠지만, 데비안에서는 확실히 그렇습니다. 요즘에는 데비안은 물론이고 거의 모든 배포판들이 한국어로 설치하면 ko_KR.UTF-8 을 기본으로 하는 듯 하기 때문에 USB 사용에는 문제가 없지만, 대신 윈도우에서 만들어진 zip 파일들 압축을 풀 때 애로사항이 있겠지요.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
위에 ganadist 님이
위에 ganadist 님이 써놓으셨지만, 파일시스템의 마운트 옵션에 iocharset=cp949,codepage=949 정도를 주게되면 ko_KR.eucKR 에서 문제가 없습니다.
배포판들이 UTF-8 로케일을 기본으로 가정하고 옵션을 넣어 패키징을 하고 있는데 억지로 ko_KR.eucKR 을 사용하시려고 하니까 문제가 생기는 겁니다.
--
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
오랫동안 꿈을 그리는 사람은 그 꿈을 닮아간다...
http://mytears.org ~(~_~)~
나 한줄기 바람처럼..
억지라는 말씀은 좀
억지라는 말씀은 좀 아닌 것 같습니다.
애플고딕, 굴비고딕
애플고딕, 굴비고딕 둘 다 간혹 이런 현상이 발생합니다.
이유는 도대체 모르겠습니다. 환장해요 -_ㅠ
전 그냥 변환 스크립트 만들어서 쓰고있습니다;
Leopard 로
Leopard 로 업그레이드했더니 이 문제가 해결되었습니다. 기분좋기도 하고 허탈하기도 하고 ...
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
인용:USB 의 vfat 은
있지 않나요? vamf12님의 원글을 봐주세요.
hanterm-xf 도 UTF8 을
hanterm-xf 도 UTF8 을 지원합니다. 데비안 패키지가 오래된 버전인가 보죠. 현재 최신 버전에는 제가 다른분이 만들어 놓으신 패치를 정리하고 조금더 수정해서 보고하여 main tree 에 commit 이 되었습니다.
데비안 언스테이블은 1:3.3.1p18-10 이라고 되어 있네요
아마도 patch18 까지만 적용된 버전인 듯 합니다.
http://kldp.net/projects/hanterm-xf/
여기에 있는 최신 릴리즈를 다운받으면 되는 것이죠?
좋은 정보 감사합니다.
데비안 패키지에도 업데이트가 되었으면 좋겠군요.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
EUC-KR 로칼에서
EUC-KR 로칼에서 vfat 한글 파일명 처리에 문제가 있다는 얘기는 처음 들어봅니다. 적어도 HDD에서는 mount시 iocharset, codepage설정만 잘해주면 문제 없습니다. HDD에서도 동일한 현상이 발생한다면 imyejin님의 설정에 문제가 있는 것입니다.
참고로 potato pre-release 시절부터 데비안 사용자입니다.
http://kldp.org/node/65724#co
http://kldp.org/node/65724#comment-249659
옵션 지정이 가능한 것이 확실하므로 치명적인 버그가 없는 이상 잘 동작하리라 생각합니다.
HDD 안해봐서 모르겠지만
자동 마운트 되는 USB 드라이브의 경우는 EUC-KR 로케일에서 확실히 안됩니다. 현재 제가 글을 올리고 있는 이 박스가 바로 그렇습니다. 컹커러 등의 GUI 응용프로그램에서도 USB 안에 들어있는 한글 이름 디렉토리나 파일이 깨지고 (charset 설정하는 기능도 써봤지만 안먹힘), 콘솔에서 ls 로도 USB 안에 있는 한글 파일명이 제대로 나타나지 않습니다.
어쩌면 USB 를 자동으로 마운트하는 패키지의 스크립트의 설정이 잘못되었을 수도 있겠군요.
@ USB 자동으로 마운트 잡는 패키지가 뭐였죠?
루트에서 직접 마운트를 걸어 iocharset 설정해서 걸어 버리는 건 잘 되는데, hal 이 해 주는 건지 어쩐지 몰라도 무슨 스크립트를 건드려야 할지 대략난감하군요 이런 ...
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
그렇다면 콘솔
그렇다면 콘솔 상에서 수동으로 USB 드라이브를 umount하시고 mount -o iocharset=cp949,codepage=949 /dev/sda1 /mnt/flash 이런 식으로 해보시면 어떨까요.
자동마운트는 잘 써본적이 없어서 모르겠습니다. 혹시 모르니 fstab도 보여주세요..
----------
그렇다면 정말 자동마운트 스크립트 문제같아보입니다. 그런데 그러면 왜 처음에 파일시스템 드라이버 문제 같다고 하셨는지요.. 그때는 수동마운트는 안해보셨나봐요.
hal 이 드라이버의 집합체 + 스크립트들이잖습니까 ㅠ,ㅜ
자동 마운트되는 장치들은 fstab 에 고정적으로 등록되어 있지 않답니다.
hal 인가 뭔가가 알아서 관리를 하는 것 같습니다.
kldp 에도 hal 관련 설정 글이 많이 올라와 있기는 한데 이게 또 요즘 설정파일이랑 약간 다른 것 같습니다.
자동 마운트에 익숙해져서 수동 마운트는 할 생각을 해보지도 않았습니다.
수동으로 마운트 해 본 것은 옛날에 레드햇 깔았을 때 플로피 디스크랑 씨디롬 정도고, 요즘에는 그나마 그런 일도 할 필요가 없어졌지요.
요즘은 아주 가끔 하드 디스크 관리한다거나 nfs 나 아니면 sshfs 말고는 수동으로 마운트를 걸어 본 일이 사실상 없네요.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
-검은해가 자진삭제-
-검은해가 자진삭제-
저는 리눅스에서
저는 리눅스에서 UTF8로케일을 사용한지 꽤 되었는데 별로 불편한점은 없네요..
참고로 데비안하고 우분투를 쓰고 scim, gnome-terminal 씁니다.
불편한 점이라고는...
1. 압축파일에 들어가 있는 파일명
2. 음악파일의 id3 tag
3. ftp에서 파일명
정도밖에 없는거 같네요.. 해결책은..
1. 그냥 압축푼담에 쉘 스크립트로 파일명을 utf8로 변환하든가, 파이썬의 zip라이브러리를 사용해서 파일명을 변환하면서 풀어주는 스크립트가 있습니다.
2. id3의 최신버젼은 인코딩을 지정하므로 문제가 없습니다. 인코딩이 지정 안되있는 이전버젼의 id3라면 이것도 변환해주는 스크립트가 있습니다.
3. 인코딩 지정이 가능한 ftp클라이언트가 있습니다. 근본적인 해결방법으로는 클라이언트와 서버가 둘다 rfc2640을 지원하면 utf8을 사용하므로 아무 문제가 없습니다. rfc2640을 지원하는 프로그램으로는 유닉스계열 서버 pureftpd, 윈도우용 서버 filezilla-server, 클라이언트로는 리눅스용 다수와, 윈도우에서는 filezilla, 그담에 windows xp의 explorer(탐색기)가 있습니다. (그런데 IE7에서는 지원 안합니다.)
그리고 파일내용에서의 한글문제가 있는데 저는 주로 vim을 쓰는데요 .vimrc에 set fileencodings=utf8,cp949 로 해놓으면 파일을 읽을때 utf8인지 cp949(euc-kr)인지 자동으로 인식합니다. 여태 쓰면서 잘못 동작한적은 없었네요..
리눅스에서 UTF8로케일을 사용하면서 격는 불편함은 맥에서도 마찬가지입니다. 왜 맥에서 로케일 지원이 더 뛰어나다고 생각하시는지 모르겠습니다.
윈도우에서는 위와같은 불편함을 느끼지 않겠지만 영어를 제외하고 2개 이상의 언어를 같이 사용한다면 (예를들어 한국어와 중국어)마찬가지로 불편할 것입니다. 그리고 윈도우에서 사용하는 많은 프로그램들이 non-unicode program 이고 이들을 위한 언어설정이 제어판에 있지만 변경하기 위해서는 재부팅이 필요합니다. 한번 이 설정을 바꿔서 사용해보면 윈도우에서도 문제가 많다는 것을 알 수 있습니다.
hal 에서 USB 자동
hal 에서 USB 자동 마운트 문제 때문에 결국 데스크탑도 리눅스도 로케일을 ko_KR.UTF-8로 바꿨습니다.
다행히 기존에 한글 파일명을 쓰는 것을 극도로 자제해 왔던 터라 몇몇 한글 파일이 있는 디렉토리를 vmware 윈도우즈를 이용해서 팝폴더에 업로드를 해서 백엄을 한 다음, 한글 파일 이름을 가진 파일을 일단 삭제한 후 로케일을 변경하고, /etc 와 홈디렉토리 설정파일들에서 eucKR, EUC-KR 등을 grep 해서 설정을 고쳐주니 별 문제없이 동작하는군요.
이제는 확실히 ko_KR.UTF-8 이 대세인 듯 합니다.
저야 한글 이름 파일이 몇 개 안 되어서 마이그레이션이 별로 어렵지 않았지만, 혹시 한글 이름을 가진 파일이나 디렉토리가 많은 분들이 ko_KR.eucKR 로케일에서 ko_KR.UTF-8 로 손쉽게 파일 이름을 마이그레이션 할 수 있는 툴 같은 것은 없나요?
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
뭔가 계속 착각
뭔가 계속 착각 하시는 것 같은데...
1. 리눅스의 파일명은 시스템 로케일과는 상관 없이 들어 갑니다.
설명이 조금 난감한데, 파일 명 자체는 그냥 바이트 상대로 무조건 들어 갑니다. 나중에 ls 같이 파일명을 불러 올때 로케일에 따라서 보여주는 겁니다. 따라서 원하신다면, 시스템 로케일과 특정 파일의 로케일을 다르게 셋팅해서 사용하는 것도 상관 없습니다.
제가 운영하는 서버는 시스템 로케일은 UTF-8인데, 지인들은 자기들 홈폴더를 EUC-KR로 셋팅해서 사용합니다. (그게 더 편하데나.. -_-)
사실 홈폴더를 따로 셋팅하는 것은 없고, 그냥 EUC-KR로 사용하는 겁니다.
2. 일괄적으로 파일명의 로케일을 바꿔 주는 프로그램은 있습니다. ^^
convmv - converts filenames from one encoding to another
내용을 바꾸실때는 iconv를 사용하면 되겠죠.
3. 결론적으로 언급하신 로케일 변경을 위해서 파일을 외부로 옮기는 작업은 필요 없습니다.
저의 글을 계속 오독하시는 것 같은데 ...
1번은 저도 이미 잘 알고 있는 내용이랍니다.
2번이 바로 제가 알고 싶은 내용이었습니다. 그런 유틸리티를 알았으면 파일을 밖으로 빼돌렸다가 다시 복사해 오지도 않았죠.
바깥으로 파일을 옮긴 것은 2번과 같은 유틸리티가 있는지 없는지 몰라서 (그렇다고 iconv로 프로그래밍하기는 귀찮아서 -_-;;) 아예 다른 시스템으로 옮겼다가 로케일 바꾸고 난 후에 다시 복사해 오면 알아서 제대로 세팅되기 때문입니다.
답변 내용은 고맙습니다만 글을 오독하시고 난 후에 적반하장으로 착각이라고 하시는 것은 좀 문제가 있는 태도로 보입니다.
어쨌든 덕분에 convmv 패키지를 설치하였습니다.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
fuse-convmvfs 편합니다.
fuse-convmvfs 편합니다. 적당한 디렉토리로 다시 마운트 한번 더 해주고 그냥 그곳으로 접근하면 됩니다.
gnome, euckr 환경에서 removable device 자동마운트를 euckr 로 하는 것은 개인적으로 거의 불가능에 가깝다고 생각합니다.
실제로 살펴본 것은 아니지만, 어딘가에 분명히 하드코딩 되어 있을 거라 강력하게 의심하고 있습니다.
hal 의 fdi 들엔 valid_options 만 정의하고 있고,
gconf-editor 를 통해 살펴본 /system/storage/default_options/vfat/mount_options 에도 charset관련내용이 없는데,
실제로는 마운트옵션에 utf8 이 붙어서 진행됩니다.
iocharset=utf8 이 아니라 이것보다 우선시되는 utf8 이라는 옵션을 누군가가 지정합니다.
OTL
말씀을 읽고,
말씀을 읽고, gnome-volume-manager 소스를 살펴본 결과, ko_KR.UTF-8 로케일에서는 gnome-volume-manager에서 마운트 옵션에 utf8을 추가하도록 하드코딩되어 있습니다. 그런데 제가 살짝 살펴본 바로는 gnome-colume-manager가 ko_KR.eucKR에서는 utf8옵션을 추가하는 것 같지는 않고, iocharset=cp949를 추가하도록 되어 있습니다. 물론 어떤 다른 "누군가"가 utf8 옵션을 추가할 가능성이 있기는 합니다.
그런데 bushi님의 다른 글을 보아도 그렇고, 특별히 ko_KR.eucKR 환경에서 usb storage의 vfat 파티션이 자동으로 마운트 될때, utf8 옵션이 붙는지를 테스트하신 거 같지는 않습니다. 이건 제 짐작이고 쓰신 글에서 이 부분에 대해서 명확하게 밝히지 않으셔셔 궁금하군요.
자동마운트에서 로케일에 따라서 마운트 옵션이 제대로 설정되지 않는다면, 이건 충분히 추적이 가능하고 또 해결 가능한 문제입니다. 다만 이걸 추적하기에 앞서서 이 문제가 imyejin님만의 문제였는지, 다른 시스템에서도 재현가능한 문제인지 살펴보아야겠지요. 그런데 앞으로도 거의 100% ko_KR.eucKR 로케일을 다시 사용할 일은 없을 것이기 때문에, 일부러 어디가 문제인지 추적하고 싶은 마음이 생기지는 않는군요... 동기부여가 문제네요.
착각 맞습니다.
착각 맞습니다. 맞고요... -_-
마이그레이션에 가장 간단한 방법을 알려 드리겠습니다.
(EUC-KR -> UTF-8)
1. 일단 USB를 하나 준비 합니다. 물론 하드도 좋습니다. 요는 fat32파티션이면 됩니다.
2. 일단 EUC-KR환경에서 iocharset=cp949, codepage=cp949로 마운트 합니다.
3. 원하는 파일들을 복사한후 언 마운트 합니다.
4. UTF-8로 로케일를 바꾸고, iocharset=utf8, codepage=cp949로 다시 마운트 합니다.
5. 백업한 내용을 다시 복사합니다.
어.. vmware를 사용하시는 군요...
1. samba에서 서버 로케일을 euc-kr로 설정한다.
2. vmware안의 xp에 백업한다.
3. samba에서 서버 로케일을 utf-8로 바꾼다.
4. vmware안의 xp에서 백업한 내용을 다시 복원한다.
생각해보니 FTP를 이용해서도 가능하겠군요. PURE-FTPD를 이용하면, 걍 복사하는 것만으로도 해결 가능 하겠네요.
아니면 FTP와 samba의 조합으로도 가능하군요.
마이그레이션에 폴플을 사용하셨다는 것 자체가 착각에 빠져 있으신겁니다.
"ko_KR.UTF-8 불편한 점 및 문제점" <- 이런제목으로 글을 쓰긴 것 자체가 착각에 빠져 있으신겁니다.
<- 이것 자체가 착각에 빠져 있으신겁니다. 제가 보기에는 아직도 인코딩에 대한 개념이 없으신것 같거든요... -_-
착각에 빠진 것은
착각에 빠진 것은 vamf12 님입니다. 저도 다 아는 내용이니 혼자만 아는 것처럼 떠벌이지 말아 주시기를 부탁드립니다. 남을 무시하는 듯한 발언으로 자신의 실력이 높아 보이는 것이 아니랍니다. 잘난체 하고자 하는 마음은 십분 이해하나 이런 기초적인 내용으로 잘난체 해 보았자 알아 줄 사람도 없습니다. vwmare 파티션을 작게 잡아 놓고 하드 용량도 딸려서 어쩔 수 없이 외부에 백업한 것입니다. (하필이면 한글 파일 이름 중에 2G 짜리 HDTV 녹화 파일이 몇 개 있어서 말이죠.)
그리고 UTF8로 로케일을 바꾸면서 건드려야 할 설정 파일들(samba 나 gnone, kde 등의 전역 혹은 홈디렉토리 설정 파일)이 정확히 얼마나 되는지 미리 모르기 때문에 혹시나 실수로 시스템일 꼬이게 만들까봐 일부러 원격으로 복사본을 하나 더 만들어 놓은 것이랍니다. 백업의 기본은 원격지에 복사본을 만들어 놓는 거에요. 원격지에 제가 직접 운영하는 서버가 없으니 웹폴더 프로그램을 사용한 것이랍니다.
또한 ko_KR.UTF-8 을 사용하면 euc-kr 파일명을 압축한 zip 파일을 압축 풀었을 때 불편한 건 다 아는 사실인데 혼자만 모르시는 건가요?
제가 모르는 유틸리티를 것을 알려 주신 것에 대해서는 감사를 드립니다만, 너무 어줍잖은 것으로 잘난체를 하시는 것 같아서 보기에 민망하니 자제하세요. 그럼.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
여전히 착각 하고
여전히 착각 하고 계시는 군요... -_-
다른 로케일이라면 모르겠지만, UTF-8과 euckr은 완벽하게 호환됩니다. 시스템상으로 말이죠.
꼬일 까봐? 절대로 꼬일일 없습니다. - 물론 잘못 설정하면 한글 파일들은 이상하게 보이겠죠. 아쉽게도 시스템이 이상해지진 않습니다.
(UTF-8, EUCKR 둘다 영어는 1byte로 표현합니다. 즉 기존의 아스키코드와 동일하게 동작합니다. 시스템에 관련된 모든 파일은 영문이니 시스템과는 상관 없겠죠^^. 사실 이부분이 UTF8의 인기의 이유겠죠. )
위에 썻던 방법은 그냥 vmware를 이용할때의 방법이었습니다.
사실 굳이 vmware를 쓸 필요도 없습니다.
rfc2640을 지원하는 ftp데몬이나 ftp클라이언트 하나만 있어도 됩니다. 걍 복사하면 되거든요... -_-
어쨌든 한수 아래로 보는 저의 어투가 예진아씨님 마음을 상하게 한것은 알지만, 거기에 대고 모르면서 훈계하는 듯한 말투를 사용하는건 보기 안쓰럽습니다. 예진아씨님의 실력뿐아니라, 성격까지 드러나 거든요... -_-
일단 리눅스를 사용하면서, - 사실 리눅스나 컴퓨터 뿐만이 아니라 모든 것에서 - 가져야 할 자세는 겸손입니다.
자신이 아는것이 모두가 아니라는 사실을 항상 주지 하고 있어야 합니다.
그런데 예진아씨님은 자신이 격은 사실에 대해서 모두 단정체를 사용하시고 계십니다.
"리눅스에서는 않됩니다." <- 이렇게 말이죠.
제가 잘난척 하는 겁니까? 예진 아씨님이 잘난척 하는 겁니까?
예진이가 짧은
예진이가 짧은 컴터지식으로 짓걸여 놓은거니
그거려니 해
큰 프로젝트를
큰 프로젝트를 하나라도 해보셨는지 의심이 드는군요.
로케일 같은 거 안바꾸고 멀쩡히 ls 하면 잘 보이는 디렉토리에서도 실수로 뭘 지워서 자료나 소스를 날려 본 적이 한번도 없으신가요?
그렇다면 vamf12님은 경험이 부족하거나 아니면 워낙 신중한 사람이라 백업이 필요없는 분일지도 모르겠습니다.
저는 리눅스 처음 배울 때부터 rm -rf 삽질이라든지 같은 것을 많이 하고,
회사에서 신입 때 사고도 치고 그래서 백업의 중요성에 대해 항상 절실히 느끼고 있답니다.
로케일 바꿔 가면서 디렉토리 리스팅 확인하다 글자 안보이는 상태에서 저는 제 자신을 못 믿겠습니다.
웹폴더들 말고 FTP 계정 10G 이상씩 지원하고 대역폭도 그만한 곳 있나요?
무슨 IDC 안에 이용할 서버가 있는 게 아닌 이상은 그만한 곳이 많지 않을텐데
원격 백업을 하려고 했다고 하니까 FTP 사용하면 되지 않느냐고 괜한 시비를 거시는군요.
제가 단정적인 말투를 사용한 것에 대해 지적한 것은 고맙습니다만,
UTF-8 이외의 로케일에서 hal 자동마운트 옵션에 문제가 있는 것은 사실입니다.
vamf12 님은 이것에 대해 숙지하고 저에게 시비를 거시는 것인지요?
vamf12님은 컴퓨터가 시스템도 아닌 사람에 대해 단정적인 어투를 사용하고 있답니다.
다른 사람들도 다 알고 아래 글타라에서도 논의된 내용에 대해 뒷북을 치면서 개념이 없다 뭐다 하는 걸 보니
그냥 저한테 한번 시비를 걸어 보려고 하시는 듯 한데, 이건 잘난체의 문제도 아니고,
아니고 그냥 버릇이 없는데다 말귀도 잘 못 알아 듣는 것이랍니다.
다른 사람과 대화하는 법을 좀더 배우시고 자신만이 확실히 알고 있다는 착각에서 벗어나
겸손해지시라는 똑같은 말씀을 저도 드리고 싶네요.
[예진아씨 피카사 웹앨범] 임예진 팬클럽 ♡예진아씨♡ http://cafe.daum.net/imyejin
아쉽게도 저는 뭐든
아쉽게도 저는 뭐든 지우는 것을 좋아하지 않기 때문에, 그런것 때문에 문제가 된적이 한번도 없었습니다. ^^
더욱 아쉽게도 백업에 대한 정의가 다르가 다르다고 해서 저를 경험이 부족한 사람으로 만드시는 것에는 동의 할수 없습니다.
더 더욱 아쉽게도 단순히 신중한 사람으로 만드는 것에 동의 할 수 없습니다.
제 말투에도 문제가 있다는 지적 감사합니다.
제 글이 너무 단정적이고 짧아서 의사 소통에 문제가 있었던점 죄송합니다.
제가 마지막으로 언급한 FTP는 로컬 상에서 복사하시라는 말씀이었습니다. 즉 파일의 인코딩을 바꾸는 방법으로 가장 간단한 방법을 제시한것입니다. - vmware안의 윈도우에 파티션이 부족하다고 하시길래 그런겁니다. 뭐 윗글들 중에서 나온 RAR압축이 유니코드를 사용하니 RAR을 사용해도 되긴 하겠군요.. ^^
FTP와 원격지 백업은 아무런 관련이 없는 사항이었습니다. 원격지 백업을 하시는 것에 대해선 아무런 반대의 여지가 없습니다.
- 팝폴더를 사용하시던, ㅂㅌ스럽게 쥐메일을 사용하시던, 그건 순전히 개인의 취향일 뿐이니까요.
하지만, 원격지 백업을 해야 하는 이유가 단순히 시스템 설정 변경이라면 동의 할 수 없다는 뜻이었습니다.
아무런 영향을 미치지 않을 것을 알고 있는데, 구태여 백업을 하는 것은 [기우]가 아닐까 합니다.
뭐 어쨌든 백업에 관련된 사항은 전적으로 취향 문제이니 이것에 대해서 논의 하는 것은 의미가 없을 것 같습니다. - 한번더 언급하지만, 제글을 보면 저는 분명히 시스템운영과 특정 로케일관의 상관 관계를 부정했을뿐 원격지 백업이 의미가 없다는 말을 아니었습니다.
제 말투에 문제가 있다는 것은 동의 합니다. 인정합니다. 사과 드립니다. - 솔직히 말해서 기분나쁘라고 한것이었습니다.
애초에 제가 먼저 시비를 걸었으니 제가 사과를 하겠습니다.
댓글 달기