維基百科:機器人/申請/Antigng-bot/33

Antigng-bot 33

狀態： 撤銷許可
操作者：Antigng（留言）
提請時間：2020年7月1日 (三) 23:05 (UTC)
自動化程度：全自動
程式語言：C
用途：清理Category:引文格式1錯誤：不可見字符
原始碼連結：
編輯時段及頻率：不限
受影響頁面：~~634~~570（存量），增速不知
遵守機器人規範：僅影響名字空間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)[回覆]

已完成50筆編輯。除1、2之外均滿足設計要求。檢查發現是上面的表達式沒有寫對，應為：

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)[回覆]