首页 / 资讯中心 / 文章详情

8cm等于多少像素?像素与厘米换算、DPI/PPI与印刷屏幕场景解析

8cm等于多少像素?像素与厘米换算、DPI/PPI与印刷屏幕场景解析 ★ FEATURED ARTICLE
上周改一版宣传物料设计在群里甩了一句“这张图按 8cm 宽出给我像素值。”底下三个人回了三个数——227、302、945。谁都没算错可谁也只对了一半。像素和厘米的换算就是这么个东西它表面上是道除法题实际上是一道“你打算把这 8cm 放在哪儿”的工程题。放在网页上、印在纸上、贴在手机屏幕上答案能差出四倍。这篇就把8cm 等于多少像素这件事从头拆一遍公式怎么来的、不同场景该套哪个密度、设计稿和前端怎么对齐、以及我自己在这些换算上栽过的几个跟头。看完你至少能做到两件事——别人报个厘米数你能立刻给出靠谱像素值以及别人给你像素值你能反推它到底能不能用。1. 8cm 到底是多少像素先接受“没有唯一答案”1.1 三个人给出三个数其实都没毛病先把结论摆出来8cm 换算成像素必须附带一个密度参数否则这个换算不成立。密度就是常说的 DPI 或 PPI前者多用于印刷后者多用于屏幕本质都是“每英寸塞多少个点”。按最常用的几个密度算一遍8cm 分别对应密度DPI/PPI典型用途8cm 对应像素精确值实际取整72早期屏幕基准、部分文档默认值226.7722796CSS 规范锚点、Windows 逻辑分辨率302.36302120低精度喷绘、部分投影素材377.95378150普通办公打印、草稿样张472.44472200中等质量彩页629.92630300商业印刷标准944.88945350精细画册、高档包装1102.361102600线稿、条码、精细纹理1889.761890那张表里 227 是 72DPI 的答案302 是 CSS 里8cm被浏览器解析出来的值945 是按商业印刷 300DPI 算的。三个人各自站在自己的场景里说话谁也没错错的是没把场景说清楚。我现在的习惯是只要有人问“X 厘米是多少像素”第一句先反问这个是给屏幕看的还是给打印机看的这一句能省掉后面八成的返工。1.2 像素是“点”厘米是“长度”中间缺的那一环叫密度理解这件事的关键是把两个概念分清楚。像素是离散的计数单位它没有物理尺寸。一个像素可以小到肉眼看不见也可以大到像马赛克砖。它只回答“有多少个点”不回答“有多大”。厘米是连续的物理长度它只回答“有多长”不回答“由多少个点构成”。要把这两者接上必须引入第三个量单位长度里塞多少个点也就是密度。三者关系是一条很朴素的式子像素数 物理长度英寸 × 密度每英寸点数厘米要先换成英寸因为密度的分母是英寸。1 英寸 2.54 厘米这一步是所有换算的地基记错这一个数后面全盘皆输。打个生活化的比方像素像是地砖的块数厘米像是房间的米数密度就是“每米铺几块砖”。同一个 8 平米的房间铺 30×30 的小砖和铺 80×80 的大砖块数完全不同但房间还是那个房间。你问“8 平米需要多少块砖”不告诉我砖多大我只能反问你。1.3 为什么“改图片 DPI”不会让图变清晰这是我在带新人的时候最常纠正的一个误解。很多人以为把一张图的 DPI 从 72 改成 300图就变高清了。实际上一张图的总像素数是写死的改 DPI 只改变了它在打印时默认铺开的物理尺寸。举个具体例子一张 1200×1200 像素的图元数据标 72DPI 时软件默认按 1200÷72 ≈ 16.7 英寸约 42cm宽来铺你把 DPI 改成 300软件就按 1200÷300 4 英寸约 10cm宽来铺。像素一个没多只是“默认尺寸”缩水了看起来变密了而已。反过来说一张手机拍的 4000×3000 照片元数据里可能写着 72DPI但这不代表它只能印 42cm 宽。你要印 8cm 宽需要 8cm 对应的像素数4000 像素远远够用绰绰有余。判断一张图能不能用看的是总像素数够不够不是看元数据里那个 DPI 数字。我自己的检查方法很土但很有效拿到图先看像素尺寸用成品尺寸反算密度。8cm 宽、945 像素的图密度就是 945 ÷ (8÷2.54) ≈ 300DPI合格如果只有 400 像素那密度才 127DPI印出来会发虚。2. 把公式拆开手算 8cm 的完整推导路径2.1 从 1 英寸 2.54 厘米推出通用式子推导过程没什么玄机两步走第一步把厘米换成英寸英寸 厘米 ÷ 2.54 8cm ÷ 2.54 3.1496 英寸第二步英寸乘以密度得到像素像素 英寸 × DPI 3.1496 × 300 944.88合并成一个式子就是像素 厘米 ÷ 2.54 × DPI反过来已知像素求厘米厘米 像素 ÷ DPI × 2.54这两条式子是整篇文章的核心建议直接抄在便签上。实际工作中百分之九十的换算都是这两条的变形。拿 8cm 依次代进去验算一遍跟前面表格里的数字对得上说明路子是对的。我在教别人的时候会强调别背结果背式子。结果会忘式子推一遍只要十秒。2.2 CSS 里的 cm 和 mm 是“名义单位”跟尺子量出来的不一样这一段是网页方向的人最容易踩的坑。CSS 规范里明确规定了一组绝对单位的换算关系1in 96px1cm 96/2.54 ≈ 37.795px1mm 3.7795px1pt 1/72in ≈ 1.333px1pc 12pt 16px。按这个规定width: 8cm在浏览器里就是 302.36px。问题在于这个 96px 是规范写死的锚点跟设备真实的物理密度没关系。你把浏览器窗口拖到不同显示器上8cm元素的物理宽度会跟着变因为浏览器根本不问显示器到底多大、每英寸多少个点。它只认“1 英寸等于 96 个 CSS 像素”这条规矩。所以如果你在网页里用cm想做出“拿尺子在屏幕上量正好 8 厘米”的效果基本不可能。这是 CSS 单位的设计取舍不是 bug。那 CSS 里这些绝对单位还有没有用有但主要用在打印样式上。写media print的时候用cm、mm、pt描述页面尺寸和字号是有意义的因为这时候浏览器会跟打印系统交接真实尺寸。我做过一个标签打印的页面成品是 8cm×5cm就是用page { size: 80mm 50mm; }配合mm单位做的打出来拿尺子量基本准。2.3 三个容易算错的地方取整方向、四舍五入、单位错位手算的时候有几个细小但致命的问题我列一下自己遇到过的。取整方向。算出来 944.88 像素取 944 还是 945印刷场景我建议向上取整宁多一点不能少。少 0.12 个像素听起来无所谓但如果是一张整版图尺寸差一点点在拼版时会被拉伸肉眼能看出来。屏幕场景反过来向下取整更安全避免多出一个像素撑破容器触发换行。四舍五入的累积误差。如果一版物料里有几十个元素都按厘米标注、都要换算每个都四舍五入误差会累积。我一般保留两位小数参与后续计算只在最终输出时取整。手算的话中间过程别急着舍入。单位错位。这是最隐蔽的一种。有些文档写的“8cm 需要 302 像素”那个 302 是按 96DPI 算的如果你把它当成 300DPI 的结果拿去印刷实际印出来宽度只有 2.56cm 左右缩了三分之二。看到任何换算结果第一件事是确认它用的是什么密度而不是直接拿来用。我见过一个更离谱的案例有人把毫米当成厘米输入8mm 算成了 8cm 的像素值印出来的字大了一圈整批物料报废。从那以后我给自己定了条规矩——所有尺寸标注必须带单位表格里单独设一列写单位不允许裸数字。3. 分场景套用印刷、网页、移动端、设计稿各走各的路3.1 印刷品8cm 按 945 像素起稿顺手把出血算进去印刷是这套换算里要求最严的场景因为它有物理交付物错了没法改。商业印刷的通用标准是300DPI意思是每英寸 300 个点肉眼在正常阅读距离下已经看不出颗粒。所以8cm 宽在印刷场景下就是 945 像素。实际起稿的时候还要多算两笔第一笔是出血。印刷品裁切会有 1~3mm 的偏差所以设计稿要在成品尺寸外扩一圈通常上下左右各留 3mm。8cm 宽 左右各 3mm 8.6cm对应像素是 8.6 ÷ 2.54 × 300 ≈ 1016 像素。少了这一圈裁切偏一点就会出现白边。第二笔是安全区。重要的文字、logo 要离裁切线至少 3~5mm不然有可能被切到。这个距离同样要换算成像素来做参考线3mm ≈ 35 像素300DPI 下。有一张常用尺寸的对照表我常年贴在显示器边上成品尺寸300DPI 像素含 3mm 出血说明名片 90×54mm1123×674出血后 96×60mm明信片 148×100mm1819×1252出血后 154×106mmA5 210×148mm2551×1819出血后 216×154mmA4 210×297mm2551×3583出血后 216×303mmA4 那一行的 2551×3583 是行业里被引用最多的数字之一很多人背下来直接用。但我建议还是理解着记297mm 6mm 303mm303 ÷ 25.4 × 300 ≈ 3578.7向上取整到 3583 是因为有些流程会额外留一点余量。还有一个容易被忽略的点印刷用 CMYK屏幕用 RGB。你按 945 像素做的 RGB 图转成 CMYK 之后颜色会变尤其是鲜艳的绿色和蓝色。所以真正交付前我一般会先转色再检查一遍别等印出来才发现偏色。3.2 网页与 CSS96PPI 是写死的锚点别指望物理精确网页这边的规则前面提过1cm 37.795px8cm 302.36px。这个数值在所有遵循规范的浏览器里是一致的可以放心用。但有一个现实问题用户的实际屏幕密度的确在变。一台普通的办公显示器可能是 96PPI一台高分屏笔记本可能是 220PPI手机更是 400PPI 往上。同样是 302 个 CSS 像素在不同设备上占的物理宽度能差两三倍。所以我做网页时的原则是能用相对单位就别用绝对单位。布局用rem、%、fr、vw字号用rem间距用em或rem。px只用在确实需要固定值的场合比如 1px 边框、图标尺寸。cm、mm、in基本只在打印样式表里出现。如果你确实需要在网页上做一个“跟物理尺寸对齐”的东西比如一个屏幕标尺那就得靠 JS 探测真实密度或者让用户手工校准。这类工具的实现思路是先渲染一个已知 CSS 长度的元素用设备接口拿到它的物理尺寸算出比例再据此缩放。这件事能做成但很麻烦而且需要用户配合一般项目不会这么干。顺便说一句分辨率适配现代页面都得加一行meta nameviewport contentwidthdevice-width, initial-scale1否则手机会按 980px 的虚拟宽度渲染再缩放所有尺寸全乱。这一行是移动端适配的地基忘了它后面怎么调都是错的。3.3 移动端与设计稿750 宽、375 逻辑像素、8cm 的位置在哪移动端设计稿的换算跟物理厘米基本脱钩了它走的是另一套逻辑逻辑像素 倍图。以常见的 750px 宽设计稿为例它对应的是 375 逻辑像素宽、2 倍密度的设备。设计稿上量出 100px代码里写 50pt或 50 个逻辑像素渲染时系统再乘 2 变成 100 个物理像素正好对上。这套体系里“8cm”这个概念几乎不会出现。偶尔出现一般是两种情况一种是从物理尺寸反推。比如要做一个宽度占屏幕 8cm 的卡片先算设备屏幕的物理宽度。假设某款手机屏幕宽 6.5cm、逻辑分辨率 375那 8cm 超出了屏幕宽度这个需求本身就不成立。这类需求要先跟产品确认——他要的可能是“占屏幕宽度的某个比例”而不是真的 8 厘米。另一种是打印类的小程序页面。比如电子发票、快递面单最终要落到纸上这时候就得老老实实按 300DPI 算8cm 945 像素然后在生成 PDF 或图片的时候按这个像素数输出。移动端还有一个坑是devicePixelRatio 的取值不一定是整数。有些设备是 2.75、3.5 这样的值1px 边框在这些设备上会被渲染成非整数物理像素出现模糊或者粗细不均。解决办法是用transform: scale()做 0.5px 的伪元素或者直接用细边框的替代方案比如背景渐变、box-shadow。这个技巧跟厘米换算没直接关系但只要做移动端就绕不开。3.4 图片素材物理尺寸和像素尺寸是两条独立的线做设计交付的时候我习惯同时给出两个数像素尺寸和建议物理尺寸。前者是硬指标后者是建议值。比如一张 8cm 宽的 banner 图我交付时会写945×300px建议 8cm×2.54cm 300DPI。这样印厂拿到手不用猜网页那边拿到手也能直接用像素值。反过来如果只给物理尺寸不给像素就会出现前面说的“三个人三个答案”如果只给像素不给物理尺寸印厂可能按默认 DPI 铺开尺寸对不上。还有一个实操细节导出图片时不要勾选“缩小到指定尺寸”之类的选项除非你确认过它按什么密度换算。很多工具的这个选项默认用的是 72DPI勾了之后 945 像素的图会被重采样成 227 像素画质直接崩掉。我一般导出原始像素物理尺寸写在文件名或者交付说明里。4. 我在换算上栽过的几个坑4.1 设计稿标 8cm前端做出来小了一圈这个坑印象最深。设计师在稿子上标了一个 8cm 宽的模块我在 CSS 里写了width: 8cm本地看着还行。上线之后有人在低分辨率显示器上看说模块明显偏窄。排查过程是这样先确认 CSS 有没有被覆盖没有再看浏览器实际计算值DevTools 显示 302.36px符合规范然后量物理宽度在我这台 96PPI 的显示器上是 8cm 没错但在另一台 110PPI 的显示器上只有 7cm 左右。根因就是前面说的CSS 的 cm 是名义单位不跟真实密度挂钩。修法很简单把width: 8cm改成width: 302px或者更好改成百分比至少在同样的像素密度下表现一致。想真正跨设备一致只能放弃物理尺寸诉求改用相对布局。从那以后我给自己定了规矩网页里不写 cm。看到设计稿标厘米先问清楚这个尺寸是给屏幕的还是给打印的屏幕的就换算成像素或者比例打印的才保留厘米。4.2 名片边缘被切掉一条白边另一个案子是印名片。设计给的文件是标准的 90×54mm我直接拿去印结果裁切之后有几张边缘露白。查下来是出血没留。90×54mm 是成品尺寸实际文件应该是 96×60mm四周各加 3mm。设计以为“我按成品尺寸做的就行了”印厂的机器又不可能百分百精准偏差 1~2mm 很常见于是就露白了。修复流程是把画布扩到 96×60mm背景色和底图延展铺满重要内容往里收 3mm。换算成像素300DPI就是 1134×709安全区距边 35 像素左右。这个教训让我养成了一个习惯凡是印刷类需求先问三句话——成品尺寸多少、出血留多少、有没有专色。三句话问完后面基本不会翻车。顺便说一下出血这部分内容如果做成了渐变或者纯色底延展很容易如果是照片就得在边缘做镜像或者模糊填充不能直接拉伸否则会被看出来。4.3 高分屏上那条 1px 边框“消失”了这个严格说不算厘米换算的坑但同属“尺寸单位”这一类一起说。场景是给一个卡片加 1px 边框在普通屏上正常在高分屏上肉眼几乎看不见或者粗细不均。原因是设备像素比是 21 个 CSS 像素对应 2 个物理像素边框渲染时被分配到非整数位置抗锯齿之后颜色变淡。尝试过几种方案方案效果适用场景直接写 1px高分屏偏淡不推荐写 0.5px部分安卓不认退化成 0 或 1px兼容性差transform: scale(0.5)伪元素效果稳定代码略繁通用推荐box-shadow模拟简单但圆角处理麻烦直角元素背景渐变边框可控性强需要定制时最后选了伪元素 transform 的方案写成一套可复用的样式类。这件事的启发是像素不是绝对的最小单位它只是 CSS 里的一个逻辑刻度。理解了这一层很多尺寸问题就迎刃而解了。5. 把换算自动化几个能直接用的小工具5.1 一段可复用的换算函数手算容易出错我习惯把换算封成函数随手调用。下面这两段可以直接抄。JavaScript 版本// 厘米转像素 function cmToPx(cm, dpi 300) { return Math.round((cm / 2.54) * dpi); } // 像素转厘米 function pxToCm(px, dpi 300) { return (px / dpi) * 2.54; } // 输出保留两位小数方便核对 console.log(cmToPx(8, 300)); // 945 console.log(cmToPx(8, 96)); // 302 console.log(pxToCm(945, 300)); // 8.00Python 版本做批量处理的时候更好用def cm_to_px(cm: float, dpi: int 300) - int: return round(cm / 2.54 * dpi) def px_to_cm(px: float, dpi: int 300) - float: return round(px / dpi * 2.54, 2) # 批量换算一张常用尺寸表 sizes_cm [3, 5, 8, 10, 15, 21, 29.7] for s in sizes_cm: print(f{s}cm - {cm_to_px(s, 300)}px 300DPI)跑一遍输出3cm 是 354px5cm 是 591px8cm 是 945px10cm 是 1181px15cm 是 1772px21cm 是 2480px29.7cm 是 3508px。最后两个数字眼熟吧——正好是 A4 纸在 300DPI 下的标准像素尺寸。验算对上了说明函数没问题。5.2 怎么快速确认一个文件的真实密度手边没有工具的场合我一般这么干第一步看像素尺寸。绝大多数系统里右键属性或者详细信息就能看到或者用命令行的图像信息工具读出来。第二步看物理尺寸。印刷文件一般会在文件名或者图层里标注没有的话按成品尺寸算。第三步两个数一除。像素宽 ÷ (物理宽 ÷ 2.54) 实际密度。低于 300 就提醒一下可能不清晰低于 150 基本就得重做了。这个三步法我用了很多年比任何软件的 DPI 显示都可靠因为它算的是真实值不受元数据干扰。5.3 反向使用从像素反推能不能印这是更常见的场景——别人扔给你一张图问“这个能印 8cm 宽吗”。我的判断标准写在下面像素宽度8cm 宽下的实际密度结论1890 以上600DPI 以上非常好适合精细印刷945~1889300~599DPI合格商业印刷标准630~944200~299DPI一般普通办公打印够用472~629150~199DPI勉强近距离看有颗粒300~47195~149DPI差只适合远距离观看300 以下95DPI 以下不合格明显模糊这套标准不是绝对的还要看观看距离。户外大牌可能 30DPI 就够因为没人贴着看名片 300DPI 起步因为拿在手里。判断的时候把距离因素加进去结论会更准。提示如果拿到的是矢量文件PDF、SVG、AI 之类就不用纠结这个表了。矢量图没有固定像素输出多大尺寸就按多大尺寸重新渲染密度天然够用。6. 一些零碎但有用的补充6.1 常见厘米尺寸的像素速查把常用值整理成一张表300DPI 和 96DPI 两列都列上省得每次重算厘米300DPI96DPI11183822367633541135591189894530210118137815177256721248079429.735081122这张表我打印出来贴在工位上用久了基本能记住几个关键值1cm 在 300DPI 下约 118 像素10cm 约 1181 像素A4 的长度约 3508 像素。有这三个锚点其他值都能估算出来。6.2 换算里最容易被忽略的“观看距离”因素严格来说密度需求跟观看距离强相关。行业里有个粗略的经验值最小可分辨细节约为观看距离的 1/3000。按这个推30cm 阅读距离需要大约 300DPI2 米观看距离需要大约 45DPI10 米外 10DPI 就够。这就解释了为什么户外喷绘用 72DPI 甚至更低也没问题而名片必须 300DPI 起步。同样是“8cm 宽”贴在广告牌上和拿在手里需要的像素数能差一个数量级。做方案的时候把这个因素摆出来能省掉很多争执。有人坚持“必须 300DPI”你把观看距离一说他可能就改成 150DPI 了文件体积小一半处理速度快好几倍。6.3 我现在的固定工作流最后说下我处理这类换算的固定流程基本不会出错一是先定场景屏幕还是印刷这一句决定用哪套密度。二是把物理尺寸转成目标像素用函数或者查表保留精确值参与计算。三是加余量和安全区印刷加 3mm 出血屏幕留响应式空间。四是回头验算用反推公式把最终像素再算回厘米看看跟需求对不对得上。这一步经常能抓到前面算错的地方。五是在交付物里写清楚像素尺寸、建议物理尺寸、密度三个数一起给别让人猜。这套流程听起来啰嗦但跑熟了也就一两分钟的事。真正省时间的是后面——不用返工。最后再分享一个小技巧不管用什么工具算算完都拿一张 A4 纸比划一下。A4 是 21×29.7cm这个尺寸人人有直觉。你把结果按比例折一下8cm 大概就是 A4 短边的一半略少一点如果算出来的尺寸跟这个直觉差得远那大概率是单位或者密度搞错了。这个土办法帮我抓出过好几次错比重新推导一遍还快。
阅读完成 · 觉得有帮助?
咨询建站