UTF 8 + umlauts

hi!
i'm new in java and have to handle Germans Umlauts '��' as input params, but i don't really now how to get them into UTF 8- may anybody help me and post me some code?
and is it possible to filter '\n' out of in coming text?
thanks
michael

solution for Replacing String '\n' to Char '\10'
private String replaceNewLine(String Psmessage)
String Fs_message;
StringBuffer F_stringBuffer = new StringBuffer ();
int i = 0, j = 0;
int Fi_lengthOldNewLine = OLDPRAEFIX_NEWLINE.length();
while ( j > -1 )
j = Ps_message.indexOf( OLDPRAEFIX_NEWLINE, i );
if ( j > -1 )
F_stringBuffer.append( Ps_message.substring(i,j) );
F_stringBuffer.append( NEWLINE );
i = j + Fi_lengthOldNewLine;
F_stringBuffer.append( Ps_message.substring(i, Ps_message.length()) );
Fs_message = F_stringBuffer.toString();
return Fs_message;
}

Similar Messages

Howto set up proper utf-8 locales and german umlaute?

Hi there,
have some issues here and i think it has something to do with my locales... I have them since one of the last updates i think...
First problem:
In Kopete, i can send the german "umlaute" (ä, ö, ü) to others and they are sent and displayed correctly at their side... But when they send me these characters, i get only a square and a deleted next-letter-in-the-word by them. This happens with every theme and font combination in kopete. Here is an example:
Second problem:
In Konsole, the "umlaute" are correctly displayed on my folders, but in the messages i get the chars are simply deleted and not visible. This happens in the VC and in Xorg too. Here is another example:
(It should mean "Keine Handbuch Seite für pacman.conf")
My config:
I think i have configured my System properly, well at least i hope that Here are the relevant parts of my config files:
/etc/rc.conf:
LOCALE="de_DE.utf8"
KEYMAP="de"
CONSOLEFONT=
CONSOLEMAP=
/etc/profile:
export LANG="de_DE.utf8"
export LANGUAGE="de_DE.utf8"
/etc/locale.gen:
de_DE.UTF-8 UTF-8
en_US.UTF-8 UTF-8
And "locale -a" gives me:
C
POSIX
de_DE.utf8
en_US.utf8
The fonts I use:
KDE GUI: Bitstream Vera Sans (everywhere)
Y-Terminal (Konsole) Font: Bitstream Vera Sans mono
So, how can i configure a proper german utf-8? I have already searched the forums (both here and the DE one) and the wiki, but found no solution to this....
THX
Funkyou

Thx for the suggestions, but none of them seems to solve it...
baze:
This line was already uncommented and i have generated my locales for several times now... I have updated my post with the uncommented lines in /etc/locale.gen, just to collect all information...
Romashka:
Ok, but what if the two variables contain the same content? I mean, when i define LANG="de_DE.utf8" in /etc/profile and it is then overwritten by /etc/profile.d/lang.sh with LANG="de_DE.utf8", then this is simply the same variable defined twice with the same content... I have tried to unset the one in /etc/profile, but it did not solve it...
As for CONSOLEFONT, i had never one defined, can anyone suggest me a proper one? And the other question is: Its not working on the terminals, but it is also not working in Xorg, so is this really a CONSOLEFONT issue?
I have tried another thing and switched my locales to de_DE@euro ISO-8859-15, and with this setting the chars appear correctly... But i cannot be the only one where it does not work, i feel so excluded without UTF-8
Have also tried another terminal in Xorg... In XTerm the chars are not deleted like in Kopete or on the VC, but i see an inverted question mark instead of them...

HTTP Test Tool Umlaut (Special Character) Problem iso-8859-1 utf-8

Hi folks,
I habe a Problem in an HTTP to IDOC Scenario. The configuration works and when I test it, by using the Test Message Tool from the Runtime Workbench i get the following problem:
I post an IDOC XML Charset iso-8859-1 when it arrive as IDoc in business system german umlauts would be displayd very cryptic
ä = Ã¤
ü = Ã¼
and so on ....
When I post the XML with UTF-8 charset it works, what can i do to handle this ?
Thank you

Hi,
maybe this document is helpful:
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/502991a2-45d9-2910-d99f-8aba5d79fb42
and also this thread:
Character translation error in Mapping Lookup API (RFC)
Regards
Patrick

Umlauts are not displayed correctly in different programs

