I had an issue with IE parsing a date , took me two hours that the date I was actually parsing has hidden characters within.
Disregarding the parse issue , I just want to know what on earth are these ?
alert("3/9/2016"==="3/9/2016")
alert("3/9/2016")
alert("3/9/2016")
JsFiddle
If no one has explaination , How can I trim these weird characters to get a valid string ?
I had an issue with IE parsing a date , took me two hours that the date I was actually parsing has hidden characters within.
Disregarding the parse issue , I just want to know what on earth are these ?
alert("3/9/2016"==="3/9/2016")
alert("3/9/2016")
alert("3/9/2016")
JsFiddle
If no one has explaination , How can I trim these weird characters to get a valid string ?
Share asked Mar 16, 2016 at 1:26 ProllyGeekProllyGeek 15.9k9 gold badges56 silver badges77 bronze badges4 Answers
Reset to default 6It seems like it's this: http://www.fileformat.info/info/unicode/char/200e/index.htm
I did: "3/9/2016".charCodeAt(0) and then googled the result.
Just replace everything that's not what you expect. In this case, it seems like you only want numbers or slashes. So ignoring every else would be /[^\d\/]. So this works:
"3/9/2016".replace(/[^\d\/]/g, '') === '3/9/2016'
These are left-to-right marks. Unicode uE2808E.
(Just for pleteness; obviously this won't fit in a ment.)
➜ ~ hexdump -C tmp.js
00000000 61 6c 65 72 74 28 22 e2 80 8e 33 e2 80 8e 2f e2 |alert("...3.../.|
00000010 80 8e 39 e2 80 8e 2f e2 80 8e 32 30 31 36 22 29 |..9.../...2016")|
00000020 0a 61 6c 65 72 74 28 22 33 2f 39 2f 32 30 31 36 |.alert("3/9/2016|
00000030 22 29 0a |").|
Using charCodeAt I figured that the symbol was char code 8026. I was then able to find another answer that should help explain your issue. Here's a relevant part of that answer.
You are likely getting the LTR markers because your display locale is RTL. Besides this, consider that the locale will always affect the output. Perhaps your locale uses dd/mm/yyyy formatting instead of mm/dd/yyyy formatting. Or perhaps your locale requires Asian or Arabic characters. These are all considerations when determining a display format, but are never appropriate for machine parsing.
tl;dr: the issue arises from getting output that is based on the machine's locale, something IE takes into account. If the locale displays RTL, IE outputs LTR, or it's some weird support for an Asian or Arabic language.
None-the-less, the aforementioned answer should be all the info you need: don't expect locale-formatted text to be machine-usable, they're meant only to be human-readable. Sure, you could filter out the characters, but there's always the possibility you could run into another locale.