Issue inputting japanese characters in sqlplus?

(Reposting this from Linux forum)
Hey all, looking for some feedback on this issue.
Background: Using a tool to process an external data file (with a Japanese filename and contents which contain Japanese as well). This tool ultimately places the converted data into an Oracle database.
When this tool is run from our Windows environment, everything works correctly.
However, when running the Linux version of the tool, talking to the same database, the following is output:
WARNING: underlying database error.
SDE Code (-51): Underlying DBMS error
Extended DBMS error code: 911
ORA-00911: invalid character
(駅)
Not able to create business table 駅
Delete layer "駅" ...
SDE Code (-51): Underlying DBMS error
Extended DBMS error code: 911
ORA-00911: invalid character
Unable to delete layer "駅"
When we re-run the tool with an English filename it seems to work fine regardless of the contents of the file.
Relevant environment variables:
LANG=ja_JP.UTF8
NLS_LANG=Japanese_Japan.UTF8
NLS_LANGUAGE=japanese
And I have also tried with:
LANG=ja_JP.eucJP
NLS_LANG=japanese_japan.JA16EUC
NLS_LANGUAGE=japanese
I have noticed that if I run sqlplus directly and attempt to create a simple table with a Japanese name, I get the ORA-00911 error with japanese_japan.JA16EUC as NLS_LANG. If I change NLS_LANG to Japanese_Japan.UTF8 I can then successfully create a table with japanese characters in its name. I still cannot run our conversion tool above.
Any ideas or tips? I believe the database is set up correctly as it does work with Windows as the client... perhaps the conversion tool is overriding my NLS_LANG settings? Any other possibilities you can think of?
TIA,
Ray

Thanks for all the input guys.
Here's output from when I have an error creating a table:
ORACLE_HOME is /goa1/ora10gr2/app/oracle/product/10.2.0
ORACLE_SID is jap10b
SDEHOME is /goa1/sde/sde93_jap/sdeexe93
NLS_LANG is japanese_japan.JA16EUC
LANG is ja_JP.eucJP
jap10b on goa.esri.com >sqlplus user/pw
SQL*Plus: Release 10.2.0.2.0 - Production on �� 5�� 8 17:06:56 2008
Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
With the Partitioning and Data Mining options
SQL> CREATE TABLE 文 (
2 I INT);
CREATE TABLE 文 (
ERROR at line 1:
ORA-00911: invalid character
SQL> SELECT * from NLS_SESSION_PARAMETERS;
PARAMETER
VALUE
NLS_LANGUAGE
JAPANESE
NLS_TERRITORY
JAPAN
NLS_CURRENCY
PARAMETER
VALUE
NLS_ISO_CURRENCY
JAPAN
NLS_NUMERIC_CHARACTERS
NLS_CALENDAR
GREGORIAN
PARAMETER
VALUE
NLS_DATE_FORMAT
RR-MM-DD
NLS_DATE_LANGUAGE
JAPANESE
NLS_SORT
BINARY
PARAMETER
VALUE
NLS_TIME_FORMAT
HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT
RR-MM-DD HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT
HH24:MI:SSXFF TZR
PARAMETER
VALUE
NLS_TIMESTAMP_TZ_FORMAT
RR-MM-DD HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY
NLS_COMP
BINARY
PARAMETER
VALUE
NLS_LENGTH_SEMANTICS
BYTE
NLS_NCHAR_CONV_EXCP
FALSE
17 rows selected.
SQL> select value from nls_database_parameters where parameter = 'NLS_CHARACTERSET';
VALUE
JA16EUC
SQL> select value from nls_database_parameters where parameter = 'NLS_NCHAR_CHARACTERSET';
VALUE
AL16UTF16
SQL> And here it works fine (using UTF8 in shell environment)
ORACLE_HOME is /goa1/ora10gr2/app/oracle/product/10.2.0
ORACLE_SID is jap10b
SDEHOME is /goa1/sde/sde93_jap/sdeexe93
NLS_LANG is Japanese_Japan.UTF8
LANG is ja_JP.UTF8
jap10b on goa.esri.com >
jap10b on goa.esri.com >sqlplus user/pass
SQL*Plus: Release 10.2.0.2.0 - Production on 木 5月 8 17:09:12 2008
Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
With the Partitioning and Data Mining options
SQL> CREATE TABLE 文 (
2 I INT);
Table created.
SQL> SELECT * from NLS_SESSION_PARAMETERS;
PARAMETER
VALUE
NLS_LANGUAGE
JAPANESE
NLS_TERRITORY
JAPAN
NLS_CURRENCY
PARAMETER
VALUE
NLS_ISO_CURRENCY
JAPAN
NLS_NUMERIC_CHARACTERS
NLS_CALENDAR
GREGORIAN
PARAMETER
VALUE
NLS_DATE_FORMAT
RR-MM-DD
NLS_DATE_LANGUAGE
JAPANESE
NLS_SORT
BINARY
PARAMETER
VALUE
NLS_TIME_FORMAT
HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT
RR-MM-DD HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT
HH24:MI:SSXFF TZR
PARAMETER
VALUE
NLS_TIMESTAMP_TZ_FORMAT
RR-MM-DD HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY
NLS_COMP
BINARY
PARAMETER
VALUE
NLS_LENGTH_SEMANTICS
BYTE
NLS_NCHAR_CONV_EXCP
FALSE
17 rows selected.
SQL> select value from nls_database_parameters where parameter = 'NLS_CHARACTERSET';
VALUE
JA16EUC
SQL> select value from nls_database_parameters where parameter = 'NLS_NCHAR_CHARACTERSET';
VALUE
AL16UTF16Input is being done from an SSH session from an XFCE Terminal on a Fedora 8 machine. I am cutting and pasting the Japanese character. Everything seems to match up, save for the shell environment variable. I wonder if somehow the character transmitted by my paste changes based on the character set setting.

Similar Messages

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)

