ECMAScript code is expressed using Unicode, version 5.1 or later. ECMAScript source text is a sequence of code points. All Unicode code point values from U+0000 to U+10FFFF, including surrogate code points, may occur in source text where permitted by the ECMAScript grammars. The actual encodings used to store and interchange ECMAScript source text is not relevant to this specification. Regardless of the external source text encoding, a conforming ECMAScript implementation processes the source text as if it was an equivalent sequence of SourceCharacter values. Each SourceCharacter being a Unicode code point. Conforming ECMAScript implementations are not required to perform any normalization of source text, or behave as though they were performing normalization of source text.
The components of a combining character sequence are treated as individual Unicode code points even though a user might think of the whole sequence as a single character.
NOTE In string literals, regular expression literals, template literals and identifiers, any Unicode code point may also be expressed using Unicode escape sequences that explicitly express a code point’s numeric value. Within a comment, such an escape sequence is effectively ignored as part of the comment.
ECMAScript differs from the Java programming language in the behaviour of Unicode escape sequences. In a Java program,
if the Unicode escape sequence \u000A, for example, occurs within a single-line comment, it is interpreted as
a line terminator (Unicode code point U+000A is LINE FEED (LF) and therefore the next code point is not part of the
comment. Similarly, if the Unicode escape sequence \u000A occurs within a string literal in a Java program,
it is likewise interpreted as a line terminator, which is not allowed within a string literal—one must write
\n instead of \u000A to cause a LINE FEED (LF) to be part of the String value of a string
literal. In an ECMAScript program, a Unicode escape sequence occurring within a comment is never interpreted and therefore
cannot contribute to termination of the comment. Similarly, a Unicode escape sequence occurring within a string literal in
an ECMAScript program always contributes to the literal and is never interpreted as a line terminator or as a code point
that might terminate the string literal.
The UTF16Encoding of a numeric code point value, cp, is determined as follows:
Two code units, lead and trail, that form a UTF-16 surrogate pair are converted to a code point by performing the following steps:
There are four types of ECMAScript code:
Global code is source text that is treated as an ECMAScript Script. The global code of a particular Script does not include any source text that is parsed as part of a FunctionDeclaration, FunctionExpression, GeneratorDeclaration, GeneratorExpression, MethodDefinition, ArrowFunction, ClassDeclaration, or ClassExpression.
Eval code is the source text supplied to the built-in eval function. More precisely, if the
parameter to the built-in eval function is a String, it is treated as an ECMAScript Script. The eval
code for a particular invocation of eval is the global code portion of that Script.
Function code is source text that is parsed to supply the value of the [[ECMAScriptCode]] and [[FormalParameters]] internal slots (see 9.2) of an ECMAScript function object. The function code of a particular ECMAScript function does not include any source text that is parsed as the function code of a nested FunctionDeclaration, FunctionExpression, GeneratorDeclaration, GeneratorExpression, MethodDefinition, ArrowFunction, ClassDeclaration, or ClassExpression.
Module code is source text that is code that is provided as a ModuleBody. It is the code that is directly evaluated when a module is initialized. The module code of a particular module does not include any source text that is parsed as part of a nested FunctionDeclaration, FunctionExpression, GeneratorDeclaration, GeneratorExpression, MethodDefinition, ArrowFunction, ClassDeclaration, or ClassExpression.
NOTE Function code is generally provided as the bodies of Function Definitions (14.1), Arrow Function Definitions (14.2), Method Definitions (14.3) and
Generator Definitions (14.4). Function code is also derived from the
arguments to the Function constructor (19.2.1.1) and the
GeneratorFunction constructor (25.2.1.1).
An ECMAScript Script syntactic unit may be processed using either unrestricted or strict mode syntax and semantics. Code is interpreted as strict mode code in the following situations:
Global code is strict mode code if it begins with a Directive Prologue that contains a Use Strict Directive (see 14.1.1).
Module code is always strict mode code.
All parts of a ClassDeclaration or a ClassExpression are strict mode code.
Eval code is strict mode code if it begins with a Directive Prologue that contains a Use Strict Directive or if the call to eval is a direct eval (see 12.3.4.1) that is contained in strict mode code.
Function code is strict mode code if the associated FunctionDeclaration, FunctionExpression, GeneratorDeclaration, GeneratorExpression, MethodDefinition, or ArrowFunction is contained in strict mode code or if the code that produces the value of the function's [[ECMAScriptCode]] internal slot begins with a Directive Prologue that contains a Use Strict Directive.
Function code that is supplied as the arguments to the built-in Function and Generator
constructors is strict mode code if the last argument is a String that when processed is a FunctionBody that begins with a Directive Prologue that contains a Use Strict Directive.
ECMAScript code that is not strict mode code is called non-strict code.
An ECMAScript implementation may support the evaluation of exotic function objects whose evaluative behaviour is expressed in some implementation defined form of executable code other than via ECMAScript code. Whether a function object is an ECMAScript code function or a non-ECMAScript function is not semantically observable from the perspective of an ECMAScript code function that calls or is called by such a non-ECMAScript function.