System.Text.Ecoding.UTF8.GetString 返回垃圾
这是一项艰难的任务。我有一个响应过滤器设置，可以在返回到浏览器之前转换 html (http://aspnetresources.com/文章/HttpFilters）。除了我的机器之外，这在每个人的机器上都可以正常工作。实际上它一直在我的机器上运行，直到我因为它锁定而不得不进行硬重置。
public override void Write(byte[] buffer, int offset, int count)
{
string strBuffer = System.Text.UTF8Encoding.UTF8.GetString(buffer, offset, count);
对于其他人（以及我以前的人）来说，strBuffer 包含 HTML。现在，无论出于何种原因，它都会为我返回垃圾字符。有什么想法吗？我要拔头发了！！
更新
事实证明，“启用动态内容压缩”导致了该问题。由于某种原因，它在传递到过滤器之前会被压缩。
解决方案
在 web.config 中将“dynamicCompressionBeforeCache”设置为 false 修复了该问题。
<urlCompression doStaticCompression="true" doDynamicCompression="true" dynamicCompressionBeforeCache="false" />
This is a tough one. I have a Response filter setup to transform the html before spitting back out to the browser (http://aspnetresources.com/articles/HttpFilters). This works fine on everyones machine but mine. Actually it was working on my machine until I had to do a hard reset because it locked up.
public override void Write(byte[] buffer, int offset, int count)
{
string strBuffer = System.Text.UTF8Encoding.UTF8.GetString(buffer, offset, count);
For everyone else (and mine previosly) strBuffer contains HTML. Now for whatever reason it's returning junk characters for me. Any ideas? I'm pulling my hair out!!
Update
Turns out that "Enable dynamic content compression" is causing the issue. For some reason it's getting gzipped before being passed into the filter.
Solution
Setting the "dynamicCompressionBeforeCache" to false in the web.config fixed the issue.
<urlCompression doStaticCompression="true" doDynamicCompression="true" dynamicCompressionBeforeCache="false" />
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您指定了这些字节： 31, 139, 8, 0, 0, 0, 0, 0, 4
这不是有效的 UTF-8。特别是，这意味着 Unicode 字符 U+0031（“信息分隔符 1”）后跟字节 139 和 8...以及 139 后跟 8 不是有效的 UTF-8 字节序列。即使这些确实形成了一个有效的序列，您也会有 5 个 Unicode U+0000 字符 (NUL)，后跟 U+0004（传输结束）。几乎没有有效的 HTML。
我不知道您实际上在过滤什么，但它不是有效的 UTF-8 文本。事实上，它看起来根本不可能是文本。您是否实际上正在尝试将过滤器应用于图像等二进制数据？
请注意，您的过滤方法还有另一个基本问题：您假设每个缓冲区都包含完整文本。您很可能会收到一个包含字符前半部分的缓冲区，然后收到包含该字符其余部分的第二个缓冲区。这就是 System.Text.Decoder 接口的用途 - 它是有状态的，可以记住部分字符。
You've specified these bytes: 31, 139, 8, 0, 0, 0, 0, 0, 4
That's not valid UTF-8. In particular, it would mean Unicode character U+0031 ("INFORMATION SEPARATOR ONE") followed by bytes 139 and 8... and 139 followed by 8 isn't a valid UTF-8 byte sequence. Even if those did form a valid sequence, you'd then have 5 Unicode U+0000 characters (NUL) followed by U+0004 (END OF TRANSMISSION). Hardly in valid HTML.
I don't know what you're actually filtering, but it isn't valid UTF-8 text. It doesn't look likely to be text at all, in fact. Is it possible that you're actually trying to apply a filter to binary data such as an image?
Note that you have another fundamental problem with your method of filtering: you're assuming that each buffer contains complete text. It's quite possible for a you to receive one buffer which contains the first half of a character and then a second buffer containing the remainder of it. That's what the
System.Text.Decoderinterface is for - it's stateful, remembering partial characters.听起来好像出了什么问题。我在被锁定后也有过一些奇怪的行为。
对我有用的是删除 C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files 中的临时文件
Sounds like something went wrong. I too have had some strange behaviour after a lockup.
What worked for me was to delete the temp files in C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files