German Umlauts in helptext displayed as rectangle

Background
Upgrading Apex from 3.2.x to 4.0.2.00.07
Problem
Apex running in German. The tests look normal ( German Umlauts looks correct)
Only customized helptext or standard help text will display the Umlauts as rectangles.
Load_de.sql was running corrctly
On Apex.oracle.com -> The issue also not reproduceable
If set: Set Screen Reader Mode On = on
it works too?
Environment
ApEx 4.0.2.00.07 on linux 64-bit on a 11.1.1.0.7 database
Client: XP SP3 IE 8
Any ideas?
Perhaps similar issues in other languages like French or so?
Thanks Hendrik

Did you look at the character set when you exported your application from the 3.2 environment?
Did you import it into the 4 environment using the same character set?

Similar Messages

German Umlaut in CSV export on mac os

Hello,
i have problems with the csv export when i use an apple mac. German Umlaute are not displayed correctly, neither when i open the .csv file with TextApp nor when i open it with Numbers from iWork.
On a windows machine all is fine. Excel and every text editor i tried opens the file fine with the umlaute displaying correct.
The application is set to automatically encode the csv and application language is set to german.
Is there any other setting that i can change to get a correct csv export on an apple mac?
Apex version is 4.0.2.00.07, Oracle version is 11.2.0.1.0.
Thanks for help in advance,
Dirk

Hi Dirk,
Most likely, the Automatic CSV encoding attribute is set to 'Yes' for your application. If you're running your application in German, then the CSV file will be encoded in WE8MSWIN1252.
Can you try setting Automatic CSV Encoding to "No" (in the Globalization attributes of your application)? The CSV file will then be encoded in UTF-8 - which means that your Windows users may not open it directly but, instead, have to do a data import and specify utf-8 character set.
Joel

No german umlauts in OHW 2.0.2 topic view

I used OHW 1.1.5 before. Now switching to OHW 2.0.2, in the table of contents the german umlauts are not displayed correctly. The rest of the installation is identical. Its the same OS, the same JDK, the same Tomcat servlet engine and the same client web browser.
This phenomenon is independent of using a navigator Alias or not. I can't find any option in the documentation, which allows to configure the TOC output. How can german umlauts displayed in the TOC with OHW 2.0.2?
Thanks in advance
Michael

Do they display correctly in the other navigators? (i.e. does the keywords show them correctly?). In addition, do they show up in your topic pages (the actual help content)?

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

Problems displaying correct caracter set (German Umlaute)

Hi everybody,
Our development server had a crash some weeks ago, forcing us
to reinstall and resetup the Coldfusion server. Since then, where
has been some problems.
One of those problems occures in displaying the correct
character set. German Umlaute like ä, ü, ö cannot be
display probperly. There are displayed like this "Ã¤". We
have absolutely no clue, where the problem lies. We even set the
connection string within the datasource to
useUnicode=true&characterEncoding=iso-8859-1
but it still doesn't work. It has before the crash.
Somebody has an idea?

Hi lerman,
I think with the text labels, added to your other requests, that you have finally come to the limits of what we can do with the DIAdem Report express block. You might want to consider instead using the DIAdem Connectivity VIs, which are a free download. My recommendation is to create a TDMS data file with all the properties and string data and numeric data you want to pass to the report, then tell DIAdem to load that TDMS file and run the VBScript for report tweaking (in your case specific axis limits). Your string data can either be named scalar properties or 1D arrays of strings stored in channels. The point is that you have complete control over the structure and content of the TDMS file from LabVIEW, and you have complete control over the data and property references from DIAdem. The "DIAdem Report Wizard Start CSC.vi" I used in my attached example is installed by the "LabVIEW DIAdem Connectivity VIs", though it doesn't show up on the palette.
Brad Turpin
DIAdem Product Support Engineer
National Instruments
Attachments:
lerman.zip ‏27 KB

Strage display when using german umlauts on KDE captions

Hi!
I'm using Sun Java 1.4.2_01 on a RedHat Linux 9.0 machine. My window manager is KDE 3.1.4.
I'm developing a Swing application. My source files are saved in UTF-8 format because the application should support international users. Therefore I need i. e. German umlauts ("��..."). My texts are displayed correctly within popup-menus and labels. But when they appear on the window captions (I think these are created by the applied window manager) the international characters are displayed as small empty boxes.
Does anyone have similar experiences? Can I change some configuration parameters to get correctly displayed captions?
Thanks a lot in advance!
Marc

