String literal

Delimiter collision

When using quoting, if one wishes to represent the delimiter itself in a string literal, one runs into the problem of delimiter collision. For example, if the delimiter is a double quote, one cannot simply represent a double quote itself by the literal """ as the second quote is interpreted as the end of the string literal, not as the value of the string, and similarly one cannot write "This is "in quotes", but invalid." as the middle quoted portion is instead interpreted as outside of quotes. There are various solutions, the most general-purpose of which is using escape sequences, such as "\"" or "This is \"in quotes\" and properly escaped.", but there are many other solutions.

Paired quotes, such as braces in Tcl, allow nested strings, such as {foo {bar} zork} but do not otherwise solve the problem of delimiter collision, since an unbalanced closing delimiter cannot simply be included, as in {}}.

Doubling up

A number of languages, including Pascal, BASIC, DCL, Smalltalk, SQL, J, and Fortran, avoid delimiter collision by doubling up on the quotation marks that are intended to be part of the string literal itself:

<span id="mw0A"></span><span class="w" id="mw0Q"> </span><span class="s" id="mw0g">'This Pascal string</span><span class="se" id="mw0w">''</span><span class="s" id="mw1A">contains two apostrophes</span><span class="se" id="mw1Q">''</span><span class="s" id="mw1g">'</span>

<span id="mw2Q"></span><span class="w" id="mw2g"> </span><span class="s2" id="mw2w">"I said, ""Can you hear me?"""</span>

Dual quoting

Some languages, such as Fortran, Modula-2, JavaScript, Python, and PHP allow more than one quoting delimiter; in the case of two possible delimiters, this is known as dual quoting. Typically, this consists of allowing the programmer to use either single quotations or double quotations interchangeably – each literal must use one or the other.

<span id="mw5g"></span> <span class="s2" id="mw5w">"This is John's apple."</span> <span class="s1" id="mw6A">'I said, "Can you hear me?"'</span>

This does not allow having a single literal with both delimiters in it, however. This can be worked around by using several literals and using string concatenation:

<span id="mw7Q"></span> <span class="s1" id="mw7g">'I said, "This is '</span> <span class="o" id="mw7w">+</span> <span class="s2" id="mw8A">"John's"</span> <span class="o" id="mw8Q">+</span> <span class="s1" id="mw8g">' apple."'</span>

Python has string literal concatenation, so consecutive string literals are concatenated even without an operator, so this can be reduced to:

<span id="mw9w"></span> <span class="s1" id="mw-A">'I said, "This is '</span><span class="s2" id="mw-Q">"John's"</span><span class="s1" id="mw-g">' apple."'</span>

Delimiter quoting

C++11 introduced so-called raw string literals. They consist, essentially of

R" end-of-string-id ( content ) end-of-string-id ",

