Warning: Cannot use a scalar value as an array in /home/admin/public_html/forum/include/fm.class.php on line 757
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/include/fm.class.php on line 770
Warning: Invalid argument supplied for foreach() in /home/admin/public_html/forum/topic.php on line 737 Форумы портала PHP.SU :: Парсинг xls с преобразованием русских символов функцией preg_replace()
Покинул форум
Сообщений всего: 55
Дата рег-ции: Дек. 2011
Помог: 2 раз(а)
Входные данные:
- Есть XLS файлы с русскими и английскими словами.
- Парсинг идет скриптом Excel Parser Pro.
- Обрабатывается все построчно.
- Значения ячеек в строке заносятся в соответствующие переменные.
- Кодировка полученных значений - ASCII
- Далее над содержимым переменных выполняется преобразование вида:
Суть проблемы:
в результате преобразований получаем следующее
начальное значение - П-40/1100Э
после преобразований получаю - 105545524847494948481069
ожидаемый результат - п401100э
с значениями переменных на английском языке проблем нет.
Уже перечитал, пересмотрел горы статей и справочников, чувствую что ответ рядом но докопаться до него не могу.
Подскажите в чем может быть проблема и как правильно надо работать с кириллическими символами в таком вот случаи?
Мелкий
Отправлено: 20 Июня, 2012 - 15:12:10
Активный участник
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
0) в ASCII кириллицы не существует. Уточните кодировку
1) mb_internal_encoding, возможно, неверно указана
----- PostgreSQL DBA
sheff2000
Отправлено: 20 Июня, 2012 - 15:31:18
Новичок
Покинул форум
Сообщений всего: 55
Дата рег-ции: Дек. 2011
Помог: 2 раз(а)
Мелкий пишет:
0) в ASCII кириллицы не существует. Уточните кодировку
1) mb_internal_encoding, возможно, неверно указана
действительно, показывает - ISO-8859-1
поставил в начале крипта строку mb_internal_encoding("UTF-8"); - ничего не изменилось, кодировку обрабатываемых слов все также пишем как ASCII, все те же цифры в результатах
fdr21
Отправлено: 20 Июня, 2012 - 15:49:20
Гость
Покинул форум
Сообщений всего: 86
Дата рег-ции: Июнь 2012
желательно что бы скрипт тоже был написан на UTF-8
sheff2000
Отправлено: 20 Июня, 2012 - 16:03:14
Новичок
Покинул форум
Сообщений всего: 55
Дата рег-ции: Дек. 2011
Помог: 2 раз(а)
fdr21 пишет:
Попробуйте для начало преобразовать символы:
желательно что бы скрипт тоже был написан на UTF-8
все файлы скриптов в UTF-8
пробовал преобразовывать - в результате получаю вообще пустое значение, для латиницы все нормально.
какойто полтергейст. и такая проблема только при обработке xls, xml (utf-8) и просто выборка из базы данных с таким же механизмом обработки строк работает отлично с любыми символами.
UPD. проверил "пустое" значение функцией mb_strlen() - есть значения
Покинул форум
Сообщений всего: 55
Дата рег-ции: Дек. 2011
Помог: 2 раз(а)
Мелкий пишет:
Всё равно у меня подозрения, что mb_strtolower портит строку.
если к строке применить только ее - то с кириллическими строками ничего вообще не происходит, регистр символов в латинских строках изменяется как надо.
именно применение preg_replace (str_replace() тоже ) приводит к указанному в теме результату.
Мелкий пишет:
sheff2000 пишет:
но вот проверяю кодировку функцией:
Может безбожно врать. Или, как в вашем случае, определять не всё. ASCII ведь полностью входит в UTF8 (и ещё большую кучу кодировок).
UPD.
Кажется нашел примерную причину "ошибок" и почему кодировка как ASCII определяется. В коде парсера при вытягивании значений из файла идет посимвольное преобразование функцией ord() - похоже от сюда и кодировка... но почему на до preg_replace() все правильно выводится - непонятно (Добавление)
Покинул форум
Сообщений всего: 11926
Дата рег-ции: Июль 2009 Откуда: Россия, Санкт-Петербург
Помог: 618 раз(а)
sheff2000 пишет:
но почему на до preg_replace() все правильно выводится - непонятно
Потому что бинарный поток сохраняется корректным. По сети браузеру-то идут байты, а не символы. Вот нормально и склеиваются.
Этот парсер умеет выдавать данные в каком-нибудь cp1251? Тогда можно через iconv нормально скормить данные. Хотя идеологически правильнее будет поправить сам парсер.
----- PostgreSQL DBA
fdr21
Отправлено: 20 Июня, 2012 - 18:59:31
Гость
Покинул форум
Сообщений всего: 86
Дата рег-ции: Июнь 2012
спасибо за совет, но тоже не поможет уже пробовал эту и множество других комбинаций и функций преобразования кодировки
Мелкий пишет:
Потому что бинарный поток сохраняется корректным. По сети браузеру-то идут байты, а не символы
как то не задумывался про "физику" этого процесса, по всей видимости Вы правы - это многое сразу же объясняет..
Мелкий пишет:
Этот парсер умеет выдавать данные в каком-нибудь cp1251?
порылся, на сколько мог его понять, в коде - нет, там все идет через функции ord() ...
появилась "гениальная" идея - раз потоком идет все верно, то завернуть этот поток в xml файл, а длаее уже спокойно парсить полученный xml
ну или другой вариант, наверное самый правильный, писать свой парсер xls
Спасибо Вам за помощь. Тема еще открыта - если есть идеи/предложения буду рад их прочесть.
sheff2000
Отправлено: 21 Июня, 2012 - 09:53:31
Новичок
Покинул форум
Сообщений всего: 55
Дата рег-ции: Дек. 2011
Помог: 2 раз(а)
Проблему решил - тему можно закрывать.
Кому интересно:
Excel Parser Pro - отличный парсер xls файлов, но в процессе парсинга все символы с файла преобразовываются в HTML сущности. С латинскими буквами и цифрами пробел не возникает, но если есть кириллица - то дальнейшая обработка строк будет невозможна.
Решение.
Оказалось очень простым.
При вытягивании из xls значения ячейки надо всего навсего выполнить следующее преобразование:
Все гости форума могут просматривать этот раздел. Только зарегистрированные пользователи могут создавать новые темы в этом разделе. Только зарегистрированные пользователи могут отвечать на сообщения в этом разделе.