知乎 - "我们检测到您此次登录异常，请您进行安全验证" 的 bug

近两天知乎的每新打开一页都会出现 "我们检测到您此次登录异常，请您进行安全验证" 对话框。(截图注: www2 只是测试， www 一样):

输入手机验证，对话框关闭，但打开新一页或点击 "查看全部 xxx 答案" 都会重复出现该验证对话框。不验证直接 X 关闭对话框也行，不过重复出现很烦。

后来察觉专栏 zhuanlan.zhihu.com 没对话框，就想到换其它 subdomain 可能可以。

MySejahtera hotspot center locator

代码: https://github.com/limkokhole/MySejahtera

中文和英文双字幕观看 YouTube 视频

我英文差， 但是又不能只看中文(讲话的人是英文，失去原味)，所以打算双字幕观看。英文字幕在 mpv 播放器下方，看到不懂的字可以望上面的中文字幕。

虽然此视频  IlU-zDU6aQ0 网页版有英文字幕以及自动翻译的中文字幕，可是旧版本的 youtube-dl 和随便两个网站 (https://downsub.com 和 https://savesubs.com) 都只能拿到英文字幕。



虽然最新版本的  youtube-dl 已经 fix 了，无论如何，要手动完成此任务，也行的：

1. 下载英文字幕 (.vtt): youtube --skip-download --write-sub --sub-lang en https://www.youtube.com/watch?v=IlU-zDU6aQ0 。

2. 在 Youtube 播放器, 变改语言边 inspect network, 得到 `api/timedtext?` 链接。

用 curl 跑链接获得 .json 格式的字幕。

3.  转换 .json 去 .srt 不需要重造轮子，浏览 https://zhuanlan.zhihu.com/p/337934938 下载某人写的 node.js 代码， `parse_subtitle.js`, 加上这三条 line:

Trace python program from log perspective

刚回答了用 -vvv debug pip：


Just a reminder to whom google this error and come here.

Let's say I get this error:

$ python3 example.py
Traceback (most recent call last):
  File "example.py", line 7, in <module>
    import aalib
ModuleNotFoundError: No module named 'aalib'

Since it mentions aalib, I was thought to try aalib:

How to play Facebook Quiz

第一种方法在重复 submit 能发出多个 messenger notification 给该朋友我玩了你的 game，而第二种方法没 notification。不过两种方法都有在 game 内置的 notification。

列出美国所有 ip 的方法

 

视频用 N 倍速看对 fps 的影响

如果播放视频时加速，对 fps 有何影响？如何预测会 dropped 多少 frames？

mpv 确实可以 speed up 后如果仍可以满足 monitor 的 refresh rate Hz 就可以不 drop frames。

不过 165 Hz 要求 gpu+cpu 很高否则也是有问题(不然 multitasking 容易 drop frame)。

而且 144 Hz 或 120 Hz 都能被常见的 24 fps 完整除 (120 Hz 能被 youtube 常见的 30 fps 除)

，只有 165 Hz 怪怪的不能整除 (https://www.svp-team.com/forum/viewtopic.php?pid=63214#p63214)。



做个小实验验证一下：

MySejahtera bug

MySejahtera 的隐私 bug，可以查看其它店的人流， 甚至更新资料。

有些非 Master branch 而看不到更新资料的页面，能通过 email 得知 `Hi contact_name`(有些填手机号)。

由于 bug 会被滥用，我就不公开方法了。(更新: 已被修复)

MySejahtera 没网络 check-in

 实验：

MySejahtera app 在没网络下，扫描二维码后， 政府还能不能收到该 check-in？

 

实验结果：

 

每次点击 "close" 按钮后的十秒， 都会调用 js 的 checkAndSync() 函数， 检查 checkInQue 数据库表之前有没有失败的请求 queue，有的话就（等多一秒）一个个调用 syncCheckIn() 函数尝试 "/clockin" API 终点请求上传。"Clear storage" 会清除该 queue，"Clear Cache" 则不会。

 

实验总结：

 

请确保点击 "close" 按钮后的十一秒后有网络，才能上传之前没网络的 check-in 给政府。即使你扫描新的二维码， 是不会包括之前没网络所累积的 check-in， 必须点击 "close" 按钮等十一秒。十一秒是开始上传的时间，上传全部需时十一秒以上。

 

Facebook 鏈接對下載質量的影響

用 youtube-dl 和 you-get 下載 4 種視頻鏈接格式:
[1] 'https://www.facebook.com/<username>/videos/123/'
[2] 'https://www.facebook.com/<username>/posts/123'
[3] 'https://www.facebook.com/permalink.php?story_fbid=123&id=123'
[4] 'https://www.facebook.com/watch/?v=123'
[5] 手動下載。

實驗結果:

怎样才能在 Facebook 上传下载最高清的图实验。

Android 上传 4 MiB (4032x3024) 的文件, PXL_20201022_141809183.NIGHT.jpg:
[1] 浏览器能下载 241 KiB (1440x1080) 的 JPEG 图。
[2] Android Facebook app 能下载 114 KiB (1080x810) 的 JPEG 图。

浏览器上传同样的 PXL_20201022_141809183.NIGHT.jpg:
[1] 浏览器能下载 509 KiB (2016x1504) 的 JPEG 图。
[2] Android Facebook app 能下载 109 KiB (1080x806) 的 JPEG 图。

实验总结：

bash -c "$pitfall"

If user use bash -c "" will easy to get unexpected result if user just copy-paste working code from existing shell session into bash -c "" (OR extend existing bash -c "") and expect it same. But if user use single quotes(outermost) consistently, then user can get rid a lot of trouble.

Facebook 新设计的 bug

如果群组组员的主页 URL 是没用户名 (譬如 https://www.facebook.com/zuck 格式) 而只有 id (譬如 https://www.facebook.com/profile.php?id=12345 格式)

，那么群组的组员页面的 "View Main Profile" 按钮是 link 去 www.facebook.com 而不是该用户的主页。需要去网址栏删除 groups/<组id>/user/ 再浏览。

如果你只有 id 那么就可以减少 (当然, 不可能完全避免) 组里 stalker 们 stalk 你主页， 反之如果你是搞宣传的且希望在组里引流去你的 profile， 则劝你放个用户名。

我转换去新设计后早就注意到这个 bug 很久了(很明显好不)，只是到现在都没去 fix 囧， fb 的员工懒到囧 😆。

万恶的 baidu

百度百度， baiduyunguanjia 协议打开网盘程序可以理解，可是你乱入 text/html (点击html 文件得经过网盘程序) 是计划通想干嘛 🎃 

汝即非 html 浏览器，亦非 html 编辑器， 想干嘛？想干嘛？ 🎃

v2ex 有人调侃 Linux 版网盘先来个硬盘扫描似乎并非调侃 🌚

【2021 更新】
skype 也有类似的情况, lolr share 你毛， 我不喜欢 share 东西囧

Google Pixel 4a 超坑人的 alarm bug

我就奇怪做么 alarm ⏰ 常没声音，原来 slider 的 alarm volume bar 要超过一半才等于 clock alarm 的第一个 volume，wth  🥶🥶🥶🤖🎃🥃


Media volume 1/3 的声音就够了，所以 Alarm volume 也跟着调 1/3， 没想到是个大坑：

与上图 slider 相应的 volume， 在 clock app 的设置是 mute 囧：

 

来个全景经典画面， 左（slider 设置）1/3, 右 (clock app 设置) 是 mute， 两者名字都称 "Alarm volume" 囧， 应该坑了不少人， 不说了我迟到了 🌚：

Catch 'Err All - universal command to check any log

之前 MCO fb 群组教人 debug 的时候无意中想到, 如果有一个命令，能收集所有常见的错误关键字来秒 grep 会超级有用。

不管你是 /var/log, 还是 logcat,  还是什么鬼程序的 log, 都能轻易看出错误的地方， 这些错误的地方值得关注为啥会错误， 而不是迷失在大量无意义的正常 log。

即便有些错误对程序来说是正常输出，我个人觉得仍然值得关心干啥会有错误字眼。而且有杀过没放过，看多好过遗漏。错误的 log 不是非常多，花不了太多时间， 而且很多是重复性的源自于同一个程序错误， 只要解决该程序问题就能大量减少该错误信息。

我知道 dmesg 可以分类， 譬如 `dmesg --facility=kern --level=emerg,alert,crit,err`。但是仍然不能说正常 log 没有值得关注的错误信息。而且我目标应付是任何程序的  log (当然不可能完美，有些字眼对某些程序或许重要/不重要而遗漏，这种情况下可以加上 -v 稍微检查是否有遗漏， 或添加排除该程序不重要的字眼)。

然后最近又要 debug log  所以就想完善它。我不熟悉 regex 无法做到 prefix 和 postfix 的 negate。且要不保留 non-match(DEBUG) 又要保留 matched line(bug) 非常困难， 网上现有的答案找了几下，也没有找到我要的答案 (有的提 `?!` 但是没有提 prefix 最重要的 `<`， 更别说提 prefix 和 postfix 有区别)，就去 UNIX stackexchange 问了大佬，重新完善了此命令。当然随着时间的推移，接触更多种类的 log，未来可以加更多遗漏的关键字或修改。

命令代码和往后的详情更新，请浏览 https://github.com/limkokhole/Catch-Err-All

你可以看到 (?<! b|dia)log(?![a-z])， 表示我要看到有 log 关键字的 line， 但是又不想包括 blog, dialog，logic, login 这些常见字眼。前面是 `?<!` ， 后面是 `?<`， 区别只是前面多了一个 `<`。要添加的时候，先检查现成有没有才修改 (比如我要 exclude "dialog"，我找到现成已有 "log"， 那就在 "log" 那里 extend， 而不是加新的 `| |` )。

 你可能会问有 "impossible" 为何没有常见的 "not possible"， 因为 "not" 已拥有自己的 `| |`。所以不需要重复加 "not possible", "not able", "not found" 之类的 | |， 省很多。想一下，有 `not `的 log  是不是很多都是跟错误(或值得关注)有关系的？就是这么个玩法。block 也是同理，有 lock 了不需要 block。改的时候要小心， 譬如 dump 是包括 core.?dump 的哦。err 可能比较常改， 所以最好分 errno  和  interrupt 出来。

还有一些比较主观的讲究， 比如 disabling, revoking ... 我觉得没那么重要，重要的是 disabled， revoked, 所以我才放 disable 而不是  disabl。还有 pause 不是很重要，毕竟只是暂停，并非如 stop 或 cancel 那么重要。放太多会很 noise  所以要取舍。

最后第二个 `\?` 是黑人问号 ?， 如果问号 ? 在 log 是正常的就要拿掉或修改。此命令主要就是 universal template，不是直接用就完美，但起码有个起点让你稍微修改就搞掂。 

最后则是常见的感叹号 "!", 排除常见的 `[ !` shell 格式和 `<! `html tag 以减少噪音， 不过仍然得保留常用来表达某些事物不等同而出错的 `!=` 符号。

有时你想了解上下文，可以加类似 -C 5 的 grep 选项或最后的 ' 前放多一个 `|` (不需要值) 即可显示全部不过仍然有搜索颜色看。

效果截图：

Longest filename test by various downloaders

[补充]

这影片说的是正常的 3 bytes 情况下，如果是故意放 4 bytes 例如 “𪍑” 字， ss youtube 少 8 个𪍑的 32 bytes (不放 PIN_id 则是 7.75 个的 31 bytes)。

you-get 则是下载错误。

观察 you-get 的代码能明显看出简单的 text[:80] 是错误的。

因为截断后的 80 * 4 bytes = 320 bytes， 仍然远远超过一般文件系统限制的  255 bytes。

此测试虽然前面是模拟 Pin ID 的数字，仍然有 263 bytes ，大于我文件系统的 255 bytes。

没有文字描述的图片没有灵魂，所以最大化的使用文件名放描述是很重要的事情。

视频可以靠播放影片弥补，或许还好（不过 ep 放在最后面可能被截断），可是类似 pinterest 的图片下载器就非常需要足够的文字描述， 否则单独的一张图片没有背景描述真的很没意思。

Pinterest 下载器

源码: https://github.com/limkokhole/pinterest-downloader

Web VS FFmpeg VS duboku-downloader

注：由于测试涉及到连续剧画面，Malaysia, Vietnam, Thailand, South Korea, Indonesia, United States, Taiwan, Philippines, India 的用户需要其它地区的 VPN 才能观看此测试视频。

mpv player 能 skip broken m3u8 chunk， 但是 mplayer, vlc, windows media player 都有卡住的问题，mplayer (vlc 没问题， 忘了 windows media player) 甚至音频在卡住的情况下继续运行，所以卡完后音频比视频快了十秒。我写的下载器通过 pad(暴力循环 17 次(事实上 16 次就够了，不过 `ValueError` 速度超快，多一个 offset 不碍事)找出需要的 16 bytes 之一， 一旦成功 decrypt 即 break) 以及 remux ts to ts 解决了这一问题。我发现 start time 变成 0 而不是保持损失的视频时间四十多分钟才能在接下来的一次性 remux ts to mp4 变成正确的时间。 remux ts to ts 需要加新 muxer mpegts ， 所以得重新编译 ffmpeg_minimal_ts_2_mp4.exe。

至于那个速度测试，与其说是我的快(纯 python 本来就不快)， 还不如说是 ffmpeg 做冗余的工作导致慢。此测试已经尽可能让 ffmpeg 发挥默认(或许有隐藏选项可是我不懂，普通用户都不懂， 基本虚设) 最好的效能， 例如第一个 m3u8 是 output .ts 而不是 .mp4 以减少不必要的 remux。至于 python 则并非第一次跑 (第一次跑肯定有点慢， 但是现实中下载都是连续的)。 不过 ffmpeg 也好不到哪里去，不是第一次跑，也直接给 m3u8 链接 (现实中， 手动或扩展找 m3u8 链接都要花时间吧)。更新: 后来才发现先转 .mp4 比先转 .ts syscalls (还没算第二次转换)少， 只是不明白之前的随便测试比较是 .ts 比较快。无论如何， 速度差不了几秒， 不然我也不会用先转 .ts 来测试， 都是慢很多。

List syscalls by `strace -c`, duboku-downloader VS ffmpeg -i .m3u8 -c copy .mp4:

我没学 C 所以看不大懂(我小白 😶)，不过先脑洞一下: 由于 FFmpeg 也必须支持 live streaming 的 m3u8 ，所以 FFmpeg 的方式可能没优化下载固定时长的 m3u8。

然后我也写了个 python 脚本分析了一下下载 .ts 速度的变化。只显示超过左边栏的差距能大于一秒的，然后右边则是当下累积的差距。能看出来，重新下载仍然是差距 ~37 秒 (最右下是  -37.6)。 此分析忽略时间格式有问题的 .ts， 包括第一个和最后二个两个，不过有其它数据足够分析了。此分析证明 FFmpeg 还是有快过我的地方，不过明显少于我快过它的地方 (右栏，~23 次我快 VS ~9 次它。 左栏则是 20 VS 12)。而且能重点分析为何第三个的 WW8CBwpZ.ts 快了 FFmpeg 近 4.7 秒， 连续则是近 7 秒。不过单体最快反而是 ffmpeg 的 5.7。



新版本的 duboku-downloader 解决了很多 bug，其中解决了 Windows 使用 ffmpeg 会出现烦人的黑窗口。首先认识了 shell=True完整的 string 可以 work。虽然 ffmpeg path 可以解决，可是 source/dest path 比较多工 (还要考虑盲目 concat 的安全性)。不过后来又发现 Windows 和 Linux 用回 list 没问题 ( Windows 用 ffmpeg full path)， 只是 Linux 用 single string 需要加上 cwd=os.path.dirname(os.path.realpath(__file__)) 。也发现 Linux 不用 ffmpeg full path 会运行 sh -c ffmpeg ... 可是竟然没有引号 no wonder 上次失败 ！ 再后来把 "ffmpeg_minimal_ts_2_mp4.exe" 嵌入 "独播库下载器.exe"， 得改用 sys._MEIPASS 才能知道 pyinstaller 默认的 ffmpeg path。以前/开头试过 binaries 也不成功，后来才知道 pyinstaller .sepc 的很多东西要用 tuple 表达， 例如:  binaries=[ ('duboku_lib\\ffmpeg_minimal_ts_2_mp4.exe', 'duboku_lib') ]，前者是 pyinstaller 找 ffmpeg_minimal_ts_2_mp4.exe 拿来 build 的路径， 后者则是 runtime 的路径 (也就是 sys._MEIPASS 的子目录)。用在 subprocess 的完整路径就需要 os.path.join(sys._MEIPASS, os.path.join('duboku_lib', ffmpeg_path) )。

项目链接: https://github.com/limkokhole/duboku-downloader

肉眼解析 QR code 的 "a"

 最近读了这篇科普文后，初学尝试用肉眼解析出简单 QR code 的 "a"。

先去这个网站输入 a，生成我们要的简单 QR。




放大：

首先找出版本号，方程式是 (格子边长 - 17) / 4, 因此上图是 (21 格 - 17) / 4 = Version 1。因此版本 2 的边长会多 4 格， 以此类推到 (177 格 - 17) / 4 = 最大的版本 40。对照某些表时，不同版本不同值， 例如 Character Count Indicator 长度， 所以需要版本号。

然后，找用来去掩码的掩模 (Mask pattern)，左上寻像图形的正下方 (或左下的正右方) 的第 3-5 格。

三格全黑表示掩模方程式是 j%3 = 0。

解读方程式是从 0, 1, 2 ... 算起，j 是 x轴, i 是 y轴。

EC (Error Correction) Level 则是左上寻像图形 (或左下的正右方) 的第 1-2 格。

两格全黑表示 11 XOR 10(即固定 Mask pattern “10”1010000010010 的左边两个 bits) = 01, 即纠错能力(仅7%)最差的 L 级。因此一眼可见: 黑黑 L(7% 👎)， 黑白 M(15%), 白黑 Q(25%), 白白 H(30% 👍)。这篇文我们不理这个。

把掩模从左上往右下盖着，黑格 1, 白格 0, XOR (即不一样才放黑, 1)， 最右边形成 (从下往上读。由于掩模右两格都是白色， XOR 后仍然一样,  所以原图不需要改。):

寻像图形 (Finder/Position pattern/marker)

全白

格式信息 (format information)

1 0 结束， 0000 0001， 表示 Data 长度只有 1 个字节。

0 0

0 0

0 0 开始 ECI Character count indicator。由于是 Version 1 且之前的 8-bit Byte Mode， 因此接着只有 8-bit。

0 0 结束，0100，对照 Mode indicators 表，0100 表示 8-bit Byte Mode。

1 0 开始 Mode indicator。

0 1 结束, 0001 1010, 表示 16+8+2=26， 对表 (或这个)即是 ISO/IEC 10646 UTF-8 编码。

0 1

1 0

0 0 开始 ECI 编码。

1 1 继续 -> 右上(1) -> 左上(1), 0111 表示 Mode Indicator 是 ECI。

1 0 开始。顺序: 右下(0) -> 左下(1)。每一行都是从右往左开始读， 不存在左往右。

扫 corner 转去左边的两 bits （从上往下读。掩模这里的两格是白黑， 所以左边不需要改， 只需想像左边纵的黑格是 1，想像右边纵的白格是 1 ):

寻像图形

全白

格式信息 (format information)

1 0 开始 Data， 01 开头属于 0bbb bbbb 的 1 个 codeword(8-bits)。

0 1

0 0

1 0 结束，0110 0001，表示 64+32+1=97，即 ASCII 的 “a”, 找到我们此次的目标。

0 0 由于剩下大于 4 够位， 所以继续 “结束符“。

0 0 结束，4 bit terminator 0000。

0 0 由于 so far 累积的总数是 36-bits ，36 (或最后的 codeword 仅是 4) 不是 8 的倍数， 所以加多 4 个 0 变成 40-bits。

0 0 结束，0000。

1 1

0 1

1 1

0 0

参考:

1. https://www.zhihu.com/question/65253283/answer/229499103

2. https://en.wikipedia.org/wiki/QR_code

3. https://www.cnblogs.com/alantu2018/p/8504373.html
4. https://web.archive.org/web/20141129033352if_/http://raidenii.net/files/datasheets/misc/qr_code.pdf

5. https://my.oschina.net/u/4087915/blog/3084215

6. https://baike.baidu.com/item/UTF-8

7. https://en.wikipedia.org/wiki/ASCII

8. https://slixurd.github.io/2013/04/26/how_the_qrcode_encode/

9. https://sourceforge.net/p/zint/tickets/128/

10. http://blog.qartis.com/decoding-small-qr-codes-by-hand/
11. https://www.qrcode.com/en/about/

Facebook - How to know who unfriend you long long time ago

Note:
If someone block you after unfriend, it still possible to see post by create new account which only added you, so there are still some possibility it will shows post of friend of you.

There are actually 2 privacy bugs here.

First bug is the search able to store deleted comment in plugins( and probably also apply to other places I don't noticed). The first bug shows the over powerful of search by post leads bug.

The second bug take further step of first bug which tick on filter by "Your Friends". This bug proved that the friend relationship never drop even after unfriend, which actually also happen if the new account add only you and unfriend you then the friend suggestion more likely is still your friends.