Non-ANSI characters in Java

class test {
     public static void main (String[] args) {
          System.out.print("새");
}Is it possible to print non-ANSI characters like the above? Since obviously saving this code in ANSI will remove the non-ANSI characters.

The code you posted runs OK on my computer - both in Eclipse and in the console. It prints a character somewhat like a rugby player about to attempt to convert a try.
Korean, I think.
Anyway Google thinks so. It directed me to this web site which has the character as its page title. www.woorimal.net/hangul/hyundai-poem/sae.htm
The poem in question has the English title "New".
1
Non covered the sky
Both divers ability of the wind
Come Athens
Both the shade of trees, birds
Sing. It is patterned knowledge of the line
It is knowledge of the bird line 19
Two Judgment beak,
Two die in the ward
Warm temperatures (体温) divide.
2
Bird uleo
Rather than creating it.
Presented gyotae (娇态)
Love is the expression (假饰).
3
--- Catcher Schneider is a cracker
As a pure (纯粹) targets, but
It is meant shooting
A wet blood saee nothing more than a virtual (伤)

Similar Messages

  • Non-English characters

    Hello, I have read several times that since Java uses Unicode, it solves the problems of non-English characters automatically or something like that.
    But my app is not working as expected. Would someone help please?
    I have a client/server combo written in Java. The server can send messages in English or Japanese. The Japanese messages are hard-coded as String literals in the server source code. On the client side, they are displayed on a JEditorPane. But the Japanese characters are all garbled. The OS on the server side and client side are, of course, different.
    My supposition, which is obviously wrong as it is not working, is that since both ends of communication are Java app, I need not worry about any encoding conversions for String literals.
    Suggest me what is wrong here?

