©CC BY-NC-SA 4.0
🚩加入 Nostr!moe 社区: join.nostr.moe
🚩加入 Nostr!moe 社区: join.nostr.moe
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
Google 去年在 Chromium 99+ 开始强制启用了证书透明度(Certificate Transparency, CT)检查, 使得对用户证书不信任的 Android 现在更加难以在 Chrome 和基于 Chromium 的浏览器上进行中间人网络分析. 分析工具也要重新改变流量路由的方式.
● Android Chrome 99 expands Certificate Transparency, breaking all MitM dev tools | HTTP Toolkit
● ref: Android Chrome 99 expands Certificate Transparency, breaking all MitM dev tools | Hacker News
#Chromium #Android
via CXPLAY's Memos
● Android Chrome 99 expands Certificate Transparency, breaking all MitM dev tools | HTTP Toolkit
● ref: Android Chrome 99 expands Certificate Transparency, breaking all MitM dev tools | Hacker News
#Chromium #Android
via CXPLAY's Memos
