Сталкнулся с такой же проблемой на windows сервере Апач (сборка Денвер).

Текст имеет нужную кодировку. А вот режим записи где то хранится тили в системе, толи в Апач. Так я не смог победить этот вопрос, и обошёл его просто.

Парадокс заключается в следующем:



Прошу обратить внимание, что:

1. AddDefaultCharset Windows-1251
2. Ранее в файл sql_array.txt происходила запись в текста в кодировке cp1251, всё было читаемо. Денвер перезапускался, файл удалялся, но попытка выполнить:

всегда приводила всегда к отрецательному результату.... При этом, если выполнить:

то всё прекрасно.

И лишь одно решение помогло:
открыть файл редактором текста, и принудительно сохранить его в UTF-8. После этого запись команды 

проходила удачно. 

Замечу, ни удание файла, ни перезапуск АПАЧ, ни замена AddDefaultCharset UTF-8 не помогали........
ЗЫ: что то здесь "виндовое" виновато....

Это сообщение отредактировал(а) slva2000 - 10.7.2010, 12:48

M skyboy

Выделено из темы "txt в utf8", потому как хоть ключевое слово и utf-8, но люди спотыкаются в разных местах.

ни AddDefaultCharset, ни header('Content-Type...charset не имеют отношения к кодировке данных при записи в файл. Это конструкции, которые информируют браузер о кодировке переданных в браузер же данных.
Т.е. то, что попадет в браузер после echo, print_r и прочих операторов вывода.
И все.
Как уже явно писали в теме, куда сразу ты разместил пост, в файл пишется просто набор байтов. Кодировка никак не влияет на механизм записи - кодировка как таковая может учитываться/изменяться только на этапе формирования строки.
Вот у тебя стоит 

Следовательно, в какой кодировке у тебя записано слово "Привет" в скрипте, в такой же кодировке текст окажется в файле. В какой у тебя кодировке сохранен РНР-скрипт? только от этого из зависит.

какому "отрицательному результату"? "крякозябрам"? 
    а вот теперь скажи, чем и как ты просматривал сохраненный файл? ты уверен, что это не проблема просмотра, а именно кодирования? например, при сохранении файла в кодировке UTF-8 без BOMO(а РНР сохраняет данные без добавления BOM в начало файла) виндовый блокнот некорректно определяет кодировку, как ср1251 и выводит текст "крякозябрами". Но это проблемы сугубо блокнота, а не записанного файла.

а такого не существует. 

да.



С ПК общаюсь давно, поэтому просмотровщиков в данном случае использовал несколько (AkelPad, EditPlus). 
В статус-строке этих вьюверов, при поптыке открыть файл, созданный нижеуказанной комманой, было указано: ANSI (1251),  Перенос cтрок - win.



Т.е. мне бы хотелось сделать акцент на следующем: что, почему то, ОС запоминает, в какой кодировке записан файл, и был созадн впервые, по определённому пути, и использует эту кодировке при попытке открывать этот файл во всех следующих ситуациях.

Изменить это понятие, можно лишь открыв файл в редакторе, и явно указать кодировку файла  - UTF-8. При следующем открытии файла, всё колрректно - русский в норме.

Итак, экспиримент с нуля, ещё раз (сам файл скрипта, имеет UTF-8):

1.


Всё удачно. BOM нет, данные читабельны даже notepad.exe.

2.
old_file_1.txt - файл, создаваемый ранее php скриптом из-под Апач (кодировка файла-скрипта - cp1251), имеющий кодировку ANSI 1251.

Отрицательно. Файл открывается криво, BOM нет, т.к. ANSI 1251

Ни удаление old_file_1.txt, ни перезапуск АПАЧ не даёт результат, как я и пасал в первом посте. Решает вопрос лишь ручная запись через редактор в UTF-8. 

ВОПРОС: как сделать эту операцию из скрипта (мне кажется топикстартер в посте, к которому я присоединился имел ввиду именно это).

Это сообщение отредактировал(а) slva2000 - 12.7.2010, 16:07

ну, так, выбери используемую кодировку UTF-8 и убедись, что файл записан правильно, а все проблемы - от того, что без BOM никакой редактор не сможет однозначно определить - записан ли в файле UTF-8, либо ANSI текст.


я же тебе писал: ВОМ и не появится сам по себе. file_put_contents записывают в файл только указанные данные. Нужен BOM - пиши его сам.

фак мой мозг! Это никак не относится к кодировке данных в файле. зачем ты это всюду вставляешь?!   

ОС тут совершенно ни при чем. все зависит от редактора-просмотрщика. 

а вот программа-редактор, в отличие от РНР-скрипта, делает вспомогательную работу: кроме текста, записывает ВОМ в файл. Тебе нужен ВОМ? Пиши его скриптом.

Добавлено через 5 минут и 35 секунд
подытожу, на всякий случай:
0. данные в файл у тебя сохраняются в UTF-8
1. РНРшные функции не писали и не будут писать в файл ничего, кроме переданных данных. ни BOM для текстовых файлов, ни заголовок ZIP-архива, ни ресурсы ЕХЕ-файлов. Только переданные данные(строки, символы, числа). Надо что-то дописать - указываешь явно: хочу записать такие-то байты.
2. проблемы у тебя только с редакторами, которыми ты просматриваешь сформированный файл. Notepad++, к примеру, корректно открывает файлы с текстом в Unicode, но без ВОМ. как он это делает? наверное, по обилию кодов 208(DO - часть двубайтного кода кирилических символов). 
3. ни header(), ни AddDefaultCharset не имеют ни малейшего отношения к формированию файла.

Добавлено через 7 минут и 55 секунд
и ещё уточнение: BOM - это не магическая сущность, а определенная стандартом Unicode последовательность байт. Следовательно, сформировать эту последовательность и записать в самое начало файла можно при помощи тех же функций записи в файл, что ты уже использовал.

Открываю редактор:
выбираю: сохранить в UTF-8, крыжик "BOM" активен, т.е.  можно выбрать, писать его или нет. При этом размер пустого файла увеличивается на 3 Байта. Всё понятно.... Кроме одного: выбираю ANSI, - BOM крыжик не активен. Т.е. checkbox - disable. Почитав спецификацию, понимаю, что BOM существует только для UTF-XX кодировок... Остальные, вероятно, определяются редакторами по другим признакам....

Вот на что наткнулся: "функция удаления BOM для файла".  



Но как добавить средствами php...? Ведь если будет BOM для UTF-8 (efbbbf), то и редакторы будет корректно открывать файл, в котором UTF-8 кодированный текст.

Добавлено через 6 минут и 13 секунд

извини меня, но это "не о том"... Специально скачал, попробовал:

в статус строке: "ANSI as UTF-8" То, что редактор смог конвертнуть на лету, этого не требуется. Требуется понять, почему текстовый файл записывается в ANSI, когда кругом UTF-8?!

Добавлено через 13 минут и 48 секунд
Прикрепил для наглядности:

ansi.php запустить первым. Затем запустить utf-8_to_ansi.php.

При этом, файл ansi.txt будет содержать кразозябры, даже если его удалить, и запустить utf-8_to_ansi.php. повторно.

Присоединённый файл ( Кол-во скачиваний: 6 )
 www.rar 0,22 Kb

ничего он не "конвертит". открывает, не обнаруживает ВОМ, обнаруживает признаки кирилицы в UTF-8, отображает с учетом того, что кодировка UTF-8. 

странно. "привет" записать можешь. а три байта, значения которых тебе известны - нет.

я вот не понимаю: ты отличаешь "РНР записывает данные в ANSI вместо UTF-8" от "текстовый редактор не может распознать utf-8 при отсутствии ВОМ"?   

skyboy, попробуй под WINDOWS выполнить два файла, которые я прикрепил... Это займёт 2 минуты...

?

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

какая разница - какая ОС? о_0
ладно, без проблем. windows, так windows.

первый записывает в файл "Привет" в кодировке ANSI.
второй записывает в файл "Привет" в кодировке UTF-8.
и че? тут должен быть вопрос "почему редактор ХХХХХ открывает файл с UTF-8 текстом, как ANSI?"? 

skyboy. Вопрос в следующем:

Почему после удаления файла созданного скриптом utf-8_to_ansi.php он опять создаётся такой же, некорректно читайемый...? А если этим же скриптом создать новый файл, то всё в порядке.

Я уже подозреваю, что ответ вовсе не в php...



Вопрос не в том, как получить данные в читабельном виде... А в том, что:
Почему после удаления файла созданного скриптом utf-8_to_ansi.php он опять создаётся такой же, некорректно читайемый...? А если этим же скриптом создать новый файл, то всё в порядке.

ЗЫ: у меня складывается впечатление, что я ставлю людей в тупик, и они начинают говорить о том, "...что всё это бред". Замечу, если вы чегото не понимаете, или не знаете как выразить, то это не означает, что этого нет.

Это сообщение отредактировал(а) slva2000 - 13.7.2010, 06:09

открой "некорректно читаемый" файл НЕХ-редактором.
открой "корректно читаемый" файл НЕХ-редактором.
сравни. 
обнаружь, что файлы идентичные.
задумайся.
приди к выводу, что дело не в РНР, а в редакторе, которым ты и устанавливаешь "читаемость" и "корявость".
только чур - не махлевать: редактором файл не пересохранять в режиме "Unicode". И вообще не пересохранять. Чтоб на файл влияло только поведение скрипта.

Всё решилось ещё проще:
переименовываем файл, открываем редактором - всё ок...
ну и бред... получается редакторы сохраняют путь до файла с именем, и при дальнейших открываниях его, вероятно, чтобы сократить время на определение кодировки, открывают в той кодировке, которая была определена ранее.... помоему это всё же виндовая фишка, потому как даже notaped ++ упомянул при открытии: ANSI as UTF-8... значит он откуда то взял инфу о том, что это д.б., якобы ANSI....

Ладно в любом случае, тема не про php... к счастью. Спасибо skyboy за терпение.   

notepad++ нормально определяет кодировку, если встречает в файле характерные символы. если же сохранить латинский текст (код, к примеру) и сохранить в утф-8, то редактору просто не за что будет зацепиться, ведь анси и утф для латиницы одинаковы. тогда он откроет файл в кодировке по умолчанию. для винды, это ессно анси

здравствуйте, напоролся на эту же проблему с сохранением txt файла в кодировке utf8. Я так и не разобрался в результате переписки в этой теме, но эта проблема решилась сохранением в  файл через fwrite() русских букв, иначе кодирует как ANSI, работаю в notepad++ и денвер'е, выводит все корректно



Это сообщение отредактировал(а) kostya1992 - 24.9.2010, 18:20