뭘 이런걸..
[miscellany]
enable-auto-props = yes
[auto-props]
*.java = svn:keywords=Author Date Id Revision;svn:eol-style=native
shell> svn up
shell> svn propset svn:keywords "Author Date Id Rev" file_name
shell> svn commit -m "Adding Id and Rev property to all files"
Python Chardet result:
google.cn {'confidence': 0.98999999999999999, 'encoding': 'GB2312'}
yahoo.jp {'confidence': 0.98999999999999999, 'encoding': 'utf-8'}
amazon.co.jp {'confidence': 1, 'encoding': 'SHIFT_JIS'}
pravda.ru {'confidence': 0.93312187961594417, 'encoding': 'windows-1251'}
auction.co.kr {'confidence': 0.56471064895612277, 'encoding': 'ISO-8859-2'}
haaretz.co.il {'confidence': 0.98999999999999999, 'encoding': 'windows-1255'}
www.nectec.or.th {'confidence': 0.77645629965698426, 'encoding': 'TIS-620'}
feedparser.org {'confidence': 0.98999999999999999, 'encoding': 'utf-8'}
PHP mod_chardet result:
google.cn (7121)
ICU : Encoding -> GB18030 Confidence -> 100
MOZ : Encoding -> GB2312 Confidence -> 98
yahoo.jp (30367)
ICU : Encoding -> UTF-8 Confidence -> 100
MOZ : Encoding -> utf-8 Confidence -> 98
amazon.co.jp (166082)
ICU : Encoding -> Shift_JIS Confidence -> 100
MOZ : Encoding -> SHIFT_JIS Confidence -> 100
pravda.ru (97826)
ICU : Encoding -> ISO-8859-1 Confidence -> 28
MOZ : Encoding -> windows-1251 Confidence -> 93
auction.co.kr (101330)
ICU : Encoding -> EUC-KR Confidence -> 100
MOZ : Encoding -> ISO-8859-2 Confidence -> 56
haaretz.co.il (174179)
ICU : Encoding -> ISO-8859-1 Confidence -> 32
MOZ : Encoding -> windows-1255 Confidence -> 98
www.nectec.or.th (41527)
ICU : Encoding -> ISO-8859-1 Confidence -> 37
MOZ : Encoding -> TIS-620 Confidence -> 77
feedparser.org (28443)
ICU : Encoding -> UTF-8 Confidence -> 100
MOZ : Encoding -> utf-8 Confidence -> 98
18.33 Sec
$buf = preg_replace ('/<[^>]*>/', '', $buf);
PHP mod_chardet result:
google.cn (2781)
ICU : Encoding -> GB18030 Confidence -> 100
MOZ : Encoding -> GB2312 Confidence -> 98
yahoo.jp (3561)
ICU : Encoding -> UTF-8 Confidence -> 100
MOZ : Encoding -> utf-8 Confidence -> 98
amazon.co.jp (30739)
ICU : Encoding -> Shift_JIS Confidence -> 100
MOZ : Encoding -> SHIFT_JIS Confidence -> 100
pravda.ru (15728)
ICU : Encoding -> windows-1251 Confidence -> 28
MOZ : Encoding -> windows-1251 Confidence -> 94
auction.co.kr (36084)
ICU : Encoding -> EUC-KR Confidence -> 100
MOZ : Encoding -> ISO-8859-2 Confidence -> 27
haaretz.co.il (44570)
ICU : Encoding -> ISO-8859-8-I Confidence -> 23
MOZ : Encoding -> windows-1255 Confidence -> 98
www.nectec.or.th (10425)
ICU : Encoding -> EUC-JP Confidence -> 64
MOZ : Encoding -> TIS-620 Confidence -> 76
feedparser.org (5854)
ICU : Encoding -> UTF-8 Confidence -> 100
MOZ : Encoding -> utf-8 Confidence -> 98
4.86 Sec
정균님 안녕하세요.
요 모듈 아직도 서포트 받을 수 있는지 궁금하네요 ^^
libtool 버전이 2.2.6으로 올라가면서 CDPATH관련 에러두 나구요. --tag를 찾네요
그리고
/home/sangjins/mod_chardet/php_chardet.h:104: error: expected specifier-qualifier-list before 'UErrorCode'
/home/sangjins/mod_chardet/php_chardet.c: In function 'zif_chardet_detect':
/home/sangjins/mod_chardet/php_chardet.c:375: error: duplicate case value
/home/sangjins/mod_chardet/php_chardet.c:367: error: previously used here
/home/sangjins/mod_chardet/php_chardet.c:392: error: 'CharDetObj' has no member named 'status'
/home/sangjins/mod_chardet/php_chardet.c: In function 'chardet_obj_init':
/home/sangjins/mod_chardet/php_chardet.c:422: error: 'CharDetObj' has no member named 'status'
/home/sangjins/mod_chardet/php_chardet.c: In function 'moz_chardet':
/home/sangjins/mod_chardet/php_chardet.c:442: error: 'CharDetObj' has no member named 'status'
/home/sangjins/mod_chardet/php_chardet.c:448: error: 'CharDetObj' has no member named 'status'
의 에러도 나네요; 잘 사용하다가 재설치 하려니 이런 문제가 발생했습니다;
바쁘신데 이거 실례가 되지 않을런지.. ㅜㅜ
제 짧은 소견으로는 배포가 문제라면 귀찮게 소스 관리를 하시느니, 정적으로 link 시키는 것이 더 편하지 않을까 싶습니다. MPL 은 GPL 이나 LGPL 처럼 과격하지 않으니, static link 하시거나 dynamic link 하신 후에, MPL 라이센스 파일 하나 넣어 주시는 것으로 끝이 납니다. 전반적으로 GPL/LGPL로 배포를 하고 싶으시다면, 특정 부분에 call 을 MPL call 을 사용하신다고 명기를 하시면 될 것 같습니다. MPL은 다른 라이센스와 결합하는데 크게 지장이 없는 라이센스이니까요.
제가 개발하는 코드들은 대부분 필요에 의해서 제작을 하는 것입니다. 그렇기 때문에 순수하게 제가 처음부터 설계/코딩을 하는 경우 보다는 비슷한 것을 찾아서 제가 사용하기 편하도록 수정/개발을 하는 경우가 많습니다.
그러다 보니, 항상 license가 문제가 골치거리가 되는데, 가장 좋은 방법은 원 코드의 license 를 유지하는 것이 가장 편한 방법이더군요. 그리고 libcharset 의 원형이 Mozilla Universal Charset Detector 이기는 하지만, 저는 이 코드를 Perl Moudle 에서 친절하게 잘 분리해 놓은 것을 C wrapper 를 만들어서 c/c++ library 로 둔갑을 시켜 놓은 것입니다. 그리고 해당 Perl Module 이 license를 MPL로 해 놓아서 저 역시 이를 승계한 것이고요.
다만, Universal Chardet code 를 보면 MPL/GPL2/LGPL2.1 중에 하나를 선택할 수 있도록 되어 있습니다. 그리고, 저와 Perl module 개발자가 추가한 코드에서 이 문구는 역시 포함이 되어 있기 때문에 재배포를 하시고 싶고, license 를 변경하고 싶다면 저작권에 위배되지 않도록 결정을 하시면 될 것 같습니다.
저도 나름 살짝 고민했다가 GPL보다 MPL이 더 자유롭지 않을까 생각해서 MPL로 그냥 고민없이 승계를 했습니다.
mod_chardet 0.0.2 로 업데이트 했습니다. Python C API로 지원하던 mozilla universal charset detect mode 를 제거하고, libchardet 을 만들어서 C++로 지원하도록 변경했습니다. 속도가 캡빵 빨라졌습니다. :-) python-chardet 보다 정확도가 조금 더 좋습니다.
ftp://ftp.oops.org/pub/oops/php/extensions/mod_chardet 에서 받으실 수 있습니다.
http://cvs.oops.org/?cvsroot=PHP-Module&module=mod_chardet&file=README,v&rev=1.3 를 참조해서 빌드 하실 수 있습니다.
이 버전은 libchardet 이 기본 모드로 지원되며, CHARDET_ICU mode 로 ICU chardet mode 를 사용할 수 있으며, 개발시의 debug mode로 CHARDET_PY (default option 아님) 를 이용할 수 있습니다.
source 안에 있는 test.php 와 http://cvs.oops.org/?cvsroot=PHP-Module&module=mod_chardet&file=Reference,v&rev=1.1 를 참조하시면 될 것 같습니다. test.php 역시 제일 첫라인을 제외하면 web에서 그대로 사용하실 수 있습니다.
shell> openssl x509 -in cacert.cer -inform DER -out cacert.pem -outform PEM
LDAP Support => enabled
RCS Version => $Id: ldap.c,v 1.161.2.3.2.13 2008/05/04 21:19:17 colder Exp $
Total Links => 0/unlimited
API Version => 3001
Vendor Name => OpenLDAP
Vendor Version => 20327
SASL Support => Enabled
<?php
function make_ad_passwd ($pass) {
$pass = '"' . $pass . '"';
$len = strlen ($pass);
for ( $i=0; $i<$len; $i++ )
$newpass .= $pass[$i] . "\000";
return $newpass;
}
?>
<?php
# SSL 로 접속을 해야 하기 때문에 ldaps:// protocol 을 사용한다.
$host = "ldaps://ad.domain.controller.com";
# ldaps 의 기본 포트는 636 을 사용한다.
$port = "636";
# 인증서 설정
$certfile = '/some/path/cacert.pem';
# default DN
$defaultdn = 'domain_manager@DOMAIN.NAME.COM';
$accesspw = 'password_of_domain_manager';
# 관리 OU
$ou = "OU=Users,DS=DOMAIN,DS=NAME,DS=com"
$username = $argv[1];
$userpass = $argv[2] ? $argv[2] : 'abcd';
if ( ! $username ) {
echo "ERROR: You must input changed username on argv[1]\n";
exit 1;
}
#
# system 의 ldap 설정을 건드리지 않고 하기 위해서 다음의 환경 변수를 설정한다.
putenv ('LDAPTLS_REQCERT=never');
putenv ("LDAPTLS_CACERT={$certfile}");
$ldap = ldap_connect ($host, $port);
if ( $ldap === false ) {
echo "ERROR: connect failed to $host\n";
exit 1;
}
$bind = @ldap_bind ($ldap, $defaultdn, $accesspw);
if ( $bind === false ) {
echo ldap_error ($ldap) . "\n";
exit 1;
}
$filter = "(samaccountname={$username})";
$result = ldap_search ($ldap, $ou, $filter);
ldap_sort ($ldap, $result, 'sn');
$info = ldap_get_entries ($ldap, $result);
for ( $i=0; $i<$info['count']; $i++ ) {
echo "You are changing the password for " .
$info[$i]['givenname'][0] . ", " .
$info[$i]['sn'][0] . " (" .
$info[$i]['samaccountname'][0] .
") to {$userpass}\n";
$userdata['unicodePwd'] = make_ad_passwd ($userpass);
$result = ldap_mod_replace ($ldap, $info[$i]['distinguishedname'][0], $userdata);
if ( $result === false )
echo "There was a problem changing your password, please call IT for help\n";
else
echo "Your password han been changed!\n";
}
@ldap_close ($ldap);
?>
일단 bind 문제는 답변을 하기가 쉽지 않네요. AD 에서 ldaps:// protocol 을 받아 주는지 확인이 되었나 부터가 우선이 되어야 해서요.
그리고, 인증서는 저의 경우에는 PEM 형식만 가능 햇습니다. 문서들에서 PEM 형식으로 변환하라고 되어 있었고요.
그리고, defaultdn, 과 accesspw 가 고정되어 있는 이유는, 위의 스크립트의 목적이 각 개별 사용자가 암호를 변경하기 위한 목적이 아니라, 전체 리스트를 관리를 하는 것이 목적이기 때문에 super user 의 권한을 가진 ldap 계정을 지정해 놓은 것입니다.
각 계정별로 자신의 password를 수정하는 것이라면 각 계정의 dn와 pw를 이용해도 무방합니다. 단, 자기 자신의 것만 수정이 가능 하겠죠.
담변 감사합니다.
SFU 3.0를 간단히 테스트해보았습니다. 테스트하면서 글을 읽으니 많이 도움이 되고 있습니다.
그런데 필자님의 글에 다른 의문이 하나 더 생겼습니다.
password sync 이 부분인데요 Windows AD의 유저, 패스워드를 어떤 식으로 Linux하고 동기화 시키는지 잘 모르겠습니다.
예로 생성파일을 user id로 정했다면 UFS를 통해 유저의 ID를 리눅스 시스템 인지하는 것은 어느정도 알겠는데 passwd 부분에서 어떻게 동기화를 시키는지 궁금합니다.
그러므로 사용자의 AD암호만 변경하면 실제로 서비스를 하는 Linux NIS까지 암호가 변경이 이해가 잘 가지 않습니다.
자꾸 귀찮게하는것 같습니다. 아직 많이 부족하여 자꾸 질문을 드리게 됩니다.
조언 기다리겠습니다.
이승환
019-445-1813
lucifertear@gmail.com
예)
너무 대단한 작업으로 생각 하시는 것 같습니다. :-) sync 는 간단하게 Linux NIS 에서 ypcat 으로 AD의 NIS entry 를 가져와서 파싱하여 Linux NIS entry 를 새로 생성하는 것 뿐입니다. 즉 AD의 NIS entry 에서는 userid/passwd field 만 사용하고, 나머지 정보는 Linux NIS 서버에서 알아서 취급을 한다는 의미입니다.
현재는, ypcat 을 사용하지 않고, Linux NIS 서버에서 LDAP 으로 AD의 SFU entry 들을 가져와서 NIS entry 를 만들고 있습니다. ^^;
Windows 2003R2 부터는 MS 예전에 application 으로 제공해 오던 Service For Unix (SFU) 를 service 로 제공합니다. 그래서 SFU에 있는 NIS를 이용해서 AD에서 NIS service 를 할 수 있습니다. 그런데 SFU의 NIS의 문제가 AD entry 에 multibyte 문자가 존재할 경우 예를 들어 CN 값을 한글 이름으로 지정할 경우, 관리툴에서 Unix Attribute tab 의 활성화가 되지 않습니다. 그래서 power shell 로 CN부분을 id와 동일하게 넣고선, Linux 에서 AD의 nis entry 를 받아와서 CN부분을 LDAP으로 값을 가져와서 복구시킨 후에 Linux NIS 에 entry 를 생성하는 방식을 사용한 것입니다. 즉, AD의 NIS는 password sync 를 위해서만 사용을 하고, Linux NIS가 실제 NIS 서비스를 하는 셈이 되는 것이죠.
이렇게 구성하면 사용자 입장에서는 AD의 암호만 변경을 하면 NIS까지 같이 변경이 되니 2군데 암호를 변경할 필요가 없게 되는 것이고요. 그리고 이렇게 이원화를 해 놓으면, OU별로 별도의 NIS entry 를 구분할 수 있는 점이 이런 설계를 가져오게 된 것입니다. 즉, 이 문서에서의 LDAP은, Linux NIS 에서 AD에서 가져온 entry 를 복구하기 위하여 사용을 하는 꽁수 때문에 작성이 된 것입니다.
사진 보기..
사진 보기..
사진 보기..
0.1 patch file
0.1.1 patch file
여기 저기 찾아가며, 설치는 했는데 여러가지 문제가 많네요...
그래서 도움 좀 구하고자 합니다...
현재 설치 버젼은 trunk-r1993 입니다.
문제1. roundcubemail에서 메일을 보내고 Outlook Express에서 회신을 하게 되면...
회신 내용이 roundcubemail에서 깨져 보이네요..(헤더 정보를 보면 UTF-8로 보내서 UTF-8로 받는데...그리고 MS-Outlook에서 회신하게 되면 roundcubemail에서 깨져 보이지 않습니다. Outlook Express만의 문제인것 같습니다만...)
문제2. 최신 버젼은 아래와 같이 main.inc.php 파일에 설정하는 부분이 있습니다.
0, 1번 설정에 대해서는 파일첨부하여 보낼시 한글파일명이 깨집니다.
그리고 2번 설정에 대해서는 긴파일명(한글)에 대해서 깨집니다.
// Encoding of long/non-ascii attachment names:
// 0 - Full RFC 2231 compatible
// 1 - RFC 2047 for 'name' and RFC 2231 for 'filename' parameter (Thunderbird's default)
// 2 - Full 2047 compatible
$rcmail_config['mime_param_folding'] = '설정번호'
위 2문제로 낑낑대고 있는데...잘안되네요. 도움좀 부탁드립니다.
첫번째 OE 가 보낸 메일을 못 읽는 것은 UTF8 BOM 때문입니다. 보통 Unix 군에서는 UTF8 BOM을 사용하지 않는 것을 권장하고 있는데, MS의 몇몇 application (특히 notepad) 들이 BOM code 를 사용하고 있습니다. 여기서 OE가 UTF-8 encoding 을 할 때 BOM code 를 넣는 것 같군요. 일단 BOM code 제거를 하니 제대로 출력이 되는 것을 확인했습니다.
그리고 두번째 문제도 수정을 하기는 했습니다만, 패치를 받아 줄지는 모르겠군요. 딱히 버그라고 할 수도 없고, RFC2047에 보면 encoding 된 문자열이 75byte 가 넘지 않아야 한다고 되어 있어, roundcube 에서는 75자가 넘어갈 경우 그냥 뒤를 버려 버리므로서 발생하는 문제입니다. rfc2047에 의거하면, 75자가 넘을 경우, carrage return, new line, space를 이용해서 그 이후의 string 을 연결하면 된다고 되어 있어, 이렇게 수정해서 패치를 제공하기는 했습니다만.. 받아 들여줄지는 저도 보장은 못하겠습니다. :-)
일단, 두가지 문제에 대해서 patch는 제출한 상태이니 기다려 보시기 바랍니다.
오늘 하루 꼬박 날라갔군요. 앞으로는 더 이상 roundcube 문제 해결에 관여하지 않을 생각 입니다. roundcube 의 code 가 엄청나게 복잡한 관계로 문제가 되는 부분을 찾는데 걸리는 시간이 대부분이다 보니 회사에서의 눈치가 장난이 아닙니다. 제가 roundcube 를 굳이 사용하는 입장도 아닌 상황에서 무상 지원은 쉽지 않을 것 같습니다.
그리고 더 중요한 것은 끝이 없어요 T.T 저는 봉이 아니랍니다. ^^
http://trac.roundcube.net/ticket/1484961 에서 거부당했던 패치의 ticket 이 다시 열렸습니다. 0.2 에서 해당 내용이 많이 반영이 되었는데, 아직 좀 부족한 편입니다.
일단, charset 에 상관없이 charset 이 잘못 출력될 수 있는 버그 2개에 대한 패치를 제공한 상태이며, 여전히 body 에 charset이 지정되지 않았을 경우, IMAPD 가 US-ASCII나 X-UNKNOWN을 리턴해서 발생하는 부분은 여전히 고쳐지지 않았습니다. 그래서 패치를 다시 제출한 상태인데, 잘 받아들여질지는 모르겠군요.
다만, 해당 ticket 에 제시된 이미지들이 좀 낯뜨거운 이미지들이군요.. ^^; sample 제출을 잘 못한듯.. ㅋㅋ
Message body 에 charset 이 지정되지 않았을 경우가 문제가 되고 있네요. 개발자들이 사용하는 imapd 인 Courier의 경우에는 charset 이 지정되어 있지 않을 경우 NIL을 return 하기 때문에 제대로 보이는데, Cyrus-imapd 나 Wu-imapd 의 경우에는 US-ASCII 나 X-UNKNOWN을 return 하기 때문에 깨지는 문제가 발생하는데, 이 부분에 대한 조율이 쉽지 않네요. 쩝.. 0.2 에서는 이 문제가 해결이 되어 나올지 쉽지 않은 문제인것 같습니다.
문제가 하도 많아서.. SSL 모드시에 헤더 출력 부분은 현재 무시된 상태이고, 리스팅에서도 CHARSET을 가진 제목이 있을 경우 다음 나오는 제목이 CHARSET이 없을 경우 이전의 CHARSET 이 유지되는 문제도 있는데 역시 묻히고 있는 듯한 기분이 ^^;
안되는 영어로 하려니 저도 힘들고.. 보는 사람도 힘들지 않을까 예상 됩니다. ㅋㅋ
답변 감사합니다.
덕분에 메일부분은 잘 정리 된듯합니다.
많은 지식을 얻어 갑니다. ^_^
앞전에 적으신 "안녕리눅스 틈새 시장노린다~" 라는 글에 많은 도움 얻었습니다.
이번엔 freeradius + pptpd(poptop) + mysql + dialup_admin 연동하고 OpenWRT(DD-WRT)를 이용하여 공유기를 VPN장비로 사용 할 수 있도록 할 예정입니다.
목표는 공인아이피 대역을 공유기로 내려주고 공유기에서 각 할당된 공인아이피를 클라이언트로 재분배 하도록 할예정입니다.
제가 지식이 부족해서 많은 도움 부탁드리겠습니다. ^_^
전달 받은 내용대로 소스를 수정하니, 문제는 해결되었습니다.
전달해 주신 내용을 천천히 읽어 보니...
예전에 제가 해결하지 못한 imap server charset 문제로 결론을....
예전에 vpopmail + procmail 연동을 해서 "한글"로 차단을 하여 사용을 하였습니다.
아래와 같이 캐릭터 셋을 강제로 변환해서 적용하면 roundcube 웹메일에서 한글로 된 제목 캐릭터가 모조리 다 깨져어요.ㅡㅡ;
뭐 스팸으로 버리지 못했다면 제목을 원복을 해야 하는데...ㅎㅎ
결론은 imap default charset이 있다면 해결 될수 있었다는 답이 나왔는데...
제 느낌으로는 소스 수정으로 procmail 부분까지 해결 될듯 한데요???? 맞는지..?? ^_^
여튼 고생 많으셨습니다.
- 감사합니다 - (_ _);;
[root@ns etc]# cat procmailrc
VIRTUALHOME=`/home/vpopmail/bin/vuserinfo -d $EXT@$HOST`
MAILDIR=$VIRTUALHOME/Maildir/
DEFAULT=$MAILDIR
PATH=/usr/bin:/usr/local/bin:/bin
SHELL=/bin/sh
#LOCKFILE=$HOME/.lockmail
LOGFILE=/var/log/qmail/procmail/procmail.log
VERBOSE=no
:0 Efhw
*^(Subject|From|Cc):.*=\?EUC-KR\?(B|Q)\?
|formail -c | /usr/bin/hcode -dk -m
:0 Efhw
*^(Subject|From|Cc):.*=\?ks_c_5601-1987\?(B|Q)\?
|formail -c | /usr/bin/hcode -dk -m
:0 Efhw
*^(Subject|From|Cc):.*=\?KSC5601\?(B|Q)\?
|formail -c | /usr/bin/hcode -dk -m
:0 Efhw
*^(Subject|From|Cc):.*=\?ISO-8859-1\?(b|B|Q)\?
|formail -c | /usr/bin/hcode -dk -m
:0 BfHw
*^*.filename=.*=\?euc-kr\?(B|Q)\?
|formail -c | /usr/bin/hcode -dk -m
:0
*^Subject: .*(\{광|\[광|\(광|포르노|포X노|광고|광\ 고|홍보|광-고|성인|최저이자|기록\ 안남아요|대출|광1고|廣告|sex|SEX|porno)
/dev/null
*^Subject: .*대박
/dev/null
이건 procmail 의 변환 문제와는 별개 입니다. header 에 charset 이 정의 되어 있느냐 안되어 있느냐의 문제이기 때문입니다. 정의가 되어 있다면 수정하지 않은 roundcubemail 이 잘 처리하고 있기 때문입니다. 문제가 되는 것은 charset 이 정의 되어 있지 않은 메일까지 처리를 하려고 하다 보니 이런 문제가 발생을 하는 것이죠.
원래, MUA를 이용해서 정상적으로 메일을 보내는 경우는 거의 깨지지 않을 겁니다. 다만 스팸이나 웹에서 메일 발송 처리를 하는 것들 중에서 메일 파트 구성을 자기 멋대로 하는 경우가 문제가 발생되는 것이죠.
그래서 그냥 지금 imapd 에 default charset 을 지정하여 무조건 US-ASCII가 나오지 않도록 수정을 해 보고 있기는 합니다. 다른 imapd 는 써 본적이 없어서 고치지는 않겠지만 ^^;
흠.. roundcubemail 개발자와 bug tracking 을 하다가 좀 안습인 상황인 것을 발견했군요.
일단, 메일을 보낼 때 charset 을 정의해서 보내지 않은 메일을 제대로 뿌려주지 않아도 된다면 (Default charset 을 사용하지 않아도 되는 경우죠. 위의 02번 패치를 적용하지 않아도 된다면..) 03번 패치가 필요 없습니다. 03번 패치를 하지 않아도 roundcubemail 이 잘 처리를 해 준다는 의미입니다.
하지만, charset 이 정의되지 않은 메일 (Imap server 는 이 경우 US-ASCII를 return 합니다. 그래서 깨지는 거죠.) 을 US-ASCII 대신 default charset 으로 처리할 경우, 다른 영역에서 같이 사용하는 부분에 영향을 미치게 되어 더 수정을 하게 되는 것이죠.
프로그래밍 적으로는 위의 패치를 다 적용해서 제대로 하는 것이 맞겠지만, 실제로는 IMAP 서버가 default charset 을 지정해서 없을 경우 US-ASCII 대신 DEFAULT CHARSET 으로 return 해 줄 수 있다면.. 더 좋은 방법일 듯 싶습니다.
즉, 제가 roundcubemail 이 수정한 부분 때문에 영향을 받아서 계속 고치고 있느니 IMAP Server 를 수정하는 것이 더 간단한 일이 되어 버리게 되네요 쩝..
이런 안습인 상황이 나오다니 T.T
정말 이번 패치를 적용하고 여러가지 테스트를 해보니 다운로드가 잘됩니다. ^_^
정말 감사합니다.
패치를 적용하고 나서 아래와 같은 새로운 문제가 생겼습니다.(_ _);;
## 한글 메일폴더가 깨지는 현상 ##
http://www.zosel.net/tt.jpg
## 설정 화면엔 한글이 정상적으로 출력 됩니다. ##
http://www.zosel.net/tt1.jpg
음.. 함수를 정말 재활용 많이 하는 군요. 마지막 패치에 약간 수정을 해야 할 것 같군요.
roundcubemail/program/include/rcube_shared.inc 의 576라인에서
if ( preg_match('/MSIE/', $_SERVER['HTTP_USER_AGENT'])) {
부분을
if ( $_GET['_download'] && preg_match('/MSIE/', $_SERVER['HTTP_USER_AGENT'])) {
와 같이 수정해 주십시오.
본문의 패치들은 이 변경사항을 반영하여 다시 올려 놓았습니다.
일단 환경은 CentOS4.6에서 기본적인 APM을 사용하고 있습니다.
최근에 제작된 패치로 웹 메일서버를 재설치 하였습니다.
메일환경은 qmail+vpopmail+dovecot+mysql 로 설치 되어 있습니다.
패치 2개를 실행 후...
$rcmail_config['locale_string'] = 'kr';
$rcmail_config['default_charset'] = 'euc-kr';
이부분만 처리하면 한글부분은 깔끔하게 해결됩니다.(첨부파일 링크 제외)
첨부파일 링크를 해서 메일 확인을 누르고 다운을 받기위해 링크를 클릭하면 아래와
같은 화면이 나옵니다. mod_url은 모듈은 내렸습니다.
## 캡쳐화면 링크해 보냅니다. ##
http://www.zosel.net/cp1.jpg // 페이지 표시 할수 없음
http://www.zosel.net/cp2.jpg // 에러 메세지 나옴
번거롭지만 꼭 좀 부탁 드리겠습니다.
oops님, 이번에 만들어 주신 파일 패치를 적용하였는데...
한글 첨부가 되지 않네요.~
(첨부는 되지만, 다운로드 링크 활성화 되지 않습니다.)
## 아래 결과 ##
[root@ns html]# patch -p0 < roundcubemail-0.1.1-multibyte-attach.patch
patching file roundcubemail-0.1.1/program/include/rcube_imap.inc
patching file roundcubemail-0.1.1/program/include/rcube_shared.inc
patching file roundcubemail-0.1.1/program/lib/Mail/mime.php
patching file roundcubemail-0.1.1/program/lib/Mail/mimePart.php
patching file roundcubemail-0.1.1/program/lib/imap.inc
patching file roundcubemail-0.1.1/program/lib/is_utf8.class.php
## 위 적용 완료 후 한글 첨부파일을 웹메일로 보내고 받기함 //
한글 첨부에 링크가 활성화 되지 않음.
원인이 뭘까요?
일단 어떻게 안되는지를 보여 주셔야 할 것 같고요. (제가 인지하지 못한 부분일 수도 있으니까요.
그리고, config/main.inc.php 에서
$rcmail_config['locale_string'] = 'kr';
$rcmail_config['default_charset'] = 'euc-kr';
두가지 설정이 되어 있나요?
그리고, mod_url 설정 되어 있으면, rcube 에서는 off 시키도록 하세요. UTF8 로 오는 메시지가 변경되면 서버에서는 UTF8로 인코딩 하고 실제 넘어온 것은 EUC-KR이 되면 엉뚱한 문제가 발생할 수 있습니다.
좀 삽질 하느라 오래 걸렸습니다. patch는 지난주에 만들었는데, UTF8 체크하는 부분을 만들다 라이센스 문제로, 아에 KSC5601 이라는 pear package 까지 만들어 버렸습니다. KSC5601 <-> Unicode (UCS4/NCR) <-> UTF8 을 통합적으로 관리할 수 있도록 하며, 예전에 만들어 놓았던 꾸질한 것들의 성능도 상당히 개선 시켰습니다.
이런 딴짓하느라 좀 오래 걸렸고, 오늘 마침 테스트 하다가, 이 패치 때문에, 첨부 이미지가 출력이 되지 않는 버그까지 잡아서 올립니다.
수정하면서 코드를 보다 보니, 열심히 만들었구나 하는 생각은 드는데, multibyte 관련 지원은 거의 없다고 보는 편이 맞을 것 같더군요. 아니 웹/메일상에서의 multibyte 관련 지식이 거의 없는 듯 싶은 느낌이 들었습니다.
c/s의 개념을 오픈소스 개발자들이 갖는 것은 상당히 어려운 일일 것 같습니다. 일반적인 개발자들도 그렇고요.
대체로 프로젝트 초기 단계에서는 외부로부터의 기능추가/수정 요청이나 패치에 대해 매우 환영하고 수용적이지만 시간이 갈수록 어느정도 프로젝트가 안정화되고 뭔가를 추가하는 것보다는 더이상 뺄 것이 없는 상태를 지향하게 된다면 보수적으로 바뀔 수밖에 없습니다. 그시점을 좀더 넘어간다면 외부로부터의 input이 귀찮을(?) 수도 있는 것이지요.
결국엔 어떻게 접근하느냐의 문제로 귀결되겠지만 사람과 사람사이의 문제가 아닐까 합니다. 오픈소스 프로젝트 개발자들에게 조금더 개방적이고 수용적인 자세를 기대하는 것은 자연스러운 일이라고 생각하지만 그것이 must가 되어야 하는 것은 아니기 때문에 오픈소스라고 해서 특별히 다른 잣대를 댈 필요는 없다는 것이죠... ㅎㅎ
Comments List
관리자만 볼 수 있는 댓글입니다.