Strings

A string is series of characters, where a character is
the same as a byte. This means that PHP only supports a 256-character set,
and hence does not offer native Unicode support. See
details of the string
type.

Note:
As of PHP 7.0.0, there are no particular restrictions regarding the length of
a string on 64-bit builds. On 32-bit builds and in earlier
versions, a
string can be as large as up to 2GB (2147483647 bytes maximum)

Syntax

Single quoted

The simplest way to specify a string is to enclose it in single
quotes (the character ').

To specify a literal single quote, escape it with a backslash
(\). To specify a literal backslash, double it
(\\). All other instances of backslash will be treated
as a literal backslash: this means that the other escape sequences you
might be used to, such as \r or \n,
will be output literally as specified rather than having any special
meaning.

// Outputs: This will not expand: \n a newlineecho 'This will not expand: \n a newline';

// Outputs: Variables do not $expand $eitherecho 'Variables do not $expand $either';?>

Double quoted

If the string is enclosed in double-quotes ("), PHP will
interpret the following escape sequences for special characters:

Escaped characters

Sequence

Meaning

\n

linefeed (LF or 0x0A (10) in ASCII)

\r

carriage return (CR or 0x0D (13) in ASCII)

\t

horizontal tab (HT or 0x09 (9) in ASCII)

\v

vertical tab (VT or 0x0B (11) in ASCII) (since PHP 5.2.5)

\e

escape (ESC or 0x1B (27) in ASCII) (since PHP 5.4.4)

\f

form feed (FF or 0x0C (12) in ASCII) (since PHP 5.2.5)

\\

backslash

\$

dollar sign

\"

double-quote

\[0-7]{1,3}

the sequence of characters matching the regular expression is a
character in octal notation, which silently overflows to fit in a byte
(e.g. "\400" === "\000")

\x[0-9A-Fa-f]{1,2}

the sequence of characters matching the regular expression is a
character in hexadecimal notation

\u{[0-9A-Fa-f]+}

the sequence of characters matching the regular expression is a
Unicode codepoint, which will be output to the string as that
codepoint's UTF-8 representation (added in PHP 7.0.0)

As in single quoted strings, escaping any other character will
result in the backslash being printed too. Before PHP 5.1.1, the backslash
in \{$var} had not been printed.

The most important feature of double-quoted strings is the fact
that variable names will be expanded. See
string parsing for
details.

Heredoc

A third way to delimit strings is the heredoc syntax:
<<<. After this operator, an identifier is
provided, then a newline. The string itself follows, and then
the same identifier again to close the quotation.

The closing identifier must begin in the first column
of the line. Also, the identifier must follow the same naming rules as any
other label in PHP: it must contain only alphanumeric characters and
underscores, and must start with a non-digit character or underscore.

Warning

It is very important to note that the line with the closing identifier must
contain no other characters, except a semicolon (;).
That means especially that the identifier
may not be indented, and there may not be any spaces
or tabs before or after the semicolon. It's also important to realize that
the first character before the closing identifier must be a newline as
defined by the local operating system. This is \n on
UNIX systems, including Mac OS X. The closing delimiter must also be
followed by a newline.

If this rule is broken and the closing identifier is not "clean", it will
not be considered a closing identifier, and PHP will continue looking for
one. If a proper closing identifier is not found before the end of the
current file, a parse error will result at the last line.

Example #1 Invalid example

<?phpclass foo { public $bar = <<<EOTbar EOT;}// Identifier must not be indented?>

Example #2 Valid example

<?phpclass foo { public $bar = <<<EOTbarEOT;}?>

Heredocs can not be used for initializing class properties. Since PHP 5.3,
this limitation is valid only for heredocs containing variables.

Heredoc text behaves just like a double-quoted string, without
the double quotes. This means that quotes in a heredoc do not need to be
escaped, but the escape codes listed above can still be used. Variables are
expanded, but the same care must be taken when expressing complex variables
inside a heredoc as with strings.

Starting with PHP 5.3.0, the opening Heredoc identifier may optionally be
enclosed in double quotes:

Example #6 Using double quotes in Heredoc

<?phpecho <<<"FOOBAR"Hello World!FOOBAR;?>

Nowdoc

Nowdocs are to single-quoted strings what heredocs are to double-quoted
strings. A nowdoc is specified similarly to a heredoc, but no
parsing is done inside a nowdoc. The construct is ideal for
embedding PHP code or other large blocks of text without the need for
escaping. It shares some features in common with the SGML
<![CDATA[ ]]> construct, in that it declares a
block of text which is not for parsing.

A nowdoc is identified with the same <<<
sequence used for heredocs, but the identifier which follows is enclosed in
single quotes, e.g. <<<'EOT'. All the rules for
heredoc identifiers also apply to nowdoc identifiers, especially those
regarding the appearance of the closing identifier.

echo <<<'EOT'My name is "$name". I am printing some $foo->foo.Now, I am printing some {$foo->bar[1]}.This should not print a capital 'A': \x41EOT;?>

The above example will output:

My name is "$name". I am printing some $foo->foo.
Now, I am printing some {$foo->bar[1]}.
This should not print a capital 'A': \x41

Example #8 Static data example

<?phpclass foo { public $bar = <<<'EOT'barEOT;}?>

Note:

Nowdoc support was added in PHP 5.3.0.

Variable parsing

When a string is specified in double quotes or with heredoc,
variables are parsed within it.

There are two types of syntax: a
simple one and a
complex one.
The simple syntax is the most common and convenient. It provides a way to
embed a variable, an array value, or an object
property in a string with a minimum of effort.

The complex syntax can be recognised by the
curly braces surrounding the expression.

Simple syntax

If a dollar sign ($) is encountered, the parser will
greedily take as many tokens as possible to form a valid variable name.
Enclose the variable name in curly braces to explicitly specify the end of
the name.

<?php$juice = "apple";

echo "He drank some $juice juice.".PHP_EOL;// Invalid. "s" is a valid character for a variable name, but the variable is $juice.echo "He drank some juice made of $juices.";// Valid. Explicitly specify the end of the variable name by enclosing it in braces:echo "He drank some juice made of ${juice}s.";?>

The above example will output:

He drank some apple juice.
He drank some juice made of .
He drank some juice made of apples.

Similarly, an array index or an object property
can be parsed. With array indices, the closing square bracket
(]) marks the end of the index. The same rules apply to
object properties as to simple variables.

He drank some apple juice.
He drank some orange juice.
He drank some purple juice.
John Smith drank some apple juice.
John Smith then said hello to Jane Smith.
John Smith's wife greeted Robert Paulsen.
Robert Paulsen greeted the two .

As of PHP 7.1.0 also negative numeric indices are
supported.

Example #10 Negative numeric indices

<?php$string = 'string';echo "The character at index -2 is $string[-2].", PHP_EOL;$string[-3] = 'o';echo "Changing the character at index -3 to o gives $string.", PHP_EOL;?>

The above example will output:

The character at index -2 is n.
Changing the character at index -3 to o gives strong.

For anything more complex, you should use the complex syntax.

Complex (curly) syntax

This isn't called complex because the syntax is complex, but because it
allows for the use of complex expressions.

Any scalar variable, array element or object property with a
string representation can be included via this syntax.
Simply write the expression the same way as it would appear outside the
string, and then wrap it in { and
}. Since { can not be escaped, this
syntax will only be recognised when the $ immediately
follows the {. Use {\$ to get a
literal {$. Some examples to make it clear:

// This is wrong for the same reason as $foo[bar] is wrong outside a string.// In other words, it will still work, but only because PHP first looks for a// constant named foo; an error of level E_NOTICE (undefined constant) will be// thrown.echo "This is wrong: {$arr[foo][3]}";

// Works. When using multi-dimensional arrays, always use braces around arrays// when inside of stringsecho "This works: {$arr['foo'][3]}";

// Works.echo "This works: " . $arr['foo'][3];

echo "This works too: {$obj->values[3]->name}";

echo "This is the value of the var named $name: {${$name}}";

echo "This is the value of the var named by the return value of getName(): {${getName()}}";

echo "This is the value of the var named by the return value of \$object->getName(): {${$object->getName()}}";

// Won't work, outputs: This is the return value of getName(): {getName()}echo "This is the return value of getName(): {getName()}";?>

It is also possible to access class properties using variables
within strings using this syntax.

Functions, method calls, static class variables, and class
constants inside {$} work since PHP
5. However, the value accessed will be interpreted as the name
of a variable in the scope in which the string is defined. Using
single curly braces ({}) will not work for
accessing the return values of functions or methods or the
values of class constants or static class variables.

// This works; outputs: I'd like an A & Wecho "I'd like an {${beers::softdrink}}\n";

// This works too; outputs: I'd like an Alexander Keith'secho "I'd like an {${beers::$ale}}\n";?>

String access and modification by character

Characters within strings may be accessed and modified by
specifying the zero-based offset of the desired character after the
string using square array brackets, as in
$str[42]. Think of a string as an
array of characters for this purpose. The functions
substr() and substr_replace()
can be used when you want to extract or replace more than 1 character.

Note:
As of PHP 7.1.0, negative string offsets are also supported. These specify
the offset from the end of the string.
Formerly, negative offsets emitted E_NOTICE for reading
(yielding an empty string) and E_WARNING for writing
(leaving the string untouched).

Note:
Strings may also be accessed using braces, as in
$str{42}, for the same purpose.

Warning

Writing to an out of range offset pads the string with spaces.
Non-integer types are converted to integer.
Illegal offset type emits E_NOTICE.
Only the first character of an assigned string is used.
As of PHP 7.1.0, assigning an empty string throws a fatal error. Formerly,
it assigned a NULL byte.

Warning

Internally, PHP strings are byte arrays. As a result, accessing or
modifying a string using array brackets is not multi-byte safe, and
should only be done with strings that are in a single-byte encoding such
as ISO-8859-1.

Note:
As of PHP 7.1.0, applying the empty index operator on an empty string throws a fatal
error. Formerly, the empty string was silently converted to an array.

Example #11 Some string examples

<?php// Get the first character of a string$str = 'This is a test.';$first = $str[0];

// Get the third character of a string$third = $str[2];

// Get the last character of a string.$str = 'This is still a test.';$last = $str[strlen($str)-1];

// Modify the last character of a string$str = 'Look at the sea';$str[strlen($str)-1] = 'e';

?>

As of PHP 5.4 string offsets have to either be integers or integer-like strings, otherwise a warning
will be thrown. Previously an offset like "foo" was silently cast to 0.

Converting to string

A value can be converted to a string using the
(string) cast or the strval() function.
String conversion is automatically done in the scope of an
expression where a string is needed. This happens when using the
echo or print functions, or when a
variable is compared to a string. The sections on
Types and
Type Juggling will make
the following clearer. See also the settype() function.

A booleanTRUE value is converted to the string"1". BooleanFALSE is converted to
"" (the empty string). This allows conversion back and
forth between boolean and string values.

An integer or float is converted to a
string representing the number textually (including the
exponent part for floats). Floating point numbers can be
converted using exponential notation (4.1E+6).

Note:

The decimal point character is defined in the script's locale (category
LC_NUMERIC). See the setlocale() function.

Arrays are always converted to the string"Array"; because of this, echo and
print can not by themselves show the contents of an
array. To view a single element, use a construction such as
echo $arr['foo']. See below for tips on viewing the entire
contents.

Resources are always converted to strings with the
structure "Resource id #1", where 1
is the resource number assigned to the resource by PHP at
runtime. While the exact structure of this string should not be relied on
and is subject to change, it will always be unique for a given resource
within the lifetime of a script being executed (ie a Web request or CLI
process) and won't be reused. To get a resource's type, use
the get_resource_type() function.

NULL is always converted to an empty string.

As stated above, directly converting an array,
object, or resource to a string does
not provide any useful information about the value beyond its type. See the
functions print_r() and var_dump() for
more effective means of inspecting the contents of these types.

Most PHP values can also be converted to strings for permanent
storage. This method is called serialization, and is performed by the
serialize() function. If the PHP engine was built with
WDDX support, PHP values can also be
serialized as well-formed XML text.

String conversion to numbers

When a string is evaluated in a numeric context, the resulting
value and type are determined as follows.

If the string does not contain any of the characters '.', 'e',
or 'E' and the numeric value fits into integer type limits (as defined by
PHP_INT_MAX), the string will be evaluated
as an integer. In all other cases it will be evaluated as a
float.

The value is given by the initial portion of the string. If the
string starts with valid numeric data, this will be the value
used. Otherwise, the value will be 0 (zero). Valid numeric data is an
optional sign, followed by one or more digits (optionally containing a
decimal point), followed by an optional exponent. The exponent is an 'e' or
'E' followed by one or more digits.

For more information on this conversion, see the Unix manual page for
strtod(3).

To test any of the examples in this section, cut and paste the examples and
insert the following line to see what's going on:

<?phpecho "\$foo==$foo; type is " . gettype ($foo) . "<br />\n";?>

Do not expect to get the code of one character by converting it to integer,
as is done in C. Use the ord() and
chr() functions to convert between ASCII codes and
characters.

Details of the String Type

The string in PHP is implemented as an array of bytes and an
integer indicating the length of the buffer. It has no information about how
those bytes translate to characters, leaving that task to the programmer.
There are no limitations on the values the string can be composed of; in
particular, bytes with value 0 (“NUL bytes”) are allowed
anywhere in the string (however, a few functions, said in this manual not to
be “binary safe”, may hand off the strings to libraries that ignore data
after a NUL byte.)

This nature of the string type explains why there is no separate “byte” type
in PHP – strings take this role. Functions that return no textual data – for
instance, arbitrary data read from a network socket – will still return
strings.

Given that PHP does not dictate a specific encoding for strings, one might
wonder how string literals are encoded. For instance, is the string
"á" equivalent to "\xE1" (ISO-8859-1),
"\xC3\xA1" (UTF-8, C form),
"\x61\xCC\x81" (UTF-8, D form) or any other possible
representation? The answer is that string will be encoded in whatever fashion
it is encoded in the script file. Thus, if the script is written in
ISO-8859-1, the string will be encoded in ISO-8859-1 and so on. However,
this does not apply if Zend Multibyte is enabled; in that case, the script
may be written in an arbitrary encoding (which is explicity declared or is
detected) and then converted to a certain internal encoding, which is then
the encoding that will be used for the string literals.
Note that there are some constraints on the encoding of the script (or on the
internal encoding, should Zend Multibyte be enabled) – this almost always
means that this encoding should be a compatible superset of ASCII, such as
UTF-8 or ISO-8859-1. Note, however, that state-dependent encodings where
the same byte values can be used in initial and non-initial shift states
may be problematic.

Of course, in order to be useful, functions that operate on text may have to
make some assumptions about how the string is encoded. Unfortunately, there
is much variation on this matter throughout PHP’s functions:

Some functions assume that the string is encoded in some (any) single-byte
encoding, but they do not need to interpret those bytes as specific
characters. This is case of, for instance, substr(),
strpos(), strlen() or
strcmp(). Another way to think of these functions is
that operate on memory buffers, i.e., they work with bytes and byte
offsets.

Other functions are passed the encoding of the string, possibly they also
assume a default if no such information is given. This is the case of
htmlentities() and the majority of the
functions in the mbstring extension.

Others use the current locale (see setlocale()), but
operate byte-by-byte. This is the case of strcasecmp(),
strtoupper() and ucfirst().
This means they can be used only with single-byte encodings, as long as
the encoding is matched by the locale. For instance
strtoupper("á") may return "Á" if the
locale is correctly set and á is encoded with a single
byte. If it is encoded in UTF-8, the correct result will not be returned
and the resulting string may or may not be returned corrupted, depending
on the current locale.

Finally, they may just assume the string is using a specific encoding,
usually UTF-8. This is the case of most functions in the
intl extension and in the
PCRE extension
(in the last case, only when the u modifier is used).
Although this is due to their special purpose, the function
utf8_decode() assumes a UTF-8 encoding and the
function utf8_encode() assumes an ISO-8859-1 encoding.

Ultimately, this means writing correct programs using Unicode depends on
carefully avoiding functions that will not work and that most likely will
corrupt the data and using instead the functions that do behave correctly,
generally from the intl and
mbstring extensions.
However, using functions that can handle Unicode encodings is just the
beginning. No matter the functions the language provides, it is essential to
know the Unicode specification. For instance, a program that assumes there is
only uppercase and lowercase is making a wrong assumption.

User Contributed Notes 50 notes

I've been a PHP programmer for a decade, and I've always been using the "single-quoted literal" and "period-concatenation" method of string creation. But I wanted to answer the performance question once and for all, using sufficient numbers of iterations and a modern PHP version. For my test, I used:

$outstr = "literal${n}${data}${int}${data}${float}${n}"
48500ms (fastest; the differences are small but this held true across multiple runs of the test, and this was always the fastest variable encapsulation style)

It blows my mind. The double-quoted strings "which look so $slow since they have to parse everything for \n backslashes and $dollar signs to do variable expansion", turned out to be the FASTEST string concatenation method in PHP - PERIOD!

Single-quotes are only faster if your string is completely literal (with nothing to parse in it and nothing to concatenate), but the margin is very tiny and doesn't matter.

So the "highest code performance" style rules are:

1. Always use double-quoted strings for concatenation.

2. Put your variables in "This is a {$variable} notation", because it's the fastest method which still allows complex expansions like "This {$var['foo']} is {$obj->awesome()}!". You cannot do that with the "${var}" style.

3. Feel free to use single-quoted strings for TOTALLY literal strings such as array keys/values, variable values, etc, since they are a TINY bit faster when you want literal non-parsed strings. But I had to do 1 billion iterations to find a 1.55% measurable difference. So the only real reason I'd consider using single-quoted strings for my literals is for code cleanliness, to make it super clear that the string is literal.

4. If you think another method such as sprintf() or 'this'.$var.'style' is more readable, and you don't care about maximizing performance, then feel free to use whatever concatenation method you prefer!

However, you cannot do this for all values in your namespace. Class constants and static properties/methods will not work because the complex syntax looks for the '$'.<?phpclass Test { const ONE = 1;}echo "foo {Test::ONE} bar";?>This will output "foo {Test::one} bar". Constants and static properties require you to break up the string.

I have a personal preference for the last variation as it is more natural and closer to what the expression would be like outside the string.

It’s not clear (to me, at least) why PHP misinterprets the single quote inside the expression but I imagine that it has something to do with the fact quotes are not part of the value string — once the string is already being parsed the quotes just get in the way … ?

Leading zeroes in strings are (least-surprise) not treated as octal.Consider: $x = "0123" + 0; $y = 0123 + 0; echo "x is $x, y is $y"; //prints "x is 123, y is 83"in other words: * leading zeros in numeric literals in the source-code are interpreted as "octal", c.f. strtol(). * leading zeros in strings (eg user-submitted data), when cast (implicitly or explicitly) to integer are ignored, and considered as decimal, c.f. strtod().

However, PHP's behaviour differs even from the strtod's. The documentation says that if the string contains a "e" or "E" character, it will be parsed as a float, and suggests to see the manual for strtod for more information. The manual says

«A hexadecimal number consists of a "0x" or "0X" followed by a nonempty sequence of hexadecimal digits possibly containing a radix character, optionally followed by a binary exponent. A binary exponent consists of a 'P' or 'p', followed by an optional plus or minus sign, followed by a nonempty sequence of decimal digits, and indicates multiplication by a power of 2.»

But it seems that PHP does not recognise the exponent or the radix character.

<?phpecho "0xEp4" + 1; // 15?>

strtod also uses the current locale to choose the radix character, but PHP ignores the locale, and the radix character is always 2E. However, PHP uses the locale while converting numbers to strings.

With strtod, the current locale is also used to choose the space characters, I don't know about PHP.

A word of caution about taking the use of single and double quotes shown here too literally.

A convention is established early on, referring to double-quotes (") and semicolon (;) for example, so the later section about concatenation using the '.' (dot) operator seems to indicate the dot must be enclosed by single quotes.

This tripped me up until I mentally reparsed it as the dot (.) operator.

Use caution when you need white space at the end of a heredoc. Not only is the mandatory final newline before the terminating symbol stripped, but an immediately preceding newline or space character is also stripped.

For example, in the following, the final space character (indicated by \s -- that is, the "\s" is not literally in the text, but is only used to indicate the space character) is stripped:

$string = <<<EOTthis is a string with a terminating space\sEOT;

In the following, there will only be a single newline at the end of the string, even though two are shown in the text:

$string = <<<EOTthis is a string that must befollowed by a single newline

If you want to use a variable in an array index within a double quoted string you have to realize that when you put the curly braces around the array, everything inside the curly braces gets evaluated as if it were outside a string. Here are some examples:

<?php$i = 0;$myArray[Person0] = Bob;$myArray[Person1] = George;

// prints Bob (the ++ is used to emphasize that the expression inside the {} is really being evaluated.)echo "{$myArray['Person'.$i++]}<br>";

I encountered the odd situation of having a string containing unexpanded escape sequences that I wanted to expand, but also contained dollar signs that would be interpolated as variables. "$5.25\n", for example, where I want to convert \n to a newline, but don't want attempted interpolation of $5.

Some muddling through docs and many obscenties later, I produced the following, which expands escape sequences in an existing string with NO interpolation.

Heredoc literals delete any trailing space (tabs and blanks) on each line. This is unexpected, since quoted strings do not do this. This is probably done for historical reasons, so would not be considered a bug.

I noticed that the documentation does not mention that when you have an XML element which contains a dash (-) in its name can only be accessed using the bracelets notation.For example:<xml version="1"><root> <element-one>value4element-one</element-one></root>

to access the above 'element-one' using SimpleXML you need to use the following:

Regarding the lack of complex expression interpolation, just assign an identity function to a variable and call it:

function id($arg) { return $arg; }

$expr = id;

echo "Field is: {$expr( "1 ". ucfirst('whatzit')) }";

It is slower due to an additional function call, but it does avoid the assignment of a one-shot temporary variable. When there are a lot of very simple value transformations made just for display purposes, it can de-clutter code.

So, if you put a "real" semicolon at the end of these examples:<?php $a=5;$foo="String";$bar=array();$yep=null;$other=func();?>Why shouldn't you put at the end of heredocs and nowdocs?After all, a heredoc or a nowdoc is simply a string.

You should read more carefully the documentation first before saying any comment.

About serious questions:I didn't read all comments here, but you can run functions inside strings and heredocs.

The docs say: "Heredoc text behaves just like a double-quoted string, without the double quotes" but there is a notable hidden exception to that rule: the final newline in the string (the one before closing heredoc token) is elided. i.e. if you have:

$foo = <<<EOFabcEOF;

the result is equivalent to "a\nb\nc", NOT "a\nb\nc\n" like the docs imply.

There may still be some way to kludge the syntax to allow constants and unbound function calls inside a double-quoted string, but it isn't readily apparent to me at the moment, and I'm not sure I'd prefer the workaround over breaking out of the string at this point.

It may be obvious to some, but it's convenient to note that variables _will_ be expanded inside of single quotes if these occur inside of a double-quoted string. This can be handy in constructing exec calls with complex data to be passed to other programs. e.g.:

the error control operator is pretty handy for supressing minimal errors or omissions. For example an email form that request some basic non mandatory information to your users. Some may complete the form, other may not. Lets say you don't want to tweak PHP for error levels and you just wish to create some basic template that will be emailed to the admin with the user information submitted. You manage to collect the user input in an array called $form:

If you require a NowDoc but don't have support for them on your server -- since your PHP version is less than PHP 5.3.0 -- and you are in need of a workaround, I'd suggest using PHP's __halt_compiler() which is basically a knock-off of Perl's __DATA__ token if you are familiar with it.

Give this a run to see my suggestion in action:

<?php//set $nowDoc to a string containing a code snippet for the user to read$nowDoc = file_get_contents(__FILE__,null,null,__COMPILER_HALT_OFFSET__);$nowDoc=highlight_string($nowDoc,true);

In Example #8, above, consider the risk to the script if a programmer were to define('koolaid1', 'XYZ'); For this reason it's wise to use quotes around literal-string associative array keys. As written without quotes, PHP should raise a Notice.

Almost every editor (even VIM) will break the syntax highlighting on the case where you have two forward slashes in a string. Which is perfectly valid in php. In fact, you are likely to have tons of that because of URLs.