维基百科:机器人/申请/Antigng-bot/33
Antigng-bot 33
- 狀態: 撤銷許可
- 操作者:Antigng(留言)
- 提請時間:2020年7月1日 (三) 23:05 (UTC)
- 自動化程度:全自动
- 程式語言:C
- 用途:清理Category:引文格式1错误:不可见字符
- 原始碼連結:
- 編輯時段及頻率:不限
- 受影響頁面:
634570(存量),增速不知 - 遵守機器人規範:仅影响名字空间0和名字空间118,本身可靠性有保证不需要{{bots}}模板控制
- 已有機器人權限:是
- 严格按照CS1模块的逻辑处理这个分类下的条目。框架与最近三个(30,31,32)和模板相关的任务完全一致:
- 遍历一棵模板树中的所有模板;
- 检查模板名是否为引用模板,若否则跳过;
- 检查是否为不使用CS1的引用模板(e.g. cite arxiv),若是则跳过;
- 检查本模板中各参数值:若参数名实质等同于quote则跳过不处理;若参数值含有"<!---"或"nowiki"字串则跳过不处理;
- 除U+FFFD(依其定义,此符号存在的目的是为了替换,而非简单粗暴地移除)之外,若含有其它任何CS1定义的不可见字符则移除,但以下情况需要特殊处理:
- 控制符\t,\r,\n需特殊处理,它们在参数值的开头和尾部出现是合法的,但在参数值中间出现则是非法的;因此在检查参数值时,在读入第一个非不可见且非空格的字符前,不会清走这三个字符;在读入满足上述条件的字符后,遇到这三个字符不会立即丢弃,而是会将其存入一个缓冲区,待读入下一个非不可见且非空格的字符时才清空。最后将留在缓冲区中的字符(即原参数值尾部的\t\r\n)加到输出的新参数值尾部。这种处理方式有一个非预期的行为即如果原参数值的尾巴是“\t \n \n”,输出后会变成“ \t\n\n”。但本人认为这种处理至少是没有害处的,应可以接受;此外,由于该三个控制字符在事实上会显示为空格,为避免把两个英文词汇/数字粘一起,在清空缓冲区前会检查当前字符和输出的前一个字符是否是非空格、非连接符且非不可见的ASCII字符,如是则先输出一个空格再丢弃。
static int judgeinvisible(unsigned int uch)
{
/* 等于是把[[:Category:引文格式1错误:不可见字符]]的说明照抄一遍,但跳过U+FFFD不处理*/
return ((uch!=0xFFFD)&&
(uch==0x200B)||
(uch==0x00AD)||
(uch==0x0009)||
(uch==0x0010)||
(uch==0x0013)||
((0<uch)&&(uch<=0x001F))||
((0x0080<=uch)&&(uch<=0x009F))||
((0xFFF9<=uch)&&(uch<=0xFFFF))||
((0xE000<=uch)&&(uch<=0xF8FF))||
((0xF0000<=uch)&&(uch<=0xFFFFD))||
((0x100000<=uch)&&(uch<=0x10FFFD)));
}
- 测试编辑。--Antigng(留言) 2020年7月1日 (三) 23:05 (UTC)
- 不使用任何CS1输出的维护信息,在整个主名字空间单独空运行的结果表明,仅6个不在分类Category:引文格式1错误:不可见字符中的页面会被程序判定为存在问题,经检查它们的问题出在各种原因导致整个模板或其中个别参数不显示(e.g. 母模板参数错误,重复模板参数等)。但针对这种情形进行的编辑仍是有益而无害的,故可以认定零假阳性事件,或该任务的假阳性率低于百分之一,误检出率低于百万分之一,完全满足要求。--Antigng(留言) 2020年7月2日 (四) 05:26 (UTC)
- 7/2更新:排除参数名为quote的情况,这种情况下虽然CS1会报错,但部分格式如\t\n仍能正确显示,清理的合法性存疑,甚至CS1模块为此报错的必要性也存疑。排除该参数后,待处理页面减少至570个。--Antigng(留言) 2020年7月2日 (四) 22:23 (UTC)
- 批准測試運作(30次編輯)。--Xiplus#Talk 2020年7月15日 (三) 10:35 (UTC)
static int judgeinvisible(unsigned int uch)
{
/* 等于是把[[:Category:引文格式1错误:不可见字符]]的说明照抄一遍,但跳过U+FFFD不处理*/
return ((uch!=0xFFFD)&&
((uch==0x200B)||
(uch==0x00AD)||
(uch==0x0009)||
(uch==0x0010)||
(uch==0x0013)||
((0<uch)&&(uch<=0x001F))||
((0x0080<=uch)&&(uch<=0x009F))||
((0xFFF9<=uch)&&(uch<=0xFFFF))||
((0xE000<=uch)&&(uch<=0xF8FF))||
((0xF0000<=uch)&&(uch<=0xFFFFD))||
((0x100000<=uch)&&(uch<=0x10FFFD))));
}
- 更正后问题便不再出现。--Antigng(留言) 2020年7月15日 (三) 18:44 (UTC)
- Special:Diff/60612638:取消|location=前的換行是在預期之內嗎?
- Special:Diff/60612625:雖然是GIGO,但是處理完之後仍有換行符,符合您的設計嗎?
- Special:Diff/60612496:「」是不可見字元? --Xiplus#Talk 2020年7月17日 (五) 23:49 (UTC)
- (:)回應
- 1. 是。如Special:Diff/60649498所示,不取消这一换行CS1即报错。(但处理任务时bot完全“看不见”CS1的报错信息,因此上面的空运行结果才有意义。)
- 2. 是。因为最后一个参数里带了reflist模板,当程序完成模板解析的时候参数值的地方是一个单向链表
(节点1:[类型=文本,字符指针=指向字符串" ref = harv \n==参考文献==\n"所在的内存区域])->(节点2: [类型=模板,结构指针=指向模板reflist所在的内存区域])->(节点3:[类型=文本,字符指针=指向字符串"\n\n==另请参阅==\n "所在的内存区域])->NULL
- 当程序处理到节点3的地方时,如果要去除“另请参阅”前面的两个\n,它就必须利用节点1和节点2中已经出现过的信息。但是它完全不知道节点2中的模板里有什么内容——不可能每解析一个条目还要向服务器请求所有使用的模板的源码,这不现实——为保险起见就一刀切禁止这种跨节点处理的情况。
- 3. 引起Citation/CS1报错的的除了不可见字符之外,还有部分控制字符和私有字符。与U+FFFD不同,其出现几乎总是由OCR识别错误所导致的,而不是替换了什么合法的字符,因此采用移除的处理方法并无不妥之处。--Antigng(留言) 2020年7月18日 (六) 02:11 (UTC)
- 正式批准運作。--Xiplus#Talk 2020年7月18日 (六) 05:13 (UTC)