Проблемы с отображением абзацев при извлечении текста из базы данных

Question

У меня проблемы с отображением фрагментов текста с абзацами из базы данных.

Например, если я передам строку типа:

local lotsOfText = "Lorem ipsum dolor sit amet, consectetur adipiscing elit.\n\nNunc euismod justo sapien, at sollicitudin lacus. Quisque vestibulum commodo felis id posuere."

Затем \ n \ n создает разрыв текста в абзаце, чего я и ожидал.

Однако, если я получу из базы данных точно такую ​​же строку, как указано выше, например:

local lotsOfText = row.Info

Затем на экране отображаются \ n \ n, а не разрыв абзаца.

Любая помощь будет принята с благодарностью!

---

Спасибо всем за их идеи и предложения. Основываясь на том, что сказал BMitch, я попробовал другой подход и считаю, что это на самом деле проблема с моей базой данных, а не с Lua или самой строкой.

Если я создаю таблицу БД в коде и вставляю строку, я могу их правильно извлечь. Я думаю, это связано с тем, какой тип данных я использовал, или, может быть, это связано с тем, как я редактирую данные в Lita.

Answer 1

Экраны обрабатываются только в строковом литерале, заключенном в одинарные или двойные кавычки.

Проблема заключается в том, что ваша база данных хранит '\ n' вместо фактического сохранения разрыва абзаца.

Если вы не можете исправить базу данных, вы можете обработать ее позже с помощью умного gsub:

mystring = string.gsub(mystring,[[\(%a)]],{n="\n",r="\r",t="\t"})

Answer 2

У меня была почти та же проблема, когда я писал скрипт на короткую сборку на Python.Проблема оказалась в том, что Python обрабатывал строковый результат, возвращаемый из вызова процесса, как двоичный.Я думаю, что Луа делает то же самое.Хотя я никогда не сталкивался с этим лично и не смог найти прямого решения через Google, кто-то еще упомянул библиотеку lpack для упаковки и распаковки двоичных данных в этом ответе .Кроме того, функции string.dump и loadstring могут указать вам на решение, если lpack не сделает то, что вы ищете, но я думаю, что ключевым моментом является поиск существующего пути (илиписать свои собственные), чтобы интерпретировать «двоичные» данные как символы.