jquery 全球化与 parseFloat 验证的问题
我正在尝试使用 jquery 全球化插件 (https://github.com/jquery/globalize) 来处理 asp.net mvc3 客户端非侵入性验证。我已经结合了 en-CA 和 fr-CA 文化,并且发现插件接受的有效数字与服务端验证接受的数字之间存在一些差异。以下是使用两种文化的不同输入调用 Globalize.parseFloat 方法的一些示例以及我得到的结果(粗体表示服务器端验证不会验证数字) fr-CA
- Globalize.parseFloat("7.12", 10, "fr-CA") 返回 7.12
- Globalize.parseFloat("7..12", 10, "fr-CA") 返回 NaN
- Globalize .parseFloat("7,12", 10, "fr-CA") 返回 7.12
- Globalize.parseFloat("7,,12", 10, "fr-CA") 返回 NaN
- Globalize.parseFloat("7 1 2,12", 10, "fr-CA") 返回 712.12
en-CA
- Globalize.parseFloat("7.12", 10, "en-CA") 返回 7.12
- Globalize.parseFloat("7..12", 10, "en-CA") 返回NaN
- Globalize.parseFloat("7,12", 10, "en-CA") 返回 712
- Globalize.parseFloat("7,,12", 10, "en-CA")返回 712
- Globalize.parseFloat("7,,1,,2.12", 10, "en-CA") 返回712.12
单步执行 parseFloat 代码看起来这就是预期的输出,但我看不出这是如何预期的,所以我希望我错过了一些东西......或者这是预期的?
谢谢
I am trying to use the jquery globalization plugin (https://github.com/jquery/globalize) to work with asp.net mvc3 client side unobtrusive validation. I have tied in both the en-CA and fr-CA cultures and was seeing some discrepancies between what the plugin accepting as a valid number vs what the service side validation was accepting. Here is some examples of calling the Globalize.parseFloat method with different inputs with the two cultures and what I am getting out (bold indicates that server side validation doesnt validate the number)
fr-CA
- Globalize.parseFloat("7.12", 10, "fr-CA") returns 7.12
- Globalize.parseFloat("7..12", 10, "fr-CA") returns NaN
- Globalize.parseFloat("7,12", 10, "fr-CA") returns 7.12
- Globalize.parseFloat("7,,12", 10, "fr-CA") returns NaN
- Globalize.parseFloat("7 1 2,12", 10, "fr-CA") returns 712.12
en-CA
- Globalize.parseFloat("7.12", 10, "en-CA") returns 7.12
- Globalize.parseFloat("7..12", 10, "en-CA") returns NaN
- Globalize.parseFloat("7,12", 10, "en-CA") returns 712
- Globalize.parseFloat("7,,12", 10, "en-CA") returns 712
- Globalize.parseFloat("7,,1,,2.12", 10, "en-CA") returns 712.12
Stepping through the parseFloat code looks like this is the intended output but I cant see how this is intended so I am hoping I am missing something ... or is this intended?
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
看起来这是全球化插件中的一个已知问题(请参阅 https://github.com/jquery/全球化/issues/46)。看起来我必须运行自己的正则表达式,以确保它采用正确的格式进行客户端验证(好消息是我目前只需要处理两种语言:)
Looks like this is a known issue in the globalization plugin (see https://github.com/jquery/globalize/issues/46). Looks like I will have to run my own regex to make sure it is in the right format for client side validation (good thing I only have to deal with two languages at the moment :)
由于 parseFloat 位于内部,因此它首先运行,并被 Globalize 包装。 parseFloat 并不是真正设计来处理复杂字符串的。
Since parseFloat is inside, it runs first, wrapped by Globalize. parseFloat isn't really designed to handle complex strings.
客户端的 parseFloat 方法只是忽略千位分隔符,因此这就是为什么 Globalize.parseFloat("7,,1,,2.12", 10, "en-CA") 返回 712.12 (这种文化中的千位分隔符是',')。
fr-CA 文化的千位分隔符是空格,这就是 Globalize.parseFloat("7 1 2,12", 10, "fr-CA") 返回 712.12 的原因。
小数点只能出现一次。对于 en-CA,这是一个“.”,对于 fr-CA,这是一个“,”。因此,所有包含多个小数点的示例都将返回 NaN。
我唯一无法解释的是为什么 Globalize.parseFloat("7.12", 10, "fr-CA") 返回 7.12。这很奇怪,因为小数点和千位分隔符都不是“.”。在这种文化中,所以这应该返回 NaN。
The parseFloat method on the client side just ignores the thousand separators, so this is why Globalize.parseFloat("7,,1,,2.12", 10, "en-CA") returns 712.12 (the thousand separator in this culture is a ',').
The thousand separator for the fr-CA culture is a space, this is why Globalize.parseFloat("7 1 2,12", 10, "fr-CA") returns 712.12.
The decimal point can only occur once. For en-CA this is a '.', for fr-CA this is a ','. So all examples containing more than one decimal point will return NaN.
The only thing I cannot explain is why Globalize.parseFloat("7.12", 10, "fr-CA") returns 7.12. This is strange because neither the decimal point nor the thousands separator is a '.' in this culture, so this should return NaN.