German umlauts / unicode in JNLP-File

Hi,
in the <description kind="short">-tag of a JNLP-file I want to use a German umlaut. If I write it as the single character, WebStart cannot load the application, in the error-message the JNLP-File is show up to this character - so it breaks at this point.
I tried to use unicode \u00fd and the html-entity ü instead but this is not a solution because this strings are writen as plain text to the gui.
Does anyone know a solution? Or should I post it as bugreport?
Thanks for answers.
Jens

Hi Jens:
I had the same problem while trying to use French accented characters, and I think it looks quite like a bug in the XML/JNLP parser. I thus suggest to submit a bug report.
Best regards,
Jean-Fran�ois Morin

Similar Messages

German umlaut in idoc to file scenario

Hi,
in our scenario we send MATMAS idocs to XI, map them and create a file using file adapter.
Settings in file receiver communication channel: file type = text and file encoding = UTF8. I also tried file encoding = ISO-8859-1 - both with the same result:
German umlauts are not converted. E.g. the material short text "Hängematte" is shown as "Hängematte" in the created file. The receiving system errors out. Acceptable would be
"H& #228;ngematte". (of course without the blank but I have to add it herer else the forum would replace this by "ä" )Any help is appreciated.
Regards,
Philipp

Hi,
Follow the steps:-
1>In your adapter -> Set File type to TEXT -> use Encoding and provide ISO-8859-1 (http://en.wikipedia.org/wiki/ISO/IEC_8859-1)
To know more about other encoding standards refer -
http://en.wikipedia.org/wiki/Character_encoding
2>file type==>binary
Regards,
AshwinM
Reward If helpful

Problem copying German Umlauts

Hello every one,
I have a problem copying the German Umlauts (ü,ö,ä) from a pdf file. When I simply copy the text from the pdf file to paste in a text document, they come out like this: ¨u, ¨a, ¨o
Please help me resolve this issue.
Cheers,
makky

Hi,
I have the same Problem.
I´m using Adobe Reader X (10.1.3) with OS X Lion.
If I copy a text with German Umlauts into a HTML-Editor the German 'ü' is diplayed obviously ok and the browser shows it correctly too, but when I move the cursor through the text the German ü are two overlapping letter. Normally it should be one letter, namely the same as entering an ü. (Yes, the charset of my HTML-file is UTF-8 and the file is saved in UTF-8). The first of the two overlapping letters is a "normal" 'u' and the second is the 'COMBINING DIAERESIS' (U+0308) (http://www.fileformat.info/info/unicode/char/308/index.htm).
Before I switched to OS X I used Adobe Reader with Windows 7 and I never had this problem. Strangely the problem only appears with 'ü's. 'Ä's and 'Ö's are copied correctly...
Right now, I suppose there is a bug/feature/whatever in Adobe Reader X using OS X....
Did you find a solution meanwhile?
Torsten

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

Character encoding problem with german umlaut in propertie files

Hi,
I use propertie files to translate application to multiple languages.
These files contains german umlaut (e.g.: Wareneingänge).
If I rebuild my application then this files are copied from ../src/view to ../classes/view.
The file in ../classes/view contains "Wareneing\ufffdnge" instead of "Wareneingänge" which is displayed as "Wareneing�nge".
My browser-, project- and application settings are UTF8.
Previously the settings for project and application where "Windows-1252"
I have found an workarounds but maybe this is a bug in Jdeveloper TP4.
Therefore I post this problem. Maybe someone can confirm this behaviour.
Workaround:
Replace "Wareneingänge" with "Wareneing\u00e4nge" in the ../src/view file
(Zaval JRC Editior does this for you :-) )
regards
Peter

Hi,
I think to remember that the same was required for properties in 10.1.3 as well. Not sure if this is an issue in JDeveloper 11. I'll take anot and have a look though
Frank

German umlaute and file download

hi to all!
hope someone can help me.
I have a directory, let's say test, with a WEB-INF directory in it. ordinarry web-app...
within "test" there is a file called gl�hw�rmchen.pdf. I want to download this file. when i use a link
Gl�hw�rmchen a 404 STATUS CODE is returned. Tomcat 4.1.18 doesn't find the resource but it is DEFINITELY in there.
I know that this is no bug, i just don't understand somethig. How can i tell Tomcat 4.1.18 to return files with german umlaute???
please help...
ciaou,
wendigo

sorry that's not the solution of the problem. I have prooved that my file is in the correct directory. It's NOT a context path problem. Other files are downloaded.....
test.txt
gl�hw�rmchen.pdf
gluehwuermchen.pdf
The JSP Source Code.....
<%@page contentType="text/html;charset=ISO-8859-1"%>
<html>
<head><title>JSP Page</title></head>
<body>
Textdatei
Gluehwuermchen.pdf Datei
Gl�hw�rmchen.pdf Datei
</body>
</html>
when I click the first or second a link, the files are transmitted, but the third file NOT.... The filename is written correctly. The Apache Tomcat 4.1.18 just doesn't find the file. REMEMBER!!! The Webserver FINDS the two other files in THE SAME DIRECTORY BUT NOT THOSE containing german umlaute. WHY????
hope you can help me...
wendigo

German umlauts not supported in CSV file export of campaigns

Hi all,
I just customized and tested exporting business partner data out of a marketing campaign to a CSV file. I created a mail form and made the appropriate customizing settings in SPRO.
All worked fine, but when opening this file with MS EXCEL, german umlauts (ä, ö, ü, ß) cannot be depicted correctly.
I figured out so far, that my file in encoded in UTF-8.
Does anybody know if there are some settings to be made in SAP and/or Excel to solve the problem with the umlauts?
Any help is appreciated!
Thanks a lot.
Best regards
Wolfgang

Hi Wolfgang,
I had the same problem as well. This is the solution suggested by SAP Support:
Unfortunately this is a problem with Microsoft Excel. It is not able to
handle the UTF-8 format file directly. Please try the following steps
and check whether the data is displayed correctly -
1) Download the file to your local system
2) Open a worksheet in Excel
3) choose 'Data->Import External Data -> Import Data' from the menu
4) Then select the file and import it.
Please remember to set the encoding of the file as UTF8
Regards, stephan

