Illegal string offset php ошибка

php -v

PHP 7.0.12 (cli) (built: Oct 14 2016 09:56:59) ( NTS )

Copyright (c) 1997-2016 The PHP Group

Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies

------ Results: -------

* 100 million iterations:

$outstr = 'literal' . $n . $data . $int . $data . $float . $n;

63608ms (34.7% slower)

$outstr = "literal$n$data$int$data$float$n";

47218ms (fastest)

$outstr =<<<EOS

literal$n$data$int$data$float$n

EOS;

47992ms (1.64% slower)

$outstr = sprintf('literal%s%s%d%s%f%s', $n, $data, $int, $data, $float, $n);

76629ms (62.3% slower)

$outstr = sprintf('literal%s%5$s%2$d%3$s%4$f%s', $n, $int, $data, $float, $data, $n);

96260ms (103.9% slower)

* 10 million iterations (test adapted to see which of the two fastest methods were faster at adding a newline; either the PHP_EOL literal, or the n string expansion):

$outstr = 'literal' . $n . $data . $int . $data . $float . $n;

6228ms (reference for single-quoted without newline)

$outstr = "literal$n$data$int$data$float$n";

4653ms (reference for double-quoted without newline)

$outstr = 'literal' . $n . $data . $int . $data . $float . $n . PHP_EOL;

6630ms (35.3% slower than double-quoted with n newline)

$outstr = "literal$n$data$int$data$float$nn";

4899ms (fastest at newlines)

* 100 million iterations (a test intended to see which one of the two ${var} and {$var} double-quote styles is faster):

$outstr = 'literal' . $n . $data . $int . $data . $float . $n;

67048ms (38.2% slower)

$outstr = "literal$n$data$int$data$float$n";

49058ms (1.15% slower)

$outstr = "literal{$n}{$data}{$int}{$data}{$float}{$n}"

49221ms (1.49% slower)

$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)

* 1 BILLION iterations (testing a completely literal string with nothing to parse in it):

$outstr = 'literal string testing';

23852ms (fastest)

$outstr = "literal string testing";

24222ms (1.55% slower)

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!

This works:

<?php
$foo = <<<END
abcd
END;
?>

This does not:

<?php
foo(<<<END
abcd
END;
);
// syntax error, unexpected ';'
?>

Without semicolon, it works fine:

<?php
foo(<<<END
abcd
END
);
?>

$a = "String array test";

var_dump($a);
// Return string(17) "String array test"

var_dump($a[0]);
// Return string(1) "S"

// -- With array cast --
var_dump((array) $a);
// Return array(1) { [0]=> string(17) "String array test"}

var_dump((array) $a[0]);
// Return string(17) "S"

- Norihiori

Example:
$foo = 1 + "bob-1.3e3"; 
$foo = "10.2 pigs " + 1.0;
Will produce: Warning: A non-numeric value encountered

Read more: https://www.php.net/manual/en/migration71.other-changes.php

$html = <<<"EOD"
<b>$comment</b>
EOD;

Using this shows all the same colour:

$html = <<<EOD
<b>$comment</b>
EOD;

making it a lot easier to work with

$const = get_defined_constants();

echo <<<END
{$const['TEST']}
END;

Result:
TEST STRING

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 '$'.
<?php
class 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.

This comparison is true because both md5() hashes start '0e' so PHP type juggling understands these strings to be scientific notation.  By definition, zero raised to any power is zero.

<?php
function doubleQuote($str) {
    $ret = '"';
    for ($i = 0, $l = strlen($str); $i < $l; ++$i) {
        $o = ord($str[$i]);
        if ($o < 31 || $o > 126) {
            switch ($o) {
                case 9: $ret .= 't'; break;
                case 10: $ret .= 'n'; break;
                case 11: $ret .= 'v'; break;
                case 12: $ret .= 'f'; break;
                case 13: $ret .= 'r'; break;
                default: $ret .= 'x' . str_pad(dechex($o), 2, '0', STR_PAD_LEFT);
            }
        } else {
            switch ($o) {
                case 36: $ret .= '$'; break;
                case 34: $ret .= '"'; break;
                case 92: $ret .= '\\'; break;
                default: $ret .= $str[$i];
            }
        }
    }
    return $ret . '"';
}
?>

Unfortunately, the documentation is not correct.

«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).»

It is not said and is not shown in examples throughout the documentation that, while converting strings to numbers, leading space characters are ignored, like with the strtod function.

<?php
    echo "     vf    r   1234" + 1;    // 1235
    var_export ("vf    r   1234" == "1234");    // true
?>

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.

<?php
    echo "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.

