Japanese Characters in a Windows Applet.....

I know this might seem like the Greek Character discussion but the problem is a bit different because of the applet's limited font selection.
Here's the basic issue:
I need to be able to display a variety of languages in an applet environment, including Japanese, Cyrillic (which mostly works), Hebrew, Arabic, and just about anything else. Some character sets (like Cyrillic) show up, others, like Japanese, just appear as boxes.
Now the question, how can I get the font I need to display the text properly in an applet environment? Is there an INI file setting somewhere that I can fiddle with?
Any help would be greatly appriciated! Thanks,
->David Priebe

Check out the link below -- it's a five page document that should answer most if not all of your questions:
http://www.onjava.com/pub/a/onjava/2001/04/12/internationalization.html
V.V.

Similar Messages

Problem in displaying Japanese characters in SAPScripts

Hi All,
I am facing a strange problem in one of my SAPScripts. I have one script in both English and Japanese languages. The scripts are already existing. I had to do some minor changes in a logo window. I did them and i did not do any other changes in any of the windows.
When the output wa s seen for the script in the Japanese version, it was looking ok displaying all hte Japanese characters in various windows. Now, during testing , in the same server, the Japanese characteres are not shown. Instead , some ' #'(hash) symb ols are getting displayed.
How could it happen? Did any body face such problem? If so, can anybody plz help me out with the solution?
What shud i do to get back the Japanese characters in my script again?
Regards,
Priya

Priya.
this is not an ABAP problem ask your BASIS team to set printer cofing from SPAD.dont worry its not an ABAP issue at all.
sometime printer doesnt support special char so it need to be setting with printer.
Amit.

Japanese characters in SQL Developer Version 1.5.4

