文本字典档案（dictionary text file）

JR86

狼儿又来了，真无趣啊！每次写的程式一定会遇到一些小问题的。
狼儿写了一些用户的注册系统，这个系统会验证用户的名称是否已经被注册，或则是否是一些比较有意义的关键字。
这样做是因为使用这一个程式的网站为了避免一些很重要的关键字被用户注册成为用户名称。
比如说：writer（职称），business（名词），beauty（形容词）这一类的字眼都不能不用户注册。

狼儿已经写好一个程式可以从文本档案（text file）中检查这一些字眼。只要档案里面有的字眼都不能被注册。
可是问题来了，狼儿没有这一些字眼的档案，如果狼儿自己写得话，可能需要写上1-2年也未必可以写完。
狼儿想知道各位有没有这样的一个档案呢？档案里面包含了大部分我们日常所使用的英文字词。（听说学网路的应该都会有类似这样的档案呢！）

如果有的话，可以很慷慨的寄一份给狼儿吗？狼儿先谢谢各位啦！

blue333

原帖由 JR86 于 11-12-2006 06:55 PM 发表

狼儿又来了，真无趣啊！每次写的程式一定会遇到一些小问题的。
狼儿写了一些用户的注册系统，这个系统会验证用户的名称是否已经被注册，或则是否是一些比较有意义的关键字。
这样做是因为使用这一个程式的网站 ...

这样的设计有什麽作用呢 =_=??

如果不要别人注册到一些有意思的名字，

干脆用自动生成的就行了吗。

JR86

怎么自动生成？不怎么明白呢？
这个系统只要是把一些有意义的字眼保留，避免使用者故意注册这一类的字眼干扰游览者。比如说：
somewebsite.com/travelling，不知道的人可能以为travelling是somewebsite的字目录，其实那个使用户注册的名字。因为用户注册了一个名字以后，系统就会自动产生一个子目录，里面就是用户的个人首页。比如说：
somewebsite.com/myusername。

ikanyuchiew

原帖由 JR86 于 13-12-2006 12:32 AM 发表

怎么自动生成？不怎么明白呢？
这个系统只要是把一些有意义的字眼保留，避免使用者故意注册这一类的字眼干扰游览者。比如说：
somewebsite.com/travelling，不知道的人可能以为travelling是somewebsite的字目 ...

照你的说法，用户名不就也储存在database吗？就直接compare with username in database就好了，这样会快很多,txt file我觉得是多余了

blue333

原帖由 JR86 于 13-12-2006 12:32 AM 发表

怎么自动生成？不怎么明白呢？
这个系统只要是把一些有意义的字眼保留，避免使用者故意注册这一类的字眼干扰游览者。比如说：
somewebsite.com/travelling，不知道的人可能以为travelling是somewebsite的字目 ...

自动生成就是：用户要注册的时候不能自选名字，

电脑自动生成一个名字给用户。

JR86

原帖由 ikanyuchiew 于 13-12-2006 02:11 AM 发表
照你的说法，用户名不就也储存在database吗？就直接compare with username in database就好了，这样会快很多,txt file我觉得是多余了

资料库的验证部分是一定有的。可是这个系统需要的除了已经被注册的名字不能被注册以外，文本档案(text file)内的名字也不能被注册。狼儿不选择把拒绝名单（banned list）储存在数据库里面是应为狼儿知道这个名单（字典）一定是很大的档案，加上这个名单的内容是不会改变的（数据库的主要工作是储存经常会被更动的资料），为了节省资源起见。所以，狼儿觉得还是把这个名单储存为文本档案（text file）然后直接用fopen()读取就好了。

可是，重点来了。谁会有这一种的字典档案（dictionary file）呢？狼儿不想要用网路上的common_pass.dic是因为这个档案（common_pass.dic）里面的字眼是毫无意义的，狼儿需要的是一些有意义的字眼。

JR86

原帖由 blue333 于 13-12-2006 02:25 AM 发表

自动生成就是：用户要注册的时候不能自选名字，

电脑自动生成一个名字给用户。

这个也是一个很不错的建议呢！谢谢了！
狼儿会呈报上去看看，希望可以通过，这样狼儿就会少了很多的麻烦以及省功夫呢！
哈哈哈！

苦瓜汤

原帖由 JR86 于 13-12-2006 12:32 AM 发表

怎么自动生成？不怎么明白呢？
这个系统只要是把一些有意义的字眼保留，避免使用者故意注册这一类的字眼干扰游览者。比如说：
somewebsite.com/travelling，不知道的人可能以为travelling是somewebsite的字目 ...

这是一个很传统的想法... url并不一定是以文件系统目录来做resource locate。例如：http://www.sun.com/servicessolutions/industries/ 不一定是子目录。servicessolutions/industries是一个请求字串，SUN的服务器中的dispatcher会以请求字串自动处理回复的数据。如果要避免混淆，可以把url用这样的格式:

http://somewebsite.com/user/travelling

或者规定用户名内必须包含至少一个数字：

http://somewebsite.com/user/travelling_76

这样一看起来就大概知道travelling_76是一个用户。

至于用户名字典.. I/O的速度未必会比数据库来的快和节省资源

cupid25

你这么做的话。。。很不 effective 而且 resource overloading
如果 1000 个人同时 register 同时 verify 那么你的 effective use 已经扣大半分

至于 black listed 的 account 不可以搬去 text file 如果能的话。。。真的要就搬去一个特别 table 专门收集这些 account
如果要 recover 也容易。。。记得放 indexing 因为能够 enchance performance

JR86

狼儿知道使用text的缺点，一开始的时候因为懒惰去建立数据库，才选择使用文本的。
所以后来狼儿已经把文本的字典内容放到数据库去了。
谢谢各位高手的提醒呢！