Както други посочиха, #2 е правилният отговор. Оставете го "суров", докато не ви потрябва, след което избягайте по подходящ начин.
За да уточним защо (и аз ще повторя/обобщим другите публикации), нека вземем сценарий 1 до неговата логична крайност.
Какво се случва, когато някой въведе " ' OR 1=1 <other SQL injection> -- ". Сега може би решите, че тъй като използвате SQL, трябва да кодирате за SQL (може би защото не сте използвали параметризирани изрази). Така че сега трябва да смесите (или да решите) SQL и HTML кодиране.
Изведнъж вашият шеф решава, че иска и XML изход. Сега, за да поддържате шаблона си последователен, трябва да кодирате и това.
Следващ CSV - о, не! Ами ако в текста има кавички и запетаи? Още бягство!
Хей - какво ще кажете за хубав интерактивен AJAX интерфейс? Сега вероятно искате да започнете да изпращате JSON обратно към браузъра, така че сега {, [ и т.н. трябва да бъдат взети под внимание. ПОМОЩ!!
Така че ясно, съхранявайте данните, както са дадени (разбира се, предмет на ограничения на домейна) и кодирайте подходящо за вашия изход в момента, в който се нуждаете от него . Изходът ви не е същият като данните ви.
Надявам се този отговор да не е твърде покровителствен. Заслуга на другите респонденти.
