|
|
|
| Есть таблица:
id int(11)
date datetime
text text
type int(1)
pub int(1)
|
И если я пишу в поля `type` или `pub` цифру 2 или скажем 3, то они записываются. А если вдруг единицу пишу, то в них пишется 0.
Запрос выглядит так:
update `ru_news` set `date` = '2010-02-08 11:24:03', `text` = '11111111', `type` = '1', `pub` = '1' where `id` = 21
|
Подскажите, где я не прав?
upd
Запостил сообщение - и всплыли какие-то непечатные символы возле единицы. убрал их - заработало. Это из-за юникода оказалось, единичка-то из файла берется.
upd
Решение: если $t - первая строка, считанная из файла в кодировке UTF-8, то чистить можно так:
$t=trim($t,"\xEF \xBB \xBF");
|
| |
|
|
|
|
|
|
|
для: DJ Paltus
(09.02.2010 в 11:30)
| | Потому как сомнительный запрос стоит печатать.
И проверять в phpMyAdmin.
Иногда даже в шестнадцатеричном виде.
Что справились сами - хорошо.
хотя trim - страшен. | |
|
|
|
|
|
|
|
для: Trianon
(09.02.2010 в 15:57)
| | Чем он страшен? | |
|
|
|
|
|
|
|
для: mihdan
(09.02.2010 в 16:33)
| | тем , что режет байты независимо. А не BOM в целом. | |
|
|
|
|
|
|
|
для: Trianon
(09.02.2010 в 15:57)
| | А я все это делал. И выводил, и в майадмине проверял, но эти символы вывелись лишь тут, в форуме в виде ascii-кодов. И только тогда я догадался тектсовик в 16ричном глянуть.
Насчет ужасного trim, не думаю, что это существенно - его использование сугубо казуально. Есть еще вариант юникодные текстовики создавать без этих управляющих символов, некоторые редакторы (акелпад, например) позволяют это делать. Либо лепить текстовики в нормальной кодировке, а при выводе конвертировать строки. | |
|
|
|
|
|
|
|
для: DJ Paltus
(10.02.2010 в 12:36)
| | >Насчет ужасного trim, не думаю,
Вот знаете, нисколько не сомневался в ответе. | |
|
|
|
|
|
|
|
для: Trianon
(10.02.2010 в 21:57)
| | Ну а что Вы бы предложили? Резать просто по str_replace? | |
|
|
|
|
|
|
|
для: DJ Paltus
(10.02.2010 в 12:36)
| | > Насчет ужасного trim, не думаю, что это существенно
Скажи честно: ты не знаешь функции substr()? | |
|
|
|