Issue with Japanese characters in files/filenames in terminal.

I recently downloaded a zip file with Japanese characters in the archive and in the files within the archive. The name of the archive is "【批量下载】パノプティコン労働歌第一等.zip"
The characters are properly displayed in firefox, chrome, and other applications, but in my terminal some of the characters appear corrupted. Screenshot: https://i.imgur.com/4R22m0D.png
Additionally, this leads to corruption of the files in the archive. When I try to extract the files, this is what happens:
% unzip 【批量下载】パノプティコン労働歌第一等.zip
Archive: 【批量下载】パノプティコン労働歌第一等.zip
extracting: +ii/flac/Let's -+-ʦ1,000,000-.flac bad CRC 5f603d51 (should be debde980)
extracting: +ii/flac/+ѦѾP++ -instrumental-.flac bad CRC 78b93a2d (should be 3501d555)
extracting: +ii/flac/----.flac bad CRC ddeb1d3e (should be c05ae84f)
extracting: +ii/flac/+ѦѾP++.flac bad CRC 0ccf2725 (should be be2b58f1)
extracting: +ii/flac/Let's -+-ʦ1,000,000--instrumental-.flac bad CRC 67a39f8e (should be ece37917)
extracting: +ii/flac/.flac bad CRC f90f3aa0 (should be 41756c2c)
extracting: +ii/flac/ -instrumental-.flac bad CRC 3be03344 (should be 0b7a9cea)
extracting: +ii/flac/---- -instrumental-.flac bad CRC 569b6194 (should be adb5d5fe)
I'm not sure what could be the cause of this. I'm using uxterm with terminus as my main font and IPA gothic (a Japanese font) as my secondary font. I have a Japanese locale set up and have tried setting LANG=ja_JP.utf8 before, but the results never change.
Also, this issue isn't just with this file. This happens with nearly all archives that have Japanese characters associated with it.
Has anyone encountered this issue before or knows what might be wrong?
Last edited by Sanbanyo (2015-05-21 03:12:56)

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)

Can't input Japanese characters into BrowserBasedHelp search

We're using RH 8.0.2.208 to create BrowserBasedHelp output for a client-side application. We have a different project for each language. In the Japanese language output, a user cannot enter Japanese characters into the search field using the Japanese keyboard; when you press the keys, nothing displays in the search field, but you CAN copy and paste Japanese characters into the search field and find results.
The Project Settings: Language setting is set to Japanese (Japan), and the properties in the generated HTML topic files are also set for Japanese.
Has anyone run into this before? I've searched and found a few topics with similar problems, but didn't see any replies or answers.

Hi,
I dont have japanese keyboard, but I tried the same with Japanese langauge bar installed with Microsoft IME. And I was able to type japanese characters in Browser based help.
thanks
Praful

Collation issue with Japanese characters in Oracle8i

Hi,
I have japanese data in a varchar2 column in an Oracle8i instance which contains both single byte and multibyte Japanese characters. The encoding type of the instance is UTF-8.
I want to sort them in such a way that equivalent single byte and multibyte Japanese characters are treated as same. Also while selecting, if I specify the single byte characters in the where condition it should select both single and double byte characters and vice-versa.
The functionality I'm looking for is similar to the one which can be achieved by using Collator class in Java with FULL_DECOMPOSITION as decmposition mode.
Could anyone please let me know how can I do it ?
Thanks in advance.
Best Regards,
Sourav

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)

Cannot write in Japanese characters on Firefox 7.0 using Mac OSX 10.5.8

