Специальные символы в одинарных и двойных кавычках

Я извлекаю поле из базы данных, содержащей документ в формате rtf.

Например, это может выглядеть так:

{\rtf1\ansi\ansicpg1252\deff0\deflang1031{\fonttbl{\f0\fnil\fcharset0 Calibri;}} {*\generator Msftedit 5.41.21.2509;}\viewkind4\uc1\pard\sa200\sl276\slmult1\lang7\f0\fs22 asdfasdf\par a\par sf\par asd\par fasd\par \b dfas\b0\par dfas\par }

Теперь PHP извлекает это как двойные кавычки из базы данных, в результате чего строка не будет интерпретироваться по символам... предполагается, что были распознаны специальные символы, такие как '\ r' и '\ n'.

Как я могу преобразовать эту двойную кавычку в строку с одинарной кавычкой, чтобы получить все необработанные символы? Или как я могу добиться, чтобы значение присваивалось как одинарные кавычки, когда я извлекаю его из базы данных?

заранее спасибо

-ральф


php string rtf converter
person rgn    schedule 15.09.2010    source источник
comment
Нет такой вещи, как выборка в двойных кавычках. Что вы имеете в виду под необработанными символами? В чем именно ваша проблема? Одиночные и двойные кавычки имеют значение только для строковых литералов.   -  person Raoul Duke    schedule 15.09.2010

Ответы (2)


arrow_upward
1
arrow_downward

Теперь PHP извлекает это как двойные кавычки из базы данных.

Какая? Результатом mysql_fetch_row или чего-то еще является просто строка. Ничто не переосмысливается никоим образом. \n остается \n. Только строковые литералы, которые вы записываете в PHP-файл в двойные кавычки, будут "интерпретированы" и затем сохранены как строки.

Нет ничего лучше строки в одинарных или двойных кавычках. В исходном коде PHP есть только строковые литералы в одинарных или двойных кавычках, из которых будут созданы фактические строки PHP.

Единственная проблема, которая у вас есть сейчас, это как обработать/разобрать данные RTF< /а>. (Предполагая, что данные были сохранены в столбце больших двоичных объектов, поэтому нет никаких сложностей с кодировками символов.)

person Messa    schedule 15.09.2010
comment
RTF хранится в поле Blob в базе данных MSSQL. Я извлекаю строки через mssql_fetch_assoc... И когда он печатается, все вхождения \r или \n интерпретируются как эти... не как простые символы... - person rgn; 15.09.2010
comment
Вы имеете в виду, что хотите печатать \r/\n без интерпретации как специальные символы? - person Pherrymason; 15.09.2010
comment
да. если вы посмотрите на начало исходной строки, она должна выглядеть так: {\rtf1... в шестнадцатеричном формате => 0x7b 0x5c 0x72 0x74 0x66, но в строке, удерживаемой php, она выглядит в шестнадцатеричном виде так => 0x7b 0xd7 0x46 0x63 0x15 - person rgn; 15.09.2010
comment
хорошо, спасибо за помощь, похоже, проблема была вызвана моим тестовым примером... я получаю правильную строку из своей базы данных. но у моего сериализатора супа проблемы со специальными символами... моя вина. - person rgn; 15.09.2010

arrow_upward
1
arrow_downward

Прежде всего, вы должны потратить некоторое время на то, кто (или что) ускользает от вашего кода.

Но для быстрого решения попробуйте использовать функцию stripslashes():

$unsecaped = stripslashes( $database_data );

Но я призываю вас попытаться найти то, что ускользает от данных. Это может произойти:

  • Перед вставкой данных в базу данных. Обычно это вызывается директивой PHP magic_quotes_gpc.
  • При получении данных из базы данных.

Обновлено

Я не понял вашей проблемы... Вы хотите сохранить все эти обратные косые черты, но избежать того, чтобы \r и \n интерпретировались как возврат каретки и перевод строки...

Попробуйте выполнить str_replace, чтобы найти все эти \r и \n и заменить их на \r и \n.

Я не знаю, может ли \r принадлежать любому мудрому символу, поэтому, возможно, вам следует заменить только " \r "/" \n ", возможно, для этого вам понадобится preg_replace().

person Pherrymason    schedule 15.09.2010
comment
Stripsplashes не поможет, потому что я хотел бы преобразовать этот текст RTF в обычный текст. Таким образом, ключевые слова, такие как \rtf1 или \ansi, должны сохраняться для синтаксического анализатора. - person rgn; 15.09.2010