但是如果电子邮件地址包含字符i,则WebSecurity.CreateUserAndAccount方法抛出异常说：
The authentication provider returned an error. Please verify your
entry and try again. If the problem persists,please contact your
system administrator.
我研究了很多,并找到了几个帖子,但没有解决方案.
http://forums.asp.net/t/1862233.aspx/1?How+can+i+use+email+address+for+username+in+MVC4+Membership
解决方法
“ASCII字符集”将您限制为美式英文字母,这恰好是拉丁字母.
我不会说土耳其语,但正如所指出的那样
http://aspnetwebstack.codeplex.com/workitem/714
在土耳其语中,“我”是小写的,而“İ”是“i”的上限.
在拉丁字母表中,你(和我)碰巧没有IT智慧,而“我”是我的大写字母.
所以你有一个字符不是EN-US ASCII字符集的成员.
因此,排序规则设置可防止您将非ASCII字符输入到数据库中,从而导致错误.
因此,您不应更改排序规则设置(允许无效邮件地址)的注释.
如上所述,ToUpper(应该是ToUpperInvariant)是怪的,因为它在幕后将’i’更改为’İ’,这不是一个有效的ASCII字符.
这是字符串/字符的ToUpper方法的常见问题.
例如,德语字母包含字母ß(Unicode U 00DF),也称为“double s”,首先没有相应的大写字符,因此如果您尝试使用toUpper比较字符串,它将始终失败,哪些是为什么你应该总是使用ToLower()比较字符串 – 另一个Microsoft失败.
类似的事情发生在这里与ToUpper.
您首先需要做的是确保您的用户输入ASCII字符.
这是不可能的,因为他们有一个土耳其语键盘和区域设置,而小的我将看起来类似于ASCII小i,它有一个不同的数字表示,因此一个不同的大写字符(小写以及btw).
所以你需要做的就是在调用成员资格方法之前,先对“输入字符串”进行拉丁/罗马化.
我有类似的问题,只有ASCII的能力的软件从第三方,失败的变音符和法语口音字符,并使用下面的方法来解决这个问题.
您可能想要检查土耳其语äöü是否与我在这里使用的(瑞士)德语äöü不同.
对于风险和副作用,请阅读包装单张,并询问您的医生或药剂师.
// string str = ApertureSucks.Latinize("(æøå âôû?aè");
public static string Latinize(string stIn)
{
// Special treatment for German Umlauts
stIn = stIn.Replace("ä","ae");
stIn = stIn.Replace("ö","oe");
stIn = stIn.Replace("ü","ue");
stIn = stIn.Replace("Ä","Ae");
stIn = stIn.Replace("Ö","Oe");
stIn = stIn.Replace("Ü","Ue");
// End special treatment for German Umlauts
string stFormD = stIn.Normalize(System.Text.NormalizationForm.FormD);
System.Text.StringBuilder sb = new System.Text.StringBuilder();
for (int ich = 0; ich < stFormD.Length; ich++)
{
System.Globalization.UnicodeCategory uc = System.Globalization.CharUnicodeInfo.GetUnicodeCategory(stFormD[ich]);
if (uc != System.Globalization.UnicodeCategory.NonSpacingMark)
{
sb.Append(stFormD[ich]);
} // End if (uc != System.Globalization.UnicodeCategory.NonSpacingMark)
} // Next ich
//return (sb.ToString().Normalize(System.Text.NormalizationForm.FormC));
return (sb.ToString().Normalize(System.Text.NormalizationForm.FormKC));
} // End Function Latinize
最后但并非最不重要的是,我不会使用内置的ASP.NET成员资格提供者,因为它通过用户名应用程序名称连接到rolename,而不是使用唯一的ID.这意味着您将无法更改用户或组/角色名称,而无需更改所有映射表.
我认为这样做是非常不受欢迎的,绝对愚蠢和粗心,如果不是微软的彻底的危险.
我会去把这种垃圾释放到野外来说是无礼的.
下面的“事情”表明问题的完全愚蠢,不应该被使用
CREATE TABLE [dbo].[UsersInRoles](
[Username] [varchar](255) NOT NULL,[Rolename] [varchar](255) NOT NULL,[ApplicationName] [varchar](255) NOT NULL,CONSTRAINT [usersinroles_pkey] PRIMARY KEY CLUSTERED
(
[Username] ASC,[Rolename] ASC,[ApplicationName] ASC
)WITH (PAD_INDEX = OFF,STATISTICS_NORECOMPUTE = OFF,IGNORE_DUP_KEY = OFF,ALLOW_ROW_LOCKS = ON,ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
原因如下：
>问题1：字符串加入将使用户角色加入非常慢 – 非常
表现不佳
>问题2：varchar – 应该是nvarchar,除非
你生活在一个只有英文的宇宙中
>问题3：场长
用户名和rolename必须符合最新活动的最低规格
目录,否则会出现同步问题
活动目录. Plus活动目录允许unicode字符.
>问题4：没有外键引用用户和角色表 –
最迟会有数据垃圾迟早(通常较早)
>问题5：如果现在你更改用户名或
groupname,UserInRoles不会被更新和用户的组
映射将孤立 – 最终与数据垃圾,左连接将带来空列,程序可能会由于未处理的NullReferenceException而崩溃.
>问题6：因为外键引用
丢失,可以更改用户名/组名
>问题7：数据垃圾迟早会在报告/显示数据时导致多行
>问题8：这里使用的主键应该是唯一的约束
>问题9：有一个组名,但是例如组“管理员”需要被本地化到许多语言,这是会员提供商不支持的.另外,groupname属于映射表,因为一个组可以有N个语言的N个名称,然后必须确保组名在特定语言中是唯一的.
>问题10：这里不可见,但用户表包含一个字段电子邮件.这是一个完全失败的原因,因为一个用户可以拥有n个电子邮件地址,智能会员提供商应该考虑到这一点,而不是愚蠢地将用户限制在一个电子邮件地址.
>问题11：此外,上述电子邮件字段限制为128个字符,小于根据rfc允许的电子邮件地址允许的最大字符数.失败 – 迟早有人无法输入他的邮件地址 – 即使他只有一个. What is the maximum length of a valid email address?
我相信MS提供的会员提供者的失败还有更多的问题.例如,使用快速散列算法(MD5),这是一种反模式,因为这样可以实现彩虹表的攻击,特别是如果散列不是盐渍的.如果MS成员提供者展示了一件事情,那么这就是如何设计会员提供商.
