Многобайтовая обрезка в PHP?

Стандартная функция trim обрезает несколько пробелов и пробельных символов. Они определяются как символы ASCII, что означает определенные определенные байты от 0 до 0100 0000.

Правильный ввод UTF-8 никогда не будет содержать многобайтовые символы, состоящие из байтов 0xxx xxxx. Все байты в правильных многобайтовых символах UTF-8 начинаются с 1xxx xxxx.

Это означает, что в правильной последовательности UTF-8 байты 0xxx xxxx могут относиться только к однобайтовым символам. Поэтому функция PHP trim никогда не будет обрезать "полсимвола" предполагая, что у вас есть правильная последовательность UTF-8. (Будьте очень-очень осторожнее с неправильными последовательностями UTF-8. .)

\s в регулярных выражениях ASCII в основном соответствует тем же символам, что и trim.

Функции preg с модификатором /u работают только с регулярными выражениями в кодировке UTF-8, а /\s/u также соответствуют nbsp. Такое поведение с неразрывными пробелами является единственным преимуществом его использования.

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

Другими словами, если вы пытаетесь обрезать обычные пробелы в строке, совместимой с ASCII, просто используйте trim. При использовании /\s/u будьте осторожны со значением nbsp для вашего текста.

Заботиться:

  $s1 = html_entity_decode(" Hello   "); // the NBSP
  $s2 = " ???? exotic test ホ ???? ";

  echo "\nCORRECT trim: [". trim($s1) ."], [".  trim($s2) ."]";
  echo "\nSAME: [". trim($s1) ."] == [". preg_replace('/^\s+|\s+$/','',$s1) ."]";
  echo "\nBUT: [". trim($s1) ."] != [". preg_replace('/^\s+|\s+$/u','',$s1) ."]";

  echo "\n!INCORRECT trim: [". trim($s2,'???? ') ."]"; // DANGER! not UTF8 safe!
  echo "\nSAFE ONLY WITH preg: [". 
       preg_replace('/^[????\s]+|[????\s]+$/u', '', $s2) ."]";

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

function mb_trim($str) {
  return preg_replace("/^\s+|\s+$/u", "", $str); 
}

Эта версия поддерживает второй необязательный параметр $charlist:

function mb_trim ($string, $charlist = null) 
{   
    if (is_null($charlist)) {
        return trim ($string);
    } 

    $charlist = str_replace ('/', '\/', preg_quote ($charlist));
    return preg_replace ("/(^[$charlist]+)|([$charlist]+$)/us", '', $string);
}

Однако не поддерживает «..» для диапазонов.

Итак, я взял решение @edson-medina, исправил ошибку и добавил несколько модульных тестов. Вот 3 функции, которые мы используем, чтобы дать mb аналоги для trim, rtrim и ltrim.

////////////////////////////////////////////////////////////////////////////////////
//Add some multibyte core functions not in PHP
////////////////////////////////////////////////////////////////////////////////////
function mb_trim($string, $charlist = null) {
    if (is_null($charlist)) {
        return trim($string);
    } else {
        $charlist = preg_quote($charlist, '/');
        return preg_replace("/(^[$charlist]+)|([$charlist]+$)/us", '', $string);
    }
}
function mb_rtrim($string, $charlist = null) {
    if (is_null($charlist)) {
        return rtrim($string);
    } else {
        $charlist = preg_quote($charlist, '/');
        return preg_replace("/([$charlist]+$)/us", '', $string);
    }
}
function mb_ltrim($string, $charlist = null) {
    if (is_null($charlist)) {
        return ltrim($string);
    } else {
        $charlist = preg_quote($charlist, '/');
        return preg_replace("/(^[$charlist]+)/us", '', $string);
    }
}
////////////////////////////////////////////////////////////////////////////////////

Вот модульные тесты, которые я написал для всех, кто заинтересован:

public function test_trim() {
    $this->assertEquals(trim(' foo '), mb_trim(' foo '));
    $this->assertEquals(trim(' foo ', ' o'), mb_trim(' foo ', ' o'));
    $this->assertEquals('foo', mb_trim(' Åfooホ ', ' Åホ'));
}

