惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Vercel News
Vercel News
T
Tor Project blog
博客园_首页
F
Fortinet All Blogs
V
V2EX
雷峰网
雷峰网
Microsoft Azure Blog
Microsoft Azure Blog
Y
Y Combinator Blog
博客园 - 【当耐特】
Jina AI
Jina AI
Google DeepMind News
Google DeepMind News
人人都是产品经理
人人都是产品经理
B
Blog RSS Feed
Engineering at Meta
Engineering at Meta
Spread Privacy
Spread Privacy
C
Cyber Attacks, Cyber Crime and Cyber Security
The Cloudflare Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Apple Machine Learning Research
Apple Machine Learning Research
V2EX - 技术
V2EX - 技术
Latest news
Latest news
L
LINUX DO - 最新话题
IT之家
IT之家
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
博客园 - 叶小钗
博客园 - Franky
I
InfoQ
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
量子位
博客园 - 聂微东
MyScale Blog
MyScale Blog
S
Security @ Cisco Blogs
Hacker News - Newest:
Hacker News - Newest: "LLM"
小众软件
小众软件
S
Secure Thoughts
D
Darknet – Hacking Tools, Hacker News & Cyber Security
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
N
News | PayPal Newsroom
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
B
Blog
Google DeepMind News
Google DeepMind News
J
Java Code Geeks
有赞技术团队
有赞技术团队
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
V
Vulnerabilities – Threatpost
T
Tailwind CSS Blog
L
Lohrmann on Cybersecurity
T
Troy Hunt's Blog
美团技术团队

Mathias Bynens

A horrifying globalThis polyfill in universal JavaScript JavaScript engine fundamentals: optimizing prototypes JavaScript engine fundamentals: Shapes and Inline Caches Asynchronous stack traces: why await beats Promise#then() ECMAScript regular expressions are getting better! Unicode property escapes in JavaScript regular expressions ES2015 const is not about immutability Valid JavaScript variable names in ES2015 Unicode-aware regular expressions in ES2015 Dear Google, please fix plain text emails in Gmail PBKDF2+HMAC hash collisions explained JavaScript has a Unicode problem Processing Content Security Policy violation reports Hiding JSON-formatted data in the DOM with CSP enabled Loading JSON-formatted data with Ajax and xhr.responseType='json' Reserved keywords in JavaScript How to support full Unicode in MySQL databases How to speedrun Dropbox’s Dropquest 2012 Unquoted font family names in CSS Valid JavaScript variable names in ES5 CSS character escape sequences JavaScript’s internal character encoding: UCS-2 or UTF-16? The smallest possible valid (X)HTML documents JavaScript character escape sequences JavaScript foo.prototype.bar notation Ambiguous ampersands HTML element + attribute notation How I detect and use localStorage: a simple JavaScript pattern Unquoted attribute values in HTML and CSS/JS selectors The end-tag open (ETAGO) delimiter Using the oninput event handler with onkeyup/onkeydown as its fallback Everything you always wanted to know about touch icons In defense of CSS hacks — introducing “safe CSS hacks” AirPlay video support in iOS Safari — a bookmarklet Completing Dropbox’s Dropquest 2011 in 60 seconds Using CSS without HTML How to create simple Mac apps from shell scripts Using setTimeout to speed up window.onload Bulletproof JavaScript benchmarks Thoughts on Safari Reader’s generated HTML How to enable Safari Reader on your site? The XML serialization of HTML5, aka ‘XHTML5’ The id attribute got more classy in HTML5 The three levels of HTML5 usage The HTML5 document.head DOM tree accessor Bulletproof HTML5 <details> fallback using jQuery Displaying hidden elements like <head> using CSS Inline <script> and <style> vs. external .js and .css — what’s the size threshold? Using Showdown/PageDown with and without jQuery
Unquoted property names / object keys in JavaScript
Mathias · 2012-03-01 · via Mathias Bynens

Fun fact: var foo = { H̹̙̦̮͉̩̗̗ͧ̇̏̊̾Eͨ͆͒̆ͮ̃͏̷̮̣̫̤̣Cͯ̂͐͏̨̛͔̦̟͈̻O̜͎͍͙͚̬̝̣̽ͮ͐͗̀ͤ̍̀͢M̴̡̲̭͍͇̼̟̯̦̉̒͠Ḛ̛̙̞̪̗ͥͤͩ̾͑̔͐ͅṮ̴̷̷̗̼͍̿̿̓̽͐H̙̙̔̄͜: 42 }; is valid JavaScript. It may not be immediately obvious, but the real surprise here is that the Cthulhu-esque property name is not surrounded by quotes. Intrigued by this, and having written about the similar topic of JavaScript identifiers before, I decided to look into valid property names in JavaScript. When do they need to be quoted? When can the quotes be omitted? And in which cases can dot notation be used instead of bracket notation to get or set a property based on its name?

