什么导致了“Base-64字符数组的无效长度”?

I have very little to go on here. I can't reproduce this locally, but when users get the error I get an automatic email exception notification:

我在这里没什么可说的。我无法在本地复制这个，但当用户收到错误时，我将收到自动的电子邮件异常通知:

Invalid length for a Base-64 char array.

  at System.Convert.FromBase64String(String s)
  at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)
  at System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter.Deserialize(String serializedState)
  at System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState)
  at System.Web.UI.HiddenFieldPageStatePersister.Load()

I'm inclined to think there is a problem with data that is being assigned to viewstate. For example:

我倾向于认为分配给viewstate的数据存在问题。例如:

List<int> SelectedActionIDList = GetSelectedActionIDList();
ViewState["_SelectedActionIDList"] = SelectedActionIDList;

It's difficult to guess the source of the error without being able to reproduce the error locally.

如果不能在本地重现错误，就很难猜测错误的来源。

If anyone has had any experience with this error, I would really like to know what you found out.

如果有人有过这种错误的经验，我很想知道你发现了什么。

12 个解决方案

#1

I've seen this error caused by the combination of good sized viewstate and over aggressive content-filtering devices/firewalls (especially when dealing with K-12 Educational institutions).

我曾见过这种错误，是由于良好的viewstate大小和过于积极的内容过滤设备/防火墙(特别是在处理K-12教育机构时)的组合造成的。

We worked around it by storing Viewstate in SQL Server. Before going that route, I would recommend trying to limit your use of viewstate by not storing anything large in it and turning it off for all controls which do not need it.

我们通过在SQL Server中存储Viewstate来解决这个问题。在此之前，我建议您尽量限制viewstate的使用，不要在其中存储任何大型内容，并关闭它，以便所有不需要它的控件使用。

References for storing ViewState in SQL Server:
MSDN - Overview of PageStatePersister
ASP Alliance - Simple method to store viewstate in SQL Server
Code Project - ViewState Provider Model

在SQL Server中存储ViewState的引用:MSDN。PageStatePersister ASP联盟概述。SQL Server代码项目中存储ViewState的简单方法

#2

After urlDecode processes the text, it replaces all '+' chars with ' ' ... thus the error. You should simply call this statement to make it base 64 compatible again:

在urlDecode处理文本后，它将所有的“+”字符替换为“”……因此,错误。你应该简单地调用这个语句，使它再次与base 64兼容:

        sEncryptedString = sEncryptedString.Replace(' ', '+');

#3

My guess is that something is either encoding or decoding too often - or that you've got text with multiple lines in.

我的猜测是，有些东西要么是编码，要么是解码得太频繁——要么就是你有多行文本。

Base64 strings have to be a multiple of 4 characters in length - every 4 characters represents 3 bytes of input data. Somehow, the view state data being passed back by ASP.NET is corrupted - the length isn't a multiple of 4.

Base64字符串必须是4个字符长度的倍数——每4个字符表示输入数据的3字节。以某种方式，视图状态数据被ASP传回。网络被破坏-长度不是4的倍数。

Do you log the user agent when this occurs? I wonder whether it's a badly-behaved browser somewhere... another possibility is that there's a proxy doing naughty things. Likewise try to log the content length of the request, so you can see whether it only happens for large requests.

当发生这种情况时，您是否记录用户代理?我想知道它是否是一个表现不佳的浏览器……另一种可能性是，有一个代理在做一些淘气的事情。同样，请尝试记录请求的内容长度，以便您可以看到它是否只发生在大型请求中。

#4

int len = qs.Length % 4;
            if (len > 0) qs = qs.PadRight(qs.Length + (4 - len), '=');

where qs is any base64 encoded string

哪里的qs是任何base64编码的字符串

#5

Try this:

试试这个:

public string EncodeBase64(string data)
{
    string s = data.Trim().Replace(" ", "+");
    if (s.Length % 4 > 0)
        s = s.PadRight(s.Length + 4 - s.Length % 4, '=');
    return Encoding.UTF8.GetString(Convert.FromBase64String(s));
}

#6

As others have mentioned this can be caused when some firewalls and proxies prevent access to pages containing a large amount of ViewState data.

正如其他人提到的，当一些防火墙和代理阻止访问包含大量ViewState数据的页面时，可能会导致这种情况。

ASP.NET 2.0 introduced the ViewState Chunking mechanism which breaks the ViewState up into manageable chunks, allowing the ViewState to pass through the proxy / firewall without issue.

ASP。NET 2.0引入了ViewState分块机制，该机制将ViewState分解为可管理的块，允许ViewState通过代理/防火墙没有问题。

To enable this feature simply add the following line to your web.config file.

要启用此功能，只需向web添加以下代码行。配置文件。

<pages maxPageStateFieldLength="4000">

This should not be used as an alternative to reducing your ViewState size but it can be an effective backstop against the "Invalid length for a Base-64 char array" error resulting from aggressive proxies and the like.

这不应该用作减少ViewState大小的替代方法，但它可以有效地防止由于攻击代理等原因导致的“Base-64 char数组的无效长度”错误。

#7

Take a look at your HttpHandlers. I've been noticing some weird and completely random errors over the past few months after I implemented a compression tool (RadCompression from Telerik). I was noticing errors like:

看看你的HttpHandlers。在我实现了一个压缩工具(来自Telerik的rad压缩)之后的几个月里，我发现了一些奇怪的、完全随机的错误。我注意到一些错误，比如:

System.Web.HttpException: Unable to validate data.

包含。HttpException:无法验证数据。
System.Web.HttpException: The client disconnected.---> System.Web.UI.ViewStateException: Invalid viewstate.

