答案1
虽然 TCP（http/https 所基于的协议）以校验和的形式进行错误检测机载错误（触发重传），它并非万无一失。这种情况非常罕见，但同一个数据包中的多次位翻转仍可能导致有效的校验和。如果数据包的其余部分仍未损坏，这些错误可能会一路传播到您的应用程序中。我在这里方便地跳过了传输较低层的错误检测/纠正。
一般来说，加密算法包括更强大的校验和，作为数据安全的一部分。TLS/SSL（通过 TCP）当然有，所以你的结论在技术上是正确的。
但是，请注意这种情况非常非常罕见；与（非 ECC）RAM、SATA 电缆和磁盘存储（服务器和客户端）中的错误一样少见。出于可靠性考虑，在不针对其他潜在问题的情况下切换到 https 是愚蠢的，并且永远无法实现“100%”的可靠性。
根据我的经验，原因很可能是系统的其他部分（处理上传数据的应用程序、可能是数据库中的静默格式转换，...）。
整个问题也适用于非http协议。
答案2
顺便说一句——你引用的文章已有 11 年多了。
我从未听说过 HTTPS 比 HTTP 更可靠（甚至从未听说过 HTTP 不可靠）——所以我认为这不会有什么区别。然而我可能错了。
但我想说的是，在你开始指责协议之前，你是否绝对确定你的上传程序或应用程序没有导致问题？例如，我以前遇到过 PHP 中令人惊讶的下载/上传问题，这些问题令人困惑，但最终很容易解决。
您也没有提到您实际上传的内容、其大小以及发生的损坏程度。