Encode utf 8 не работает

Проблемы с кодировкой на сайте

Одной из самых частых проблем, с которой сталкивается начинающий Web-мастер (да и не только начинающие), это проблемы с кодировкой на сайте. Даже у меня постоянно появляется при создании сайтов «абракадабра«. Но, благо, я прекрасно знаю, как эту проблему решить, поэтому всё привожу в порядок в течение нескольких секунд. И в этой статье я постараюсь научить Вас также быстро решать проблемы, связанные с кодировкой на сайте.

Первое, что стоит отметить, это то, что все проблемы с появлением «абракадабры» связаны с несовпадением кодировки документа и кодировки, выставляемой браузером. Допустим, документ в windows-1251, а браузер почему-то выставляет UTF-8. А уже источником такого несовпадения могут быть следующие причины.

Первая причина

Неправильно прописан мета-тег content-type. Будьте внимательны, в нём всегда должна находиться та кодировка, в котором написан Ваш документ.

Вторая причина

Вроде бы, мета-тег прописан так, как Вы хотите, и браузер выставляет именно то, что Вы хотите, но почему-то всё равно с кодировкой проблемы. Здесь, почти наверняка, виновато то, что сам документ имеет отличную кодировку. Если Вы работаете в Notepad++, то внизу справа есть название кодировки текущего документа (например, ANSI). Если Вы ставите в мета-теге UTF-8, а сам документ написан в ANSI, то сделайте преобразование в UTF-8 (через меню «Кодировки» и пункт «Преобразовать в UTF-8 без BOM«).

Третья причина

Мета-тег написан правильно, кодировка документа верная, но браузер почему-то настойчиво выбирает другую кодировку. Это уже связано с настройками сервера. Способ решения данной проблемы можно прочитать здесь: как задать кодировку в htaccess.

Четвёртая причина

И, наконец, последняя популярная причина — это проблема с кодировкой в базе данных. Во-первых, убедитесь, что все Ваши таблицы и поля написаны в одной кодировке, которая совпадает с кодировкой остального сайта. Если это не помогло, то сразу после подключения в скрипте выполните следующий запрос:

Вместо «utf8» может стоять другая кодировка. После этого все данные из базы должны выходить в правильной кодировке.

В данной статье я, надеюсь, разобрал, как минимум, 90% проблем, связанных с появлением «абракадабры» на сайте. Теперь Вы должны расправляться с такой популярной и простой проблемой, как неправильная кодировка, в два счёта.

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

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

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

Она выглядит вот так:

BB-код ссылки для форумов (например, можете поставить её в подписи):

Комментарии ( 33 ):

Помогите пожалуйста мне. Я делаю чат и все сообщения заносятся в файл log.html. но при выводе они становятся кракозябрами(русские буквы, а с английскими всё нормально). Что мне делать

Всё исправил но непонятно как. надо было обработчик и файл с сообщениями поставить в кодировку utf-8 а всё остальное оставить в кодировке windows-1251. И как он вообще работает. Интересно

поменяй все на юникод тогда будет работать или своем браузере поменяй кодировку

Здравствуйте Михаил! Проблема такая: в файле html кодировка написана так: , в проге нотпад++ стоит галочка UTF-8 без БOМ, при написание заголовка русские буквы видит коряво а англ норма, ставлю просто утф 8 все нормально! а рекомендуется делать без бoм! В чем проблема и как ее решить. Спасибо!

Спасибо Михаил))я разобрался со своей проблемой))спасибо)Удачи)

У меня почему то с UTF 8 без BoM не работает, а с обычным Utf 8 прекрасно, чем они отличаются кто нить может объяснить?

Они ничем не отличаются кроме того, что с BOM в начало файла добавляются невидимые символы, которые могут помешать в работе с php

А что если заголовок (title) в кодировке без BOM отображается не корректно. Вы как это исправили, Михаил?

Такого быть не должно. utf-8 без bom это практически та же кодировка.

Обычная UTF-8 оставляет отметку которая указывает что файл записан в кодировке UTF-8, но как сказал выше Михаил это может помешать работе PHP. То что браузер без этой пометки не может определить кодировку файла ваша ошибка, убедитесь что вы корректно написали

Михаил не один из выше перечисленных способов не подошёл, Помогите пожалуйста зарегистрировался на hostia и не могу там разобраться с кодировкой, вроде бы всё сделал правильно да и на локальном сервере работает и на других бесплатных хостингах тоже, а вот на hostia ерунда какая-то, и самое главное что кодировка нарушается только для тех страниц которые вывожу через БД.

В самой базе может стоять другая кодировка.

Михаил, у меня такая проблема ! Все что выводится из базы, нормально отображается. Но все, остальное идет иероглифами. Кодировка в мата-теге utf-8 в нотпаде тоже менял на utf-8 без бум, все равно не помогает. В чем может быть причина.

А на сервере какая прописана проверили?

И кстати у меня почему то документы css не работают.Вообще не могу поменять ни цвет текста ни цвет самого фона

