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

Еще раз по ходу дела - пока вы не приведете данные в базе и не важно какая она у вас, а об 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-файлов случайные пробелы, переводы строк и еже с ними ВОМ, которые могут быть перед тегом РНР, попадают в тело РНР кода, а значит не будут выводиться бесконтрольно в браузер.