String literal

A string literal is the representation of a string value within the source code of a computer program. There are numerous alternate notations for specifying string literals, and the exact notation depends on the individual programming language in question. Nevertheless, there are some general guidelines that most modern programming languages follow.

Specifically, most string literals can be specified using:

• declarative notation;
• whitespace delimiters (indentation);
• bracketed delimiters (quoting);
• escape characters; or
• a combination of some or all of the above

Declarative notation

In the original FORTRAN programming language (for example), string literals were written in so-called Hollerith notation, where a decimal count of the number of characters was followed by the letter H, and then the characters of the string:

27HAn example Hollerith string

This declarative notation style is contrasted with bracketed delimiter quoting, because it does not require the use of balanced "bracketed" characters on either side of the string.

Advantages:

• eliminates text searching (for the delimiter character) and therefore requires significantly less overhead
• avoids the (100% programmer induced) problem of delimiter collision
• enables the inclusion of metacharacters that might otherwise be mistaken as commands
• can be used for quite effective data compression of plain text strings

Drawbacks:

• this type of notation is error-prone if used as manual entry by programmers

This is however not a drawback when the prefix is generated by an algorithm as most likely the case.

Whitespace delimiters

In YAML, string literals may be specified by the relative positioning of whitespace and indentation.

   - title: An example multi-line string in YAML
     body : |
       This is a multi-line string.
       "special" metacharacters may
       appear here. The extent of this string is
       indicated by indentation.

Bracketed delimiters

Most modern programming languages use bracket delimiters (also balanced delimiters, or quoting) to specify string literals. Double quotations are the most common quoting delimiters used:

 "Hi There!"

Some languages also allow the use of single quotations as an alternative to double quotations (though the string must begin and end with the same kind of quotation mark):

 'Hi There!'

Note that these quotation marks are unpaired (the same character is used as an opener and a closer), which is a hangover from the typewriter technology which was the precursor of the earliest computer input and output devices. The Unicode character set includes paired (separate opening and closing) versions of both single and double quotations:

 “Judeth Rocks!”
 ‘Hi There!’

The paired double quotations can be used in Visual Basic .NET.

The PostScript programming language uses parentheses, with embedded newlines allowed, and also embedded unescaped parentheses provided they are properly paired:

 (The quick
 (brown
 fox))

Similarly, the Tcl programming language uses braces (embedded newlines allowed, embedded unescaped braces allowed provided properly paired):

 {The quick
 {brown
 fox}}

On one hand, this practice is derived from the single quotations in Unix shells (these are raw strings) and, on the other, from the use of braces in C for compound statements, since blocks of code is in Tcl syntactically the same thing as string literals. That the delimiters are paired is essential for making this feasible.

Delimiter collision

Main article: delimiter § Delimiter collision

Delimiter collision is a common problem for string literal notations that use balanced delimiters and quoting. The problem occurs when a programmer attempts to use a quoting character as part of the string literal itself. Because this is a very common problem, a number of methods for avoiding delimiter collision have been invented.

Dual quoting style

Some languages (e.g., Modula-2, JavaScript, and Python) attempt to avoid the delimiter collision problem by allowing a dual quoting style. Typically, this consists of allowing the programmer to use either single quotations or double quotations interchangeably.

 "This is John's apple."
 'I said, "Can you hear me?"'

One problem with dual quoting is that it doesn't allow for the inclusion of both styles of quotations at once within the same literal (unless escaped, see below).

Some programming languages allow subtle variations on dual quoting, treating single quotations and double quotations slightly differently (e.g. sh, Perl).

Escape character

One method for avoiding delimiter collision is to use escape characters:

 "I said, \"Can you hear me?\""

The most commonly-used escape character for this purpose is the backslash "\", the tradition for which originated on Unix. From a language design standpoint, this approach is adequate, but there are drawbacks:

• text can be rendered unreadable when littered with numerous escape characters
• escape characters are required to be escaped, when not intended as escape characters
• although easy to type, they can be cryptic to someone unfamiliar with the language

   "I said, \"The Windows path is C:\\Foo\\Bar\\Baz\""

The confusing presence of too many escape and slash characters in a string is commonly disparaged as leaning toothpick syndrome.

Escape sequence

An extended concept of the escape character, an escape sequence is also a means of avoiding delimiter collision. An escape sequence consists of two or more consecutive characters that can have special meaning when used in the context of a string literal. For example, programming languages such as Perl, Python and Ruby support the following:

   "I said, \x22Can you hear me?\x22"

Escape sequences can also be used for purposes other than avoiding delimiter collision, and can also include metacharacters. (see Metacharacters below).

Double-up escape sequence

Some languages (such as Pascal, BASIC, DCL, and SQL) avoid delimiter collision by doubling up on the quotation marks that are intended to be part of the string literal itself:

  'This Pascal string''contains two apostrophes'''
  "I said, ""Can you hear me?"""

Extended quoting styles