    How is the required encoding/decoding supposed to be done?
    When I didn't worry about non-English characters, I did the following, which WORKED.
    // SENDER side
    Socket socket ;
    PrintWriter     out = new PrintWriter(socket.getOutputStream(),true);
    String outMessage = "my message";
    out.println(outMessage);//RECEIVER
    Socket socket ;
    BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream()));
    String inMessage =  in.readLine();When non-English characters are involved, I did the following, which DID NOT WORK. Please someone correct me.
    // SENDER side
    Socket socket ;
    PrintWriter     out = new PrintWriter(socket.getOutputStream(),true);
    String outMessage = "my message";
    String utfString = new String(outMessage.getBytes(),"UTF-8");
    out.println(utfString);//RECEIVER
    Socket socket ;
    InputStreamReader ins = new InputStreamReader(clientSocket.getInputStream(),"UTF-8");
    BufferedReader in = new BufferedReader(ins);
    String inMessage =  in.readLine();The received message is still garbled.

  • Non-English characters processed correctly by XML Parser 2 XSLT?

    I'm trying to transform an XML document (parsed as an XMLDocmument) using an XSL stylesheet (parsed as an XSLStylesheet) and the XSLProcessor class in Java, I encounter the following problem:
    Non-US characters such as German umlauts, stored in the XML in &#xxx; style, are not processed properly. "|" (&#252;), for example, comes out as "C<". Is this a bug in the XSLProcessor class or am I doing something wrong? I'm using this stylesheet declaration:
    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml1/strict"> Or should I mess with the encoding attribute of the ?xml ...? PI?
    tia
    John Smith

    I have not specified any encoding.
    <?xml version="1.0"?>
    <?xml-stylesheet type="text/xsl" href="completeproduct.xsl"?>
    <PRODUCT connection="demosample" xmlns:xsql="urn:oracle-xsql">
    <xsql:query>
    select * from products
    </xsql:query>
    should i specify encoding
    null

  • Odd number of non-english characters get broken in windows-chrome and ff

    I developed jnlp applet which prints out the user input.
    When I put odd number of non-english characters(eg: chinese), chrome and firefox browser prints out the last character as question mark.
    input : 가
    output : 가��
    I checked on java console that the character is correct.
    It must be bug in communication of applet to chrome browser.
    IE prints out correctly.
    I can resolve the issue by appending white space on applet and remove it on java script.
    Anyone has any clue on the issue?
    Codes are as follows.
    MainApplet.Java
    public class MainApplet extends JApplet implements JSInterface{//, Runnable {
         public int stringOut(String sData) {
              OutData = sData;
              return 0;
    js File
    function TSToolkitRealWrapper ()
         var OutData;
         var OutDataNum;
    var TSToolkit = new TSToolkitRealWrapper();
    var attributes = { id:'TSToolkitReal',code:'tradesign.pkitoolkit.applet.MainApplet', width:100, height:100} ;
    var parameters = {jnlp_href: getContextPath() + '/download/pkitoolkit.jnlp',
                         separate_jvm:true, classloader_cache:false} ;
    TSToolkitRealWrapper.prototype.stringOut=function(str)
              var      nRet = TSToolkitReal.stringOut(str)     ;
              this.OutData= TSToolkitReal.OutData;
              return      nRet;
    HTML
    <SCRIPT language=javascript>
    <!--
    function StringOut(form)
         var data = form.data.value;
         var nRet = 0;
         var base64Data;
         nRet = TSToolkit.stringOut(data);
         if (nRet > 0)
              alert(nRet + " : " + TSToolkit.GetErrorMessage());
         else
              form.data1.value = TSToolkit.OutData;
    -->
    </SCRIPT>
    Edited by: user13496918 on 2013. 3. 20 오후 7:29
    Edited by: user13496918 on 2013. 3. 20 오후 7:39
    Edited by: user13496918 on 2013. 3. 20 오후 9:17
    Edited by: user13496918 on 2013. 3. 20 오후 9:18

    I checked on java console that the character is correct.So it isn't a Java problem.
    It must be bug in communication of applet to chrome browser.So tell the people who make the Chrome browser.
    IE prints out correctly.That's a change. I've just spent nine days tracking down an IE applet problem and I'm not finished yet.
    Please omit the boldface next time. We can read. Boldface doesn't help; it makes it worse.

  • Encrypting non-English characters

    Hi,
    I have this application which has to do the following
    Scenario (i)
    - Read ENCODED string SE from Network Source NS1 (Native,Non-JAVA)
    - Decode SE to SD using the same charset as NS1
    - Apply some transformation to SD to get SD2
    - Encode SD2 to get SE2 using the same charset as Network Source NS2
    (Native, Non-JAVA)
    - Send SE2 to NS2
    - NS2 gets what it expects without any problems :))
    Scenario (ii)
    - Read ENCODED string SE from Network Source NS1 (Native,Non-JAVA)
    - Decode SE to SD using the same charset as NS1
    - Apply some transformation to SD to get SD2
    - Get the bytes from SD2 as BSD2
    - Encode BSD2 to get BSE2 using the same charset as Network Source NS2
    (Native, Non-JAVA)
    - Encrypt BSE2 to BSE2_Enc
    - Send BSE2_Enc to NS2 (Native,Non-JAVA)
    - NS2 does not gets what it expects :((
    (It recieves English text OK but it gets ???? for non-English)
    The charset being used is windows-1256 (at NS1,NS2 and my application)
    Encryption is being done using BouncyCastle TwoFish w/ 256 bit keys
    Reading/Writing from/to network is being done over SocketChannel
    Get the bytes from SD2 as BSD2 => byte [] BSD2 = SD2.getBytes()It seems the non-Enlish characters are getting lost when I go SD2.getBytes()
    and they get encrypted as 'lost-non-English characters' ;)
    And when they get decrypted at NS2, they are displayed as 'lost-non-English
    characters' :)) i.e. ??????? .. so on
    Is there a way I can encrypt non-English plain text without losing information ?
    (without having to implement a TwoFish engine in my application itself)

    1) Bytes are not characters. Characters are UNICODE
    and have a byte representation defined by an encoding
    scheme. It is usually wrong to use the default
    encoding given by String.getBytes(). One should realy
    use String.getByte(encoding) eg
    "fred".getBytes("UTF-8");Awwllright ... got that :)) Thanks buddy
    2) Not having access to your code makes it difficult
    but make sure you are not converting encrypted bytes
    to a String using new String(encrypted bytes); No .. I am not doing that.
    3) Again, not having access to your code makes it
    difficult , but when you display your Strings make
    sure that you use a Font that has representations for
    all the UNICODE characters you wish to display. It is
    normal for any character that does not have a valid
    glyph in a gien font to display as a box.That infrastructure exists and is working fine ... as I mentioned
    this is working OK when plain text is being used.
    The problem was with using the getBytes() rather than getBytes("windows-1256")
    Its working now ... thanks alot .. again. I wonder how that never occurred to me.

  • Non latin characters in .cfm filename

    Hi - I have users who want to name files with non latin characters.  i.e.
    Логотип_БелРусь_2500x1.cfm
    We get a file not found error, it is not an IIS issue and we have UTF-8 encoding and are running CF8.
    Yes we can rename the files but for now would like to know if non latin characters are allowed in .cfm file names.
    Thank you!
    Sapna

    PaulH wrote:
    en_US is the JRE locale. is that the same as the OS? and what file encoding?
    (check via cfadmin).
    i ask, because pretty sure you can't use non-ascii file names w/cf. there's an
    open bug on that:
    http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#bugId=77177
    only can guess that file encoding isn't latin-1, etc. and/or OS locale equals
    the same language as the file name.
    cfadmin gives pretty much the same information. Here's a direct copy
    Server Product
    ColdFusion
    Version
    9,0,0,241018  
    Edition
    Developer  
    Serial Number
    Operating System
    Windows 2000  
    OS Version
    5.0  
    Update Level
    /C:/ColdFusion9/lib/updates/hf900-78588.jar  
    Adobe Driver Version
    4.0 (Build 0005)  
    JVM Details
    Java Version
    1.6.0_12  
    Java Vendor
    Sun Microsystems Inc.  
    Java Vendor URL
    http://java.sun.com/
    Java Home
    C:\ColdFusion9\runtime\jre  
    Java File Encoding
    Cp1252  
    Java Default Locale
    en_US  
    File Separator
    Path Separator
    Line Separator
    Chr(13)

  • SetMnemonic for non-english characters

    Does anybody knos how to set JButtons mnemonic for non-english characters?
    My mnemonic is loaded from a resource bundle, and in the documentation the setMnemonic(char) is only limited to english and it is written that the user should call setMnemonic(int) instead.
    So what value should this int contains in order to display the non-english char which is loaded from resource bundle?
    Thanks in advanve,
    Hanoch

    It seems that this is an issue that has popped up in various forums before, here's one example from last year:
    http://forum.java.sun.com/thread.jspa?forumID=16&threadID=490722
    This entry has some suggestions for handling mnemonics in resource bundles, and they would take care of translated mnemonics - as long as the translated values are restricted to the values contained in the VK_XXX keycodes.
    And since those values are basically the English (ASCII) character set + a bunch of function keys, it doesn't solve the original problem - how to specify mnemonics that are not part of the English character set. The more I look at this I don't really understand the reason for making setMnemonic (char mnemonic) obsolete and making setMnemonic (int mnemonic) the default. If anything this has made the method more difficult to use.
    I also don't understand the statement in the API about setMnemonic (char mnemonic):
    "This method is only designed to handle character values which fall between 'a' and 'z' or 'A' and 'Z'."
    If the type is "char", why would the character values be restricted to values between 'a' and 'z' or 'A' and 'Z'? I understand the need for the value to be restricted to one keystroke (eliminating the possibility of using ideographic characters), but why make it impossible to use all the Latin-1 and Latin-2 characters, for instance? (and is that in fact the case?) It is established practice on other platforms to be able to use characters such as '�', '�' and '�', for instance.
    And if changes were made, why not enable the simple way of specifying a mnemonic that other platforms have implemented, by adding an '&' in front of the character?
    Sorry if this disintegrated into a rant - didn't mean to... :-) I'm sure there must be good reasons for the changes, would love to understand them.

  • Cannot login with password containing non-ascii characters

    Hello,
    I have web application, form based login. UTF-8 is specified "everywhere".
    And it works, except for passwords.
    If user register itself with password containing non-ascii characters, it is correctly written in database, but when doing either programmatic login or normal form based login, if fails.
    If the password is only ascii, it works.
    Username of login could be ascii or non-ascii, it doesn't matter, both works.
    I'm using sun java application server 9.1.
    jdbc realm.
    I'm not using hashing passwords, just clean (now)
    I tried configure realm Charset: UTF8 as last chance, but it doesn't work either.
    The problem is only with non-ascii characters in password.
    Any help very appreciated
    Thanks a lot

    hi,
    I know all that, but that's not the case. My app uses preparedStatements, everything is properly configured, in all pages, utf-8 is going from user to db and back without any problems.
    The only problem is with password field. As I am using form based login, with jdbc realm configured (again, nicely working when only ascii characters), I have very little chance to do something bad through the login phase.
    I'm not talking about special characters, I'm talking about non-ascii characters, let's say - Chinese, arabish, Russian alphabet etc.
    When user registers (my code), the fields are properly written to db. I have checked that, trust me.
    But the Sun app server realm seems to have some problems with the password field.
    (realm uses jdbc connection to mysql, the url contains all extra parameters to be sure about utf8. there is nothing more what can be configured...)
    If I try other alphabet codes in login and ascii in password, it works. But soon, as I use other alphabet code also in password, it doesn't work anymore.
    My only idea is, that I could try MD5 to create ascii only characters (I hope it works that way) on the client with javascript and then set Digest to MD5 in realm configuration. But still, it seems very strange. The clear way storage should also function? (now set Digest to 'none')
    Is it a bug of Sun App Server?
    thanks

  • Cannot rename file with non-ASCII characters when using the

    My application moves files from one directory to another by calling File[] srcFiles = srcDir.listFiles() to get a list of files in the source directory, and then calling srcFiles.renameTo(destFile) to rename each file.
    This does not work (renameTo returns false and the file is not moved) under the following circumstances:
    - the file's leaf name contains non-ASCII characters, for example "�"
    - the OS is Solaris 9
    - the LANG and LC_* environment variables are unset, i.e. the C locale is being used
    If I set the LANG environment variable to, for example, en_GB.UTF-8 then the rename succeeds.
    I have tried calling srcFiles[index].getName().getBytes("UTF-8") and the non-ASCII characters are being replaced with ? (0x3f) characters when LANG is unset.
    Is this a bug in the JRE? I would argue that since my code does not actually manipulate the filename (I just use the File object that File.listFiles() gives me) then the rename should succeed. Of course I would not expect the file name to be displayed correctly if I printed it out.
    I have reproduced this behaviour with JDK 1.4.2_05 and 1.5.0_04 on Solaris 9.
    Francis

    Thanks for the info Alan.
    I considered setting the locale in the environment (this sounds like the "correct" fix to me and we might implement it later), but this application shares a WebLogic server with many other applications so we would have to do a huge amount of testing to make sure that the locale change wouldn't break the other apps. In the end I worked around the problem by making the code that generates the filenames in the first place strip out any non-ASCII characters (the names of the files are not critically important).
    Looking forward to JSR-203, in the meantime perhaps a note about this behaviour in the java.io.File javadoc would be useful.

  • Cannot create file with Non-latin characters- I/O

    I'm trying to create a file w/ Greek (or any other non-latin) characters ... for use in a RegEx demo.
    I can't seem to create the characters. I'm thinking I'm doing something wrong w/ IO.
    The code follows. Any insight would be appreciated. - Thanks
    import java.util.regex.*;
    import java.io.*;
    public class GreekChars{
         public static void main(String [ ] args ) throws Exception{
              int c;
              createInputFile();
    //          String input = new BufferedReader(new FileReader("GreekChars.txt")).readLine();
    //          System.out.println(input);
              FileReader fr = new FileReader("GreekChars.txt");
              while( (c = fr.read()) != -1)
                   System.out.println( (char)c  );
         public static void createInputFile() throws Exception {
              PrintStream ps = new PrintStream(new FileOutputStream("GreekChars.txt"));
              ps.println("\u03A9\u0398\u03A0\u03A3"); // omega,theta,pi,sigma
              System.out.println("\u03A9\u0398\u03A0\u03A3"); // omega,theta,pi,sigma
              ps.flush();
              ps.close();
              FileWriter fw = new FileWriter("GreekChars.txt");
              fw.write("\u03A9\u0398\u03A0\u03A3",0,4);
              fw.flush();
              fw.close();
    // using a printstream to create file ... and BufferedReader to read
    C:> java GreekChars
    // using a Filewriter to create files  .. and FileReader to read
    C:> java GreekChars
    */

    Construct your file writer using a unicode format. If
    you don't then the file is written using the platform
    "default" format -probably ascii.
    example:
    FileWriter fw = new FileWriter("GreekChars.txt",
    "UTF-8");I don't know what version of FileWriter you are using, but not that I know of take two string parameters. You should try checking the API before trying to help someone, instead of just making things up.
    To the OP:
    The proper way to produce a file in UTF-8 format would be this:
    OutputStreamWriter writer = new OutputStreamWriter(new FileOutputStream("filename"), "UTF-8");Then to read the file, you would use:
    InputStreamReader reader = new InputStreamReader(new FileInputStream("filename"), "UTF-8");

  • We cannot type Polish (non-latin) characters in WebDynpro applications

    We cannot type Polish (non-latin) characters in WebDynpro application (in runtime) because 'Browser Help Shortcuts' are fired.
    To type a polish character in polish keyboard you need to press AltGr + letter (ie. AltGr + a/c/e/s/o/l/z/x/n). To type an uppercase polish character you need to press AltGr + Shift + letter. This comination is in fact the same as pressing Alt + Ctrl + Shift + letter (because AltGr produces Alt + Ctrl) and it fires some of 'Browser Help Shortcuts'. For example AltGr + Shift + O should produce a letter O with a dash on it's top but instead it fires 'Show nesting of HTML containers'.
    We tried to turn off sap-wd-lightspeed, but then other key combinations are reserved for u2018Browser Help Shortcutsu2019.
    We need to be able to use AltGr + Shift + a/c/e/s/o/l/z/x/n in runtime.
    Product: SAP NW 7.11 SP04
    WebDynpro for Java
    I hope there is a somewhere a hidden parameter that solves our problem Maybe we're in some kind of debug mode?
    Thanks for your help!!

    The funny thing is that bold font [when message unread in message list] shows OK, ie in greek, but when i click on unread message, it is assumed to have been read, so it changes over to medium [non bold] and the encoding changes as well into the one that is not greek and thus unreadable.  In ~/.sylpheed/sylpheedrc the fonts are:
    widget_font=
    message_font=-microsoft-sylfaenarm-medium-r-normal-*-*-160-*-*-p-*-iso8859-7
    normal_font=-monotype-arial-medium-r-normal-*-12-*-*-*-*-*-iso8859-7
    bold_font=-monotype-arial-bold-r-normal-*-12-*-*-*-*-*-iso8859-7
    small_font=-monotype-arial-medium-r-normal-*-12-*-*-*-*-*-iso8859-7
    In /etc/gtk, for gtk1.2 apps the file refering to greek encoding [el] seems to be fine [exactly the same as in slackware 9.1].

  • Prevent Non-English Characters on JSP forms

    I was hoping to get any programming tips/ideas to prevent users from entering non-english text on web-forms.
    Any feedback would be greatly appreciated. Thanks.

    I have a jsp page something like:
    <tr>
    <td colspan=2> </td>
    <td colspan=2>
    <textarea name="title" cols="<%=cols%>" rows="3" wrap><%= form.getTitle()%></textarea>
    </td>
    </tr>
    When the user submits the page, I do the form validation in the java formhandler. I was hoping that I could somehow compare the ascii codes of the character to ensure user is entering only english characters.
    The following is the code, I have written in java the form-handler
    for (int i =0 ; i < title.length() ; i++) {
         char c = title.charAt(i);
         System.out.println("c = " + c + ", ascii = " +(int)'c');
         if (int(c) > 127) {
              setErrorMessage(ID.QUESTION.TITLE, "Non-English characters are not allowed. Please enter the required information only in Enlgish.");     
    But for some reason which I am not able to debug, is that no matter what character I enter english or non-english its ascii equivalent i.e. the int(c) value getting printed out is always 99. Moreover even if I enter a non-english character, in the system.out it is printing its english equivalent...if that makes any sense...
    I hope I was able to explain my problem...Any help/feedback would be greatly appreciated.
    Thanks.

  • Problems with non-ASCII characters on Linux Unit Test Import

    I found a problem with non-ASCII characters in the Unit Test Import for Linux.  This problem does not appear in the Unit Test Import for Windows.
    I have attached a Unit Test export called PROC1.XML  It tests a procedure that is included in another attachment called PROC1.txt. The unit test includes 2 implementations.  Both implementations pass non-ASCII characters to the procedure and return them unchanged.
    In Linux, the unit test import will change the non-ASCII characters in the XML file to xFFFD. If I copy/paste the the non-ASCII characters into the Unit Test after the import, they will be stored and executed correctly.
    Amazon Ubuntu 3.13.0-45-generic / lubuntu-core
    Oracle 11g Express Edition - AL32UTF8
    SQL*Developer 4.0.3.16 Build MAIN-16.84
    Java(TM) SE Runtime Environment (build 1.7.0_76-b13)
    Java HotSpot(TM) 64-Bit Server VM (build 24.76-b04, mixed mode)
    In Windows, the unit test will import the non-ASCII characters unchanged from the XML file.
    Windows 7 Home Premium, Service Pack 1
    Oracle 11g Express Edition - AL32UTF8
    SQL*Developer 4.0.3.16 Build MAIN-16.84
    Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
    Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)
    If SQL*Developer is coded the same between Windows and Linux, The JVM must be causing the problem.

    Set the System property "mail.mime.decodeparameters" to "true" to enable the RFC 2231 support.
    See the javadocs for the javax.mail.internet package for the list of properties.
    Yes, the FAQ entry should contain those details as well.

  • Word Replacements for Non- English Characters

    Hi
    Does anyone have an idea on implementing Word Replacements for non- english characters in TCA- DQM 11i.
    We are trying to identify, capture and cleanse common accented characters like à, â , ê
    However, the default language for replacement is American English , So even if we add these in the existing lists it will not take any effect
    Is creating a new Word replacement list for every language the solution ?? any patch recommendations???
    Thanks in advance

    It seems that this is an issue that has popped up in various forums before, here's one example from last year:
    http://forum.java.sun.com/thread.jspa?forumID=16&threadID=490722
    This entry has some suggestions for handling mnemonics in resource bundles, and they would take care of translated mnemonics - as long as the translated values are restricted to the values contained in the VK_XXX keycodes.
    And since those values are basically the English (ASCII) character set + a bunch of function keys, it doesn't solve the original problem - how to specify mnemonics that are not part of the English character set. The more I look at this I don't really understand the reason for making setMnemonic (char mnemonic) obsolete and making setMnemonic (int mnemonic) the default. If anything this has made the method more difficult to use.
    I also don't understand the statement in the API about setMnemonic (char mnemonic):
    "This method is only designed to handle character values which fall between 'a' and 'z' or 'A' and 'Z'."
    If the type is "char", why would the character values be restricted to values between 'a' and 'z' or 'A' and 'Z'? I understand the need for the value to be restricted to one keystroke (eliminating the possibility of using ideographic characters), but why make it impossible to use all the Latin-1 and Latin-2 characters, for instance? (and is that in fact the case?) It is established practice on other platforms to be able to use characters such as '�', '�' and '�', for instance.
    And if changes were made, why not enable the simple way of specifying a mnemonic that other platforms have implemented, by adding an '&' in front of the character?
    Sorry if this disintegrated into a rant - didn't mean to... :-) I'm sure there must be good reasons for the changes, would love to understand them.

  • Validation for non-ASCII characters

    Hi all,
    Requirement: I have to apply a validation on on fields like Name and Address in applicationdefination.xml. When a user types non-ASCII characters and navigates to next page then it should display the error message. Thus, I have to restrict my user to ASCII values only.
    Present Situation: I'm using regular expression for this problem. In Jheadstart there is an option regular expression under the heading Validation. I have written following values in regular expression and Regular Expression Error Message options.
    Regular Expression
    ^\s*[\w\.\,\-\_\(\)\#\'\/\\\ u0022\u0026\*\;\:\s]+\s*$
    Regular Expression Error Message
    It is important to note that foreign characters are not accepted on our system. Please ensure only standard English letters are entered
    Since, i was getting error in jspx page due to double quotes(") and ampercent(&), So i have replaced the double quotes(") and amprecent(&) by their unicodes. Thus, the expression has become like ^\s*[\w\.\,\-\_\(\)\#\'\/\\\u0022\u0026\*\;\:\s]+\s*$.
    This expression is validating many characters like Ã,µ,Ç,Ï,Ö,§,¥,{,} but not all non ASCII characters like ѓ є ѕ ї Њ Щ Ώ Ω Ϊ Ά Ή Θ Λ Ξ Π τ ẫ ờ Ỡ Ứ Ỷ ự Ẁ ỹ ị Ọ ň ũ ť ţ Έ Ϊ ﻍ. Thus, its not fulfilling the requirement.
    Please suggest some valid solution to this problem. It’s very urgent.

    Hi,
    The validation seems to be performed in Java or Javascript depending on the layout (I'm sorry I can't remember the exact details). The expression suggested above by theEternalStudent works very well in Java, but not in Javascript.
    We came up with an expression which works in both. It rejects strings which contain &# by doing a lookahead before the main pattern - you might want to expand this to look for &#nnn; but for our purposes &# is enough.
    Here is the "platform neutral" solution:
    (?!.*\u0026#.*)^[\w\.\,\-\_\(\)\#\'\/\\\u0022\u0026\*\;\:\s]+$
    I think in future we will write a javascript function and amend the templates to call it directly.
    thanks,
    Michael

Maybe you are looking for