活动存储/清理文件 url

Posted 2023-02-24

【中文标题】活动存储/清理文件 url

【英文标题】：active storage / clean files url

【发布时间】：2018-09-20 21:57:22

【问题描述】：

关于同一个问题的多个问题，主动存储返回文件url的方式

现在使用默认设置，以下（云或本地）以某种方式返回以下内容：

_domain/_path/_superlong_hash/_original_filename._ext

鉴于回形针或许多其他现有的 gem，_path/_superlong_hash/_original_filename._ext 部分可以自定义，最终可能会在任何文件的干净 url 中结束

意思是：

有没有办法用更自定义的东西“代理”_path？ 有没有办法避免_superlong_hash？ 有没有办法即时（或上传）自定义文件名？

要使其成为单行，如何自定义文件网址？

我在这里和那里看到人们最终创建自定义控制器来提供具有体面 url 的文件，但让我们承认这是不行的（恕我直言）

【参考方案1】：

我希望 ActiveStorage 很快证明我错了，但在编写 Rails 5.2 时，直接的答案似乎是你必须选择“不通过”选项，将你自己的控制器组合在一起并大量修补 ActiveStorage 以暴露文件。

有关代理，请参阅：

https://github.com/rails/rails/issues/31419

https://github.com/rails/rails/pull/30465

尤其是 georgeclaghorn 的反应很有趣

重命名文件：

@user.avatar.blob.update(filename: 'NewFilename.jpg')

操纵 _superlong_hash / url

我没有很好的答案。尽管 ActiveStorage 使上传文件变得非常容易（并且在某种程度上易于操作），但它却将 Rails 固执己见的软件哲学推向了边缘，使得通过抽象方法生成 url 来绕过它的晦涩难懂。 ActiveStorage 不提供内置方法来执行基本操作，例如生成后的文件和变体的永久或直接链接。因此，文件/图像缓存和漂亮的 url 目前似乎无法通过 ActiveStorage 实现开箱即用。

【讨论】：

恕我直言，我想补充一点，我认为 ActiveStorage 目前不推荐给任何人，但开发人员的应用程序与 Basecamp 的行为非常精确匹配。此外，ActiveStorage 的路由劫持是一个主要问题/错误github.com/rails/rails/issues/31228 对于其他所有人来说，CarrierWave 是一个更明智和可配置的选项。

持有相同观点，但基于越来越多的人将使用代理服务（cloudinary、imgix 等...或任何其他等效服务）这一事实，事情可能会开始ONLY 对上传部分有意义。这并不能使它成为一个完美的解决方案，我们都可以同意，如果必须满足所有要求，主动存储会以某种方式丢失一些东西