that is, after R" the programmer can enter up to 16 characters except whitespace characters, parentheses, or backslash, which form the end-of-string-id (its purpose is to be repeated to signal the end of the string, eos id for short), then an opening parenthesis (to denote the end of the eos id) is required. Then follows the actual content of the literal: Any sequence characters may be used (except that it may not contain a closing parenthesis followed by the eos id followed a quote), and finally – to terminate the string – a closing parenthesis, the eos id, and a quote is required.
The simplest case of such a literal is with empty content and empty eos id: R"()".
The eos id may itself contain quotes: R""(I asked, "Can you hear me?")"" is a valid literal (the eos id is " here.)
Escape sequences don't work in raw string literals.

D supports a few quoting delimiters, with such strings starting with q" plus an opening delimiter and ending with the respective closing delimiter and ". Available delimiter pairs are (), <>, {}, and []; an unpaired non-identifier delimiter is its own closing delimiter. The paired delimiters nest, so that q"(A pair "()" of parens in quotes)" is a valid literal; an example with the non-nesting / character is q"/I asked, "Can you hear me?"/".
Similar to C++11, D allows here-document-style literals with end-of-string ids:

q" end-of-string-id newline content newline end-of-string-id "

In D, the end-of-string-id must be an identifier (alphanumeric characters).

In some programming languages, such as sh and Perl, there are different delimiters that are treated differently, such as doing string interpolation or not, and thus care must be taken when choosing which delimiter to use; see the section on different kinds of strings below.

Multiple quoting

A further 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:

<span id="mwATY"></span><span class="sx" id="mwATc">qq^I said, "Can you hear me?"^</span> <span class="sx" id="mwATg">qq@I said, "Can you hear me?"@</span> <span class="sx" id="mwATk">qq§I said, "Can you hear me?"§</span>

all produce the desired result. Although this notation is more flexible, few languages support it; other than Perl, Ruby (influenced by Perl) and C++11 also support these. A variant of multiple quoting is the use of here document-style strings.

Lua (as of 5.1) provides a limited form of multiple quoting, particularly to allow nesting of long comments or embedded strings. Normally one uses [[ and ]] to delimit literal strings (initial newline stripped, otherwise raw), but the opening brackets can include any number of equal signs, and only closing brackets with the same number of signs close the string. For example:

<span id="mwAUM"></span><span class="kd" id="mwAUQ">local</span><span class="w" id="mwAUU"> </span><span class="nv" id="mwAUY">ls</span><span class="w" id="mwAUc"> </span><span class="o" id="mwAUg">=</span><span class="w" id="mwAUk"> </span><span class="s" id="mwAUo">[=[</span> <span class="s" id="mwAUs">This notation can be used for Windows paths: </span> <span class="s" id="mwAUw">local path = [[C:\Windows\Fonts]]</span> <span class="s" id="mwAU0">]=]</span>

Multiple quoting is particularly useful with regular expressions that contain usual delimiters such as quotes, as this avoids needing to escape them. An early example is sed, where in the substitution command s/regex/replacement/ the default slash / delimiters can be replaced by another character, as in s,regex,replacement, .

Constructor functions

Another option, which is rarely used in modern languages, is to use a function to construct a string, rather than representing it via a literal. This is generally not used in modern languages because the computation is done at run time, rather than at parse time.

For example, early forms of BASIC did not include escape sequences or any other workarounds listed here, and thus one instead was required to use the CHR$ function, which returns a string containing the character corresponding to its argument. In ASCII the quotation mark has the value 34, so to represent a string with quotes on an ASCII system one would write

<span id="mwAWA"></span><span class="s2" id="mwAWE">"I said, "</span><span class="w" id="mwAWI"> </span><span class="o" id="mwAWM">+</span><span class="w" id="mwAWQ"> </span><span class="kr" id="mwAWU">CHR$</span><span class="p" id="mwAWY">(</span><span class="il" id="mwAWc">34</span><span class="p" id="mwAWg">)</span><span class="w" id="mwAWk"> </span><span class="o" id="mwAWo">+</span><span class="w" id="mwAWs"> </span><span class="s2" id="mwAWw">"Can you hear me?"</span><span class="w" id="mwAW0"> </span><span class="o" id="mwAW4">+</span><span class="w" id="mwAW8"> </span><span class="kr" id="mwAXA">CHR$</span><span class="p" id="mwAXE">(</span><span class="il" id="mwAXI">34</span><span class="p" id="mwAXM">)</span>

In C, a similar facility is available via sprintf and the %c "character" format specifier, though in the presence of other workarounds this is generally not used:

<span id="mwAXo"></span><span class="kt" id="mwAXs">char</span><span class="w" id="mwAXw"> </span><span class="n" id="mwAX0">buffer</span><span class="p" id="mwAX4">[</span><span class="mi" id="mwAX8">32</span><span class="p" id="mwAYA">];</span> <span class="n" id="mwAYE">snprintf</span><span class="p" id="mwAYI">(</span><span class="n" id="mwAYM">buffer</span><span class="p" id="mwAYQ">,</span><span class="w" id="mwAYU"> </span><span class="k" id="mwAYY">sizeof</span><span class="w" id="mwAYc"> </span><span class="n" id="mwAYg">buffer</span><span class="p" id="mwAYk">,</span><span class="w" id="mwAYo"> </span><span class="s" id="mwAYs">"This is %cin quotes.%c"</span><span class="p" id="mwAYw">,</span><span class="w" id="mwAY0"> </span><span class="mi" id="mwAY4">34</span><span class="p" id="mwAY8">,</span><span class="w" id="mwAZA"> </span><span class="mi" id="mwAZE">34</span><span class="p" id="mwAZI">);</span>

These constructor functions can also be used to represent nonprinting characters, though escape sequences are generally used instead. A similar technique can be used in C++ with the std::string stringification operator.

Escape sequences

Escape sequences are a general technique for representing characters that are otherwise difficult to represent directly, including delimiters, nonprinting characters (such as backspaces), newlines, and whitespace characters (which are otherwise impossible to distinguish visually), and have a long history. They are accordingly widely used in string literals, and adding an escape sequence (either to a single character or throughout a string) is known as escaping.

One character is chosen as a prefix to give encodings for characters that are difficult or impossible to include directly. Most commonly this is backslash; in addition to other characters, a key point is that backslash itself can be encoded as a double backslash \\ and for delimited strings the delimiter itself can be encoded by escaping, say by \" for ". A regular expression for such escaped strings can be given as follows, as found in the ANSI C specification:

"<code style="background:none; border:none; color:inherit; padding: 0px 0px;" class="mw-highlight mw-highlight-lang-c mw-content-ltr" dir="ltr" typeof="mw:Extension/syntaxhighlight" about="#mwt55" data-mw='{"name":"syntaxhighlight","attrs":{"lang":"c","style":"background:none; border:none; color:inherit; padding: 0px 0px;","inline":""},"body":{"extsrc":"(\\\\.|[^\\\\\"])*"}}' id="mwAag"><span class="p" id="mwAak">(</span><span class="err" id="mwAao">\\</span><span class="p" id="mwAas">.</span><span class="o" id="mwAaw">|</span><span class="p" id="mwAa0">[</span><span class="o" id="mwAa4">^</span><span class="err" id="mwAa8">\\</span><span class="s" id="mwAbA">"])*</span></code>"

meaning "a quote; followed by zero or more of either an escaped character (backslash followed by something, possibly backslash or quote), or a non-escape, non-quote character; ending in a quote" – the only issue is distinguishing the terminating quote from a quote preceded by a backslash, which may itself be escaped. Multiple characters can follow the backslash, such as \uFFFF, depending on the escaping scheme.

An escaped string must then itself be lexically analyzed, converting the escaped string into the unescaped string that it represents. This is done during the evaluation phase of the overall lexing of the computer language: the evaluator of the lexer of the overall language executes its own lexer for escaped string literals.

Among other things, it must be possible to encode the character that normally terminates the string constant, plus there must be some way to specify the escape character itself. Escape sequences are not always pretty or easy to use, so many compilers also offer other means of solving the common problems. Escape sequences, however, solve every delimiter problem and most compilers interpret escape sequences. When an escape character is inside a string literal, it means "this is the start of the escape sequence". Every escape sequence specifies one character which is to be placed directly into the string. The actual number of characters required in an escape sequence varies. The escape character is on the top/left of the keyboard, but the editor will translate it, therefore it is not directly tapeable into a string. The backslash is used to represent the escape character in a string literal.

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 code unit with the specified value in the literal's encoding (for example, the corresponding ASCII code for an ASCII literal). This was later extended to allow more modern hexadecimal character code notation:

<span id="mwAcI"></span><span class="s" id="mwAcM">"I said,</span><span class="se" id="mwAcQ">\t\t\x22Ca</span><span class="s" id="mwAcU">n you hear me?</span><span class="se" id="mwAcY">\x22\n</span><span class="s" id="mwAcc">"</span>

Note: Not all sequences in the list are supported by all parsers, and there may be other escape sequences which are not in the list.

Nested escaping

When code in one programming language is embedded inside another, embedded strings may require multiple levels of escaping. This is particularly common in regular expressions and SQL query within other languages, or other languages inside shell scripts. This double-escaping is often difficult to read and author.

Incorrect quoting of nested strings can present a security vulnerability. Use of untrusted data, as in data fields of an SQL query, should use prepared statements to prevent a code injection attack. In PHP 2 through 5.3, there was a feature called magic quotes which automatically escaped strings (for convenience and security), but due to problems was removed from version 5.4 onward.

Raw strings

A few languages provide a method of specifying that a literal is to be processed without any language-specific interpretation. This avoids the need for escaping, and yields more legible strings.

Raw strings are particularly useful when a common character needs to be escaped, notably in regular expressions (nested as string literals), where backslash \ is widely used, and in DOS/Windows paths, where backslash is used as a path separator. The profusion of backslashes is known as leaning toothpick syndrome, and can be reduced by using raw strings. Compare escaped and raw pathnames in C#:

<span id="mwAq8"></span><span class="w" id="mwArA"> </span><span class="s" id="mwArE">"The Windows path is C:\\Foo\\Bar\\Baz\\"</span> <span class="w" id="mwArI"> </span><span class="s" id="mwArM">@"The Windows path is C:\Foo\Bar\Baz\"</span>

Extreme examples occur when these are combined – Uniform Naming Convention paths begin with \\, and thus an escaped regular expression matching a UNC name begins with 8 backslashes, "\\\\\\\\", due to needing to escape the string and the regular expression. Using raw strings reduces this to 4 (escaping in the regular expression), as in C# @"\\\\".

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.

<span id="mwAr8"></span><span class="cp" id="mwAsA"><![CDATA[ if (path!=null && depth<2) { add(path); } ]]></span>

Multiline string literals

In many languages, string literals can contain literal newlines, spanning several lines. Alternatively, newlines can be escaped, most often as \n. For example:

<span id="mwAsY"></span><span class="nb" id="mwAsc">echo</span><span class="w" id="mwAsg"> </span><span class="s1" id="mwAsk">'foo</span> <span class="s1" id="mwAso">bar'</span>

and

<span id="mwAs4"></span><span class="nb" id="mwAs8">echo</span><span class="w" id="mwAtA"> </span>-e<span class="w" id="mwAtE"> </span><span class="s2" id="mwAtI">"foo\nbar"</span>

are both valid BASH statements, both producing the same output:

foo bar

Languages that allow literal newlines include BASH, Lua, Perl, PHP, R, and Tcl. In some other languages string literals cannot include newlines.

Two issues with multiline string literals are leading and trailing newlines, and indentation. If the initial or final delimiters are on separate lines, there are extra newlines, while if they are not, the delimiter makes the string harder to read, particularly for the first line, which is often indented differently from the rest. Further, the literal must be unindented, as leading whitespace is preserved – this breaks the flow of the code if the literal occurs within indented code.

The most common solution for these problems is here document-style string literals. Formally speaking, a here document is not a string literal, but instead a stream literal or file literal. These originate in shell scripts and allow a literal to be fed as input to an external command. The opening delimiter is <<END where END can be any word, and the closing delimiter is END on a line by itself, serving as a content boundary – the << is due to redirecting stdin from the literal. Due to the delimiter being arbitrary, these also avoid the problem of delimiter collision. These also allow initial tabs to be stripped via the variant syntax <<-END though leading spaces are not stripped. The same syntax has since been adopted for multiline string literals in a number of languages, most notably Perl, and are also referred to as here documents, and retain the syntax, despite being strings and not involving redirection. As with other string literals, these can sometimes have different behavior specified, such as variable interpolation.

Python, whose usual string literals do not allow literal newlines, instead has a special form of string, designed for multiline literals, called triple quoting. These use a tripled delimiter, either ''' or """. These literals are especially used for inline documentation, known as docstrings.

Tcl allows literal newlines in strings and has no special syntax to assist with multiline strings, though delimiters can be placed on lines by themselves and leading and trailing newlines stripped via string trim, while string map can be used to strip indentation.

String literal concatenation

A few languages provide string literal concatenation, where adjacent string literals are implicitly joined into a single literal at compile time. This is a feature of C, C++, D, Ruby, and Python, which copied it from C. Notably, this concatenation happens at compile time, during lexical analysis (as a phase following initial tokenization), and is contrasted with both run time string concatenation (generally with the + operator) and concatenation during constant folding, which occurs at compile time, but in a later phase (after phrase analysis or "parsing"). Most languages, such as C#, Java and Perl, do not support implicit string literal concatenation, and instead require explicit concatenation, such as with the + operator (this is also possible in D and Python, but illegal in C/C++ – see below); in this case concatenation may happen at compile time, via constant folding, or may be deferred to run time.

Motivation

In C, where the concept and term originate, string literal concatenation was introduced for two reasons:

• To allow long strings to span multiple lines with proper indentation in contrast to line continuation, which destroys the indentation scheme; and
• To allow the construction of string literals by macros (via stringizing).

In practical terms, this allows string concatenation in early phases of compilation ("translation", specifically as part of lexical analysis), without requiring phrase analysis or constant folding. For example, the following is valid C:

<span id="mwAzY"></span><span class="kt" id="mwAzc">char</span><span class="w" id="mwAzg"> </span><span class="n" id="mwAzk">s</span><span class="p" id="mwAzo">[]</span><span class="w" id="mwAzs"> </span><span class="o" id="mwAzw">=</span><span class="w" id="mwAz0"> </span><span class="s" id="mwAz4">"hello, "</span><span class="w" id="mwAz8"> </span><span class="s" id="mwA0A">"world"</span><span class="p" id="mwA0E">;</span> <span class="n" id="mwA0I">printf</span><span class="p" id="mwA0M">(</span><span class="s" id="mwA0Q">"hello, "</span><span class="w" id="mwA0U"> </span><span class="s" id="mwA0Y">"world"</span><span class="p" id="mwA0c">);</span>

However, the following is invalid:

<span id="mwA0s"></span><span class="kt" id="mwA0w">char</span><span class="w" id="mwA00"> </span><span class="n" id="mwA04">s</span><span class="p" id="mwA08">[]</span><span class="w" id="mwA1A"> </span><span class="o" id="mwA1E">=</span><span class="w" id="mwA1I"> </span><span class="s" id="mwA1M">"hello, "</span><span class="w" id="mwA1Q"> </span><span class="o" id="mwA1U">+</span><span class="w" id="mwA1Y"> </span><span class="s" id="mwA1c">"world"</span><span class="p" id="mwA1g">;</span> <span class="n" id="mwA1k">printf</span><span class="p" id="mwA1o">(</span><span class="s" id="mwA1s">"hello, "</span><span class="w" id="mwA1w"> </span><span class="o" id="mwA10">+</span><span class="w" id="mwA14"> </span><span class="s" id="mwA18">"world"</span><span class="p" id="mwA2A">);</span>

This is because string literals have array type, char[] (C) or const char[] (C++), which cannot be added; this is not a restriction in most other languages. Do note that operator+ is overloaded for string literals in C++.

This is particularly important when used in combination with the C preprocessor, to allow strings to be computed following preprocessing, particularly in macros. As a simple example:

<span id="mwA28"></span><span class="kt" id="mwA3A">char</span><span class="w" id="mwA3E"> </span><span class="n" id="mwA3I">file_and_message</span><span class="p" id="mwA3M">[]</span><span class="w" id="mwA3Q"> </span><span class="o" id="mwA3U">=</span><span class="w" id="mwA3Y"> </span><span class="n" id="mwA3c">__FILE__</span><span class="w" id="mwA3g"> </span><span class="s" id="mwA3k">": message"</span><span class="p" id="mwA3o">;</span>

will (if the file is called a.c) expand to:

<span id="mwA34"></span><span class="kt" id="mwA38">char</span><span class="w" id="mwA4A"> </span><span class="n" id="mwA4E">file_and_message</span><span class="p" id="mwA4I">[]</span><span class="w" id="mwA4M"> </span><span class="o" id="mwA4Q">=</span><span class="w" id="mwA4U"> </span><span class="s" id="mwA4Y">"a.c"</span><span class="w" id="mwA4c"> </span><span class="s" id="mwA4g">": message"</span><span class="p" id="mwA4k">;</span>

which is then concatenated, being equivalent to:

<span id="mwA40"></span><span class="kt" id="mwA44">char</span><span class="w" id="mwA48"> </span><span class="n" id="mwA5A">file_and_message</span><span class="p" id="mwA5E">[]</span><span class="w" id="mwA5I"> </span><span class="o" id="mwA5M">=</span><span class="w" id="mwA5Q"> </span><span class="s" id="mwA5U">"a.c: message"</span><span class="p" id="mwA5Y">;</span>

A common use case is in constructing printf() or scanf() format strings, where format specifiers are given by macros.

A more complex example uses stringification of integers (by the preprocessor) to define a macro that expands to a sequence of string literals, which are then concatenated to a single string literal with the file name and line number:

<span id="mwA6s"></span><span class="cp" id="mwA6w">#define STRINGIFY(x) #x</span> <span class="cp" id="mwA60">#define TOSTRING(x) STRINGIFY(x)</span> <span class="cp" id="mwA64">#define AT __FILE__ ":" TOSTRING(__LINE__)</span>

Beyond syntactic requirements of C/C++, implicit concatenation is a form of syntactic sugar, making it simpler to split string literals across several lines, avoiding the need for line continuation (via backslashes) and allowing one to add comments to parts of strings. For example, in Python, one can comment a regular expression in this way:

<span id="mwA7g"></span><span class="kn" id="mwA7k">import</span><span class="w" id="mwA7o"> </span><span class="nn" id="mwA7s">re</span> <span class="kn" id="mwA7w">from</span><span class="w" id="mwA70"> </span><span class="nn" id="mwA74">re</span><span class="w" id="mwA78"> </span><span class="kn" id="mwA8A">import</span> <span class="n" id="mwA8E">Pattern</span> <span class="n" id="mwA8I">pattern</span><span class="p" id="mwA8M">:</span> <span class="n" id="mwA8Q">Pattern</span> <span class="o" id="mwA8U">=</span> <span class="n" id="mwA8Y">re</span><span class="o" id="mwA8c">.</span><span class="n" id="mwA8g">compile</span><span class="p" id="mwA8k">(</span> <span class="s2" id="mwA8o">"[A-Za-z_]"</span> <span class="c1" id="mwA8s"># letter or underscore</span> <span class="s2" id="mwA8w">"[A-Za-z0-9_]*"</span> <span class="c1" id="mwA80"># letter, digit or underscore</span> <span class="p" id="mwA84">)</span>

Problems

Implicit string concatenation is not required by modern compilers, which implement constant folding, and causes hard-to-spot errors due to unintentional concatenation from omitting a comma, particularly in horizontal lists of strings, as in:

<span id="mwA9M"></span><span class="n" id="mwA9Q">l</span><span class="p" id="mwA9U">:</span> <span class="nb" id="mwA9Y">list</span><span class="p" id="mwA9c">[</span><span class="nb" id="mwA9g">str</span><span class="p" id="mwA9k">]</span> <span class="o" id="mwA9o">=</span> <span class="p" id="mwA9s">[</span><span class="s2" id="mwA9w">"foo"</span><span class="p" id="mwA90">,</span> <span class="s2" id="mwA94">"bar"</span> <span class="s2" id="mwA98">"zork"</span><span class="p" id="mwA-A">]</span>

Accordingly, it is not used in most languages, and it has been proposed for deprecation from D and Python. However, removing the feature breaks backwards compatibility, and replacing it with a concatenation operator introduces issues of precedence – string literal concatenation occurs during lexing, prior to operator evaluation, but concatenation via an explicit operator occurs at the same time as other operators, hence precedence is an issue, potentially requiring parentheses to ensure desired evaluation order.

A subtler issue is that in C and C++, there are different types of string literals, and concatenation of these has implementation-defined behavior, which poses a potential security risk.

Different kinds of strings

Some languages provide more than one kind of literal, which have different behavior. This is particularly used to indicate raw strings (no escaping), or to disable or enable variable interpolation, but has other uses, such as distinguishing character sets. Most often this is done by changing the quoting character or adding a prefix or suffix. This is comparable to prefixes and suffixes to integer literals, such as to indicate hexadecimal numbers or long integers.

One of the oldest examples is in shell scripts, where single quotes indicate a raw string or "literal string", while double quotes have escape sequences and variable interpolation.

For example, in Python, raw strings are preceded by an r or R – compare 'C:\\Windows' with r'C:\Windows' (though, a Python raw string cannot end in an odd number of backslashes). Python 2 also distinguishes two types of strings: 8-bit ASCII ("bytes") strings (the default), explicitly indicated with a b or B prefix, and Unicode strings, indicated with a u or U prefix. while in Python 3 strings are Unicode by default and bytes are a separate bytes type that when initialized with quotes must be prefixed with a b.

C#'s notation for raw strings is called @-quoting.

<span id="mwBAw"></span><span class="s" id="mwBA0">@"C:\Foo\Bar\Baz\"</span>

While this disables escaping, it allows double-up quotes, which allow one to represent quotes within the string:

<span id="mwBBE"></span><span class="s" id="mwBBI">@"I said, ""Hello there."""</span>

C++11 allows raw strings, unicode strings (UTF-8, UTF-16, and UTF-32), and wide character strings, determined by prefixes. It also adds literals for the existing C++ string, which is generally preferred to the existing C-style strings.

In Tcl, brace-delimited strings are literal, while quote-delimited strings have escaping and interpolation.

Perl has a wide variety of strings, which are more formally considered operators, and are known as quote and quote-like operators. These include both a usual syntax (fixed delimiters) and a generic syntax, which allows a choice of delimiters. These include:

<span id="mwBB8"></span><span class="s" id="mwBCA">''</span><span class="w" id="mwBCE"> </span><span class="s" id="mwBCI">""</span><span class="w" id="mwBCM"> </span><span class="sb" id="mwBCQ">``</span><span class="w" id="mwBCU"> </span><span class="sr" id="mwBCY">//</span><span class="w" id="mwBCc"> </span><span class="sr" id="mwBCg">m//</span><span class="w" id="mwBCk"> </span><span class="sx" id="mwBCo">qr//</span><span class="w" id="mwBCs"> </span><span class="sr" id="mwBCw">s///</span><span class="w" id="mwBC0"> </span><span class="n" id="mwBC4">y</span><span class="sr" id="mwBC8">//</span><span class="o" id="mwBDA">/</span> <span class="sx" id="mwBDE">q{}</span><span class="w" id="mwBDI"> </span><span class="sx" id="mwBDM">qq{}</span><span class="w" id="mwBDQ"> </span><span class="sx" id="mwBDU">qx{}</span><span class="w" id="mwBDY"> </span><span class="sx" id="mwBDc">qw{}</span><span class="w" id="mwBDg"> </span><span class="sr" id="mwBDk">m{}</span><span class="w" id="mwBDo"> </span><span class="sx" id="mwBDs">qr{}</span><span class="w" id="mwBDw"> </span><span class="sr" id="mwBD0">s{}{}</span><span class="w" id="mwBD4"> </span><span class="nb" id="mwBD8">tr</span><span class="p" id="mwBEA">{}{}</span><span class="w" id="mwBEE"> </span><span class="n" id="mwBEI">y</span><span class="p" id="mwBEM">{}{}</span>

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

<span id="mwBEg"></span><span class="s" id="mwBEk">'20'</span>x <span class="s" id="mwBEo">"0010 0000"</span>b <span class="s" id="mwBEs">"00100000"</span>b

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

String interpolation

In some languages, string literals may contain placeholders referring to variables or expressions in the current context, which are evaluated (usually at run time). This is referred to as variable interpolation, or more generally string interpolation. Languages that support interpolation generally distinguish strings literals that are interpolated from ones that are not. For example, in sh-compatible Unix shells (as well as Perl and Ruby), double-quoted (quotation-delimited, ") strings are interpolated, while single-quoted (apostrophe-delimited, ') strings are not. Non-interpolated string literals are sometimes referred to as "raw strings", but this is distinct from "raw string" in the sense of escaping. For example, in Python, a string prefixed with r or R is called raw string and has no escaping or interpolation, a normal string (no prefix) has escaping but no interpolation, and a string prefixed with f or F is called f-string and has escaping and interpolation.

For example, the following Perl code:

<span id="mwBHQ"></span><span class="nv" id="mwBHU">$name</span><span class="w" id="mwBHY"> </span><span class="o" id="mwBHc">=</span><span class="w" id="mwBHg"> </span><span class="s" id="mwBHk">"Nancy"</span><span class="p" id="mwBHo">;</span> <span class="nv" id="mwBHs">$greeting</span><span class="w" id="mwBHw"> </span><span class="o" id="mwBH0">=</span><span class="w" id="mwBH4"> </span><span class="s" id="mwBH8">"Hello World"</span><span class="p" id="mwBIA">;</span> <span class="k" id="mwBIE">print</span><span class="w" id="mwBII"> </span><span class="s" id="mwBIM">"$name said $greeting to the crowd of people."</span><span class="p" id="mwBIQ">;</span>

produces the output:

Nancy said Hello World to the crowd of people.

In this case, the metacharacter character ($) (not to be confused with the sigil in the variable assignment statement) is interpreted to indicate variable interpolation, and requires some escaping if it needs to be outputted literally.

This should be contrasted with the printf function, which produces the same output using notation such as:

<span id="mwBI8"></span><span class="nb" id="mwBJA">printf</span><span class="w" id="mwBJE"> </span><span class="s" id="mwBJI">"%s said %s to the crowd of people."</span><span class="p" id="mwBJM">,</span><span class="w" id="mwBJQ"> </span><span class="nv" id="mwBJU">$name</span><span class="p" id="mwBJY">,</span><span class="w" id="mwBJc"> </span><span class="nv" id="mwBJg">$greeting</span><span class="p" id="mwBJk">;</span>

but does not perform interpolation: the %s is a placeholder in a printf format string, but the variables themselves are outside the string.

This is contrasted with "raw" strings:

<span id="mwBKA"></span><span class="k" id="mwBKE">print</span><span class="w" id="mwBKI"> </span><span class="s" id="mwBKM">'$name said $greeting to the crowd of people.'</span><span class="p" id="mwBKQ">;</span>

which produce output like:

$name said $greeting to the crowd of people.

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

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.