Exchange 2003 Server Carriage Return Problem

[Aykut Guven]

Hello,

We are using MS Exchange 2003 as email server and SD 4.5 SP4. There is a problem inbound SC. When someone sends an email to open a call carriage returns are viewed as pipe sign "|" instead of creating a new line in the description field.

Have you faced with this problem before?

Thanks.

[Rune J. Winje]

Without knowing SD (ServiceDesk) or the solution I can only make a general observation.

When characters (carriage return is also a caracter combination) are converted to something else this is often caused by language settings which are different on the client and server(s). E.g. if the client and server both have "Regional Setting"=English there are seldom any problems.

For Exchange look into:
Frequently asked questions about MIME and content conversion in Exchange 2000 Server and in Exchange Server 2003
http://support.microsoft.com/default.aspx?scid=kb;en-us;836555


To guarantee against conversion when client and server settings do not match one needs to use Unicode text. Unicode is a unified character table big enough to hold most special characters in the world. The programmer however needs to use nchar instead of char, nvarchar instead of varchar and ntext instead of text to keep text as unicode. Microsoft SQL since version 6.5 and presumably Exchange's storage engine support Unicode.

Unicode text in SQL is stored in UCS-2 format (double-byte format) Most web-pages however use a shortened format where the first characters are single byte and characters further up in the Unicode table have 2 or 3 bytes. This is called UTF-8 format, so here is another place where the programmer has to take care to convert between UCS2 and UTF-8 if displaying database results on the web.

The overhead (double byte compared to single byte) in processing and storing unicode is the main reason why Unicode has not gained more acceptance compared to the myriad of 8-bit and 7-bit character sets out there.

Legal demands that governments support minority languages (with special characters) are however beginning to fuel end-to-end Unicode solutions into existence.


Cheers,
Rune

[Aykut Guven]

I think I must have a look at closer to the problem.

Thanks.