Special characters are changed to question marks

I'm using SQL developer 3.107 for unit testing.
In a particular unit test, the expected result is a sentence (varchar2) with a special character (ë).
But when I save the result, SQL developer changes the character to 2 question marks.
And as a result, the unit test fails because the expected result differs from the received result (where the 'ë' remains unchanged).
I already tried changing the encoding in the SQL Developer preferences from cp1252 to UNICODE and UTF8 but that didn't help.
Any suggestions?
Thanks in advance

Hello:
I guess that what you observe could be an interaction between the server characterset and the client characterset.
These are the results with different client characterset settings:
NLS_LANG=american_america.WE8ISO8859P1
select 'ë' c, dump('ë') dumped from dual;
C DUMPED
ë Typ=96 Len=1: 137
NLS_LANG=american_america.WE8MSWIN1252
select 'ë' c, dump('ë') dumped from dual;
C DUMPED
+ Typ=96 Len=1: 191
set NLS_LANG=american_america.WE8PC850
select 'ë' c, dump('ë') dumped from dual;
C DUMPED
ë Typ=96 Len=1: 235
According to the ISO 8859-1, 8-bit single-byte coded graphic character sets document [http://www.open-std.org/JTC1/SC2/WG3/docs/n411.pdf] the encoding of the latin small letter e with diaeresis is 0xEB -> (decimal 235).
If you set the client to WE8PC850 do you see a correct behaviour?

Similar Messages

Arabic characters are displaying as question marks in forms 10g

We have migrated our application from forms 6i to forms 10g and now in forms 10g the arabic characters are displaying as question marks while it displays correctly in the old application using forms 6i. I have already set the character set to AR8MSWIN1256 in the registry, but it didn't help. Somebody please help.

@ Sarah, Al-Salamu Alikum We Rahmatu Allah we Barakatu,
Sarah Habibty, why new installation ? In order to select a new suitable character set !!!
Then creating a new instance from the db is a better alternative since it saves time,effort and another back up of his current db is exist safely if needed for any purposes in the future.
@Amer,honestly speaking...
Modifing ur NLS_LANG to > AMERICAN_AMERICA.AR8MSWIN1256
Works for me in both Arabic and English data in 2 applications.This works in my pc.But it didn't works at my boss pc this can happened don't have any reason for that.!!!!
i spent lot's of time trying to search but what i had got is that solution i suggested by a friend of mine.
Now please could you advise me, is it better to create a new instance of database as Amatu Allah has suggested or is it better to change the character set through sql as some others have suggested? Again i suggest to select the short cut way ; to reset the character set through sql after taking a back up from ur data that is currently exist.
then retest again doing the select and test ur data input and retrieval.
SQL> select * from v$nls_parameters
2 where parameter in ('NLS_CHARACTERSET','NLS_LANGUAGE');watching the output if it works that's fine saving ur time & effort .
if not working with the correct NLS_CHARACTERSET then use my previous solution.
Hope this helps...
Regards,
Amatu Allah

Weblogic 12c Servlet Response - Special characters show up as question mark

My web app is running on Weblogic 12c (12.1.1) using WebWork + Hibernate. The program streams data (bytes making up a pdf) from a CLOB in an Oracle Database to the AsciiStream of the servlet output response. No exceptions are thrown, but the generated pdf contains blank pages. Comparing the bytes of the generated pdf, special characters are showing up as question marks.
Some of the bytes read in from the database contain 8 bits (correct data), but the bytes that the servlet return contain only 7 (all bytes with 8 bits become "1111111"). The number of bytes returned from the servlet is correct.
Code:
//Response is HttpServletResponse
response.setContentType("application/pdf");
response.setHeader("Content-Disposition", "inline; filename=\"test.pdf\"");
out = response.getOutputStream();
byte[] buf = new byte[16 * 1024];
InputStream in = clob.getAsciiStream();
int size = -1;
while ((size = in.read(buf)) != -1){
// buf contains the correct data
out.write(buf, 0, size);
// other exception handling code, etc
out.flush();
out.close();
"Correct" pdf byte example:
10011100
10011101
1010111
1001011
1101111
11011011
Incorrect pdf byte example:
111111
111111
1010111
1001011
1101111
111111
I have verified that the data read from the CLOB in the database IS correct. My guess is that the Weblogic server has some strange servlet settings that causes the bytes to be written to the servlet output stream incorrectly, or a character encoding issue. Any ideas?
Edited by: 944705 on Jul 26, 2012 10:17 AM

Solution found, I'll post the work around to those who might encounter the same problem.
Somewhere in the layers of technology (webwork or weblogic I'd guess), the servlet response is encoded into UTF-8 regardless. The encoding in the database was ISO-8859-1. Sending ISO encoded bytes by UTF-8 caused the conflicting character codes (anything above 127) to show up as undefined.
The fix is to decode the input byte array into ISO-8859 string, then encode that string into UTF-8, which can be send by Weblogic.
isoConvert = new String(buf, "ISO-8859-1");
out.write(isoConvert.getBytes("UTF-8"), 0, isoConvert.getBytes("UTF-8").length);

Some characters are replaced by question marks!

All of a sudden my iMac (OS X 10.5.1 Leopard) is displaying question marks for some special characters.
For example, on internet, look up a word "pediment" in Yahoo! Dictionary ( http://education.yahoo.com/reference/dictionary/entry/pediment)... Instead of showing the "dot" symbol to identify a syllabus break, it shows question marks as ped?i?ment, and instead of showing c with a little squiggle underneath for a word facade (within the definition of pediment), it shows fa?ade.
I did not have this problem on my iMac on Tuesday (01/29/08) morning and I have not installed anything other than the Apple updates.
I tried with FireFox and Safari, and both show the same thing. Then I went and checked my husband's iMac (OS X 10.5.1 Leopard) and it has a same problem, so I know it is not just my iMac.
Then (yes, there is more...) I started to work on my Word document and tried to insert "symbol" from insert on the Toolbar... many of my symbol fonts (Symbol, Osaka, etc) has question marks replacing special characters.
Please help! I am unable to complete my work without these special characters!!

Well, I went to the Yahoo! Dictionary "Pediment" and it said it was set to Default which is set to Western (ISO Latin 1), so I assumed it was Western (ISO Latin 1). But when I click on Western (ISO Latin 1), the pages appear what it's supposed to look like with special characters... What does this mean?
I reset all the settings; I chose something else as default, quit Safari, opened it and chose Western (ISO Latin 1) as a default to see if it changes anything... No change. It says my default is Western (ISO Latin 1), but it seems not.
I am officially confused and have no clue what to do...??????!!!!!
On the bright side, at least I can get my work done, even if I have to change the encoding one page at a time... Thanks.

Unicode characters are shown as "question marks" in Eclipse console

I am trying to retrieve Unicode data from Sybase database using jdbc.
The data are stored in Sybase with unichar and univarchar datatypes.
Following is the java code tring to run.
{color:#808080}public class Test
public static void main(String [] args) throws Exception
CoreServiceSoapBindingStub binding_Core = new CoreServiceSoapBindingStub();
CoreWSServiceLocator locator_Core = new CoreWSServiceLocator();
binding_Core = (CoreServiceSoapBindingStub) locator_Core.getCoreService();
Contact[] con = binding_Core.getContact();
for(int i=0;i< con.length;++i)
System.out.println(con.getLastName());
}{color}
The result of this code in Eclipse console should be as follow (consists of one English and one Japanese name).
{color:#808080}Suzuki
鈴木{color}
However when I run this, I get the following.
{color:#808080}Suzuki
{color}
The alphabetical characters seem to diplay fine in the console, but foreign characters are not....
The default character set of the database is ISO-8859-1, but I used unichar and univarchar to store data in unicode thus believe no issue at database side...
Used jconnect 6.05 (com.sybase.jdbc3.jdbc.SybDriver
) for the database driver.
Java files are encoded in UTF-8.
Console Encoding is UTF-8.
Is this an issue in database driver?
Since I set the parameters for character set to UTF-8 in both the database and java files....
It would be great if someone could give some comments on this issue....
Thanks a lot.

It might be better to ask this question on an Eclipse forum. I have a couple of suggestions, but none of them have made the output in my console look entirely correct:
1. Try to start Eclipse with these parameters: -vmargs -Dfile.encoding=UTF-8
2. Try switching the font settings for the Console under Preferences in Eclipse.

Japanese Characters are showing as Question Marks '?'

Hi Experts,
We are using Oracle Database with below nls_database_parameters:
PARAMETER VALUE
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET WE8MSWIN1252
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_NCHAR_CONV_EXCP FALSE
NLS_CSMIG_SCHEMA_VERSION 3
NLS_RDBMS_VERSION 11.1.0.7.0
When we are trying to view the Japanese characters (windows 7) in SQLdeveloper, toad or sqlPlus, we are getting data like '????'.
Can anybody please explain us the setups required to view the Japanese characters from the local machine and database.
Thanks in advance.

user542601 wrote:
[Note: If I insert the Japanese characters from Sql Developer or Toad, I am unable to see proper results.]For JDBC connections in Oracle SQL Developer, I believe a different parameter setting is required.
Try running Sql Dveloper with jvm option: -Doracle.jdbc.convertNcharLiterals=true.
I need to use this data in Oracle 6i Reports now.
When I am creating reports using the table where I have Japanese characters stored in NVARCHAR2 column, the value is not displaying correctly in Report Regardless of Reports support for nchar columns, 6i is very very old and based on equally ancient database client libraries (8.0.x if memory serves me). Earliest version of Oracle database software that support the N literal replacement feature is 10.2. So, obviously not available for Reports 6i.
I'm guessing only way to fully support Japanese language symbols is to move to a UTF8 database (if not migrating to a current version of Report Services).
Please help to provide a workaround for this. Or do I need to post this question in any other forums?There is a Reports forum around here somewhere. Look in the dev tools section or maybe Middleware categories.
Edit: here it is: {forum:id=84}
Edited by: orafad on Feb 25, 2012 11:12 PM
Edited by: orafad on Feb 25, 2012 11:16 PM

Outlook 2010 apostrophe, single and double quotes are changes to question mark while sending mails to other internet receipient.

We are using MS Outlook 2010 as our mail client. But we have noticed that whenevr we sent a mail to any other internet mail recipient all the "apostrophe", "single" and "double quotes" have automatically converted to ?. We have
done almost all the workaround found in this site such as
1.New a message and focus on the message window > click File > Options > Mail > Spelling and Autocorrect… > Proofing > AutoCorrect Options… > AutoFormat > clear the box before “Straight quotes” with “smart quotes”
2. Used different encoding. We presently using US-ASCII for outgoing message. etc.
Need your help to sort out these issues urgently.
Waiting for a solution.

Hi,
What is your account type? IMAP, POP or Exchange?
Send an email from the webmail, ask the recipient if this issue persists.
As far as I know, this problem is always related to the encoding for outgoing messages, and here I suggest you try UTF-8:
Go to File -> Options -> Advanced -> International options -> Uncheck "Automatically select encoding for outgoing messages", then select "Unicode (UTF-8)" beside "Preferred encoding for outgoing messages" -> OK.
Hope this helps.
Regards,
Melon Chen
TechNet Community Support

Language: Filename with characters for arabic turns question mark

Language: Filename with characters for arabic turns question mark
OS: Solaris 9
Machine: Sun-Fire 25K
There is an adobe distiller software that is configured and a java apps. There are postscript files that are being converted to .pdf format using the adobe distiller. Using the GUI (using the Exceed; for remote access), when they use GUI to convert the postscripts to pdf files, the long filenames have the corresponding characters for arabic reading purpose. This is OK.
When we use the windows RUN to telnet the server and convert the postscripts to pdf, it gives a question marks characters in the filenames ( this; is a sample; filename; ?? ??? ??; right.pdf )
We are not sure now if we have to add a package of arabic or a patch to resolve this problem.
Message was edited by:
yurioira32
Message was edited by:
yurioira32

Solution found, I'll post the work around to those who might encounter the same problem.
Somewhere in the layers of technology (webwork or weblogic I'd guess), the servlet response is encoded into UTF-8 regardless. The encoding in the database was ISO-8859-1. Sending ISO encoded bytes by UTF-8 caused the conflicting character codes (anything above 127) to show up as undefined.
The fix is to decode the input byte array into ISO-8859 string, then encode that string into UTF-8, which can be send by Weblogic.
isoConvert = new String(buf, "ISO-8859-1");
out.write(isoConvert.getBytes("UTF-8"), 0, isoConvert.getBytes("UTF-8").length);

Special characters are not shown in compare document report in Acrobat X

Hi All,
I have a pdf document which is having some special characters like üὄ. Now I have updated the document with few corrections and while compare document in Acrobat X special characters are not shown in the report.
Can any one please look into this and give suggestion.

Hi Steve,
Thanks for your reply.
Platform - PC
Application - 3B2 and Acrobat 9
So far we have seen this kind of issue in only one document. In the below screenshot you can see 2 pdf files, the right side one is my MS pdf and the left side one is the exported pdf from 3B2 application both the files having the special characters such as . I just did the text comparison however both and is missing in the exported pdf but the reports shown the changes for characters only wherever the charactes is missing the report not shown the changes properly(See highlighted in yellow).
Please let me know if you need more deatails.

RFC call from portal to CRM - Special Characters are replaced

Hi All,
I am trying to call an RFC which gives the user information. I pass the portal username.
Issue is when the user name has special characters 'ä' are replaced by 'Ã#'.
Iam using SAP CRM ABAP 7.0.
Please let me know how to solved it.
Thanks in advance..
Thanks and Kind Regards,
Basheer.

Possibility is your one of the system is Unicode & other is non unicode.

Reg:special characters are not priniting while selecting the CS language

Hi All,
When I am trying to print in CS language some special characters are not printing.
Even when I was trying to create the entries in TTDGT table ,these special characters are not created
( příkazu) here r & i are the special characters. instead of special characters simply r and i were created .
Could you please advice me on this how to resolve this .
Regards,
S.chaitanya.

Hello Chaitu,
I think you are working on scripts and trying to create the Script in different language?
However, try to copy the text in CS and paste it in STandard Text. If it is not displaying properly then Try to log in to the same language and try to paste that Text in the STanard text So10. If it appears properly then your issue is fixed.
Please let me know if the issue is while printing the Script form, i mean are you able to view it properly in the Print preview...?
If this is the issue then it is not an issue at your end user needs to check whether his printer is supporting their langauge or not.
Also check with the related language package . for ex I had worked on the Script form and tried to convert it into chinese i faced the same issue so when i checked with the System Admin he installed Asian Langauge Package in my system. After that I was able to convert the script into Chinese properly.
Hope this will be helpful..
Regards,
Kittu

Special characters are not being displayed normally after recent update.

FF messed up with that recent update. Special characters are now not being displayed properly - they somehow stretch the whole line where they are posted. It was fine before
I.E.:
http://www.discogs.com/artist/%E2%84%91%E2%8A%87%E2%89%A5%E2%97%8A%E2%89%A4%E2%8A%86%E2%84%9C
ℑ⊇≥◊≤⊆ℜ
Here you can see what I mean (Opera & FF screenshots), Opera has no problems with them, see highlighted:
http://img525.imageshack.us/img525/3897/image16m.jpg
Thanks

Which version were you using before?
Some font issues may be caused by graphics hardware acceleration. Since this feature was added to Firefox, it has gradually improved, but there still are a few glitches.
You can disable it, but you might need to restart Firefox in order for this to take effect, so save all work first (e.g., mail you are composing, online documents you're editing, etc.).
orange Firefox button ''or'' classic Tools menu > Options > Advanced
On the "General" mini-tab, uncheck the box for "Use hardware acceleration when available"
Does that make any difference?

German special characters are not returned from catalog

When the german special characters are part of the descrition of the article from the the catalog (external). ( reaching catalog from PM order components screen)
It returns '#' in place german special characters ö ('Umlet') . This is because of the initial charset from the HTML page. How do we get the correct charset of the loaded HTML page.
But when we execute the same through WTS the german characters are correctly returned but charset is incorrect. Can someone help me to resolve this?

Hi ,
Can you pls check the customization OCI interface Convert of HTML fields to SAP Fields where in you maintained the text, which is inturn mapped to conversion module in the customization for example IOCI_DESCRIPTION_W.
Regards
Satish

Why are special chars used in Labview filenames supplied by NI? By special chars, I mean ampersands, questions marks, Plus signs, slashes etc. Thats just bad practice in an otherwise good product.

I would like to request that National not use such filenames anymore. Spaces should also be avoided. Just use a format such as MyFileNameWillSuffice.vi.

> Perl. I carry that naming style from those languages. Questions marks
> used to be (maybe still are) used as wild card characters. I have run
> into problems on a Solaris machine when there were spaces in the file
> names. Plus signs slashes (/ or \) are a definite nono. So should
> !@#$%^&*()|.
>
> All those other languages have defined coding standards which serve to
> make code more readable and easier to maintain.
The LabVIEW coding guidelines warn against using some of those symbols,
but it isn't nearly as limiting as you might want. The reason for this
is that you rarely use VI names on a command line. If you are using
them, then simply "" the path. Feel free to further limit the
characters used in naming your own VIs, but
the names of VIs in vi.lib
and toolkits have already been determined and have in many cases been in
use for five to ten years. They do not cause problems.
Just for the record, LV is also localized into several languages
including Japanese and many of those customers use their native language
and native characters. Again, this doesn't cause problems.
Greg McKaskle

Values are returned as question marks.

I have set up a UTF-8 database, on my english version of WinXP..
SELECT * FROM NLS_DATABASE_PARAMETERS;
.. shows this is correct - UTF8
I have set up NLS_LANG variable in windows, to be "American.America.UTF8"
Using SQL*Plus worksheet I can update a row in my database to contain chinese characters. I dont know what the chinese means, but I can copy and paste from another application, and the glyphs looks the same in the source and SQL*Plus worksheet.
I can then select the row ..
SELECT * FROM THETABLE WHERE THECOLUMN = '{CHINESECHARS}';
The correct row is returned, but the column is shown with just question marks, instead of the glyphs I expect.
(This also happens with the web application I am developing which also seems to return qurestion marks. (PHP not JSP))
Can anyone shed any light on this problem as I am completely stuck.

Check these notes# 132453.1, 152260.1 & 158577.1 out on metalink also for further good details. This may/may not work for Chinese yet it should steer you
in the right direction.. It's the combination of the NLS_LANG and Active
Code page settings on the client as well as the database characterset. I believe you say the database character set is UTF8. That part should be correct. It's then the client side combo's that do the trick. It's trying differing combo's until he desired results are achieved. Having not worked with Chinese I can
give you an example of what I've experienced...
These are the following steps I performed to enable the client SQL*Plus (command line and GUI) and SQL*Worksheet to display/input the euro currency symbol correctly for example...
1) Search from the top of the registry (regedit) for ALL occurrences of NLS_LANG and make the value AMERICAN_AMERICA.WE8MSWIN1252.
2) Go to the following registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\ACP
and change the active code page (ACP) to 1252. If there is an OEMACP entry there change that also to 1252.
3) Reboot the PC
To test .. go to DOS and enter at the prompt..
E:\>chcp
Active code page: 1252
If the above message IS NOT 1252 you must have missed editting the registry entry
explained above. However you can change it for this session by entering
E:\>chcp 1252
- < Set font to Lucida Console (in Properties, Font tab) >
To get the UNICODE characters you want insert into the database do the following
E:\>charmap
You will see a display of different characters.
If you click on advanced view at the lower right corner a search screen comes up. Enter UNICODE for the character set, ALL for group by and EURO for the search for and the euro currency symbol will come up. This is one way how the user can enter this character into the app. You can copy the character in this function as you can see and then you can paste it elsewhere. Copy whatever character you want to test with. My test was with the euro currency symbol.
E:\>sqlplus.exe <user>/<pwd>
SQL*Plus: Release 8.1.7.0.0 - Production on Fri Jul 13 13:22:19 2001
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Connected to: Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
With the Partitioning option JServer Release 8.1.7.0.0 - Production
SQL> create table t (a char(3));
Table created.
SQL>insert into t values ('');
1 row inserted. SQL>
commit;
SQL> select * from t;
A
If the all the registry edits were performed correctly this will work with
SQL*Plus GUI and SQL*Worksheet.
Check these notes# 132453.1, 152260.1 & 158577.1 out on metalink also for further details real carefully.

Special characters are changed to question marks

Similar Messages

Maybe you are looking for