WebUtil Using Client_Text_IO with Japanese chars

Hi, I am trying to use Client_Text_IO to read text file with Japanese characters in it. But it seems like Client_Text_IO can't read Japanese chars properly. Can anyone tell me how to use Client_Text_IO with double byte
chars like Japanese?
Thanks in advance for any help.
Tad Teramoto

Hi Frank,
Thank you for your reply. Could you be a bit more specific about what this bug 3075927 really is? Is this a problem only in handling files with muli-byte chars or does it have an effect on other functions? And is there any workaround for it?
Thanks

Similar Messages

ThrowNew() with Japanese chars went wrong

Hi All.
I want to throw exception that has Japanese chars from C++ code.
char szMsg[256];
// put Japanese chars into szMsg.
// ... and throw exception.
env->ThrowNew(exceptionClass, (const char*)szMsg);
Then, in Java code, it is displayed with unreadable characters like "????".
How can I get a readable string from C++?
Thank you.

Thank you for your reply.
But I'm not familiar with C++, could you tell me in detail?
My project is compiled with _MBCS option, and I tried to convert string to UNICODE to get readable string in JNI by using
(1) MultiByteToWideChar(...)
const char* szErrMsg = "...."; // including Japanese character
WCHAR szUnicodeMsg[256];
MultiByteToWideChar(GetACP(), 0, szErrMsg, -1, szUnicodeMsg,
sizeof(szUnicodeMsg)/sizeof(wchar_t));
env->ThrowNew(ExceptionCls, (const char*)szUnicodeMsg);
(2) mbstowcs(...)
mbstowcs(szUnicodeMsg, szErrMsg, strlen(szErrMsg)+1);
env->ThrowNew(ExceptionCls, (const char*)szUnicodeMsg);
(3) T2CW() macro
env->ThrowNew(ExceptionCls, (const char*)T2CW(szErrMsg));
Result
In case (1), unexpected string (like "B0D0F0H0J0?0") was displayed.
(by calling Throwable#getMessage() in JNI)
In case (2), only '?' was displayed in JNI.
In case (3), I got the same result as case (1).
Do you mean another way?
Thank you.

Issues with Japanese encoding using Mail

Since recently (I would say since I updated to 10.6), I have an issue with Japanese-encoded (ISO 2022-JP) mails on my English MacOS.
I have no problem to read, edit and write answers to any mails.
However with some ISO JP-2022-JP encoded messages (sent with Thunderbird 2.0.0.23 (Windows/20090812) btw) I have the following misbehaviour:
- if I send the message and let the encoding to "automatic", Mail sends the mail in UTF-8, which I do not want since most of Japanese computer do not understand UTF-8 by default (and the receiver gets panicked: "I can not read your mail T_T !")
- if I set the encoding to "ISO JP-2022-JP", I can not send nor save the message (see [1] at the end of the post). One should note that the error message when saving is really misleading (and yes my hard-drive has a lot of space left) and it should be fixed by Apple.
- if I dig a bit deeper, I can in effect find some characters in the original message which prevent Mail to send my mail. It however does not make any sense since:
- those char were in the original message properly encoded in ISO JP-2022-JP
- those char are always very common ones
The only solution I have found so far is to delete the original message in my mail, which is very frustrating...
A sample of such mail can be found at (I removed personal info. and the mail is about a drinking party):
- http://files.me.com/trouve.antoine/73w3w9
Help would be very appreciated.
Thank you very much.
Antoine
[1] I get the following error messages:
-> try to save:
*This message can’t be saved to the Drafts mailbox.*
The message contains one or more attachments that
are too large to be saved in the Drafts mailbox. Try
deleting some attachments.
->try to send
*Invalid Text Encoding*
Some characters in your message could not be
converted to the “Japanese (ISO 2022-JP)” text
encoding. Choose a different encoding from the
“Text Encoding” menu.

You can find out about the different versions here, for example:
http://en.wikipedia.org/wiki/ISO/IEC_2022
Thank you. I feel a bit stupid for not having looked in Wikipedia at first...
I sometime wonder how could such basic problem like charset not being solved after more than 40 years of computer science...
Here is a note that addresses that problem, but I don't think it works with 10.6. Might be worth a > try:
http://discussions.apple.com/thread.jspa?threadID=121808&tstart=60
Thank for the link.
It seems to still work: new japanese mails are now sent in "ISO 2022-JP-2".
However, for messages with the header explicitly specifying "ISO 2022-JP" (which should be "ISO 2022-JP-2" on my mac) it has no influence.
The only ways I see to solve this issue would be:
i) to force "ISO 2022-JP-2" for all mails (a bit too extreme)
ii) to force the use of "ISO 2022-JP-2" instead of "ISO 2022-JP", but I do not think such precise configuration is possible
This mess appears to be due to Thunderbird which seems to mix "ISO 2022-JP-2" and "ISO 2022-JP", but I do not have any working Thunderbird to test now...

