NEWBT独播软件超市 - NBTxt -- 文本处理大师mini -- 纯文本编辑器版

您的位置：首页 >> NEWBT独播软件超市 >> 主题: NBTxt -- 文本处理大师mini -- 纯文本编辑器版 [回主站] [分站链接]

您的位置：首页 >> NEWBT独播软件超市 >> 主题: NBTxt -- 文本处理大师mini -- 纯文本编辑器版 [最新] [回主站]

标题

NBTxt -- 文本处理大师mini -- 纯文本编辑器版

clq

浏览(528) + 2020-08-26 12:59:31 发表编辑

关键字:

[2020-08-27 19:23:58 最后更新]
NBTxt -- 文本处理大师mini -- 纯文本编辑器版

ps. 其实我最常用的是用它来清除 utf8 文件中的 bom 头(即 windows 记事本中添加的那个不可见的 utf8 文件标志头)和格式化源码中经常会出现的令人头痛的回车换行符。
----

NBTxt 是一款纯文本编辑器。来源于早前笔者略有名气的软件《文本处理大师》，不过作为作者我用《文本处理大师》主要是搜索源码字符串和普通的文本处理，而随着功能越来越多，打开速度也是比较慢。再加上界面上可操作区也比较小，不太适合长期写文字工作。于是将其中的编辑器部分独立出来即为 NBtxt 。这之后又加入了许多纯文字编辑才会用到的功能。

这款软件的编辑器是笔者自主开发的，所以和其他以第三方控件或者系统控件的编辑器不同的是可扩展性几乎无限。不过在使用过程中又发觉太多的功能其实也并不是好事，所以实际上是专注于纯文本编辑的功能。因为扩展后在一些临时的工作场景下没有对应的编辑器就没法用了 -- 这对于 word / excel / wps 这样的编辑器来说也是一样的。所以笔者长久以来一直在苦苦思索：如何能使用普通编辑器进行容易性操作，又能让文字高亮这样的功能能够实现。在传统上解决方案是有的，比如现在很流行的 markdown 格式就是可以兼容纯文本编辑的，更早期的还有 bbcode 这样的。但这些格式的缺陷就是可读取性太差了，而且标志代码混合在纯文本中会很难看。

所以我们最终的解决方案是 CSSText 格式，这个编辑器可以理解为就是这种格式的示例 App 。

CSSText 格式的要点其实只有一个，就是后缀修饰。即扩展标志是写在正常文字的行未的。这样对整个文本的观感没有任何影响。而对文字高度这样的功能实现也没有用什么新语法，就是 css 的小变形罢了，所有的程序员/美工都会的，就是算不是，也很容易学习掌握。

[图片]

含有高速下载地址，但您没有文件高速下载权限。请先开通1元包年会员:
了解/开通会员

clq

2020-08-27 19:23:58 发表编辑

下面我说一下为什么现在这么多编辑器我还要自己一直维护着一个，还是在不挣钱的情况下。

1.
作为多年的程序开发者我其实和大家一样在同时使用着多种纯文本编辑器，包括各个大 IDE 很多时候都是当纯文本编辑器用。因为它们各有自己好用的特性，同时纯文本它们又都能打开。比如微软的 vs 系列的列操作功能很是方便，我是经常用的。读者也许还不知道什么列是列操作，是这样的，在 vs 中按住 ALT 键再选择文本就能选中多行中的其中几列文字，这时可同时删除它们，这在写代码修改了变量名时非常方便 -- 当然还有其他用途。

而我自己的这款则有以下特点（很多啦，这里只是几个常用的）：现在的源码用 utf8 的越来越多了，用 windows 的记事本转换成 utf8 有时候很方便。或者是到客户那里修改页面，没有 ide 顺手也会用记事本临时用一下。总之不管什么原因，项目中总会有 windows 的记事本存过的代码，但这会写入特别的 bom 文件头，在某些环境下这是正常的，在另外一些环境下你会发现页面上莫名其妙的会显示几个不存在的乱码字符。你用所有的编辑器打开一遍，会发现都是正常的呀？其实这时您用我的这个软件打开一下就会发现了，文件前面被加了几个字符。而所有的编辑器都会智能判断忽略掉，这对普通用户很友好，对代码就是灾难（当然现在有些开发环境也会自动忽略）。比如 php 下是肯定会出错的。

我这款软件就是故意设计的让这个文件头显示存在的，除此之外没有其他编辑器会。通常的编辑器，比如在微软 vsc 中，就是在右下角提示。但这样程序员一般都不会注意到，而且很多程序员和知识储备其实不多，甚至根本不知道这代表什么含义，于是他就会调试很久的代码去找是什么原因 ... ... 不要说新手了，我都经常反复犯这个错误，所以这个功能我是一定要做的。

2.
程序员朋友都知道 unix/linux 下的换行和 windows 下的是不同的，很多开发者都是偏 linux ，不过在这上面 windows 的处理是正确的，即完整的 \r\n 。rfc 协议中的换行也是这样的。但很多开发者会固执地使用 unix/linux 风格的 \n ，这种处理风格会在各种编辑器、浏览器、阅读器中出现。当你找到一块代码放到项目中是会出现一个头痛的问题：如果代码中报错，那么报的行数根本和源码对不上！原因其实非常简单，就是不同处理器对换行的理解不同，代码中混杂了两种换行方式时就更容易出现这种情况。更头痛的是绝大多数编辑器打开出现问题的源码再存也不会消除这个问题，因为它们会很智能的保留换行的方式！而我的这款，则是很干脆的直接存为 rfc 标准的 \r\n。这样，这些问题就全部解决了。我一直理解不了一个情况：就是这么简单的一个问题，在 ultraedit 编辑器中也是有明确的这个处理项的，但它的处理就是有问题。我估计是 ultraedit 这些编辑器中对行的分隔做了什么特别的处理，使它一直无法正确的修改这个换行符，也有可能它的开发者没想到有两个换行符混用的情况。

当然编辑器中还有很多我自己需要的功能，不过这两点是我必须保留它的原因，因为大多数编辑器会认为这两点处理上的差异太微小了，它们不会改的。这么多年过去了，一直是如此。

这里也有一个设计思想上的问题，它们认为应该更多的去智能处理。而我认为应该直接先显示原始状态，让用户自己去进行下一步处理。所以打开一个 utf8 文件时大多数编辑器会显示正确的中文，而我们会显示原始的 ansi 乱码，需要用户自己再点一下 utf8 的显示按钮。因为对于我这样的开发者来说，需要知道文件原始的内容。所以也不能说它们的处理方式就不对，这是各自的侧重点不同。

NEWBT官方QQ群1: 276678893
可求档连环画,漫画;询问文本处理大师等软件使用技巧;求档softhub软件下载及使用技巧.
但不可"开车",严禁国家敏感话题,不可求档涉及版权的文档软件.
验证问题说明申请入群原因即可.