无忧启动论坛

标题: 解决UD乱码之源，支持命令行格式UD区为utf-8格式的fbinst和fbinst Plus来了！ [打印本页]

作者: zds1210 时间: 2017-3-4 01:16
标题: 解决UD乱码之源，支持命令行格式UD区为utf-8格式的fbinst和fbinst Plus来了！
本帖最后由 zds1210 于 2017-3-15 18:29 编辑

长期以来，因ansi和utf格式存在，经常导致UD区中文文件名乱码，
这些特请这方面的专家百草霜出山，改进原版fbinst和fb加强版fbinst plus，
强制格式UD区为uft8格式，支持导入utf8格式的fba。强制废除UD区和fba文件的ansi格式，统一为utf8格式，终结UD乱码之源!!!
这是UD三分区一键制作又一个重要里程碑，UD一键编程制作的朋友有福了。升级一下你的UD一键制作核心fbinst或fbinst plus，问题就解决了。
utf8格式的UD区外置加载，建议用百大改进的对utf8格式导出兼容性好的fbinst plus。

乱码原因详解：

1改进的uft8版fbinst和fbinst plus，经百大反复折腾，大大完善了。在附件中下载。
老版本的fbinst和fbinst plus，详见原帖子：http://bbs.wuyou.net/forum.php?mod=viewthread&tid=187865

2无损制作cmd脚本模块使用说明：下载模块后用cmd脚本制作，看新版的fbinst或fbinst plus是不是格式ＵＤ区为utf8格式，用fbinstool查看有没有乱码。
初步测试成功。

3支持Utf8版格式的新UD三分区一键制作cmd和默默程序成品PE合盘测试版：
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=370703&extra=

无损制作UD三分区cmd模块20170305U版.7z

2.5 MB, 下载次数: 578, 下载积分: 无忧币 -2

fb1.63和fbp1.4

Fbinst&Plus_1.5.1703.5.zip

73.26 KB, 下载次数: 189, 下载积分: 无忧币 -2

fb1.6.4和fbp1.5

fbplus1.5.1703.13.zip

45.57 KB, 下载次数: 94, 下载积分: 无忧币 -2

fbp1.5.1703

fbplus1.5.1703.9.zip

42.94 KB, 下载次数: 66, 下载积分: 无忧币 -2

fbinst1.6.3& fbp1.4.rar

63.16 KB, 下载次数: 163, 下载积分: 无忧币 -2

fb1.63和fbp1.4

作者: zengqcyxx 时间: 2017-3-4 01:22

{:2_133:}

作者: 青青草 时间: 2017-3-4 01:43
期待早日分享！

作者: 窄口牛 时间: 2017-3-4 07:22
支持动手，赞扬分享

作者: Anson4 时间: 2017-3-4 08:08
感谢大神做出的努力！

作者: Plantsoot 时间: 2017-3-4 08:14

我等着下载最新版的三分区合盘呢，那么晚还没睡，辛苦啦。加油！

作者: lwslin 时间: 2017-3-4 08:14
这个必须要支持，多谢分享好资源！

作者: 不知 时间: 2017-3-4 08:58
期待下载链接。

作者: l3429900 时间: 2017-3-4 14:40
原来就是2种标准，ansi也该淘汰了

作者: zds1210 时间: 2017-3-5 16:16
已经发布了一个cmd脚本模块，供大家测试。
晚上发布utf8版的无损制作标准UD三分区cmd脚本和默默程序版合盘。

作者: Anson4 时间: 2017-3-5 16:54
菜鸟对UD3分区了解甚少，请问有啥优点？有科普贴吗？

作者: zds1210 时间: 2017-3-5 16:59

Anson4 发表于 2017-3-5 16:54
菜鸟对UD3分区了解甚少，请问有啥优点？有科普贴吗？

查一下，我有这方面的帖子。
UD乱码问题，不是菜鸟的事，主要是UDPE和编程制作上使用的。

作者: Anson4 时间: 2017-3-5 17:15

zds1210 发表于 2017-3-5 16:59
查一下，我有这方面的帖子。
UD乱码问题，不是菜鸟的事，主要是UDPE和编程制作上使用的。

谢谢！

作者: zds1210 时间: 2017-3-5 17:22

Anson4 发表于 2017-3-5 17:15
谢谢！

但乱码的问题，UD用户体验最深。

作者: zds1210 时间: 2017-3-5 18:46

l3429900 发表于 2017-3-4 14:40
原来就是2种标准，ansi也该淘汰了

是的，两种编码，命令行制作，手工制作，弄来弄去就乱码了。
所以，只能选择一种编程格式，utf8先进，就选它，废掉ansi，
天下一统，不乱码，清静世界。

作者: wintoflash 时间: 2017-3-5 19:08
本帖最后由 wintoflash 于 2017-3-5 23:06 编辑

utf-8好啊。

作者: 2010WyUser 时间: 2017-3-5 21:52
支持一下

作者: lbw2007 时间: 2017-3-5 23:01
支持一下！一直在用20140513最后一版支持ansi的fbinsttool。

作者: zds1210 时间: 2017-3-6 12:12

lbw2007 发表于 2017-3-5 23:01
支持一下！一直在用20140513最后一版支持ansi的fbinsttool。

升级一下fb，以后制作的U盘就可以用最新版fbinstool了。

作者: zds1210 时间: 2017-3-6 12:26
本帖最后由 zds1210 于 2017-3-6 12:58 编辑

Anson4 发表于 2017-3-5 16:54
菜鸟对UD3分区了解甚少，请问有啥优点？有科普贴吗？

有关UD三分区的帖子很多，新手注意搜索下。
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=346029

作者: myBOOT 时间: 2017-3-6 12:33
厉害。看看效果。

作者: 青青草 时间: 2017-3-6 12:53
谢谢分享！