public function test_rtrim() {
    $this->assertEquals(rtrim(' foo '), mb_rtrim(' foo '));
    $this->assertEquals(rtrim(' foo ', ' o'), mb_rtrim(' foo ', ' o'));
    $this->assertEquals('foo', mb_rtrim('fooホ ', ' ホ'));
}

public function test_ltrim() {
    $this->assertEquals(ltrim(' foo '), mb_ltrim(' foo '));
    $this->assertEquals(ltrim(' foo ', ' o'), mb_ltrim(' foo ', ' o'));
    $this->assertEquals('foo', mb_ltrim(' Åfoo', ' Å'));
}

Вы также можете обрезать несовместимые с ascii пробелы (например, неразрывный пробел) в строках UTF-8 с помощью preg_replace('/^\p{Z}+|\p{Z}+$/u','',$str);

\s будет соответствовать только «совместимому с ascii» символу пробела даже с модификатором u .
но \p{Z} будет соответствовать всем известным символам пробела Unicode

mb_ereg_replace, похоже, обходит это:

function mb_trim($str,$regex = "(^\s+)|(\s+$)/us") {
    return mb_ereg_replace($regex, "", $str);
}

.. но я недостаточно разбираюсь в регулярных выражениях, чтобы знать, как добавить параметр "charlist", который люди ожидают получить в функции trim(), т. е. список символов для обрезки, так что просто сделал регулярное выражение параметром.

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

(Перенесено из дубликата Q на trim борется с NBSP.) Следующие примечания действительны для PHP 7.2+. Пробег может отличаться от более ранних версий (пожалуйста, сообщите в комментариях).

PHP trim игнорирует неразрывные пробелы. Он обрезает только пробелы в основном диапазоне ASCII. Для справки: исходный код для обрезки читается следующим образом (т. е. без недокументированных функций с обрезкой):

(c == ' ' || c == '\n' || c == '\r' || c == '\t' || c == '\v' || c == '\0')

Из вышеперечисленного, за исключением обычного пробела (ASCII 32, ), все это управляющие символы ASCII; LF (10:\n), CR (13:\r), HT (9:\t), VT (11:\v), NUL (0:\0). (Обратите внимание, что в PHP вы должны заключать экранированные символы в двойные кавычки: "\n", "\t" и т. д. В противном случае они анализируются как буквальные \n и т. д.)

Ниже приведены простые реализации трех разновидностей trim (ltrim, rtrim, trim) с использованием preg_replace, которые работают со строками Unicode:

preg_replace('~^\s+~u', '', $string) // == ltrim
preg_replace('~\s+$~u', '', $string) // == rtrim
preg_replace('~^\s+|\s+$~us', '', $string) // == trim

Не стесняйтесь включать их в свои собственные mb_*trim функции.

В соответствии с спецификацией PCRE, \s любой символ управляющей последовательности пробелов с u Включенный режим Unicode будет соответствовать всем следующим символам пробела:

The horizontal space characters are:

U+0009     Horizontal tab (HT)
U+0020     Space
U+00A0     Non-break space
U+1680     Ogham space mark
U+180E     Mongolian vowel separator
U+2000     En quad
U+2001     Em quad
U+2002     En space
U+2003     Em space
U+2004     Three-per-em space
U+2005     Four-per-em space
U+2006     Six-per-em space
U+2007     Figure space
U+2008     Punctuation space
U+2009     Thin space
U+200A     Hair space
U+202F     Narrow no-break space
U+205F     Medium mathematical space
U+3000     Ideographic space

The vertical space characters are:

U+000A     Linefeed (LF)
U+000B     Vertical tab (VT)
U+000C     Form feed (FF)
U+000D     Carriage return (CR)
U+0085     Next line (NEL)
U+2028     Line separator
U+2029     Paragraph separator

Вы можете увидеть тестовую итерацию preg_replace с флагом Unicode u, затрагивающим все перечисленные пробелы. Все они обрезаны, как и ожидалось, в соответствии со спецификацией PCRE. Если вы настроили таргетинг только на указанные выше горизонтальные пробелы, \h будет соответствовать им, как \v — всем вертикальным пробелам.

