string — Почему в php есть бинарные безопасные и бинарные небезопасные функции?

Пример кулака из вопроса

Ваш первый пример сбивает с толку, потому что сообщение об ошибке — это часть, оканчивающаяся нулевым символом, а не потому, что строка неправильно обрабатывается массивом. Ниже приведен исходный код, который вы разместили с сообщением об ошибке:

$array = array("index-of-an-array" => "value");
$string = "index-of\0-an-array";
echo $array[$string];

Примечание: неопределенный индекс: индекс в

Обратите внимание, что сообщение об ошибке выше было усечено index-of из-за нулевого символа, массив работает должным образом, потому что если вы попробуете его таким образом, он будет работать нормально:

$array = array("index-of\0-an-array" => "value");
$string = "index-of\0-an-array";
echo $array[$string];

В сообщении об ошибке правильно указано, что два ключа были неправильными, что
они есть

"index-of\0-an-array" != "index-of-an-array"

Проблема в том, что в сообщении об ошибке распечатано все до нулевого символа. Если это так, то некоторые могут считать это ошибкой.

Второй пример запускает глубину PHP 🙂

Я добавил немного кода, чтобы мы могли видеть, что происходит

<?php
class Foo {
public    $index_public;
protected $index_prot;
private   $index_priv;
function __construct() {
$this->index_public = 0;
$this->index_prot   = 1;
$this->index_priv   = 2;
}
}
$foo = new Foo();
$array = (array)$foo;
print_r($foo);
print_r($array);
//echo $array["\0Foo\0index_of_an_array2"];//This prints 2
//echo $foo->{"\0Foo\0index_of_an_array2"};//This fails
var_dump($array);
echo array_keys($array)[0]       . "\n";
echo $array["\0Foo\0index_priv"] . "\n";
echo $array["\0*\0index_prot"]   . "\n";

Вышеуказанные коды выводятся

Foo Object
(
[index_public] => 0
[index_prot:protected] => 1
[index_priv:Foo:private] => 2
)
Array
(
[index_public] => 0
[*index_prot] => 1
[Fooindex_priv] => 2
)
array(3) {
'index_public' =>
int(0)
'\0*\0index_prot' =>
int(1)
'\0Foo\0index_priv' =>
int(2)
}
index_public
2
1

Разработчики PHP решили использовать \0 символ как способ разделения типов переменных членов. Обратите внимание, что защищенные поля используют * чтобы указать, что переменная-член может фактически принадлежать многим классам. Он также используется для защиты частного доступа, т.е. этот код не будет работать.

echo $foo->{"\0Foo\0index_priv"}; //This fails

но как только вы приведете его к массиву, такой защиты не будет, т.е.

echo $array["\0Foo\0index_priv"]; //This prints 2

Есть ли причина для такого поведения?/реализация?

Да. В любой системе, с которой вам нужно взаимодействовать, вам нужно сделать систему
звонки, если вы хотите, чтобы текущее время или конвертировать дату и т. д. вам нужно поговорить
к операционной системе, и это означает вызов API OS, в случае Linux
этот API находится в C,

PHP изначально разрабатывался как тонкая оболочка C довольно много языков
Начните с этого пути и развивайтесь, PHP не является исключением.

Есть ли причина для этого поведение/реализация?

В отсутствие каких-либо проблем с обратной совместимостью я бы сказал, что некоторые варианты выбора не являются оптимальными, но я подозреваю, что обратная совместимость является важным фактором.

Но я до сих пор не понимаю, почему язык разработан таким образом?

Обратная совместимость почти всегда является причиной того, что функции, которые не нравятся людям, остаются в языке. Со временем языки развиваются и удаляются, но это постепенно и приоритетно. Если бы вы спросили всех разработчиков PHP, хотят ли они лучшей обработки двоичных строк для некоторых функций или JIT-компилятора, я думаю, что JIT может выиграть, как в PHP 7. Обратите внимание, что люди, выполняющие реальную работу, в конечном итоге решают, над чем они работают, и работать над JIT-компилятором гораздо веселее, чем исправлять библиотеки, которые делают что-то странное.

Я не знаю ни одного языкового разработчика, который не хотел бы, чтобы они делали некоторые вещи иначе, чем с самого начала. Любой, кто реализует компилятор до
язык популярен и находится под большим давлением, чтобы получить то, что работает для
их, и это означает, что срезание углов, не все языки, существующие сегодня
огромная компания, поддерживающая их, чаще всего это была небольшая преданная команда, и они
совершил ошибки, некоторым посчастливилось получить за это деньги. Называя их ленивыми
немного несправедливо.

У всех языков есть темные углы бородавок и кипит и особенности, которые вы в конечном итоге будете ненавидеть. У некоторых больше, чем у других, и у PHP плохая репутация, потому что у него было / было намного больше, чем у большинства. Обратите внимание, что PHP 5 — это огромный шаг вперед по сравнению с PHP 4. Я думаю, что PHP 7 улучшит ситуацию еще больше.

Любой, кто думает, что его любимый язык свободен от проблем, бредит и почти наверняка не изучил глубины инструмента, который они используют, до какой-то большой глубины.

Функции в PHP, которые внутренне работают со строками C, «не бинарно безопасны» в терминологии PHP. Строка C — это массив байтов, заканчивающийся байтом 0. Когда функция PHP внутренне использует строки C, она читает один за другим символ, а когда она встречает байт 0, она считает ее концом строки. Байт 0 сообщает строковым функциям C, где находится конец строки, поскольку строка C не содержит никакой информации о длине строки.

«Не бинарный» означает, что если функции, которая работает со строкой C, каким-то образом передается строка C, не заканчивающаяся байтом 0, поведение непредсказуемо, поскольку функция будет читать / записывать байты за пределами конца строки, добавляя мусор в строку и / или потенциально сбой PHP.

Например, в C ++ у нас есть строковый объект. Этот объект также содержит массив символов, но он также имеет поле длины, которое он обновляет при любом изменении длины. Таким образом, он не требует байта 0, чтобы сказать ему, где конец. Вот почему строковый объект может содержать любое количество 0 байтов, хотя обычно это недопустимо, поскольку он должен содержать только допустимые символы.

Чтобы это исправить, нужно переписать все ядро ​​PHP, включая все модули, работающие со строками Си, чтобы отправлять «недвоичные безопасные» функции в историю. Объем работы, необходимый для этого, огромен, и создатели всех модулей должны создать новый код для своих модулей. Это может внести новые ошибки и нестабильности во всю историю.

Проблема с байтом 0 и «небинарно-безопасными» функциями не так уж критична, чтобы оправдать переписывание кода модулей PHP и PHP. Возможно, в более новой версии PHP, где некоторые вещи нужно кодировать с нуля, имеет смысл исправить это.

До этого вам просто нужно знать, что любые произвольные двоичные данные, помещенные в некоторую строку с использованием бинарно-безопасных функций, должны иметь добавленный байт 0 в конце. Обычно вы замечаете это, когда в конце строки возникает неожиданный мусор или происходит сбой PHP.