作者: Anson4 时间: 2017-3-6 12:56

zds1210 发表于 2017-3-6 12:26
有关UD三分区的帖子很多，菜鸟注意搜索下。
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=346029 ...

谢谢！

作者: 贝壳iT 时间: 2017-3-6 15:04
昨晚上的 Fbinst&Plus_1.5.1703.5.zip，有问题，旧版OK

作者: zds1210 时间: 2017-3-6 15:26

贝壳iT 发表于 2017-3-6 15:04
昨晚上的 Fbinst&Plus_1.5.1703.5.zip，有问题，旧版OK

什么问题，发来给百大修正。

作者: 贝壳iT 时间: 2017-3-6 15:27

zds1210 发表于 2017-3-6 15:26
什么问题，发来给百大修正。

UTF8模式下制作UD中文乱码。你可以试试。我只是好奇看了看

作者: 贝壳iT 时间: 2017-3-6 15:34
本帖最后由贝壳iT 于 2017-3-6 15:37 编辑

zds1210 发表于 2017-3-6 15:26
什么问题，发来给百大修正。

刚才还看了下
fbinst (hd3) add 打你.txt 打你.txt 也会乱码。
如果 fbinst (hd3) add test.txt test.txt 则OK
看样子相关的其他命令都应该遗忘了。

作者: zds1210 时间: 2017-3-6 15:37

贝壳iT 发表于 2017-3-6 15:34
刚才还看了下
fbinst (hd3) add 打你.txt 打你.txt 也会乱码。
如果 fbinst (hd3) add test.txt test.t ...

是原版的fbinst还是改进的fbinst Plus。说清楚。好叫百大修正

作者: 享β亻寸木东 时间: 2017-3-6 16:01
感谢各位大神辛苦劳动！！！

作者: 贝壳iT 时间: 2017-3-6 18:58

zds1210 发表于 2017-3-6 15:37
是原版的fbinst还是改进的fbinst Plus。说清楚。好叫百大修正

fbinst Plus
原版没测试

作者: Plantsoot 时间: 2017-3-6 20:00
本帖最后由 Plantsoot 于 2017-3-6 20:12 编辑

贝壳iT 发表于 2017-3-6 15:34
刚才还看了下
fbinst (hd3) add 打你.txt 打你.txt 也会乱码。
如果 fbinst (hd3) add test.txt test.t ...

不会吧，我反复测试了几次的……
用fbinsttool截个图看看。

作者: 贝壳iT 时间: 2017-3-6 20:23
本帖最后由贝壳iT 于 2017-3-6 20:36 编辑

Plantsoot 发表于 2017-3-6 20:00
不会吧，我反复测试了几次的……
用fbinsttool截个图看看。

详细点。
Fbinst version : 1.6 build 4
FbPlus version : 1.5.1703.5这个版本 -V感觉比较流畅的输出info信息。其他没测试
这个版本的fbinst 单独导入导出中文名称文件到FBA或者U盘UD分区都是正常的不乱码。但是全新制作格式化出UD并写入FBA数据到UD会乱码。

然后
Fbinst version : 1.6 build 2
Plus version : 1.4.1703.03
而这个输出版本号 -V 感觉卡顿。
这个版本是全部都OK得，没有乱码的情况，测试环境步骤一样。

方便测试我上传FBA了

TEST.7z

37.77 KB, 下载次数: 4, 下载积分: 无忧币 -2

作者: Plantsoot 时间: 2017-3-6 20:37
本帖最后由 Plantsoot 于 2017-3-6 20:38 编辑

贝壳iT 发表于 2017-3-6 20:23
详细点。
Fbinst version : 1.6 build 4
FbPlus version : 1.5.1703.5

有点乱了……
按理说，不管是否有UTF-8标记，新版fbinsttool（1.607之后的）和fbplus1.5都不应该会乱码。
我现在有点晕了。

我大概知道了，你是说导入fba之后乱码，单独导入文件不乱码对吗？

作者: 贝壳iT 时间: 2017-3-6 20:38

Plantsoot 发表于 2017-3-6 20:37
有点乱了……
按理说，不管是否有UTF-8标记，新版fbinsttool（1.607之后的）和fbplus1.5都不应该会乱码 ...

我后面改了反馈你再看下，前面的确回复得有点问题。
后面我再详细测试得出结论

作者: 贝壳iT 时间: 2017-3-6 20:40

Plantsoot 发表于 2017-3-6 20:37
有点乱了……
按理说，不管是否有UTF-8标记，新版fbinsttool（1.607之后的）和fbplus1.5都不应该会乱 ...

对，差不多就是导入FBA乱码，导入文件不乱码。应该是这样子了。你可以下载附件用那个新版的fbinst plus测试下

作者: zds1210 时间: 2017-3-6 20:42

贝壳iT 发表于 2017-3-6 20:23
详细点。
Fbinst version : 1.6 build 4
FbPlus version : 1.5.1703.5这个版本 -V感觉比较流畅的输出in ...

我看了一下你的fba包，是ansi格式，如果导入utf8的UD区，当然会乱码。
用老版本的fbinstool转换fba包为utf8格式再试下。

作者: zds1210 时间: 2017-3-6 20:42

贝壳iT 发表于 2017-3-6 20:23
详细点。
Fbinst version : 1.6 build 4
FbPlus version : 1.5.1703.5这个版本 -V感觉比较流畅的输出in ...

我看了一下你的fba包，是ansi格式，如果导入utf8的UD区，当然会乱码。
用老版本的fbinstool转换fba包为utf8格式再试下。

作者: 贝壳iT 时间: 2017-3-6 20:46
本帖最后由贝壳iT 于 2017-3-6 20:48 编辑

zds1210 发表于 2017-3-6 20:42
我看了一下你的fba包，是ansi格式，如果导入utf8的UD区，当然会乱码。
用老版本的fbinstool转换fba包为u ...