http://myrusakov.ru/kak-zadat-css-stil.html и используйте Firebug.

привет,почему проблемы с кодировкой на хостинге,а на локальном сервере все нормально?.на сайте стоит кодировка utf8.есть файл htaccess.

Напишите хостеру, возможно, он поможет. Быть может, он запретил использовать AddDefaultCharset.

прописал эту строчку в конфигурационном файле и все норм.mysql_query («SET NAMES ‘utf8′»);

Михаил, здравствуйте. У меня была проблема с кодировкой вывода текста из php скрипта. Мне удалось решить проблему лишь путем явного указания внутренней кодировки mb_internal_encoding(«UTF-8»); В перечисленных Вами способах, данный не указан. Вопрос: можно ли обойтись без явного указания ? //mb_internal_encoding(«UTF-8»);

Если использовать строковые функции, то без указания кодировки не обойтись.

Источник

Решение типовых проблем с json_encode (PHP)

Это краткая статья о наиболее вероятных проблемах с json_encode и их решениях. Иногда при кодировании данных в json, с помощью json_encode в php, мы получаем не тот результат который ожидаем. Я выделил три наиболее частые проблемы с которыми сталкиваются программисты:

• доступ к полям
• кодировка текстовых значений
• цифровые значения

Доступ к полям

Проблема заключается в том что json_encode имеет доступ только к публичным полям объекта. Например если у вас есть класс

то результатом выполнения следующего кода будет:

как видно в результирующий json были включены только публичные поля.
Что же делать если нужны все поля?

Решение

Для php = 5.4:
достаточно будет реализовать интерфейс JsonSerializable для нашего класса, что подразумевает добавление метода jsonSerialize который будет возвращать структуру представляющую объект для json_encode

Теперь мы можем использовать json_encode как и раньше

Почему не стоит использовать подход с toJson методом?

Многие наверно заметили что подход с созданием метода возвращающего json может быть использован и в версиях php >= 5.4. Так почему же не воспользоваться им? Все дело в том что ваш класс может быть использован как часть иной структуры данных

и результат уже будет совсем другой.
Также класс может использоваться другими программистами, для которых такой тип получение json-а с объекта может быть не совсем очевиден.

Что если у меня очень много полей в класcе?

В таком случае можно воспользоваться функцией get_object_vars

А если нужно private-поля, из класса, который нет возможности редактировать?

Может получиться ситуация когда нужно получить private поля (именно private, т.к. доступ к protected полям можно получить через наследование) в json-е. В таком случае необходимо будет воспользоваться рефлексией:

Кодировка текстовых значений

Кириллица и другие знаки в UTF8

Второй тип распространённых проблем с json_encode это проблемы с кодировкой. Часто текстовые значения которые нужно кодировать в json имеют в себе символы в UTF8 (в том числе кириллица) в результате эти символы будут представлены в виде кодов:

Отображение таких символов лечится очень просто — добавлением флага JSON_UNESCAPED_UNICODE вторым аргументом к функции json_encode:

Символы в других кодировках

Функция json_encode воспринимает строковые значения как строки в UTF8, что может вызвать ошибку, если кодировка другая. Рассмотрим маленький кусочек кода (данный пример кода максимально упрощен для демонстрации проблемной ситуации)

На первый взгляд ничего не предвещает проблем, да и что здесь может пойти не так? Я тоже так думал. В подавляющем большинстве случаев все будет работать, и по этой причине поиск проблемы занял у меня несколько больше времени, когда я впервые столкнулся с тем что результатом json_encode было false.

Для воссоздания такой ситуации предположим что p=%EF%F2%E8%F6%E0 (на пример: localhost?=%EF%F2%E8%F6%E0 ).
*Переменные в суперглобальных массивах $_GET и $_REQUEST уже декодированы.

Как можно увидеть из ошибки: проблема с кодировкой переданной строки (это не UTF8). Решение проблемы очевидное — привести значение в UTF8

Цифровые значения

Последняя типовая ошибка связана с кодированием числовых значений.

Как известно php не строго типизированный язык и позволяет использовать числа в виде строки, в большинстве случаев это не приводит к ошибкам внутри php приложения. Но так как json очень часто используется для передачи сообщений между приложениями, такой формат записи числа может вызвать проблемы в другом приложении. Желательно использовать флаг JSON_NUMERIC_CHECK:

Уже лучше. Но как видим «3.0» превратилось в 3, что в большинстве случаев будет интерпретировано как int. Используем еще один флаг JSON_PRESERVE_ZERO_FRACTION для корректного преобразования в float:

Прошу также обратить внимание на следующий фрагмент кода, что иллюстрирует ряд возможных проблем с json_encode и числовыми значениями:

Спасибо за прочтение.

Буду рад увидеть в комментариях описание проблем, с которыми вы сталкивались, что не были упомянуты в статье

Источник

encoding=’utf8′ не решает проблему с кодировкой при записи в файл