Problem with special chars in BLOB datatype using contains keyword

Facing problem, when part searching with special chars in BLOB datatype. It is considering the non alpha-numeric chars as a separtor in a provided string
EX:
SELECT *
FROM RESUME_TEST P,grst_candidate d
WHERE d.candidate_id = p.candidate_id
AND CONTAINS(P.CAND_RESUME,'%VB.NET%',1) > 0
Strings: , VB.NET , PL/SQL AS/400 , C etc..
Followed the below approaches
1) created a table:
Syntax: create table resume_Test(cand_id number(10),cand_resume blob);
2) inserted the values into this table upto 60,000
3) created a context index
3.1 created preferences
Syntax:
BEGIN
ctx_ddl.create_preference('try_lexer3','BASIC_LEXER');
ctx_ddl.set_attribute('try_lexer3','printjoins','-_~!@#$%^&*(){}[],=?\;|><.+');
END;
3.2 created context index
Syntax:
CREATE INDEX CANDRESUME_CTX_IDX ON resume_test (cand_resume)
INDEXTYPE IS CTXSYS.CONTEXT
PARAMETERS ('LEXER try_lexer3 memory 500M');
4) while executing this index, it is taking much time approx 6 hrs(plz explain why it is taking time)
5) Problems:
5.1 when searching with string(VB.NET , PL/SQL AS/400 , C etc..) it is considering the special char as a separator
5.2 used escape char (\) also, but no effect
5.3 when searching with single char, it is giving error (ORA-29902,ORA-20000,DRG-51030)
5.4 getting the above error with wild card chars (& ,_, (),{},[])
So, please explain the clear scenarios, why am getting this error , and how to get the proper results.

Have you tried adding the / char to the printjoin characters?
Indexing can take a lot of time, depending on the amount of data and your machine's power. You could try to parallelize the index creation and / or assign more memory
CREATE INDEX CANDRESUME_CTX_IDX ON resume_test (cand_resume)
INDEXTYPE IS CTXSYS.CONTEXT
PARAMETERS ('LEXER try_lexer3 memory 2000M') PARALLEL 8;

Use Forms with webutil with java plug

I am using oracle 9i forms with webutil, it works with jinitiator but I have problem runiing with java plug-in. I have changed formweb.cfg as follow. It des not work.
It works on oracle 10g rel1 appserver using jinitiator but does not work with java plug.
jpi_classid=clsid:8AD9C840-044E-11D1-B3E9-00805F499D93
jpi_codebase=http://java.sun.com/products/plugin/autodl/jinstall-1_4_2-windows-i586.cab#Version=1,4,2,0
jpi_mimetype=application/x-java-applet;jpi-version=1.4.2
webUtilArchive=/forms90/webutil/webutil.jar,/forms90/webutil/jacob.jar
baseHTMLJInitiator=basejpi.htm

see
Webutil using JAVA plug
Good thing to start using JRE anyway ;-)
Erwin

How to use CLIENT_TEXT_IO more fast?

Hello,
I'm using new features for Forms 10g like WebUtil, but I can't fine work with file manipulation - CLIENT_TEXT_IO.
The loading of the text file with 7mb size, delay 15-30 minutes, is not good.
I like know one other way for this works more fast, anybody help me?
I tried using Java for replace WebUtil commands (CLIENT_TEXT_IO), but, my java class, works as a client program. I accept others forms to resolve this problem, but, I look for solutions using WebUtil, if is possible.
Thanks in advanced.

