C产品在市场上有哪些独特优势？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1034个文字，预计阅读时间需要5分钟。
前言：前不不久遇到一个问题，是公司早期的基础库遇到的，其实是很低级的问题，但还是有记录下来。
出错点是IO流的写入bug，我们项目会有一种特定的数据格式，这个格式的奇妙之处在于……
前言
前不久遇到一个问题，是公司早期的基础库遇到的，其实很低级，但是还是记录下来。出错点是一个 IO 流的写入bug，我们项目会有一种专有的数据格式，这个格式的奇葩点在于如果设置 IO 读缓冲区为 2014 字节的时候，整个文件刚好能读完，也就是说其 length 刚好是 1024 的倍数。后来在一次升级中增加了更多的文件格式，并且新的文件格式使用了新的自定义写入流，具有加密和压缩的作用，这样一来，文件的长度就不一定是 1024 的倍数了。
后来通过查看这个基础类的源代码发现因为是 .NET 2.0 时代的东西，也没有 Stream.Copy 的方法，于是当时的程序员手动写了个 Stream.Copy 的方法，我稍作改动为了更直观将输出流改为输出到文件，代码大概如下：
var fs_in = System.IO.File.OpenRead(@"C:\3.0.6.apk"); var fs_out = System.IO.File.OpenWrite(@"C:\3.0.6.apk.copy"); byte[] buffer = new byte[1024]; while (fs_in.Read(buffer,0,buffer.Length)>0) { fs_out.Write(buffer, 0, buffer.Length); } Console.WriteLine("复制完成");
所以一眼就能看出这个方法简直有天大的 bug ，假设文件长度不为 1024 的倍数，永远会在文件尾部多补充上一段的冗余数据。
本文共计1034个文字，预计阅读时间需要5分钟。
前言：前不不久遇到一个问题，是公司早期的基础库遇到的，其实是很低级的问题，但还是有记录下来。
出错点是IO流的写入bug，我们项目会有一种特定的数据格式，这个格式的奇妙之处在于……
前言
前不久遇到一个问题，是公司早期的基础库遇到的，其实很低级，但是还是记录下来。出错点是一个 IO 流的写入bug，我们项目会有一种专有的数据格式，这个格式的奇葩点在于如果设置 IO 读缓冲区为 2014 字节的时候，整个文件刚好能读完，也就是说其 length 刚好是 1024 的倍数。后来在一次升级中增加了更多的文件格式，并且新的文件格式使用了新的自定义写入流，具有加密和压缩的作用，这样一来，文件的长度就不一定是 1024 的倍数了。
后来通过查看这个基础类的源代码发现因为是 .NET 2.0 时代的东西，也没有 Stream.Copy 的方法，于是当时的程序员手动写了个 Stream.Copy 的方法，我稍作改动为了更直观将输出流改为输出到文件，代码大概如下：
var fs_in = System.IO.File.OpenRead(@"C:\3.0.6.apk"); var fs_out = System.IO.File.OpenWrite(@"C:\3.0.6.apk.copy"); byte[] buffer = new byte[1024]; while (fs_in.Read(buffer,0,buffer.Length)>0) { fs_out.Write(buffer, 0, buffer.Length); } Console.WriteLine("复制完成");
所以一眼就能看出这个方法简直有天大的 bug ，假设文件长度不为 1024 的倍数，永远会在文件尾部多补充上一段的冗余数据。