首页   注册   登录

mostkia

V2EX 第 322101 号会员,加入于 2018-06-12 11:18:11 +08:00
今日活跃度排名 5890
mostkia 最近回复了
2 小时 0 分钟前
回复了 zachlhb 创建的主题 程序员 大牛是如何做到整套程序不写一个注释的
不写注释才爽好吗…只是后期看代码就蛋疼了,你让任何程序员不写注释都能做到的,后期维护就不知道了,至于你说的情况,我觉得可能是留了两份吧,开发用开发版的有注释,上线了就删除所有注释,提高阅读成本。一般搞前端的比较普遍。
@iwtbauh 74#受教了,以后有需要的情况下也有可行对策了,虽然有轮子用自然最好了的,pdo 也挺方便的。但多一个办法多一条路总归也是好的。
rem+响应式吧,分辨率不是问题,只是不再兼容 IE9 以下了。
已重写控制程序,目前使用 pdo 预处理解决注入问题,今天一点开就 40 多条回复,没想到那么讨论激烈。其实这个被疯狂吐槽的需求锅不应该由我来背。。。因为之前的数据库控制程序并不是我写的,项目做到一半由我接手的,现在想想的确挺蛋疼的,之前的控制程序直接是标准的 sqlite 接口,当然也有一些基本的字符串过滤,但感觉不太好,但也因为怕出 BUG 实在不想改数据库控制程序这部分,所以才想了一些投机取巧的方法。后来一想长痛不如短痛,索性都重写了,好在业务逻辑也不复杂,已经全部搞定了,感谢大家的意见。
@Vegetable 没有复杂查询条件我觉得是可以的,但碰到如果有模糊查询就不行了。我目前需求只是偶尔有一些精确匹配搜索,所以问问可行性,没想到那么多人理解错了,哈哈,没关系。实在不行就老老实实的直接做标准过滤吧,反正也就是处理一些用户名、密码、数量、型号、日期什么的,按照它们的类别做好过滤即可,一般也用不上这些特殊字符,保留英文数字,正则判断禁止所有的特殊字符就可以了。
@opengps 好的,谢谢,我认真考虑你说的方案的。
@yagao0o 是啊,我也这样考虑了,这个问题比较困难,虽然目前数据库虽然没有模糊匹配的需求,但以后就不确定了,所以也只是探讨一下是否可行。
@gamexg 恩,你说的很对,我也考虑过。不过目前我数据库需求,都是完整精确匹配的,可以将输入内容也进行 b64 预处理后再搜索,类似于 MD5 的密码校验吧。复杂的多条件估计是不行的。所以也是处于考虑中是否要这样做。
@funcman =_=神奇。。好吧,看来我说的不清楚,大家都有些理解错误。我的意思在明确一下:字符串处理完全在后台存数据时进行,存入到数据库的就是 b64,SQL 增删改查的关键词都是预设的字符串,固定的,前台来的变量则通通都会被编码成 b64 再存储,网络传输阶段都是明文传输的,和传输阶段没有什么关系。
想不通为什么大家都理解为传输阶段进行编码呢。。我的意思其实是存入数据库前由后台进行编码,存入数据库的就是 base64 内容。
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   821 人在线   最高记录 4346   ·  
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 15ms · UTC 19:40 · PVG 03:40 · LAX 11:40 · JFK 14:40
♥ Do have faith in what you're doing.
沪ICP备16043287号-1