It seems the implementation of CLIENT_TEXT_IO is not optimal, refer to the webutil manual for performance improvement.
http://www.oracle.com/technology/products/forms/htdocs/webutil/web_util.pdf - page 6-1.
Use functions in an efficient manner. For instance if you need to read a text file on
the client computer, it will probably be more efficient to transfer the file to the
users’s work area using WebUtil_File_Transfer and then read it with normal
TEXT_IO, rather than reading it line by line across the network

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)

Problem in working with Japanese data

Hello,
We have an application, which should work for both English and Japanese languages. Our application is working fine for English data but in case of Japanese, we are facing problems. In the application, there is a language setting, where the user can select either English or Japanese. This changes the language of the labels to English or Japanese. We are handling this thru' ResourceBundles. But the data that is entered can be independent of this. In English setting also, the data entered or diplayed could be Japanese. Now we are facing problems at vaious places -
1. When we enter Japanese data and save it, it gets copied into the bean and if there is any error in the saving, the same data from bean comes back on the screen. This data doesn't appear properly in Japanese.
2. When we try to retrieve the already saved data from database, it doesn't show poperly in Japanese.
We are using our own 'toUnicode' function, which converts the data to Unicode before saving the data to database. Similarly, we have tried different encodings like SJIS / Shift_JIS / ISO-2022-JP at various places i.e. in 'Page' directive or in HTML Meta tag or various combinations of these two. Nothing is working reliably. Sometimes for some combination, data retained in the first case is correct but it can't be saved. Sometimes it works with Unicode, sometimes without Unicode. Some combination affects the Japanese labels as well. Otherwise the labels at least are displayed properly.
The same code with just Shift_JIS setting in 'page' directive, worked well in IIS Server for both English and Japanese.
What could be the problem in WebLogic? Does it matter if WL is installed on English or Japanese machine?
Kindly answer ASAP, since the project is getting delayed.
Thanking in anticipation...
-Medha

Hi,
is there a difference in handling Japanese and Chinese chars? If not I
might be able to give you some hints.
Daniel
-----Original Message-----
From: JSB [mailto:[email protected]]
Posted At: Monday, February 12, 2001 6:22 PM
Posted To: internationalization
Conversation: Problem in working with Japanese data
Subject: Re: Problem in working with Japanese data
Have u solved this yet, and how ?
Medha <[email protected]> wrote in message
news:[email protected]...
>
Hello,
We have an application, which should work for both English andJapanese
languages. Our application is working fine for English data but in case
of
Japanese, we are facing problems. In the application, there is a
language
setting, where the user can select either English or Japanese. This
changes
the language of the labels to English or Japanese. We are handling this
thru' ResourceBundles. But the data that is entered can be independent
of
this. In English setting also, the data entered or diplayed could be
Japanese. Now we are facing problems at vaious places -
1. When we enter Japanese data and save it, it gets copied into thebean
and if there is any error in the saving, the same data from bean comes
back
on the screen. This data doesn't appear properly in Japanese.
2. When we try to retrieve the already saved data from database, itdoesn't show poperly in Japanese.
We are using our own 'toUnicode' function, which converts the datato
Unicode before saving the data to database. Similarly, we have tried
different encodings like SJIS / Shift_JIS / ISO-2022-JP at various
places
i.e. in 'Page' directive or in HTML Meta tag or various combinations of
these two. Nothing is working reliably. Sometimes for some combination,
data
retained in the first case is correct but it can't be saved. Sometimes
it
works with Unicode, sometimes without Unicode. Some combination affects
the
Japanese labels as well. Otherwise the labels at least are displayed
properly.
The same code with just Shift_JIS setting in 'page' directive,worked
well in IIS Server for both English and Japanese.
What could be the problem in WebLogic? Does it matter if WL isinstalled on English or Japanese machine?
Kindly answer ASAP, since the project is getting delayed.
Thanking in anticipation...
-Medha

Japanese chars display in Solaris 8

