Погода: -12°C
  • Сразу скажу, что я только начинаю изучать основы программирования 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:

  • На всякий случай, в 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"

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

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


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

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

  • Еще как минимум при каждом подключение к mysql приходится прописывать
    mysqli_set_charset($dbc, "utf8");

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

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

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

    "Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин:улыб:(а не на "вертикаль власти" надеяться)

  • В ответ на: Никакие аддслеши, стриптеги и специалчары от инъекций НЕ спасают.
    Не в плане спора, а любопытства ради: пример привести можете, когда экранирование не поможет?

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

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

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

    "Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин:улыб:(а не на "вертикаль власти" надеяться)

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

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

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

    Исправлено пользователем IEEE (01.02.13 05:54)

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

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

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

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

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

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

Записей на странице:

Перейти в форум

Модератор: