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.

例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 character at index -2 is n.
Changing the character at index -3 to o gives strong.

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.

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

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.

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.

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:

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.

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.

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.

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.

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.