Most of the hashs wont works regarding file encoding about crypto-js

[GoogleCodeExporter]

I used JS Beautifier to get the code like that btw, if you wonder why my file 
is not minified.

http://jsbeautifier.org/

Original comment by [email protected] on 3 Aug 2014 at 2:54

[GoogleCodeExporter]

also, I use js FileReader with reader.readAsBinaryString to open my file.

Original comment by [email protected] on 3 Aug 2014 at 2:58

[GoogleCodeExporter]

So, the issue is that JavaScript strings are UTF-16, always. When you 
readAsBinaryString, of course, only a small subset of JavaScript's possible 
characters are used, but CryptoJS has no way to know that. In hindsight, I 
probably should have required the library user to always specify the character 
encoding of the input. Instead, the current behavior is that if you don't 
specify the character encoding (by first converting to bytes), then UTF-8 is 
picked as the default.

Original comment by Jeff.Mott.OR on 3 Aug 2014 at 3:51

[GoogleCodeExporter]

We may not know the character encoding, it's hard to deal with character 
encoding when it come to a file.

For example: a UTF8-NoBom encoded file give you no hint about its current 
encoding, you need to parse the first character and determine what encoding it 
is, when this is done automatically when running a webserver like apache2, this 
task adds alot of code on the developper side who would use the API.

I don't know about UTF-16 and JavaScript strings but I can guarranty that any 
non-AINSII encoding mismatch between my checksum tool and the output the 
website gave me.

I don't know how much it affect users that will use this library only for 
normal strings (instead of output from a file), it would probably don't affect 
them at all... ? I don't see a case where you could have a mismatch of hash 
since the string will be coded INSIDE the file anyway.

Original comment by [email protected] on 3 Aug 2014 at 5:54