包含。textbox:客户端断开连接。推荐- - - - - - > System.Web.UI。ViewStateException:无效的视图状态。

and

和

System.FormatException: Invalid length for a Base-64 char array.

系统。FormatException:基64字符数组的无效长度。
System.Web.HttpException: The client disconnected. ---> System.Web.UI.ViewStateException: Invalid viewstate.

包含。textbox:客户端断开连接。推荐- - - - - - > System.Web.UI。ViewStateException:无效的视图状态。

I wrote about this on my blog.

我在博客上写了这篇文章。

#8

This is because of a huge view state, In my case I got lucky since I was not using the viewstate. I just added enableviewstate="false" on the form tag and view state went from 35k to 100 chars

这是因为视图状态很大，我很幸运，因为我没有使用viewstate。我刚刚在表单标签上添加了enableviewstate="false"视图状态从35k变为100chars

#9

During initial testing for Membership.ValidateUser with a SqlMembershipProvider, I use a hash (SHA1) algorithm combined with a salt, and, if I changed the salt length to a length not divisible by four, I received this error.

在初始会员测试期间。使用SqlMembershipProvider的ValidateUser，我使用一个散列(SHA1)算法和一个salt结合，如果我将salt长度更改为不能被4整除的长度，我就会收到这个错误。

I have not tried any of the fixes above, but if the salt is being altered, this may help someone pinpoint that as the source of this particular error.

我还没有尝试过上面的任何修复方法，但是如果盐被改变了，这可能会帮助人们找到这个错误的来源。

#10

As Jon Skeet said, the string must be multiple of 4 bytes. But I was still getting the error.

正如Jon Skeet所说，字符串必须是4字节的倍数。但我还是犯了错误。

At least it got removed in debug mode. Put a break point on Convert.FromBase64String() then step through the code. Miraculously, the error disappeared for me :) It is probably related to View states and similar other issues as others have reported.

至少在调试模式下被删除了。在Convert.FromBase64String()上设置一个断点，然后逐步执行代码。不可思议的是，这个错误对我来说消失了:)它可能与视图状态以及其他报告中提到的类似问题有关。

#11

This isn't an answer, sadly. After running into the intermittent error for some time and finally being annoyed enough to try to fix it, I have yet to find a fix. I have, however, determined a recipe for reproducing my problem, which might help others.

遗憾的是，这不是一个答案。在遇到断断续续的错误一段时间后，终于感到很恼火，想要修复它，我还没有找到解决办法。然而，我已经决定了一个方法来重现我的问题，这可能会对其他人有所帮助。

In my case it is SOLELY a localhost problem, on my dev machine that also has the app's DB. It's a .NET 2.0 app I'm editing with VS2005. The Win7 64 bit machine also has VS2008 and .NET 3.5 installed.

在我的例子中，它只是一个本地主机问题，在我的开发机器上，它也有应用程序的DB。这是我正在用VS2005编辑的。net 2.0应用。win764位机也安装了VS2008和。net 3.5。

Here's what will generate the error, from a variety of forms:

以下是将从各种形式中产生错误的原因:

Load a fresh copy of the form.
加载一个新的表单副本。
Enter some data, and/or postback with any of the form's controls. As long as there is no significant delay, repeat all you like, and no errors occur.
使用窗体的任何控件输入一些数据和/或回发。只要没有明显的延迟，重复所有您喜欢的，并且不会发生错误。
Wait a little while (1 or 2 minutes maybe, not more than 5), and try another postback.
稍等一会儿(1或2分钟，不超过5分钟)，然后尝试另一个回发。

A minute or two delay "waiting for localhost" and then "Connection was reset" by the browser, and global.asax's application error trap logs:

一到两分钟的延迟“等待localhost”，然后“连接被浏览器重置”和全局。asax的应用程序错误陷阱日志:

Application_Error event: Invalid length for a Base-64 char array.
Stack Trace:
     at System.Convert.FromBase64String(String s)
     at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)
     at System.Web.UI.Util.DeserializeWithAssert(IStateFormatter formatter, String serializedState)
     at System.Web.UI.HiddenFieldPageStatePersister.Load()

In this case, it is not the SIZE of the viewstate, but something to do with page and/or viewstate caching that seems to be biting me. Setting <pages> parameters enableEventValidation="false", and viewStateEncryption="Never" in the Web.config did not change the behavior. Neither did setting the maxPageStateFieldLength to something modest.

在这种情况下，似乎困扰我的不是viewstate的大小，而是与页面和/或viewstate缓存有关的内容。在Web中设置参数enableEventValidation="false"， viewStateEncryption="Never"。配置没有改变行为。maxPageStateFieldLength的设置也不太合适。

#12

In addition to @jalchr's solution that helped me, I found that when calling ATL::Base64Encode from a c++ application to encode the content you pass to an ASP.NET webservice, you need something else, too. In addition to

除了@jalchr的解决方案对我有帮助之外，我还发现，在从c++应用程序调用ATL::Base64Encode以对传递给ASP的内容进行编码时。NET webservice，你也需要别的东西。除了

sEncryptedString = sEncryptedString.Replace(' ', '+');

from @jalchr's solution, you also need to ensure that you do not use the ATL_BASE64_FLAG_NOPAD flag on ATL::Base64Encode:

从@jalchr的解决方案中，您还需要确保不使用ATL:: base64_flag_nopad标志:

 BOOL bEncoded = Base64Encode(lpBuffer,
                    nBufferSizeInBytes,
                    strBase64Encoded.GetBufferSetLength(base64Length),
                    &base64Length,ATL_BASE64_FLAG_NOCRLF/*|ATL_BASE64_FLAG_NOPAD*/);

#1