©CC BY-NC-SA 4.0
🚩加入 Nostr!moe 社区: join.nostr.moe
🚩加入 Nostr!moe 社区: join.nostr.moe
HttpCanary 作者的新作品. 基于 Flutter 和 C++ 开发, 界面相对现有的同类工具都很「先进」. 目前支持 Windows, macOS, Linux, 计划支持移动端(iOS, Android).
定价层分为免费社区版, 专业版(¥79.9/年), 企业版(¥59.9/年, 三许可起). 订阅制计费, 移动端页面上称 "将作为桌面端的订阅赠品".
● 网站: 先进API生产力工具 | Reqable
● GitHub: reqable/reqable-app: Reqable issue track repo
#software #Windows #Linux #macOS
via CXPLAY's Memos
在中国大陆使用广告拦截器拦截合法网络广告是违法的:
第十六条 互联网广告活动中不得有下列行为：
● （一）提供或者利用应用程序、硬件等对他人正当经营的广告采取拦截、过滤、覆盖、快进等限制措施；
● （二）利用网络通路、网络设备、应用程序等破坏正常广告数据传输，篡改或者遮挡他人正当经营的广告，擅自加载广告；
● （三）利用虚假的统计数据、传播效果或者互联网媒介价值，诱导错误报价，谋取不正当利益或者损害他人利益。
----------------------
国家工商行政管理总局令（第87号）互联网广告管理暂行办法__2016年第29号国务院公报_中国政府网
----------------------
#形势政策
via CXPLAY's Memos
第十六条 互联网广告活动中不得有下列行为：
● （一）提供或者利用应用程序、硬件等对他人正当经营的广告采取拦截、过滤、覆盖、快进等限制措施；
● （二）利用网络通路、网络设备、应用程序等破坏正常广告数据传输，篡改或者遮挡他人正当经营的广告，擅自加载广告；
● （三）利用虚假的统计数据、传播效果或者互联网媒介价值，诱导错误报价，谋取不正当利益或者损害他人利益。
----------------------
国家工商行政管理总局令（第87号）互联网广告管理暂行办法__2016年第29号国务院公报_中国政府网
----------------------
#形势政策
via CXPLAY's Memos
现在都很流行用在线的 DNS 服务器比如 AdGuard Home 来屏蔽广告. 但是如果能自己管理 hosts 文件, 那就不会用这种办法. 不过现在没办法方便地管理 hosts, 就还是非常麻烦. Android 上有 AdAway, Windows 上好像没找到这类专门处理 hosts 的软件.
但是同时 hosts 的局限性也很大, 复杂拦截的情况下很难适应, 最好还是选择用专门的服务处理. #吐槽
但是同时 hosts 的局限性也很大, 复杂拦截的情况下很难适应, 最好还是选择用专门的服务处理. #吐槽
两个 JSONPath 工具:
● 查询: https://jsonpathfinder.com/
● 验证: https://jsonpath.com/
#software #web #JSON #opensource
via CXPLAY's Memos
● 查询: https://jsonpathfinder.com/
● 验证: https://jsonpath.com/
#software #web #JSON #opensource
via CXPLAY's Memos
Windows 下的 UTF-8 编码问题
----------------------
这几天又遇到 Windows 下的字符编码问题了, 于是还是决定记录一下.
----------------------
由于 Windows NT 发布时 UTF-8 甚至都没有出现, 所以微软选择 Unicode 的时候用了 UTF-16. 虽然现在 Windows 的区域设置里有一个选项能够让 Windows 默认使用 UTF-8 来显示字符, 但直到今天 Windows 11 这个选项都还是 beta 状态不会给你默认启用.
在简体中文的设置下 Windows 默认使用
系统首选的编码是
但我也还记得我很久之前在 Windows 10 上开启过这个 UTF-8 支持选项, 但后来不知道为什么又主动去关掉了, 原因已经记不清楚了, 可能等以后踩到坑才会想起来吧.
#note #Windows #Python
via CXPLAY's Memos
----------------------
这几天又遇到 Windows 下的字符编码问题了, 于是还是决定记录一下.
----------------------
由于 Windows NT 发布时 UTF-8 甚至都没有出现, 所以微软选择 Unicode 的时候用了 UTF-16. 虽然现在 Windows 的区域设置里有一个选项能够让 Windows 默认使用 UTF-8 来显示字符, 但直到今天 Windows 11 这个选项都还是 beta 状态不会给你默认启用.
在简体中文的设置下 Windows 默认使用
cp936(GBK) 代码页, 英语设置下使用 cp850 或者 cp1252(Windows-1252). 如果开启了区域设置里的 UTF-8 支持, 则会变成 cp65001(UTF-8). 当初为了标准化各种字符集名称才使用系统内的代码页进行编号, 但 Unicode 出现后还是继续用代码页, 于是出现了这种盛况:PS C:\Users\CXPLAY> python -c 'import locale; print(locale.getpreferredencoding()); import sys; print(sys.getdefaultencoding())'
cp65001
utf-8
系统首选的编码是
cp65001, Python 解释器默认编码是 utf-8, 所以说 cp65001 等于 UTF-8, 又不等于 UTF-8?但我也还记得我很久之前在 Windows 10 上开启过这个 UTF-8 支持选项, 但后来不知道为什么又主动去关掉了, 原因已经记不清楚了, 可能等以后踩到坑才会想起来吧.
#note #Windows #Python
via CXPLAY's Memos
关于 URL 的大小写问题
1. W3C 写道: "一般来说, URL 是区分大小写的(机器名除外). 有些 URL 或 URL 的某些部分可能不区分大小写, 但要识别这些 URL 或 URL 的大小写可能并不容易. 用户应始终注意 URL 是区分大小写的." [1]
2. Google 对于搜索引擎索引: 即使不同大小写的 URL 指向完全相同的资源, 它们也始终被搜索引擎认为是完全不同 URL. 即使索引会尝试抓取所有的链接, 但对于指向相同资源的 URL 最终也要需要网站管理员选择保留其中一个, 这个过程被称为 "标准化". 而在 robots.txt 中对路径大小写也是敏感的. [2]
3. RFC 1738 "统一资源定位器(URL)" 写道: "URL 包含正在使用的协议名(scheme), 后跟冒号, 然后是一个字符串(协议具体实现), 其解释取决于协议. 协议名由字符: 小写字母 "a" ~ "z", 数字和字符加号("+"), 句号(".")和连字符("-"). 为提高弹性, 程序解释 URL 时应将协议名中的大写字母等同于使用小写字母(例如: 允许使用 "HTTP" 和 "http")." [3]
4. RFC 4343 "域名系统(DNS)域名系统不区分大小写的说明". [4]
5. RFC 2616 "超文本传输协议(HTTP)" 写道: (URI 比较) 在比较两个 URI 以确定是否匹配时, 客户端应使用区分大小写的 8 比特组逐个比较整个 URI, 但以下情况例外: [5]
● 空端口或未给出的端口等同于该 URI 引用的默认端口;
● 主机名的比较必须区分大小写;
● 协议名称的比较必须区分大小写;
● 空的 abs_path 相当于 "/" 的 abs_path.
———
● ref: Should URL be case sensitive? - Stack Overflow
● Windows 和 macOS 使用不区分大小写的文件系统, Unix/类Unix使用的文件系统区分大小写. (Git is case-sensitive and your filesystem may not be - Weird folder merging on Windows - Scott Hanselman's Blog)
● Netlify 部署站点路径不区分大小写. (My URL paths are forced into lowercase - Support - Netlify Support Forums)
● Cloudflare Page 部署站点路径区分大小写.
● Vercel 部署站点路径区分大小写.
● Amazon S3 进行静态托管时, 引用储存桶名称定位时区分大小写. (Access Denied error when using an S3 static website endpoint | AWS re:Post)
#note
via CXPLAY's Memos
1. W3C 写道: "一般来说, URL 是区分大小写的(机器名除外). 有些 URL 或 URL 的某些部分可能不区分大小写, 但要识别这些 URL 或 URL 的大小写可能并不容易. 用户应始终注意 URL 是区分大小写的." [1]
2. Google 对于搜索引擎索引: 即使不同大小写的 URL 指向完全相同的资源, 它们也始终被搜索引擎认为是完全不同 URL. 即使索引会尝试抓取所有的链接, 但对于指向相同资源的 URL 最终也要需要网站管理员选择保留其中一个, 这个过程被称为 "标准化". 而在 robots.txt 中对路径大小写也是敏感的. [2]
3. RFC 1738 "统一资源定位器(URL)" 写道: "URL 包含正在使用的协议名(scheme), 后跟冒号, 然后是一个字符串(协议具体实现), 其解释取决于协议. 协议名由字符: 小写字母 "a" ~ "z", 数字和字符加号("+"), 句号(".")和连字符("-"). 为提高弹性, 程序解释 URL 时应将协议名中的大写字母等同于使用小写字母(例如: 允许使用 "HTTP" 和 "http")." [3]
4. RFC 4343 "域名系统(DNS)域名系统不区分大小写的说明". [4]
5. RFC 2616 "超文本传输协议(HTTP)" 写道: (URI 比较) 在比较两个 URI 以确定是否匹配时, 客户端应使用区分大小写的 8 比特组逐个比较整个 URI, 但以下情况例外: [5]
● 空端口或未给出的端口等同于该 URI 引用的默认端口;
● 主机名的比较必须区分大小写;
● 协议名称的比较必须区分大小写;
● 空的 abs_path 相当于 "/" 的 abs_path.
———
● ref: Should URL be case sensitive? - Stack Overflow
● Windows 和 macOS 使用不区分大小写的文件系统, Unix/类Unix使用的文件系统区分大小写. (Git is case-sensitive and your filesystem may not be - Weird folder merging on Windows - Scott Hanselman's Blog)
● Netlify 部署站点路径不区分大小写. (My URL paths are forced into lowercase - Support - Netlify Support Forums)
● Cloudflare Page 部署站点路径区分大小写.
● Vercel 部署站点路径区分大小写.
● Amazon S3 进行静态托管时, 引用储存桶名称定位时区分大小写. (Access Denied error when using an S3 static website endpoint | AWS re:Post)
#note
via CXPLAY's Memos
#issue_genshinnav
收到了一个新的条目提交, 但检查之后决定暂时不会加入导航:
- 世界树: https://hoyo.life/
由于提交者没有留下联系方式, 并且由于属于公开项目, 在此留下不加入导航的原因:
> 站点属于内容/维基型, 项目和项目站点域名建立时间过于早期, 没有经历持久维护. 但我站(genshin.cx.ms)会持续关注这个项目的发展, 直到这个站点的域名首年到期节点(2024-07-29)来临, 如果此时这个项目依旧保持稳定持续的发展, 那么导航页会将其收录.
收到了一个新的条目提交, 但检查之后决定暂时不会加入导航:
- 世界树: https://hoyo.life/
由于提交者没有留下联系方式, 并且由于属于公开项目, 在此留下不加入导航的原因:
> 站点属于内容/维基型, 项目和项目站点域名建立时间过于早期, 没有经历持久维护. 但我站(genshin.cx.ms)会持续关注这个项目的发展, 直到这个站点的域名首年到期节点(2024-07-29)来临, 如果此时这个项目依旧保持稳定持续的发展, 那么导航页会将其收录.
How to Favicon in 2023: Six files that fit most needs
#article #read
#article #read
evilmartians.com
How to Favicon in 2026: Three files that fit most needs—Martian Chronicles, Evil Martians’ team blog
Prefer SVG over PNG, trust browsers to downscale, drop obscure formats—the ultimate, exhaustive guide to favicons for modern web. Includes steps for static HTML and Webpack.
调整了结构, 添加了第三种实现, 默认为 index.html, 现在有:
- python: https://static-index-demo.pages.dev/index.html
- Snap2HTML: https://static-index-demo.pages.dev/index2.html
- tree: https://static-index-demo.pages.dev/index3.html
- python: https://static-index-demo.pages.dev/index.html
- Snap2HTML: https://static-index-demo.pages.dev/index2.html
- tree: https://static-index-demo.pages.dev/index3.html
Snap2HTML 只支持 Windows, 替代品 LinuxDir2HTML 对特殊字符支持不齐全并且不支持自定义基础路径, 自动化构建还存在问题.
tree 能很好地生成基本的 HTML, 但是有些构建系统没有安装 tree, 可能直接构建不了(Cloudflare Page 使用 v1 构建环境可以使用 tree, v2 不再提供预设框架之外的软件和语言环境). #吐槽
tree 能很好地生成基本的 HTML, 但是有些构建系统没有安装 tree, 可能直接构建不了(Cloudflare Page 使用 v1 构建环境可以使用 tree, v2 不再提供预设框架之外的软件和语言环境). #吐槽
用 Snap2HTML 和 tree 生成的两种静态文件索引(一份 Python-3.11.4 源代码):
Snap2HTML: https://static-index-demo.pages.dev/index.html
tree: https://static-index-demo.pages.dev/index2.html
Snap2HTML: https://static-index-demo.pages.dev/index.html
tree: https://static-index-demo.pages.dev/index2.html
Windows 上的 Snap2HTML: https://www.rlvision.com/snap2html/about.php
Linux 上的 Snap2HTML 替代品 LinuxDir2HTML: https://github.com/homeisfar/LinuxDir2HTML
Linux 上的 Snap2HTML 替代品 LinuxDir2HTML: https://github.com/homeisfar/LinuxDir2HTML
