Почему классический ASP публикует список множественного выбора с пробелом между значениями, а ASP.Net — нет?

У меня есть старый классический код ASP, такой как:

<html>
<head></head>
<body>
<form action="test.asp" method="post" name="fname">
<select name="clients" size="3" multiple="multiple">
       <option value="5311" selected="selected">5311</option>
       <option value="9999" selected="selected">9999</option>
</select>
<input type="submit" value="test">
</form>
<%
dim clients
clients=Request.Form("clients")
Response.Write(clients)
%>
</body>
</html>

Это выводит 5311, 9999 из объекта Request.Form.

Если я добавлю тот же HTML-код в приложение ASP.Net и прочитаю объект Request.Form, он выведет 5311 9999.

Найди разницу, между ними есть пространство.

Это почему? Есть ли способ изменить его, чтобы он включал пробел?

Спасибо


forms html asp.net asp-classic html-select
person Jon    schedule 09.10.2009    source источник
comment
ну, пробел и недостающая 9 ;)   -  person UpTheCreek    schedule 09.10.2009
comment
Просто интересно - зачем тебе это место? Похоже, классический асп только что сделал что-то плохое...   -  person UpTheCreek    schedule 09.10.2009
comment
Это была опечатка, мне нужно место в приложении, чтобы создать оператор SQL, такой как IN('5311', '9999')   -  person Jon    schedule 09.10.2009

Ответы (3)


arrow_upward
2
arrow_downward

Классический ASP изменился. Примерно в Windows Server 2008, вероятно, позже из-за патча или пакета обновления, он начал ставить между элементами.

То же самое он делает с массивами полей. Если у вас есть 3 поля ввода с именем "AMOUNT", response.write(request.amount) будет отображать aaa, bbb, ccc

Я работаю с классическим ASP около 12 лет, и это начало происходить некоторое время назад и ломать вещи.

Я никогда не видел, чтобы это было задокументировано.

Примечание. Я могу найти старую документацию Microsoft, в которой конкретно говорится о «строке с разделителями-запятыми».

person SWobmat    schedule 18.03.2011

arrow_upward
0
arrow_downward

Похоже, вы могли бы сделать замену, чтобы создать часть допустимого оператора SQL. Если это то, что вы делаете, это действительно очень плохая идея, поскольку злой посетитель может использовать это для запуска любых операторов SQL, которые им нравятся. Лучшая идея, как для классического ASP, так и для ASP.net, состоит в том, чтобы разделить запятую и использовать CLng или Convert.ParseInt32 для преобразования в число и построить оператор SQL, используя это.

person svinto    schedule 09.10.2009

arrow_upward
0
arrow_downward

Я никогда не замечал разницы в том, как в этом отношении работает Classic ASP и ASP.NET, но наличие или отсутствие пробела не должно влиять на предложение IN. Если вы в настоящее время просто добавляете значение Request.Form в динамически сконструированный оператор SQL, вы потенциально создаете проблемы, как было указано. Вы должны параметризовать его:

http://www.mikesdotnetting.com/Article/116/Parameterized-IN-clauses-with-ADO.NET-and-LINQ

person Mike Brind    schedule 09.10.2009