UTF-8 vs. MySQL - обсуждение на форуме НГС Самара

A

veteran

30 января 2013

Сразу скажу, что я только начинаю изучать основы программирования PHP и MySQL

С горем пополам удалось победить корректное отображение русского текста в таблицах MySQL как столкнулся с новой.

Есть код, который отвечает за рассылку писем. Яндекс отображает их нормально, Outlook последний - текст не читаем, BAT - принудительно поставил кодировку UTF-8, текст стал отображаться корректно, но тема не читаема. На андройдовском клиенте так же абракадабра.

Вот код:



<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//RU"

  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="RU" lang="RU">

<head>

  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

</head>

<body>



<?php

  $from = 'alexander@------.ru';

  $subject = $_POST['subject'];

  $text = $_POST['textemail'];



  $dbc = mysqli_connect('localhost', 'User1', 'Pass2', 'host_db')

or die('Ошибка соединения с MySQL сервером.');



  mysqli_set_charset($dbc, "utf8");



  $query = "SELECT * FROM email_list";

  $result = mysqli_query($dbc, $query)

or die('Невозможно выполнить запрос к базе данных.');



while($row = mysqli_fetch_array($result)){  

$to = $row['email'];

$first_name = $row['first_name'];

$last_name = $row['last_name'];

$msg = "Уважаемый $first_name $last_name, \n$text\n";

mail($to, $subject, $msg, 'From: ' . $from);

echo 'Электронное письмо отправлено: ' . $first_name . " " . $last_name . " " . $to . '<br />';

}



mysqli_close($dbc);

?>  



</body>

</html>

В MySQL базе отображается все корректно.
Что еще нужно чтобы в браузерах и почтовых клиентах это было читаемо без танцев с бубнами???

Или ну его этот UTF-8??? Или у меня руки кривые? :dry:

Ответить

A

Alexander_

veteran

30 января 2013

Alexander_

На всякий случай, в phpmyadmin хостером установлены такие параметры кодировки



haracter_set_client cp1251

character_set_connection cp1251

character_set_database cp1251

character_set_filesystem binary

character_set_results cp1251

character_set_server cp1251

character_set_system utf8

character_sets_dir /usr/local/share/mysql/charsets/

Для моей базы в "операциях" я установил "сравнение с "utf8_general_ci"

Ответить

A

Alexander_

veteran

30 января 2013

Alexander_

Сам спросил, сам отвечу :улыб:



$header = "From: $from\n";

$header .= "Content-type: text/plain; charset=utf-8 \r\n";

Но вопрос про актуальность использования этой кодировки остается открытым. Это нормальная ситуация что приходиться дополнительно везде по несколько раз ее дописывать?

Ответить

K

KSergey

guru

30 января 2013

Alexander_

Ни несколько, а всего один раз в письме. Что ж тут такого?

Ответить

A

Alexander_

veteran

30 января 2013

KSergey

Еще как минимум при каждом подключение к mysql приходится прописывать

mysqli_set_charset($dbc, "utf8");

И это я еще только элементарные вещи изучаю, вот и предполагаю что подобные "дополнения" кода всплывут еще не раз

Ответить

tolstopuz

v.i.p.

31 января 2013

Alexander_

Абсолютно нормально. Если хотите, чтобы работало, привыкайте кодировку всегда и везде указывать явно. Имхо, utf-8 - наиболее нормальная кодировка. То что у хостера - виндовая, это даже плюс. Будете всегда "в тонусе".

и ещё замечание. В работе с базой переходите на PDO адаптер. Он позволяет отделить данные от запросов, что есть единственно надежный способ защиты от разного рода инъекций. Освойте и забудьте всяческие mysql(i)_ насовсем. Никакие аддслеши, стриптеги и специалчары от инъекций НЕ спасают.

Ответить

K

KSergey

guru

31 января 2013

tolstopuz

Никакие аддслеши, стриптеги и специалчары от инъекций НЕ спасают.

Не в плане спора, а любопытства ради: пример привести можете, когда экранирование не поможет?

Ответить

tolstopuz

v.i.p.

31 января 2013

KSergey

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

на медиаме, на карточках товаров внизу выводится статистика переходов по конкретным поисковым фразам из поисковиков. Так вот, мало того, что это тексты рефереров (слешуются всякими Яшами и Гуглами), они ещё и у меня проверяются и слешуются всеми возможными способами.

До тех пор пока не перевел вставку в БД на полноценный PDO (с нормальным бинтованием данных), примерно раз в неделю скрипт банально падал по ошибке некорректного запроса.

Ответить

I

IEEE

experienced

01 февраля 2013

KSergey

Пример:
http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html

Взято здесь:
http://habrahabr.ru/post/148701/

Плюс, не надо забывать, что баги в самом PHP и MySQL могут открывать интересные новые виды через старые щели.

Ответить

A

Alexander_

veteran

01 февраля 2013

tolstopuz

Спасибо за информацию.

Про "PDO адаптер" возьму на заметку, но я пока основы основ изучаю и мне это ни о чем не говорит :улыб:

Ответить

K

KSergey

guru

01 февраля 2013

IEEE

Взято здесь:
http://habrahabr.ru/post/148701/

Очередные страшилки ни о чем.
Как обычно: сначала мы делаем гибкость никому не нужную, зато "такую красивую!" (типа пихания всех полей из реквеста прямо в запрос) плюс используем не понятые до конца по воздействию на данные функции, а потом изумляемся "о! нас хакнули!!".
Разумеется, с "осознанием" и написанием "разоблачительных" мега-статей.

SQL-запрос - всего лишь строка. Строка текста.
Достаточно понимать какие символы и что в ней означают и какие надо экранировать - вот и все.

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

Ну разве что в качестве проверенных кем-то (кем? на сколько компетентен автор?) best practice...

Ответить