Some languages extend the previously-mentioned quoting conventions even further. These extended approaches provide an even more flexible style of notation for avoiding delimiter collision.

Triple quoting: One such extension, the use of triple quoting, is used in Python:

'''This is John's apple.'''

"""John is Nancy's so-called "boyfriend"."""

Triple quoted string literals may be delimited by """ or '''. Triple quoting in Python also has the added benefit of allowing string literals to span more than one physical line of source code.

Multiple quoting: Another such extension is the use of multiple quoting, which allows the author to choose which characters should specify the bounds of a string literal.

For example in Perl:

qq^I said, "Can you hear me?"^

qq@I said, "Can you hear me?"@

qq§I said, "Can you hear me?"§

all produce the desired result. Although this notation is more flexible, few languages support it. Perl and Ruby are two that do.

Here documents

A Here document is an alternate quoting notation that allows the programmer to specify an arbitrary unique identifier as a content boundary for a string literal. This avoids delimiter collision, and also preserves newlines in the source code as newlines in the string literal itself.

Concatenation

In some languages (e.g., BASIC) there is no provision for escape sequences or any of the workarounds discussed above. To place a string delimiter character in a string, it is necessary to use string concatenation. The following example shows how this might be done in BASIC on a system using ASCII:

"I said, " + CHR$(34) + "Can you hear me?" + CHR$(34)

Here, the CHR$() function returns the character corresponding to its argument; in ASCII the quotation mark has the value 34.

Metacharacters

Many languages support the use of metacharacters inside string literals. Metacharacters have varying interpretations depending on the context and language, but are generally a kind of 'processing command' for representing printing or nonprinting characters.

For instance, in a C string literal, if the backslash is followed by a letter such as "b", "n" or "t", then this represents a nonprinting backspace, newline or tab character respectively. Or if the backslash is followed by 1-3 octal digits, then this sequence is interpreted as representing the arbitrary character with the specified ASCII code. This was later extended to allow more modern hexadecimal character code notation:

"I said,\t\t\x22Can you hear me?\x22\n"

Raw strings

A few languages provide a method of specifying that a literal is to be processed without any language specific interpretation.

For example, in Python 'raw strings' are preceded by an r. In such strings backslashes are not interpreted as escape sequences, making it simpler to write DOS/Windows paths and regular expressions:

r"The Windows path is C:\Foo\Bar\Baz\ "

C#'s notation is called @-quoting:

@"C:\Foo\Bar\Baz\"

Which also allows double-up quotations:

@"I said, ""Hello there."""

In XML documents, CDATA sections allows use of characters such as & and < without an XML parser attempting to interpret them as part of the structure of the document itself. This can be useful when including literal text and scripting code, to keep the document well formed.

<![CDATA[  if (path!=null && depth<2) { add(path); }  ]]>

Variable interpolation

Main article: Variable interpolation

Languages differ on whether and how to interpret string literals as either 'raw' or 'variable interpolated'. Variable interpolation is the process of evaluating an expression containing one or more variables, and returning output where the variables are replaced with their corresponding values in memory. In sh-compatible Unix shells, quotation-delimited (") strings are interpolated, while apostrophe-delimited (') strings are not.

For example, the following Perl code:

$name     = "Nancy";
$greeting = "Hello World";
print "$name said $greeting to the crowd of people.";

produces the output:

Nancy said Hello World to the crowd of people.

The sigil character ($) is interpreted to indicate variable interpolation.

Similarly, the printf function produces the same output using notation such as:

printf "%s said %s to the crowd of people.", $name, $greeting;

The metacharacters (%s) indicate variable interpolation.

This is contrasted with "raw" strings:

print '$name said $greeting to the crowd of people.';

which produce output like:

$name said $greeting to the crowd of people.

Here the $ characters are not sigils, and are not interpreted to have any meaning other than plain text.

Binary and hexadecimal strings

REXX uses suffix characters to specify characters or strings using their hexadecimal or binary code. E.g.,

'20'x
"0010 0000"b
"00100000"b

all yield the space character, avoiding the function call X2C(20).

Embedding source code in string literals

Languages that lack flexibility in specifying string literals make it particularly cumbersome to write programming code that generates other programming code. This is particularly true when the generation language is the same or similar to the output language.

for example:

• writing code to produce quines
• generating an output language from within a web template;
• using XSLT to generate XSLT, or SQL to generate more SQL
• generating a PostScript representation of a document for printing purposes, from within a document-processing application written in C or some other language.

Nevertheless, some languages are particularly well-adapted to produce this sort of self-similar output, especially those that support multiple options for avoiding delimiter collision.

Using string literals as code that generates other code may have adverse security implications, especially if the output is based at least partially on untrusted user input. This is particularly acute in the case of Web-based applications, where malicious users can take advantage of such weaknesses to subvert the operation of the application, for example by mounting an SQL injection attack.

See also

• Sigil (computer programming)

External links

• Literals In Programming