Ever since I upgraded to Firefox 7.0, I cannot input Japanese characters into Firefox. I use a Mac OSX 10.5.8. I have my international settings such that I can write in this and other languages, but none come up other than English.
I can write in Japanese on Microsoft Word, Safari, and a slew of other applications, so it's definitely a Firefox issue.

The following worked for me:
http://support.mozilla.com/en-US/questions/684867
"Problem: I had the same problem but with mac osx 10.5.8, Firefox 3.6.6 sometimes prints and sometimes does not, but the preview was always blank and I could not save to pdf file.
Solution: I downloaded Firefox 3.5.10, installed it on my desktop and opened it, tried print preview and it worked, quit Firefox 3.5.10 and ran 3.6.6 and voila! print preview is working fine and I can save to pdf fine.
I guess running 3.5.10 fixes the profile in a certain way. I have no idea how that happened but it worked."

Can't input Japanese caharacters to Firefox 15

After update to firefox 15 I no longer can input Japanese characters from my keyboard to firefox.
I can input Japanese to Chrome, Explorer and other programs, except firefox!
I can copyJapanese characters from other programs to firefox with no problem but I can not write in firefox!!!
I have been using firefox for years and this is the first time to face such a problem

How do you normally switch to Japanese input mode?
Start Firefox in <u>[[Safe Mode|Safe Mode]]</u> to check if one of the extensions or if hardware acceleration is causing the problem (switch to the DEFAULT theme: Firefox/Tools > Add-ons > Appearance/Themes).
*Don't click the Reset button on the Safe mode start window or otherwise make changes.
*https://support.mozilla.org/kb/Safe+Mode
*https://support.mozilla.org/kb/Troubleshooting+extensions+and+themes

How to input japanese text in x11 and openoffice

