Записи в БД на русском языке
 

Как сделать записи в БД на русском, что нужно сделать, где какие кодировки, уже часа 2 хожу по сайтам, в слепую тыкаю, но ничего не выходит:

Нашел решение, думаю многим понадобиться:

$con = mysql_connect('localhost', 'gmoryes_login', '*****'); // Подсоединяемся к БД
if(mysql_select_db('gmoryes_login', $con))
{      
// в самом начале прописываем это:
        mysql_query("SET CHARACTER SET cp1251")or die(mysql_error());
        mysql_query("SET NAMES cp1251")or die(mysql_error());
        mysql_query ("SET character_set_client='cp1251'");
        mysql_query ("SET character_set_results='cp1251'");
        mysql_query ("SET collation_connection='cp1251_general_ci'");

на скриншоте выше вы используете сравнение utf8_general_ci, а в коде используете кодировку cp1251
Такое решение будет работать не совсем корректно.
Использовать стоит сравнение из семейства соответсвующих используемой кодировке

И учитывая, что вы используете кодировку cp1251, то вы не сможете использовать символы не из латиницы и кириллицы
В вашем случае более странным, чем использование кириллицы для пароля, может показать использование только кириллицы и латиницы в пароле

Gvozd,
насколько я понял, ты хочешь сказать, что я не смогу использовать латиницу?

Да и это пока тупость, согласен, я просто хочу сделать чат, вот и задумался, как буду сообщения сохранять, и не стал создавать что-то новое, сделал все на странице регистрации, естественно потом все номрмально сделаю
P.S. не ты писал выше? 102-106 записи

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

Gvozd,
пароль на иврите :blink:
=====
Cейчас поменял кодировку на ср1251, но немецкий все также не читается, или я опять тебя не так понял :write:
=====
да о нем, сейчас делаю возможность добавления аватарок)

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

Gvozd,
просто в жизни бы не догадался использовать пароль на иврите...тогда уж на китайском или японском лучше...правда без инета его не наберешь, если конечно не носить с собой его, чтобы скопировать
======
1) Не легче на js создать ограничения?
2) Как в случае чего добавить поддержку всех языков? Мне для сообщений понадобиться

Но ведь на русском догадались)
Намекаю: пароль на любом национальном шрифте - глупость по определению. Но если уж и разрешать какой-нибудь из национальных шрифтов, то разрешать все языки.
у вас уже на уровне базы стоит ограничение
я говорю не о том, что вам нужно ввести проверку или поставить ограничение, а о том, что вы уже ввели весьма странное ограничение, выбрав кодировку cp1251 для пароля
Выбрать кодировку UTF8, и одно из сравнений из семейства utf8_*, например utf8_general_ci
Если выберете однобайтовую кодировку, то поддерживать она будет только ограниченный список языков
Если выберете неправильное сравнение, то у вас будет неправильно работать выборка с сортировкой
PS кодировка и сравнение -разные вещи. в гугле об этом можно прочитать, если что

:D :D !pokerface! Я полдня просидел с utf-8, и это не смешно, и на ней не работал русский язык..были кракозябы

Это форум так глючит, или вы специально мои цитаты переписываете на чужое имя?)
значит что-то вы делали неправильно
например, возможно исходные данные, помещаемые в БД были в неверной кодировке
Учитывая, что вы додумались страницу регистрации создать в CP1251, то данные присланные из браузера не могли бы быть обработанными в иной кодировке, если вы их конечно не перевели в нормальную кодировку. А вы наверняка не перевели, иначе проблема бы не было.

Итак, что нужно сделать:
везде использовать UTF-8
страница с формой регистрации должна быть в UTF-8, а не CP1251, как щаз
для этой страницы должны быть указаны HTTP-заголовки, указывающие кодировку, и соответствующий META_тег. кодировка - UTF-8
скрипт принимающий данные, также в UTF-8
И база также, в UTF-8

Gvozd,
сори, это я ваши логины вечно путаю)
=======
ок, спасибо, попробую

а зачем вы логины переписываете?
форум их прекрасно подставляет в сообщение, когда вы его выделяете(в хроме так точно)
даже если вам движок форума не подставил логин, то зачем его дописывать?

Gvozd,
просто цитату сделал посредством bb кодов, имена сам решил дописать, если тебя как-то обидело извини :/

да не, ниче страшного

Чтобы не создавать новую тему, спрошу здесь.

Скажите, вот phpmyadmin предлагает более 10 видов кодировок utf-8. Только 3 из них кажутся нейтральными: utf8_general, utf8_unicode и utf8_bin. Какую одну из них следует использовать?

jsuse,
Это о предлагает не кодировки, а сравнения
сравнение будет влиять на то, в каком порядке выводить записи, если вы отсортируете их по текстовому полю.
а кодировка во всех случаях - одна и та же - Utf8
Если нету какой-то специфики, то берите utf8_general_ci

Пароль вообще хранить в БД не нужно.

И где же его хранить? В защищённых файлах?