我今天用新版的fbinstool1.607.2015.0203已经没有转换编码选择，我看作者介绍现在默认就是UTF格式。2014的那个fbinstool支持编码转换是真的。我以为是旧版识别新版的FBA识别错误，其实已经是UTF格式，不过还是郁闷。因为同样的FBA
Fbinst version : 1.6 build 2
Plus version : 1.4.1703.03
这个版本的制作时没乱码的
另外不管新版旧版的 fbinstool UI版本导入FBA都正常，只是命令行下有问题

作者: Plantsoot 时间: 2017-3-6 20:56
本帖最后由 Plantsoot 于 2017-3-6 20:59 编辑

贝壳iT 发表于 2017-3-6 20:46
我今天用新版的fbinstool1.607.2015.0203已经没有转换编码选择，我看作者介绍现在默认就是UTF格式。201 ...

FbPlus version : 1.5.1703.5 版本我改动了原版fbinst，也就是说原版load命令是否因为我修改了代码，引出了BUG，刚才我发现你给我的test.fba的文件列表好像不是UTF-8编码。
一会我把我的U盘清空，重新测试吧。

作者: 贝壳iT 时间: 2017-3-6 21:02

Plantsoot 发表于 2017-3-6 20:56
FbPlus version : 1.5.1703.5 版本我改动了原版fbinst，也就是说原版load命令是否因为我修改了代码，引 ...

嗯编码问题我还是用旧版的fbinstool制作FBA 顺便也能直观确认编码格式是否为UTF-8
最新2015那个fbinstool没有转换编码的选项，看更新支持UTF-8 我以为已经弃用ANSI 强制UTF-8

版本
Fbinst version : 1.6 build 2
Plus version : 1.4.1703.03
制作时正常的。不知是否可以再看看，可以兼顾下两种格式。

作者: Plantsoot 时间: 2017-3-6 21:07

贝壳iT 发表于 2017-3-6 21:02
嗯编码问题我还是用旧版的fbinstool制作FBA 顺便也能直观确认编码格式是否为UTF-8
最新2015那个fbinstoo ...

正在看代码，代码量有点大，之前只测试了 info、add、remove、export，并没有测试load和save这两个命令。我先整理下我的U盘，然后再测试吧，ANSI和UTF-8相互转换，绕来绕去，有点复杂，我已经绕晕了……

作者: 贝壳iT 时间: 2017-3-6 21:09

Plantsoot 发表于 2017-3-6 21:07
正在看代码，代码量有点大，之前只测试了 info、add、remove、export，并没有测试load和save这两个命令。 ...

哈哈，是的代码多了，头昏眼花。辛苦了。
我电脑屏幕1440X900也是恼火，准备换个大屏。

作者: Plantsoot 时间: 2017-3-6 21:19

贝壳iT 发表于 2017-3-6 21:09
哈哈，是的代码多了，头昏眼花。辛苦了。
我电脑屏幕1440X900也是恼火，准备换个大屏。

我把我的U盘的ud区清空了，没有乱码……
测试结果如下：

等下，我这个fba是 ANSI……

作者: 贝壳iT 时间: 2017-3-6 21:20

Plantsoot 发表于 2017-3-6 21:07
正在看代码，代码量有点大，之前只测试了 info、add、remove、export，并没有测试load和save这两个命令。 ...

我还发现 FbinstTool_V1.607.2015.0203 制作的FBA，默认是ANSI，但是他自己FbinstTool_V1.607.2015.0203是可以识别的，也不乱码。

但是用FbinstTool_V1.607.2014.0507 打开就FBA看是乱码，格式显示ANSI，转换UTF-8后还是乱码。

这个时候再用FbinstTool_V1.607.2015.0203 查看，也乱码了，这个FBA就没救了。
看来这两个版本的工具最好不要混用。

因此命令行fbint plus，能改善支持两种编码更好，不能也不为过，因为FbinstTool创建FBA他本来就是昏呼呼的。

作者: 贝壳iT 时间: 2017-3-6 21:21

Plantsoot 发表于 2017-3-6 21:19
我把我的U盘的ud区清空了，没有乱码……
测试结果如下：

我已经晕了

作者: Plantsoot 时间: 2017-3-6 21:24

贝壳iT 发表于 2017-3-6 21:21
我已经晕了

确实有问题……

作者: 贝壳iT 时间: 2017-3-6 21:28

Plantsoot 发表于 2017-3-6 21:24
确实有问题……

估计你还的看看最新版本号的fbinst，虽然UI版本也有点迷迷糊糊，但是你这确实存在问题。
刚才创建了一个 UTF-8格式的 FBA，从创建UD分区到导入FBA，步骤不变，看U盘UD区中文的确乱码了、

作者: zds1210 时间: 2017-3-6 21:32

贝壳iT 发表于 2017-3-6 21:20
我还发现 FbinstTool_V1.607.2015.0203 制作的FBA，默认是ANSI，但是他自己FbinstTool_V1.607.2015.0203 ...

我也发现了，貌似j大后来的版本，编码格式有一点乱。

作者: Plantsoot 时间: 2017-3-6 21:33

贝壳iT 发表于 2017-3-6 21:28
估计你还的看看最新版本号的fbinst，虽然UI版本也有点迷迷糊糊，但是你这确实存在问题。
刚才创建了一个 ...

你创建一个ANSI编码的fba，就不乱了，呵呵呵呵

作者: 贝壳iT 时间: 2017-3-6 21:41

Plantsoot 发表于 2017-3-6 21:33
你创建一个ANSI编码的fba，就不乱了，呵呵呵呵

我只是看到更新，好奇测试了一下。我还不知道文件编码为什么一定要utf8呢，ansi不是也可以中文的嘛。
另外两种编码对引导兼容是否有影响，新版fbinst，看标题是分区表项法专用版本。只有ansi应该有原因吧

