|
|
本帖最后由 许一诺 于 2017-1-30 20:25 编辑
怎样处理超长文本的换行【用二进制加载克服emedior换行速度慢的问题】
我是针对这样的问题写的：
见sky66在https://www.pdawiki.com/forum/fo ... =%B1%E0%BC%AD%C6%F7的发言
“我个人最常使用 EmEditor (LIFETIME 价格约 $120)来处理 mdx 源文件, 主要是有方便的提取功能和批处理, 而且打开大文件速度很快, 最致命的缺点就是正则处理 \n 速度很慢.
这时候就要使用免费的 Notepad++ 来代劳处理 \n 了. Notepad++ 处理大档案有时会有一些问题, 而且没有方便的提取功能和批处理, 个人不习惯用来处理 mdx 源文件.
UltraEdit, 当然可打开大文件, 正则替换也很快, 但就是打开文件速度有点慢. 还有 Unlimited upgrades 的价格约 $300, 是 EmEditor 的两三倍, 比 Office 还贵, 实在买不下手.
还有其他的编辑器, 大多有约略测试一下, 不是不顺手就是难以处理大文件.”
用论坛发许多图不方便，我就把文档输出为图片了，请直接看下面的5张图：
![]()
![]()
![]()
![]()
![]()
下面是文字说明：
emeditor是非常适合打开超大文件的编辑器，不过它处理换行非常不便。
下面截图中的文档超过1500万行，使用普通方式将\r\n\r\n转换为\r\n（也就是把空两行变成空一行非常慢）
对于这种问题以前有人建议用notepad++处理，其实也还是很慢的（1500万行估计要等10分钟以上）
下面我来说一个快的方法（只需要几秒）
如果在下面这个800万行的文本中把<br>变成\r\n（即将html的换行记号变成文本中的换行）
我们把文档重新载入，用“二进制（十六进制视图）”
文档变成这样：
文本自然的换行完全被打乱。左边是二进制数据，右边是对应的文本（换行符号显示为..（也就是两个点））。
此时我们通过点击右边的文本，了解到：
<br>对应二进制为3C 62 72 3E
\r\n在后边显示为“..”，点击得知，对应二进制0D 0A
此时我们开始替换：
如上图，把“3C 62 72 3E”替换为“0D 0A”，可以看到替换速度极快，如下图：
替换完之后，默认对再搜索一遍有多少个3C 62 72 3E，如下图。
之后文本变成这样（如下图），有些行的长度减少了：
保存文本，需要几秒钟时间：
再重新打开文本（用普通方式打开），可以发现全部<br>都变成了换行。
【总之，我这个方法就是让exeditor避免了普通文本的换行，改为用二进制模式处理，该模式下换行符号体现为普通字符。】
后来发现的问题
可能是因为我选取的文档比较特殊，<br>的二进制代码“3C 62 72 3E”都不跨行。
所以替换中没有问题，实际上可能会出现这样的情况：
文本：
![]()
二进制加载
![]()
注意第4个<br>在换行的位置，这样用替换就处理不到（二进制下不能换行）。
因为“3C 62 72 3E”是四个单位，所以<br>被“中间割断”的情况有4种：4=4+0=3+1=2+2=1+3
我的解决方法是：
1. 给“3C 62 72 3E”替换为“0D 0A”录制一个宏，比如叫做macro.jsee
2. 运行一次宏，保存文本，在文本头加一个“3C”，也就是一个“<”字符。
3. 保存，重新打开，加载为二进制，再运行一次宏。
4. 再重复步骤3两次。
下面我要指出emeditor的几个特点：
1. 按照“行”来处理替换等操作，所以只要不跨行执行速度就快（比如“抽取符合条件的行”），跨行就慢。
2. 但是如果一行非常长，处理起来也会很慢，比如把一个几千万行的文本换行全部取消变成一个一行的文件再执行替换操作。
3. 综上，emeditor擅长处理每行不是非常长（不达到几十万个字符），但是行数特别多的文本。
4. emeditor有一个快速处理行的转换的功能，就是“保存文件”，每次保存并重新打开为二进制，都会重新排版。
|
本帖被以下淘专辑推荐:
- · 图片词典制作|主题: 41, 订阅: 6
- · 工具|主题: 8, 订阅: 5
|
发表于 2017-1-30 10:10:41
发表于 2017-2-10 13:25:23