提供部分 MemoryStream 和完整原始 Stream 的复合流包装器
- 作者: 纵点银
- 来源: 51数据库
- 2022-12-15
问题描述
有谁知道一种复合流解决方案,可以将流的第一部分预加载到 MemoryStream 中,并将剩余部分保留为原始流,在需要后续部分时将访问该流?
Does anyone know of a composite stream solution that will pre-load the first portion of a Stream in to a MemoryStream and keep the remainder as the original Stream which will be accessed when subsequent parts are required as necessary?
我应该想象一些包装类将实现 Stream 接口并根据访问的部分透明地处理两个流之间的访问.
I should imagine some wrapper class would implement the Stream interface and transparently juggle the access between the two streams depending upon which part is accessed.
我希望这是一个以前有人可能解决过的解决方案,也许是为了优化读取大型 FileStream 的性能.
I'm hoping this is a solution someone may have solved before, maybe to optimize performance of reading a large FileStream.
就我而言,我试图解决从 SD 卡读取大文件的 Windows Phone 8 错误.这个答案提供了我试图绕过的问题的更多细节:https://stackoverflow.com/a/17355068/250254
In my case I'm trying to get around a Windows Phone 8 bug reading large files from the SD card. More detail of the issue I'm trying to circumnavigate is provided in this answer: https://stackoverflow.com/a/17355068/250254
推荐答案
没有任何合理的方法可以使用 MemoryStream 来解决该错误,您首先会遇到 OutOfMemoryException.让我们把注意力集中在 bug 上,我会稍微简化一下代码以使其具有可读性:
There isn't any reasonable way you can use a MemoryStream to work around the bug, you'll fall over on OutOfMemoryException first. Let's focus a bit on the bug, I'll simplify the code a bit to make it readable:
DistanceToMove = (offset & 0xffffffff00000000L) >> 32; DistanceToMoveHigh = offset & 0xffffffffL; SetFilePointer(this.m_handle, lDistanceToMove, ref lDistanceToMoveHigh, begin);
微软程序员不小心交换了低值和高值.那么,您也可以撤消该错误.自己交换它们,以便错误将它们交换回您想要的方式:
The Microsoft programmer accidentally swapped the low and high values. Well, so can you to undo the bug. Swap them yourself so the bug swaps them back the way you want it:
public static void SeekBugWorkaround(Stream stream, long offset, SeekOrigin origin) {
ulong uoffset = (ulong)offset;
ulong fix = ((uoffset & 0xffffffffL) << 32) | ((uoffset & 0xffffffff00000000L) >> 32);
stream.Seek((long)fix, origin);
}
如果需要说明,显然确实如此,您必须依靠 Microsoft 最终修复此错误.很难预测什么时候会赌下一个点.有一些可能性您可以自动检测到这一点,尽管由于此错误如此严重,因此微软将要做什么并不明显.Seek() 的返回值以及 Position 属性的返回值都存在相同的错误.因此,寻找位置 1 并验证您是否获得了 1.
In case it needs to be said, it apparently does, you do have to count on Microsoft eventually fixing this bug. Hard to predict when so gamble on the next point release. There are some odds you can auto-detect this, albeit that it isn't obvious what Microsoft is going to do since this bug is so breaking. The return value of Seek() as well as the Position property return value suffer from the same bug. So seek to position 1 and verify that you get 1 back.
- C#通过fleck实现wss协议的WebSocket多人Web实时聊天(附源码)
- 团队城市未满足要求:MSBuildTools12.0_x86_Path 存在
- 使用 MSBuild.exe 在发布模式下构建 C# 解决方案
- 当我发布 Web 应用程序时,AfterPublish 脚本不运行
- 构建时 T4 转换的产品仅在下一个构建中使用
- ASP.NET Core Application (.NET Framework) for Windows x64 only error in project.assets.json
- 新的 .csproj 格式 - 如何将整个目录指定为“链接文件"到子目录?
- 如何将条件编译符号(DefineConstants)传递给 msbuild
- MSBuild 支持 Visual Studio 2017 RTM 中的 T4 模板
- NuGet 包还原找不到包,没有源