作者: zds1210 时间: 2017-3-6 21:46

贝壳iT 发表于 2017-3-6 21:41
我只是看到更新，好奇测试了一下。我还不知道文件编码为什么一定要utf8呢，ansi不是也可以中文的嘛。
另 ...

这个fbinst，是为格式UD区专用的，可以用于纯UD，UD三分区和UD分区表项。
J大很早的版本，不管你的fba什么格式，全部强制转换为utf8，也没有报告兼容性的问题。
而UD两种格式，ansi和utf8，是造成UD中文乱码之源。就应该统一为一格式，而utf8比较先进，
就应该统一为utf8，废掉ansi，从此不乱码，清静世界。

作者: zds1210 时间: 2017-3-6 21:52
发现一个非常有意思的事，用废掉ansi格式的新版fbinstool，强格式出一个新UD区，并在格式化中勾选utf8的fba中，在格式化中同时写入这个fba。
在新版本的fbinstool中无乱码。在支持ansi格式的老版本fbinstool中看，却是中文乱码，显示也是ansi格式。

作者: 贝壳iT 时间: 2017-3-6 21:56

zds1210 发表于 2017-3-6 21:52
发现一个非常有意思的事，用废掉ansi格式的新版fbinstool，强格式出一个新UD区，并在格式化中勾选utf8的fb ...

有点乱了。洗洗睡了再来梳理下

作者: zds1210 时间: 2017-3-6 21:57
再深入测试，用废掉ansi格式的新版fbinstool，强格式出一个新UD区，按理说是utf8格式；在支持ansi格式的老版本fbinstool中看，显示的却是ansi格式。这个格式到底是什么格式？J大自己貌似都糊涂了吧？
貌似新版本的fbinstool自己有问题，ansi和utf8自己都没有分清楚。

作者: Plantsoot 时间: 2017-3-7 08:42
昨天凌晨1点半，测试 create 命令，悲剧的是写的是 fbinst (hd3) create ，写错了，不是这样写的，U盘被当成一个fba文件创建（修改）了。数据全毁，除非手工去修复。
正确的写法应该是 fbinst ARFILE create
数据无价，操作需谨慎……

作者: 贝壳iT 时间: 2017-3-7 08:56

Plantsoot 发表于 2017-3-7 08:42
昨天凌晨1点半，测试 create 命令，悲剧的是写的是 fbinst (hd3) create ，写错了，不是这样写的，U盘被当 ...

fbinst (hd1) load C:/grldr
上面命令是将c:盘根目录下的grldr文件导入U盘前面8M的隐藏空间内。
或
fbinst (hd1) load grldr
上面命令是导入当前目录下的grldr文件。

4，还有一些其他命令：

fbinst (hd1) info
显示mbr里的信息

fbinst (hd1) clear
清除原来load的映像，于是可以使用load载入新的映像。也即，在load新的映像前，需要先使用clear清除原来的映像。

所以那个测试包里面的test没有错，貌似就是导入fba到hd3，难道我发错了？你可以再看看复制上来，我手机无法附件

作者: jianliulin 时间: 2017-3-7 09:40
本帖最后由 jianliulin 于 2017-3-7 09:47 编辑

原来还有人在用fbinst啊，我以为没有什么人在用了。我现在说说乱码的根源：

1.原来fbinst的文件列表只支持ansi编码，后来我在fbinst一处预留的地方做了个标记，以便标示ud的文件列表是ansi还是utf-8，所以早期fbt就有ansi转utf-8的功能，过了几千年之后grub4dos菜单也改为utf-8编码，当加载了中文字库的grldr查看ansi编码的ud时会乱码的，utf-8则不乱码，所以我就把fbt废除了ansi。没有转换功能的fbt都默认是utf-8编码，之前我占用的标记也释放掉，把位置腾出来以便其他需要使用的人使用，所以造成了早期的fbt把utf-8编码误认为是ansni，导致用早期的fbt查看最新的ud乱码。我已经和百大讨论过这个问题了。

Q群：49405566
此群目前没有人再讨论fbinst了，但它是fbinst/0pen发展与普及的摇篮,很多老鸟都在里面。

作者: 贝壳iT 时间: 2017-3-7 09:59

jianliulin 发表于 2017-3-7 09:40
原来还有人在用fbinst啊，我以为没有什么人在用了。我现在说说乱码的根源：

1.原来fbinst的文件列表只支 ...

原来如此。

作者: chiannet 时间: 2017-3-7 11:59

jianliulin 发表于 2017-3-7 09:40
原来还有人在用fbinst啊，我以为没有什么人在用了。我现在说说乱码的根源：

1.原来fbinst的文件列表只支 ...

J大，下面的代码，在delphi7及delphi 2010下分别编译得到的MD5c.exe，运行

MD5c.exe "字符串"

所得结果不一致。请帮修改一下，让delphi 2010下编译的MD5c.exe与delphi 7下编译的MD5c.exe

在对任意字符串md5加密计算所得结果一致。

MD5cr_cons.7z (22.14 KB, 下载次数: 5)

作者: jianliulin 时间: 2017-3-7 12:49

chiannet 发表于 2017-3-7 11:59
J大，下面的代码，在delphi7及delphi 2010下分别编译得到的MD5c.exe，运行

MD5c.exe "字符串"

我修改了一下，你测试看看有没有问题：

MD5cr_cons.rar (130.09 KB, 下载次数: 2)

作者: chiannet 时间: 2017-3-7 13:02
本帖最后由 chiannet 于 2017-3-7 13:11 编辑

jianliulin 发表于 2017-3-7 12:49
我修改了一下，你测试看看有没有问题：

不一致

md5c.exe chiannet
$1$4$fjdJqMLSmFl5g5UzyZ4Qo.

