Как исправить пустые строки в БД при добавление кириллицы?

Question

[Александр Grom]

Когда добавляю кириллицу из админ-панели в БД пустые строки , если меняю что-то на кириллицу в самой БД всё нормально. Понял что это связанно с htmlspecialchars, но как победить его так и не понял.
Пробовал декодировать с помощью iconv и htmlspecialchars_decode ничего не получилось, а скорее всего не правильно делаю. У меня PHP 8.1, MYSQL 8.

functionsecureSuperGlobalPOST($key)
{
if(is_array($key)){
$valrets= $value;
}elseif($key) {
$return = '';
for($i = 0; $i < strlen($key ); ++$i) {
$char = htmlspecialchars($key[$i], ENT_QUOTES, 'UTF-8');
$ord = ord($char);
if($char !== "'" && $char !== "\"" && $char !== '\\' && $ord >= 32 && $ord <= 126)
$return.=$char;
else
$return.='';

}
$valrets= $return;
}

Comments

[Ivan Ustûžanin]

1) а зачем что-то декодировать если кириллица и так в utf-8 приходит?
2) побайтовый проход для utf-8 не работает

Answer 1

[nokimaro]

1. Это никак не связано с htmlspecialchars
2. Выкиньте функцию secureSuperGlobalPOST вообще, она не нужна

Если конкретно искать проблему то она в функции secureSuperGlobalPOST, то что идёт после htmlspecialchars. Даже не беря во внимание что скорее всего вы работаете с utf-8 строками, то в функции удаляются из строки все символы не входящие в ascii 32-126
Так вот кирилица не входит в ascii 32-126 , там только латиница.



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

Comments

[Александр Grom]

Я не писал этот код так как не селён в MySQL я и в PHP новичок, а тот кто писал слился вот уже месяц не отвечает. ASCII символы с кодами от 32 до 126 не совпадают с кириллицей, я это изменил потом поменял ENT_QUOTES на ENT_NOQUOTES и UTF-8 на CP1251 и латиница и кириллица стали залетать в БД но опять же это костыль, а декодировать эту строку я так и не смог. функция secureSuperGlobalPOST в файле config.php на него смотрит весь сайт так что вырезать я её не смогу.

[nokimaro]

Александр Grom, просто сократите функцию до

function secureSuperGlobalPOST($key)
{
    if(!is_string($key)){
        return $key;
    } 
    
    return htmlspecialchars($key, ENT_QUOTES, 'UTF-8');
}

[Александр Grom]

nokimaro, Большое человеческое спасибо. Всё получилось.

Answer 2

[Руслан Федосеев]

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

Answer 3

[dmitryklerik]

Ваша функция functionsecureSuperGlobalPOST() ломает юникодную кирилическую строку. Так происходит потому-что в юникоде utf8 символы могут занимать от 1 до 4 байт https://ru.wikipedia.org/wiki/UTF-8 , а функции strlen и ord работают только с однобайтовыми строками. В PHP для обработки utf8 строк нужно использовать только mb_ функции https://www.php.net/manual/ru/book.mbstring.php

Судя по всему функция пытается вырезать "плохие символы" перед сохранением в базу. Обычно в PHP наоборот: в базу сохраняют строки как есть, но перед выводом обязательно(!) прогоняют строки через htmlspecialchars: htmlspecialchars($string, ENT_QUOTES, 'UTF-8');

Comments

[dmitryklerik]

Что-то я посмотрел на вашу функцию и мне кажется вы её и для эскейпинга SQL используете. Для того чтобы пользовательская строка не ломала SQL запросы перед сохранением строки в базу строку нужно прогонять через mysqli_real_escape_string(), а уж потом подставлять строку в запрос

(После подключения к базе важно не забыть установить кодировку mysqli_set_charset($mysql, "utf8mb4")).

[Rsa97]

dmitryklerik,

строку нужно прогонять через mysqli_real_escape_string()

Нужно использовать подготовленные запросы с плейсхолдерами. А всякие escape - это, в основном, от скудоумия.

[Александр Grom]

dmitryklerik, Я не писал этот код так как не селён в MySQL я и в PHP новичок, а тот кто писал слился вот уже месяц не отвечает. Мне подсказали что ASCII символы с кодами от 32 до 126 не совпадают с кириллицей, я это изменил потом поменял ENT_QUOTES на ENT_NOQUOTES и UTF-8 на CP1251 и латиница и кириллица стали залетать в БД но опять же это костыль, а декодировать эту строку я так и не смог.

Answer 4

[ThunderCat]

Понял что это связанно с htmlspecialchars, но как победить его так и не понял.

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

Во вторых - научитесь отладке. Если вы не знаете в чем вообще проблема, стоит посмотреть что и на каком этапе пошло не так, для этого в самом примитивном виде нужно использовать var_dump/print_r, ну или инструменты по типу xdebug.

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