User talk:InternetArchiveBot

m:User talk:InternetArchiveBot
本頁面為軟重定向。

有關台灣企業永續獎資料更新

2023已新增了很多獎項，加上內容的數據內容為2021年， ESG的發展極快，應幾時更新正確的資料給予大眾觀看。--Williamchong92（留言） 2023年7月13日 (四) 05:53 (UTC)

World--180.217.193.171（留言） 2024年3月13日 (三) 02:20 (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故障？

於Phabricator查看
編號T364136的工單
狀態：已解決

这两天突然发现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)

虽然但是我觉得应该联系机器人维护者@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)

•  已修复—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編碼移除（一個例外是%20，空格會觸發警告），但若IABot行爲不改，將降低成效，所以先單獨處理此行爲。--惣流·明日香·蘭格雷不姓式波 2024年11月10日 (日) 01:14 (UTC)

URL的编码原理。——Sakamotosan路过围观 | 避免做作，免敬 2024年11月10日 (日) 02:56 (UTC)

這我大概了解，但有什麽技術上的原因必須將漢字進行編碼嗎？即使無法顯示也不影響存取吧（見無韓語字型瀏覽ko.wiki），在可讀性上也是不編碼更佳（圖中的6個方塊 vs %EC​%9C​%84​%ED​%82​%A4​%EB​%B0​%B1​%EA​%B3​%BC​:​%EB​%8C​%80​%EB​%AC​%B8）。--惣流·明日香·蘭格雷不姓式波 2024年11月10日 (日) 03:33 (UTC)

• 有「空格」字元的新聞連結、作品名稱等必須使用%XX各式；請不要跟我說維基百科自動會將內部連結的空格換成底線（ _ ），那如果連結是「yahoo新聞」怎麼辦？你覺得Yahoo新聞會幫你轉換？其他網站才沒有這種功能。之所以 有「空格」字元的新聞連結、作品名稱等必須使用%XX各式是因為如果你在維基百科外部鏈接語法中直接輸入空白，連結會被截斷，你必須寫成%20才不會被截斷
  •  [//zh.wikipedia.org/wiki/%20娜娜奇 連結名稱] ➡️

    連結名稱

  •  [//zh.wikipedia.org/wiki/0 0娜娜奇 連結名稱] ➡️

    娜娜奇 連結名稱

@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天后仍掛有模板的條目]]（鏈接損毀）

vs

[[維基百科:頁面存廢討論/記錄/2024/11/10#30天后仍掛有{{notability}}模板的條目]]（鏈接損毀）

vs

維基百科:頁面存廢討論/記錄/2024/11/10#30%E5%A4%A9%E5%90%8E%E4%BB%8D%E6%8E%9B%E6%9C%89%7B%7Bnotability%7D%7D%E6%A8%A1%E6%9D%BF%E7%9A%84%E6%A2%9D%E7%9B%AE（只有這個是正確的）

以上-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年11月10日 (日) 05:04 (UTC)

%20空格的問題我知道，也提出了是要保留的例外。由於本來是針對IABot的行爲，確實沒想到{之類的問題，但此類字符加起來大概就十來二十個吧，應該不難處理？比如你的例子其實可以寫成維基百科:頁面存廢討論/記錄/2024/11/10#30天後仍掛有%7B%7Bnotability%7D%7D模板的條目。--惣流·明日香·蘭格雷不姓式波 2024年11月10日 (日) 06:46 (UTC)

@Sohryu Asuka Langley Not Shikinami 抱歉，您的鏈接無效。我點進去不但沒有跳轉到任何章節，右上角還提示：「無法找到此話題，可能已被刪除、移動、或重新命名。」。-- 宇帆-娜娜奇🐰鮮果茶☕在維基百科尋求休閒是否搞錯了什麼（☎️·☘️） 2024年11月10日 (日) 07:05 (UTC)

簡繁問題，維基百科:頁面存廢討論/記錄/2024/11/10#30天后仍掛有%7B%7Bnotability%7D%7D模板的條目才對。 捂脸--惣流·明日香·蘭格雷不姓式波 2024年11月10日 (日) 07:14 (UTC)

• (：)回應^[引述]「確實沒想到{之類的問題，但此類字符加起來大概就十來二十個吧，應該不難處理？比如你的例子其實可以寫成[...]」^[引述](：)回應：@Sohryu Asuka Langley Not Shikinami：

　​並非。　　​你怎麼保證所有瀏覽器都用「相同的編碼方式」處理文字『天后仍掛有模板的條目』這些文字？　　​你怎麼保證所有伺服器都用相同的解析方式解析文字『天后仍掛有模板的條目』這些文字？　　​『#30​ ​%E5​ ​%A4​ ​%A9​ ​%E5​ ​%90​ ​%8E​ ​%E4​ ​%BB​ ​%8D​ ​%E6​ ​%8E​ ​%9B​ ​%E6​ ​%9C​ ​%89​ ​ ​%7B​ ​%7B​ ​notability​ ​%7D​ ​%7D​ ​ ​%E6​ ​%A8​ ​%A1​ ​%E6​ ​%9D​ ​%BF​ ​%E7​ ​%9A​ ​%84​ ​%E6​ ​%A2​ ​%9D​ ​%E7​ ​%9B​ ​%AE​ ​』　​才是可以確保所有設備正確解析為　​『#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)

其实我的意思就是，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)

哈，我工作中也遇到过这类问题，非常头疼--百無一用是書生 (☎) 2024年11月11日 (一) 03:02 (UTC)

( π )题外话：例子中的香港01，去掉URL中的标题部分也能正常打开（如https://www.hk01.com/%E9%A3%9F%E7%8E%A9%E8%B2%B7/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：

mw.loader.load('//meta.wikimedia.org/wiki/User:Txkk/CurIDLink.js?action=raw&ctype=text/javascript');

--Txkk（留言） 2024年11月25日 (一) 07:37 (UTC)