怎样处理超长文本的换行【用二进制加载克服emedior换行速度慢的问题】

许一诺 · 发表于 2017-1-30 10:10:41

本帖最后由许一诺于 2017-1-30 20:25 编辑

怎样处理超长文本的换行【用二进制加载克服emedior换行速度慢的问题】

我是针对这样的问题写的：5 O9 H6 @# ~4 s5 N9 V
见sky66在https://www.pdawiki.com/forum/fo ... =%B1%E0%BC%AD%C6%F7的发言
" |' f8 t7 a* J% E“我个人最常使用 EmEditor (LIFETIME 价格约 $120)来处理 mdx 源文件, 主要是有方便的提取功能和批处理, 而且打开大文件速度很快, 最致命的缺点就是正则处理 \n 速度很慢.
8 F1 R/ g8 H9 p# `. d l这时候就要使用免费的 Notepad++ 来代劳处理 \n 了. Notepad++ 处理大档案有时会有一些问题, 而且没有方便的提取功能和批处理, 个人不习惯用来处理 mdx 源文件.5 ?, c& h6 Q j D$ _/ U# t! K0 U, y
UltraEdit, 当然可打开大文件, 正则替换也很快, 但就是打开文件速度有点慢. 还有 Unlimited upgrades 的价格约 $300, 是 EmEditor 的两三倍, 比 Office 还贵, 实在买不下手.' E( P# I8 \ ?- _; B: r- S
还有其他的编辑器, 大多有约略测试一下, 不是不顺手就是难以处理大文件.”

用论坛发许多图不方便，我就把文档输出为图片了，请直接看下面的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有一个快速处理行的转换的功能，就是“保存文件”，每次保存并重新打开为二进制，都会重新排版。

skydan05 · 发表于 2017-1-30 10:32:24

了不起！赞一个！

mingqing007 · 发表于 2017-1-30 15:13:40

本帖最后由 mingqing007 于 2017-1-30 15:15 编辑

哈哈，好办法，感谢分享，回头试试看。

EMEditor处理换行速度确实不佳，Notpad++处理大文件时长处理不完全。

传送门：https://www.pdawiki.com/forum/forum.php?mod=viewthread&tid=19749&page=1&extra=#pid449490

chigre3 · 发表于 2017-1-30 18:34:12

好经验，之前一直用UltraEdit处理大量换行替换

mingqing007 · 发表于 2017-1-30 21:08:54

本帖最后由 mingqing007 于 2017-1-30 21:10 编辑

看到另一种用命令行模式提速换行符处理的的方法。

没有测试过，不知是否好用，也贴在这里吧，留个有心人有时间测试一下：

https://www.emeditor.com/forums/ ... its-very-very-slow/

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The graphical interface seems to slow it down when it’s doing \n or \r or \r\n , etc.0 W3 |- t' p1 Z/ r9 W; t
8 x6 D; ^0 W6 Z0 Q$ `9 F
Make the change from command prompt. I have a 7mb doc that is just numeric CSV data – like this 234, 345, 111, etc. From the command prompt the change to the file is practically instant.
3 V/ Y( _# _- p: K9 u# [# w( T! ?5 P' q# t5 F; u* o! |5 V) x
Here I am replacing comma space with new line.0 F7 E) ^$ [1 Y4 ]

9 T- E: F) ~0 u, N1 ] `& u }c:\emeditor /fi “, ” /x “c:\output2.txt” /rw “\r\n”6 d! d6 h5 i/ C" ?' t9 Z
1 Z8 q& T3 B5 @$ }
It is the same speed to go in the other direction.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

macos6 · 发表于 2017-1-31 11:12:38

chigre3 发表于 2017-1-30 18:34$ Q) U: L2 t" Z P7 i
好经验，之前一直用UltraEdit处理大量换行替换

同意这个；UE处理换行速度没的说。

y8888 · 发表于 2017-2-9 14:13:04

试了一下，对小文件是可以，但对大文件则进不了二进制模式.

onlyXXenglish · 发表于 2017-2-9 15:55:20

各种方法我都用过，最终我的选择是把超大文件分割成多个小文件，再用文本编辑类软件通常都有的“在文件中查找替换”解决换行问题。这样既可以兼顾效率，又能避免文本编辑类软件在编辑超大文件时容易出错的问题。

sky66 · 发表于 2017-2-9 19:21:01

mingqing007 发表于 2017-1-30 21:08
2 v H8 W6 k3 }3 G1 m看到另一种用命令行模式提速换行符处理的的方法。6 ~4 o, ~( } f
7 Z W F4 c" J" W
没有测试过，不知是否好用，也贴在这里吧，留个有心人 ...

之前我有测试过命令行模式, 很可惜..还是很慢.

sky66 · 发表于 2017-2-9 19:49:31

二进制方式我也试过, 的确是有效, 适用于较简单的替换

但处理mdx麻烦的地方在于有些分段比较复杂, 是需要用到正则删除多余的内文与\n
像是网页下来的文本 : <head>\n...<title>...</title>\n...</head>\n...</body>\n</html>\n

如果直接用Emeditor 将 <head>\n 替换为 "空", 须花较长的时间
如果先将 <head> 替换为 "空", 再将 \n 设为"书签" => "删除书签" 的方式, 就会很快..

mingqing007 · 发表于 2017-2-9 19:49:41

sky66 发表于 2017-2-9 19:21
5 O) k% b( z" _之前我有测试过命令行模式, 很可惜..还是很慢.

SublimeText 貌似不存在这个问题. 可以试试看.

deeke · 发表于 2017-2-10 13:25:23

在我的机器上，Sublime Text 打开170MB-200MB的txt还是会卡。今天我准备试试看VSCode。

henices · 发表于 2017-2-10 13:33:45

直接 sed 就可以了，用 perl 也行。

sky66 · 发表于 2017-3-31 17:50:01

今天使用 EmEditor v16.6.0 beta 1 实际测试三百万行的colmdx txt,
</div>\n 替换为</div>
已经有大幅度的改善了.

正则引擎选 Onigmo 又比 Boost.Regex(默认) 更快

greatszh · 发表于 2017-4-30 00:06:10

算是个思路吧，有点胡搞乱搞的瞎折腾的感觉，不知道各位在折腾繁简转换的时候用没用过lopencc,处理几百兆的文件基本秒杀。其中opencc有一个自定义字典的功能，如果各位把想要替换的字符定义到opencc的自定义字典里，看看啥效果？

		自动登录	找回密码
密码			免费注册

[求助] 怎样处理超长文本的换行【用二进制加载克服emedior换行速度慢的问题】

本帖被以下淘专辑推荐:

点评