Javascript equivalent for java.lang.Character.getNumericValue(char ch) method












1















Javascript's charCodeAt() method gives ASCII equivalent value for the characters (like 65 to 90 for 'A' to 'Z'). Is there any Javascript method equivalent for Java's Character.getNumericValue() method, which returns int value that the specified Unicode character represents? (Eg. It returns 10 to 35 for 'A' to 'Z')










share|improve this question





























    1















    Javascript's charCodeAt() method gives ASCII equivalent value for the characters (like 65 to 90 for 'A' to 'Z'). Is there any Javascript method equivalent for Java's Character.getNumericValue() method, which returns int value that the specified Unicode character represents? (Eg. It returns 10 to 35 for 'A' to 'Z')










    share|improve this question



























      1












      1








      1








      Javascript's charCodeAt() method gives ASCII equivalent value for the characters (like 65 to 90 for 'A' to 'Z'). Is there any Javascript method equivalent for Java's Character.getNumericValue() method, which returns int value that the specified Unicode character represents? (Eg. It returns 10 to 35 for 'A' to 'Z')










      share|improve this question
















      Javascript's charCodeAt() method gives ASCII equivalent value for the characters (like 65 to 90 for 'A' to 'Z'). Is there any Javascript method equivalent for Java's Character.getNumericValue() method, which returns int value that the specified Unicode character represents? (Eg. It returns 10 to 35 for 'A' to 'Z')







      javascript java






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Dec 31 '18 at 11:56









      Ivan Aracki

      1,75142640




      1,75142640










      asked Dec 31 '18 at 10:58









      AbiramiAbirami

      435




      435
























          1 Answer
          1






          active

          oldest

          votes


















          2














          parseInt will do that if you tell it to use base 36:






          console.log(parseInt("A", 36)); // 10
          console.log(parseInt("Z", 36)); // 35





          If you want (and you aren't writing a library or module that others will mix into their code), you could even add getNumericValue to String.prototype:






          Object.defineProperty(String.prototype, "getNumericValue", {
          value() {
          return parseInt(this, 36);
          },
          writable: true,
          configurable: true
          });

          console.log("A".getNumericValue()); // 10





          It's best not to extend built-in prototypes when writing libraries or modules that will be mixed into code you don't directly control, since if everyone did it, conflicts can arise. And if extending a built-in prototype, it's important to use Object.defineProperty so the property isn't enumerable (the default for enumerable is false). Even in your own codebase, it's usually best not to extend Object.prototype at all (not even with non-enumerable properties).






          share|improve this answer
























          • The case against extending built-in prototypes also relates to it being really slow compared to the direct procedural approach because the receiver has to be wrapped into an object to make the method call. jsperf.com/negative-modulo/2 .Overall, great answer

            – Almost Handsome
            Dec 31 '18 at 12:08













          • @AlmostHandsome - You can prevent that object wrapping and its associated cost by using strict mode when defining the prototype function: jsperf.com/negative-modulo/17 (Doesn't matter if it's called from loose mode, just matters that it be defined in strict.) In strict mode, it's a dead heat in Chrome and Firefox (looks like Edge still has work to do in that regard, assuming they continue to use Chakra after switching over to Chromium for everything else...). :-) (Not that I'm advocating the prototype approach.)

            – T.J. Crowder
            Dec 31 '18 at 12:30











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53986658%2fjavascript-equivalent-for-java-lang-character-getnumericvaluechar-ch-method%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          2














          parseInt will do that if you tell it to use base 36:






          console.log(parseInt("A", 36)); // 10
          console.log(parseInt("Z", 36)); // 35





          If you want (and you aren't writing a library or module that others will mix into their code), you could even add getNumericValue to String.prototype:






          Object.defineProperty(String.prototype, "getNumericValue", {
          value() {
          return parseInt(this, 36);
          },
          writable: true,
          configurable: true
          });

          console.log("A".getNumericValue()); // 10





          It's best not to extend built-in prototypes when writing libraries or modules that will be mixed into code you don't directly control, since if everyone did it, conflicts can arise. And if extending a built-in prototype, it's important to use Object.defineProperty so the property isn't enumerable (the default for enumerable is false). Even in your own codebase, it's usually best not to extend Object.prototype at all (not even with non-enumerable properties).






          share|improve this answer
























          • The case against extending built-in prototypes also relates to it being really slow compared to the direct procedural approach because the receiver has to be wrapped into an object to make the method call. jsperf.com/negative-modulo/2 .Overall, great answer

            – Almost Handsome
            Dec 31 '18 at 12:08













          • @AlmostHandsome - You can prevent that object wrapping and its associated cost by using strict mode when defining the prototype function: jsperf.com/negative-modulo/17 (Doesn't matter if it's called from loose mode, just matters that it be defined in strict.) In strict mode, it's a dead heat in Chrome and Firefox (looks like Edge still has work to do in that regard, assuming they continue to use Chakra after switching over to Chromium for everything else...). :-) (Not that I'm advocating the prototype approach.)

            – T.J. Crowder
            Dec 31 '18 at 12:30
















          2














          parseInt will do that if you tell it to use base 36:






          console.log(parseInt("A", 36)); // 10
          console.log(parseInt("Z", 36)); // 35





          If you want (and you aren't writing a library or module that others will mix into their code), you could even add getNumericValue to String.prototype:






          Object.defineProperty(String.prototype, "getNumericValue", {
          value() {
          return parseInt(this, 36);
          },
          writable: true,
          configurable: true
          });

          console.log("A".getNumericValue()); // 10





          It's best not to extend built-in prototypes when writing libraries or modules that will be mixed into code you don't directly control, since if everyone did it, conflicts can arise. And if extending a built-in prototype, it's important to use Object.defineProperty so the property isn't enumerable (the default for enumerable is false). Even in your own codebase, it's usually best not to extend Object.prototype at all (not even with non-enumerable properties).






          share|improve this answer
























          • The case against extending built-in prototypes also relates to it being really slow compared to the direct procedural approach because the receiver has to be wrapped into an object to make the method call. jsperf.com/negative-modulo/2 .Overall, great answer

            – Almost Handsome
            Dec 31 '18 at 12:08













          • @AlmostHandsome - You can prevent that object wrapping and its associated cost by using strict mode when defining the prototype function: jsperf.com/negative-modulo/17 (Doesn't matter if it's called from loose mode, just matters that it be defined in strict.) In strict mode, it's a dead heat in Chrome and Firefox (looks like Edge still has work to do in that regard, assuming they continue to use Chakra after switching over to Chromium for everything else...). :-) (Not that I'm advocating the prototype approach.)

            – T.J. Crowder
            Dec 31 '18 at 12:30














          2












          2








          2







          parseInt will do that if you tell it to use base 36:






          console.log(parseInt("A", 36)); // 10
          console.log(parseInt("Z", 36)); // 35





          If you want (and you aren't writing a library or module that others will mix into their code), you could even add getNumericValue to String.prototype:






          Object.defineProperty(String.prototype, "getNumericValue", {
          value() {
          return parseInt(this, 36);
          },
          writable: true,
          configurable: true
          });

          console.log("A".getNumericValue()); // 10





          It's best not to extend built-in prototypes when writing libraries or modules that will be mixed into code you don't directly control, since if everyone did it, conflicts can arise. And if extending a built-in prototype, it's important to use Object.defineProperty so the property isn't enumerable (the default for enumerable is false). Even in your own codebase, it's usually best not to extend Object.prototype at all (not even with non-enumerable properties).






          share|improve this answer













          parseInt will do that if you tell it to use base 36:






          console.log(parseInt("A", 36)); // 10
          console.log(parseInt("Z", 36)); // 35





          If you want (and you aren't writing a library or module that others will mix into their code), you could even add getNumericValue to String.prototype:






          Object.defineProperty(String.prototype, "getNumericValue", {
          value() {
          return parseInt(this, 36);
          },
          writable: true,
          configurable: true
          });

          console.log("A".getNumericValue()); // 10





          It's best not to extend built-in prototypes when writing libraries or modules that will be mixed into code you don't directly control, since if everyone did it, conflicts can arise. And if extending a built-in prototype, it's important to use Object.defineProperty so the property isn't enumerable (the default for enumerable is false). Even in your own codebase, it's usually best not to extend Object.prototype at all (not even with non-enumerable properties).






          console.log(parseInt("A", 36)); // 10
          console.log(parseInt("Z", 36)); // 35





          console.log(parseInt("A", 36)); // 10
          console.log(parseInt("Z", 36)); // 35





          Object.defineProperty(String.prototype, "getNumericValue", {
          value() {
          return parseInt(this, 36);
          },
          writable: true,
          configurable: true
          });

          console.log("A".getNumericValue()); // 10





          Object.defineProperty(String.prototype, "getNumericValue", {
          value() {
          return parseInt(this, 36);
          },
          writable: true,
          configurable: true
          });

          console.log("A".getNumericValue()); // 10






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Dec 31 '18 at 11:01









          T.J. CrowderT.J. Crowder

          685k12112181311




          685k12112181311













          • The case against extending built-in prototypes also relates to it being really slow compared to the direct procedural approach because the receiver has to be wrapped into an object to make the method call. jsperf.com/negative-modulo/2 .Overall, great answer

            – Almost Handsome
            Dec 31 '18 at 12:08













          • @AlmostHandsome - You can prevent that object wrapping and its associated cost by using strict mode when defining the prototype function: jsperf.com/negative-modulo/17 (Doesn't matter if it's called from loose mode, just matters that it be defined in strict.) In strict mode, it's a dead heat in Chrome and Firefox (looks like Edge still has work to do in that regard, assuming they continue to use Chakra after switching over to Chromium for everything else...). :-) (Not that I'm advocating the prototype approach.)

            – T.J. Crowder
            Dec 31 '18 at 12:30



















          • The case against extending built-in prototypes also relates to it being really slow compared to the direct procedural approach because the receiver has to be wrapped into an object to make the method call. jsperf.com/negative-modulo/2 .Overall, great answer

            – Almost Handsome
            Dec 31 '18 at 12:08













          • @AlmostHandsome - You can prevent that object wrapping and its associated cost by using strict mode when defining the prototype function: jsperf.com/negative-modulo/17 (Doesn't matter if it's called from loose mode, just matters that it be defined in strict.) In strict mode, it's a dead heat in Chrome and Firefox (looks like Edge still has work to do in that regard, assuming they continue to use Chakra after switching over to Chromium for everything else...). :-) (Not that I'm advocating the prototype approach.)

            – T.J. Crowder
            Dec 31 '18 at 12:30

















          The case against extending built-in prototypes also relates to it being really slow compared to the direct procedural approach because the receiver has to be wrapped into an object to make the method call. jsperf.com/negative-modulo/2 .Overall, great answer

          – Almost Handsome
          Dec 31 '18 at 12:08







          The case against extending built-in prototypes also relates to it being really slow compared to the direct procedural approach because the receiver has to be wrapped into an object to make the method call. jsperf.com/negative-modulo/2 .Overall, great answer

          – Almost Handsome
          Dec 31 '18 at 12:08















          @AlmostHandsome - You can prevent that object wrapping and its associated cost by using strict mode when defining the prototype function: jsperf.com/negative-modulo/17 (Doesn't matter if it's called from loose mode, just matters that it be defined in strict.) In strict mode, it's a dead heat in Chrome and Firefox (looks like Edge still has work to do in that regard, assuming they continue to use Chakra after switching over to Chromium for everything else...). :-) (Not that I'm advocating the prototype approach.)

          – T.J. Crowder
          Dec 31 '18 at 12:30





          @AlmostHandsome - You can prevent that object wrapping and its associated cost by using strict mode when defining the prototype function: jsperf.com/negative-modulo/17 (Doesn't matter if it's called from loose mode, just matters that it be defined in strict.) In strict mode, it's a dead heat in Chrome and Firefox (looks like Edge still has work to do in that regard, assuming they continue to use Chakra after switching over to Chromium for everything else...). :-) (Not that I'm advocating the prototype approach.)

          – T.J. Crowder
          Dec 31 '18 at 12:30


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53986658%2fjavascript-equivalent-for-java-lang-character-getnumericvaluechar-ch-method%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Mossoró

          Error while reading .h5 file using the rhdf5 package in R

          Pushsharp Apns notification error: 'InvalidToken'