• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 436
  • Last Modified:

Foreign characters

I can type Russian, Hebrew etc into a JTextField and JTextArea and they display ok, but sending the strings over a socket seems to destroy them and they become question marks. What readers / writers / streams are best to use in this case?
0
afterburner
Asked:
afterburner
  • 12
  • 7
  • 4
  • +1
3 Solutions
 
objectsCommented:
use a Writer and check the problem isn't with whats reading the data at the other end.
0
 
afterburnerAuthor Commented:
At the other end is always a buffered reader that reads the string. Or would the problem be in something else?
0
 
objectsCommented:
check the encoding being used
and is the oher end using a font that supports the characters being sent?
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
afterburnerAuthor Commented:
I tried sending the string as a string captured from the JTextField (JTextField.getTExt();), then tried it as a new String using UTF, UTF-8, UTF-16, UTF-16BE, UTF-16LE, etc., and none of these worked, although with 16BE I think it was, the displayed return string looked a bit more promising, as it was not simply question marks, but I guess this is neither here nor there.

As I am using loopback, yes, the 'other end' is also using a font that supports the charset.
0
 
Al-KhwarizmiCommented:
When you instance your BufferedReader, be sure to pass it a Reader object configured with the encoding you're used.

As in

myReader = new BufferedReader ( new InputStreamReader ( myInputStream , "UTF-16" ) );
0
 
CEHJCommented:
>>and they become question marks

Where?
0
 
afterburnerAuthor Commented:
>> be sure to pass it a Reader object configured  ...

that sounds like a good idea - I will try that.

>> Where?  ...

in the displaying JTextArea which receives the returned string.
0
 
CEHJCommented:
>>in the displaying JTextArea which receives the returned string.

That's OK then

>>that sounds like a good idea - I will try that.

Let us know if it doesn't work. Use UTF-8 unless you have a specific reason not to
0
 
afterburnerAuthor Commented:
>> Use UTF-8 unless you have a specific reason not to ...

Does the printerwriter *and* the reader have to be configured with the encoding?
0
 
Al-KhwarizmiCommented:
If you use a PrintWriter too, the situation is similar:

PrintWriter myPrintWriter = new PrintWriter ( new OutputStreamWriter ( myOutputStream , "UTF-16" ) );

would be a good match for the reader above, if the input and output streams are connected as is the case with a socket.
0
 
CEHJCommented:
>>Does the printerwriter *and* the reader have to be configured with the encoding?

Readers/Writers have to match encoding-wise
0
 
afterburnerAuthor Commented:
OK, it will take me a little while to change things. Two small points meanwhile  - why do you mention UTF-8 and AL-Khwarizmi UTF-16 ? ; and secondly, will the encoding still allow the transport of ASCII chars as is the case with the existing Printwriter and Reader that I'm using?
0
 
CEHJCommented:
>>why do you mention UTF-8

It's the most economical way of transmitting Unicode

>>will the encoding still allow the transport of ASCII chars as is the case with the existing Printwriter and Reader that I'm using?

Yes - 'ascii' is a subset of Unicode
0
 
afterburnerAuthor Commented:
That's it. Thanks 4 ur help(s).
0
 
CEHJCommented:
8-)
0
 
Al-KhwarizmiCommented:
I only mentioned UTF-16 as an example, sorry if that confused you. UTF-8, as CEHJ says, is probably a better option in your case. UTF-16 is more suited for heavy use of Asian languages, where it can save space.

Although I don't think you need it, if you want to learn more about unicode formats you can check http://www-106.ibm.com/developerworks/library/utfencodingforms/index.html?dwzone=unicode
0
 
afterburnerAuthor Commented:
>> UTF-16 is more suited for heavy use of Asian languages ...

in fact, that is exactly where it comes in - but at least I know now, and appreciate your help v. much.
0
 
CEHJCommented:
>>
UTF-8, as CEHJ says, is probably a better option in your case. UTF-16 is more suited for heavy use of Asian languages, where it can save space.
>>

Yes you're right. That comment of mine could have been quite misleading. I think it's better to say UTF-8 is more economical when there are mixed 'ascii' and higher characters
0
 
afterburnerAuthor Commented:
Tell me if I need to open another question for this, but I have been trying it now with Japanese and Korean, and all I get are little squares in the JTextArea and JTextFields. Would any of you have anything to say on that? It's these languages - plus Chinese  - that I need in particular.
0
 
objectsCommented:
> and all I get are little squares in the JTextArea and JTextFields.

Are you using a font that supports the characters being used?
0
 
afterburnerAuthor Commented:
>> Are you using a font that supports the characters being used?


I am, because I can type Japanese into Word - although I admit I am not sure of the role of IME in this, and fear it may be some kind of a 'closed interface', just for M$ purposes, which Java can't share.

0
 
objectsCommented:
Is the same process involved transferring the string, and if so what encoding are you using.
0
 
afterburnerAuthor Commented:
Yes, it is the same process exactly. I tried with UTF-8 first and it didnt work so I tried UTF-16LE for no good reason :) which of course didnt work either.
0
 
afterburnerAuthor Commented:
I think (but I am not sure) that I might have seen another choice apart from IME when installing the Asian support; if that's the case should I unistall IME and try another one?
0
 
afterburnerAuthor Commented:
Ah, sorry, my comment about using a Font that supports Jap may not be right exactly, since I might of course not be using the same one in Word as I am in the Java app JTextField. Should I check that or is it a red herring?
0
 
CEHJCommented:
You need to do something like:

textField.setFont(new Font("Batang", Font.PLAIN, 12));
0

Featured Post

Become an Android App Developer

Ready to kick start your career in 2018? Learn how to build an Android app in January’s Course of the Month and open the door to new opportunities.

  • 12
  • 7
  • 4
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now