I'm running into some issues with the runtime parameter hashing of globalize due to embedded Unicode control characters being escaped during calls to JSON.stringify. This is happening with Left-to-right and Right-to-left control characters (e.g. \u200e), and results in the runtime hash not matching the pre-compiled hash value of the formatters.
My environment is a little unique; I am running globalize successfully (aside from this issue!) in a Classic ASP page using Microsoft JScript (ECMAScript 3-ish). It does require the use of es5-shim and a JSON library, in my case, currently, json2.
And, when that is hashed, the \u200e character is hashed as [92][117][50][48][48][101] instead if [8206], resulting in a hash mis-match.
I'm not sure the best way to fix this -- should the hashing algorithm be more robust to handle control characters consistently? Do I need to modify json2.js to not escape these characters and behave more like other browsers? I expect the json2.js behavior is intentionally the way it is, and the JSON spec allows for escaping unicode control characters, so this is technically correct, it's just not consistent for use as a hash input.
This seems related to #705, and a fix for that might/should take this into account.
I'm running into some issues with the runtime parameter hashing of
globalizedue to embedded Unicode control characters being escaped during calls toJSON.stringify. This is happening with Left-to-right and Right-to-left control characters (e.g.\u200e), and results in the runtime hash not matching the pre-compiled hash value of the formatters.My environment is a little unique; I am running
globalizesuccessfully (aside from this issue!) in a Classic ASP page using Microsoft JScript (ECMAScript 3-ish). It does require the use ofes5-shimand a JSON library, in my case, currently, json2.The issue is that
json2is escaping a larger set of Unicode control characters than other JS implementations.For example, my compiled formatter looks like this:
When the arguments for this are stringified, it turns into this:
And, when that is hashed, the
\u200echaracter is hashed as[92][117][50][48][48][101]instead if[8206], resulting in a hash mis-match.I'm not sure the best way to fix this -- should the hashing algorithm be more robust to handle control characters consistently? Do I need to modify
json2.jsto not escape these characters and behave more like other browsers? I expect thejson2.jsbehavior is intentionally the way it is, and the JSON spec allows for escaping unicode control characters, so this is technically correct, it's just not consistent for use as a hash input.This seems related to #705, and a fix for that might/should take this into account.