Re: How to write Asian character to file?

[Ken <yo...@gmail.com>]

your word gave great help to me. I resolve the problem, call 
setEncoding("ISO-8859-1") and use literal with L, in log file can see
the right result. It's my fault not log4cxx's.
I am wondering why must call setEncoding("ISO-8859-1")? My LANG is
already "en_US"? Another question is for RollingFileAppender, in 0.9.7
can keep many history files, but in 0.9.8 SVN code only 12 is allowed.
I know rename many files not a good idea when rolling the file, but
how about subfix 0 for the oldest file and subfix MAX for the newest
file? currently is there any way to have history file more than 12?

2006/3/1, Curt Arnold <ca...@apache.org>:
>
> On Feb 28, 2006, at 5:11 AM, Ken wrote:
>
> >   What is right syntax if I want use char array variable with wide
> > character?
> >         char  lc_str[] =  "hello你好hello01";
> >         logstream << lc_str << LOG4CXX_ENDMSG;  // not work
> >   since L only can use with literal.
> >  a fool question, but I just can not figure it out. Hope somebody
> > will tell me.
> >
>
>        const wchar_t  lc_str[] =  L"hello你好hello01";
>
> There is a unit test for encoding support (tests/src/
> encodingtest.cpp) that should be run as part of the Ant build.   Did
> the unit tests pass on your platform?
>
> What happens if you try to output the test string from the unit test:
>
>         //   arbitrary, hopefully meaningless, characters from
>         //     Latin, Arabic, Armenian, Bengali, CJK and Cyrillic
>         const wchar_t greeting[] = { L'A', 0x0605, 0x0530, 0x986,
> 0x4E03, 0x400, 0 };
>
> If that works, I'd suspect that there is a mismatch between source
> file encoding and the encoding expectations of your compiler.  For
> example, your source file might be in UTF-8 and the compiler expects
> ISO-8859-1.  The string in the unit test would not be affected be an
> source file encoding mismatch.
>
> You mentioned that your LANG is "en_US".  Plain en_US on other Linux
> distributions indicates ISO-8859-1 as the default encoding  where
> en_US.UTF-8 would indicate UTF-8 as the default encoding.  ISO-8859-1
> can not represent Asian characters and log4cxx will substitute '?'
> for any character it can not represent in the current encoding.
> Seeing '?' in the output would be the expected (and desirable)
> behavior if the encoding is ISO-8859-1.
>
> What happens if you set the LANG environment variable to en_US.UTF-8
> before running the program?  What happens if you explicitly call
> setEncoding("UTF-8") on the appender?
>
>
>
>
>
>


--
Ken

Re: How to write Asian character to file?

[Curt Arnold <ca...@apache.org>]

On Mar 4, 2006, at 7:00 AM, Ken wrote:

> your word gave great help to me. I resolve the problem, call
> setEncoding("ISO-8859-1") and use literal with L, in log file can see
> the right result. It's my fault not log4cxx's.
> I am wondering why must call setEncoding("ISO-8859-1")? My LANG is
> already "en_US"?


ISO-8859-1 is incapable of representing Asian characters.  If setting  
ISO-8859-1 makes things work, it is only because the encoding  
expectations were messed up earlier.  It is most likely that:

a) your source file is encoded in UTF-8
b) you are not explicitly setting the encoding for gcc, it is  
assuming the en_US default of ISO-8859-1.

I'd suspect that if you were to use your Asian characters as part of  
a file name or output to the console using std::wcout, the characters  
would not be as you expected.

I think it is very likely that it is a problem on your end with the  
encoding during compilation.  However, if you are not able to resolve  
the problem, please log a JIRA issue (http://issues.apache.org/JIRA)  
and attach the source for a sample app and output to the issue using  
a .tar.gz or .zip.  Do not copy the source code into the message or  
in a email since that hides the encoding of the source file which is  
significant.  Attaching a tarball or zip file should also help  
preserve the encodings of the original files.



> Another question is for RollingFileAppender, in 0.9.7
> can keep many history files, but in 0.9.8 SVN code only 12 is allowed.
> I know rename many files not a good idea when rolling the file, but
> how about subfix 0 for the oldest file and subfix MAX for the newest
> file? currently is there any way to have history file more than 12?
>

The limit of 12 was ported over from log4j which has that limit.  The  
new RollingFileAppender design (introduced in the log4j 1.3 branch  
and ported to log4cxx) allows pluggable naming policies and I have  
considered adding one that uses incrementing suffixes and does not  
rename.