Google chrome Chrome图像EXIF定位问题

我正在构建一个显示图片的web应用程序。大多数照片都是通过智能手机拍摄的，并且有EXIF旋转信息。 我正在公开一个url，该url返回图像blob而不进行修改

我注意到，当我把这个url放在img标签中时，Chrome并不尊重EXIF方向数据，但当我把这个url放在Chrome地址栏中时，它会显示一个带有图像的页面，然后它会尊重EXIF方向

很抱歉，我无法共享该图像，我将尝试查找另一个可以共享的示例

---

有人注意到这个问题吗？

这种行为的原因是，只有当图片作为主文档直接显示在浏览器选项卡中时，Chrome才会根据EXIF数据自动旋转图片

跟踪此实施的相关铬问题如下：

在未来，Chrome（和其他浏览器）将允许开发者对通过具有CSS图像旋转属性的img标签显示的图像启用自动旋转：

---

更新：自Chrome 81（于20年5月13日移动到稳定状态）起，

img

标签和

反向图像

标签都支持此行为

下面是一个例子：这对我来说似乎是一个大问题。我正在建立一个数据库，里面有数千张不同方向的图片。现在，我必须使用Imagemagick的convert with-auto orient在导入之前修复它们…相关说明，这可能对某些人有用：如果您正在使用

iMazing HEIC Converter

或类似工具转换从iOS设备发送的图像，请确保取消选中

保留EXIF数据

，因此，当您尝试在chrome中查看时（例如，在上传过程中），您的图片不会被翻转。您可以在

Get info

中看到所选图像的差异，当保存EXIF数据时，它应该包含更多数据。一年半后，chrome仍然不支持它；（看起来只有在遥远的将来才会出现这种情况。为什么在浏览器中显示HTML内部的图像（忽略EXIF方向）与在浏览器选项卡中单独显示图像（应用EXIF方向）之间存在不一致？是因为操作系统处理图像显示，而图像本身就是图像吗？令人困惑的是，这个问题已经存在了近10年，而且没有一个不涉及图像处理（或JS操作，这有它自己的问题）的解决方案。这个问题不是一个优先事项，在现代浏览器中可能永远不会像W3.org建议的那样得到纠正：

注意，有些设备会“标记”带有一些元数据的图像指示其正确方向，因此图像查看软件可以自己进行必要的转换。由于旧式兼容性限制，默认情况下，Web浏览器需要忽略此数据。此规范的未来级别预期会有一个值，该值应用transformat指定的元数据自动旋转。

难道没有可以使用的前缀吗？谢谢你这么说！我刚刚在IE和Firefox中的一个Web应用程序中遇到了一个问题，因为我的代码可以正确旋转图像，但在Chrome中，图像现在会旋转两次-在Chrome中，根据我们的代码，这意味着它不会正确旋转。好吧，而且似乎MDN不赞成图像方向css属性。