М... в смысле?
В одну строку весь файл? Нет, не сольет.
Или в одну строку сольет текст который был с переносами? Ну так это же и есть "удалить переносы".
Сергей Алпеев: ну можно регулярками попробовать разобрать.
Суть такая - текст с переносами строки экранируется кавычками обычными двойными. Если внутри текста есть кавычки, они заменяются двумя кавычками подряд. Вот на это и ориентируйтесь.
В Либре просто - открываем csv. Жмем Ctrl+H. Другие параметры - ставим галку Регулярные выражения.
В поле найти пишем "\n" (без кfвычек, в смысле обратный слэш и английская n), в поле "Заменить на" ставим пробел (ну чтобы переносы строк заменялись на пробел), жмем "Заменить все" и сохраняем как csv.
Черт, я почему-то подумал, что у вас есть файл и надо импортировать его в битрикс убрав переносы строк. Теперь понятно.
> в csv должно быть так , одна строка , один объект
неправильно
Тогда путь другой - берем выгруженный csv из битрикса, открываем его в программе которая умеет правильно обрабатывать csv с экранированным текстом (например LibreOffice), заменяем переносы строк в ней, скармливаем "другой системе".
Еще один вариант (если "другая система" - коммерческий продукт) - пишем в их техgоддержку и требуем нормальной поддержки csv.
Алексей Емельянов: Почему не удастся если это сунуть в фильтр - отлично будет работать.
Только был какой-то способ проще и без подзапроса. Пару дней назад наткнулся на такой же вопрос в другом месте и вспоминал-вспоминал - не вспомнил. А способ был...
Aleks305: а черт его знает. Зависит от того с какой частотой вы обновляте данные. Если у вас допустим 1С выгружает каталог каждые 15 минут, то 1 час это много - три четверти апдейтов пролетит мимо. А если это случается раз в неделю, то можете и поставить неделю, только сбрасывать кэш руками после внесения изменений.
Продолжительность кэширования должна быть такой на сколько вы готовы чтобы запаздывали новые данные в своем появлении на сайте.
Я думаю, что за рубежом фрилансить можно будет без гемора. Ну, а у нас без гемора уже давно даже умереть нельзя...
А если серьёзно, то, не претендуя на ответ, думаю что все будет можно. Конечно будет какой-то мизирный шанс попасть под показательную порку, но закон явно вводится не для этого, тут цель очевидна - повысить лояльность окружения и крепче повязать его. Укрепить вертикаль перед лицом превращения ее в осиновый кол, так сказать.
uaSaint: вконтактик работает на PHP и это ему никак не мешает. Так что дело не в скриптах видимо. Быструю обработку сейчас может обеспечить все что угодно. Даже java. Тут требования больше к тому что может выдержать база и насколько решение масштабируемо. А это уже никак не зависит от того на чем оно сделано.
Ошибка-то не в этой строчке.
<? - вот это что у вас в шестой строчке значит? Это не может быть открытие открытие блока PHP потому что он открыт уже открыт в 4. Ошибка.
uaSaint: Нет. Я с ним не работаю. Дело-то не в том чтобы посмотреть, а в том чтобы сделать. Нагрузочная прочность на 99% зависит от правильно спроектированной архитектуры, а нет от используемых решений.
FanatPHP: да - так.
Причем еще можно соль добавлять к паролю перед шифрованием. Соль генерить на клиенте. Если она будет фиксированной длины, то от дешифрованной строки на сервере ее можно будет отрезать. Ваще круть.
1) Ну да, логично. Я дурак. Можно передавать.
2) Нет, не в обратимом. Мы шифруем не пароль, а хэш. Он не обратим по определению. Но да - предвычесленные таблицы сделают нам больно - согласен.
На дерибасовскую же мы не выходим. Тут вы ошиблись - мы же не передаем хэш!
А чо либру-то искать - ru.libreoffice.org