Ошибка кодировки
 

Доброго времени суток!
Не могли бы Вы мне помочь?
У меня вдруг внезапно отказала русская кодировка на странице, вместо слов пишутся ??????, однако она отказала как-то выборочно, т.е в div находится одновременно данные из бд и просто вписанный по умолчанию текст. Те, что были взяты из БД отображаются верно, а вот те что по умолчанию -нет. Точнее даже такое происходит только в одном div, в остальных же на этой странице все отображается корректно. И в БД и на странице указана кодировка UTF-8.
Кто -нибудь сталкивался с подобным? как это можно исправить?

Файл этот должен быть также сохранен в utf.

текст для этого div берется из файла php, в файлике htaccess ставила соответствующие настройки AddDefaultCharset UTF-8, но они не помогли

Все ваши файлы на сервере, включая и php должны быть сохранены в utf. Если это не так и файл содержит текст, то никакие charset не помогут.

Огромное Вам спасибо!!!
У меня, действительно оказалась неверной кодировка именно в этом файле.Причем непонятной осталась причина, по которой она поменялась... у файлов может быть потеря памяти?

Если верить британским ученым, то файлы склерозом не страдают.

думаете им можно верить?:-?
если так, то виновник может быть только один.... Бегу вызывать экзорцистов!

В редакторе нужно установить кодировку по умолчанию при создании и сохранении документов и шарлатанов не потребуется )

Спасибо) учту на будущее)

Доброго времени суток всем.
У меня собственно ситуация схожая с оной у ТС, но вот какая штука:
Есть php-файл, который соединяется с БД Oracle (9i), достает оттуда данные и пишет их в массив для последующей обработки. Сама база возвращает текстовые поля в кодировке Win-1251, которые php конвертирует с помощью iconv() в utf-8. В итоге отображается только нужная часть данных.
Есть JS, который выводит результат работы php в определенный div на странице.
Но в Firefox 44 и в IE 8(завалялся и такой) в div отображаются иероглифы вида "Дата поступР". В Chrome 48 все выглядит нормально.
Все *.php, и *.js файлы сохранены в кодировке UTF-8 + BOM.
Что пробовал:
1) менять кодировку всех исходных файлов в utf-8 без BOM - ничего не меняется;
2) добавлять header() в начало файла php - выскакивает предупреждение, что оный файл уже установил заголовок, менять нельзя;
3) добавить .htaccess с текстом "AddDefaultCharset UTF-8" в каталог с php-файлами - безрезультатно.
4) грузить файл php пробовал и через .load() и через .ajax(get) - результат одинаков.
5) проверил <meta> - там стоит utf-8.

П.С. Прошу сильно не пинать... я html изучаю отсилы полтора месяца, а php и js и того меньше :(

код дайте как пытаетесь установить заголовок в php.

destus

header('Content-type: text/html; charset="utf-8"');

результат: Warning: Cannot modify header information - headers already sent by (output started at C:\WEB\www\new_menu\news.php:1) in C:\WEB\www\new_menu\news.php on line 3

собственно js-функции, которые грузят php:

function get_db() {
	$(document).ready(function(){
 	$("#soon-news").load("news.php");
 });

}

либо

function n_load() {
	$.ajax(
	{
		type: "GET",
		cache: false,
		url: "news.php",
		data: "",
		success: function(data)
		{
			$('#soon-news').html(data);
		}
	});
}

P.S. Если php-файл подключить через require(), то всё отображается как надо. Но мне надо, что-бы страница грузилась в любом случае, а нужный div - если БД доступна/открыта (она на другом сервере)

А что идет до 3ей строчки в news.php? Пустая строка и пробел перед <? тоже считается за вывод информации, соответсвенно нельзя установить заголовок.

<?php	
	// http://javascript.ru/forum/jquery/11430-kodirovka-load.html
	header('Content-type: text/html; charset="utf-8"');
	if ($conn=oci_connect(...)) {

первая строчка начинается непосредственно с "<", вторая строчка - комментарий-подсказка (ссылка, где подсмотрел инфо про(headers()), третья - установка заголовка, четвертая - if(){ далее идет попытка подключения к базе. Cкрипт завершается закрытием "}" оного if()

в .htaccess добавить

CharsetDisable On
AddDefaultCharset UTF-8

1) база возвращает текстовые поля в кодировке Win-1251, которые php конвертирует с помощью iconv() в utf-8 - перевести данные базы в UTF единожды, чтобы не заставлять РНР заниматься постоянно лишней работой.

2) Все *.php, и *.js файлы сохранены в кодировке UTF-8 + BOM. - БЕЗ ВОМ! И это не для решения проблемы, а для того, чтобы предотвратить возможные (да практически неизбежные) "непонятные" проблемы впоследствии.

3) добавлять header() в начало файла php - выскакивает предупреждение, что оный файл уже установил заголовок, менять нельзя - вывод заголовка должен быть до любого вывода в браузер, чем является и ВОМ в том числе.

4) добавить .htaccess с текстом "AddDefaultCharset UTF-8" в каталог с php-файлами - установка кодировки по умолчанию устанавливается не на файлы каталога, а для данных отдаваемых сервером клиенту, кодировку файлов этот параметр не изменяет. Это информация для браузера.