不是预期的：
$1$4$j5UrjZKvMnZ8J0BtO14ZY0

作者: chiannet 时间: 2017-3-7 13:11

jianliulin 发表于 2017-3-7 12:49
我修改了一下，你测试看看有没有问题：

不一致

md5c.exe chiannet
$1$4$fjdJqMLSmFl5g5UzyZ4Qo.

不是预期的：
$1$4$j5UrjZKvMnZ8J0BtO14ZY0

作者: jianliulin 时间: 2017-3-7 14:33
上传你预期的工具。

作者: 贝壳iT 时间: 2017-3-7 15:08
本帖最后由贝壳iT 于 2017-3-7 15:14 编辑

@Plantsoot

jianliulin 发表于 2017-3-7 14:33
上传你预期的工具。

仍然是有BUG的。
此FBA是新版创建，也就是UTF-8编码

使用命令"
fbplus (hd3) format --force --extended 512m --align --fat32 --primary 8m
fbplus (hd3) load 我们.fba

test.7z (35.82 KB, 下载次数: 0)

作者: jianliulin 时间: 2017-3-7 15:17

贝壳iT 发表于 2017-3-7 15:08
@Plantsoot

仍然是有BUG的。

fbplus 是百草的，我不清楚。你需要找他，我说的新版是，fbinsttool的新版。

作者: tiansw1 时间: 2017-3-7 15:24
很久之前就纠结个这个问题。至今仍保留着fbinstool的多个版本。现在看到大神们又开始改进了。搜了一篇关于编码的文章。补补自己，也给各位伸手党解解惑。
关于编码ansi、GB2312、unicode与utf-8的区别

终于对编码有一定的认识，一说编码，就tmd的恶心。

关于编码ansi、GB2312、unicode与utf-8的区别
先做一个小小的试验：
在一个文件夹里，把一个txt文本（文本里包含“今天的天气非常好”这句话）分别另存为ansi、unicode、utf-8这三种编码的txt文件。然后，在该文件夹上点击右键，选择“搜索(E)…”。
搜索“天气”二字，可以搜索出ansi和unicode这两种编码的txt文件，搜索不出utf-8编码的文件。
原因：
1.中文操作系统默认ansi编码，生成的txt文件默认为ansi编码，所以，可以搜索出来。
2.unicode是国际通用编码，所以，可以搜索出来。
3.utf-8编码是unicode编码在网络之间（主要是网页）传输时的一种“变通”和“桥梁”编码。utf-8在网络之间传输时可以节约数据量。所以，使用操作系统无法搜索出txt文本。

按照utf-8创始人的愿望：
端（unicode）——传输（utf-8）——端（unicode）

但是，后来，许多网站开发者在开发网页时直接使用utf-8编码。
端（utf-8）——传输（utf-8）——端（utf-8）

所以，在浏览器上看到的编码是：unicode（utf-8）。正因为在浏览器上这么并列地列出unicode（utf-8），造成许多网友（甚至不少程序员）误认为unicode=utf-8。其实，按照utf-8创始人的原意，在开发网页时使用utf-8编码是错误的做法，并且，早期的浏览器也不支持解析utf-8编码。但是，众人的力量是巨大的，微软不得不“趋炎附势”，在浏览器上支持解析utf-8编码。

问题是：utf-8编码影响了网站开发者，或者说，网站开发者“扩展”了utf-8编码的使用范围。但是，网站开发者仍然无法影响各类文档的开发者，所以，word文档和一些国际通用的文档仍然使用unicode编码而不使用utf-8编码。

比如：“严”的Unicode码是4E25，UTF-8编码是E4B8A5，两者是不一样的。

在中文和日文操作系统里生成的（txt和xml）文件的编码虽然都是ansi，但是，在简体中文系统下，ansi 编码代表 GB2312 编码，在日文操作系统下，ansi 编码代表 JIS 编码。不同 ansi 编码之间互不兼容，当信息在国际间交流时，无法将属于两种语言的文字，存储在同一段 ansi 编码的文本中。

结论：国际文档（txt和xml）使用unicode编码是正宗做法；操作系统和浏览器都能够“理解”unicode编码。浏览器“迫于压力”才“理解”utf-8编码。但是，操作系统有时只认unicode编码。
Unicode与Unicode big endian的区别：你吃鸡蛋时先吃小头还是先吃大头？Unicode与Unicode big endian的区别就是在编码时小头优先与大头优先的区别。“随波逐流”使用Unicode就OK了。
我（不是程序员）这几年一直因为编码问题，感到非常困惑，查了许多资料，在国际文档的实际应用中也遇到过许多问题，所以，“感性”地总结了上述观点，不一定准确（或者说，不一定正确）。
企业级项目实战(带源码)地址：http://zz563143188.iteye.com/blog/1825168
收集五年的开发资料下载地址： http://pan.baidu.com/share/link? ... 0%E6%96%87%E4%BB%B6
http://wenku.baidu.com/view/a651b849f7ec4afe04a1df9f.html
Unicode、UTF－8 和 ISO8859-1到底有什么区别
1.本文主要包括以下几个方面：编码基本知识，Java，系统软件，url，工具软件等。

在下面的描述中，将以"中文"两个字为例，经查表可以知道其GB2312编码是"d6d0 cec4"，Unicode编码为"4e2d 6587"，UTF编码就是"e4b8ad e69687"。注意，这两个字没有iso8859-1编码，但可以用iso8859-1编码来"表示"。
在下面的描述中，将以"中文"两个字为例，经查表可以知道其GB2312编码是"d6d0 cec4"，Unicode编码为"4e2d 6587"，UTF编码就是"e4b8ad e69687"。注意，这两个字没有iso8859-1编码，但可以用iso8859-1编码来"表示"。
2. 编码基本知识

