Thanks you reply so fast. My platform info is:
Slackware 10.1.0 gcc (GCC) 3.3.4 Kernel: 2.6.8.1 host system LANG=en_US
wide literals in source code is Chinese.
I added FileAppender, RollingFileAppender and ConsoleAppender to logger,
never use setEncoding() call for any appender
following source code:
cout << "hello你好hello01" << endl;
lc_logstream << L"hello你好hello02" << LOG4CXX_ENDMSG;
lc_logstream << "hello你好hello03" << LOG4CXX_ENDMSG;
output from FileAppender and RollingFileAppender are following(there are same)
hell?????hello02
????hello03
output from ConsoleAppender is following
hello
but cout can output the right result on screen.
The generated files are plain text file, four question marks taken my
2 Chinese literals' place.
I thought did I need add some compile options with my test program or
when build the Log4Cxx lib?
2006/2/28, Curt Arnold <carnold@xxxxxxxxxxxxxx>:
>
> On Feb 28, 2006, at 12:29 AM, Ken wrote:
>
> >
> > Hi,
> > Forgive me if it's bothersome........
> > Following is my test source code, I use setEncoding() method to
> > set the encoding,
> > but the Asian character in log still can not output correctly, I
> > only can get
> > question mark in file, I tried US-ASCII, ISO-8859-1, UTF-8,
> > UTF-16BE, UTF-16LE,
> > UTF-16 with setEncoding() call, but all same......
> > Anyone can tell me the right way to get the Asian character show
> > in log file?
> > I got the SVN source code on Feb. 19, build the static lib by:
> > ant -Ddebug=false - Dlib.type=static build
> >
> > int main()
> > {
> > PatternLayoutPtr layout = new PatternLayout("%d{ISO8601} [%t] %
> > l %p - %m%n");
> > RollingFileAppenderPtr rfa = new RollingFileAppender();
> > rfa->setName("sizeROLLING");
> > rfa->setLayout(layout);
> > rfa->setFile("tsizeBased-test.log");
> >
> > SizeBasedTriggeringPolicyPtr sbtp = new
> > SizeBasedTriggeringPolicy();
> > sbtp->setMaxFileSize(1024 * 1024 * 10);
> >
> > FixedWindowRollingPolicyPtr swrp = new FixedWindowRollingPolicy();
> > swrp->setMaxIndex(10);
> > swrp->setMinIndex(1);
> > swrp->setFileNamePattern("tsizeBased-test.log.%i");
> >
> > rfa->setRollingPolicy(swrp);
> > rfa->setTriggeringPolicy(sbtp);
> > rfa->setEncoding("UTF-16");
> > //cout << __LINE__ << ": " << rfa->getEncoding() << endl;
> >
> > Pool p;
> > rfa->activateOptions(p);
> >
> > LoggerPtr sizeroll = Logger::getLogger("sizeLogger");
> > sizeroll -> setLevel(Level::DEBUG);
> > sizeroll -> addAppender(rfa);
> >
> > logstream lc_logstream(sizeroll, Level::DEBUG);
> > // lc_logstream << L"koko你好test12+" << LOG4CXX_ENDMSG;
> > lc_logstream << LOG4CXX_STR("koko你好test34-") << LOG4CXX_ENDMSG;
> > lc_logstream << LogString("koko你好test56*") << LOG4CXX_ENDMSG;
> > LOG4CXX_DEBUG(sizeroll, "koko你好test78/");
> > LOG4CXX_DEBUG(sizeroll, LOG4CXX_STR("koko你好test78/"));
> > LOG4CXX_DEBUG(sizeroll, LogString("koko你好test78/"));
> >
> > exit(1);
> > }
> >
> > Thanks in advance...
> >
> >
> >
>
>
> Can you reproduce the problem with a simpler appender, for example,
> does the problem occur with a FileAppender?
>
> What platform are you running on? The code used to support character
> encoding is different between platforms and if there is a bug, it may
> only appear for certain platforms.
>
> Have you examined the generated files with a hex editor? There
> should be obvious differences between a ISO-8859-1 and a UTF-16
> encoded file at the byte level. Obviously, the ISO-8859-1 file can
> only output placeholder characters since it can not represent asian
> characters.
>
> Have you had success compiling other programs containing asian string
> literals? Are you sure that your compiler's encoding expectation is
> correct. Could you try expliciting specifying the source code
> encoding to the compiler (--encoding flag for gcc).
>
> What happened when you used wide literals?
>
> p.s. Using LOG4CXX_STR and LogString should not be used for log
> requests. They represent the internal string representation in
> log4cxx. The log request methods use the external string types
> std::wstring and std::string. LogString may be assignment compatible
> with the external string types, however the encoding expectations may
> be different.
--
Ken
|