It seems that I have solved the problem with the character set. It's not really something that I understand but it works: I have changed the startup script that is used in /etc/init.d/rc5 to start the server. I changed the shell for the script. It was not working when I used #/bin/bash or #/bin/sh but it works when I use #/bin/csh.

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

Encoding Problem: Losing German Umlaute from gathering data from Oracle 8i

my problem does concerns the diplay of german Umlaute such as Ã¤Ã¶Ã¼Ã etc. The OS is NW65 out of the box with Apache 2.0.49 and tomcat 4.1.28, JVM 1.4.2_02 and JDBC-driver Oracle 8i 8.1.7 JDBC Driver.
The Data containing Umlaute which are retreived from the Database does somehow lose itÂ´s Umlaute. The Umlaut which are coded in the servlet directly in order to generate the regular HTML does display the Umlaute without any problem.
The same servlet and request from a Unix Enviroment does work fine. We have checked all Codepage settings (Java, NetWare, Tomcat etc).

Hi Sven and Ingmar,
I will try to kill 2 birds with one stone here. First of all you should check the definition of your current database character set and make sure that it can support all the characters that you need to store in your database.
Please check out
http://www.microsoft.com/globaldev/reference/iso.asp
WE8ISO8859P9 is for Turkish and WE8ISO8859P1 is for western European (without Euro support).
Next you need to set your client NLS_LANG character set (eg. for your SQL*Plus seesion), so that Oracle can convert your client operating system characters correctly into your database character set. The NLS_LANG character set also determines how SQL*Plus interpret/display your characters upon retrieval from the db.
In both of your cases , I believed that the client NLS_LANG setting was not defined , hence this was defaulting to AMERICAN_AMERICA.US7ASCII. This is telling SQL*PLUS that the your client operating system can handle ASCII data only , hence all the accented characters are converted to ASCII during insertion into the database. Likewise upon data retrieval.
If you are running SQL*PLUS client on English Windows then you NLS_LANG character set should be WE8MSWIN1252 and for Turkish Windows it should set to TR8MSWIN1254 .
If the client character set and the database character set are the same , Oracle does not perform any data conversion, that's why if you use a US7ASCII database and set you NLS_LANG character set to US7ASCII .then you can insert all the accented Latin characters , Japanese , Chinese etc. This configuration is not supported, and it can cause many issues.
For more information on character set configuration and possible problems.
Please check out the white paper Database Character set migration on http://otn.oracle.com/products/oracle8i/content.html#nls
And the Globalization Support FAQ at:
http://technet.oracle.com/products/oracle8i/
Regards
Nat
null

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?

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...

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

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

Wrong german umlauts

Hi,
we are using PI/7.0 and a customer uses XI/3.0 - we have the same SWCV installed on the machines.
The solution sends mails via java-mail - not via mail adpter of XI/PI.
We are sending IDocs from R/3 to XI and the solution sends mails via java-mail to external destinations.
Our problem is now the "german umlauts".
On XI everything works fine - the attachment-file is ANSI and all german umlauts are correct.
On PI the attachment is UTF-8 and all german umlauts are 2 bytes.
I checked everything hundreds of times - and found no difference.
The only difference is the NLS-Support of the database. On both installations there is ORACLE 9.2 and on PI (that doesn't work correctly) the NLS-LANG configuration is "US" and UTF-8,
The installation on XI/3.0 (this works!) is german.germany and iso-8859-1.
Is it possible that this is out problem?
Regards
Wolfgang

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 disappeared

Hi. My Apple Mail is no longer able to display and print German Umlauts. It prints greek characters instead. That happens although Umlauts are working with any other program, including Safari URLs etc. Selected code table is "Automatic", but UTF and ISO 1 doesn't change anything either. There has been no change and no update done when this error occured. What shall I do?

Could you send a screenshot (tom at bluesky dot org)?

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

German Umlauts in helptext displayed as rectangle

Similar Messages

Maybe you are looking for