使用者討論:InternetArchiveBot
m:User talk:InternetArchiveBot
本頁面為軟重新導向。
有關台灣企業永續獎資料更新
[編輯]2023已新增了很多獎項,加上內容的數據內容為2021年, ESG的發展極快,應幾時更新正確的資料給予大眾觀看。--Williamchong92(留言) 2023年7月13日 (四) 05:53 (UTC)
黃剛 (1946年)的快速刪除通知
[編輯] 您好,有編者認為您創建的頁面黃剛 (1946年)內容不當,符合快速刪除條件,該頁面很快會由管理員進行覆核並決定是否保留。
維基百科非常歡迎您的編輯,但請先看看編輯幫助和維基百科不是什麼,以免犯了常見的錯誤。
請不要自行移除快速刪除模板,快速刪除旨在加快處理顯然不合適的頁面。若您認為刪除理由不合適或您已對頁面做了改善,請在被提刪頁面快速刪除模板的正下方加入{{Hang on}}
,並在頁面的討論頁中說明理由。您亦可以與提刪的維基人進行溝通,多謝合作!
幫助:互助客棧 · 刪除指導 · 存廢覆核請求 · IRC聊天頻道--GZWDer(留言) 2023年9月9日 (六) 11:01 (UTC)
Talk:CGTN Radio的快速刪除通知
[編輯] 您好,有編者認為您創建的頁面Talk:CGTN Radio內容不當,符合快速刪除條件,該頁面很快會由管理員進行覆核並決定是否保留。
維基百科非常歡迎您的編輯,但請先看看編輯幫助和維基百科不是什麼,以免犯了常見的錯誤。
請不要自行移除快速刪除模板,快速刪除旨在加快處理顯然不合適的頁面。若您認為刪除理由不合適或您已對頁面做了改善,請在被提刪頁面快速刪除模板的正下方加入{{Hang on}}
,並在頁面的討論頁中說明理由。您亦可以與提刪的維基人進行溝通,多謝合作!
幫助:互助客棧 · 刪除指導 · 存廢覆核請求 · IRC聊天頻道--Mafalda4144(留言) 2023年11月4日 (六) 10:56 (UTC)
InternetArchiveBot故障?
[編輯]這兩天突然發現User:InternetArchiveBot無法識別{{Cite web}}、{{Cite news}}等系列模板中已添加的存檔,而是直接在模板外添加了{{Wayback}},導致大量引用來源出現重複的存檔連結(如:[1]);即使Cite系列模板沒有存檔連結,也不會填進去(如:[2])。我已在P站提單,暫未得到回覆;但剛剛發現機器人在其他站點的工作是正常的(如西語維基百科、英語維基百科)……想請教是否會與本地的一些配置有關?以及我認為有必要將這兩天機器人做的編輯全數回退……--Tim Wu(留言) 2024年5月4日 (六) 17:55 (UTC)
- 問題持續中,現在還是重複添加{{Wayback}}。InternetArchiveBot的條目修改量也不少,在解決問題之前,能否先禁止這個bot的在zhwiki的運行。--Nostalgiacn(留言) 2024年5月6日 (一) 03:04 (UTC)
- 不反對暫時禁止。--Tim Wu(留言) 2024年5月6日 (一) 03:14 (UTC)
- 不確定是bug還是只是參數識別問題,因為用iabot界面編輯存檔的話,參數名為「archive-date」和「archive-url」,可能是原來的模板參數對不上而無法處理?——Sakamotosan路過圍觀 | 避免做作,免敬 2024年5月6日 (一) 07:26 (UTC)
- 現在有沒有橫槓都識別不出來。--Tim Wu(留言) 2024年5月6日 (一) 07:31 (UTC)
- 像這個更改Special:Diff/82526887,{{Cite web}}的參數就是
archive-url
和archive-date
,但bot還是在模板外加的{{Wayback}}。--𝓧𝓩𝓣𝓓𝓮𝓪𝓷 𝕋𝕒𝕝𝕜 2024年5月6日 (一) 10:05 (UTC) - 剛試了用iabot界面編輯存檔,出現了同樣問題。連帶之前沒有存檔的也是以{{Wayback}}存檔。--S叔 2024年5月6日 (一) 12:48 (UTC)
- 不確定是bug還是只是參數識別問題,因為用iabot界面編輯存檔的話,參數名為「archive-date」和「archive-url」,可能是原來的模板參數對不上而無法處理?——Sakamotosan路過圍觀 | 避免做作,免敬 2024年5月6日 (一) 07:26 (UTC)
- 不反對暫時禁止。--Tim Wu(留言) 2024年5月6日 (一) 03:14 (UTC)
- 雖然但是我覺得應該聯繫機器人維護者@Cyberpower678、Harej而不是去phab開工單……我覺得該問題是機器人本身的問題與mw沒啥關係,機器人也不是基金會人員所有的。--忒有錢 🌊塩水あります🐳(留言) 2024年5月9日 (四) 19:24 (UTC)
- 工單也加了Cyberpower678。但如果直接去對方用戶討論頁提醒一下,或者先諮詢一下是不是出了一些問題,應該會更好。——Sakamotosan路過圍觀 | 避免做作,免敬 2024年5月10日 (五) 00:23 (UTC)
- 是在機器人元維基問題回報頁反饋無果後才提單的,雖然兩處直到現在都沒有更新,很失望。--Tim Wu(留言) 2024年5月10日 (五) 03:37 (UTC)
- 建議修復前先禁用吧。另外IABOT工具也是在{{cite}}模板之外添加的存檔,不論archive-url是否已經填寫。--Kethyga(留言) 2024年5月10日 (五) 03:32 (UTC)
- 另外,還有IABotManagementConsole的也是,見 Special:Diff/81922170/82595494、標籤:IABotManagementConsole最近更改。--Kethyga(留言) 2024年5月11日 (六) 01:18 (UTC)
- 有必要按照Wikipedia:忽略所有規則立刻禁用該機器人,避免受影響範圍擴大--Dnaimfz(留言) 2024年5月14日 (二) 12:10 (UTC)
- 此機器人的自動作業已停止,但這期間仍有用戶通過 IABotManagementConsole 添加存檔。--Tim Wu(留言) 2024年5月14日 (二) 13:07 (UTC)
- It would appear that this edit has broken the bot's ability to read the CS1 configuration for this wiki. I suspect the comma might be interfering, but I'm not certain.—CYBERPOWER (留言) 2024年5月14日 (二) 12:55 (UTC)
- @Shizhao @Cookai1205 請知悉--Tim Wu(留言) 2024年5月14日 (二) 12:59 (UTC)
- 翻譯:這個編輯似乎破壞了機器人讀取這個wiki的CS1配置的能力。我懷疑逗號可能起了干擾作用,但我不確定--Dnaimfz(留言) 2024年5月14日 (二) 13:00 (UTC)
- css語法沒問題,如果的確是這個問題造成的,那麼最有可能的是IAbot的代碼遇到css3的var()函數觸發了bug--百無一用是書生 (☎) 2024年5月14日 (二) 13:24 (UTC)
- I'm not denying that it's likely just a parsing issue of IABot, I'm just pointing out what seems to have triggered that bug. I'm investigating the parser right now.--—CYBERPOWER (留言) 2024年5月14日 (二) 14:14 (UTC)
- 翻譯:我不否認這可能只是一個IABot的解析問題,我只是指出似乎是什麼觸發了這個錯誤。我正在調查解析器。--Dnaimfz(留言) 2024年5月14日 (二) 15:41 (UTC)
- Definitely a result of the edit, the -- is causing the parser to think a comment was added and is purging it with the rest of the line causing breakage.--—CYBERPOWER (留言) 2024年5月14日 (二) 16:10 (UTC)
- 翻譯:我不否認這可能只是一個IABot的解析問題,我只是指出似乎是什麼觸發了這個錯誤。我正在調查解析器。--Dnaimfz(留言) 2024年5月14日 (二) 15:41 (UTC)
- I'm not denying that it's likely just a parsing issue of IABot, I'm just pointing out what seems to have triggered that bug. I'm investigating the parser right now.--—CYBERPOWER (留言) 2024年5月14日 (二) 14:14 (UTC)
- css語法沒問題,如果的確是這個問題造成的,那麼最有可能的是IAbot的代碼遇到css3的var()函數觸發了bug--百無一用是書生 (☎) 2024年5月14日 (二) 13:24 (UTC)
- 已修復—CYBERPOWER (留言) 2024年5月14日 (二) 16:42 (UTC)
管理人員解任投票通告
[編輯]Mys_721tx的管理員解任投票(第2次)正在進行,投票期為2024年7月12日至7月26日,誠邀您踴躍參與投票。
- 投票須知
- 依據方針,本次投票必須按照指定格式在安全投票的「投票留言」框內填寫文字來進行投票,並給出理由。
- 由於技術原因,因而保留空白的投票選項,但空白選項是無效的,請在「投票留言」一欄留下您的投票及理由。
- 請注意,中立票意見僅供參考,僅能計入總有效票數,但不會計入得票比率。
- 在系統中,每個用戶只有一票會被儲存。您可以在投票期間重複更改您的投票,但系統只會儲存最新的投票,並覆蓋之前的記錄。
- 請儘可能讓您的留言簡潔。請注意,您的投票留言將在投票結束後打亂順序並公開可見。
- 指定格式
- 支持解任:您的理由
- 反對解任:您的理由
- 中立:您的意見留言
建議在您的投票留言最前面寫「支持解任」或「反對解任」或「中立」,之後是冒號「:」,接著是您的理由。
請明確填寫「支持解任」或「反對解任」或「中立」並給出理由,中立票意見僅供參考不會計入得票比率,未填寫「支持解任」或「反對解任」或「中立」的為無效票。
MediaWiki message delivery(留言) 2024年7月14日 (日) 14:31 (UTC)
邀請您參與管理人員任免及仲裁委員會制度討論
[編輯]您好!中文維基百科社群現正檢討管理人員任免制度,並籌劃仲裁委員會首屆委員選舉方案。歡迎參與相關討論,並踴躍提出意見。 |
- 註:此通告由MediaWiki message delivery(留言)於2024年9月21日 (六) 13:36 (UTC)寄送。若您未來長期或目前暫時不欲接收任何類似訊息,可考慮婉拒消息發送。
有關IABot對URL字符編碼的行爲
[編輯]
據觀察,IABot會將源碼中能編碼的字符都編掉,無視原來的寫法,這導致源碼難以閲讀且不必要地增加條目長度。例子見special:diff/84907263。每個3位元組的漢字都會換成9位元組的%xx%xx%xx,再算上url archive-url,效果雙倍。一旦條目中含此類URL的連結較多,對長度的影響將變得明顯。例子見special:diff/84911755,所有url編碼所帶來的額外長度達條目的30%(157284/513488)。
如果本來填的URL並未進行編碼就代表不編碼也能存取吧,再進一步說,有沒有情況是一定要進行編碼?如果可以的話應停止此行爲。
個人認爲應該將所有URL編碼移除(一個例外是 ,空格會觸發警告),但若IABot行爲不改,將降低成效,所以先單獨處理此行爲。--惣流·明日香·蘭格雷不姓式波 2024年11月10日 (日) 01:14 (UTC)
- URL的編碼原理。——Sakamotosan路過圍觀 | 避免做作,免敬 2024年11月10日 (日) 02:56 (UTC)
- 這我大概了解,但有什麽技術上的原因必須將漢字進行編碼嗎?即使無法顯示也不影響存取吧(見無韓語字型瀏覽ko.wiki),在可讀性上也是不編碼更佳(圖中的6個方塊 vs � � � � � � � � � � � � : � � � � � �)。--惣流·明日香·蘭格雷不姓式波 2024年11月10日 (日) 03:33 (UTC)
- @Sohryu Asuka Langley Not Shikinami,你自己看,不使用%xx寫的連結直接都壞掉了耶,根本連不到目標頁,因為維基語法就是這樣讀取啊,網址後段全部截掉了,被當成顯示的文字,行為完全錯誤,不符預期;請不要跟我說維基百科自動會將內部連結的空格換成底線(
),那如果連結是「yahoo新聞」怎麼辦?你覺得Yahoo新聞會幫你轉換?其他網站才沒有這種功能。%XX寫法仍有必須存在、必須使用的時機。-- 宇帆- _娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年11月10日 (日) 04:45 (UTC)
- (~)補充不止空格,所有「網址中包含與維基語法撞符號之字元」的網址全部都只能寫成%XX模式,不然就語法錯誤,爆炸!-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年11月10日 (日) 04:52 (UTC)
- 第二彈
- 鏈接:
維基百科:頁面存廢討論/記錄/2024/11/10#30天后仍掛有{{notability}}模板的條目
- 鏈接:
- 對比
- 維基百科:頁面存廢討論/記錄/2024/11/10#30天後仍掛有模板的條目(系統提示:無法找到此話題,可能已被刪除、移動、或重新命名。)
- vs
- [[維基百科:頁面存廢討論/記錄/2024/11/10#30天後仍掛有
模板的條目]](鏈接損毀)
- [[維基百科:頁面存廢討論/記錄/2024/11/10#30天後仍掛有
- vs
- [[維基百科:頁面存廢討論/記錄/2024/11/10#30天後仍掛有{{notability}}模板的條目]](鏈接損毀)
- vs
- 以上-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年11月10日 (日) 05:04 (UTC)
- 空格的問題我知道,也提出了是要保留的例外。由於本來是針對IABot的行爲,確實沒想到{之類的問題,但此類字符加起來大概就十來二十個吧,應該不難處理?比如你的例子其實可以寫成維基百科:頁面存廢討論/記錄/2024/11/10#30天後仍掛有{{notability}}模板的條目。--惣流·明日香·蘭格雷不姓式波 2024年11月10日 (日) 06:46 (UTC)
- @Sohryu Asuka Langley Not Shikinami 抱歉,您的鏈接無效。我點進去不但沒有跳轉到任何章節,右上角還提示:「
無法找到此話題,可能已被刪除、移動、或重新命名。
」。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年11月10日 (日) 07:05 (UTC)- 簡繁問題,維基百科:頁面存廢討論/記錄/2024/11/10#30天後仍掛有{{notability}}模板的條目才對。 捂臉--惣流·明日香·蘭格雷不姓式波 2024年11月10日 (日) 07:14 (UTC)
- (:)回應[引述]「
確實沒想到
」[引述](:)回應:@Sohryu Asuka Langley Not Shikinami:{
之類的問題,但此類字符加起來大概就十來二十個吧,應該不難處理?比如你的例子其實可以寫成[...]
- 『
#30notability } } � � � � � � � � � � � � � � �
』 � � � � � � � � � � � � � � � { { 才是可以確保所有設備正確解析為 『#30天后仍掛有notability }} 模板的條目
』 {{ 的方式吧。以維基百科目前後台的作法,沒有別的方式。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年11月10日 (日) 08:17 (UTC) 並非。 你怎麼保證所有瀏覽器都用「相同的編碼方式」處理文字『天后仍掛有模板的條目』這些文字? 你怎麼保證所有伺服器都用相同的解析方式解析文字『天后仍掛有模板的條目』這些文字?
- (:)回應[引述]「
- 從外鏈問題討論到內鏈,並且沒搞清楚目錄和片段ID的編碼問題,真服了。如果想保證頁面內目錄的片段ID跳轉準確的話,可以直接點擊目錄的連結,看一下mw輸出的錨點值,抄下來就可以了。——Sakamotosan路過圍觀 | 避免做作,免敬 2024年11月10日 (日) 07:26 (UTC)
- 我想表達的意思就只是想說「最好別縮」並舉幾個例子。縮了之後會出現許多問題,包括但不限於內部連結和外部連結。有些問題可能剛好是你的瀏覽器沒事,所以User:Sohryu Asuka Langley Not Shikinami「以偏概全地」認為所有人都沒事,但事實並未如此,例如下方Sakamotosan路過圍觀的舉例,天知道哪牌的瀏覽器用了什麼鬼編碼方式,結果點出來的鏈接就都跟別人不一樣。最穩定的方式還是%Xx,至少可以確保該鏈接「所有人」乃至「所有電子設備」乃至「所有瀏覽器」點進去都是連到相同位置。因為如果你直接打中文,瀏覽器預設編碼方式換了一個,你的網址就迷路了,無疑徒增讀者困擾,還不易Debug,仍然堅持必要時仍應維持全段完整的%XX模式。User:Sohryu Asuka Langley Not Shikinami請您務必不要以為閣下那邊鏈接起來正常,就會所有人都正常,並不是這樣。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年11月10日 (日) 07:47 (UTC)
- 簡繁問題,維基百科:頁面存廢討論/記錄/2024/11/10#30天後仍掛有{{notability}}模板的條目才對。 捂臉--惣流·明日香·蘭格雷不姓式波 2024年11月10日 (日) 07:14 (UTC)
- @Sohryu Asuka Langley Not Shikinami 抱歉,您的鏈接無效。我點進去不但沒有跳轉到任何章節,右上角還提示:「
- 空格的問題我知道,也提出了是要保留的例外。由於本來是針對IABot的行爲,確實沒想到{之類的問題,但此類字符加起來大概就十來二十個吧,應該不難處理?比如你的例子其實可以寫成維基百科:頁面存廢討論/記錄/2024/11/10#30天後仍掛有{{notability}}模板的條目。--惣流·明日香·蘭格雷不姓式波 2024年11月10日 (日) 06:46 (UTC)
- 其實我的意思就是,URL編碼化才是URL正確的形式。如果不進行URL編碼保存進wikicode代碼的話,實際上mw渲染時不會再做URL編碼處理而原樣輸出(oldid=84916049,打開開發者工具看一下連結href屬性)。這時候URL請求的編碼化就落在瀏覽器上,這可能會導致請求行為不確定(我的工作,見過項目處理這種不URL編碼且不屬於ASCII編碼集的連接,伺服器識別會出現請求字符錯誤的情況)。這種不懂技術想縮數的做法沒啥好說的。——Sakamotosan路過圍觀 | 避免做作,免敬 2024年11月10日 (日) 07:11 (UTC)
- 所以是爲了瀏覽器的兼容性而不能改嗎?那反過來説,應該要確保含漢字(及其他非ASCII)的連結必須被編碼化?--惣流·明日香·蘭格雷不姓式波 2024年11月10日 (日) 07:52 (UTC)
- 可以理解為沒必要處理,因為URL的編碼模式就是這樣。——Sakamotosan路過圍觀 | 避免做作,免敬 2024年11月10日 (日) 08:30 (UTC)
- -- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼(☎️·☘️) 2024年11月10日 (日) 08:22 (UTC)
- 正常來説是會被編掉,但比如我最初提的special:diff/84907263,假若編者當時連archive-url都填好,就不會被IABot處理,那不就有潛在問題了?--惣流·明日香·蘭格雷不姓式波 2024年11月10日 (日) 08:39 (UTC)
- 這個你應該找Iabot系列的開發者討論這個問題。但我認為,1.URL的百分位編碼才是針對非ASCII字符編碼下的URL請求的正確處理模式;2.外鏈語法在mw是會原樣輸出的;3.URL的非ASCII字符編碼在瀏覽器上做了一些「人性化」處理(包括百分位解碼顯示和再次連接請求時的百分位編碼),但不保證兼容。不要糾結這種碼元問題。——Sakamotosan路過圍觀 | 避免做作,免敬 2024年11月10日 (日) 11:39 (UTC)
- 可以理解為沒必要處理,因為URL的編碼模式就是這樣。——Sakamotosan路過圍觀 | 避免做作,免敬 2024年11月10日 (日) 08:30 (UTC)
- 哈,我工作中也遇到過這類問題,非常頭疼--百無一用是書生 (☎) 2024年11月11日 (一) 03:02 (UTC)
- 所以是爲了瀏覽器的兼容性而不能改嗎?那反過來説,應該要確保含漢字(及其他非ASCII)的連結必須被編碼化?--惣流·明日香·蘭格雷不姓式波 2024年11月10日 (日) 07:52 (UTC)
- ( π )題外話:例子中的香港01,去掉URL中的標題部分也能正常打開(如https://www.hk01.com/食玩買/868261)。--Kcx36(留言) 2024年11月10日 (日) 07:48 (UTC)
- 需要看對應伺服器的代碼設計,實際上這些文章查看器的每一筆數據應該對應一個類似數字或者UUID等組成的唯一業務ID,只需要傳入這個ID就能獲得相應的文章數據,URL中的標題信息可能不是必要的,也可能是SEO策略,方便搜尋引擎捕捉關鍵詞。像我們這種URL直接依靠「標題」來獲得文章資源的應該少見(?),雖然每個頁面是存在pageid這個類似唯一業務ID,可以通過特殊:重新導向來唯一獲得。——Sakamotosan路過圍觀 | 避免做作,免敬 2024年11月10日 (日) 08:30 (UTC)
- 本質上是
encodeURI
、encodeURIComponent
和mw.util.wikiUrlencode
三者行為的差異,既然場景是對外的,就應儘可能保證兼容,即使用encodeURIComponent
。--安憶Talk 2024年11月14日 (四) 08:18 (UTC)
續:有關IABot對URL字符編碼的行為
[編輯]@Cwek:「像我們這種URL直接依靠「標題」來獲得文章資源的應該少見(?),雖然每個頁面是存在pageid這個類似唯一業務ID,可以通過特殊:重新導向來唯一獲得。
」,可以通過pageid連結訪問維基百科頁面(比如 https://zh.wikipedia.org/?curid=5685170&redirect=no ),但是不能用在頁面內鏈上就是了。--Txkk(留言) 2024年11月25日 (一) 07:30 (UTC)
- 添加以下代碼到Special:MyPage/common.js即可獲取該gadget:--Txkk(留言) 2024年11月25日 (一) 07:37 (UTC)
mw.loader.load('//meta.wikimedia.org/wiki/User:Txkk/CurIDLink.js?action=raw&ctype=text/javascript');