Unicode to Japanese characters

Hi,
I need a function to convert unicode to Japanese characters. I have a unicode string in my syncBO and it needs to be converted to the "strange" Japanese characters.
When I read the unicode String from the MAMText files it is automatically done by the MI framework.
Unicode string example: \u6A5F\u80FD\u5834\u6240\u4E00\u89A7
Are there standard MI functions for me which are converting these kind of Strings? Because for the MAMText files it is working via the getString method of the com.sap.ip.me.api.services.MEResourceBundle class.
I hope someone knows more about this conversion.
Thanks in advance! Kind regards,
Bart Elshout

hi bart,
it would be nice if you could feedback me with the error problems.
i know the code might not cater to all of the requirements, you might need to add
other escaped characters if you need to in the switch scope. i forgot to tell you
that to use the a2n function you should provide it with the string in its ISO format.
try running on the MyTest program below with the argument as follows:
MyTest "u6A5Fu80FD u5834 u6240u4E00u89A7"
public class MyTest {
  public  static void main(String[] args){
    System.out.println(a2n(args[0]));
if you use it like this way, it will not work, since the String class will detect this
and automatically create the native representation of the characters. there's no
need for the a2n function.
  String s = "u6A5Fu80FD u5834 u6240u4E00u89A7";
  System.out.println(a2n(s));
if you are reading text from an ascii file, you need to specify that the input stream
should be  ISO-8859-1 i.e.something like
new InputStreamReader(inStream, "ISO-8859-1")
hope this helps.
jo

Similar Messages

  • Handling Multi-byte/Unicode (Japanese) characters in Oracle Database

    Hello,
    How do I handle the Japanase characters with Oracle database?
    I have a Java application which retrieves some values from the database; makes some changes to these [ex: change value of status column, add comments to Varchar2 column, etc] and then performs an UPDATE back to the database.
    Everything works fine for the English. But NOT for Japanese language, which uses Multi-byte/Unicode characters. The Japanese characters are garbled after the performing the database UPDATE.
    I verified that Java by default uses UTF16 encoding. So there shouldn't be any problem with Java/JDBC.
    What do I need to change at #1- Oracle (Database) side or #2- at the OS (Linux) side?
    /* I tried changing the NLS_LANG value from OS and NLS_SESSION_PARAMETERS settings in Database and tried 'test' insert from SQL*plus. But SQL*Plus converts all Japanese characters to a question mark (?). So could not test it via SQL*plus on my XP (English) edition.
    Any help will be really appreciated.
    Thanks

    Hello Sergiusz,
    Here are the values before & after Update:
    --BEFORE update:
    select tar_sid, DUMP(col_name, 1016) from table_name where tar_sid in ('6997593.880');
    /* Output copied from SQL-Developer: */
    6997593.88 Typ=1 Len=144 CharacterSet=UTF8: 54,45,53,54,5f,41,42,53,54,52,41,43,54,e3,81,ab,e3,81,a6,4f,52,41,2d,30,31,34,32,32,e7,99,ba,e7,94,9f,29,a,4d,65,74,61,6c,69,6e,6b,20,e3,81,a7,e7,a2,ba,e8,aa,8d,e3,81,84,e3,81,9f,e3,81,97,e3,81,be,e3,81,97,e3,81,9f,e3,81,8c,e3,80,81,52,31,30,2e,32,2e,30,2e,34,20,a,e3,81,a7,e3,81,af,e4,bf,ae,e6,ad,a3,e6,b8,88,e3,81,bf,e3,81,ae,e4,ba,8b,e4,be,8b,e3,81,97,e3,81,8b,e7,a2,ba,e8,aa,8d,e3,81,a7,e3,81,8d,e3,81,be,e3,81,9b,e3,82,93,2a
    --AFTER Update:
    select tar_sid, DUMP(col_name, 1016) from table_name where tar_sid in ('6997593.880');
    /* Output copied from SQL-Developer: */
    6997593.88 Typ=1 Len=144 CharacterSet=UTF8: 54,45,53,54,5f,41,42,53,54,52,41,43,54,e3,81,ab,e3,81,a6,4f,52,41,2d,30,31,34,32,32,e7,99,ba,e7,94,9f,29,a,4d,45,54,41,4c,49,4e,4b,20,e3,81,a7,e7,a2,ba,e8,aa,8d,e3,81,84,e3,81,9f,e3,81,97,e3,81,be,e3,81,97,e3,81,9f,e3,81,8c,e3,80,81,52,31,30,2e,32,2e,30,2e,34,20,a,e3,81,a7,e3,81,af,e4,bf,ae,e6,ad,a3,e6,b8,88,e3,81,bf,e3,81,ae,e4,ba,8b,e4,be,8b,e3,81,97,e3,81,8b,e7,a2,ba,e8,aa,8d,e3,81,a7,e3,81,8d,e3,81,be,e3,81,9b,e3,82,93,2a
    So the values BEFORE & AFTER Update are the same!
    The problem is that sometimes, the Japanese data in VARCHAR2 (abstract) column gets corrupted. What could be the problem here? Any clues?

  • Create HTML file that can display unicode (japanese) characters

    Hi,
    Product:           Java Web Application
    Operating system:     Windows NT/2000 server, Linux, FreeBSD
    Web Server:          IIS, Apache etc
    Application server:     Tomcat 3.2.4, JRun, WebLogic etc
    Database server:     MySQL 3.23.49, MS-SQL, Oracle etc
    Java Architecture:     JSP (presentation) + Java Bean (Business logic)
    Language:          English, Japanese, chinese, italian, arabic etc
    Through our java application we need to create HTML files that have to display unicode text. Our present works well with English and most of the european character set. But when we tried to create HTML files that will display unidoce text, say japanese, only ???? is getting displayed. Following is the code we have used. The out on the browser displays the japanese characters correctly. But the created file displays only ??? in place of japanese chars. Can anybody tell how can we do it?
    <%
    String s = request.getParameter( "txt1" );
    out.println("Orignial Text " + s);
    //for html output
    String f_str_content="";
    f_str_content = f_str_content +"<HTML><HEAD>";
    f_str_content = f_str_content +"<META content=\"text/html; charset=utf-8\" http-equiv=Content-Type></HEAD>";
    f_str_content = f_str_content +"<BODY> ";
    f_str_content = f_str_content +s;
    f_str_content = f_str_content +"</BODY></HTML>";
    f_str_content = new String(f_str_content.getBytes("8859_9"),"Shift_JIS");
    out.println("file = " + f_str_content);
              byte f_arr_c_buffer1[] = new byte[f_str_content.length()];
    f_str_content.getBytes(0,f_str_content.length(),f_arr_c_buffer1,0);
              f_arr_c_buffer1 = f_str_content.getBytes();
    FileOutputStream l_obj_fout; //file object
    //file object for html file
    File l_obj_f5 = new File("jap127.html");
    if(l_obj_f5.exists()) //for dir check
    l_obj_f5.delete();
    l_obj_f5.createNewFile();
    l_obj_fout = new FileOutputStream(l_obj_f5); //file output stream for writing
    for(int i = 0;i<f_arr_c_buffer1.length;i++ ) //for writing
    l_obj_fout.write(f_arr_c_buffer1);
    l_obj_fout.close();
    %>
    thanx.

    Try changing the charset attribute within the META tag from 'utf-8' to 'SHIFT_JIS' or 'utf-16'. One of those two ought to do the trick for you.
    Hope that helps,
    Martin Hughes

  • Japanese characters, outputstreamwriter, unicode to utf-8

    Hello,
    I have a problem with OutputStreamWriter's encoding of japanese characters into utf-8...if you have any ideas please let me know! This is what is going on:
    static public String convert2UTF8(String iso2022Str) {
       String utf8Str = "";
       try {          
          //convert string to byte array stream
          ByteArrayInputStream is = new     ByteArrayInputStream(iso2022Str.getBytes());
          ByteArrayOutputStream os = new ByteArrayOutputStream();
          //decode iso2022Str byte stream with iso-2022-jp
          InputStreamReader in = new InputStreamReader(is, "ISO2022JP");
          //reencode to utf-8
          OutputStreamWriter out = new OutputStreamWriter(os, "UTF-8");
          //get each character c from the input stream (will be in unicode) and write to output stream
          int c;
          while((c=in.read())!=-1) out.write(c);
          out.flush();          
         //get the utf-8 encoded output byte stream as string
         utf8Str = os.toString();
          is.close();
          os.close();
          in.close();
          out.close();
       } catch (UnsupportedEncodingException e1) {
          return    e1.toString();
       } catch (IOException e2) {
          return e2.toString();
       return utf8Str;
    }I am passing a string received from a database query to this function and the string it returns is saved in an xml file. Opening the xml file in my browser, some Japanese characters are converted but some, particularly hiragana characters come up as ???. For example:
    &#23627;&#21488;&#39592;&#30000;&#23478;&#12399;&#26178;&#38291;&#30446;&#38626;&#12428;&#25312;&#12426;&#25152;&#37027;&#35207;&#24066;&#30690;&#30000;&#20124;&#24076;&#23376;&#12490;&#12479;&#12495;&#12450;&#12469;&#12459;&#12521;&#12510;&#26978;&#33865;&#12373;&#12510;&#12516;&#12450;
    shows up as this:
    &#23627;&#65533;?&#65533;&#39592;&#30000;&#23478;&#65533;?&#65533;&#26178;&#38291;&#30446;&#38626;&#12428;&#25312;&#12426;&#25152;&#37027;&#35207;&#24066;&#30690;&#30000;&#20124;&#24076;&#65533;?&#12490;&#12479;&#65533;?&#12450;&#12469;&#12459;&#12521;&#12510;&#26978;&#33865;&#65533;?&#65533;&#12510;&#12516;&#12450;
    (sorry that's absolute nonsense in Japanese but it was just an example)
    To note:
    - i am specifying the utf-8 encoding in my xml header
    - my OS, browser, etc... everything is set to support japanese characters (to the best of my knowledge)
    Also, I ran a test with a string, looking at its characters' hex values at several points and comparing them with iso-2022-jp, unicode, and utf-8 mapping tables. Basically:
    - if I don't use this function at all...write the original iso-2022-jp string to an xml file...it IS iso-2022-jp
    - I also looked at the hex values of "c" being read from the InputStreamReader here:
    while((c=in.read())!=-1) out.write(c);and have verified (using character value mapping table) that in a problem string, all characters are still being properly converted from iso-2022-jp to unicode
    - I checked another table (http://www.utf8-chartable.de/) for the unicode values received and all of them have valid mappings to a utf-8 value
    So it appears that when characters are written to the OutputStreamWriter, not all characters can be mapped from Unicode to utf-8 even though their Unicode values are correct and there should be utf-8 equivalents. Instead they are converted to (hex value) EF BF BD 3F EF BF BD which from my understanding is utf-8 for "I don't know what to do with this one".
    The characters that are not working - most hiragana (thought not all) and a few kanji characters. I have yet to find a pattern/relationship between the characters that cannot be converted.
    If I am missing some....or someone has a clue....oh...and I am developing in Eclipse but really don't have a clue about it beyond setting up a project, editing it and hitting build/run. It is possible that I may have missed some needed configuration??
    Thank you!!

    It's worse than that, Rene; the OP is trying to create a UTF-8 encoded string from a (supposedly) iso-2022 encoded string. The whole method would be just an expensive no-op if it weren't for this line:   utf8Str = os.toString(); That converts the (apparently valid) UTF-8 encoded byte array to a string, using the system default encoding (which seems to be iso-2022-jp, BTW). Result: garbage.
    @meggomyeggo, many people make this kind of mistake when they first start dealing with encodings and charset conversions. Until you gain a good understanding of these matters, a few rules of thumb will help steer you away from frustrating dead ends.
    * Never do charset conversions within your application. Only do them when you're communicating with an external entity like a filesystem, a socket, etc. (i.e., when you create your InputStreamReaders and OutputStreamWriters).
    * Forget that the String/byte[] conversion methods (new String(byte[]), getBytes(), etc.) exist. The same advice applies to the ByteArray[Input/Output]Stream classes.
    * You don't need to know how Java strings are encoded. All you need to know is that they always use the same encoding, so phrases like "iso-2022-jp string" or "UTF-8 string" (or even "UTF-16 string") are meaningless and misleading. Streams and byte arrays have encodings, strings do not.
    You will of course run into situations where one or more of these rules don't apply. Hopefully, by then you'll understand why they don't apply.

  • Oracle Report Server Issue with Japanese Characters

    We are trying to setup a Oracle Report Server to print the Japanese characters in the PDF format.
    We have separate Oracle Report servers for printing English, Chinese and Vietnamese characters in PDF formats using Oracle Reports in the production which are running properly with Unix AIX version 5.3. Now we have a requirement to print the Japanese characters. Hence we tried to setup the new server for the same and the configurations are done as same as Chinese/Vietnamese report servers. But we are not able to print the Japanese characters.
    I am providing the details which we followed to configure this new server.
    1.     We have modified the reports.sh to map the proper NLS_LANG (JAPANESE_AMERICA.UTF8) and other Admin folder settings.
    2.     We have configured the new report server via OPMN admin.
    3.     We have copied the arialuni.ttf to Printers folder and we have converted this same .ttf file in AFM format. This AFM file has been copied to $ORACLE_HOME/guicommon/gk/JP_Admin/AFM folder.
    4.     We have modified the uifont.ali (JP_admin folder) file for font subsetting.
    5.     We have put an entry in JP_admin/PPD/datap462.ppd as *Font ArialUnicodeMS: Standard "(Version 1.01)" Standard ROM
    6.     We have modified the Tk2Motif.rgb (JP_admin folder) file for character set mapping (Tk2Motif*fontMapCs: iso8859-1=UTF8) as we have enabled this one for other report servers as well.
    Environment Details:-
    Unix AIX version : 5300-07-05-0831
    Oracle Version : 10.1.0.4.2
    NLS_LANG : JAPANESE_AMERICA.UTF8
    Font Mapping : Font Sub Setting in uifont.ali
    Font Used for Printing : arialuni.ttf (Font Name : Arial Unicode MS)
    The error thrown in the rwEng trace (rwEng-0.trc) file is as below
    [2011/9/7 8:11:4:488] Error 50103 (C Engine): 20:11:04 ERR REP-3000: Internal error starting Oracle Toolkit.
    The error thrown when trying to execute the reports is…
    REP-0177: Error while running in remote server
    Engine rwEng-0 crashed, job Id: 67
    Our investigations and findings…
    1.     We disabled the entry Tk2Motif*fontMapCs: iso8859-1=UTF8 in Tk2Motif.rgb then started the server. We found that no error is thrown in the rwEng trace file and we are able to print the report also in PDF format… (Please see the attached japarial.pdf for your verification) but we are able to see only junk characters. We verified the document settings in the PDF file for ensuring the font sub set. We are able to see the font sub setting is used.
    2.     If we enable the above entry then the rwEng trace throwing the above error (oracle toolkit error) and reports engine is crashed.
    It will be a great help from you if you can assist us to resolve this issue…

    Maybe 7zip or another tool has workarounds for broken file names, you could try that.
    Or you could try to go over the files in the zip archive one-by-one and write it to files out-1, out-2, ..., out-$n without concerning yourself with the file names. You could get file endings back via the mimetype.
    This script might work:
    #include <stdio.h>
    #include <zip.h>
    static const char *template = "./out-%04d.bin";
    int main(int argc, char**argv)
    int err = 0;
    zip_t *arc = zip_open((const char*)argv[1], ZIP_RDONLY, &err);
    if(arc == NULL)
    printf("Failed to open ZIP, error %d\n", err);
    return -1;
    zip_int64_t n = zip_get_num_entries(arc, 0);
    printf("%s: # of packed files: %d\n", argv[1], n);
    for(int i = 0; i < n; i++)
    zip_stat_t stat;
    zip_stat_index(arc, i, ZIP_FL_UNCHANGED, &stat);
    char buf[stat.size];
    char oname[sizeof(template)];
    zip_file_t *f = zip_fopen_index(arc, (zip_int64_t)i, ZIP_FL_UNCHANGED);
    zip_fread(f, (void*)&buf[0], stat.size);
    snprintf(&oname[0], sizeof(template), template, i);
    FILE *of = fopen(oname, "wb");
    fwrite(&buf[0], stat.size, 1, of);
    printf("%s: %s => %lu bytes\n", argv[1], oname, stat.size);
    zip_fclose(f);
    fclose(of);
    zip_close(arc);
    return 0;
    Compile with
    gcc -std=gnu99 -O3 -o unzip unzip.c -lzip
    and run as
    ./unzip $funnyzipfile
    You should get template-named, numbered output files in the current directory.
    Last edited by 2ion (2015-05-21 23:09:29)

  • How to store japanese characters in mysql 5.0

    I want to store japanese characters in mysql 5.0 database through java program and then to retrive the same characters through the program only.Java program means a form containing first name ,last name and address. I am entering corresponding translations in japanese to this fields while inserting to database. In another form i am retrieving those japanese characters.those should display
    in this form.

    How to handle the unicode sir for japanese characters..Pls give me more hints and any reference links to get the answer.

  • 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

  • Problem with Gui_download using ASC File type - japanese characters

    Hi,
    During upgrade,while downloading data for japanese characters using GUI_DOWNLOAD Function module with file type as 'ASC', the space between 2 fields data getting much wider compared to 4.6C Version ws_download Function module's  data.
    Example: the gap between first field data and second field data in ECC 6.0 is 6 characters length,but in 4.6C it is 2 characters length.
    Is there any possibility to get the results similar to 4.6c version.Please give your valueable suggestions.
    Thanks
    BalaNarasimman

    Hi Sandra
    Please find the detailed information for your questions.
    1.Internal table content before download:During Debugging,it was observed that internal table content was same in both versions.For testing,i used only brand new data(Transaction entry).
    2.Download with code Page conversion:Yes,codepage parameter 4103 was explicitly passed into GUI_DOWNLOAD Function module.Also the front end code page which is used by system is 4110 . No errors occured.
    3.System is an Unicode system only.
    4.Actually this 6 character does not refer the byte value,only the gap between 2 fields data is getting referred in ECC 6.0.Please find the below example.
    Example - File data after Download:
    ECC 6.0: Field1            Field2      (gap - 6 characters space between 2 fields data)  Using GUI_Download
    data       u0152©Ïu201Dԍu2020      EN                               
         4.6C: Field1            Field2       (gap - 2 characters space between 2 fields data) Using WS_Download
         data    u0152©Ïu201Dԍu2020  EN    
    Note:Special characters are Japanese characters:

  • Saving a file in a with a file name containing Japanese Characters

    Hi,
    I hope some genius out there comes up with the solution to this problem
    Here it is :
    I am trying to save some files using a java program from the command console , and the file name contains japanese characters. The file names are available to me as string values from an InputStream. When I try to write to a File Object containing the japanese characters , I get something like ?????.txt . I found out that I am able to save the files using the unicode value of the java characters.
    So I realize that the trick is to convert the streaming japanese characters , character by character into their respective unicode value and then Create A File Object with that name. The problem is -> I cant find any standard method to convert these characters into their unicode values. Does anyone have a better solution ? Remember , its not writing japanese characters to a file , but creating a file with japanese characters in the file name !!!!
    Regards
    Chandu

    retrive a byte array out of the input Stream and store the values in String using the condtructor
    String(byte [] bytes, String enc)
    where encoding would be Shift_Jis for japanese I guess.
    Now to understand this concept basically all the Strings are unicode however when you are passing a byte array String has no means to know what is the encoding of the byte array, which is being used to instantiate the String value so if no encoding is specified it takes the System value which is mostly iso-8859-1. This leads to displaying ?
    However in case you know the encoding of the array specifying that in the constructor would be a real help.

  • Chinese/Japanese characters not appearing on smartforms PDF output

    Hi,
    The print preview of the Smartforms output layout is correctly displaying the characters of native/local languages like Chinese, Japanses etc.....but when i try to print this output, it is printing the junk characters.
    Whereas the same printer is able to print the Chinese, Japanese characters when printed from MS Word.
    So this issue is occurring only when printing from SAP.
    In spool i could see the Chinese/Japanese characters appearing correctly, whereas when i try to convert it to PDF using program RSTXPDFT4, the PDF is again showing junk characters replacing the chinese characters.
    Thanks!

    This could be of different reeasons...
    1) Make sure your printer is uni-code enabled.
    2) Make sure, your unicode enabled printer is configured in SAP.
    3) make sure, your printer device is supported by SAP. (You can find list of SAP recommended printers in www.service.sap.com)
    4) Check whether the correct device type is used for printing chinese and japanese characters.
    5) Check code pages.
    6) Make sure you use Cyrillic font family, for printing chinese and Japanese characters.
    Regards,
    SaiRam

  • Square boxes instead of Japanese characters in pdf output of a crystal rep

    Hi All,
    Did anyone of you ever faced such an issue, where the pdf output of a crystal report shows square boxes instead of Japanese characters when the output is saved in pdf. However the crystal report output looks perfect. I have saved the ouput in xls and rtf formats the characters look perfect as required, the issue we have is when the output is saved as pdf.
    I have language pack installed on my machine.
    My guess is that the few Character's width is not sufficient and few Characters in other fields appear perfect in pdf. I have to test this, it might take few days before I can access this report. Before that I want to gather information. If anyone has solution to this issue please let me know.
    Thanks,
    Ravi

    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

  • MySQL Japanese characters

    Hello,
    I already searched the froums for a soluton to my problem but couldn't find any for it though I tried some of the things that were proposed. I have a MySQL Database where I store Japanese characters in SJIS. I tested if they are in SJIS and they are.
    I am using mysql 4.1.3b-beta, mysql-connector-java-3.0.14, JBuilderX (jdk 1.4.2), and OS XP.
    When I try to retrieve the data I only get a square, then a some character, then a square, then another character,... but not the actual Kanji/Kana. I can display Japanese characters correctly when I retrieve them from a file, so I don't think it's a problem with the font.
    My code is as follows:
    public void testDB(){
    String result ="";
    Connection con = null;
    Statement st = null;
    try
    Properties prop = new java.util.Properties();
    prop.put("user","");
    prop.put("password","");
    prop.put("useUnicode", "true");
    prop.put("characterEncoding","SJIS");
    String url = "jdbc:mysql://localhost/japanese";
    //Class.forName ("org.gjt.mm.mysql.Driver");
    Class.forName ("com.mysql.jdbc.Driver").newInstance ();
    con = DriverManager.getConnection (url, prop);
    result= "Database connection established";
    st = con.createStatement();
    ResultSet rs = null;
    String querry1 = "SELECT * FROM jp";
    PreparedStatement pstmt = con.prepareStatement(querry1);
    rs = pstmt.executeQuery();
    int i = 0;
    while (rs.next()) {
    result = rs.getString(1);
         jTable1.setFont(new Font("Arial Unicode MS",0,15));
    jTable1.setValueAt(result,i,0);
    i++;
    catch (Exception e)
    // result = "Cannot connect to database server";
    finally
    if (con != null)
    try
    con.close ();
    // result ="Database connection terminated";
    catch (Exception e) { /* ignore close errors */ }
    I hope someone can help me as MySql is my last option after I already discovered that I couldn't use MS Access and Foxpro because the ODBC:JDBC bridge doesn't work correctly for unicode.
    On a side note as I am new to MySql after installing version mysql4.1.3b. I no longer have the mysqld.exe but only mysqld-opt.exe. So I am using this instead. But I don't think that can be responsible for my problem.
    Thaks for any help.
    S

    I see your original question was sent in August so maybe you have found an answer ?.. Would be interesting to see how you fixed it.
    I was having a similar sort of problem but managed to fix it by looking at the fonts available to Java on my machine and setting the font used by the graphics object to one of the japanese fonts. (nb. I see in your code you are setting the font to arial unicode, maybe setting it to a japanaese font name would be enough)
    Hopefully the following will give you some help.
    // this line sticks the name of all fonts in the graphics environment in an array
    String[] nameArray = GraphicsEnvironment
                   .getLocalGraphicsEnvironment()
                   .getAvailableFontFamilyNames();
    // I know that the last two fonts are for japanese characters. I chose the font name second from the end of the array.
    int listfonts=nameArray.length-2 ;
    //then I sent the font for the g2 object.
    Font fontselec ;
    fontselec = new Font(nameArray[listfonts],Font.PLAIN,24) ;
    g2.setFont(fontselec) ;
    best regards
    Graham

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

Maybe you are looking for

  • ITUNES locks up my PC

    ITUNES locks up my PC when importing from my music folder as well as when importing music from a CD. It's very random, soetimes I can get through a CD without issue other times it stops every few songs and I have to reboot my PC. Here's my CD Diagnos

  • How do I recover my missing messages?

    when I start tbird to check messages all previous messages were missing and only those that immediately downloaded were displayed--- how to recover?

  • How to get out of full screen mode

    This can't be difficult but for me it is annoying. It would probably help to know how I got here in the first place

  • NEWBIE TO MAC - HELP - Notation Composer Problem

    Hi, I have just brought my first mac and its good apart from this problem. On Windows, I use a prog called Notation Composer. The prog does all I want to do. import midi files, then shows it as sheet music score. I can change key,tempo, and if I;am i

  • SAP and the FIFO issues

    Hi I am a continuous improvement advisor in an medium sized factory and we are currently looking to streamline the purchase order through to despatch process. The main problem seems to be the high quantity of part pallets we have due to the only supp