<?php
$juice = "apple";// Valid. Explicitly specify the end of the variable name by enclosing it in braces:
echo "He drank some juice made of {$juice}s.";
?>

$string = 'a';

var_dump($string[2]);  // string(0) ""

var_dump($string[7]);  // string(0) ""

$string[7] === '';  // TRUE

It appears that anything past the end of the string gives an empty string..  However, when E_NOTICE is on, the above examples will throw the message:

Notice:  Uninitialized string offset:  N in FILE on line LINE

This message cannot be specifically masked with @$string[7], as is possible when $string itself is unset.

isset($string[7]);  // FALSE

$string[7] === NULL;  // FALSE

Even though it seems like a not-NULL value of type string, it is still considered unset.

When both strings can be converted to the numerics (in ("$a" > "$b") test) then resulted numerics are used, else FULL strings are compared char-by-char:

<?php
var_dump('1.22' > '01.23'); // bool(false)
var_dump('1.22.00' > '01.23.00'); // bool(true)
var_dump('1-22-00' > '01-23-00'); // bool(true)
var_dump((float)'1.22.00' > (float)'01.23.00'); // bool(false)
?>

Of course, that would be rather meaningless for PHP/web, but it's useful for PHP-CLI. The solution is simple:  echo "x07"

<?php// Hack declaration
function _expr($v) { return $v; }
$_expr = '_expr';// Our playground
define('qwe', 'asd');
define('zxc', 5);$a=3;
$b=4;

function

c($a, $b) { return $a+$b; }// Usage
echo "pre {$_expr(1+2)} postn"; // outputs 'pre 3 post'
echo "pre {$_expr(qwe)} postn"; // outputs 'pre asd post'
echo "pre {$_expr(c($a, $b)+zxc*2)} postn"; // outputs 'pre 17 post'

// General syntax is {$_expr(...)}

?>

<?phpif ('123abc' == 123) echo '(intstr == int) incorrectly tests as true.';// Because one side is a number, the string is incorrectly converted from intstr to int, which then matches the test number.

// True for all conditionals such as if and switch statements (probably also while loops)!

// This could be a huge security risk when testing/using/saving user input, while expecting and testing for only an integer.

// It seems the only fix is for 123 to be a string as '123' so no conversion happens.

?>

<?phpclass Testing {
    public static $VAR = 'static';
    public const VAR = 'const';

        public function

sayHelloStatic() {
        echo "hello: {$this::$VAR}";
    }

        public function

sayHelloConst() {
        echo "hello: {$this::VAR}"; //Parse error:  syntax error, unexpected '}', expecting '['
    }
}$obj = new Testing();
$obj->sayHelloStatic();
$obj->sayHelloConst();

<?php

  $foo = "bar";

  echo "{{$foo}}";

?>



will just show {bar}. The { is special only if followed by the $ sign and matches one }. In this case, that applies only to the inner braces. The outer ones are not escaped and pass through directly.

    how about syntax errors?; = gone, I bet.

_EOC;
?>

Useful for debugging when C-style just won't do.  Also useful if you wish to embed Perl-like Plain Old Documentation; extraction between POD markers is left as an exercise for the reader.

Note there is a performance penalty for this method, as PHP must still parse and variable substitute the string.

Note that if you intend to use a double-quoted string with an associative key, you may run into the T_ENCAPSED_AND_WHITESPACE error. Some regard this as one of the less obvious error messages.

An expression such as:

<?php
    $fruit=array(
        'a'=>'apple',
        'b'=>'banana',
        //    etc
    );

    print

"This is a $fruit['a']";    //    T_ENCAPSED_AND_WHITESPACE
?>

will definitely fall to pieces.

You can resolve it as follows:

<?php
    print "This is a $fruit[a]";    //    unquote the key
    print "This is a ${fruit['a']}";    //    Complex Syntax
    print "This is a {$fruit['a']}";    //    Complex Syntax variation
?>

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 … ?

<?phpecho "The expression {$h->q()["x}"]->p(9 == 0 ? 17 : 42)} gets parsed just as well as " . $h->q()["x}"]->p(9 == 0 ? 17 : 42) . " does.";?>

    public

$smith = "Smith";
}$people = new people();

echo

"$people->john then said hello to $people->jane.".PHP_EOL;
echo "$people->john's wife greeted $people->robert.".PHP_EOL;
echo "$people->robert greeted the two $people->smiths";
\Won't work
\Outputs: Robert Paulsen greeted the two

/**Solution:**

echo "$people->robert greeted the two $people->smithx08s";

\Will work
\Outputs: Robert Paulsen greeted the two Smiths

?>