小写字母节省数据
把文本转成小写确实可能稍微提高压缩率，因为它去除了压缩器需要编码的大小写变化，但评论者指出，这本质上只是丢弃信息，而不是小写本身有什么特殊性质。许多人认为，可读性、排版规范以及人名的正确大小写，远比微小的带宽收益更重要；而且改成全大写对大小也会有类似影响。讨论还延伸到信息论、QR code 编码模式、Unicode 边缘情况（如土耳其语 “i” 和 Han unification），以及把字节节省与碳足迹估算联系起来的局限性。
可读性与大小写的使用
- 许多人不同意小写会“显著”提升可读性；也有人觉得，只要习惯了，全小写或全大写一样容易辨认。
- 另一些人表示自己对 title case 有阅读困难，更喜欢标题和正文使用 sentence case。
- 公路标志研究（美国高速公路标志）常被引用为证据，说明混合大小写比全大写更易读，不过其机制（词形识别 vs 字母级识别）仍有争议。
- 还有几位指出，许多使用拉丁字母的语言（如法语、西班牙语、意大利语）标题通常本来就用 sentence case，也能很好地使用，而不需要特殊的 title-case 规则。
压缩、信息论与“节省数据”
- 核心观点：小写化（或任何规范化）本身并不会天然节省数据；去除区分（例如大小写）会降低熵并改善压缩。全大写也会产生同样效果。
- 多位评论者强调这是一种有损处理：你并不总能还原原始大小写，而大小写在语义上可能很重要（例如“jack”与“Jack”）。
- 有人认为，一个好的压缩器本来就应该利用“句号 + 空格 + 大写字母”这类模式，因此手动把大小写抹平在原则上没那么有说服力。
- 还有人指出，语义感知或基于词典的方案带来的收益，可能远远超过大小写规范化的任何增益。
技术细节：HTML、SVG、Brotli、QR Code
- 对于 HTML 的 doctype 和属性，有评论者举例说明 gzip 与 Brotli 的行为可能不同；Brotli 的静态词典可能偏好常见但并非最优的模式（例如
<!DOCTYPE html>）。 - 在 SVG 路径数据中，盲目把命令转成小写被称为“靠不住”；选择绝对坐标还是相对坐标，以及精简语法，往往比大小写更重要。
- QR code 是个例外：它们的“字母数字模式”能更高效地编码仅大写的文本，从而生成更小/更不密集的码。
姓名、Unicode 与区域设置问题
- 经过大小写折叠的姓名（例如 “VINCENT VAN GOGH”）会丢失重要的大小写细节，尤其是像 van/de/von 这类词素，其用法会因语言和地区而异。
- Unicode 的大小写映射很棘手，而且依赖区域设置（例如土耳其语的带点/不带点 “i”，德语 ß）。简单地“规范化为大写/小写”可能无法正确往返。
- Han unification 和国家字符集标准化被提及为更广泛的文化偏置与有争议统一取舍的例子。
象棋压缩旁支话题
- 一条很长的子讨论深入探讨了象棋局面和棋谱的比特级编码：专门的棋子编码、兵形结构技巧、走法索引方案，以及之后再使用通用压缩器。
- 它说明领域特定建模确实可能胜过朴素编码，但复杂度也会随之上升，而且收益会递减。
环境与元讨论
- 有人喜欢这篇文章的压缩技巧和表述方式；也有人认为，如果把它理解成写作风格建议，那么这个前提是误导性的，甚至令人恼火。
- “节省的字节 = 节省的 CO₂” 这种说法被批评为过度简化；每字节对应的真实能耗和碳影响被认为高度不确定，并且依赖整个技术栈。
- HN 自己的标题大小写处理/扭曲也被提到，作为人们常常不喜欢的自动大小写变换的例子。