Нет, тоже самое...
В общем ладно, решил свою проблему поиском нужного блока регулярным выражением, оно работает замечательно в данном простом случает. Возможно какой-то баг DOMDocument или же я не полностью разобрался в его настройке...
отображает нормально страницу, она в юникоде, получается, то, что парсер HTML преобразует этот юникод в нечто непонятное, которое обратно не преобразуется... (Добавление)
Плюнул на гордость и сделал файл в кодировке Windows-1251, поменял в хидере тип кодировки, однако после применения xPath получается всё равно кривая строка:
Цитата:
Ïåðåïèñêà â ãðóïïå êëà ГГ WoT.
Наверное дело в самом domDocument, который использует где-то внутри настройки юникода, а получает Windows-1251 и ошибается...
Пытаюсь распарсить страничку bash.im, сайт в кодировке Windows-1251, сам скрипт в кодировке UTF-8. При простом выводе строки текста на экран получаю получаю:
Декодер Лебедева на первую строку говорит, что для читабельности преобразовал CP1252 → CP1251? что у меня также не особо заработало...
Подскажите, как правильно провести конвертацию кодировки в данном случае? Пример кода под спойлером:
У меня в базе хранится много текста и полученная выборка нередко весит 1-2 мегабайта, я подумал, что было бы не плохо сделать кэширование таких запросов в файлы и вытягивать из них вместо базы.
Вопрос: будет ли чтение файлов реально быстрее? Как лучше сделать такое кэширование?
Так, с помощью какой регулярки можно разделить по буквам строку так?
Потом есть небольшая проблема, я хотел использовать разделение строки на массив, чтобы затем выполнить функцию вычисления расхождения массивов, т.е. чтобы слово состояло только из нужных мне букв, а других не было (array_diff), но при сравнении элементов используется === и двухбайтовая буква не будет равна однобайтовой...
Загружаю через simplexml большой файл в UTF-8, но при попытке разбить часть строк на символы функцией str_split наблюдаю, что буквы разделяется на 2 и уже не читаются нормально, как сделать, чтобы буква читалась как один элемент массива, а не делилась на 2?
да не должно бы вообще. Может, у вас в скрипте стоит переадресация?
Это просто html странички, никакой динамики, насчёт возможных переадресаций это моё мнение, хром просто выдаёт ошибки про кучу редириктов, в консоли отладки видно, что при запросе /news идёт 301 редирикт на /news и так до бесконечности...
Почему то активируется правило перенаправления для адреса news.html... Я считаю это как раз из-за того, что /news берёт содержимое из news.html...
Кстати, а что значит \.p? и зачем оно надо? первые 2 символа это экранированная точка, последний любой символ, а что значит p?
Единственное, при запросе /news хочет показать /news.html, что в свою очередь перенаправляется на /news и получается циклические переадресации и [L] почему то не спасает...
В крайнем случае конечно можно написать скрипт, но это лишняя нагрузка на его интерпретацию и выполнение...