I have a sun box with solaris 8 and Windows NT. I had FTP a notepad file containing japanese text from windows NT to the Solaris Environment but whenever the file is opened in solaris using editors like vi or dtpad, some special characters appear in place of japanese chars. I have also tried :-
-- FTP the file in binary form from windows to solaris
-- Changing the "locale" value to ja_JP.UTF8
-- Changing the language option to en_US.UTF8 at the login screen.
But the problem still persists. Kindly help me out.
Atul

UTF8 will make your head melt.
setenv LANG ja_JP.eucJP
sjtoeuc FILE
(I use mutt in japanese on solaris all the time and most of my mail is in japanese ^^;;)

Zip.ZipInputStream cannot extract files with Chinese chars in name

Dear friends,
Peace b upon u!
I am trying to read a zip file (~3000 files)containing one
or more files with Chinese, Japanese or Korean names, the
getNextEntry method throws an IllegalArgumentException as below after extracting just ~300 files as below:-
java.lang.IllegalArgumentException
        at java.util.zip.ZipInputStream.getUTF8String(Unknown Source)
        at java.util.zip.ZipInputStream.readLOC(Unknown Source)
        at java.util.zip.ZipInputStream.getNextEntry(Unknown Source)
        at testZipFiles.getZipFiles(testZipFiles.java:65)
        at testZipFiles.main(testZipFiles.java:18) issue:java.util.zip.ZipInputStream cannot extract files with Chinese chars in name
Category java:classes_util_jarzip
Plz let me know 1 of the ways which I can solve this issue.
1)if someone has JAVA DCOMPILER plz send the SOURCE Code
for the ZipInputStream.class to me..I need to edit it using 1 of the solutions as provided below which I googled.
2)If there is an alternate or upgraded java.util.zip.ZipInputStream or any org.apache.tools.zip.* package which can read such files..If yes where I can download the same on net.
3)Any other easier solution, which can let me extract all files (by excluding Chinese files thru CATCH) without the extractor process to fail altogether.
On net I found that the only solution with this is:-
- edit the new ZipEntry, remove the static initializer that calls
the native methods initIDs().
this step seems a bit scary, but it's according to the
workaround
to bug #4244499 (the workaround of Olive64, THU JUN 05
01:55 P.M. 2003),
that handles a similar bug at the ZipOutputStream.
Now you have a ZipInputStream that supports multi-bytes
entry names.
to extract the zip file, using the fixed code that is offered
above,
create a function that gets an "encoding" string, a "destPath"
string
and a "sourceFile" (zipped) and does :
ZipInputStream zipinputstream = null;
ZipEntry zipentry;
zipinputstream = new ZipInputStream(new FileInputStream
(sourceFile),encoding);
zipentry = zipinputstream.getNextEntry();
while (zipentry != null) { //for each entry to be extracted
    String entryName = zipentry.getName();
    int n;
    FileOutputStream fileoutputstream = new FileOutputStream
( destPath + entryName );
    while ((n = zipinputstream.read(buf, 0, 1024)) > -1)
        fileoutputstream.write(buf, 0, n);
    fileoutputstream.close();
    zipinputstream.closeEntry();
    zipentry = zipinputstream.getNextEntry();
}//while
zipinputstream.close();

Hi friend,
We'd better to ask one question in each thread. If you have another issue, you can consider to open up a new thread in this forum.
Now for the first question, do you mean this picture? It throws access exception in archive2.
If so , because your extractPath is a path, not a directory.You should add +"xxx.zip". For more information, please refer to
ZipFile.Open
Method (String, ZipArchiveMode).
For the second question, you can use the following code to skip the error message.
while (true)
try
//do something;
catch (Exception ex)
{ continue; }
Good day!
Kristin
We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
Click
HERE to participate the survey.

RFC SDK, connect with japanese username to a unicode SAP system

Hello everybody,
I try to connect with a japanese username to a unicode SAP system. I use VC++ and make the call like this:
     BYTE utf8_byteArray[10] = {0xE3, 0x81, 0x8A, 0xE3, 0x81, 0x99, 0xE3, 0x81, 0x99, 0x00 };
     CString sJapUser(utf8_byteArray);
     sConnectParam.Format( cU("CLIENT=%s USER=%s PASSWD=%s LANG=%s SYSNR=%d ASHOST=%s PCS=2"),
                         "800",
                         sJapUser,
                         "password",
                         "EN",
                         1,
                         "9.22.104.145");
     hRfc = ::RfcOpenEx( (char*)(LPCTSTR)sConnectParam, &error_info);