I am using SQL Developer ver 1.5.4 with Oracle 11g. There are Japanese characters stored in VARCHAR2 field.
When I execute a SELECT SQL query, SQL Developer does not display Japanese characters in the Result window -- it displays row of small square characters instead.
(When I execute the same query as a script -- it displays the Japanese characters in Script Output window,
What should I do to have SQL Developer to display Japanese characters in Result window?
Thank you!
Mark.
Edited by: MarcoPolo on Jul 7, 2009 11:16 AM

Hi there, Have you fixed this issue?
I'm having the same issue albeit with SQL Developer VERSION 1.5.5
The Select stmt displays the the empty square boxes in the result window, I've set the encoding preferences to UTF8 in the menu and font to Arial Unicode (there is no option to set script to Japanese). How can i display japanese characters in the results window??
When i export these empty square boxes in the result window to notepad (where encoding set to Unicode and Font set to Arial Unicode and Script to Japanese), the japanese value is displayed correctly in the notepad.
Kindly provide some input
Many Thanks

Display Japanese characters on Applet

Hi All,
I am able to display Japanese Characters on my Applet locally(Windows 2000 - US) by overwriting the font.properties content with the one in font.properties.ja found in JRE/LIB directory of my Jdeveloper JDK. When I deploy the applet on 9ias server which is configured for UTF8 charset I get squares wherever I have Japanese characters.
Appreciate if someone could tell the procedures to make the applet to recognize the Japanese/UTF8 characters and display accordingly.

I have read some documentation on JDBC thin drivers and they have mentioned that whenever JDBC retreives data from a database it converts it to Unicode 1.2 and I am already retreiving data from a UTF 8 database. The reason I think this is true is because I can display japanese characters locally on my windows machine by overwriting the font.properties in the JDevelopers- JDK- JRE - LIB folder by font.properties.ja
There must be some way to test why it is showing squares for japanese characters when I deploy it on the server. May be not getting the MS Gothic font used to display Japanese?
Looks like updating all the code is not feasible at this point as the code currently stores the data in Vectors and we can't perform a vector.getBytes(). Any help will be really appreciated.

Japanese characters in applet

I apologise if this question has been asked befor, but here's the deal
I have a database full of HTML character codes that a colleague is using in a servlet. They are in japanese. One of the lines looks like this.
インフォメーショ&#12531
I'm retrieving this as a string. How do I convert this into unicode so I can display the japanese characters. At the moment, any effort on my part to convert the charset just looks at each individual character - ie it converts &, then # rather than realising that &#12452 is one char.
Thanks in advance
Dan

Addition: sorry, forgot that the forum is of course HTMl! The string that I am getting back looks like this:
インフォメーショ&#12531

How can I get Japanese characters to show up for my music in iTunes?

I am not exactly sure what generation my iPod is, but it says copyright 2004 on the back. It is 20 GB. It has no problems displaying Japanese characters if a particular song of mine is Japanese. I have my iPod set up to manually manage music. I like to carry my iPod between home and work. At both home and work, I use PCs with Windows XP Pro installed. I also use the latest version of iTunes (ver. 7.1.1.5).
However, I have run into a weird problem. On my home computer, my iTunes displays Japanese characters perfectly fine, but on my work computer, whenever there is a Japanese character, iTunes does not recognize it and puts an ugly "square" character in its place. How do I get my iTunes to display these Japanese characters properly?
Thanks.

Well I just answered my own question. I needed to install the files for East Asian languages via the WinXP Control Panel. So if anyone else runs into this problem, there ya go!

Creating a PDF from a SAAS app creates boxes instead of Japanese characters

I'm using an online app (Unleashed Software) to "print" invoices, and the printed invoices show boxes instead of Japanese characters. The really weird thing about this problem, is that it occurs only on certain devices. I've tested on Macs, Windows, Android, and iOS, and on some devices I get the problem, and on some devices I don't. It's not just a Windows problem, or a iOS problem. Additionally, I use different browsers, from Chrome, to IE, to Firefox, to Safari. Changing the browser doesn't seem to help when it's on a device that won't output Japanese characters in a PDF properly.
I'm wondering how PDFs are generated when using online software. Since I can't reproduce the problem on certain devices, it seems to me that the software is using some local settings to render the PDF incorrectly.
Any ideas of how I could go about troubleshooting this problem?

Hi,
Could you please answer the following questions
1.What version of Crystal Reports are you using?
Go to Help-> About to find out.
2.What is the font you are using on the report?
Try to change the font style to MS Gothic or Arial Unicode MS, most preferably MS Gothic.
And export the report to PDF format.
This may help you
Thanks,
Praveen G

Specify File Encoding(Japanese Characters) for UTL_FILE in Oracle 10g

Hi All,
I am creating a text file using the UTL_FILE package. The database is Oracle 10G and the charset of DB is UTF-8.
The file is created on the DB Server machine itself which is a Windows 2003 machine with Japanese OS. Further, some tables contain Japanese characters which I need to write to the file.
When these Japanese characters are written to the text file they occupy 3 bytes instead of 1 and distort the format of the file, I need to stick to.
Can somebody suggest, is there a way to write the Japanese character in 1 byte or change the encoding of the file type to something else viz. ShiftJIS etc.
Thanking in advance,
Regards,
Tushar

Are you using the UTL_FILE.FOPEN_NCHAR function to open the files?
Cheers, APC

Japanese characters display with wrong encoding all of a sudden...

I had no issues before when it came to typing in Japanese in DW using the windows language bar , I would just change the keyboard to JP(japanese) and then start typing within DW code view, but then one day after doing updating my main template and using the find and replace feature in DW all the Japanese characters turned into question marks, diamonds with question marks and ASCII alphanumeric codes..
also the spaces in my documents turned into blocks. It was a mess,
*I don't know if it was something I triggered accidentaly or if it was some type of bug....I also remember copying and pasting text and Japanese characters from another website that I created(but I had done that a dozen times before and it was never a problem).
Long story short, after not being able to find a solution I decided to manually delete the weird symbols and start over, I typed in Japanese using the windows language bar as always and began typing away inside the same pages that displayed those weird characters (sorry I don't know what the proper name for them is)and it accepted the Japanese characters with no issues, it was working just like it did before.
but my question is "What happened?" was that a bug in DW or was it something on my end?
I would like to know so I can fix the problem incase this happens again.
I've always had utf-8 as the charset and it's never been an issue. (and I all my pages are saved as utf-8 as well)
--Which is why I am confused why all the Japanese got messed up.
Here is the head code of one of the pages that had the problem:
Thank you.

Without seeing an actual page, it's impossible to say what happened, but the most likely explanation is that you did something wrong. Asian characters, such as Japanese, require correct encoding. If the encoding is incorrect, you end up with mojibake.
I suspect that what happened is that you copied and pasted from Shift-JIS or EUC-JP encoding into a different encoding. It's quite possible that your page was set to iso-8859-1 (Western European) without realizing.
By the way, your head code didn't show up in your post.

Acrobat Pro 9.3.1 does not convert certain Japanese characters

I have a text document that contains a mix of Roman and Japanese characters - when I do Create PDF From File and read that text document in, there is a sequence of 2 Japanese characters that disappear - the text before them and after them appear in the PDF, but there's a void between.
The sequence is (don't know if I can insert Japanese in here...)
before監査証跡after
When the PDF is generated, the first 2 Japanese characters (after the last 'e' in before) do not appear in the PDF.
Here is the source text document (UTF-8 encoded with BOM): http://www.scribd.com/doc/28158046
and here is the resulting PDF: http://www.scribd.com/doc/28158121
Anyone seen this before?

If I paste your "before監査証跡after" into Notepad and save it as UTF-8 text, I can print the file to the Acrobat 9.3.1 Pro "Adobe PDF" printer with no problems at all: the 4 kanji appear in a font Acrobat calls "MS-UIGothic". If I right-click on the saved *.txt file in Windows Exploreer (Vista 64) and select "Convert to Adobe PDF" I still get all the kanji, although the first shows up in Adobe Ming, the 2nd in Adobe Song, and the last 2 in KozGoPr6N.
I can't explain what's going on here, but perhaps this can help point you down a useful path.
David

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

Oracle 6i Report Output Japanese Characters to XML on UNIX?

I have a 6i report which reads text from the database and outputs everything to XML. There is now a requirement for it to handle Japanese characters.
I was able to do this successfully in Windows by changing my NLS_LANG to UTF8 and changing the field font to a Unicode font. I then ran the report, and the XML that was output contains the correct Japanese characters from the underlying database query.
When I port the report to UNIX, the report runs, but the Japanese characters all show up as upside-down question marks in the XML. If I open the report in Reports Builder from the server, I do not see any Unicode fonts, but it changed my selected font to "clear".
Can anyone suggest the fix to get this working in UNIX? Does a new font need to be installed on the server to support this?
Thanks in advance for any suggestions!

we used UTF8 which worked fine with that.

Japanese characters from args giving question marks on Japanese OS

Hi,
We are internationalising our product to japanese, and one of the features is to be able to open a file containing japanese characters from a double click on a japanese windows OS.
The double click is set up in the registry, and indeed it works properly for most characters. There are a few characters though (unicode character 20060 among them) that it doesn't work for, and what happens is that between the double clicking of the file, and the command line name of the file to open ("%1" in the registry / args[0] in java), the character in question is converted into the literal character for "?" (ascii 63), and java can't open the file.
Testing wordpad directly with this character is fine, the file opens. I've written a simple C++ app and a simple JAVA app which fork wordpad with the fileName param passed to it from the registry, and it didn't open the file passed because of that character.
So our java application, a simple java program and a simple C++ program can't resolve the fileName passed to it because of this character.
The thing is, wordpad is using the same regedit method to get its parameters as we do ("appName.exe" "%1" in shell/open/command) and it opens files containing this character without a problem.
Any ideas on what I'm missing?
Thanks very much
Jack

Hi,
We are internationalising our product to japanese,
and one of the features is to be able to open a file
containing japanese characters from a double click on
a japanese windows OS.
The double click is set up in the registry, and
indeed it works properly for most characters. There
are a few characters though (unicode character 20060
among them) that it doesn't work for, and what
happens is that between the double clicking of the
file, and the command line name of the file to open
("%1" in the registry / args[0] in java), the
character in question is converted into the literal
character for "?" (ascii 63), and java can't open the
file.
Testing wordpad directly with this character is fine,
the file opens. I've written a simple C++ app and a
simple JAVA app which fork wordpad with the fileName
param passed to it from the registry, and it didn't
open the file passed because of that character.
So our java application, a simple java program and a
simple C++ program can't resolve the fileName passed
to it because of this character.
The thing is, wordpad is using the same regedit
method to get its parameters as we do ("appName.exe"
"%1" in shell/open/command) and it opens files
containing this character without a problem.
Any ideas on what I'm missing?
Thanks very much
JackUnicode 20060 belongs to an extended part of JIS Kanji code set and there can be many
applications or systems that do not support those characters. Shift_JIS doesn't and
EUC-JP use 24 bit code for representig those chars which, unfortunately, aren't supported
by most exixting apps.

[Bug Report] CR4E V2: Exported PDF displays Japanese characters incorrectly

We now plan to transport a legacy application from VB to Java with Crystal Reports for Eclipse. It is required to export report as PDF file, but result PDFs display Japanese characters incorrectly for field with some mostly used Japanese fonts (MS Gothic & Mincho).
Here is our sample Crystal Reports project: [download related resources here|http://sites.google.com/site/cr4eexportpdf/example-of-cr4e-export-pdf]
1. PDFExportSample.rpt located under ..\src contains fields with different Japanese fonts.
2. Run SampleViewerFrameClient#main(..) to open a Java Report Viewer:
    a) At zoom rate 100%, everything is ok.
    b) Change zoom rate to 200% or 50%, some fields in Japanese font collapse.
    c) Export to PDF file,
         * Fonts "MS Gothic & Mincho": both ASCII & Japanese characters failed.
         * Fonts "Meiryo & HGKyokashotai": everything works well.
         * Open PDF properties, you will see all fonts are embedded with built-in encoding.
         * Interest to note that copy collapsed Japanese characters from Acrobat Reader, then
           paste them into a Notepad window, Notepad will show the correct Japanese characters anyway.
           It seems PDF export in CR4E mistaking to choose right typeface for Japanese characters
           from some TTF file.
3. Open PDFExportSample.rpt in Crystal Report 2008 Designer (trial version), and export it as PDF.
    The result PDF displays both ASCII & Japanese characters without any problem.
Test environment as below:
* Windows XP Professional SP3 (Japanese) with MS Office which including extra fonts (i.e. HGKyokashotai)
* Font version: MS Gothic, Mincho, Meiryo, all in Version 5.0
    You can download MS Meiryo from Microsoft's Site:
    http://www.microsoft.com/downloads/details.aspx?familyid=F7D758D2-46FF-4C55-92F2-69AE834AC928&displaylang=en)
* Eclipse 3.5.2
* Crystal Reports for Eclipse, V2, 12.2.207.r916
Can this problem be fixed? If yes how long will it take to release a patch?
We really looking forward to a solution before abandoning CR4E.
Thanks for any reply.

I have created a [simple PDF file|http://sites.google.com/site/cr4eexportpdf/inside-the-pdf/simple.pdf?attredirects=0&d=1] exported from CR4E. It is expected to display "漢字" (or in unicode as "\u6F22\u5B57"), but instead being rendered in different ones of "殱塸" (in unicode as "\u6BB1\u5878").
Look inside into this simple PDF file (you can just open it with your favorite text editor), here is its page content:
8 0 obj
<</Filter [ /FlateDecode ] /Length 120>>
stream ... endstream
endobj
Decode this stream, we get:
/DeviceRGB cs
/DeviceRGB CS
q
1 0 0 1 0 841.7 cm
13 -13 569.2 -815.7 re W n
BT
1 0 0 1 25.75 -105.6 Tm     <-- text position
0 Tr
/ttf0 10 Tf                 <-- apply font
0 0 0 sc
( !)Tj                      <-- show glyphs [20, 21], which index is to embedded TrueType font subset
ET
Q
The only embeded font subset is defined as:
9 0 obj /ttf0 endobj
10 0 obj /AAAAAA+MSGothic endobj
11 0 obj
<< /BaseFont /AAAAAA+MSGothic
/FirstChar 32
/FontDescriptor 13 0 R
/LastChar 33
/Subtype /TrueType
/ToUnicode 18 0 R                            <-- point to a CMap object
/Type /Font
/Widths 17 0 R >>
endobj
12 0 obj [ 0 -140 1000 859 ] endobj
13 0 obj
<< /Ascent 860
/CapHeight 1001
/Descent -141
/Flags 4
/FontBBox 12 0 R
/FontFile2 14 0 R                            <-- point to an embedded TrueType font subset
/FontName /AAAAAA+MSGothic
/ItalicAngle 0
/MissingWidth 1000
/StemV 0
/Type /FontDescriptor >>
endobj
The CMap object after decoded is:
18 0 obj
/CIDInit /ProcSet findresource begin 12 dict begin begincmap /CIDSystemInfo <<
/Registry (AAAAAB+MSGothic) /Ordering (UCS) /Supplement 0 >> def
/CMapName /AAAAAB+MSGothic def
1 begincodespacerange <20> <21> endcodespacerange
2 beginbfrange
<20> <20> <6f22>                         <-- "u6F22"
<21> <21> <5b57>                         <-- "u5B57"
endbfrange
endcmap CMapName currentdict /CMap defineresource pop end end
endobj
I can write out the embedded TrueType font subset (= "14 0 obj") to a file named "[embedded.ttc|http://sites.google.com/site/cr4eexportpdf/inside-the-pdf/embedded.ttf?attredirects=0&d=1]", which is really a tiny TrueType font file containing only the wrong typefaces for "漢" & "字". It seems everything OK except CR4E failed to choose right typefaces from the TrueType file (msgothic.ttc).
Is it any help? I am looking forward to any solution.

Problem in displaying Japanese characters on the browser.

Hi Friends,
Hope one of you could help me in this!!
We are using SHIFT_JIS character encoding in our jsps to display Japanese characters.
<%@ page contentType="text/html; charset=SHIFT_JIS" %>
Is there any other configuration required on server side to let the Japanese characters being displayed? Because what I am getting on screen is quite annoying. Well something like below.
?V?M???????�
Even though my knowledge in Japs isn't too good :-)) I can understand that these are not Japanese. I believe I am missing something in terms of server side configuration, Can anybody point that out. (Maybe some of the Japanese developers in here).
This could not be a client side issue, since from the same machine I can access other Japanese sites and they display properly. Let me know if anybody can help.
I am running these in WAS 5.0
Thanks,
King

Your text in the JSP should be UTF-8 nevertheless - as would be ideal
for internationalization. Java comes with a command-line conversion tool
native2ascii which is bidirectional.
As non-Japanese I am not certain whether "SJIS" might not be better (there
are some name variations in java).
The HTML generation will translate these characters to SHIFT_JIS in your case.
Where the target encoding cannot handle the intended character it receives a
question mark - hat you saw.
Furthermore you need a proper font in HTML and under Windows (window title).
Your webserver should have east-asian support. Though Japanese (and English)
are standard, I, as non-japanese am not certain about SHIFT_JIS.
Also there is some freedom in choice for a japanese encoding.

Japanese Characters in a Windows Applet.....

Similar Messages

Maybe you are looking for