Использование \p{Z} в некоторых ответах потерпит неудачу по некоторым причинам; в частности, с большинством пробелов ASCII и, что шокирует, также с монгольским разделителем гласных. Хубилай-хан был бы в ярости. Вот список ошибок с \p{Z}: U+0009 Горизонтальная вкладка (HT), U+000A Перевод строки (LF), U+000C Перевод страницы (FF) , U+000D возврат каретки (CR), U+0085 следующая строка (NEL) и U+180E разделитель монгольских гласных. эм>

Что касается того, почему это происходит, в приведенной выше спецификации PCRE также отмечается: \s любой символ, который соответствует \p{Z}, \h или \v. То есть \s является надмножеством \p{Z}. Затем просто используйте \s вместо \p{Z}. Он более полный, и импорт более очевиден для тех, кто читает ваш код, кто может не помнить сокращения для всех типов символов.

Мои два цента

Фактическое решение вашего вопроса заключается в том, что вы должны сначала выполнить проверку кодировки, прежде чем работать над изменением чужих входных строк. Многие быстро узнают о «очистке и проверке» входных данных, но медленно осваивают этап определения основной природы (кодировки символов) строк, с которыми они работают на раннем этапе.

Сколько байтов будет использоваться для представления каждого символа? При правильно отформатированном UTF-8 это может быть 1 (символы, с которыми имеет дело trim), 2, 3 или 4 байта. Проблема возникает, когда в игру вступают устаревшие или искаженные представления UTF-8 - границы байтовых символов могут не совпадать, как ожидалось (говорят непрофессионалы).

В PHP некоторые выступают за то, чтобы все строки соответствовали правильной кодировке UTF-8 (1, 2, 3 или 4 байта на символ), где такие функции, как trim(), по-прежнему будут работать, потому что граница байт/символ для символов операции будут соответствовать расширенным значениям ASCII / 1 байт, которые trim() пытается исключить из начала и конца строки (обрезать страницу руководства).

Однако, поскольку компьютерное программирование — это разнообразная область, невозможно иметь универсальный подход, который работал бы во всех сценариях. С учетом сказанного напишите свое приложение таким, каким оно должно быть для правильной работы. Просто делаете базовый веб-сайт, управляемый базой данных, с вводом данных в форму? Да, за мои деньги заставить все быть UTF-8.

Примечание. У вас по-прежнему будут проблемы с интернационализацией, даже если проблема с UTF-8 стабильна. Почему? Многие неанглийские наборы символов существуют в пространстве 2, 3 или 4 байта (кодовые точки и т. д.). Очевидно, что если вы используете компьютер, который должен работать с китайскими, японскими, русскими, арабскими или ивритскими сценариями, вы хотите, чтобы все работало также и с 2, 3 и 4 байтами! Помните, что функция PHP trim может обрезать символы по умолчанию или заданные пользователем. Это важно, особенно если вам нужен trim для учета некоторых китайских иероглифов.

Я бы предпочел иметь дело с проблемой того, что кто-то не может получить доступ к моему сайту, чем с проблемой доступа и ответов, которых не должно быть. Если подумать, это соответствует принципам наименьших привилегий (безопасность) и универсального дизайна (доступность).

Резюме

Если входные данные не соответствуют правильной кодировке UTF-8, вы можете генерировать исключение . Вы можете попытаться использовать многобайтовые функции PHP, чтобы определить вашу кодировку, или какая-то другая многобайтовая библиотека. Если и когда PHP будет написан с полной поддержкой юникода (Perl, Java...), PHP станет для этого еще лучше. Усилия по юникоду PHP умерли несколько лет назад, поэтому вы вынуждены использовать дополнительные библиотеки для разумной работы с многобайтовыми строками UTF-8. Простое добавление флага /u к preg_replace() не дает полной картины.

Обновлять:

При этом я считаю, что следующая многобайтовая обрезка будет полезна для тех, кто пытается извлечь ресурсы REST из компонента пути URL-адреса (естественно, за вычетом строки запроса). Примечание: это было бы полезно после очистки и проверки строки пути.

function mb_path_trim($path)
{
    return preg_replace("/^(?:\/)|(?:\/)$/u", "", $path);
}