<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Base64 on Timmoc 的技术小屋</title>
    <link>https://t1mmoc.github.io/tags/base64/</link>
    <description>Recent content in Base64 on Timmoc 的技术小屋</description>
    <generator>Hugo</generator>
    <language>zh-cn</language>
    <lastBuildDate>Sat, 17 Oct 2026 15:40:00 +0800</lastBuildDate>
    <atom:link href="https://t1mmoc.github.io/tags/base64/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>【AIGC】base64 变表题里出题人换的是表，不是算法：12 行的编解码器，和两个不报错的坑</title>
      <link>https://t1mmoc.github.io/posts/2026-10-17-base64-variant-table/</link>
      <pubDate>Sat, 17 Oct 2026 15:40:00 +0800</pubDate>
      <guid>https://t1mmoc.github.io/posts/2026-10-17-base64-variant-table/</guid>
      <description>base64 变表题的解法：编码流程一个字没改，换的只是那 64 个符号，所以解码器就是把密文按表换回标准字符、再走一次 b64decode——去掉空行和注释 12 行，只用标准库。这篇讲三件事：为什么这招成立（一一对应的置换必然可逆）；密文里每 4 个字符插一个 &amp;#39;=&amp;#39; 为什么照样解得开（是 b64decode 默认的非严格模式在替你兜底，加上 validate=True 当场报 Excess padding）；以及我写说明时断言「表里有重复符号会解出坏数据」，自己跑一遍却是假绿——随手构造的测试串根本没踩到丢映射的那个字符。探针能被无关信号满足，和载荷探针共用同一串字符，是同一个错误。文末附同仓库的第二个小工具：把 DiskGenius 里复制出来的十六进制转储还原成二进制文件。</description>
    </item>
  </channel>
</rss>
