Стоимость производительности правильной кодировки utf-8 в PHP

Я не смог найти определенно лучшие практики, когда дело доходит до обработки входящих данных. У некоторых других тем была полезная информация, но у меня все еще есть много вопросов без ответа. Все, что я точно знаю, это 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) Как насчет дат, int, десятичных знаков, взятых из базы данных или из 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 скрипт: использование mb_internal_encoding('UTF-8'); затем следует mb_http_output('UTF-8'); на каждой странице .php, в самом начале после тега php <?php. (Разве это не может быть установлено по умолчанию в php?)
• PDO: использование параметра charset=utf8mb4 при создании нового объекта PDO.
• Текстовый редактор: если вы используете Notepad++, используйте параметр "Кодировать в UTF-8" с самого начала, для каждой страницы независимо от расширения.

Надеемся, что этот поток будет последним и наиболее полным местом для изучения лучших практик кодирования с приемлемой производительностью в среде php/sql.