How to determine the encoding

Question

In my web application , we are capturing arabic name and storing it in oracle database
// while saving
this.arabicDesc=new String(paymentTransactionTypeDetailVO.getArabicDesc().getBytes("ISO8859_1"),"UTF8") ;
// while retrieving from database
paymentTransactionTypeDetailVO.setArabicDesc(new String (arabicDesc.getBytes("UTF8"),"ISO8859_1"));In the jsp pages , we are using
In all the jsp pages , we are using
<META HTTP-EQUIV="Content-type" CONTENT="text/html; charset=UTF-8">All these values are coming correctly in our jsp pages. But when we tried to convert this arabic data to cp864 in an applet for printing , we are getting junk.Here we are not explictly converting the data but using printstream class like this. any idea why ????? is coming..
FileOutputStream fos =  new FileOutputStream("LPT1");  
PrintStream pw =  new PrintStream(fos,true,"Cp864");I checked the database also...
select * from nls_database_parameters
where parameter='NLS_CHARACTERSET';
NLS_CHARACTERSET     UTF8data is coming like this...
<object
  id="ReceiptPrinterApplet"
  classid="clsid:CAFEEFAC-0015-0000-0007-ABCDEFFEDCBB"
  width="0" height="0" >
   <param name="code" value="ReceiptPrinterApplet.class">  
   <param name="printermode" value="Broad">  
   <param name="Party Name1" value="KUANJIKOMBIL VARGHESE ALEXANDER (720216)- PO Box No:245">
   <param name="Party Name Arabic1" value="����� ������ ������ �������">
</object>Where could be the problem ? How can we resolve this issue. We need to convert to cp864 since the printer is supporting only cp864.

Answer 1

Unfortunately, based on your description of how you acquired the data, I believe you may be correct in saying that there is no generic solution. If your database is encoded in UTF-8, and you can confirm that the data is correct in the database, then you should be in reasonable shape - then it is a matter of figuring out where in your code you have some issues.
If, on the other hand, you determine that part of the data is corrupted in the database because if may have been incorrectly converted when it was stored, then it becomes much more difficult to figure out what to do with it, and how to correct it (if that is possible at all - if one of the conversions was to a target encoding where the source code point does not exist, then the data is lost forever).
Converting UTF-8 encoded data to 8859-1 is really only possible for a small subset of data (data actually in Latin-1 scripts), and there is no good reason to do it, unless it is part of an attempt to correct a previous incorrect conversion (and that should only be attempted with extreme caution, in my opinion).