Valid property names

Looking at the ECMAScript spec grammar, we can see that a property name can be either an identifier name (i.e. identifiers + reserved words), a string literal, or a numeric literal.

Identifier names are a superset of identifiers; any valid identifier and any reserved word is a valid identifier name.

A string literal is any valid string, encapsulated in either single (') or double (") quotes. 'foo', "bar", 'qu\'ux', "" (the empty string), and 'Ich \u2665 B\xFCcher' are all valid string literals.

A numeric literal can be either a decimal literal (e.g. 0, 123, 123., .123, 1.23, 1e23, 1E-23, 1e+23, 12, but not 01, +123 or -123) or a hex integer literal (0[xX][0-9a-fA-F]+ in regex, e.g. 0xFFFF, 0X123, 0xaBcD).

Technically, octal literals (0[0-7]+ in regex, e.g. 010, 012, 01) are valid numeric literals too, but as they’re not allowed in strict mode it’s probably best to avoid them altogether.

The spec defines property names as strings:

The Property Identifier type is used to associate a property name with a Property Descriptor. Values of the Property Identifier type are pairs of the form (name, descriptor), where name is a String and descriptor is a Property Descriptor value.

This can make the use of numeric literals as property names a bit confusing. For example, if you were to use the number .12e3 as an (unquoted) property name, it would be coerced into a string first, and the actual object key would become '120'.

var object = {
	.12e3: 'wut'
};
object[.12e3]; // 'wut'
object['.12e3']; // undefined
object['120']; // 'wut'

// Let’s try another numeric literal:
object = {
	12e34: 'heh'
};
object[12e34]; // 'heh'
object['12e34']; // undefined
object[1.2e35]; // 'heh'
object['1.2e35']; // undefined
object[1.2e+35]; // 'heh'
object['1.2e+35']; // 'heh'

While you can easily check the string value of any number — String(number) or (number).toString() — it’s definitely simpler to just stick to string literals or identifier names for property names.

Note: ECMAScript 3 didn’t allow the use of unquoted reserved words as property names. Here’s the full list of ES3 reserved words: abstract, boolean, break, byte, case, catch, char, class, const, continue, debugger, default, delete, do, double, else, enum, export, extends, false, final, finally, float, for, function, goto, if, implements, import, in, instanceof, int, interface, long, native, new, null, package, private, protected, public, return, short, static, super, switch, synchronized, this, throw, throws, transient, true, try, typeof, var, void, volatile, while, and with. Avoid using these as unquoted property names if backwards compatibility is a concern.

When can the quotes be omitted?

Unless an object key is a numeric literal or a valid identifier name, you need to quote it to avoid a syntax error from being thrown. In other words, quotes can only be omitted if the property name is a numeric literal or a valid identifier name. Of course, if the property name is a string literal, it’s already quoted by definition.

var object = {
	// `abc` is a valid identifier; no quotes are needed
	abc: 1,
	// `123` is a numeric literal; no quotes are needed
	123: 2,
	// `012` is an octal literal with value `10` and thus isn’t allowed in strict mode; but if you insist on using it, quotes aren’t needed
	012: 3,
	// `π` is a valid identifier; no quotes are needed
	π: Math.PI,
	// `var` is a valid identifier name (although it’s a reserved word); no quotes are needed
	var: 4,
	// `foo bar` is not a valid identifier name; quotes are required
	'foo bar': 5,
	// `foo-bar` is not a valid identifier name; quotes are required
	'foo-bar': 6,
	// the empty string is not a valid identifier name; quotes are required
	'': 7
};

JSON only allows string literals that are quoted in double quotes (") as property names.

When can dot notation be used?

To get or set a value from an object based on a property name, you can always use bracket notation. Let’s say we want to get the value for the property name abc from the object in the previous example this way:

object['abc']; // 1

Bracket notation can safely be used for all property names.

As you may know, there is an alternative that can be used in some cases: dot notation.

object.abc; // 1

Dot notation can only be used when the property name is a valid identifier name. It cannot be used for property names that are numeric literals, or for strings that aren’t valid identifier names.

Unquoted JavaScript property name validator

I made a tool that will tell you if any given property name can be used without quotes and/or with dot notation. Try it at mothereff.in/js-properties.

Unquoted JavaScript property name validator