private static boolean isASCIISuperset(String encoding) throws Exception {
  String chkS="0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ" + "abcdefghijklmnopqrstuvwxyz-_.!~*'();/?:@&=+$,";
  byte[] chkB={48,49,50,51,52,53,54,55,56,57,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,45,95,46,33,126,42,39,40,41,59,47,63,58,64,38,61,43,36,44};
  byte[] b=chkS.getBytes(encoding);
  return Arrays.equals(b,chkB);
}

private static boolean isASCIISuperset ( String encoding ) throws Exception { String chkS = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ" + "abcdefghijklmnopqrstuvwxyz-_.!~*'();/?:@&=+$," ; byte [ ] chkB = { 48 , 49 , 50 , 51 , 52 , 53 , 54 , 55 , 56 , 57 , 65 , 66 , 67 , 68 , 69 , 70 , 71 , 72 , 73 , 74 , 75 , 76 , 77 , 78 , 79 , 80 , 81 , 82 , 83 , 84 , 85 , 86 , 87 , 88 , 89 , 90 , 97 , 98 , 99 , 100 , 101 , 102 , 103 , 104 , 105 , 106 , 107 , 108 , 109 , 110 , 111 , 112 , 113 , 114 , 115 , 116 , 117 , 118 , 119 , 120 , 121 , 122 , 45 , 95 , 46 , 33 , 126 , 42 , 39 , 40 , 41 , 59 , 47 , 63 , 58 , 64 , 38 , 61 , 43 , 36 , 44 } ; byte [ ] b = chkS . getBytes ( encoding ) ; return Arrays . equals ( b , chkB ) ; }
test the named character encoding to verify that it converts ascii characters correctly . we have to use an ascii based encoding , or else the networkclients will not work correctly in ebcdic based systems . however , we cannot just use ascii or iso8859_1 universally , because in asian locales , non - ascii characters may be embedded in otherwise ascii based protocols ( eg . http ) . the specifications ( rfc2616 , 2398 ) are a little ambiguous in this matter . for instance , rfc2398 [ part 2 . 1 ] says that the http request uri should be escaped using a defined mechanism , but there is no way to specify in the escaped string what the original character set is . it is not correct to assume that utf - 8 is always used ( as in urls in html 4 . 0 ) . for this reason , until the specifications are updated to deal with this issue more comprehensively , and more importantly , http servers are known to support these mechanisms , we will maintain the current behavior where it is possible to send non - ascii characters in their original unescaped form .
