Hello Curt, Thanks for the info and tips. I can live with the \u representation for the moment, when I know that there will be readable output in the future.
But I have another small question: I am currently replacing in an application std::string with std::wstring Before it was possible to log in streams, but with wstrings its not possible at the moment. works: LOG4CXX_DEBUG(loggerPtr_, "hello" << someString << 5 ); works not: LOG4CXX_DEBUG(loggerPtr_, L"hello" << someWtring << 5 ); Is this planned or do I have to use other ways to log things like this? Best regards ML CA> That is the intent behind the Unicode rework, but not everything is CA> fleshed out. The "\u4ECA" construct is generated by CA> Transcoder::encode(const LogString& src, std::string& dst) when a CA> character in src cannot be represented in the current code page. CA> On Feb 1, 2005, at 4:44 AM, LECHNER Martin wrote: CA> That is the intent behind the Unicode rework, but not everything is CA> fleshed out. The "\u4ECA" construct is generated by CA> Transcoder::encode(const LogString& src, std::string& dst) when a CA> character in src cannot be represented in the current code page. CA> In the case of the text file, you will get that form unless you specify CA> an encoding that can represent the character (UTF-16 or UTF-8) using CA> WriterAppender::setEncoding (or the equivalent configuration entry). CA> However, support for arbitrary encodings hasn't been completed. I CA> expect to implement it using APR-iconv shortly. CA> I can probably fix the XML faster. Even though you could encode those CA> characters as UTF-8 (since all XML processors are required to support CA> UTF-8), it is probably preferable to represent non-USASCII characters CA> as character entities (for example, &x4ECA;) since it would not be CA> uncommon for users to try to open up a log file in a non-XML aware text CA> editor or use a command line tool like cat. -- Best regards, Martin mailto:[EMAIL PROTECTED]
