search

LiMinggang / madedit-mod

MadEdit-Mod is a cross platform Text/Hex editor(based on the madedit project @ sourceforge)
GNU General Public License v3.0
124 stars 27 forks source link

语系编码自动识别的问题 #314

Open inker8086 opened 4 years ago

inker8086 commented 4 years ago

基于原0.2.9版本开发存在一个问题： 对于语系编码的自动识别，无法如同0.2.6版本一样准确。 比如某UTF-8的文件，偶尔的被自动识别为其他语系编码。

如果改变检视时的语系编码之后退出文件，则这个问题能够立即重现： 再次开启该文件，会调用上次的检视，而非自动识别文件的原语系编码。

希望 Li 大，是不是能够抽空纠正这个问题。 辛苦了，感谢您接手这个工具的维护，敬祝安康。

LiMinggang commented 4 years ago

这个真没注意到，你的信息准确吗？madedit的编码识别是来自与Firefox的编码识别那部分代码。我后面曾经跟firefox比较和同步过，没发现有大的改动。也就是说0.2.6跟后面的没太大改动，如果你有列子能复现这个问题最好，否则也不好说是哪里出了问题。

inker8086 commented 3 years ago

忘了说了，Li大，我是在Windows上碰到这问题的。 文件第一次载入时识别编码错误的情况是比较难复现的，在一次性载入多个不同编码的文件时能偶尔发生。 而手动变更检视时的编码，退出文件后再重新载入就能复现这个问题了。麻烦 Li大有空的时候搞搞。

LiMinggang commented 3 years ago

额，看来有可能是我做检测代码的单例化引入的问题

inker8086 commented 3 years ago

Li大辛苦了，这事不急，有空再搞，注意休息，毕竟从028版至今都十来年了。 本想027版就用到天荒地老，却才发现Li大让这个CJK语区用户才明白的好工具续命了。 总之，感谢Li大的无私工作，谢谢！

LiMinggang commented 3 years ago

目前工作确实比较忙，但这个问题的难点是如何验证，如果你能找到几个可以复现出问题的文件就能很快修复。不然也都是漫无目的的瞎蒙。

LiMinggang commented 3 years ago

我好像搞混了，我是把语法高亮给单例化了，这个encoding好像没动。所以这个就奇怪了

LiMinggang commented 3 years ago

我检查了代码，有如下发现： 我放宽了UTF8部分的检查，实际应该是原来madedit的bug，原因在这里 //Extra check from http://codeblocks.sourcearchive.com/documentation/8.02-0ubuntu4/encodingdetector_8cpp-source.html

LiMinggang commented 3 years ago

所以需要你提供能复现你说的问题的文件我来查。

KrasnayaPloshchad commented 3 years ago

其实这个很容易复现。Wikimedia Commons 上面收藏了很多 SVG 图像，保存原始文件以后随便一个打开都有 encoding="utf-8" 这类标记，如果你把本 issue 也保存一个网页下来的话就会发现源码里面有 <meta charset="utf-8"> 这段代码。

LiMinggang commented 3 years ago

@KrasnayaPloshchad 你遇到同样的问题？如果可能，就提供一个能复现这个问题的文件 image

KrasnayaPloshchad commented 3 years ago

文件在下面的两个资源里面，点击 Original file 就能得到文件 https://commons.wikimedia.org/wiki/File:Seal_of_the_President_of_the_Republic_of_Korea.svg https://commons.wikimedia.org/wiki/File:2021_Kazakh_Latin_alphabet_table_-_RU.svg

LiMinggang commented 3 years ago

@KrasnayaPloshchad 这两个文件编码检测确实错了。但是，这个不是程序的bug，而且也没法解决。这两个文件是因为在最前面有很大一部分没有出现任何非ASCII的UTF8字符。 目前MadEdit-Mod（或者说是原来的madedit一直都是）只检测文件的前4K字符来判断文件编码。所以如果前4K字节的内容如果没有出现标志性字符，结果很可能是不对的。即使放松到8K字节，甚至1M，也不能彻底解决问题，如果检测字符太多，会使得打开文件变得很慢，这个是很差的用户体验。 你可以试试把你提到的上面的两个文件的前面部分删掉，直到有韩文或者其他文字的部分，重新命名一个文件，再打开试试。

LiMinggang commented 3 years ago

有一种折中方案就是把检测长度作为一个配置选项暴露给用户，配置的过大还是会导致性能问题。

KrasnayaPloshchad commented 3 years ago

你可以试试把你提到的上面的两个文件的前面部分删掉，直到有韩文或者其他文字的部分，重新命名一个文件，再打开试试。

我试了下，文件的确能解析为 UTF-8 编码。那能不能添加一个规则，把 encoding/charset 之类的属性当作优先解析的对象。

LiMinggang commented 3 years ago

你可以试试把你提到的上面的两个文件的前面部分删掉，直到有韩文或者其他文字的部分，重新命名一个文件，再打开试试。

我试了下，文件的确能解析为 UTF-8 编码。那能不能添加一个规则，把 encoding/charset 之类的属性当作优先解析的对象。

encoding/charset 这个是语法（syntax）范畴的东西----多数文件格式都没有这个，少数诸如html，xml，python之类的，但是MadEdit的语法高亮部分比较弱，我可以看看语法部分，但是不抱希望。

LiMinggang commented 3 years ago

我先标为invalid，你们要是有其他发现，就在这里更新吧