I tried it with different codepages and PCS settings (1/2) too but i always get the error:
"Name or password is incorrect (repeat logon)"
When I connect to a non unicode japanese system in locale encoding it works.
Another thing i saw is that the utf8 string is truncated after 12 bytes (12 character/bytes is the limit of user name length). When I use a japanese username with 6 japanese symbols (18 bytes in utf8) I see the following in the RFC trace:
rfcOpenHooked
    destination             <unknown>
    mode                    3
    conopt 3 hostname       9.22.104.145
    conopt 3 sysnr          1
    conopt 3 use_l_bal      0
    conopt 3 use_sapgui     0
    client                  800
    user                    おすすめ (here the username misses 2 japanese characters)
    language                E
    trace                   0
L-GetCodePage (DEFAULT-CP) rc = 0: 1100
Here the username is correct:
>>> RfcOpenEx ...
Got following connect_param string:
   CLIENT=800 USER=おすすめダウ PASSWD=******* LANG=EN SYSNR=1 ASHOST=9.22.104.145 CODEPAGE=4110 PCS=2
Send RFCHEADER: 01/LIT/IEEE/SPACE/4110
Send UNICODE-RFCHEADER: cp:4110/ce:IGNORE/et:5/cs:1/rc:0x00000023
In the RFC trace the username is truncated (only 12 bytes(4 characters) instead of 18 bytes (6 characters))
000160 | 44657369 676E0130 0111000C E3818AE3 |Design.0........|
000170 | 8199E381 99E38281 01110117 000C905F |..............._|
000180 | E417BBAC 1DDD543E CE540117 01140003 |......T>.T......|
To connect with japanese usernames using the SAP-GUI works fine but the rfc traces show that the connection is established in another way.
Can anyone help me with this or is it just impossible to use japanese usernames for logon with RFC.
Thank you in advance.

Please note the header of this forum: "This forum is dedicated to all other development-related questions which are not directly addressed by other forums. This includes Business Objects SDKs, products, or technologies which do not fall under BusinessObjects Enterprise, BusinessObjects Edge, Crystal Reports Server, or Crystal Reports (for example Desktop Intelligence SDK, Universe Designer SDK, Portal Integration Kits, Java User Function Libraries, and other third party technologies or development languages). "
I do not think you are using any of the products described above. Please post to the correct forum.
Ludek

Form English Char ( Single Byte ) TO Double Byte ( Japanese Char )

Hello EveryOne !!!!
I need Help !!
I am new to Java ,.... I got assignment where i need to Check the String , if that string Contains Any Non Japanse Character ( a~z , A~Z , 0 -9 ) then this should be replaced with Double Byte ( Japanese Char )...
I am using Java 1.2 ..
Please guide me ...
thanks and regards
Maruti Chavan

hello ..
as you all asked Detail requirement here i an pasting C code where 'a' is passed as input character ..after process it is giving me Double Byte Japanese "A" .. i want this to be Done ..using this i am able to Convert APLHA-Numeric from singale byte to Doubel Byte ( Japanse ) ...
Same program i want to Java ... so pleas guide me ..
#include <stdio.h>
int main( int argc, char *argv[] )
char c[2];
char d[3];
strcpy( c, "a" ); // a is input char
d[0] = 0xa3;
d[1] = c[0] + 0x80;
printf( ":%s:\n", c ); // Orginal Single byte char
printf( ":%s:\n", d ); // Converted Double Byte ..
please ..
thax and regards
Maruti Chavan

Read japanese char from oracle

I have a database column stores japanese char in Shift-JIS encoding. A
perl script can read the database and display the result on browser.
But If i try the get the japanese string in Java using JDBC. I got an
exception:
String text = resultset.getString(1);
Exception in main(): java.sql.SQLException: Fail to convert between
UTF8 and UCS2: failUTF8Conv
I wonder why I getting this exception and how to fix this?
thanks