5) грузить файл php пробовал и через .load() и через .ajax(get) - эти методы не грузят файл РНР, они запрашивают и получают данные результатов работы РНР файлов, к которым обращаются. В какой кодировке он их получит зависит или от переданного заголовка, или от AddDefaultCharset установленного в Апач.

6) проверил <meta> - там стоит utf-8 - если сервер отдает по умолчанию заголовки кодировки по умолчанию (AddDefaultCharset), то мета тег может быть и опущен.

Выполнить сначала по п. 1 и п. 2, а затем далее выяснять проблемы.

Ну да, прямо раз и готово, а если косяки иные?

я делаю так:

while (oci_fetch ($st)) {
	$employees[] = array(
	"fio" => iconv("windows-1251", "utf-8", oci_result($st, "FIO")),
	...
}

по-другому пока не умею

делал - не помогло. переделал все php и js-файлы. Так и оставил.

устанавиваю заголовок в 3 строчке скрипта. первый вывод в браузер - в 5-й (временно - подтверждение коннекта к базе, потом будет не ранее 57-й)

добавил. сам .htaccess положил в корень каталога со своей страничкой. Исходя из комментариев выше, браузер должен получить данные в кодировке UTF-8 (данные из каталога размещения .htaccess включая все подкаталоги)... НО не помогло. При этом Chrome почему-то получает данные в корректной кодировке, а FF и IE - нет.

Еще раз повторяю:

1) Перевести кодировку базы в UTF, а заниматься iconv("windows-1251", "utf-8",... постоянно при запросах, это нагружать сервер чепухой в то время, когда ему и так есть чем заняться. Нужно сделать единожды перекодровку и удалить из кода все преобразования iconv().

2) Забудьте раз и на всегда о БОМ, ибо это неконтролируемый вывод в браузер, который не раз породит проблемы при выдаче данных пользователю. Я писал, это нужно сделать обязательно, и не потому, что в данном случае они есть проблема с кодировкой.

3) Выполнить то что сказано в 1, 2.

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

PS. По ссылке база MySQL у вас Oracle, поэтому использовать ее запросы и параметры. Главное понять суть, ну или найдете в сети сами ссылку именно по Oracle, я взял первую попавшуюся, думаю искать в Гугл и сами можете.

laimas,
если не хотите помочь по-сути - не стоит лишний раз напоминать мне о моем непонимании, я и без Вас в курсе, что не силен ни в JS, ни в PHP, поскольку изучаю их крайне мало времени. Сюда обратился за конкретной помощью именно потому, что не шарю.
А теперь по ходу дела:

1) У меня БД Oracle, а не MySQL, и данные туда пишет/читает совсем сторонний софт. Я использую одну единственную таблицу, да и то скорее ради попрактиковаться в работе связки PHP+Oracle. Менять кодировку БД я не буду, т.к. остальной софт может ее не понять.
Можно, конечно, конвертнуть 1 лишь таблицу, но тогда мне не пришлось бы писать сюда, и тем самым узнать для себя много нового.
Кроме того, на моем сервере аж 2 (две) веб-странички. Апач в общей сложности использует аж 50 МБ памяти и <1% процессора - ему и в самом деле нечем заняться ;-)

2) Повторю: я конвертнул кодовую страницу всех без исключения исходников (*.html, *.css, *.php, *.js) в UTF-8 БЕЗ BOM!!! И так оставил.

3) Кажется, проблема была в том, что после

<?php

стоял символ табуляции и/или перенос строки. Убрал их и Warning по поводу некорректности установки заголовка пропал, ирезультат отобразился как надо.

Всем откликнувшимся - спасибо за помощь.

P.S. уважаемый laimas, может подскажете, как без iconv() конвертнуть кодировку принимаемой для парсинга страницы, когда целевой сервер отдает ее в win-1251? А то в моем другом php-файлике есть и такая штуковина...

И где это я вас упрекнул в не понимании?

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

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

Ну если вы еще эту чушь начнете нести, то стоит ли говорить дальше вообще?Это тоже полная чушь - все что между тегами <?php ?> без принудительного вывода echo, print и т.п., в браузер не выводится, а вот любое до тега <?php, включая ВОМ, есть как раз вывод а браузер, неконтролируемый! Будем по этому поводу далее продолжать полемику или все таки прекратим?

Без принудительной перекодировки, и не важно iconv() ли это, или иным способом естественно нельзя получить другую кодировку. Это как раз по чепухе типа "другой софт не поймет" - нет в рамках веб страницы "другого софта". Кодировка должна быть единой от базы данных до файлов, с которой надо определиться, и по многим параметрам дня сегодняшнего, это UTF. А уж отдавать (экспортировать) данные для "другого софта", принимать данные (импортировать) от "другого софта", это куда реже операции нежели постоянные запросы от клиентов, и тут конвертирование не будет столь обременительным.

