You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-user@logging.apache.org by Jo...@kisters.de on 2008/04/10 15:26:31 UTC

Problems with log4net Rolling File Appender

Hello!
We use log4net in a linux environment (OpenSuSE 10.2) with Mono.
We utilize a RollingFileAppender which appearantly puts 3 or so Bytes (Hex 
Values: EF BB BF) in Front of each file. These characters interfere with 
our Software processing these logfiles. Under .NET we don't have this 
problem. Question now is if this is a known Problem which has a fix or if 
we have to modify our processing software to ignore these specific bytes

Mit freundlichen Grüßen / Regards
Johannes Frank

RE: Problems with log4net Rolling File Appender

Posted by Eric Chamberlain <ec...@ventripoint.com>.
One clarification here would seem to be in order.   UTF-8 is a
variable-length encoding.   The length of any given code point will be
between 1 and 4 bytes long.   UTF-8 is a byte stream and so there really is
no byte ordering (unlike UTF-16).  Hence, the BOM is pretty useless for
UTF-8.

For grubby details, see http://en.wikipedia.org/wiki/UTF-8.

Eric Chamberlain
Software Engineer
 
-----Original Message-----
From: Dag Christensen [mailto:Dag.Christensen@vismaretail.no] 
Sent: Wednesday, April 16, 2008 12:25 AM
To: Log4NET User
Subject: RE: Problems with log4net Rolling File Appender

>Is there a workaround for that? I mean this can't be intended behaviour 
>:) But as I interpret your answer, this has most likely something to do
with the Mono Framework, not with log4net, right?
>
>Mit freundlichen Grüßen / Regards
>Johannes Frank

Not sure if this behavior is intended or not, but there's an Encoding
attribute on the (Rolling)FileAppenders which is set to Encoding.Default
unless you override it. Perhaps your Mono build gave an early warning for a
bug you'll encounter later on other systems? Below the hood,
RollingFileAppender uses StreamWriter(stream, encoding) where stream is a
FileStream so you might want to experiment with this class a bit.

With UTF-8, non-ASCII/international characters are encoded with two bytes.
IMHO you should be prepared to handle BOM/byte order mark if you intend to
work with this encoding because of its 8/16 bit duality. If your parser
believes your UTF-8 encoded file contains only ASCII these international
characters won't be preserved.

When I have problems with UTF-8, I usually turn to ISO 8859 instead. In this
encoding, ASCII is preserved for the low 7 bits while regional characters
are mapped to the remaining bytes. For example, here in Norway we use ISO
8859-1 (Latin 1 - Western Europe). See http://en.wikipedia.org/wiki/ISO_8859
for more information.

Best wishes,

Dag

###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.f-secure.com/


RE: Problems with log4net Rolling File Appender

Posted by Dag Christensen <Da...@vismaretail.no>.
>Is there a workaround for that? I mean this can't be intended behaviour 
>:) But as I interpret your answer, this has most likely something to do with the Mono Framework, not with log4net, right?
>
>Mit freundlichen Grüßen / Regards
>Johannes Frank

Not sure if this behavior is intended or not, but there's an Encoding attribute on the (Rolling)FileAppenders which is set to Encoding.Default unless you override it. Perhaps your Mono build gave an early warning for a bug you'll encounter later on other systems? Below the hood, RollingFileAppender uses StreamWriter(stream, encoding) where stream is a FileStream so you might want to experiment with this class a bit.

With UTF-8, non-ASCII/international characters are encoded with two bytes. IMHO you should be prepared to handle BOM/byte order mark if you intend to work with this encoding because of its 8/16 bit duality. If your parser believes your UTF-8 encoded file contains only ASCII these international characters won't be preserved.

When I have problems with UTF-8, I usually turn to ISO 8859 instead. In this encoding, ASCII is preserved for the low 7 bits while regional characters are mapped to the remaining bytes. For example, here in Norway we use ISO 8859-1 (Latin 1 - Western Europe). See http://en.wikipedia.org/wiki/ISO_8859 for more information.

Best wishes,

Dag

###########################################

This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.f-secure.com/

RE: Problems with log4net Rolling File Appender

Posted by Jo...@kisters.de.
Is there a workaround for that? I mean this can't be intended behaviour :)
But as I interpret your answer, this has most likely something to do with 
the Mono Framework, not with log4net, right?

Mit freundlichen Grüßen / Regards
Johannes Frank




"Eric Chamberlain" <ec...@ventripoint.com> 
10.04.2008 17:03
Please respond to
"Log4NET User" <lo...@logging.apache.org>


To
"'Log4NET User'" <lo...@logging.apache.org>
cc

Subject
RE: Problems with log4net Rolling File Appender






The bytes are the UTF-8 byte order mark (see 
http://en.wikipedia.org/wiki/Byte-order_mark).   I do not know why they 
are getting added, however?
 
 == Eric Chamberlain ==
 

From: Johannes.Frank@kisters.de [mailto:Johannes.Frank@kisters.de] 
Sent: Thursday, April 10, 2008 6:27 AM
To: log4net-user@logging.apache.org
Subject: Problems with log4net Rolling File Appender
 

Hello! 
We use log4net in a linux environment (OpenSuSE 10.2) with Mono. 
We utilize a RollingFileAppender which appearantly puts 3 or so Bytes (Hex 
Values: EF BB BF) in Front of each file. These characters interfere with 
our Software processing these logfiles. Under .NET we don't have this 
problem. Question now is if this is a known Problem which has a fix or if 
we have to modify our processing software to ignore these specific bytes 

Mit freundlichen Grüßen / Regards
Johannes Frank

RE: Problems with log4net Rolling File Appender

Posted by Eric Chamberlain <ec...@ventripoint.com>.
The bytes are the UTF-8 byte order mark (see
http://en.wikipedia.org/wiki/Byte-order_mark).   I do not know why they are
getting added, however…

 

 == Eric Chamberlain ==

 

  _____  

From: Johannes.Frank@kisters.de [mailto:Johannes.Frank@kisters.de] 
Sent: Thursday, April 10, 2008 6:27 AM
To: log4net-user@logging.apache.org
Subject: Problems with log4net Rolling File Appender

 


Hello! 
We use log4net in a linux environment (OpenSuSE 10.2) with Mono. 
We utilize a RollingFileAppender which appearantly puts 3 or so Bytes (Hex
Values: EF BB BF) in Front of each file. These characters interfere with our
Software processing these logfiles. Under .NET we don't have this problem.
Question now is if this is a known Problem which has a fix or if we have to
modify our processing software to ignore these specific bytes 

Mit freundlichen Grüßen / Regards
Johannes Frank