Спасибо, так и сделал. Но что-то русский все равно не выводит. Уже слава богу не кракозябры, а только ?????? вопросительные знаки, но все равно не выводит.

У меня была windows-1251 везде. И на доктайпе html-страницы, и база данных (сама БД была windows-1251), каждая таблица БД w-1251 и каждая ячейка таблицы, где имелся текст, тоже w-1251. И текст на русском выводился из БД нормально.

Теперь перевел все на utf-8, и доктайп html-страниц, и базу данных, и таблицы в БД, и ячейки в таблицах (и charecter set и collation, все сделал utf-8_general_ci). Попересохранял все файлы через Блокнот, там есть опция "сохранить в utf-8". А все равно русский текст из БД не вытаскивает, превращает в ?????. Что еще может быть, не подскажите, что мог пропустить?

Но правда не все еще таблицы и ячейки поменял. Сменил только кодировку всей БД и одной из таблиц, из которой беру русскую инфу на вывод. Другие остались пока win-1251. Но они не связаны с измененной таблицей. Не думаю, что это может влиять.

Спасибо.

Не нужно его хранить вообще. Хранить нужно солёный хеш.

jsuse,
полагаю, вы изменили только сравнение, не изменив кодировку

http://www.lissyara.su/articles/free...ysql_charsets/
Читать полностью, а особенно часть про "Что делать, если данные внесены в неправильной кодировке"

Раед,
нет, его нужно схранить также, но в БД отправлять md5, при логине, хешируешь, то что ввел юзер, и сравниваешь, если хеши совпадают, то пароль правильный

Gvozd, Хочу поблагодарить за ссылку. Ценнейшая статья. Я из одной этой статьи понял больше о кодировке, чем из всех книг и форумов, которые читал до этого. Разобрался, настроил, работает. Спасибо)

Интересно, что, если вызывать просмотр переменных кодировки в PhpMyAdmin и в командной строке, то результат разный. PhpMyAdmin показывает не верный, а командная строка верный. Это на всякий случай, если кому понадобится. Не доверять PhpMyAdmin, проверять в командной строке.

Вот, что показывает phpMyAdmin. По нему получается, что все правильно:




А на самом деле так:

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

А собственно говоря почему?
Как предлагаете восстанавливать пароль? Отправлять на мыло сгенерированный, а потом чтобы юзер вбивал что хотел опять, тот же самый пароль?

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

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

1) создают ссылку для создания нового пароля
2) добавляют новый пароль введенный юзером
А если хранить чистый пароль в БД, то при чужом попадании в нее, можно зайти в аккаунт другого юзера

Да.Нет, разница огромна. При правильном использовании хешей, конечно.

Патамушта!

Это разговор ни о чём. Разницы нет.

Я даже могу выделить это красным:

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

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

Тот кто не видит обычного и красного не увидит.

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

пользователи использующие сложные пароли все еще будут защищены, даже при хищении базы с солеными хешами

Я где-то говорил про посторонних в БД?
Не вижу смысла в дальнейшем обсуждении, Вы всё равно не привели ни одного стоящего аргумента.

Дело в том что навредить могут необязательно посторонние. Не читали историй про злобных и обиженных уволенных админов?)

Вы вообще не привели ни одного аргумента.

Нет, не читал.

То, что Вы игнорируете мои посты, не означает, что я не привёл аргументы.

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

Gozar,
аргументы:
1) Если зайдет кто-нибудь посторнний в БД, то сможет взять пароль юзера
2) Юзерам неприятно то чувство, что к их аккаунту есть доступ от администратора, хотя понимают, что читать он перписку чью-нибудь не будет
3) Зачем хранить в открытом виде вообще, если можно хранить в более защищенном?

B@rmaley.e><e,
Это не аргумент, поэтому я и проигнорировал. Меня так же не интересует на какой стороне спит пользователь. Это его сугубо личное дело. У многих пароль написан на стикере приклееном в монитору.

Ничего они не понимают и нужно всегда осознавать, что админ имеет доступ к твоей переписке. Там где начинаются деньги заканчиваются сопли про защищённость. Поэтому вконтакте плевать на то, как хранить пароли.

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

Развели тут демагогию про защищённость и секретность. Давайте без показушности. Хранение паролей имеет ряд преимуществ и недостатков.

Недостаток:
1. Можно получить доступ к многим аккаунтам одновременно, если нет дополнительной защиты. Это пожалуй самый серьезный недостаток.

Преимущество:
1. Не нужно морочить пользователю голову и заставлять его трахать себе мозг ссылками с новыми паролями. Это одно из самых серьезных преимуществ. Единицы не любят получать пароли и тысячи любят получать их, а не тратить время на процедуры "криворуких программистов", которые придумывают всемозможные "издевательства" для бедных пользователей.

Любое действо имеет ряд перимуществ и недостатков.

Доступ к БД бывает разный. С помощью SQL-inj можно утянуть интересные данные, но очень редко удаётся изменить их.