最早的编码是iso8859-1，和ascii编码相似。但为了方便表示各种各样的语言，逐渐出现了很多标准编码，重要的有如下几个。

2.1. iso8859-1 通常叫做Latin-1

属于单字节编码，最多能表示的字符范围是0-255，应用于英文系列。比如，字母a的编码为0x61=97。

很明显，iso8859-1编码表示的字符范围很窄，无法表示中文字符。但是，由于是单字节编码，和计算机最基础的表示单位一致，所以很多时候，仍旧使用iso8859-1编码来表示。而且在很多协议上，默认使用该编码。比如，虽然"中文"两个字不存在iso8859-1编码，以gb2312编码为例，应该是"d6d0 cec4"两个字符，使用iso8859-1编码的时候则将它拆开为4个字节来表示："d6 d0 ce c4"（事实上，在进行存储的时候，也是以字节为单位处理的）。而如果是UTF编码，则是6个字节"e4 b8 ad e6 96 87"。很明显，这种表示方法还需要以另一种编码为基础。
2.2. GB2312/GBK

这就是汉子的国标码，专门用来表示汉字，是双字节编码，而英文字母和iso8859-1一致（兼容iso8859-1编码）。其中gbk编码能够用来同时表示繁体字和简体字，而gb2312只能表示简体字，gbk是兼容gb2312编码的。
2.3. unicode

这是最统一的编码，可以用来表示所有语言的字符，而且是定长双字节（也有四字节的）编码，包括英文字母在内。所以可以说它是不兼容iso8859-1编码的，也不兼容任何编码。不过，相对于iso8859-1编码来说，uniocode编码只是在前面增加了一个0字节，比如字母a为"00 61"。

需要说明的是，定长编码便于计算机处理（注意GB2312/GBK不是定长编码），而unicode又可以用来表示所有字符，所以在很多软件内部是使用unicode编码来处理的，比如java。
2.4. UTF

考虑到unicode编码不兼容iso8859-1编码，而且容易占用更多的空间：因为对于英文字母，unicode也需要两个字节来表示。所以unicode不便于传输和存储。因此而产生了utf编码，utf编码兼容iso8859-1编码，同时也可以用来表示所有语言的字符，不过，utf编码是不定长编码，每一个字符的长度从1-6个字节不等。另外，utf编码自带简单的校验功能。一般来讲，英文字母都是用一个字节表示，而汉字使用三个字节。

注意，虽然说utf是为了使用更少的空间而使用的，但那只是相对于unicode编码来说，如果已经知道是汉字，则使用GB2312/GBK无疑是最节省的。不过另一方面，值得说明的是，虽然utf编码对汉字使用3个字节，但即使对于汉字网页，utf编码也会比unicode编码节省，因为网页中包含了很多的英文字符。
3. java对字符的处理

在java应用软件中，会有多处涉及到字符集编码，有些地方需要进行正确的设置，有些地方需要进行一定程度的处理。

3.1. getBytes(charset)

这是java字符串处理的一个标准函数，其作用是将字符串所表示的字符按照charset编码，并以字节方式表示。注意字符串在java内存中总是按unicode编码存储的。比如"中文"，正常情况下（即没有错误的时候）存储为"4e2d 6587"，如果charset为"gbk"，则被编码为"d6d0 cec4"，然后返回字节"d6 d0 ce c4"。如果charset为"utf8"则最后是"e4 b8 ad e6 96 87"。如果是"iso8859-1"，则由于无法编码，最后返回 "3f 3f"（两个问号）。
3.2. new String(charset)

这是java字符串处理的另一个标准函数，和上一个函数的作用相反，将字节数组按照charset编码进行组合识别，最后转换为unicode存储。参考上述getBytes的例子，"gbk" 和"utf8"都可以得出正确的结果"4e2d 6587"，但iso8859-1最后变成了"003f 003f"（两个问号）。

因为utf8可以用来表示/编码所有字符，所以new String( str.getBytes( "utf8" ), "utf8" ) === str，即完全可逆。
3.3. setCharacterEncoding()

该函数用来设置http请求或者相应的编码。

