ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

CentOS 7安装LibreOffice与中文字体乱码处理实战

CentOS 7安装LibreOffice与中文字体乱码处理实战 1. 先搞清楚CentOS 7上装LibreOffice到底难在哪CentOS 7服务器上装LibreOffice这件事不少人第一反应是不就是一个 yum install 的事吗真这么简单就好了。我见过太多人在内网服务器上装完LibreOffice开开心心写了个转换测试结果文档一生成中文全是豆腐块英文数字正常标题乱成一片然后开始怀疑人生。这篇东西要解决的就是两个问题第一CentOS 7上怎么把LibreOffice装好并且是能用的版本第二怎么把中文字体装进系统让LibreOffice渲染中文文档不再出现乱码和方块。这两个问题往往是绑在一起出现的——服务器上部署LibreOffice十个里有八个是为了做文档在线预览、格式转换、批量导出PDF这类后端服务中文是绕不开的刚需。适合谁来参考后端开发、运维工程师、做Docker镜像打包的同事以及所有需要在Linux服务器上处理Office文档的小伙伴。先说点实在的CentOS 7的生命周期已经步入尾声软件源迁移到vault归档源后很多默认仓库里的软件版本就冻结在老版本上。系统自带的那个LibreOffice如果有的话通常是5.4甚至更老解析新版docx、带复杂样式的PPT效果只能用“凑合”来形容。所以生产环境我一般不推荐直接用系统yum源里的LibreOffice而是用官方发布的RPM包装7.x版本。这也是为什么很多教程都强调“去官网下RPM包”而不是直接 yum install libreoffice。还有一个很多教程没告诉你的事CentOS 7本身不带任何中文字体装完LibreOffice哪怕你转换的是一个纯中文的txt文档输出PDF照样可能全是方块。原因很简单LibreOffice本身只是个渲染引擎它自己不携带字体所有字符都要靠系统中fontconfig管理的字体来渲染。系统里一个字都没有那它画出来的自然就是空方框。所以我把整件事分成三条线来看装软件、补依赖、配字体。缺了任何一条都会在后续使用中露馅。2. 安装前的系统准备与依赖确认2.1 检查系统版本与已存在的办公套件动手之前先花两分钟摸清现场。登录服务器先确认一下系统版本cat /etc/redhat-release如果是 CentOS Linux release 7.9.2009那就对上了。接着看系统里是不是已经装了老版本LibreOffice或者OpenOfficerpm -qa | grep -i office which soffice这一步非常关键。我遇到过一台服务器系统里残留着OpenOffice新装LibreOffice时rpm包之间产生了菜单项冲突导致desktop-integration包怎么都装不进去。处理方案其实很简单老版本办公套件先卸干净再说。如果确定不需要老版本直接rpm -e --nodeps $(rpm -qa | grep -i openoffice)注意--nodeps 是个双刃剑能不用就不用。但如果老版本死活卸载不了而它又不影响业务那可以保留着安装LibreOffice时跳过desktop-integration包也行。不过我不建议这么干后面出问题你会分不清到底是哪个套件在捣乱。再确认一下架构x86_64还是aarch64这决定了你下载哪个架构的RPM包。CentOS 7服务器99%是x86_64但偶尔也有arm架构的机器这一步省不得。2.2 更新软件源与预装依赖CentOS 7的yum源用默认mirrorlist已经非常慢了新装系统建议先换到可用的源。这里不做太多展开只提醒一个重点不管你用哪个源epel-release 建议先装上因为后面排查依赖时有很多辅助工具在默认源里没有yum install -y epel-release yum makecacheLibreOffice的RPM安装包对图形库的依赖不少官方文档里写了需要这些基础库libXinerama、cups-libs、dbus-libs、glibc、libstdc、fontconfig、freetype、libXext、libXrender。在CentOS 7上完整装一遍yum install -y libXinerama libXinerama-devel cups-libs dbus-libs libXext libXrender libICE libSM libX11 libXau libXdmcp libxcb glibc libstdc fontconfig freetype有人会问我只是做headless转换也要装这些图形库吗要。LibreOffice虽然可以无显示环境运行但它编译时链入了X11的库缺了这些so文件启动直接报错报错信息还特别隐晦——有时候只说“cannot open shared object file”有时候干脆就卡死不动。所以在最小化安装的CentOS 7上先把这些依赖补齐是最省心的做法。还有个容易被忽略的如果后续要用Java调用LibreOffice比如通过JODConverter需要检查一下系统里的JDK版本。LibreOffice 7.6官方支持Java 8以上CentOS 7默认OpenJDK 1.8可以直接用。不需要Java环境的可以跳过LibreOffice本身不依赖Java也能做命令行转换。3. 安装LibreOffice的两种实操路径3.1 在线安装yum localinstall走一遍适合能联网的测试机LibreOffice官方发布的Linux版RPM包下载下来是一个几百MB的压缩包解压后里面是一大堆RPM文件。网上说的“在线安装”其实也不是真在线而是把RPM包下载到服务器本地再用yum的localinstall去解依赖。我习惯把安装包放到 /opt/libreoffice_setup 目录下解压出来mkdir -p /opt/libreoffice_setup tar -xvzf LibreOffice_7.6.4_Linux_x86-64_rpm.tar.gz -C /opt/libreoffice_setup解压后你会看到一个 RPMS 目录里面几十个rpm文件。先不要急着 rpm -Uivh *.rpm那样装容易顺序错乱导致依赖失败。推荐做法cd /opt/libreoffice_setup/LibreOffice_7.6.4_Linux_x86-64_rpm/RPMS yum localinstall -y *.rpmyum localinstall 会自动读取RPM包之间的依赖关系把缺的库一起从软件源里拉下来装好。实测下来只要第2章的依赖预先装了localinstall基本不会报错。如果企业内网没有外部yum源那就得走下面离线那条路。安装完成之后LibreOffice默认装在 /opt/libreoffice7.6 目录下。验证一下/opt/libreoffice7.6/program/soffice --version如果能看到 LibreOffice 7.6.4.1 这样的版本号输出说明主程序已经安装成功。接下来还有个细节RPMS目录装完后官方包里其实还有一个 desktop-integration 目录里面有让你把LibreOffice集成到GNOME/KDE桌面的菜单包。纯服务器环境不需要这个我都跳过。装了反而可能因为缺少桌面环境报错。3.2 离线安装RPM包手动分发生产内网更常见生产服务器不能上外网这是常态。离线安装的核心思路在一台能联网的测试机上把RPM包和依赖库全部下载好再拷到目标服务器上装。依赖库可以用 yumdownloader 工具一次性拉下来yum install -y yum-utils mkdir -p /opt/libreoffice_deps yumdownloader --resolve --destdir /opt/libreoffice_deps libXinerama cups-libs dbus-libs libXext libXrender freetype fontconfig然后把这个 deps 目录和 LibreOffice 的 RPMS 目录一起打包拷贝到内网服务器。内网安装时先装依赖cd /opt/libreoffice_deps rpm -Uivh *.rpm --nodeps --force生产环境离线装依赖--nodeps 有时候没法完全避免。但注意这个操作只在依赖库打包完整的情况下才安全否则后面LibreOffice装完启动不了排查起来更麻烦。我的经验是依赖库宁多勿少把第2章列出的所有库都下载下来反正加起来也没多大。依赖装完再装LibreOffice本体cd /opt/libreoffice_setup/LibreOffice_7.6.4_Linux_x86-64_rpm/RPMS rpm -Uivh *.rpm如果提示某个包依赖缺失用 rpm -ivh 单个安装报错的包再回到目录里继续装剩下的这样能精确定位缺哪个库。不建议一上来就 --nodeps除非你非常确定系统环境已经是干净的。这个问题我踩过不少次。有一次在内网装到 liblibreofficekit 这个包时卡住提示需要 liblangtag、libnumbertext 这些库这些库在CentOS 7默认源里根本没有最后是从COPR源里找到了RPM包拿进去装的。所以离线安装前最好还是准备一台联网机器试装一遍确认依赖全了再打包带走。4. 中文字体部署乱码解决全过程4.1 字体从哪来合法获取与文件准备LibreOffice装好了打开文档看到中文全是方块此时系统里连一个中文字体都没有。中文字体的获取路径有三条我按推荐程度排一下。第一条路径使用开源中文字体首推思源黑体Noto Sans CJK SC和思源宋体Noto Serif CJK SC。这类字体没有版权风险也是目前质量最高的中文字体之一简体、繁体、日文假名都覆盖适合企业内网部署。CentOS 7通过epel源可以尝试安装yum install -y google-noto-sans-cjk-fonts google-noto-serif-cjk-fonts如果软件源里没有不同源情况不一样那就下载Noto字体包手动部署。注意CentOS 7上包名可能是 google-noto-sans-cjk-fonts也可能是 noto-sans-cjk-fonts装之前先 yum search noto 看一眼。第二条路径从已有的Windows机器上拷贝字体文件。宋体simsun.ttc、微软雅黑msyh.ttc这类字体在公司内部使用实测中很常见。但这里必须提醒一句Windows字体是有版权的仅限于你个人使用的机器如果公司生产环境要商用建议走第一条路用开源字体避免后续麻烦。拷贝时记得把 simsun.ttc、msyh.ttc、simhei.ttf 这些常用字体都拿上。第三条路径使用文泉驿系列字体。文泉驿正黑、文泉驿微米黑是国产开源字体CentOS的软件源里有安装命令yum install -y wqy-microhei-fonts wqy-zenhei-fonts这个字体渲染中文没问题但单个字体文件较大且字体风格偏印刷体做常规办公用足够了。我的建议是能装思源就装思源装不上的时候文泉驿保底。4.2 字体安装三步走拷贝、改权限、重建缓存不论字体文件从哪里来安装方式都一样。先建一个专门的目录mkdir -p /usr/share/fonts/zh_CN然后把字体文件放进去。ttc、ttf、otf格式都行LibreOffice通过fontconfig都能识别cp simsun.ttc msyh.ttc simhei.ttf /usr/share/fonts/zh_CN/ cp NotoSansCJK-Regular.ttc /usr/share/fonts/zh_CN/接下来改权限。这个细节容易被忽略如果服务器上LibreOffice是以普通用户身份跑的字体文件权限不对就读取不了。目录权限755、文件权限644是最稳妥的chmod 755 /usr/share/fonts/zh_CN chmod 644 /usr/share/fonts/zh_CN/*然后是最关键的一步重建字体缓存。Linux系统靠fontconfig管理字体字体文件放进目录后必须让fontconfig重新扫描一遍才能被发现fc-cache -fv /usr/share/fonts/zh_CN看到“fc-cache: succeeded”这样的输出就说明缓存更新完成了。检查一下字体是否能被识别fc-list :langzh这个命令会列出所有支持中文的字体如果列表不为空那就成功了一大半。再精确验证某个字体fc-list | grep -i simsun\|microsoft yahei\|Noto Sans CJK看到对应字体路径输出就说明LibreOffice已经能感知到这些中文字体了。4.3 按需定制只装宋体黑体还是全套字体不是越多越好。有些工程师把Windows下Fonts目录整个拷贝到服务器上结果LibreOffice启动变慢字体解析开销变大转换耗时反而涨了。字体文件越多fontconfig缓存越大LibreOffice启动时加载字体列表的时间就越长。实际项目里分两种情况。场景一只是把 docx 转成 PDF 供在线预览这种场景装一个思源黑体就够中文文档、表格、PPT都能正常渲染不需要纠结是不是宋体。场景二业务方对格式有严格要求比如合同、公文类文档模板里指定了宋体那就要把 simsun.ttc 装上否则LibreOffice会用默认字体替代输出PDF排版会崩。推荐组合是NotoSansCJK SimSun Microsoft YaHei。这三款覆盖了办公场景最常见的黑体和宋体体积也可控默认字体文件加起来大概一百多MB完全不影响性能。有个小技巧装完字体如果LibreOffice正在运行记得重启相关进程再测试。字体缓存是系统级的但LibreOffice在启动时会把字体列表加载到内存里运行中装上字体并不会自动刷新。5. 转换验证与常见故障排查实录5.1 用命令行验证中文转换是否正常一切装完后用真实文档做一次全流程验证。写一个简单的中文docx不方便可以先用LibreOffice自己新建一个cd /tmp /opt/libreoffice7.6/program/soffice --headless --convert-to docx --outdir /tmp test.txt用自带的test.txt生成的docx来测试最多只能验证软件本身能用中文渲染还得靠真实文档。最直接的方法是准备一份带中文的docx转成PDF看看效果/opt/libreoffice7.6/program/soffice --headless --convert-to pdf --outdir /tmp /tmp/测试文档.docx转换完成后把生成的PDF下载到本地打开仔细检查中文显示是否正常、表格边框是否完整、字体是否被替换。这里有个常见误区只要PDF打开不是方块很多人就觉得字体OK了。但更隐蔽的问题是——字体被替换了。比如文档指定的是宋体系统里没宋体LibreOffice自动用了文泉驿替代PDF里所有文字都会变“胖”一圈。检查PDF属性栏里的字体列表确认中文字体名和你预期的完全一致这才算真正成功。5.2 事故高发区权限、残留进程、内存与临时目录用LibreOffice做服务化部署常见的坑我一个个说。第一个是权限问题。很多后端服务用root用户跑LibreOffice用root启动时可能警告但能运行。问题是后续如果切换成普通用户跑第一次执行转换大概率失败因为/root目录下的LibreOffice配置文件夹.config/libreoffice普通用户没有访问权限。解决方法是第一次启动前先切换成目标用户执行一次su - www -c /opt/libreoffice7.6/program/soffice --headless --convert-to pdf --outdir /tmp /tmp/test.docx提前生成好目标用户的配置目录后面再跑就不会碰到“com.sun.star.uno.RuntimeException”这类权限报错。第二个是soffice残留进程。LibreOffice每次启动都需要几秒钟初始化如果是通过Java接口反复调用每次调用都会拉起一个soffice.bin进程调用完了如果程序没有正常退出这个进程会一直占着内存。时间一长服务器上挂着一堆soffice.bin内存耗尽。处理方式有两种要么在调用代码里使用进程池并按需销毁要么在计划任务里定期清理pkill -9 soffice.bin但注意pkill会让正在执行的转换任务直接中断在低峰期清理比较稳妥。我用Java做转换服务时会监控soffice进程数量和内存占用当连续转换超过500次之后主动重启一次soffice进程释放内存实测效果很好。第三个是内存和临时目录。LibreOffice转换大文档比如几十MB的PPT时很吃内存建议服务器至少预留4GB内存临时目录 /tmp 也要有足够空间。如果 /tmp 分区比较小可以指定临时目录/opt/libreoffice7.6/program/soffice --headless -env:UserInstallationfile:///opt/libreoffice_work --convert-to pdf --outdir /tmp /tmp/large.pptx通过 -env:UserInstallation 把LibreOffice的工作目录单独隔离出来既避免污染系统目录也方便以后排查缓存问题。5.3 排查速查表现象可能原因解决思路转换报错 java.io.IOException: Connection refusedsoffice进程没启动或端口不对检查进程状态确认LibreOffice能独立启动中文显示为方形豆腐块系统无中文字体或字体缓存未更新安装第4章提到的字体执行 fc-cache -fv中文显示正常但字体变形指定字体缺失被自动替换为替代字体用 fc-list 确认对应字体存在检查PDF字体属性安装rpm包时报依赖缺失系统缺少图形库或基础库用yum install补齐后再装soffice启动后立刻退出Java版本不匹配或可执行权限错误检查 /opt/libreoffice7.6/program/ 下的文件权限转换速度极慢卡死内存不足、/tmp空间满清理/tmp释放内存或指定UserInstallation目录部分PPT转换后排版错乱LibreOffice版本旧、字体缺失、媒体资源丢失升级到7.6安装中文字体检查PPT兼容性Linux下排查LibreOffice问题最快的办法是直接跑命令行转换错误信息会直接打到终端。如果你的服务是通过进程调用看不到终端输出那就把日志重定向到文件里/opt/libreoffice7.6/program/soffice --headless --convert-to pdf --outdir /tmp /tmp/test.docx /tmp/lo.log 21排查问题时盯着这个日志文件比四处猜效率高得多。最后分享一个我自己的习惯装完LibreOffice和字体之后我会建一个简单的shell脚本把“清缓存、杀残留进程、执行转换测试”打成一个命令#!/bin/bash pkill -9 soffice.bin fc-cache -f /dev/null 21 /opt/libreoffice7.6/program/soffice --headless --convert-to pdf --outdir /tmp $1以后线上出了中文乱码、转换卡死先跑一遍这个脚本八成能恢复。这套组合拳打完CentOS 7上的LibreOffice基本上就稳了再配合中文字体的完整部署各种文档转换、在线预览场景都能顶得住。
返回列表