Имеем текстовый файл с одной строкой.
Задача: запихнуть его содержимое в БД.
Открываем файл, читаем, запихиваем в базу. НО, в результате в базе оказывается не одна строка, а две (вторая пуская). В исходном файле перехода на новую строку нет. Так всего одно.
Вопрос: откуда берется вторая и как от нее отделаться?
Спустя 34 минуты, 9 секунд (22.08.2011 - 17:48) inpost написал(а):
Покажи содержание файла. Покажи код, как добавляешь. Не забудь оформить [ php] тегом
Выведи данные через echo, покажи, каков результат через ИСХОДНЫЙ КОД СТРАНИЦЫ, какие там символы выводятся.
Ещё в ФФ запусти HTML-инспектор, и посмотри что там.
При добавлении в БД используй mysql_real_escape_string, убирай пробелы через trim.
Выведи данные через echo, покажи, каков результат через ИСХОДНЫЙ КОД СТРАНИЦЫ, какие там символы выводятся.
Ещё в ФФ запусти HTML-инспектор, и посмотри что там.
При добавлении в БД используй mysql_real_escape_string, убирай пробелы через trim.
Спустя 13 минут, 39 секунд (22.08.2011 - 18:01) Гость_Mark написал(а):
Содержание файла простое: последовательность цифр и букв (например: 56G или 12М). Такого типа.
echo выводит одну строку: 56G или 12M, без перехода на новую строку. В исходном коде отображается как надо (тоесть без пустой строки).
Зачем при добавлении убирать пробелы? Они там нужны...
Читаем:
Запихиваем:
При выводе записанного пустой строки нету. Но при просмотре таблицы через phpmyadmin - есть. Может ли быть, что мускул впихивает эту пустую строку когда доходит до eof?
echo выводит одну строку: 56G или 12M, без перехода на новую строку. В исходном коде отображается как надо (тоесть без пустой строки).
Зачем при добавлении убирать пробелы? Они там нужны...
Читаем:
$file_hdd_media=fopen ("$path_data/hdd_media", 'r');
$stat_hdd_media=fgets($file_hdd_media, 128);
fclose($file_hdd_media);
Запихиваем:
$query = "INSERT INTO stat (stat_hdd_media) VALUES ('$stat_hdd_media')";
При выводе записанного пустой строки нету. Но при просмотре таблицы через phpmyadmin - есть. Может ли быть, что мускул впихивает эту пустую строку когда доходит до eof?
Спустя 7 минут, 50 секунд (22.08.2011 - 18:09) Гость_Mark написал(а):
Нет, вру. В исходнике html эта пустая строка тоже есть.
Спустя 6 минут, 40 секунд (22.08.2011 - 18:16) inpost написал(а):
Гость_Mark
Покажи, как выглядит.
Почему не применил те функции, которые я тебе показал?
Ты покажи, как выглядит исходный код хтмл, строка в начале или в конце. Открой через ФФ HTML инспектор в FireBug: http://my.jetscreenshot.com/demo/20110822-zvsm-93kb
Покажи, как выглядит.
Почему не применил те функции, которые я тебе показал?
Ты покажи, как выглядит исходный код хтмл, строка в начале или в конце. Открой через ФФ HTML инспектор в FireBug: http://my.jetscreenshot.com/demo/20110822-zvsm-93kb
Спустя 17 минут, 51 секунда (22.08.2011 - 18:34) Гость_Mark написал(а):
Ну так mysql_real_escape_string ведь вроде экранирует сомнительные символы. Так что он тут думаю не помошник.
Про trim не знал. Хорошая штука. Вот он та меня и спас:
По ходу был в конце строки какой-то управляющий символ.
Спасибо.
Про trim не знал. Хорошая штука. Вот он та меня и спас:
trim($stat_hdd_media, "\x00..\x1F");
По ходу был в конце строки какой-то управляющий символ.
Спасибо.
Спустя 2 минуты, 52 секунды (22.08.2011 - 18:36) inpost написал(а):
ты уверен, что в конце, а не в начале? Если в начале, значит у тебя сохранен UTF with BOM, а надо without BOM.
Спустя 47 минут, 40 секунд (22.08.2011 - 19:24) Гость_Mark написал(а):
Да, уверен что в конце. Ибо выдавало:
12G
[пустая строка]
А не:
[пустая строка]
12G
Так что именно в конце.
12G
[пустая строка]
А не:
[пустая строка]
12G
Так что именно в конце.