问题描述
密码输入框能输入N个空格，同时也能登录这个算错误吗？
解决方案
解决方案二：
其实我们都不允许密码输入时带空格的，都要求只包含：字母、数字、下划线。
解决方案三：
没问题吧加密的时候又不会出错，只是要注意防注入
解决方案四：
这要看客户的要求了，不过个人认为不妥，几乎没见过能让密码里面含空格的。输入的时候就应该检测是否含有空格，然后把它删掉，使空格输入没有响应。
解决方案五：
这种东西常规来讲是不对的，但如果业务就是要这样你也不能说错，毕竟业务最大
解决方案六：
可以，只要客户愿意，不过我想一般的客户都不会有这种要求。
解决方案七：
看使用场景、客户需求比如，银行卡密码只能是6位数字一般很少允许空格作为密码字符的
解决方案八：
不算错误，但不严密
解决方案九：
password其实应该叫通行口令。其实应该是一个句子，所以有空格是可以得。
解决方案十：
这个要看客户的需求了，没有什么对不对的
解决方案十一：
通常是只允许数字,字母和下划线银行就只允许数字但是QQ就允许输入各种标点符号啊,空格也可以的看需求呗
解决方案十二：
引用4楼starfd的回复:
这种东西常规来讲是不对的，但如果业务就是要这样你也不能说错，毕竟业务最大
是的，这又不是算术题，哪来的对错
解决方案十三：
其实我见过的很多不让输入空格的程序,后台数据库字段都是用的char或者varchar这种字段类型会补齐空格比如设置了字段类型是char(16)用户明明输入的密码是123但是数据库里存的是123+13个空格为了在登陆时匹配用户名密码,程序里就必须做去空格处理这样一来就根本不可能将空格作为密码了,因为根本区分不出来空格到底是自动补齐的,还是用户录入的其实数据库字段用nvarchar2就好了嘛
解决方案十四：
或者数据库里不要存明文而是存MD5散列后的密文这样不管输入的字符串是多少位,最后散列后的密文固定是32位就也不存在不允许这个不允许那个的问题了
解决方案十五：
只有银行是特殊的,不是因为软件技术上的问题,而是银行窗口和提款机上输入密码的键盘就只有数字为了统一,只能让你在网页登陆的时候也只能输入数字
解决方案：
为毛不能用空格，空格也是一个字符，我的密码就使用了空格。除非有很特殊的原因，否则不应该剥夺用户使用空格的权利。
解决方案：
引用楼主poost1的回复:
密码输入框能输入N个空格，同时也能登录这个算错误吗？
重新再读楼主的问题感觉好像是说,我的密码本来设置的是123但是输入了123之后,也能正常登陆??那当然是错误还请楼主说清楚问题
解决方案：
除非是不需要密码，否则是错误的。
解决方案：
应该算错。不过，为了防止用户按错或者默认有空格。可以用textBox1.Text.Trim();清空空格
解决方案：
解决方案：
为毛让别人输入空格，万一用户不记得输入的密码哪里有空格了咋办，该限制就就得限制，免得以后麻烦。
解决方案：
个人觉得，还是应该看客户需求。。。程序来说没问题，只是不严谨
解决方案：
算错误的，肯定是你判断密码的地方有误，密码必须严格等于，跟你空格没关系，除非你是空密码，并且取出页面密码值时用了TRIM()，这样才是可以登录。
解决方案：
这种不算是什么错误，但是不建议用这种，不安全
解决方案：
可以用，但是存在问题
解决方案：
引用16楼Z65443344的回复:
Quote: 引用楼主poost1的回复:
密码输入框能输入N个空格，同时也能登录这个算错误吗？重新再读楼主的问题感觉好像是说,我的密码本来设置的是123但是输入了123之后,也能正常登陆??那当然是错误还请楼主说清楚问题
题主好像就是这个意思。这样肯定算错误啊....
解决方案：
引用16楼Z65443344的回复:
Quote: 引用楼主poost1的回复:
密码输入框能输入N个空格，同时也能登录这个算错误吗？重新再读楼主的问题感觉好像是说,我的密码本来设置的是123但是输入了123之后,也能正常登陆??那当然是错误还请楼主说清楚问题
好像有的例子会把用户名密码trim下避免什么前后空格之类的,结果有空格也正常登陆了吧,我觉得不好说算不算错误,毕竟是要在正确密码基础之上才能登陆,对于安全性影响似乎也没那么大?
解决方案：
引用26楼zeratul1990的回复:
好像有的例子会把用户名密码trim下避免什么前后空格之类的,结果有空格也正常登陆了吧,我觉得不好说算不算错误,毕竟是要在正确密码基础之上才能登陆,对于安全性影响似乎也没那么大?
简单粗暴的trim一下确实能解决很多问题,但是同样会产生很多问题就会给用户造成错觉,以为允许输入空格.但是岂不知输入的空格其实全部都是无效的正确的做法应该是判断输入的是空格,就直接不显示空格,而不是让空格也占个位置
解决方案：
说白了就是让用户"无法输入空格"而不是等用户高高兴兴的输入了一大堆文字之后,才告诉用户"您输入的字符串非法"
解决方案：
引用27楼Z65443344的回复:
简单粗暴的trim一下确实能解决很多问题,但是同样会产生很多问题就会给用户造成错觉,以为允许输入空格.但是岂不知输入的空格其实全部都是无效的正确的做法应该是判断输入的是空格,就直接不显示空格,而不是让空格也占个位置
确实,不过明文内容到还好,密码这种,就算我们做了按了空格没显示,估计用户也不会太注意到空格被和谐了,可能还是即时判断下内容出提示比较合适话说正则式真是不好搜啊,网上一搜一大片,能用的没几个...
解决方案：
引用29楼zeratul1990的回复:
话说正则式真是不好搜啊,网上一搜一大片,能用的没几个...
如果不会用正则,那么就用你自己最擅长的方法去判断,不非要用自己不熟悉的写法.出了问题还不好调试.
解决方案：
逻辑上不错，但是需求上说不通啊，谁会允许空白字符串作为密码呢......
解决方案：
如果客户愿意，我们也就只能呵呵！
解决方案：
搞测试人的如果不去理解普通用户（哪怕是小时、工钟点、出租车司机）的习惯和认识，而用一个把学生的习惯去替代实际用户习惯，那就肯定是不行的。
解决方案：
最好不要有空格，特别是尾巴后面的空格，有的时候尾巴后面的空格是客户不小心输进去的，而且客户也不知道，然后他们就会找你，“唉哎，我的密码怎么登陆不了了。”
解决方案：
客户想怎么我们就怎样干
解决方案：
一般来讲密码都会去掉空格的
解决方案：
原则上是不算错误的，可以允许输入的，经过加密处理后，只要登录的时候能匹配过去就OK了！
解决方案：
没有规则，就没有对错
解决方案：
看客户需求吧。如果你设计的密码不允许输入空格，可以在输入时正则检查，如果有空格，弹出提示，让客户重设
解决方案：
个人感觉还是不要这样的好
解决方案：
看需求。什么需求对应什么设计，很正常的
解决方案：
我感觉支持空格的密码不好判断
解决方案：
看客户的意思了。客户不懂你就做主。
解决方案：
是的，是错误的。
解决方案：
引用35楼u013489804的回复:
客户想怎么我们就怎样干
客户不会去想这么多，这其实都是程序员在那里内耗。比如说如果某个用户在密码的最后多了一个空格，那么程序自动给人家trim()又什么不可以呢？是把程序员累坏了、还是给客户造成半点误会了呢？
解决方案：
实际上这还不用考虑是非问题，许多事情你仔细看，往往都还没有到那个互相争吵的份上！有的东西就按照现在的设计来测试，而超过Design阶段的未来的功能需要在6个月后才去纠结的，为什么提前纠结？因为测试的人太清闲了。如果你让她写出100个测试用例然后通过集体讨论一次，你看看这个人是不是就怂了呢？
解决方案：
开发中很重要的一点就是要有最起码的“bydesign”的判断。一个（报告的）bug是不是（最终被技术经理评估的）bug，其重要一点就是要看测试用例有没有，以及测试用例有没有让所有程序员学习过。我们遇到一些扯淡的测试人员，手中没有测试用例文档，然后随便“点点点”地去测试，这个时候在一个正规的团队中显然就会造成很大的内耗（在只有2、3个人的团队中则不明显）。这就是不尊重开发流程的结果。没有测试用例而随便发出测试bug的测试人员，对一个正在繁忙工作的开发团队的开发进度的影响，就像是传播疟疾的苍蝇、传播瘟疫的老鼠，造成了内耗会在1个月之后显现出来。
解决方案：
为什么程序员总是说自己是最“苦逼的”程序员呢？可能就是因为他所处的团队中，其它部门（产品、测试）往往不按规矩行事。测试部门没有测试用例，或者有测试用例就用扯淡的“录入密码必须正确”这种空话来写，而没有具体的测试数据（最起码要写上“在密码之后写上3个空格”这种话），那么这种跟在开发人员屁股后头放空炮（没有事先测试用例用来沟通）的做法就造成了内耗。而产品的问题，往往就在于其描述的都是低层次的静态概念和图片，其提交的逻辑设计文档水平太低，无法作为模块设计文档的直接素材。