Hello!
I live in germany, but my locale is set to "en_US.UTF8" because I like to have everything in english.
I do not have any problems with umlauts on the machine, but when I connect with sFTP oder Samba to it, the umlauts in files are not displayed correctly.
Look at this example
The upper word is how it looks in "ssh putty" (=locally on the machine), the bottom one is from "filezilla" (from my windows host)
This is my locale
locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
When I create a file "asd_aöü" locally on the machine (with the help of ssh - putty), it looks fine, but when I connect by samba or filezilla again the umlauts are not displayed correctly.
Do you understand my problem? What can I do?
Thanks!
Last edited by cyberius (2011-02-19 10:12:19)

Did you check the locale settings on your Windows machine?

How do I supress the encoding of UTF-8 characters in a f:param element

Hello,
I have a keyboard displayed on my page, which won't work properly because of the used german characters.
I have an icon for every button embedded in a link, which adds the selected character to the searchstring.
For example adding an a works like this:
from keyboard.xhtml:
<s:link><f:param name="#{keyname}" value="#{keyword}a"/><h:graphicImage value="key_a.png"/></s:link>keyname and keyword are parameters submitted by the including form:
from myform.xhtml:
<ui:param name="keyword" value="#{end}"/>
<ui:param name="keyname" value="end"/>This works great as long as the character is a standard one, but on as soon as I have a german umlaut in the string, the umlaut gets encoded/escaped with every single character that i add to the searchstring:
The string makes it's way correctly to the keyboard-template, I can use a h:outputText to show it on the page and it doesn't get escaped.
So, how can I prevent the escaping of my characters in the f:params elements?
I really need to get this to work. so any hint or even solution would be fabulous.
Thanks in advance, Peter
PS: maybe my web server is doing something nasty, so it would be nice, if someone can check this code:
<s:link><f:param name="test" value="�"/>INIT</s:link> 
<s:link><f:param name="test" value="#{test}"/>REPEAT</s:link> 
INFO: <h:outputText value="#{test}" /> here is the same one with h:outputLink
<h:outputLink><f:param name="test" value="�"/>INIT</h:outputLink> 
<h:outputLink><f:param name="test" value="#{test}"/>REPEAT</h:outputLink> 
INFO: <h:outputText value="#{test}" /> EDIT: I found the solution, it was my beloved jboss application server, after adding a parameter to the server.xml, everything worked as expected:
use page settings:
<Connector port="8080" .....
useBodyEncodingForURI="true" ..../>hardcoded:
<Connector port="8080" .....
URIEncoding="UTF-8" ..../> Edited by: pete007 on Mar 12, 2008 1:47 PM

"Encoding" refers to the charset used to convert the Unicode data into bytes. But since you're writing to a String, you aren't converting the data to bytes and therefore UTF-16 is the appropriate encoding. It doesn't make sense to ask for your data to be encoded in UTF-8 when you aren't producing bytes.
You could read this tutorial about XML and Unicode and encodings for more information:
http://skew.org/xml/tutorial/

Numbers don't show german umlaut but quick view does

I do have a problem opening CSV files in Numbers.
I have a shared folder with VirtualBox. The virtual HD is formatted in FAT32. With Windows I created a CSV file which contains german umlauts like ÄÖÜ.
When I open the CSV with the "quick view" (press space when file is selected in finder, the CSV is displayed as a nice Table and all Umlauts are OK.
When I double click the CSV file to open it in Numbers, the Umlauts are not displayed. Opening in Text Edit is the same result, no Umlauts.
ö = ^
ß = fl
ü = ¸
ä = ‰
I think this is an encoding problem, but why is "quick view" displaying it correct. I'm confused.
Thanks for any help.

Hello
I cannot find any encoding settings for opening files in Numbers 09.
A simple and obvious solution would be to save CSV file in UTF-8 in FAT32 volume in VirtualBox if possible.
One other method is to copy the CSV file to HFS+ volume and set its extended attributes to specify its text encoding. This method is only changing the metadata of the file and so is less intrusive than to convert the data itself to different text encoding. When text encoding extended attribute is properly set, Numbers 09 (and TextEdit.app set to use "Automatic" encoding option in opening files) will open it in the specified text encoding.
The following AppleScript script might help to set the extended attributes (OSX 10.5 or later only). Recipe is as follows.
A1) Open /Applications/Utilities/AppleScript Editor.app, copy the code of set_latin1_xattr.applescript listed below and save it as application (bundle) in the folder where target CSV files reside.
A2) Double click the saved applet and it will set the com.apple.TextEncoding extended attribute of the *.csv and *.txt files in the same folder where the applet resides to Latin 1 when they are recognised as 'ISO-8859 text' by file(1) command.
-- set_latin1_xattr.applescript
_main()
on _main()
    set p2m to (path to me)'s POSIX path
    if p2m ends with "/" then set p2m to p2m's text 1 thru -2
    set sh to "