对于request，是指提交内容的编码，指定后可以通过getParameter()则直接获得正确的字符串，如果不指定，则默认使用iso8859-1编码，需要进一步处理。参见下述"表单输入"。值得注意的是在执行setCharacterEncoding()之前，不能执行任何getParameter()。Java doc上说明：This method must be called prior to reading request parameters or reading input using getReader()。而且，该指定只对POST方法有效，对GET方法无效。分析原因，应该是在执行第一个getParameter()的时候，java将会按照编码分析所有的提交内容，而后续的getParameter()不再进行分析，所以setCharacterEncoding()无效。而对于GET方法提交表单是，提交的内容在URL中，一开始就已经按照编码分析所有的提交内容，setCharacterEncoding()自然就无效。
4.iso-8859-1是JAVA网络传输使用的标准字符集,而gb2312是标准中文字符集,当你作出提交表单等需要网络传输的操作的时候,就需要把 iso-8859-1转换为gb2312字符集显示,否则如果按浏览器的gb2312格式来解释iso-8859-1字符集的话,由于2者不兼容,所以会是乱码.
转自http://hi.baidu.com/libo20475/bl ... d3105d94ee37f2.html
unicode和utf-8是什么关系
Unicode的最初目标，是用1个16位的编码来为超过65000个字符提供映射。但这还不够，它不能覆盖全部历史上的文字，也不能解决传输的问题(implantation head-ache's)，尤其在那些基于网络的应用中。已有的软件必须做大量的工作来实现16位的数据。
　　因此，Unicode用一些基本的保留字符制定了三套编码方式。它们分别是UTF-8,UTF-16和UTF-32。正如名字所示，在UTF－8中，字符是以8位序列来编码的，用一个或几个字节来表示一个字符。这种方式的最大好处，是UTF－8保留了ASCII字符的编码做为它的一部分，例如，在UTF－8和ASCII中，“A”的编码都是0x41. UTF－16和UTF－32分别是Unicode的16位和32位编码方式。考虑到最初的目的，通常说的Unicode就是指UTF-16。在讨论Unicode时，搞清楚哪种编码方式非常重要。Unicode:
unicode.org制定的编码机制, 要将全世界常用文字都函括进去.
在1.0中是16位编码, 由U+0000到U+FFFF. 每个2byte码对应一个字符; 在2.0开始抛弃了16位限制, 原来的16位作为基本位平面, 另外增加了16个位平面, 相当于20位编码, 编码范围0到0x10FFFF.
UTF: Unicode/UCS Transformation Format
UTF-8, 8bit编码, ASCII不作变换, 其他字符做变长编码, 每个字符1-3 byte. 通常作为外码. 有以下优点:
* 与CPU字节顺序无关, 可以在不同平台之间交流
* 容错能力高, 任何一个字节损坏后, 最多只会导致一个编码码位损失, 不会链锁错误(如GB码错一个字节就会整行乱码)
UTF-16, 16bit编码, 是变长码, 大致相当于20位编码, 值在0到0x10FFFF之间, 基本上就是unicode编码的实现. 它是变长码, 与CPU字序有关, 但因为最省空间, 常作为网络传输的外码.
UTF-16是unicode的preferred encoding.
UTF-32, 仅使用了unicode范围(0到0x10FFFF)的32位编码, 相当于UCS-4的子集.
UTF与unicode的关系:
Unicode是一个字符集, 可以看作为内码.
而UTF是一种编码方式, 它的出现是因为unicode不适宜在某些场合直接传输和处理. UTF-16直接就是unicode编码, 没有变换, 但它包含了0x00在编码内, 头256字节码的第一个byte都是0x00, 在操作系统(C语言)中有特殊意义, 会引起问题. 采用UTF-8编码对unicode的直接编码作些变换可以避免这问题, 并带来一些优点
utf-8与utf-16的区别
UTF8 和 UTF16 都是变长表示的，为啥欧美技术宅会觉得太浪费了咧？因为欧美字符 0x0000 - 0x00FF 就搞定了，UTF8 最小变长是 1 个字节，而 UTF16 变长是 2 个字节，
.utf-8 与 uft-16 表示 'a' a的ascii是0X61
utf-8为[0X61]
uft-16 [0x00,0X61]

作者: 贝壳iT 时间: 2017-3-7 15:25

jianliulin 发表于 2017-3-7 15:17
fbplus 是百草的，我不清楚。你需要找他，我说的新版是，fbinsttool的新版。

恩恩是的，发错。后来我 @ 了，貌似没有我在回复下他

作者: 贝壳iT 时间: 2017-3-7 15:25

Plantsoot 发表于 2017-3-7 08:42
昨天凌晨1点半，测试 create 命令，悲剧的是写的是 fbinst (hd3) create ，写错了，不是这样写的，U盘被当 ...

请看 http://bbs.wuyou.net/forum.php?m ... &fromuid=542985

作者: Plantsoot 时间: 2017-3-7 15:47

贝壳iT 发表于 2017-3-7 15:25
请看 http://bbs.wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=386272&pid=3347651&fromuid=542 ...

fbplus1.5.1703.7.zip (42.94 KB, 下载次数: 21)

请用最新版本测试下把，原版的fbinst我暂时没修改了，用fbplus版本吧，修改量很大，绕来绕去晕了。
目前我基本上测试了大部分功能，应该是没什么大问题，create创建空白的fba我没有加UTF-8标记，保存fba加上了。

info、filelist、add、remove、export、load、save、resize、copy、move、cat、cat-menu、output、inisize、iniout、onlylink均已测试过了。

create慎用，毁了我的U盘数据……，懒得恢复了。

作者: 贝壳iT 时间: 2017-3-7 15:57

Plantsoot 发表于 2017-3-7 15:47
请用最新版本测试下把，原版的fbinst我暂时没修改了，用fbplus版本吧，修改量很大，绕来绕去晕了。
...

辛苦了，恭喜，一切正常。。本主题zds1210发的那个最新版是有问题，赶紧换你这个

作者: Plantsoot 时间: 2017-3-7 16:07

贝壳iT 发表于 2017-3-7 15:57
辛苦了，恭喜，一切正常。。本主题zds1210发的那个最新版是有问题，赶紧换你这个

这两天代码写的有点乱，头大了……

作者: zds1210 时间: 2017-3-7 16:21
本帖最后由 zds1210 于 2017-3-7 16:25 编辑

jianliulin 发表于 2017-3-7 09:40
原来还有人在用fbinst啊，我以为没有什么人在用了。我现在说说乱码的根源：

1.原来fbinst的文件列表只支 ...

谢谢前辈的指点，我大致明白原因了。UD因三分区玩法，和分区表项法法，支持efi，而让UD还在流行。UD一直不会死，它只会慢慢老去。
不过有几点建议：
1.ansi格式会让新版grub中文乱码，这样子升级UD到utf8编码是完全有必要的。fbinstool取消对ansi格式UD支持，这个我完全是理解了。
2.新版fbinstool取消utf8标志，让新版建立的标准utt8的fba和UD区，被老版本识认为是ansi格式而造成新乱码，而造成用户的困惑。建议最新版的fbinstool在放弃对ansi格式的基础上，恢复utf8标志。
3编程制作用的fbinst或fbinst plus，强制格式UD区为utf8格式，放弃对ansi格式化的支持。但考虑到历史上还有许多ansi格式的fba没有升级到utf8外置加载支持，也是保留utf8标志，在导出UD区文件上保留对两种格式的支持。以待大家慢慢升级到utf8格式。
这样子看来方案就完美些，又考虑了历史，又考虑了编码的方向，又考虑了节约升级成本。

作者: 贝壳iT 时间: 2017-3-7 16:21

Plantsoot 发表于 2017-3-7 16:07
这两天代码写的有点乱，头大了……

那强迫症患者想知道还要不要等你继续更新优化，还是目前这个就目前来说完结了。

作者: Plantsoot 时间: 2017-3-7 16:24

贝壳iT 发表于 2017-3-7 16:21
那强迫症患者想知道还要不要等你继续更新优化，还是目前这个就目前来说完结了。

再更新，就是兼容下WIN10PE了，编码的问题基本终结，create不打算更新了。这个没什么用。

作者: zds1210 时间: 2017-3-7 16:25

Plantsoot 发表于 2017-3-7 16:24
再更新，就是兼容下WIN10PE了，编码的问题基本终结，create不打算更新了。这个没什么用。

支持支持。

作者: 贝壳iT 时间: 2017-3-7 16:30

Plantsoot 发表于 2017-3-7 16:24
再更新，就是兼容下WIN10PE了，编码的问题基本终结，create不打算更新了。这个没什么用。

期待着·

作者: 贝壳iT 时间: 2017-3-7 16:43
本帖最后由贝壳iT 于 2017-3-7 16:47 编辑

Plantsoot 发表于 2017-3-7 16:24
再更新，就是兼容下WIN10PE了，编码的问题基本终结，create不打算更新了。这个没什么用。

下个版本希望可以命令行修改MBR的ZIP CHS模式，这样就不要从新制作格式化U盘了、

作者: chiannet 时间: 2017-3-7 16:48
本帖最后由 chiannet 于 2017-3-7 16:49 编辑

jianliulin 发表于 2017-3-7 12:49
我修改了一下，你测试看看有没有问题：

这个是delphi7 下编译好的exe:

Desktop.7z (40.27 KB, 下载次数: 10) ,这个运算的结果符合GRUB4dos password --md5 需求。同一代码，delphi 2010 下编译出来的exe，运算结果就错误。

作者: jianliulin 时间: 2017-3-7 16:52

zds1210 发表于 2017-3-7 16:21
谢谢前辈的指点，我大致明白原因了。UD因三分区玩法，和分区表项法法，支持efi，而让UD还在流行。UD一直 ...

fbinst的内核只有2个字节是空闲的，不该无谓的浪费。旧版的fba转成utf-8即可

作者: chiannet 时间: 2017-3-7 17:04

jianliulin 发表于 2017-3-7 14:33
上传你预期的工具。

在78楼，请J大再看看。

作者: jianliulin 时间: 2017-3-7 17:14

chiannet 发表于 2017-3-7 16:48
这个是delphi7 下编译好的exe:,这个运算的结果符合GRUB4dos password --md5 需求。同一代码，delph ...

一时大意了。

MD5cr_cons.rar (130.13 KB, 下载次数: 7)

作者: chiannet 时间: 2017-3-7 17:24

jianliulin 发表于 2017-3-7 17:14
一时大意了。

好了，谢谢j大

作者: andos 时间: 2017-3-7 19:03
fbinst Plus有64位的版本吗?

作者: Plantsoot 时间: 2017-3-7 20:34

andos 发表于 2017-3-7 19:03
fbinst Plus有64位的版本吗?

没有纯64位，不过，fbinst plus 几乎所有的命令我都在WIN10 X64下测试过了，编译环境也是WIN10 X64，没有发现什么特别不兼容的问题。刚才测试 --onlylink和--udload在WIN10下也能正常运行，只要给管理员权限。

作者: 贝壳iT 时间: 2017-3-7 21:20

Plantsoot 发表于 2017-3-7 20:34
没有纯64位，不过，fbinst plus 几乎所有的命令我都在WIN10 X64下测试过了，编译环境也是WIN10 X64，没有 ...

我一般都加上XPSP3的兼容模式后管理员执行

作者: 贝壳iT 时间: 2017-3-8 14:07
本帖最后由贝壳iT 于 2017-3-8 14:14 编辑

Plantsoot 发表于 2017-3-6 21:24
确实有问题……

新版 fbinst.exe 123.fba output "文件" %~nx"
似乎总是说没有这个文件，其实info是有的，以前的fbinst可以正常输出
看返回命令是说MBR未初始化

Fbinst: error: fb mbr not initialized

稳定无措的仍然是你这个版本

fbinst.rar (38.34 KB, 下载次数: 4)

作者: Plantsoot 时间: 2017-3-8 15:43

贝壳iT 发表于 2017-3-8 14:07
新版 fbinst.exe 123.fba output "文件" %~nx"
似乎总是说没有这个文件，其实info是有的，以前的fbins ...

额…… 123.fba 大吗？不大也传上来。

作者: andos 时间: 2017-3-8 20:35

Plantsoot 发表于 2017-3-7 20:34
没有纯64位，不过，fbinst plus 几乎所有的命令我都在WIN10 X64下测试过了，编译环境也是WIN10 X64，没有 ...

现在基本上都用64位系统为主，所以希出个64位版，省去管理员权限执行

作者: 贝壳iT 时间: 2017-3-9 10:41

Plantsoot 发表于 2017-3-8 15:43
额…… 123.fba 大吗？不大也传上来。

123.rar (3.08 KB, 下载次数: 1)

作者: Plantsoot 时间: 2017-3-9 17:26

贝壳iT 发表于 2017-3-9 10:41

fbplus1.5.1703.9.zip (42.94 KB, 下载次数: 14)

修复了iniout不小心又让 output出现了BUG，这次应该可以了。

作者: 贝壳iT 时间: 2017-3-9 19:18

Plantsoot 发表于 2017-3-9 17:26
修复了iniout不小心又让 output出现了BUG，这次应该可以了。