You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Sam <sa...@gmail.com> on 2006/04/27 00:17:22 UTC

UTF-8 Logging

I was wondering if there was a way to have an XML rolling file appender log
with a UTF-8 encoding.  Currently I am getting my systems default encoding
which is not going to work because my logs contain UTF-8 chars.  I don't see
any references to setting the log file encoding type.  Am I missing
something or is there a common workaround?

Thanks,
Sam.

Re: UTF-8 Logging

Posted by Dan Dragut <da...@gmail.com>.
Hi Sam,

A little bit offtopic, I believe that BBEdit is a text editor for
Macs, but if you are able to run Windows applications, I would suggest
to use TextPad (www.textpad.com) - it can handle UTF-8 log files
without the need for BOM marker, and also there is a syntax highlight
definition file for .log file.

Regards,
Dan

On 03/05/06, Sam <sa...@gmail.com> wrote:
> Thanks for the follow up. I did some more testing and using the property '
> log4j.appender.ErrorMonitor.Encoding=UTF-8' did work correctly. I was able
> to see UTF-8 chars in my logs.  The confusing bit is that the rolling file
> appender is outputting a file that does not have any bits specifying the
> character set.  So for example, when I open the file in BBEdit, it believes
> the file format and character encoding is DOS Mac OS Roman.
>
> To answer your other questions.
>
> >    - Does specifying the encoding work correctly for plain FileAppender
> > and is broken for RollingFileAppender?
>
> I have not tried.
>
> > What version of log4j are you using?
>
> log4j 1.2.8
>
> >  Does the behavior change when using the SVN trunk?
>
>
> I'll have to try. Thanks for the tip.
>
> Sam.
>
>
>
>
> Sam.
>
> On 4/30/06, Curt Arnold <ca...@apache.org> wrote:
> >
> >
> > On Apr 30, 2006, at 10:23 AM, duvelbier-tsmets@yahoo.com wrote:
> >
> > > The expected typography of UTF-8 might be "UTF8" instead...
> > >  At least, this is the expected value with some jasper report and
> > > for the -Dfile.encoding JVM switch
> > >  If I recall correctly :)
> > >
> > >  \T,
> > >
> >
> > According to http://java.sun.com/j2se/1.5.0/docs/api/java/nio/charset/
> > Charset.html, "UTF-8" a standard charset identifier.  There is no
> > guarantee that "UTF8" will be available.
> >
> >
> >
> > On Apr 26, 2006, at 5:33 PM, Sam wrote:
> > > I should mention I am trying to set the encoding with this
> > > property.  Having
> > > this property set does not seem to do anything.
> > > log4j.appender.ErrorMonitor.Encoding=UTF-8
> > >
> >
> > Couple of questions:
> >      Does specifying the encoding work correctly for plain
> > FileAppender and is broken for RollingFileAppender?
> >      What version of log4j are you using?
> >      Does the behavior change when using the SVN trunk?
> >
> > The SVN trunk contains a unit test (http://svn.apache.org/repos/asf/
> > logging/log4j/trunk/tests/src/java/org/apache/log4j/
> > EncodingTest.java) to check that the encoding specification is
> > correctly handled for some common states, so it shouldn't be totally
> > broken.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: UTF-8 Logging

Posted by paul womack <pw...@papermule.co.uk>.
Sam wrote:
> Thanks for the follow up. I did some more testing and using the property '
> log4j.appender.ErrorMonitor.Encoding=UTF-8' did work correctly. I was able
> to see UTF-8 chars in my logs.  The confusing bit is that the rolling file
> appender is outputting a file that does not have any bits specifying the
> character set.

Many encodings do not allow or specify "marker bits".
It is common for the encoding to be specified
via some other channel, including the ever
popular "you just have to know".

    BugBear

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: UTF-8 Logging

Posted by Sam <sa...@gmail.com>.
Thanks for the follow up. I did some more testing and using the property '
log4j.appender.ErrorMonitor.Encoding=UTF-8' did work correctly. I was able
to see UTF-8 chars in my logs.  The confusing bit is that the rolling file
appender is outputting a file that does not have any bits specifying the
character set.  So for example, when I open the file in BBEdit, it believes
the file format and character encoding is DOS Mac OS Roman.

To answer your other questions.

>    - Does specifying the encoding work correctly for plain FileAppender
> and is broken for RollingFileAppender?

I have not tried.

> What version of log4j are you using?

log4j 1.2.8

>  Does the behavior change when using the SVN trunk?


I'll have to try. Thanks for the tip.

Sam.




Sam.

