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

Similar Messages

Apex 4.0 Cascading Select List: ajax problem with german umlaute

Hi everybody,
Apex 4.0
Dad PlsqlNLSLanguage: GERMAN_GERMANY.WE8MSWIN1252
I have problems with german umlaute and ajax cascading select lists (Cascading LOV Parent Item).
The data is populated without a page refresh in the select list when the parent select list changes but special signs like german umlaute are shown as weird characters.
Seems like there is some charset problem with ajax.
This is the only part of the application where special signs like umlaute are messed up. Everything else is fine.
I allready tried to figure out if I can escape the umlaute in the javascript (file apex_widget_4_0.js) but no success here.
Can anybody help me with this issue?
Thanks in advance,
Markus

Hi Markus,
your specified character set in your DAD is wrong. As mentioned in the installation instructions at http://download.oracle.com/docs/cd/E17556_01/doc/install.40/e15513/otn_install.htm#CHDHCBGI , Oracle APEX always requires AL32UTF8.
>
3. Locate the line containing PlsqlNLSLanguage.
The PlsqlNLSLanguage setting determines the language setting of the DAD. The character set portion of the PlsqlNLSLanguage value must be set to AL32UTF8,
regardless of whether or not the database character set is AL32UTF8. For example:Regards
Patrick
My Blog: http://www.inside-oracle-apex.com
APEX 4.0 Plug-Ins: http://apex.oracle.com/plugins
Twitter: http://www.twitter.com/patrickwolf

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

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

AS2 Sender problem with German "Umlaute"

Hello experts,
I have an AS2 sender adapter sending orders into my SAP system. My problem is though that it deletes all German "Umlaute" before converting it into XML.
I used to use the "CallBicXIRaBean" to do the Encoding with ISO-8859-1 and it did not work. So now I am using the "CharsetConversion" to do that but it still does not work.
In the Module of the AS2 sender I am using:
1) CharsetConversion
- sourceDest --> MainDocument
- targetDest --> MainDocument
- sourceEnc --> ISO-8859-1
- targetEnc --> ISO-8859-1
2) CallBicXIRaBean
- mappingName --> E2X_ORDERS_UN_D93A
3) localejbs/CallSapAdapter
- 0
Does anyone have an idea what I have to change?
Thank you very much for your help!
Best regards,
Peter

Hello Iddo,
Thank you for your answer.
When I expect Umlaute in a message I always use ISO-8859-1 and not UTF-8.
The Umlaute are actually deleted. For example the German "für" looks like this "f". Or "Präferenzsituation" looks like this: "Prerenzsituation". So it kills the Umlaut and the following character.
The sender insists that he sends the messages with Umlaute. Now I activated the AS2 Message Dumping and hopefully will see what the message really looks like. Maybe the Umlaute are already deleted when they get to the AS2 adapter. I hope to find out soon.
Best regards,
Peter

Problems with German umlaut in OCI query

Hello,
I have some problems in getting results, if I search for data with a German umlaut like "ä", "ö" or "ü".
In SQL*Plus the following query returns on row:
SQL> SELECT SYSBE.ID AS SYSBE_ID
2          , SYSBE.NACHNAME AS SYSBE_NACHNAME
3          , SYSBE.VORNAME AS SYSBE_VORNAME
4       FROM SYS_BENUTZER SYSBE
5          LEFT JOIN SYS_ABTEILUNGEN SYSAB ON SYSAB.ID = SYSBE.ABTEILUNG_ID
6        WHERE SYSBE.STATUS = 'aktiv'
7           AND ((SYSAB.KUERZEL <> 'SYS') OR (SYSAB.KUERZEL IS NULL))
8           AND SYSBE.ID NOT IN (SELECT PMPD.MITARBEITER_ID
9                 FROM PM_PROJEKT_MITARBEITER PMPD
10                 WHERE PMPD.PROJEKT_ID = 26 AND
11                   PMPD.MITARBEITER_ID = SYSBE.ID)
12           AND (REGEXP_LIKE(SYSBE.NACHNAME, 'hö', 'i')
13              OR REGEXP_LIKE(SYSBE.VORNAME, 'hö', 'i'))
14        ORDER BY SYSBE.NACHNAME, SYSBE.VORNAME;
SYSBE_ID SYSBE_NACHNAME
SYSBE_VORNAME
        52 Höfling
AlexanderIf I execute this from PHP via the oci8.dll no rows will be returned. Yesterday the DBA helped me to trace the query and it looks exactly the same as above.
Can anyone help?
Regards,
Stefan

Are your NLS environment variables the same on both systems? Were they set prior to starting up Apache/IIS?

SAP Gui 7.20 PLevel 3, ALV Problems with German Umlauts u00FCu00F6u00E4...

Hi,
we have updated our SAP Gui to version 7.20 lately and have some serious problems now with entering German Umlauts 'üöäÜÖÄß' into any editable ALV grid.
This means when typing in e.g. 'ü', the grid immediately removes this character and replaces it by, well, by nothing. It just ignores this character at all.
SAP Gui is currently at patch level 3 . The correct version is 7200.1.3.3190, build 1196830. Running German Windows XP clients with service pack 3. ERP is running SAP ECC 6.0.
Is this a known problem? Has sbdy. a workaround this?
Edit: Just found the release notes for SAP Gui 7.20 Lvl 3:
2010/09/02 Texts get garbled while typing umlaut character in ALVGrid, Note 1503081
This note, however, is not open for public view. OTH this means SAP was aware of this problem and tried to correct it to no avail so far.
Thanks,
Michael
Edited by: Michael Fritz on Nov 19, 2010 11:19 AM

