算法读取大文件

1. C++如何读取一个大文件，并识别各个字符串出现的次数，找到次数最多的。输出这个字符

#include <stdio.h>
#include <string.h>

int main()
{
char s[4]="abc",sc='d';//比较的字符串和字符
FILE *fp;
char filename[100],c;
int i=0,n1=0,n2=0;
long fpos,len;

printf("input filename:\n");
gets(filename);//输入文件名称

if((fp=fopen(filename,"r"))==NULL)//打开文件
{
printf("open %s error!\n",filename);
return 1;
}

len=strlen(s);
c=fgetc(fp);
while(!feof(fp))
{
if(c==s[0])//如果第一个字符相等,比较剩下的字符串
{
fpos=ftell(fp);//记住当前文件指针位置
for(i=1;i<len;i++)
{
if(fgetc(fp)!=s[i])//如果不匹配,跳出循环
{
fseek(fp,fpos,0);//重新设置指针位置
break;
}
}
if(i==len)//如果匹配成功,累加数目
n1++;

}
if(c==sc)//与字符sc匹配,累加数目
n2++;
c=fgetc(fp);
}

printf("\n与字符串%s匹配的有%d个\n",s,n1);//输出匹配个数
printf("与字符%c匹配的有%d个\n",sc,n2);
getchar();
return 0;
}

2. c语言按块读取大文本文件，但是最后一段不定长，求代码，悬赏100，能用给分

fread和fwrite函数参数1和8写反了，请查阅这两个函数的定义。

int nCount = fread(mingwen1,1,8,f); //返回nCount实际读取到的字符个数，每一次能读满就是8否则按读到的数来
fwrite(mingwen1,1,nCount,f); //要写入实际读取的长度，而不是统一的8，至于你密文长度是多少就得你自己计算了，因为不知道你加密算法有没有增加原来字符串长度。

你用如下代码覆盖你源代码中的类似部分试试：
while(int nCount = fread(mingwen1,1,8,f))
{
//int se = CDes(mingwen1,miwen,mm,0);//暂时屏蔽，要加密请加上这句并把下一句变量改为miwen
fwrite(mingwen1,1,nCount,g);
}

同时在while循环之前，和每一次fwrite之后应该使用
memset(mingwen1,0,8);
memset(miwen,0,8);
将mingwen1和miwen置0，不然最后一次虽然没有读取满，但是会保留前一次的字符在里面。

3. 寻找java提取大文件中一段字符串的最快的算法

字符串.substring(start,end);
字符串.replace("\n","");

4. VC 读写大文件

先读一段比如100K，然后在这个100K的内存总查找"begin"，如果查不到，再读下一个100K，直到找到为止，如果相应的"end"不在这个段中，那么再继续读下面的段，直到找到结束标签为止。

----------------------------------------------------- 补充1
这个问题不难解决，在读数据的时候，需要多读一点，但是下次再读取的时候，不能仅接着上次的尾部读取了，而是应该倒退几个字符，倒退的数目应该是：最大特征字符长度 - 1。
下面是个简单的图解：
------------------|xxx 3 xxx|
---------|xxx 2 xxx|
|xxx 1 xxx|
################################################
一次性的new出一个特别巨大的内存，是一个愚蠢的做法，如果是一个大于4G的文件，那么你就会更加困难。虽然系统会自动的申请虚拟内存，但是这将极大的影响函数处理的速度，这也是我们国家软件行业所存在的通病，虽然很多程序也能够运行，但是效率与速度都相当的落后，我们应该把软件做的尽可能的快、智能、便捷、清丽。

5. J2ME怎么读取大文件TXT

一般是先定位再读取。
如果是阅读器，读取任意文本文件，那建议设定一个字符缓冲区大小，比如n，那么上来就先读取这n个字符，够你全屏显示的。然后根据用户输入，比如翻页，或者定位到百分比，再计算出位置，以及根据位置计算出跳过的字节数，然后skip过去。
如果是你的软件自己保存文件，可以在文件中加上“里程碑”一样的标记，和楼上说的一样，这样可以快速定位到一个小节，再做后续操作。
读取方法还是无外乎那几种方式getClass().getResourceAsStream(String str)；或用jsr75

