4 ms·
Why aren't ◎ܫ◎ and ☺ valid Javascript variable names?
- yannis 15y agoFor a bit more in-depth understanding have a look at some of the problems as noted in Google's closure library (goog.i18n.uChar). Any unicode character can be used as a JavaScript identifier for example: var 按 = function (){ return '\uD869\uDED6'; } works with no issues.
- lifthrasiir 15y agoA (quite large) subset of Unicode characters, to be specific. Of course some "letters" are hardly recognizable as letters for many people (for example, Vai syllabary) but they are used as letters in at least one script.
- yannis 15y agoThere are a few in the higher planes that may give you problems (for example phoenician etc..). It is also important that the Browser does not do a replacement. You need a font like code2000 or latest version.
- jfarmer 15y agoAnswer: Javascript allows variables to begin with unicode letters, but these characters are classified as symbols, not letters. Internet Explorer 9 doesn't seem to follow the above rule, and permits unicode symbols at the beginning of variable names.
- jvdh 15y agoThe ECMAscript standard is actually a bit more prohibitive: you can only use Unicode letters or (non-space) combining symbols in variable names. IE has relaxed this a little bit, by allowing variables to contain (but not start) with symbols.
- chime 15y agoSerious question: Do people around the world really use non-English code to develop websites? If <div> and <span> have to be in English, CSS styles are in English, and libraries like jQuery have functions in English, are there developers somewhere who absolutely need the ability to write JS in Kannada or French? If not, why is Unicode even allowed as a variable name? It seems like a potential vulnerability waiting to be exploited.
- deleted 15y ago[deleted]
- Ralith 15y agoHow could it be exploited?
- chime 15y agoDon't know why you were down-voted, it is a perfectly good question. Personally I don't know but then again I'm not samy.pl. I know there have been unicode vulnerabilities in IIS in the past but what I'd be more concerned with would be XSS. While most sites sanitize data to prevent XSS, maybe someone could come up with a dirty input that doesn't get filtered and runs an exploit.
- jbri 15y agoFor this specific issue to be relevant, your sanitizer would have to assume that a particular string is not a valid javascript identifier when in fact it is, and that changes the semantic meaning from something that is safe to embed directly into something that is not. Unless you're trying to parse Javascript and see whether it's safe to embed, it's not really relevant. XSS attacks are dealt with by escaping the special characters that can change the context in which something is interpreted (e.g. " changing the context from "contents of a string" to "javascript code", or < changing the context from "text on a page" to "an html tag").
- yannis 15y agoJavascript will let it go through (as it is a valid identifier) and for example on the server PHP will not catch it.
- ftwinnovations 15y agoDamn you IE, always being different! (╯｀□′)╯ ┴—┴
- japherwocky 15y agobecause unicode is tedious, and wtf needs to use shit like ◎ܫ◎ as a variable name?