I posted this question in the Mac OS section, but someone suggested that I post it here, too.
I recently installed X11 on my computer to run OpenOffice.org. Unfortunately, I can't figure out how to switch between languages. Normally, I use the hot keys shift-cmnd-space to toggle between languages, but on X11, it won't allow me to do that.
I don't know very much about X11, and I only downloaded it because I needed it to use OOo. OOo seems to have the easiest way to to input furigana characters when typing in Japanese, so it would make my life a lot easier if I could use OOo when creating Japanese documents. I'm not hellbent on using OOo, but the furigna input seemed easier to do than with Word (also, word has been crashing a lot lately, so I thought I'd try something else). If anyone out there uses a different program with furigana capabilities, I'd be open to hearing about that, too. Especially if it's easier to configure.
Either way, I still need to figure out how to get X11 to input different languages. Can I use the katoeri program in X11 to input Japanese characters? Do I need to install something else? I'd also like to be able to use French, so if I need to do something special for that, please let me know how to do that, too.
Also, if you couldn't tell, I don't know anything about computers, open source or codes. I don't have unix on my computer, but figured maybe someone here might be able to help me. Please be patient with my ignorance about all this stuff!
Thanks in advance

Either way, I still need to figure out how to get X11 to input different languages.
Not really. You wouldn't use X11 for anything other than OO I think.
Do I need to install something else?
Yes, after some more research it seems you need something called kinput2. You can search this forum for Japanese. Here is one item of possible interest:
http://discussions.apple.com/thread.jspa?messageID=5249892&#5249892
I'd also like to be able to use French,
No problem. You should be able to demonstrate that for yourself already, since it is the same as normal OS X apps. Do you know how to do that?
I don't have unix on my computer
Yes you do, OS X is based on Unix, and X11 requires it.
http://www.apple.com/macosx/technology/unix.html

Japanese characters alone are not passing correctly (passing like ??? or some unreadable characters) to Adobe application when we create input variable as XML data type. The same solution works fine if we change input variable data type to document type a

Dear Team,
Japanese characters alone are not passing correctly (passing like ??? or some unreadable characters) to Adobe application when we create input variable as XML data type. The same solution works fine if we change input variable data type to document type. Could you please do needful. Thank you

Hello,
most recent patches for IGS and kernel installed. Now it works.

Japanese characters are broken

The code below prints the Japanese text properly in both System console and in browser
<%@ page contentType="text/html; charset=Shift_JIS" %>
<html>
<body>
<form>
<%
request.setCharacterEncoding("Shift_JIS");
String value = request.getParameter("txtJapan");
System.out.println("Value : " + value);
out.println("Value : " + value);
%>
<input name="txtJapan" >
<input type="SUBMIT" />
</form>
</body>
</html>However the same code is not working (i.e. Japanese characters are not correctly displayed) when this Page is called thru faces servlet. I have also tried using JSF components on this page, but they too don't display as expected.
Even after setting the content type and charcter encoding to Shift_JIS in JSP page (using the page directive as shown in the code above), after passing thru faces servlet both request.getCharacterEncoding() and response.getCharacterEncoding() return "null" and "ISO-8859-1" respectively
I think due to this I am not getting the Japanese character properly in browser as well as in System console.
In order to work I have created a filter and set both the content type and character encoding.
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
     response.setContentType("text/html; charset=Shift_JIS");
     request.setCharacterEncoding("Shift_JIS");
     chain.doFilter(request, response);
}I don't know whether this approach is the right way or something has to be done in faces servlet itself.
I am also seeing another weird problem -- for the JSF command button if the label attribute value is "Go" then in the console I am getting the HTML encoded character (奈&#33391). But the browser automatically convert the encoded character and display Japanese character properly. However, when the label is anything other than "Go" both console as well as browser displays proper Japanese characters.

Heh, yeah, it's old topic and I wasn't really sure if somebody will reply to it, but I tried anyway.
I haven't come to issue of DB yet but I guess I'll as soon as I solve this one. I remember when I was using EA everything works so fine so I didn't pay any attention this time until some coworker told me.
I saw that filter and it's similar to mine which is unfortunately not working and I still have no ideas why.
Here's my filter code:
     public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws ServletException, IOException {
          System.err.println("Before: "+request.getParameter("form1:text1"));
          String encoding = "UTF-8";
          System.err.println("doFiler(): setting encoding to "+encoding);
          request.setCharacterEncoding(encoding);
          System.err.println("After: "+request.getParameter("form1:text1"));
          chain.doFilter(request, response);
When I enter string č�ćđ� and run it I get following to log
That's what I get in log file:
2004-09-01 15:08:16,264 INFO (EncodingFiler.java:33) => Before: ?????
2004-09-01 15:08:16,264 INFO (EncodingFiler.java:38) => doFiler(): setting encoding to UTF-8
2004-09-01 15:08:16,264 INFO (EncodingFiler.java:41) => After: ?????
but in JSP page I see ISO-8859-1. Any ideas?

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

How do I copy/paste Japanese characters from Word to ID CS5.5?

I'm using ID CS5.5 as my layout program and helping my girlfriend lay out a children's book she's working on. She's a Spanish professor at a local university. So far, we've done the text in English, Spanish, French, Portuguese, and German. But she also wants to provide the book in Japanese, so had one of her colleagues, who is from Japan, translate it and provided the translation to me in the body of an e-mail, which I copied and pasted into Word. However, when I pasted it into the InDesign layout, I get the pink boxes with the "x", indicating that particular font isn't installed. I understand this. I selected one of the Japanese characters and checked the info in Word, finding that it is CJK Unified Ideograph, character code 69D8, keyboard shortcut 69D8, Alt+x. Here is the character: 様
Here is one of the sentences in Japanese:
カルロスです。ぼくにはしんゆうがいて、ジャバリとジョッシュといいます。ぼくらはいつもいっしょにあそびます。みためはちがうけど、にているとこもたくさんあります
Is it absolutely impossible to accomplish our goal without having the particular Japanese typset installed on my system that he's using? It's showing up here and in Word. ????? I've done a search and did a lot of reading, but didn't find my exact issue, so just wanted to start fresh and hopefully get some helpful input. If this has been discussed before, I apologize, but didn't find it.
Thanks
DC

Your line breaks will most likely be incorrect if you don't turn on the Japanese Composer.
It is almost absolutely impossible to accomplish your goal without having a font - any font - installed on your system that has that glyph. However, if it's showing up in Word, than means that you must have that glyph installed, right? What font are you trying to use in InDesign? You might already know that Word will auto-substitute fonts when it encounters a missing glyph, so we really don't know what font is being used to render that one glyph. The whole sentence might be in MS Mincho but one glyph might be pulled from another font if MS Mincho doesn't have that glyph.
That being said, you're going to break it if you don't know how to set Japanese type in ID. It's not something where you can just copy text out of email and paste into your English layout.

[SOLVED] Qt Applications not recognizing japanese characters

When I run Qt applications (goldendict, anki) and open a file browser from within the application itself, file names with Japanese characters in them (醤字.txt) don't get read and the file is "invisible". I don't have any problems when I launch a file browser from the terminal or via cinnamon. I read the arch wiki page on Qt, but wasn't able to find anything that helped. Also, I have a thread about XTerm not reading Japanese characters or being able to take Japanese input, so, not sure if it's related or not. Any suggestions?
Thanks in advance!
Last edited by Bipolarbearz (2014-12-24 03:40:47)

Issue was with my locale settings. Full story here: https://bbs.archlinux.org/viewtopic.php … 0#p1486600 for anyone with the same issue.

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.

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.

Issue inputting japanese characters in sqlplus?

Similar Messages

Maybe you are looking for