Desktop.open() fails when file contains German umlauts

Hello,
I want to open a file using the Desktop-API:
// check whether opening a file is supported or not
if (!desk.isSupported(Desktop.Action.OPEN)) {
// display error message box
JOptionPane.showMessageDialog(getFrame(),getResourceMap().getString("errLinkUnsopportedMsg"),
         getResourceMap().getString("errLinkUnsopportedTitle"),JOptionPane.ERROR_MESSAGE);
return;
desk.open(linkfile);I'm catching all possible exceptions here:
             catch (IOException e)
            catch (IllegalArgumentException e)
            catch (SecurityException e)
            catch (UnsupportedOperationException e)
            catch (URISyntaxException e)But when I want to open a file that contains German umlauts, my application throws following exception:
Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException:
Non-Java exception raised, not handled!
(Original problem: *** -[NSCFArray initWithObjects:count:]:
attempt to insert nil object at objects[0])
at apple.awt.CDesktopPeer._lsOpen(Native Method)
at apple.awt.CDesktopPeer.lsOpen(CDesktopPeer.java:53)
at apple.awt.CDesktopPeer.open(CDesktopPeer.java:33)
at java.awt.Desktop.open(Desktop.java:254)
at zettelkasten.ZettelkastenView.eventHyperlinkActivated(ZettelkastenView.java:9609)
at zettelkasten.ZettelkastenView.access$6000(ZettelkastenView.java:119)
at zettelkasten.ZettelkastenView$14.hyperlinkUpdate(ZettelkastenView.java:7014)The file does definitely exist. I chose it with a filechooser, and I debugged the source step-by-step. Before calling the desktop.open() command, I check whether the file exists or not (File.Exists()).
When I open any file without umlauts, everything is fine. Only files with umlauts in their filename seem to make trouble.
My OS is:
Mac OS X 10.5.5, running the latest Java 6, using NetBeans 6.5
Is there any solution, or at least a workaround?
Thanks in advance!
Daniel
Edited by: DnlLdck on Jan 29, 2009 6:23 AM

Same thing happened to me, but I was trying to browse an URI which contains non-English characters. Haven't try it on Windows yet. Maybe it does not support non-English characters on Mac.

German Umlauts

The chart does not display German umlauts. Only English characters are displayed correctly. Is there a codepage problem?

Hi,
Usually this is caused by a missing or wrong configuration of the IGS fonts. Make sure that both chart interpreters are configured as desribed in note 596825 (gfwchart) and note 531668 (xmlchart).
Most UNIX boxes do not have TrueType font files. Therefore it's important to have the SAP IGS font files: note 1028690 tells you where to get the four Arial Unicode font files from and how to configure them appropriately.
Thanks,
Venkat

German umlauts and WLS...... (once again)

Hi
i'm using wls6.0 sp1 on a NT(4.0 Sp6) and on a Sun Solaris 6. if i try
to POST (using jsp) some data containing umlauts, an invalid character
('?') will be showed instead of the umlaut on solaris. the same
procedure works well on NT.
simply try the http://[myServer]:7001/console/..... application and
enter a "ä" in a "notes" tab of the wls server settings (wherever you
like).
is this a bug or a feature ? .->
idealy i would like to use german-umlauts.... so HELP !
thanx 4 ur answer
rsc

Hello Rolf,
It looks to me that the code conversion table between Unicode and the german
code page in JDK is not correct, or you may be running on the wrong locale
(codepage).
To verify that, use native2ascii.
1. Edit a file that has the german-umlauts and save it
2. execute native2ascii filename_input filename_output
3. execute native2ascii -reverse filename_output filename_output2
4. Open filename_output2 to see if it goes to ?
If it went to ?, you are in one of the above.
Reiji

German umlaute in resource bundles

Hi,
I am localizing an app in german. On windows I can use wordpad or Netbeans to type german umlaute (��) directly into the resource bundles (I have a german keyboard). But I fear, if someone runs this app on e.g. Linux, this does not work. I remember opening such files with an editor on Linux and the umlaute turned into some other strange letters. I think the same happens on english windows installs?
How can I do this right, to be able to run this app on Linux later?
Ingo

Ok, I am answering my own question here, just in case anybody else has the same problem. The solution is: use the native2ascii tool to covert files written with notepad into unicode. Or, use Netbeans to edit the resource Bundles (property files), it saves them in unicode from the beginning.
Ingo

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

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?

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

German umlauts / unicode in JNLP-File

Similar Messages

Maybe you are looking for