6. 读取大量数据时数据时内存溢出怎样分批读取该怎么处理

众所周知，java在处理数据量比较大的时候，加载到内存必然会导致内存溢出，而在一些数据处理中我们不得不去处理海量数据，在做数据处理中，我们常见的手段是分解，压缩，并行，临时文件等方法;例如，我们要将数据库(不论是什么数据库)的数据导出到一个文件，一般是Excel或文本格式的CSV;对于Excel来讲，对于POI和JXL的接口，你很多时候没有法去控制内存什么时候向磁盘写入，很恶心，而且这些API在内存构造的对象大小将比数据原有的大小要大很多倍数，所以你不得不去拆分Excel，还好，POI开始意识到这个问题，在3.8.4的版本后，开始提供cache的行数，提供了SXSSFWorkbook的接口，可以设置在内存中的行数，不过可惜的是，他当你超过这个行数，每添加一行，它就将相对行数前面的一行写入磁盘(如你设置2000行的话，当你写第20001行的时候，他会将第一行写入磁盘)，其实这个时候他些的临时文件，以至于不消耗内存，不过这样你会发现，刷磁盘的频率会非常高，我们的确不想这样，因为我们想让他达到一个范围一次性将数据刷如磁盘，比如一次刷1M之类的做法，可惜现在还没有这种API，很痛苦，我自己做过测试，通过写小的Excel比使用目前提供刷磁盘的API来写大文件，效率要高一些，而且这样如果访问的人稍微多一些磁盘IO可能会扛不住，因为IO资源是非常有限的，所以还是拆文件才是上策;而当我们写CSV，也就是文本类型的文件，我们很多时候是可以自己控制的，不过你不要用CSV自己提供的API，也是不太可控的，CSV本身就是文本文件，你按照文本格式写入即可被CSV识别出来;如何写入呢？下面来说说。。。在处理数据层面，如从数据库中读取数据，生成本地文件，写代码为了方便，我们未必要1M怎么来处理，这个交给底层的驱动程序去拆分，对于我们的程序来讲我们认为它是连续写即可;我们比如想将一个1000W数据的数据库表，导出到文件;此时，你要么进行分页，oracle当然用三层包装即可，mysql用limit，不过分页每次都会新的查询，而且随着翻页，会越来越慢，其实我们想拿到一个句柄，然后向下游动，编译一部分数据(如10000行)将写文件一次(写文件细节不多说了，这个是最基本的)，需要注意的时候每次buffer的数据，在用outputstream写入的时候，最好flush一下，将缓冲区清空下;接下来，执行一个没有where条件的SQL，会不会将内存撑爆？是的，这个问题我们值得去思考下，通过API发现可以对SQL进行一些操作，例如，通过：PreparedStatementstatement=connection.prepareStatement(sql)，这是默认得到的预编译，还可以通过设置：PreparedStatementstatement=connection.prepareStatement(sql，ResultSet.TYPE_FORWARD_ONLY，ResultSet.CONCUR_READ_ONLY);来设置游标的方式，以至于游标不是将数据直接cache到本地内存，然后通过设置statement.setFetchSize(200);设置游标每次遍历的大小;OK，这个其实我用过，oracle用了和没用没区别，因为oracle的jdbcAPI默认就是不会将数据cache到java的内存中的，而mysql里头设置根本无效，我上面说了一堆废话，呵呵，我只是想说，java提供的标准API也未必有效，很多时候要看厂商的实现机制，还有这个设置是很多网上说有效的，但是这纯属抄袭;对于oracle上面说了不用关心，他本身就不是cache到内存，所以java内存不会导致什么问题，如果是mysql，首先必须使用5以上的版本，然后在连接参数上加上useCursorFetch=true这个参数，至于游标大小可以通过连接参数上加上：defaultFetchSize=1000来设置，例如：jdbc：mysql：//xxx.xxx.xxx.xxx：3306/abc？zeroDateTimeconvertToNull&useCursorFetch=true&defaultFetchSize=1000上次被这个问题纠结了很久(mysql的数据老导致程序内存膨胀，并行2个直接系统就宕了)，还去看了很多源码才发现奇迹竟然在这里，最后经过mysql文档的确认，然后进行测试，并行多个，而且数据量都是500W以上的，都不会导致内存膨胀，GC一切正常，这个问题终于完结了。我们再聊聊其他的，数据拆分和合并，当数据文件多的时候我们想合并，当文件太大想要拆分，合并和拆分的过程也会遇到类似的问题，还好，这个在我们可控制的范围内，如果文件中的数据最终是可以组织的，那么在拆分和合并的时候，此时就不要按照数据逻辑行数来做了，因为行数最终你需要解释数据本身来判定，但是只是做拆分是没有必要的，你需要的是做二进制处理，在这个二进制处理过程，你要注意了，和平时read文件不要使用一样的方式，平时大多对一个文件读取只是用一次read操作，如果对于大文件内存肯定直接挂掉了，不用多说，你此时因该每次读取一个可控范围的数据，read方法提供了重载的offset和length的范围，这个在循环过程中自己可以计算出来，写入大文件和上面一样，不要读取到一定程序就要通过写入流flush到磁盘;其实对于小数据量的处理在现代的NIO技术的中也有用到，例如多个终端同时请求一个大文件下载，例如视频下载吧，在常规的情况下，如果用java的容器来处理，一般会发生两种情况：其一为内存溢出，因为每个请求都要加载一个文件大小的内存甚至于，因为java包装的时候会产生很多其他的内存开销，如果使用二进制会产生得少一些，而且在经过输入输出流的过程中还会经历几次内存拷贝，当然如果有你类似nginx之类的中间件，那么你可以通过send_file模式发送出去，但是如果你要用程序来处理的时候，内存除非你足够大，但是java内存再大也会有GC的时候，如果你内存真的很大，GC的时候死定了，当然这个地方也可以考虑自己通过直接内存的调用和释放来实现，不过要求剩余的物理内存也足够大才行，那么足够大是多大呢？这个不好说，要看文件本身的大小和访问的频率;其二为假如内存足够大，无限制大，那么此时的限制就是线程，传统的IO模型是线程是一个请求一个线程，这个线程从主线程从线程池中分配后，就开始工作，经过你的Context包装、Filter、拦截器、业务代码各个层次和业务逻辑、访问数据库、访问文件、渲染结果等等，其实整个过程线程都是被挂住的，所以这部分资源非常有限，而且如果是大文件操作是属于IO密集型的操作，大量的CPU时间是空余的，方法最直接当然是增加线程数来控制，当然内存足够大也有足够的空间来申请线程池，不过一般来讲一个进程的线程池一般会受到限制也不建议太多的，而在有限的系统资源下，要提高性能，我们开始有了newIO技术，也就是NIO技术，新版的里面又有了AIO技术，NIO只能算是异步IO，但是在中间读写过程仍然是阻塞的(也就是在真正的读写过程，但是不会去关心中途的响应)，还未做到真正的异步IO，在监听connect的时候他是不需要很多线程参与的，有单独的线程去处理，连接也又传统的socket变成了selector，对于不需要进行数据处理的是无需分配线程处理的;而AIO通过了一种所谓的回调注册来完成，当然还需要OS的支持，当会掉的时候会去分配线程，目前还不是很成熟，性能最多和NIO吃平，不过随着技术发展，AIO必然会超越NIO，目前谷歌V8虚拟机引擎所驱动的node.js就是类似的模式，有关这种技术不是本文的说明重点;将上面两者结合起来就是要解决大文件，还要并行度，最土的方法是将文件每次请求的大小降低到一定程度，如8K(这个大小是经过测试后网络传输较为适宜的大小，本地读取文件并不需要这么小)，如果再做深入一些，可以做一定程度的cache，将多个请求的一样的文件，cache在内存或分布式缓存中，你不用将整个文件cache在内存中，将近期使用的cache几秒左右即可，或你可以采用一些热点的算法来配合;类似迅雷下载的断点传送中(不过迅雷的网络协议不太一样)，它在处理下载数据的时候未必是连续的，只要最终能合并即可，在服务器端可以反过来，谁正好需要这块的数据，就给它就可以;才用NIO后，可以支持很大的连接和并发，本地通过NIO做socket连接测试，100个终端同时请求一个线程的服务器，正常的WEB应用是第一个文件没有发送完成，第二个请求要么等待，要么超时，要么直接拒绝得不到连接，改成NIO后此时100个请求都能连接上服务器端，服务端只需要1个线程来处理数据就可以，将很多数据传递给这些连接请求资源，每次读取一部分数据传递出去，不过可以计算的是，在总体长连接传输过程中总体效率并不会提升，只是相对相应和所开销的内存得到量化控制，这就是技术的魅力，也许不要太多的算法，不过你得懂他。类似的数据处理还有很多，有些时候还会将就效率问题，比如在HBase的文件拆分和合并过程中，要不影响线上业务是比较难的事情，很多问题值得我们去研究场景，因为不同的场景有不同的方法去解决，但是大同小异，明白思想和方法，明白内存和体系架构，明白你所面临的是沈阳的场景，只是细节上改变可以带来惊人的效果。

