Кодировка вынесла мозг, спасайте.

Здесь или BOM или одна другая особенность... в общем кинь в личку линк на пагу где проблема

RFC2505 добавил 27.03.2011 в 18:53

угу, сорь, не заметил линку вверху )

в общем, это не БОМ и вообще, всё норм конвертится... возможно, просто ты сам где-то напутал с кодировками уже локально, когда открываешь и сохраняешь скачанную курлом страницу, или же, смотришь сконвертированный файл каким-то редактором, который читает <meta, где явно прописанно, что там UTF-8, вот он и пытается отрендерить твою cp1251 как UTF-8

так же, попробуй:

- вместо windows-125 юзай cp1251 (был там какой-то баг с iconv в какой-то версии кажется)

- так же, в какой-то версии ПЫХа, iconv глучило, если в левой части присваивания использовалась та же переменная, что и в качестве исходной строки (в этом примере этого нет, но хз, как ты тестил ещё у себя локально)

в общем, могу сказать одно - смотри исходные кодировки, в которых открываешь/сохраняешь ттестовый файл... я проверил, у меня всё работает

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

Начал искать "найди отличие в двух практически одинаковых функциях" почему одна работает другая нет.

Косяк оказался до безобразия простой, но коварно спрятался в коде :)

Затесалась после парсинга функция перевода в нижний регистр (strtolower) до конвертации кодировки, в итоге она и портила UTF-8 превращая его в крокозябры.

Банальная невнимательность убила кучу времени.

вот это залет :))

да, не надо так делать с ютф)

Кто подскажет, как победить следующую проблему:

Наткнулся на такую ситуацию, когда вебмастера умудряются внести в контент сайта одновременно символы из кодировки UTF-8 и WINDOWS-1251, страница выдает что она в UTF-8. Так оно и есть, но встречаются фрагменты левой кодировки, при просмотре исходного кода браузером, видно черные ромбики с вопросами.

Парсим такую страницу, определяем ее кодировку и при перекодировании:

$cont=iconv($charset,"windows-1251",$cont);

Соответственно обрезается на первом символе, который не совпадает с исходной кодировкой, лечим пропусканием левых символов:

$cont=iconv($charset,"windows-1251//IGNORE",$cont);

Все бы хорошо, но в более новой версии iconv, которая стоит на хостинге, даже //IGNORE не помогает и все равно половина страницы теряется. Как вылечить? Кикие есть альтернативы? Версия iconv на хостинге 2.6.1

советую посмотреть как устроено utf-8 и регуляркой/автоматом вырезать ненужные символы. иконв даже не придется лечить оО)

Так и не смог решит проблему с iconv, как альтернативу решил использовать mb_convert_encoding, вроде справляется хорошо:

$cont=mb_convert_encoding($cont,"windows-1251",$charset);

Отписываюсь на случай если кто поиском будет искать решение данной проблемы.

Ink-developer, интересное решение :-)

спасибо, может пригодится когда либо)

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

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

Что то вроде этого:

<?php header("Content-Type: text/html; charset=windows-1251");

function charset_convert($text,$charset){

	$text1=mb_convert_encoding($text,"windows-1251",$charset);

	$text2=iconv($charset,"windows-1251//IGNORE",$text);

	if(strlen($text1)>strlen($text2)){ return $text1; }else{ return $text2; }

}

$text=charset_convert("текст в utf-8","utf-8");

?>

я бы уже перехал на другой сервер, где правильно работает iconv//ignore, вам так не кажется логичным? 🤣

времени бы сэкономилось ух)

Не вариант, у меня хостинг проверенный годами. Вообще там ВДС, так что по идее самому можно нормальную версию iconv установить, но опять надо разбираться что да как. Как ее вообще найти где она на серваке эта dll лежит, я вчера не смог ее найти.