Re: UTF-8 Logging

[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

[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

[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