# set current directory to parent directory of script (or die)
cd \"${0%/*}\" || exit 1
# add com.apple.TextEnncoding xattr for Latin-1
# for *.csv and *.txt files, of which file info contains 'ISO-8859 text', in current directory
for f in *.{csv,txt}
do
    if [[ $(file \"$f\") =~ 'ISO-8859 text' ]]
    then
        xattr -w com.apple.TextEncoding \"WINDOWS-1252;$((0x0500))\" \"$f\"
    fi
done
    do shell script "/bin/bash -c " & sh's quoted form & " " & p2m's quoted form
end _main
Another method is to convert the text encoding itself as you have already done using TextEdit.app.
The following AppleScript might help to convert text encoding from latin-1 to utf-8 in bulk. Recipe is basically the same as the above.
B1) Open /Applications/Utilities/AppleScript Editor.app, copy the code of convert_latin1_to_utf8.applescript listed below and save it as application (bundle) in the folder where target CSV files reside.
B2) Double click the saved applet and it will convert the text encoding of the *.csv and *.txt files in the same folder where the applet resides to UTF-8 when they are recognised as 'ISO-8859 text' by file(1) command. Also it sets the extended attribute for text encoding accordingly.
-- convert_latin1_to_utf8.applescript
_main()
on _main()
    set p2m to (path to me)'s POSIX path
    if p2m ends with "/" then set p2m to p2m's text 1 thru -2
    set sh to "
# set current directory to parent directory of script (or die)
cd \"${0%/*}\" || exit 1
# make temporary directory
temp=$(mktemp -d /tmp/\"${0##*/}\".XXXXXX) || exit 1
# convert text encoding from ISO-8859-1 to UTF-8
# for *.csv and *.txt files, of which file info contains 'ISO-8859 text', in current directory
for f in *.{csv,txt}
do
    if [[ $(file \"$f\") =~ 'ISO-8859 text' ]]
    then
        iconv -f ISO-8859-1 -t UTF-8 \"$f\" > \"$temp/$f\" \\
        && xattr -w com.apple.TextEncoding \"UTF-8;$((0x08000100))\" \"$temp/$f\" \\
        && mv -f \"$temp/$f\" \"$f\"
    fi
done
# clean up temporary directory
rm -rf \"$temp\"
    do shell script "/bin/bash -c " & sh's quoted form & " " & p2m's quoted form
end _main
Note that the extended attribute is not supported in FAT32 and so the above methods only work in HFS+ formatted volume.
Scripts are briefly tested with Numbers 2.0.5 under OSX 10.5.8 and 10.6.5. Please make sure you have backup CSV files before applying the above scripts.
Good luck,
H

HTTP adapter - change encoding from UTF-8 to ISO-8859-1

Hi,
I am trying to change the encoding used by the HTTP sender adapter in a scenario.
However, when I enter ISO-8859-1 in the XML Code under XI Payload Manipulation on the comms channel it has no effect - the paylad still shows as UTF-8 in SXI_MONITOR.
Am I missing a step or entering the field incorrectly ??
Thanks
Colin.

Hi,
From help
Enhancing the Payload
Some external systems, for example, Web servers in marketplaces, can only process data if it is sent as an HTML form using HTTP.
A typical HTML form comprises named fields. When transferring a completed form to the server or a CGI program, the data must be transferred in such a way that the CGI script can recognize the fields that make up the form, and which data was entered in which field.
The plain HTTP adapter constructs this format using a prolog and an epilog. Therefore, there is a particular code method that separates form fields and their data from each other. This code method uses the following rules:
     Individual form elements, including their data, are separated from each other by the character &.
     The name and data of a form element are separated from each other by an equals sign (=).
     Blanks in the entered data (for example, in multiple words) are replaced by a plus sign (+).
    All characters with the (enhanced) ASCII values 128 to 255 (hexadecimal 80 to FF) are transcribed using a hexadecimal sequence, beginning with a percentage sign (%) followed by the hexadecimal value of the character (for example, the German umlaut ö in the character set ISO-8859-1 is transcribed as %F6).
   All characters that occur in these rules as control characters (&, +, =, and %) are also transcribed hexadecimally in the same way as high value ASCII characters
http://help.sap.com/saphelp_nw2004s/helpdata/en/44/79973cc73af456e10000000a114084/content.htm
Regards
Chilla

Certain characters such as "-" in UTF-8 are not displayed correctly in file

Hi,
Has anyone else seen a similar scenario?
There are certain characters entered in the R/3 system (UTF-8) such as a and ("), which looks different then the normal dash or quotation, in a free form text field. The values of these fields are transferred through XI via abap proxy and written to a mainframe file via the file adapter. The default file encoding of our XI system is ISO-8859-1. When the file is created these characters are interpreted as a (?). When we change the encoding to UTF-8 in the receiver adapter, it translates the characters as (b.). When I write the file out to the file system with encoding UTF-8, everything looks normal.
Can anyone shed some light on this situation?
Thanks.
Best Regards,
Duke

Hi Stefan,
To clarify, the (") the user is entering are curly quotes. I found this on google.
Windows ANSI (224 characters; since Win3.1). This adds the accented characters common in Western European languages (including vowels with acute, grave, circumflex and umlaut accents), plus some other typographical symbols like u201Ccurly quotesu201D, bullets, currency symbols etc. The additional 126 characters above the ASCII set are called u201CUpper ANSIu201D.
This is a flat file using content conversion on the receiver file adapter. In SXMB_MONI it looks correct. If I do a view source, I can see that the quotations are the "curly quotes" and not the same as when I enter the character.
Best Regards,
Duke

Encoding problem (Umlaute) in HTTP-Headers

Hi!
I have a servlet that is being called by another server via a POST request.
The request contains user data in HTTP-headers, and whenever there is a
German Umlaut in the user's name, it ends up garbled. :(
The requests character encoding is set to 'ISO-8859-1', according to the servlet
requests getCharacterEncoding() method.
I try to copy the value of a header variable into a String like this:
headerNameValue = request.getHeader("headerNameKey");Which, unfortunatly, doesn't work. For example, the value "G�nter" becomes "G��nter".
Shouldn't the API take care of the encoding, when the CharacterEncoding is set
right in the servlet call?
It looks like it interprets the ISO88591 data as Unicode?
BTW, I'm on a WebSphere 5 server, with Java 1.4.
I've been tearing my hair out on this one for days, so any help is highly appreciated.
Thanks a lot!
Andreas

A header variable with the key 'accept-charset' is not sent.
Only 'accept-encoding', with the value 'gzip, deflate'.
Like I wrote in my first post, the servlet request's character encoding is set to ISO-8859-1,
according to the getCharacterEncoding-method.
I have kind of solved this for now by converting the String 2times back, like this:
try {
     headerNameValue = new String((new String(headerNameValue.getBytes(),"UTF-8")).getBytes(),"UTF-8");
} catch (UnsupportedEncodingException e) {
      logger.error("Fehler beim Umwandeln der Umlaute im Benutzernamen.",e);
}                    }This code converts the '��', that my servlet receives, back to '�'.
(The first conversion changes the '��' to '��', the second the remaining '��' to '�').
While this seems to work, I don't think it is the right solution, and I still don't understand what's going on. :)
Regards,
Andreas

German umlauts :Sender File Adapter

Hi,
I am trying to configure Sender File adapter,but it is not working properly for German umlauts.
I have tried encoding UTF-8, UTF-16, ISO-8859-1,ISO-8859-2, ISO-8859-5 but none of them are working.
Can anyone please help me out in this.
Thanks a lot.
Regards,
Shweta

Hi Stefan,
I have already added this module exactly in the same way.
But can you please confirm the sequence
Module :
localejbs/AF_Modules/PayloadSwapBean                     Local Enterprise Bean     swap
localejbs/AF_Modules/MessageTransformBean     Local Enterprise Bean     Transform
localejbs/AF_Modules/MessageTransformBean     Local Enterprise Bean     Transform
Transform.ContentType                     text/plain;charset="UTF-8"
Transform.ContentDisposition            attachment;filename="ABC.csv"
Also,I noticed one thing
The content is corrupted in SXI_MONITOR but it is correct in payload of File as well as Mail adapter in Message Monitor(RWB)
Thanks.
Regards,
Shweta

Umlaut Conversion issue in Sender communication channel SAP PI

Hi Gurus,
We are facing issue while conversion.
umlaut Conversion issue in Sender communication channel that is reason channel not able to pic the file from the path.
Sender CC error:
Value of incoming field is too large. Segment:'IMD', Field:'7008', MaxLength:'35', value:'Plssvvkbecher LÃ¼bzer 0,4 (1280Stk p' DESCRIPTION: The length of the field value is too big !
Actually field contains 35 Chars only the value is : 'Plssvvkbecher Lübzer 0,4 (1280Stk p'
We tried with “ISO-8859-1” if the field value is less than 35 characters it is able to converting.
Please help me out from this issue.
Thank you.
Regards,
Jittu.

Hi Jittu,
Have you tried using the codepageconversion bean in the modules under the sender? It would be like:
AF_Modules/TextCodepageConversionBean with a parameter of Conversion.charset and a value of utf-8.
Regards,
Ryan Crosby

German Umlauts OK in Test Environment, Question Marks (??) in production

Hi Sun Forums,
I have a simple Java application that uses JFrame for a window, a JTextArea for console output. While running my application in test mode (that is, run locally within Eclipse development environment) the software properly handles all German Umlauts in the JTextArea (also using Log4J to write the same output to file-- that too is OK). In fact, the application is flawless from this perspective.
However, when I deploy the application to multiple environments, the Umlauts are displayed as ??. Deployment is destined for Mac OS X (10.4/10.5) and Windows-based computers. (XP, Vista) with a requirement of Java 1.5 at the minimum.
On the test computer (Mac OS X 10.5), the test environment is OK, but running the application as a runnable jar, german umlauts become question marks ??. I use Jar Bundler on Mac to produce an application object, and Launch4J to build a Windows executables.
I am setting the default encoding to UTF-8 at the start of my app. Other international characters treated OK after deployment (e, a with accents). It seems to be localized to german umlaut type characters where the app fails.
I have encoded my source files as UTF-8 in Eclipse. I am having a hard time understanding what the root cause is. I suspect it is the default encoding on the computer the software is running on. If this is true, then how do I force the application to honor german umlauts?
Thanks very much,
Ryan Allaby
RA-CC.COM
J2EE/Java Developer
Edited by: RyanAllaby on Jul 10, 2009 2:50 PM

So you start with a string called "input"; where did that come from? As far as we know, it could already have been corrupted. ByteBuffer inputBuffer = ByteBuffer.wrap( input.getBytes() ); Here you convert the string to to a byte array using the default encoding. You say you've set the default to UTF-8, but how do you know it worked on the customer's machine? When we advise you not to rely on the default encoding, we don't mean you should override that system property, we mean you should always specify the encoding in your code. There's a getBytes() method that lets you do that.
CharBuffer data = utf8charset.decode( inputBuffer ); Now you decode the byte[] that you think is UTF-8, as UTF-8. If getBytes() did in fact encode the string as UTF-8, this is a wash; you just wasted a lot of time and ended up with the exact same string you started with. On the other hand, if getBytes() used something other than UTF-8, you've just created a load of garbage. ByteBuffer outputBuffer = iso88591charset.encode( data );Next you create yet another byte array, this time using the ISO-8859-1 encoding. If the string was valid to begin with, and the previous steps didn't corrupt it, there could be characters in it that can't be encoded in ISO-8859-1. Those characters will be lost.
byte[] outputData = outputBuffer.array();
return new String( outputData ); Finally, you decode the byte[] once more, this time using the default encoding. As with getBytes(), there's a String constructor that lets you specify the encoding, but it doesn't really matter. For the previous steps to have worked, the default had to be UTF-8. That means you have a byte[] that's encoded as ISO-8859-1 and you're decoding it as UTF-8. What's wrong with this picture?
This whole sequence makes no sense anyway; at best, it's a huge waste of clock cycles. It looks like you're trying to change the encoding of the string, which is impossible. No matter what platform it runs on, Java always uses the same encoding for strings. That encoding is UTF-16, but you don't really need to know that. You should only have to deal with character encodings when your app communicates with something outside itself, like a network or a file system.
What's the real problem you're trying to solve?

TextEdit doesn't display UTF-8 characters corrrectly

I have a plain text file with some German umlauts, encoded in UTF-8. When I select this file in the Finder, the umlauts are displayed correctly in the Preview. However, if I double click on that file to have it loaded into the TextEdit program, the umlauts are displayed incorrectly.
The screenshot at ftp://ftp.cadsoft.de/pub/etc/mac-osx-utf-8-bug.png shows the Finder's window in the background, and the TextEdit window in the foreground.
When I explicitly load the file into the TextEdit program, with "Plain Text Encoding" set to "Unicode (UTF-8)" the text is displayed correctly. Only with "Automatic" it doesn't work.
Am I doing something wrong here, or is this an actual bug in TextEdit?
Franz
Mac mini Mac OS X (10.4.6)

Well, the "Notepad" editor on Windows XP does it
correctly with both UTF-8 and ISO8859-1 umlauts.
I think Notepad identifies UTF-8 correctly because Windows (unlike other OS's) puts a BOM at the start of UTF-8 files. Normally you only see this at the start of UTF-16 files, which many text editors can identify correctly.
However, if the Mac user clicks on our German
README text file and has "Plain text file encoding"
set to "Automatic" (which apparently is the default),
he sees broken umlauts.
Yes I think Automatic means MacRoman. One possible solution is to use either rtf or html for the readme. I think the encoding for these will be recognized correctly. You could also try putting a BOM at the start of your UTF-8 plain text file.
I was unter the impression that "UTF-8" was the
plain text format on the Mac
No, OS X stores data internally as UTF-16. Anything using xml will be UTF-8, and that's now the default encoding in Mail for lots non-Roman scripts, but otherwise the other encodings seem to have pretty equal status.

Mail Adapter - PayloadSwapBean - MessageTransformBean - German umlauts

Hi there,
I'm receiving mails with an attachment (.csv / .txt) that I want to process to get IDocs. Everything works fine but the conversion of German umlauts. I tried to apply several charsets (i.e. iso-8859-1, iso-8859-2, utf-8) in the contentType parameter without success. The result in my payload after swapping and transforming is a message without umlauts. All these characters have been replaced by the same 'character' that looks like a quadrangle. Therefore even the earliest possible mapping comes too late to convert this character back into umlauts, because I don't know anymore the original ones.
When I process the same attachment with a file adapter in the same manner (until getting an IDoc) there are no problems with umlauts, the payload looks fine!
I even checked the note 881308 (although it's said to be for the mail receiver) but it's already in the system (XI 3.0, SP 14)
Anyone an idea to solve my problem?
Regards,
Ralph

Hi Ralph,
now I got the solution:
Allpy the MessageTransformBean twice.
First you set the code page for the mail attachment, how it comes to the system.
Then you do the conversion and set the code page how the target xml should be.
Make two entries in Module configuration:
localejbs/AF_Modules/MessageTransformBean - contenttype
localejbs/AF_Modules/MessageTransformBean - tranform
as paramters you set:
contentType - Transform.ContentType - text/plain; charset=iso-8859-1
transform - Transform.ContentType - text/xml; charset=UTF-8
transform - Transform.Class - com.sap.aii.messaging.adapter.Conversion
and so on.
The problem is that outlook does not provide the content type for the attachment, so the MailTransformBean assumes UTF-8, but the attachment has iso-8859-1, so you have to set this before the conversion.
I have tested this with XI 3.0 SP17 with note 960501 included.
Regards
Stefan

Wrong email display name with german umlauts (MS Exchange 2003)

We use 6 iPhones with Exchange 2003 and get wrong email display names with german umlauts (ä,ü,ö) - but the email-body is right.
We get special characters instead of umlauts, so the display name split into pieces. Anwering is not posipble - we get a failure-message.
We changed the standard-internet-mailformat on the exchange-server to unicode utf-8. First it works fine, after a few hours the names displays wrong again.
So we use this hotfix:
http://support.microsoft.com/?scid=kb%3Ben-us%3B916299&x=11&y=13
Same result: First it works fine, after a few hours the names displays wrong again at the iPhone.
Any ideas?

Do you have commas in the display name? We used to have "Müller, Thomas" <[email protected]> and then got the split up and special characters you mention. Tests have shown that when leaving out the comma in the display name, e.g. "Thomas Müller" <[email protected]>, everything worked fine.
Guess it's a question of whether a company wants to change its naming convention for a few iPhone users...
HCD

UTF 8 + umlauts

Similar Messages

Maybe you are looking for