On 4/30/06, Curt Arnold <ca...@apache.org> wrote:
>
>
> On Apr 30, 2006, at 10:23 AM, duvelbier-tsmets@yahoo.com wrote:
>
> > The expected typography of UTF-8 might be "UTF8" instead...
> >  At least, this is the expected value with some jasper report and
> > for the -Dfile.encoding JVM switch
> >  If I recall correctly :)
> >
> >  \T,
> >
>
> According to http://java.sun.com/j2se/1.5.0/docs/api/java/nio/charset/
> Charset.html, "UTF-8" a standard charset identifier.  There is no
> guarantee that "UTF8" will be available.
>
>
>
> On Apr 26, 2006, at 5:33 PM, Sam wrote:
> > I should mention I am trying to set the encoding with this
> > property.  Having
> > this property set does not seem to do anything.
> > log4j.appender.ErrorMonitor.Encoding=UTF-8
> >
>
> Couple of questions:
>      Does specifying the encoding work correctly for plain
> FileAppender and is broken for RollingFileAppender?
>      What version of log4j are you using?
>      Does the behavior change when using the SVN trunk?
>
> The SVN trunk contains a unit test (http://svn.apache.org/repos/asf/
> logging/log4j/trunk/tests/src/java/org/apache/log4j/
> EncodingTest.java) to check that the encoding specification is
> correctly handled for some common states, so it shouldn't be totally
> broken.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>

Re: UTF-8 Logging

Posted by Curt Arnold <ca...@apache.org>.
On Apr 30, 2006, at 10:23 AM, duvelbier-tsmets@yahoo.com wrote:

> The expected typography of UTF-8 might be "UTF8" instead...
>  At least, this is the expected value with some jasper report and  
> for the -Dfile.encoding JVM switch
>  If I recall correctly :)
>
>  \T,
>

According to http://java.sun.com/j2se/1.5.0/docs/api/java/nio/charset/ 
Charset.html, "UTF-8" a standard charset identifier.  There is no  
guarantee that "UTF8" will be available.



On Apr 26, 2006, at 5:33 PM, Sam wrote:
> I should mention I am trying to set the encoding with this  
> property.  Having
> this property set does not seem to do anything.
> log4j.appender.ErrorMonitor.Encoding=UTF-8
>

Couple of questions:
     Does specifying the encoding work correctly for plain  
FileAppender and is broken for RollingFileAppender?
     What version of log4j are you using?
     Does the behavior change when using the SVN trunk?

The SVN trunk contains a unit test (http://svn.apache.org/repos/asf/ 
logging/log4j/trunk/tests/src/java/org/apache/log4j/ 
EncodingTest.java) to check that the encoding specification is  
correctly handled for some common states, so it shouldn't be totally  
broken.



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: UTF-8 Logging

Posted by du...@yahoo.com.
The expected typography of UTF-8 might be "UTF8" instead...
 At least, this is the expected value with some jasper report and for the -Dfile.encoding JVM switch 
 If I recall correctly :)
 
 \T,
 
 
 
-- Any fool can write code that a computer can understand. 
Good programmers write code that humans can understand. 
Martin Fowler 
 
T. : +32 (0)2 742 05 94 
M. : +32 (0)497 44 68 12 
@ : duvelbier-tsmets@yahoo.com 
Do you skype too ... (callto://tsmets/) ?

----- Original Message ----
From: Sam <sa...@gmail.com>
To: log4j-user@logging.apache.org
Sent: Thursday, April 27, 2006 12:33:00 AM
Subject: Re: UTF-8 Logging

I should mention I am trying to set the encoding with this property.  Having
this property set does not seem to do anything.
log4j.appender.ErrorMonitor.Encoding=UTF-8

Sam.

On 4/26/06, Sam <sa...@gmail.com> wrote:
>
> I was wondering if there was a way to have an XML rolling file appender
> log with a UTF-8 encoding.  Currently I am getting my systems default
> encoding which is not going to work because my logs contain UTF-8 chars.  I
> don't see any references to setting the log file encoding type.  Am I
> missing something or is there a common workaround?
>
> Thanks,
> Sam.
>





---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: UTF-8 Logging

Posted by Sam <sa...@gmail.com>.
I should mention I am trying to set the encoding with this property.  Having
this property set does not seem to do anything.
log4j.appender.ErrorMonitor.Encoding=UTF-8

Sam.

On 4/26/06, Sam <sa...@gmail.com> wrote:
>
> I was wondering if there was a way to have an XML rolling file appender
> log with a UTF-8 encoding.  Currently I am getting my systems default
> encoding which is not going to work because my logs contain UTF-8 chars.  I
> don't see any references to setting the log file encoding type.  Am I
> missing something or is there a common workaround?
>
> Thanks,
> Sam.
>