照片传到电脑上怎么躺倒了

手机竖着拍的一张照片，发到电脑、或者上传到某个后台，打开一看横躺着，脖子得歪 90 度。更奇怪的是：同一张图，在微信里看是正的，在某个网页的上传预览里是歪的，在同事的电脑上又是正的。

这不是"图片坏了"，也不是谁把图转了一下。像素从头到尾没变过，变的是"要不要按说明转一下"。

一、相机不知道你当时是怎么拿手机的

手机摄像头的传感器是横着装的，所有照片在存储那一刻，像素都是按传感器的方向排的——不管你是竖着举还是横着举。

那为什么竖拍的照片最后是正的？因为手机在照片里写了一句说明："这张要用 6 号方式显示"。这个说明存在 EXIF 里，字段名是 Orientation（方向）。看图软件读到这句说明，就在显示时把画面转过来。

也就是说：照片有两种状态，一种是"像素本身是正的"，另一种是"像素横着躺，但带着一个'请旋转'的标记"。

二、这句说明有 8 种写法

Orientation 的取值是 1 到 8，不只是"转 90 度"这么简单，还包含镜像：

所以"照片横躺"十有八九是这句说明写着 6（或 8），而看图的软件没理它。

三、为什么有时正、有时歪

因为不是所有软件都读这个字段。

• 浏览器、微信、手机相册：基本都读，所以你在手机上看着是正的。
• 老一些的看图软件、部分图片处理程序：不读，画出来就是横的。
• 自己写的服务端代码：更常见——只用了图像库的默认解码，而很多库默认不按 EXIF 自动转正。

这就是"同一张图，三台设备三种结果"的全部原因。它跟文件本身是否损坏无关，跟软件愿不愿意读那句说明有关。

四、做上传功能时最容易踩的三个坑

坑一：生成缩略图时没转正。 原图带着 6，前端浏览器转了，看着正常；后端拿原图直接裁成正方形缩略图，裁出来是歪的——因为后端压根没做旋转。结果就是"列表里全是歪的，点开详情又是正的"。

正确顺序是：先按 Orientation 把像素转正，再缩放/裁剪。顺序反了，裁剪框的位置也会跟着错——毕竟转 90 度之后，宽高是互换的。

坑二：转正了，但没把标记清零。 这是最阴的一个。你把像素转正、存回文件，可是 Orientation 还是 6。接下来任何支持 EXIF 的软件（浏览器、微信）都会再转一次，于是照片变成歪向另一边，或者干脆倒了。

规矩很简单：要么不动像素、只信任标记；要么动了像素，就一定把 Orientation 写成 1。两者只能选一个，不能各做一半。

坑三：以为带标记就一定是歪的。 有些导出工具会把像素转正，却忘了清标记；也有些工具清得很干净。面对历史数据，你没法靠"有没有这个字段"来判断。所以处理旧图时，比较稳的做法是统一走一遍"解码 → 按标记转正 → 重编码 → 标记置 1"，让所有图落到同一个状态，后面的代码就不用再猜。

五、前端也有类似的分工

浏览器 CSS 里的 image-orientation 默认是 from-image，意思是"按图片自带的说明显示"。所以 <img> 显示通常是正的。

但如果你把图放进 <canvas> 做处理，或者自己算尺寸做裁切预览，就得自己处理这个标记——canvas 拿到的是像素，它不认识 EXIF。判断宽高的时候也要注意：一张竖拍的照片，文件里的宽高可能是"宽 > 高"的，因为你看到的方向是转过来的。

六、所以下次遇到"照片躺倒"

按这个顺序看，基本一次定位：

• 看图片的存储宽高：宽比高大，但你记得是竖着拍的——大概率就是带了 6 / 8 标记。
• 看 Orientation 的值：1 说明像素已经是正的，那"歪"就出在别的地方（比如上游裁剪时算错了）。
• 看处理链路里哪一步碰过像素：裁剪、缩放、加水印、转格式，任何一步碰过，都要检查那一步之后标记有没有被正确处理。

收尾

一张照片"歪了"，本质是两拨人对同一份数据的理解不一致：拍的那一方把方向写进了说明，看的那一方没读说明。

这类问题在工程里到处都是——数据里带着元信息，而处理链路只认主体、不认说明。修的时候也不用想得太复杂：要么遵守说明，要么把说明变成事实，然后删掉说明。最怕的是两边各做一半，谁也说不清最后该转到几度。

依据：EXIF 规范中的 Orientation（274）字段取值为 1–8，分别对应正常、水平镜像、180°、垂直镜像、镜像+顺时针 90°、顺时针 90°、镜像+逆时针 90°、逆时针 90°；手机竖拍通常写入 6 或 8。浏览器 image-orientation: from-image 为默认值。