UPD Если у вас такая же проблема и вы не хотите мучиться, то просто запишите файл в utf-16, а utf-8. У меня в задаче, кроме кириллицы и латиницы были ещё китайские и японские иероглифы, всё нормально записалось.

Я запарсил 200 страниц с данными 10к пользователей одного небольшого сайта и пытаюсь записать их в csv файл в таком формате:

И так 10 тысяч раз.

Всё идёт хорошо, пока дело не доходит до пользователей со всякими необычными символами в именах, выскакивает ошибка ‘charmap’ codec can’t encode character ‘\xf6′ in position 2: character maps to Я её загуглил и добавил encoding=’utf8’ в свой код, как советовали во всех ответах, ошибка исправилась, но все имена пользователей, в которых использовали кириллицу, записались вот так Крестьянин . Что делать? Может можно как-то разделить имена при парсинге или после него на нормальные и особенные? Вот функция записи в csv.

2 ответа 2

Проверьте users[‘Nickname’] , уверен уже в этих строках у вас будут кракозябры вида Крестьянин .

Если вы откуда-то скачиваете данные с этими строками убедитесь что она пришли как utf-8 и что вы с ними не делаете преобразования в cp1251 . Если у вас Windows, то преобразование в cp1251 может быть неявным при работе с методами encode / decode , или с bytes — если при работе с ними не указывать кодировку, то подставится системная.

Ниже информация по кодировкам (сложная эта тема. ).

Файл лучше всего хранить в кодировке utf-8 , но нужно убедиться, что и остальные строки у вас будут той же кодировке.

Например, берем исходную строку:

Как мы видим, в ней 10 символов. Теперь кодируем ее в байты как utf-8 :

И размер стал в два раза больше. Выходит, что кириллица в utf-8 хранится не в одном байте, а в двух. Теперь попробуем эту байтовую строку кодированную в utf-8 декодировать в строку cp1251 :

Получаем наши кракозябры. Это потому что cp1251 (она же windows-1251) однобайтовая кодировка.

Берем первые 4 байта из utf-8, декодируем как cp1251 и получаем знакомые символы:

Теперь мы зная причину появления кракозябр можем получить исходную строку через обратные действия:

Источник

Как решить проблему с кодировкой UTF-8?

Пишу в PyCharm и вроде как там с кодировкой проблем не должно возникать, однако удача меня обошла стороной.
При запуске локального сервера возникает следующая ошибка:

Unhandled exception in thread started by .wrapper at 0x035B1B28>
Traceback (most recent call last):
File «C:\Users\Tony\AppData\Local\Programs\Python\Python36-32\lib\site-packages\django\utils\autoreload.py», line 227, in wrapper
fn(*args, **kwargs)
File «C:\Users\Tony\AppData\Local\Programs\Python\Python36-32\lib\site-packages\django\core\management\commands\runserver.py», line 149, in inner_run
ipv6=self.use_ipv6, threading=threading, server_cls=self.server_cls)
File «C:\Users\Tony\AppData\Local\Programs\Python\Python36-32\lib\site-packages\django\core\servers\basehttp.py», line 164, in run
httpd = httpd_cls(server_address, WSGIRequestHandler, ipv6=ipv6)
File «C:\Users\Tony\AppData\Local\Programs\Python\Python36-32\lib\site-packages\django\core\servers\basehttp.py», line 74, in __init__
super(WSGIServer, self).__init__(*args, **kwargs)
File «C:\Users\Tony\AppData\Local\Programs\Python\Python36-32\lib\socketserver.py», line 453, in __init__
self.server_bind()
File «C:\Users\Tony\AppData\Local\Programs\Python\Python36-32\lib\wsgiref\simple_server.py», line 50, in server_bind
HTTPServer.server_bind(self)
File «C:\Users\Tony\AppData\Local\Programs\Python\Python36-32\lib\http\server.py», line 138, in server_bind
self.server_name = socket.getfqdn(host)
File «C:\Users\Tony\AppData\Local\Programs\Python\Python36-32\lib\socket.py», line 673, in getfqdn
hostname, aliases, ipaddrs = gethostbyaddr(name)
UnicodeDecodeError: ‘utf-8’ codec can’t decode byte 0xcf in position 5: invalid continuation byte

Заморочился и пересохранил все файлы в UTF-8 — не помогло. Пересмотрел кодировку каждого файла в самом PyCharm’e — везде UTF-8. Нашел на некоторых форумах такую же проблему — в качестве решения предлагалось переименовать имя компьютера в ASCII кодировку (на латинице короче говоря). Весь путь на латинице — ноль изменений. В каждом файле писал комментарий с кодировкой:
# coding: utf8
и вот так, что одно и то же
# -*- coding: utf-8 -*- .
Результата как не было, так и нет. Весь день копаюсь, так до сих пор и без понятия в чем дело.
Использую фреймворк Django (может что на нем завязано).
Надеюсь на вашу помощь. Заранее спасибо!

Источник