не исполняется, текст на странице, как и положено в таком случае — крякозябра полная.
Руками в меню «. Кодировка» задашь UTF-8 — нормально читается страница. А судя по галкам, браузер считает, что страница содержит текст Win-1251. Откуда они это берут? Где поискать «зарытую собаку»?
1. тег не устанавливает кодировку, а лишь сообщает браузеру о кодировке т.е. если фактически ваш HTML-редактор настроен под кодировку windows-1251, то вы можете хоть двадцать пять раз прописать — в браузер всё-равно придёт кодировка windows-1251
[это как тег — сайт вполне может быть по содержанию педофильским, а в этом теге будет что-то о художественно-прекрасном именно так раньше обманывали поисковые системы поэтому поисковики теперь первым делом сравнивают данные этого тега с фактическими словами в теле сайта и если находят несоответствие между первым и вторым, сразу же относят страницу к сомнительным и существенно понижают её рейтинг]
2. если вы не знаете — какая кодировка в вашем HTML-редакторе, то напишите какой-нить коротенький HTML-файл с русским текстом, не прописывая в нём и запустите в браузере, предварительно установив в браузере «Автоматическое определение кодировки» когда страница с вашим файлом загрузится (и все русские буквы будут читабельны), посмотрите «Информацию о странице» — там будет прописана определённая браузером фактическая кодировка вашего HTML-редактора
3. если кодировка вашего HTML-редактора вас не устроит, соответственно, писать вам надо будет в HTML-редакторе, в котором есть возможность сохранить файл в нужной кодировке сам я использую Notepad++ (в сети найдёте, он бесплатен) в нём есть пункт меню «Кодировка», в ней надо выбрать «Кодировать в UTF-8 (без BOM)»
4. всё это будет нормально работать из-под вашего локального компьютера однако, при сохранении на сервере вполне возможна проблема дело в том, что в серверном файле .htaccess существует команда принудительной установки кодировки, в которую сервер преобразует ВСЕ свои файлы, отдавая их браузерам пользователей и вполне может быть, что там у вас прописано AddDefaultCharset windows-1251 эту строчку вам надо просто удалить — тогда по умолчанию будет utf-8 (а лучше принудительно записать AddDefaultCharset utf-8)
Ответить
яса1 огромный респект, заработало =D .
CMS джумла, в БД инфа в UTF-8 — всё ОК!
Причина была в том, что у Вас описано в п.4 — зашел на хост, а там в настройках вирт сервера «Кодировка сайта — win1251». Поменял на utf — всё встало на свои места! Стало быть настройки сервера оказались важнее для браузеров, чем мой хидер.
Были уже неск лет назад подобные заморочки — не знал, что можно было таким не сложным способом вылечить. Тогда, я помню, менял кодировку контента %
Спасибо ещё раз!
Ответить
meta content=»text/html; charset=utf-8, это не заголовок, вот если бы вы передавали его как header(), вот это было бы заголовком, а так ваш сервер передавал этот заголовок со значением по умолчанию.
Ответить
Да, пардон, ошибся. Имел ввиду , а написал совсем другое.
Источник
Drupal Русскоязычное сообщество
Проблема: Если с моего сайта на (Drupal, utf-8) пользователь IE переходил на сайт с другой кодировкой (cp1251), а потом возвращался на мой сайт, то в IE сбивалась кодировка и все уже посещенные закэшированные страницы отображались кракозябрами (в кодировке cp1251).
Голову сломал прежде чем разобрался. Дело было вот в чем:
Drupal5
Блог
Войдите или зарегистрируйтесь, чтобы отправлять комментарии
Комментарии
Еще и важны в документе. Не забывайте о них! Кстати у тёмы ещё есть предрассудки: — насчёт не писать DOCTYPE. Я, как и большинство считаю, что его нужно стараться писать, несмотря на необязательность.
Drupal ведь сам это прописывает
Войдите или зарегистрируйтесь, чтобы отправлять комментарии
Drupal ведь сам это прописывает
Войдите или зарегистрируйтесь, чтобы отправлять комментарии
отдавайте сервером http заголовки с указанием кодировки
DOCTYPE было прописано, http сервер выдавал с указанием кодировки, даже и были на месте, а вот приведенного мета тега небыло в используемой мной теме, поэтому возник такой непонятный глюк в IE.
Если у тебя заголовком отсылалась кодировка, то пока ты руками на сменишь её в браузере, она будет той, что отослал сервер. Мета «Content-Type» это не панацея, это фигня .. на которую давно положили все браузеры
http://biota.ru/trash/one/ — UTF-8 страница. Как выглядит? Читабельно? Хмм http://biota.ru/trash/two/ — Тоже UTF-8 страница. Ура, всё понятно
В первом случае сервер отсылает заголовок в котором указан windows-1251, во втором UTF-8. И эта директива для браузеров является приоритетной. К сожалению сейчас не могу посмотреть будет ли работать мета в том случае если не отсылается заголовка о кодировке документа .. но мне кажется что будет, хотя может и нет.
Посему считаю данное громогласное заявление:
Всегда прописывайте: meta http-equiv= «Content-Type» content= «text/html; charset=utf-8» >
Войдите или зарегистрируйтесь, чтобы отправлять комментарии
В том то и дело что я описываю баг IE 6.0 к которому (к багу) данное выражение не применимо: «Если у тебя заголовком отсылалась кодировка, то пока ты руками на сменишь её в браузере, она будет той, что отослал сервер. Мета «Content-Type» это не панацея, это фигня .. на которую давно положили все браузеры =)» Баг заключался в следующем: Если с моего сайта на (Drupal, utf-8) пользователь IE переходил на сайт с другой кодировкой (cp1251), а потом возвращался на мой сайт, то в IE сбивалась кодировка и все уже посещенные закэшированные страницы отображались кракозябрами (в кодировке cp1251). То есть IE запоминал кодировку с другого сайта и применял к закэшированным страницам моего сайта. В результате при повторном посещении моего сайта у пользователей вываливалась абра-кадабра. Еще раз повторяю — это глюк IE 6.0, я просто описал как с ним бороться.
Войдите или зарегистрируйтесь, чтобы отправлять комментарии
Мда? А у меня на нескольких компах в ИЕ нету такого бага, если нормально прописать заголовок кодировки. Может у вас IE не лицензионный?
Войдите или зарегистрируйтесь, чтобы отправлять комментарии
Не знаю — на нескольких компах такой глюк был.
Войдите или зарегистрируйтесь, чтобы отправлять комментарии
Здравствуйте. Подскажите где прописать/> У меня код с наклонной чертой. И валидатор выдает ошибку. Как убрать красную палку? мой сайт
кодировка не так важна на самом деле как кажется. ) достаточно заголовка сервера, как правило
Войдите или зарегистрируйтесь, чтобы отправлять комментарии
Трекер
адаптация модулей Д7 на Д9
Лишние link rel на страницах термина.
Вернуть стандартное меню к заводским настройкам
Почему возникают такие ошибки при добавлении модуля через ftp?
Обновлённый модуль quote для цитирования
Ищу удалённую работу за 40 руб в час. Живу под Калининградом.
Сделать из простого списка выпадающий на js для Drupal 8
Стартовая страница вместо главной с кнопкой перехода на Drupal 8
CRM на Drupal
Ищу проф. программера со знанием английского
Новые материалы
адаптация модулей Д7 на Д9
Вернуть стандартное меню к заводским настройкам
Лишние link rel на страницах термина.
Сделать из простого списка выпадающий на js для Drupal 8
Стартовая страница вместо главной с кнопкой перехода на Drupal 8
Поиск на странице
Почему возникают такие ошибки при добавлении модуля через ftp?
Как получить значения поля «Текст (список)»?
Ограничение на общее количество полей сущностей Drupal 9.1
Сформировать массив в hook
На развитие drupal.ru
Ваша финансовая помощь дает нам возможность оплачивать хостинг и поддерживать стабильную работу сайта. Благодарим за поддержку!
Источник
Привет
Русскоязычный информационно-болтологический форум
HTML + meta http-equiv charset = НЕ РАБОТАЕТ 🙁
HTML + meta http-equiv charset = НЕ РАБОТАЕТ 🙁
Post by Pukite » Thu Jan 29, 2004 3:44 am
Необходима скорейшая помощь! Имеется webmail http://webmail.[..auto-moderated. ] , если посмотреть View -> Source, то увидим кодировку utf-8, как и должно быть, НО: реально она устанавливается на Western European, судя показаниям M$IE всех сортов 🙁
Вопрос — ЧТО ДЕЛАТЬ? Сижу и пл’ачу .
Post by A. Fig Lee » Thu Jan 29, 2004 3:55 am
У меня так работает:
Post by Pukite » Thu Jan 29, 2004 3:57 am
A. Fig Lee wrote: У меня так работает:
Нет, регистр здесь ни при чем, у меня на других страницах и маленькими буквами работает.
Post by A. Fig Lee » Thu Jan 29, 2004 4:40 am
Post by chip700 » Thu Jan 29, 2004 6:59 am
Re: HTML + meta http-equiv charset = НЕ РАБОТАЕТ 🙁
Post by Strannik223 » Thu Jan 29, 2004 8:33 am
Pukite wrote: Привет, коллеги !
Необходима скорейшая помощь! Имеется webmail http://webmail.[..auto-moderated. ] , если посмотреть View -> Source, то увидим кодировку utf-8, как и должно быть, НО: реально она устанавливается на Western European, судя показаниям M$IE всех сортов 🙁
Вопрос — ЧТО ДЕЛАТЬ? Сижу и пл’ачу .
Плакать не надо telnet webmail.[..auto-moderated. ] http HTTP-1.1 GET / =================================== HTTP/1.1 400 Bad Request Date: Thu, 29 Jan 2004 16:29:14 GMT Server: Apache/1.3.27 (Unix) Connection: close Content-Type: text/html; charset=iso-8859-1 ^^^^^^^^^^^^^^^^^^^^ ====================================
И кто у нас админ сервера? Кому п*****у бить будем?
Re: HTML + meta http-equiv charset = НЕ РАБОТАЕТ 🙁
Post by Pukite » Thu Jan 29, 2004 9:45 am
Я админ, но бить меня не надо 🙂 На том же сервере стоит множество других страниц с самыми разными кодировками, которые прекрасно работают, без вышеупомянутых глюков — как сие объяснить-то?
И какое отношение имеет сервер к странице, на которой указана желаемая кодировка?
Re: HTML + meta http-equiv charset = НЕ РАБОТАЕТ 🙁
Post by Strannik223 » Thu Jan 29, 2004 7:30 pm
Pukite wrote: Я админ, но бить меня не надо 🙂 На том же сервере стоит множество других страниц с самыми разными кодировками, которые прекрасно работают, без вышеупомянутых глюков — как сие объяснить-то?
И какое отношение имеет сервер к странице, на которой указана желаемая кодировка?
Объяснить можно только факты, а их нет Какие кодировки? Проблема только с utf? Какая кодировка в http заголовках этих самых «других» файлов?
Попробуй закоментировать Апачу AddDefaultCharset и не забудь перестартовать его, если полечиться, значит в этом дело, дальше надо будет разобраться как проставить кодировку тоько на одну диркекторию
Re: HTML + meta http-equiv charset = НЕ РАБОТАЕТ 🙁
Post by Strannik223 » Thu Jan 29, 2004 7:36 pm
Источник
Не работает meta http equiv charset
Find centralized, trusted content and collaborate around the technologies you use most.
Teams
Connect and share knowledge within a single location that is structured and easy to search.
In order to define charset for HTML5 Doctype, which notation should I use?
8 Answers 8
In HTML5, they are equivalent. Use the shorter one, as it is easier to remember and type. Browser support is fine since it was designed for backwards compatibility.
Both forms of the meta charset declaration are equivalent and should work the same across browsers. But, there are a few things you need to remember when declaring your web files character-set as UTF-8:
Save your file(s) in UTF-8 encoding without the byte-order mark (BOM).
Declare the encoding in your HTML files using meta charset (like above).
Your web server must serve your files, declaring the UTF-8 encoding in the Content-Type HTTP header.
Apache servers are configured to serve files in ISO-8859-1 by default, so you need to add the following line to your .htaccess file:
This will configure Apache to serve your files declaring UTF-8 encoding in the Content-Type response header, but your files must be saved in UTF-8 (without BOM) to begin with.
Notepad cannot save your files in UTF-8 without the BOM. A free editor that can is Notepad++. On the program menu bar, select «Encoding > Encode in UTF-8 without BOM». You can also open files and re-save them in UTF-8 using «Encoding > Convert to UTF-8 without BOM».
Another reason to go with the short one is that it matches other instances where you might specify a character set in markup. For example:
Consistency helps to reduce errors and make code more readable.
Note that the charset attribute is case-insensitive. You can use UTF-8 or utf-8, however UTF-8 is clearer, more readable, more accurate.
Also, there is absolutely no reason at all to use any value other than UTF-8 in the meta charset attribute or page header. UTF-8 is the default encoding for Web documents since HTML4 in 1999 and the only practical way to make modern Web pages.
Also you should not use HTML entities in UTF-8. Characters like the copyright symbol should be typed directly. The only entities you should use are for the 5 reserved markup characters: less than, greater than, ampersand, prime, double prime. Entities need an HTML parser, which you may not always want to use going forward, they introduce errors, make your code less readable, increase your file sizes, and sometimes decode incorrectly in various browsers depending on which entities you used. Learn how to type/insert copyright, trademark, open quote, close quote, apostrophe, em dash, en dash, bullet, Euro, and any other characters you encounter in your content, and use those actual characters in your code. The Mac has a Character Viewer that you can turn on in the Keyboard System Preference, and you can find and then drag and drop the characters you need, or use the matching Keyboard Viewer to see which keys to type. For example, trademark is Option+2. UTF-8 contains all of the characters and symbols from every written human language. So there is no excuse for using — instead of an em dash. It is not a bad idea to learn the rules of punctuation and typography also . for example, knowing that a period goes inside a close quote, not outside.
Using a tag for something like content-type and encoding is highly ironic, since without knowing those things, you couldn’t parse the file to get the value of the meta tag.
No, that is not true. The browser starts out parsing the file as the browser’s default encoding, either UTF-8 or ISO-8859-1. Since US-ASCII is a subset of both ISO-8859-1 and UTF-8, the browser can read just fine either way . it is the same. When the browser encounters the meta charset tag, if the encoding is different than what the browser is already using, the browser reloads the page in the specified encoding. That is why we put the meta charset tag at the top, right after the head tag, before anything else, even the title. That way you can use UTF-8 characters in your title.
You must save your file(s) in UTF-8 encoding without BOM
That is not strictly true. If you only have US-ASCII characters in your document, you can Save it as US-ASCII and serve it as UTF-8, because it is a subset. But if there are Unicode characters, you are correct, you must Save as UTF-8 without BOM.
If you want a good text editor that will save your files in UTF-8, I recommend Notepad++.
On the Mac, use Bare Bones TextWrangler (free) from Mac App Store, or Bare Bones BBEdit which is at Mac App Store for $39.99 . very cheap for such a great tool. In either app, there is a menu at the bottom of the document window where you specify the document encoding and you can easily choose «UTF-8 no BOM». And of course you can set that as the default for new documents in Preferences.
But if your Webserver serves the encoding in the HTTP header, which is recommended, both [meta tags] are needless.
That is incorrect. You should of course set the encoding in the HTTP header, but you should also set it in the meta charset attribute so that the page can be Saved by the user, out of the browser onto local storage and then Opened again later, in which case the only indication of the encoding that will be present is the meta charset attribute. You should also set a base tag for the same reason . on the server, the base tag is unnecessary, but when opened from local storage, the base tag enables the page to work as if it is on the server, with all the assets in place and so on, no broken links.
Or you can just change the encoding of particular file types like so:
A tip for serving both UTF-8 and Latin-1 (ISO-8859-1) files is to give the UTF-8 files a «text» extension and Latin-1 files «txt.»
Finally, consider Saving your documents with Unix line endings, not legacy DOS or (classic) Mac line endings, which don’t help and may hurt, especially down the line as we get further and further from those legacy systems. An HTML document with valid HTML5, UTF-8 encoding, and Unix line endings is a job well done. You can share and edit and store and read and recover and rely on that document in many contexts. It’s lingua franca. It’s digital paper.
Ответить