Hi Martin,
where did you get this info? Any official SAP note available? Do you encounter similar problems?
We, too, noticed that uploading and downloading files from directories with German Umlauts, this fails now,too. There may be problems with files, too, however, we did not check this so far. The previous SAP Gui, I guess it was 7.10, didn't have any problems with this.
I start wondering if SAP Germany have ever tested this? Or do they not use Umlauts anyway

Pages 2.0.2 has problems with German umlaut characters and hangs.

The problem has occured when I had the idea to rename the style names to have exported html files wider accepted by other browsers.
Therefore I tried to rename used style names by replacing encountered umlaut letters by their transcriptions e.g. "Überschrift 1" by "Ueberschrift 1" and so on. But when doing so, the program was freezing while the last changed style name was vanishing and did not come back at all.
Reinhard.
iMac Mac OS X (10.4.9) computer chess programming

I cannot reproduce your problem. I rename überschrift 1 to Ueberschrift. Logically it moves to the bottom of the list, but it is still there and nothing hangs.
Does this happen in all your documents or only one?
Does it happen using all templates or only one?
Are you working in German all the time, or have you switched to English in the mean time?
Do you have access to other computers with the problem, or have you seen it only on yours?
Have you renamed other styles like "Text" or "Titel" without problem?
If you start Pages in English, do you have the same problem?

Problems with german umlauts when Migration from MS Access to Oracle

When I make a Migration from MS Access 97 to Oracle 8.1.5, I have Problem with the germans characters (umlauts). The Oracle is using the rigth character Set for german characters. What can I do? Is it e problem from the MS Access ODBC Driver or the Oracle ODBC Driver?

Is your character set for Oracle set up to UTF8??

XML and german Umlaut

Hello everyone,
i am writing a little application that uses SAX to parse XML documents and i am having a bit of a problem with german Umlaut (e.g. �, �, �). I looked up the entities that are commonly used in the internet, so for example � becomes either ä or ä , but now for some incomprehensible weird reason those entities are changed into something like for example ä...
Could anybody help me out with this problem? I am completely lost and don't even know what's going on here any more. Maybe my PC is developing a vicious life of its own...
Thanks
Chris

Here's what's happening, then.
Your XML is being written in UTF-8. This is the default encoding for XML and it represents characters that aren't in the ASCII character set by 2 or more bytes. For Latin accented characters it uses 2 bytes. When you read that file back into your program, you must specify the encoding; if you don't, then the system will incorrectly assume that the file is encoded in whatever is the default for your system. To do this:Reader r = new InputStreamReader(new FileInputStream(yourFile), "UTF-8");

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

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

Legend map request with german umlaut

Hello,
i have a problem sending a legend map request that contains a german umlaut.
I'm trying to use the pl/sql function for sending and parsing a xml request from the mapviewer documentation (chapter 3.1.16, example 3-19).
my request looks like this
<map_request datasource="mvdemo" format="PNG_URL">
<legend bgstyle="fill:#ffffff;stroke:#ffffff" profile="MEDIUM">
    <column>
      <entry style="C.YELLOW" text="Übernahme"/>
    </column>
</legend>
</map_request>The resulting image does not contain the umlaut Ü but a little square instead.
I tried replacing the Ü with Ü ;
<map_request datasource="mvdemo" format="PNG_URL">
<legend bgstyle="fill:#ffffff;stroke:#ffffff" profile="MEDIUM">
    <column>
      <entry style="C.YELLOW" text="Übernahme"/>
    </column>
</legend>
</map_request>This works when i manually send the request on the mapviewer map request page, but it doesn't work when i use the pl/sql function.
The documentation says that the request has to be url encoded, so i tried using utl_url.escape on the whole request and on only the umlaut. Both doesn't work.
Thanks for help in advance,
Dirk

Hi Cleber,
which MapViewer version are you using? This may be related with the PDF graphics library version. This library has been modified to better handle the legend texts. I tested your request and it appears to be OK with the current library. You can send me (by email) a picture of your legend, and I will confirm if this has been fixed.
Joao

Adobe Dreamweaver FTP connection doesn't work with german "Umlaut" like "ö" in the severadress

Hi
Today I tried to establish a FTP connection to the serveradress "ftp.möbelverwandlung.com", but I get the error message that the program couldn't connect to the host. As Dreamweaver works perfectly with other serveradresses and I managed to establish a connection to "ftp.möbelverwandlung.com" with other programs, I think that the problem is the german "Umlaut" "ö". Did anyone recognize the same problem and does someone know a solution?
Thank you very much for your help

Here is the English translation of your previous post -
Hello Maximilian,
I got a even looked at my provider. Usually there must pay the original domain for the agreed period and agree a new. However, they show a accommodating for so short "duration" of a few hours like you. Try to contact your ISP phone support.
MfG
Hans-Günter
Anyhow, I think you have covered the options!

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?

Problem copying German Umlauts

Similar Messages

Maybe you are looking for