laimas,
вы меня совсем не поняли, ну совсем. С сервером БД работает софт не web-платформы, а именно написанный на С++, дэлфи, с использованием тогоже VFP7. Софта много, разного... около 50 программ и комплексов, которые мусолят Базу. Все они написаны минимум лет 7 назад и совсем разными людьми (вероятно, даже с разных стран). Видимо тогда, при проектировании БД стандарт Win-1251 им подошел, оттого его и выбрали...
Далее цитата с сайта по вашей ссылке: а какраз сервер Oracle мне нагружать лишний раз неохота. Поэтому мне iconv() подходит: просто и быстро (я ж всего 44 записи достаю и конвертитую только 1 поле в каждой из них)
Кроме всего прочьего, сервер БД и веб-сервер в моем случае это физически 2 разных сервера. Второй в качестве веб-сервера использую (пока) только лишь я. Посему могу грузить-нагружать его без опасения и создания дискомфорта другим. А вся эта дребедень, которую я затеял - всего лишь, что-бы вывести в уголке моей старнички ближайшые Д/Р сотрудников. А почему гружу через JS/AJAX - потому, что это самый первый способ, который я нашел для реализации последовательности:
1) отобразить запрашиваемую страницу (все данные лежат на веб-сервере в виде файлов)
2)
-если есть проблеммы при соединении с БД, или она занята/недоступна по каким-либо причинам - не менять содержимое определенного блока (можно оставить пустым, главная цель - сама страница)
-если нет проблемм соединения с БД - отобразить в определенном блоке страницы список ближайших 5-ти Д/Р сотрудников.
П.С., laimas, кодировку поменял в "без BOM" еще до обращения сюда; .htaccess добавил еще до вашего первого ответа. После ваших предложений по пунктам 1 и 2 делал только: удалил табы, комментарии и переносы перед headers(), добавил в .headers строчку "CharsetDisable On" и собсно перезапустил службу апача. Что из этого помогло - понятия не имею, но помогло только что-то из этого. :yes:

Ну если база "мертвая" (не изменяется во времени), служит только для извлечения 44 записей, конвертируйте, это не так и много.

Если ВОМ было убрано до задания вопроса, то почему ВОМ отмечался в параметрах файлов? Или это всем померещилось?

удалил табы, комментарии и переносы перед headers(), это ерунда - я могу написать и так:

<?php


header(.....);
?>

и это не приведет к ошибке при передаче заголовка, ибо переводы строки что есть в коде не выводятся, а вот так:

<?php
header(.....);
?>

уже приведет к ошибке, если до открывающего тега РНР есть вывод в браузер (хоть один пробел, перевод строки), и ваш ВОМ в том числе будет таким выводом. ВОМ для веб страниц, это зло, и обсуждать этого даже не стоит.

писал же, что переделал, так и оставил

возможно про табы и комментарии и ерунда, но тогда остается строка "CharsetDisable On" в .headers... либо перезагрузка службы апача (я не знаю, когда именно апач смотрит в этот файл: при старте или непосредственно перед ответом браузеру)... как-то так

Возможно, BOM присутствует в php-файле до первого видимого в редакторе символа? Если да, то он вполне может быть виновником, поскольку сам php-файл в редакторе Notepad++ в первой строчке первые 5 символов отображает: <?php и только потом строка с установкой заголовка...

Если ни одно из вышеприведенного не может сменить кодировку, тогда не прав ни я, ни вы... ведь помогло именно что-то из этого. Ведь правда помогло. Ради эксперимента попробую проделать обратно пошагово всё, что-бы вычислить "виновника", но это уже будет после недельного отпуска ;)

И база не "мертвая"... людей же принимают на работу, увольняют, в пенсию отправляют... записи в базе будут меняться, но количество результирующих строк - не сильно ;)

П.С. Прочитал про BOM. Вы, laimas, были правы. Ставлю "+"

ВОМ всегда есть первые байты файла в многобайтной кодировке.

Интерпретатор РНР (как впрочем и все интерпретаторы) выполняет код исключительно в рамках своего тега. РНР будучи языком серверным, должен также уметь отдавать клиенту и "чистый" html:

<div>Text</div><!--вывод html в поток-->
<?php
//исполнение кода, все что не выводится принудительно конструкциями языка не есть вывод в браузер, 
//как дальнейшие переводы строк и табуляторы



    echo '<p>Text</p>'; //будет выведено только то, что содержит строка, конструкцией echo
                 $v = 'Text';
?>
<span><?=$v?></span><!--php-включение в html-->

Поэтому то, что до открывающего тега РНР отдается в поток вывода, а значит и ВОМ.

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

Как просто ларчик открывался.

На заметку: так как все что вне тегов РНР интерпретатор не обрабатывает и оно просто отдается в поток вывода, разработчики рекомендуют не использовать закрывающий php-тег в конце файлов. В этом случае при подключении php-файлов случайные пробелы, переводы строк и еже с ними ВОМ, которые могут быть перед тегом РНР, попадают в тело РНР кода, а значит не будут выводиться бесконтрольно в браузер.