Мне не удалось найти определенно лучшие практики, когда дело доходит до обработки входящих данных.У некоторых других тем была полезная информация, но у меня все еще есть много вопросов без ответа.Все, что я точно знаю, это UTF-8 - единственный современный стандарт.Мой вопрос касается использования php, но, возможно, есть некоторые общие применения, которые могут применяться к другим языкам.Я готов уважать принятые стандарты, предполагая, что затраты на производительность достаточно незначительны.Не стесняйтесь указывать на ориентиры для обоснования некоторых конкретных вариантов.
1) Если вы действительно проверяете все входящие данные (apis, get, post, ...), подлежащие манипуляции или хранению?В конкретном случае websocket и Rest API я не вижу, что с точки зрения разумной производительности ... постоянная проверка строки кодирования для всех входящих данных и переменных, действительно ли это следует делать для хорошей практики?Если да, какой-либо метод, который не слишком дорогостоящ на ресурсах сервера?Я видел, как это используется, чтобы определить, является ли переменная UTF-8:
if(preg_match('!!u', $data))
{
echo 'this is utf-8'; //use the var
}
else
{
echo 'definitely not utf-8'; //do something else
}
Делать это все время кажется излишним.И разве эта функция не должна быть mb_ereg_match?
2) Если вы должны всегда проверять входящие данные, какую жизнеспособную функцию использовать для того, чтобыпреобразовать данные в UTF-8?
3) Как насчет дат, целых, десятичных чисел, взятых из базы данных или из get / post ... имеют ли они какое-либо отношение к UTF-8, нужно ли кодировать их в UTF-8 перед отправкой в mysql?Что касается разрывов строк, они «появляются» в utf-8 как видимые разрывы строк, или они всегда отображаются как \r\n в тексте utf-8?Есть ли причина, по которой phpMyAdmin заменяет \r\n на видимые разрывы строк в интерфейсе, в этом случае?
4) Тот же вопрос для массивов (особенно тех, которые должны быть закодированы в json):
- следует ли кодировать ключ массива в utf-8?
- следует ли кодировать данные в ключах в utf-8?
- должны ли все массивы переменныхсам кодируется в utf-8?
5) Должны ли мы научиться использовать многобайтовые версии строковых функций вместо обычных не многобайтовых строковых функций, как показано в http://php.net/manual/en/ref.mbstring.php?это означает, что нужно взять весь набранный код и заменить функцию ради легкого повторного использования ...
6) При использовании utf8mb4_unicode (или его разновидности) для столбцов mysqlкакой максимальный размер VARCHAR() возможен?Видимо 255 это не вариант.Я также настороженно отношусь к выступлениям, когда поле является частью индекса.
7) Всегда в отношении достаточно хорошей производительности, чтобы применить передовой опыт, можете ли вы подтвердить (или исправить?)что следующее является правильным способом обработки кодирования в среде php / mysql или если элемент отсутствует;информация о том, что программное обеспечение всегда обновлено, не указана, так как это здравый смысл.
- Mysql : по умолчанию используется
utf8mb4_unicode_520_ci в качестве параметров сортировки и для каждого столбца, которыйможет содержать что угодно, кроме чисел, дат или времени. - Веб-страница : по умолчанию используется
<meta charset="UTF-8">. - Сервер PHP : использоватьрасширения
mbstring и его параметр Multibyte Support включен.default_charset=UTF-8 в php.ini. - PHP Script : использование
mb_internal_encoding('UTF-8'); с последующим mb_http_output('UTF-8'); на всех страницах .php, в самом начале после тега php <?php,(Разве это не может быть установлено по умолчанию в php?) - PDO : использование параметра
charset=utf8mb4 при создании нового объекта PDO. - Текстовый редактор : При использовании Notepad ++ с самого начала использовать параметр «Кодировать в UTF-8» для каждой страницы независимо от расширения.
Надеемся, что этот поток будет последним инаиболее полное место для изучения лучших практик кодирования с приемлемой производительностью в среде php / sql.