using division operator (/) on strings in javascript

后端 未结 3 1360
野性不改
野性不改 2020-12-02 01:52

I realized that in javascript all 101/100, \"101\"/100, 101/\"100\" and \"101\"/\"100\" result in 1.01 (checked on Chrome, FF and IE11). But I cannot find a piece of documen

相关标签:
3条回答
  • 2020-12-02 02:44

    When you use / on strings, the strings are implicitly converted to numbers and then division operation is performed.

    This may work in all browsers, but it's always good practice to convert to number explicitly using parseInt or parseFloat or other method.

    parseInt("101", 10) / 100
    

    Or

    parseFloat("101") / 100
    

    ECMAScript Specifications for Division Operator

    0 讨论(0)
  • 2020-12-02 02:49

    Therefore my question is if it is (cross-browser) safe to use this feature...

    It depends on your definition of "safe." With the division operator, yes, it's specified behavior: Each operand is converted (implicitly coerced) to a number, and then numeric division is done.

    But beware of generalizing this too far. You'll be okay with /, *, and - but it will bite you on +, because if either operand to + is a string, + does string concatenation, not addition.

    Another way that it may or may not be "safe" depending on your point of view is the implicit coercion: It uses the browser's JavaScript engine's rules for converting strings to numbers. Some older browsers went beyond the specification (which they were allowed to in the past) and treated numbers starting with a 0 as octal (base 8) rather than decimal. Naturally, end users who type in, say, "0123" as a number probably mean the number 123, not the number 83 (123 in octal = 83 decimal). JavaScript engines are no longer allowed to do that, but some older ones do.

    In general, it's probably best to explicitly coerce or convert those operands. Your choices for doing so:

    • The unary + operator: value = +value will coerce the string to a number using the JavaScript engine's standard rules for that. Any non-digits in the string (other than the e for scientific notation) make the result NaN. Also, +"" is 0, which may not be intuitive.

    • The Number function: value = Number(value). Does the same thing as +.

    • The parseInt function, usually with a radix (number base): value = parseInt(value, 10). The downside here is that parseInt converts any number it finds at the beginning of the string but ignores non-digits later in the string, so parseInt("100asdf", 10) is 100, not NaN. As the name implies, parseInt parses only a whole number.

    • The parseFloat function: value = parseFloat(value). Allows fractional values, and always works in decimal (never octal or hex). Does the same thing parseInt does with garbage at the end of the string, parseFloat("123.34alksdjf") is 123.34.

    So, pick your tool to suit your use case. :-)

    0 讨论(0)
  • 2020-12-02 02:53

    Type coercion is at play here. Quoting @Barmar's answer from What exactly is Type Coercion in Javascript?

    Type coercion means that when the operands of an operator are of different types, one of them will be converted to an "equivalent" value of the other operand's type.

    The reason for your observation is valid for other operations too -

    1 + "2" will give you "12"
    1 - "2" will give you -1 
    

    (because "-" operation on strings is not defined like division")

    In the case "101/100" the operation "/" will decide the coercion, since there is no operation defined on strings with that operator "/", but is there for "numbers".

    Using it is safe (at least in modern browsers) as long as you are clear how type coercion will play out in your operation.

    0 讨论(0)
提交回复
热议问题