Символы в строке в сообщении автоматически экранируются

Я отправляю токены через POST-запрос, но когда я вижу их на сервере, они не совпадают с тем, что было отправлено.

"U2FsdGVkX1+pxBHFdSU4NiSIOdR2GCCBr/WF7AOSF5zQjRqjSoTeOKR0Dzwm\nNT+g\n" ‹-- Оригинал "U2FsdGVkX1+pxBHFdSU4NiSIOdR2GCCBr/WF7AOSF5zQjRqjSoTeOKR0Dzwm\\nNT+g\\n" ‹-- Результат

Обратите внимание, что \n был заменен на \\n. Когда я выполняю проверку поиска токена, конечно же, ничего не найдено, потому что строка, которую я ищу, больше не является правильной строкой!

Я не уверен, почему эта строка автоматически изменяется или как это исправить. Я просто получаю доступ к этому через стандартные параметры.

token.verify(params["token"])

РЕДАКТИРОВАТЬ для большей ясности

Я просматриваю это с терминала, используя гем отладчика. У меня включена автооценка и отображается с params["token"] без p или puts. Я не пытаюсь создавать символы новой строки с помощью \n. Литерал \n — это фактическая часть строки, полученной в сообщении. Я случайным образом генерирую токен, используя библиотеку хеширования и шифрования, и строки иногда заканчиваются этими символами. Если я запускаю token.verify(params["token"]) из терминала отладчика, я получаю nil из базы данных, поскольку совпадения нет из-за добавления в строку дополнительных символов обратной косой черты.

Если я запускаю token.verify("U2FsdGVkX1+pxBHFdSU4NiSIOdR2GCCBr/WF7AOSF5zQjRqjSoTeOKR0Dzwm\nNT+g\n") напрямую из терминала отладчика, я получаю правильную запись из базы данных. Это заставляет меня думать, что либо Рэк, либо Синатра автоматически избегают «специальных» символов в строке, прежде чем я смогу даже коснуться ее.


ruby sinatra
person bigtunacan    schedule 09.02.2014    source источник
comment
Токен экранируется, можете ли вы обновить вопрос с кодом, который отправляет запрос post?   -  person fmendez    schedule 09.02.2014
comment
Насколько я могу судить, от него не убегают, отправляя его. В настоящее время я просто использую почтовый запрос через curl для тестирования, поскольку я создаю свой API. curl --data "token=U2FsdGVkX1+pxBHFdSU4NiSIOdR2GCCBr/WF7AOSF5zQjRqjSoTeOKR0Dzwm\nNT+g\n" http://localhost:4567/auth/verify_token   -  person bigtunacan    schedule 09.02.2014
comment
Как вы смотрите на результат? Если вы делаете что-то вроде p params["token"], тогда Ruby будет избегать \, удваивая их при отображении строки, но «настоящая» строка будет состоять только из одиночных символов. Также обратите внимание, что curl будет отправлять \n как литералы, не как символ новой строки, поэтому вам может потребоваться изменить способ использования curl (неясно, имеете ли вы в виду отправку новых строк или литерал \n).   -  person matt    schedule 10.02.2014
comment
Мэтт, я добавил дополнительную информацию выше, чтобы попытаться внести ясность.   -  person bigtunacan    schedule 10.02.2014

Ответы (1)


arrow_upward
0
arrow_downward

Это как-то связано с тем, как Ruby обрабатывает специальные символы. Из irb вы можете увидеть это с помощью такой быстрой проверки.

"\\n" == '\n'

Неожиданно; по крайней мере, для меня это возвращает true, поскольку они обрабатываются одинаково. Вместо того, чтобы пытаться иметь дело со специальными символами, поступающими по сети, я просто кодировал все с помощью base 64.

person bigtunacan    schedule 15.02.2014
comment
В Ruby к строкам в одинарных кавычках не применяются управляющие последовательности. \n — это новая строка, '\n' — это обратная косая черта, за которой следует n, что совпадает с \\n. - person ZiggyTheHamster; 15.12.2015