7. C语言快速读取超大数组的问题

关键不在于你要把它读进去。
而在于：
1.文件哪来的，有办法不用那么大的文件么？建立文件的时候不能建立一个索引么？或者用一个便于访问的格式么？
2.文件要用来干什么？CPU一次只能处理几个字节，你为什么要把它全读到内存里呢？

如果第1条不能解决，也就是最坏的情况，那么建议：
做一个转换器，把原始文件转换成便于操作的文件再进行处理。所谓便于操作，就是说，每一行数据的大小固定，因而可以对数据进行快速访问。转一行存一行，不会花太多内在。需要一定的转换时间，但是因为可以预估，所以界面上可以做一个转换进度来降低用户的主观等待时间。

PS:至于你是把转换后的数据存到文件进行访问，还是用映射的方式把文件映射到内存来读写，实质上差不多，不过后者可能有系统提供的缓存机制来提高效率。但是本质上一样的：转换成临时文件、使用；或者干脆就是用专门的程序转换出新文件，再用处理程序去处理。看场合了。

如果你的文件是存储在顺序存储器中，比如磁带上：
那么差不多意思，想办法把数据转存到你的磁盘上，然后再进行随机访问。

补充：：：：关于内存映射：见上面的PS内容，先把文件转成可随机访问格式（比如我说要哪一行数据，你就立刻能找到/算出，而不是从头一行一行去找），然后再做内存映射。
另外，Windows下和Linux下的内存映射有所不同，但是基本上不难，可以直接搜索找到照搬。

