| |
|
|
| | я думал проблемы уже позади но увы .. столкнулся со следующей
КОДИРОВКА..
заполняю я в форме
"Кашка"
в MySql записалось
"Кашка"
ввывел на другую форму эту запись
"Кашка"
считал её с формы и записал в MySql
"Кашка "
в результате в 2 таблицах 1 бд один и тото же текст с 2 разных кодировках | |
| |
|
|
| |
|
|
| |
для: Арфей
(16.06.2010 в 17:48)
| | | вот так из "кашка" получилась "какашка"
__
рассказывайте начиная с кодировки БД, соединения с БД и самой страницы | |
| |
|
|
| |
автор: вред (16.06.2010 в 17:59) |
|
| |
для: Арфей
(16.06.2010 в 17:48)
| | | И какой же запрос получает база? Сомневаюсь, что MySQL самостоятельно будет заморачиваться над преобразованиями html-сущностей. | |
| |
|
|
| |
|
|
| |
для: Арфей
(16.06.2010 в 17:48)
| | | может все же стоит в заголовке страницы с формой указывать корректную кодировку html-документа? | |
| |
|
|
| |
|
|
| |
для: Trianon
(16.06.2010 в 17:59)
| | | счас по порядку | |
| |
|
|
| |
|
|
| |
для: Арфей
(16.06.2010 в 17:48)
| | | Страница 1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<meta http-equiv="content-type" content="text/html; charset=cp-1251">
|
отправляеться Ajax
в на сервак на Серваке
bulk_insert_buffer_size 8388608
character_set_client utf8
character_set_connection utf8
character_set_database utf8
character_set_filesystem binary
character_set_results utf8
character_set_server latin1
character_set_system utf8
character_sets_dir /usr/local/share/mysql/charsets/
collation_connection utf8_general_ci
collation_database utf8_general_ci
collation_server latin1_swedish_ci
и потом с сервака на другую страницу
на ней
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<meta http-equiv="content-type" content="text/html; charset=windows-1251">
|
| |
| |
|
|
| |
|
|
| |
для: Арфей
(16.06.2010 в 18:13)
| | | всю мету следует выкинуть нах.
Заголовки выводить явным образом через header/Content-Type либо неявным - через AddDefaultCharset в .htaccess
с какого справочника Вы взяли кодировку cp-1251? Нет такой кодировки. Нет, и не было никогда.
Уж коль скоро система поддерживает utf-8 у Вас, то почему в ней все и не делать?
Путаницы всяко будет меньше. | |
| |
|
|
| |
автор: вред (16.06.2010 в 18:50) |
|
| |
для: Trianon
(16.06.2010 в 18:44)
| | | > всю мету следует выкинуть нах.
аяйяй, а как же пользователи dial-up, которые сохраняют html на диск и смотрят накаченное в оффлайн?) | |
| |
|
|
| |
|
|
| |
для: вред
(16.06.2010 в 18:50)
| | | Браузеры при просмотре автономного контента берут данные заголовка из собственной базы кеша.
Если кому спичит сохранять контент на диск диким способом - денвер в лапы.
А кодировка вплющенная в тело документа не дает его спокойно конвертировать без необходимости залезания внутрь, а по сему - зло инконсистентности.
PS. Мне будет удобнее с Вами общаться, если Вы потратите чуть времени, и зарегистрируетесь. | |
| |
|
|
| |
|
|
| |
для: Trianon
(16.06.2010 в 19:07)
| | | Конвертирование документа без залезания "внутрь" лишает браузер возможности корректно определить в какой кодировке отображать сконвертированный документ. Угадать сможет, определить - нет.
> потратите чуть времени, и зарегистрируетесь.
На зрение не жалуюсь, но вспоминалку паролей тут не нашёл... Пришлось вспоминать головой )) | |
| |
|
|
| |
|
|
| |
для: sms-send
(16.06.2010 в 19:58)
| | | Хо! Знакомые всё лица!
>Конвертирование документа без залезания "внутрь" лишает браузер возможности корректно определить в какой кодировке отображать сконвертированный документ.
Это с каких таких дел?
Если инконсистентная мета отсутствует - ничего не мешает.
>Угадать сможет, определить - нет.
Зачем гадать? Он возьмет кодировку и тип обычным образом - из поля заголовка.
>
>> потратите чуть времени, и зарегистрируетесь.
>На зрение не жалуюсь, но вспоминалку паролей тут не нашёл... Пришлось вспоминать головой ))
А нетути тут её ... давно уже. Чупса надо дергать для пароля. | |
| |
|
|
| |
 958 байт |
|
| |
для: Trianon
(16.06.2010 в 21:11)
| | | =)
<meta http-equiv="content-type" ...
|
http-equiv - буквально "эквивалент поля заголовка протокола http". В html-документе ведь нет самих этих заголовков.
> Он возьмет кодировку и тип обычным образом - из поля заголовка.
Так откуда браузер из локально сохранённого файла воссоздаст http-заголовки, с которыми этот html пришёл? (при отсутствии meta)
В аттаче 4 файла. Опера у меня чудесным алгоритмом угадывает верную кодировку во всех случаях. А вот IE8 и Firefox 3.6.3 спотыкаются минимум на одном из файлов без указанной кодировки.
Сейчас протестировал... При сохранении в режиме "веб-страница с картинками" все 3 браузера добавили в html этот самый инконсистентный тег meta с content-type и текущей отображаемой кодировкой страницы (т.е. если не угадали - то дописывают неправильную кодировку). В режиме "только html" сохраняют весь html без изменений.
Значит в большинстве случаев при сохранении, если meta с кодировкой не было, то добавится тот, который пришёл от сервера, но если файл уже был сохранён локально и без meta, то будем гадать кодировку. | |
| |
|
|
| |
|
|
| |
для: sms-send
(16.06.2010 в 22:47)
| | | Если локальное хранение выполнено браузером - из базы данных кеша браузера.
Если человеком - меты, прописанной браузером. Хоть это и зло.
Если мету браузер не прописал - из настроек денвера. Которые этот человек также обеспечит. | |
| |
|
|
| |
|
|
| |
для: Trianon
(16.06.2010 в 22:54)
| | | Ну да, если браузеры всегда при сохранении будут прописывать meta с кодировкой, тогда единственный мой аргумент отпадает и вопросов больше нет :) | |
| |
|
|