Hi
We had faced the same problem.
Problem was with oracle jdbc thin driver.
We change the driver from THIN to OCI that works fine.
Try this option and pls let me know.
Regards,
Aslam A.S

German Umlaute don't work after upgrading to Yosemite with Japanese Romaji Layout set on U.S.

Hi everyone,
previously i could just use [ALT] + [U] and then press [A] / [a] / [U] / [u] / [O] / [o] to generate the german umlaut version.
After installing Yosemite this does not work anymore, which is kinda frustrating. Cause it forces me to add another keyboard layout and switch when i have to write a german umlaut.
I was previously using 'Input Source' > 'Japanese' > Enabled Romaji (Romaji layout was set to U.S.) & Hiragana.
For testing purpose i added the Standard U.S. Layout and writing the Umlaut with the keyboard shortcut still works there. So that's why i think this is a Romaji specific bug.
Has anyone any idea what's wrong ? Did Apple change something ?
Best Regards

Before I stumbled upon this thread, there was no flag at all. I had the character viewer there because pre-Yosemite it was the only way to access emoji (and things like arrows and other special symbols) in many apps (and still is for my Adobe CS5 apps). Additionally, I would use the keyboard viewer from time to time as a way to learn which keys to use for other special symbols (bring up the keyboard viewer and press option or shift-option or other combinations and it would show you a preview of what each key would generate).
While reading this thread, I added more input sources (US International and US Extended) and would see the flags. The flags replaced the previous character/keyboard viewer menu icon. I switched between each flag to test my issue under each, to no avail. Then I tried adding the Spanish keyboard but still had the same issue.
Now I've removed all the input sources except the primary US keyboard. There is no longer a flag in my menu, it's gone back to the character viewer icon.
The issue is still there. When I type option-r, u, or g, in any app nothing happens at all.
Unfortunately, neither auto-substitution nor press-and-hold work in Adobe CS5 apps, which is where I need to use these special characters the most.
Thank you for reaching out

Bug report: A keyboard layout is incorrect on the remote with Japanese keyboard

This is a bug report for Microst Remote Desktop
===================================================
## Summary
A keyboard layout is incorrect on the remote with Japanese keyboard
## Version Information, I tested
* Client
   * Case 1
       * MacBook Pro with JIS106 Keyboard
       * Mac OS X Lion 10.7.5
       * Microsoft Remote Desktop 8.0.24308
   * Case 2
       * MacBook Pro with JIS106 Keyboard
       * Mac OS X Mavericks 10.9.1
       * Microsoft Remote Desktop 8.0.24308
* Remote
   * Case 1
       * Windows 7 Professional Japanese
   * Case 2
       * Windows Server 2008R2 Datacenter Japanese
   * Case 3
       * Windows Server 2012R2 Datacenter Japanese
## Detail of bug
When login from Mac OS X with Microsoft Remote Desktop, the keyboard layout is always incorrect on the remote.
The client machine have a built-in keyboard of JIS 106 layout,
and the primary language is set to Japanese.
But on the remote, the keyboard layout is US 101.
So a input of Shift+2 does not result " but @.
I've seen the above behavior on the 3 remote enviornments described the above.
This bug did not occcur with Microsoft Remote Desktop Connection Client for Mac 2.1.1, even if the system language is English and keyboard layout is Japanese.
## Captures
I've took some of screen captures.
I'm sorry for the capture includes Japanese words, so I added description in English.
Capture 1:
Mac OS X Keyboard Setting
Capture 2:
Windows Server 2012R2 Screen Keyboard
Capture 3:
Windows Server 2012R2 Screen Keyboard, with a additional registry key configured.

This bug also affects the Canadian English settings. If the client is set to Canadian English with a US keyboard the remote server is setup using a Canadian French keyboard. Using the language selection in the toolbar you can temporarily correct
the problem but the keyboard resets to french at the most inopportune times. The was a problem in the earlier RDP client and was fixed so it's sad to see it reoccur in the new client.
Lawrence

WebUtil Using Client_Text_IO with Japanese chars

Similar Messages

Maybe you are looking for