hi, i'm using junit for testing my http server client functionality. here one test looks for the expected and actual Content-Length values. exp = "66" actual = "66" Although the display shows same strings with values "66" and "66" for expected and actual, the test fails. on further investigation, i found that the exp.equals(actual) returns false. Moreover, when i printed the byte arrays for both the strings, it was returning same sequence of bytes.
i tried printing the char arrays, but my linux machine can't display some characters, so it was throwing exceptions. byte[] b1 = new byte[exp.length()] byte[] b2 = new byte[actual.length()] but the
returns false. also their hascode are different so from this i can conclude the charater sequence is different for both the strings which i'm not sure why?
is it because of different charsets or formatting or because of client server scenario?(client and server are on same machine). i tried testing with different charsets and it works fine. equals() returns true. i'm totally stuck can anybody throw som light on this or is it a bug in java
The reason an Integer 10 and a String "10" don't return equal is that they are completely different kinds of Object.
Suggest you print out your char[] arrays using the %d or the %x formatting tag.See whether the two arrays are in fact equal. It makes me suspicious if you are getting Exceptions.
[edit]Try changing %x to %04x for better formatting[/edit] [ February 22, 2008: Message edited by: Campbell Ritchie ]
This segmet of code is an intent to encode a non ASCII String into an ASCII one:
For test you can use the following JUnit:
This test always fails, I tryed everything, both string before and after the conversation print the same sequence of characters, the getBytes() method returns exactly the same array. I'm really pissed for this, hope it can be resolved quickly.
Campbell Ritchie
Sheriff
Joined: Oct 13, 2005
Posts: 32830
4
posted
0
Please check your displayed name "camelo" against the JavaRanch naming policy and change it to comply.
I can only conclude that there is some subset of characters that your encoding method doesn't work as expected on. It has nothing to do with Charsets or anything like that. I haven't figured out what characters it's failing on, but there is definitely a difference between the original String and the decoded String. Here's the tests I used:
[ April 20, 2008: Message edited by: Garrett Rowe ] [ April 20, 2008: Message edited by: Garrett Rowe ]
Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. - Laurence J. Peter