8. 文件读写操作，排序算法

1、 堆排序定义 n个关键字序列Kl，K2，…，Kn称为堆，当且仅当该序列满足如下性质(简称为堆性质)： (1) ki≤K2i且ki≤K2i+1 或(2)Ki≥K2i且ki≥K2i+1(1≤i≤ ) 若将此序列所存储的向量R[1..n]看做是一棵完全二叉树的存储结构，则堆实质上是满足如下性质的完全二叉树：树中任一非叶结点的关键字均不大于(或不小于)其左右孩子(若存在)结点的关键字。 【例】关键字序列(10，15，56，25，30，70)和(70，56，30，25，15，10)分别满足堆性质(1)和(2)，故它们均是堆，其对应的完全二叉树分别如小根堆示例和大根堆示例所示。 2、大根堆和小根堆 根结点(亦称为堆顶)的关键字是堆里所有结点关键字中最小者的堆称为小根堆。 根结点(亦称为堆顶)的关键字是堆里所有结点关键字中最大者，称为大根堆。 注意： ①堆中任一子树亦是堆。 ②以上讨论的堆实际上是二叉堆(Binary Heap)，类似地可定义k叉堆。 3、堆排序特点 堆排序(HeapSort)是一树形选择排序。 堆排序的特点是：在排序过程中，将R[l..n]看成是一棵完全二叉树的顺序存储结构，利用完全二叉树中双亲结点和孩子结点之间的内在关系【参见二叉树的顺序存储结构】，在当前无序区中选择关键字最大(或最小)的记录。 4、堆排序与直接插入排序的区别 直接选择排序中，为了从R[1..n]中选出关键字最小的记录，必须进行n-1次比较，然后在R[2..n]中选出关键字最小的记录，又需要做n-2次比较。事实上，后面的n-2次比较中，有许多比较可能在前面的n-1次比较中已经做过，但由于前一趟排序时未保留这些比较结果，所以后一趟排序时又重复执行了这些比较操作。 堆排序可通过树形结构保存部分比较结果，可减少比较次数。 5、堆排序 堆排序利用了大根堆(或小根堆)堆顶记录的关键字最大(或最小)这一特征，使得在当前无序区中选取最大(或最小)关键字的记录变得简单。 （1）用大根堆排序的基本思想 ① 先将初始文件R[1..n]建成一个大根堆，此堆为初始的无序区 ② 再将关键字最大的记录R[1](即堆顶)和无序区的最后一个记录R[n]交换，由此得到新的无序区R[1..n-1]和有序区R[n]，且满足R[1..n-1].keys≤R[n].key ③ 由于交换后新的根R[1]可能违反堆性质，故应将当前无序区R[1..n-1]调整为堆。然后再次将R[1..n-1]中关键字最大的记录R[1]和该区间的最后一个记录R[n-1]交换，由此得到新的无序区R[1..n-2]和有序区R[n-1..n]，且仍满足关系R[1..n-2].keys≤R[n-1..n].keys，同样要将R[1..n-2]调整为堆。 …… 直到无序区只有一个元素为止。 （2）大根堆排序算法的基本操作： ① 初始化操作：将R[1..n]构造为初始堆； ② 每一趟排序的基本操作：将当前无序区的堆顶记录R[1]和该区间的最后一个记录交换，然后将新的无序区调整为堆(亦称重建堆)。 注意： ①只需做n-1趟排序，选出较大的n-1个关键字即可以使得文件递增有序。 ②用小根堆排序与利用大根堆类似，只不过其排序结果是递减有序的。堆排序和直接选择排序相反：在任何时刻，堆排序中无序区总是在有序区之前，且有序区是在原向量的尾部由后往前逐步扩大至整个向量为止。 （3）堆排序的算法： void HeapSort(SeqIAst R) { //对R[1..n]进行堆排序，不妨用R[0]做暂存单元 int i； BuildHeap(R)； //将R[1-n]建成初始堆 for(i=n;i>1；i--){ //对当前无序区R[1..i]进行堆排序，共做n-1趟。 R[0]=R[1]；R[1]=R[i];R[i]=R[0]； //将堆顶和堆中最后一个记录交换 Heapify(R，1，i-1)； //将R[1..i-1]重新调整为堆，仅有R[1]可能违反堆性质 } //endfor } //HeapSort （4） BuildHeap和Heapify函数的实现 因为构造初始堆必须使用到调整堆的操作，先讨论Heapify的实现。 ① Heapify函数思想方法 每趟排序开始前R[l..i]是以R[1]为根的堆，在R[1]与R[i]交换后，新的无序区R[1..i-1]中只有R[1]的值发生了变化，故除R[1]可能违反堆性质外，其余任何结点为根的子树均是堆。因此，当被调整区间是R[low..high]时，只须调整以R[low]为根的树即可。 "筛选法"调整堆 R[low]的左、右子树(若存在)均已是堆，这两棵子树的根R[2low]和R[2low+1]分别是各自子树中关键字最大的结点。若R[low].key不小于这两个孩子结点的关键字，则R[low]未违反堆性质，以R[low]为根的树已是堆，无须调整；否则必须将R[low]和它的两个孩子结点中关键字较大者进行交换，即R[low]与R[large](R[large].key=max(R[2low].key，R[2low+1].key))交换。交换后又可能使结点R[large]违反堆性质，同样由于该结点的两棵子树(若存在)仍然是堆，故可重复上述的调整过程，对以R[large]为根的树进行调整。此过程直至当前被调整的结点已满足堆性质，或者该结点已是叶子为止。上述过程就象过筛子一样，把较小的关键字逐层筛下去，而将较大的关键字逐层选上来。因此，有人将此方法称为"筛选法"。 具体的算法【参见教材】 ②BuildHeap的实现 要将初始文件R[l..n]调整为一个大根堆，就必须将它所对应的完全二叉树中以每一结点为根的子树都调整为堆。 显然只有一个结点的树是堆，而在完全二叉树中，所有序号 的结点都是叶子，因此以这些结点为根的子树均已是堆。这样，我们只需依次将以序号为 ， -1，…，1的结点作为根的子树都调整为堆即可。 具体算法【参见教材】。 5、大根堆排序实例 对于关键字序列(42，13，24，91，23，16，05，88)，在建堆过程中完全二叉树及其存储结构的变化情况参见【动画演示】。 6、 算法分析 堆排序的时间，主要由建立初始堆和反复重建堆这两部分的时间开销构成，它们均是通过调用Heapify实现的。 堆排序的最坏时间复杂度为O(nlgn)。堆排序的平均性能较接近于最坏性能。 由于建初始堆所需的比较次数较多，所以堆排序不适宜于记录数较少的文件。 堆排序是就地排序，辅助空间为O(1)， 它是不稳定的排序方法。

9. 超大文件如何计算md5

首先，至少没必要先把整个文件读到内存里。比如在 php 里，如果有人 md5(file_get_contents(big_file_name)) 就确实非常不妥当。因为 md5 是每 512 bit 作为一个 chunk 进行计算的。所以可以每次读取一部分的内容（最少 512 bit，比较合适是 st_blksize），进行那些 chunk 部分的计算，之后再读取下一部分内容继续计算。简单先说下，md5是有规范的，提供了现成的算法（规范的名字就是md5算法。RFC 1321 The MD5 Message-Digest Algorithm），我们只需要翻译成c、java、python、js等等代码。前端算超大文件可以取头跟尾chunk内容及整个文件的name + update 时间一起算md5值就比较快了，只是为了做唯一标识来做断点续传，从业务逻辑上应该够用了。推荐使用 js spark-md5 开源库，支持直接append各个部分然后算出md5。我做的断点续传功能就是用它在前端算的md5. 各大网盘 TB级别 md5算法应该是这样的，楼上几位都说了文件md5是文件流分块算出来的，那么网盘想获得TB级别文件的md5就必须读取整个文件的文件流才能得到，但是这么做效率十分低下，运算时间是个问题。但是大家忽略了一个问题，文件在上传的过程也是分块上传的，这些上传的碎片其实也是文件流。那么可以把计算md5的时间分摊到每一个碎片上。这样每上传一个片段就计算一点等上传完成了，文件的md5也就算出来了。okTB级别MD5不是问题了。上传完成md5自然就出来了。 不知道我的猜测大家有其他看法没有。刚才提出都传完了就还怎么秒传。秒传最基本的是先要前端算出md5然后传给后端（可能需要更多种哈希值）我研究了很久前端没有办法秒内完成超大文件MD5的，现在用html5 的api 可以算出任意大小文件的 md5 但是耗时相当长。我没有解决办法。也没有想到那些网盘怎么在前端快速获取md5的。

10. 怎么获取大文件的MD5

原理 对MD5算法简要的叙述可以为：MD5以512位分组来处理输入的信息，且每一分组又被划分为16个32位子分组，经过了一系列的处理后，算法的输出由四个32位分组组成，将这四个32位分组级联后将生成一个128位散列值