警惕“μg”变“mg”,融合出版时代字符变换问题探索
——以Symbol字体为例
2021-10-09王叶青董文革
李 梅,李 鹏,王叶青,律 琦,刘 爽,董文革*
(1.中国医学科学院血液病医院(中国医学科学院血液学研究所),国家血液系统疾病临床医学研究中心,《中华血液学杂志》杂志社 天津300191;2.天津市医学科学技术信息研究所,《天津医药》编辑部 天津300070)
我们在数字出版活动中发现一个现象:Word、排版小样、PDF中均编辑校对无误的文本“铁蛋白100μg/L”,发布在PubMed Central平台上竟然变更为“铁蛋白100mg/L”,而其中并无任何人为的文本调整,仅仅为XML文件面向不同平台的输出。那么该差错是从何而来的呢?为何在没有任何更改的情况下文本发生了变化?我们进行探究并发现了原因:Symbol字体中“μ”的16位编码为[006D],而普通文本采用的Unicode编码中[006D]为英文小写“m”,由于Symbol字符集编码未编入Unicode,一旦出版平台的解码设备无法对Symbol字符进行解码,则会将Symbol字符编码的[006D](即Symbol字体的“μ”),误用Unicode编码读取为“m”,便发生前文所述的差错。而目前,期刊编辑部的编校流程仍局限在Word到PDF的传统出版阶段,尚未有针对数字出版环节的审校流程,XML文件之后的融合出版环节缺乏有效监控,易导致该类差错的出现。因此,本研究试图梳理数字出版阶段的字符变换问题,并提出一些解决办法,望同仁警惕。
1 概念与问题
1.1 字符编码与Unicode编码
由于计算机内部只认识二进制代码,文字必须编码为二进制代码。计算机最基本的存贮单位为字节,每个字节存贮8个比特(即8个二进制位),所以,一个字节能表示的整数个数为28=256个,表示的范围是0~255,据此制定出ASCII编码用来表示大小写英文字母、数字和一些符号。英语用256个字符完全是足够的,但是用来表示其他国家语言,256个字符远远不够。类似如表示中文汉字要7000多个,显然1个字节不够,至少需要2个字节,于是中国制定了GB2312、GBK编码,日本制定了Shift-JIS编码等。然而不同编码体系之间的转码常常会因各种问题出现乱码与错码现象,为了解决不同编码的转码问题,最大程度将自己的产品做到国际化,使之能很容易接收各国的语言,Unicode编码应运而生[1-2]。Unicode编码就是将所有的语言文字符号都编入其中,并为每种语言中的字符设定了统一的二进制编码,来满足跨语言、跨平台进行文本转换、处理的要求。每个符号对应一个唯一的编码,乱码问题就不存在了。Unicode每个字符有16个位宽,表示世界上计算机通信所有的文字和符号,其中汉字Unicode编码范围为[3400,9FD5],英文小写编码范围为[0061,007A],英文大写编码范围为[0041,005A],数字的编码范围为[0030,0039],希腊文的编码范围为[0391,03C9]。
1.2 Symbol字体与希文字符
Symbol字体是微软公司开发的非正文字体,多用于数学公式中,包括希腊字母、数字、运算符、集合符号和其他符号[3]。Symbol字符集共有224个字符,从Symbol 32起始编码,字符代码为[0020],为“空格”字符,希文大写的编码范围为[0041,005A],希文小写的编码范围为[0061,007A]。虽然它的很多符号已经在多个系统中可调用,但由于该字符集没有被编入Unicode,导致很多仅采用Unicode编码架构的网站并不能有效识别Symbol字体。比如生物医学最重要的数据库Medline,为了解决可能出现的转码问题,将所有的希文表述替换为拉丁字母(如将TNF-α替换为TNF-a)或希文的拉丁文全称(如将κ/λ替换为kappa/lambda)。很多非微软公司开发的产品,多不带有Symbol字体,如WPS for Linux打开含有Symbol字符的doc文件,会提示“系统缺失字体Symbol、Wingdings、Wingdings 2、Wingdings 3、Webding”。然而科技论文的撰写常需要使用希文字符,由于默认的文本字体通过键盘不易方便获得希文字符,而期刊对作者如何键入希文字符缺乏要求与指导,导致如何输入希文字符常会困扰作者。如果作者通过【插入】>【符号】,选择字体Symbol来键入希文字符,Word文本中便插入了Symbol字符。
1.3 字符变换的产生机制
如前文所述,在Word中,Symbol字体的编码体系独立于Unicode编码,导致不同字符集存在字符代码共用的情况,如图1所示,Symbol字体中“μ”的字符代码为[006D],而普通文本字体中“m”的字符代码同样为[006D],两个不同字符共用一个编码。我们所见的“μ”在计算机中的传输信号为[006D],当接收文件的平台/软件无法解析Symbol字体时,便将[006D]读取为“m”输出至显示设备,发生“μ”到“m”的字符变换。试想,如果作者Word的中叙述为“A药的剂量为100μg/d”,而网站最终展示为“A药的剂量为100mg/d”,可能造成极大危害。
图1 Word插入菜单“符号”界面的symbol字体与普通文本字体Fig.1 Symbol font and normal text font in“Symbol”interface of Word insert menu
2 防范措施
2.1 呼吁作者规避使用Symbol字符
由于Medline数据库并不支持Symbol字体,首先应避免作者使用Symbol字符。通过微信、官网、邮件等形式提示作者避免使用Symbol字体,如果作者插入了Symbol字符,则需要替换为拉丁文本。为此编辑部宜在写作指导中告知作者键入拉丁文本中“μ”的方法。
方法一:在【符号】界面,字体选择“拉丁文本”,子集选择“希腊语和科普特语”,下拉找到字符“μ”,双击键入文本中,见图2(a)。然而由于文本字符集过大,查找难度大、耗时长,此方法效率较低。
方法二:通过输入编码+快捷键的方式快速得到所需字符,如“μ”的Unicode编码为[03BC],直接在Word中键入03BC,然后选中该编码,使用快捷键“alt+x”可快速获得字符“μ”,见图2(b)。该方法效率高于方法一,但是需要了解每个字符的具体编码,故适用于熟悉该字符编码的情况。
方法三:利用Sogou输入法,笔者一般通过Sogou输入法,在输入框输入“miu”,即可在结果栏中看到字符“μ”,选中对应数字键入即可,见图2C。其他希文字符输入对应希文的拉丁全称或缩写均可键入。也可在当前输入法为Sogou输入法时,按“shift+ctrl+z”快捷键,在“希腊/拉丁”列表中选择“μ”,见图2(d)。
图2 键入Unicode编码希文字符“μ”的几种方法Fig.2 Several ways to type Unicode Greek character“μ”
2.2 编辑过程注意发现Symbol字符并及时换
由于Symbol字符不受Unicode编码的文本字体控制,在编辑过程中可以通过改变希文的文本字体来鉴别是否为Symbol字符,如图3所示,Unicode编码的“μ”字体外观可受控制,不同字体下的外观有所差异,笔者常用“blackoak Std”字体进行鉴别,而期刊常用的“Georgia”与“Times New Roman”字体与Symbol编码字体最为接近,识别难度最大。若编辑在处理文本之初首先进行字体规范,将不利于Symbol字符的识别,因而建议先通过“blackoak Std”等字体观察全文文本,若有不受控制的希文或其他字符,则应高度警惕该字符并非Unicode编码。此外,编辑还可通过将Word文本复制到不支持显示Symbol字符的平台进行鉴别,如txt(显示为空白)、WPS for Linux(提示字体缺失)、PS(提示字体缺失)、R(显示为空心方框)等。
图3 Unicode编码与Symbol编码字符“μ”的不同字体Fig.3 Different fonts for Unicode and Symbol encoding character “μ”
2.3 平台开发过程注意兼容非Unicode编码
在编辑部开发网页版页面、epub文档、APP、微信小程序等多媒体平台时,需注意与工程师沟通部分文本可能非Unicode编码,建议开发平台的过程中嵌入Symbol、GBK等多个编码解码器,保证非Unicode编码的文本能在终端正常显示。
2.4 数字出版终产品应建立质量控制机制
目前,绝大部分数字出版物的数字化加工质量检查都无编辑人员参与,技术人员的质量检查重点在于发现乱码,图注、表注、上下角标缺失,正斜体不统一,图文位置不正确,链接失效等问题[4],对涉及学术内容的“μg”与“mg”等编校问题缺乏敏感性。期刊编辑部应加强数字出版终产品的质量检查,总结质量风险点,建立包括编校、技术等相关环节的质量控制机制,做到全程留痕、有据可查,从内容、技术和项目整体上保障各个形态数字出版物的文本一致。
3 结 语
希文字符在科技文献中使用较多,然而通过Symbol字符键入的希文字符编码未编入Unicode编码,在数字出版过程中易导致字符转换的差错出现。除Symbol字符外,“Monotype Sorts”中包含了200多种箭头、指示符和标记;“MT Extra”中包含一些数学符号,用来扩充“Symbol”字体。编辑应提高对希文,数学公式,箭头、指示符和标记等字符的敏感性,一方面呼吁作者尽可能采用Unicode编码字符撰写稿件,一方面加强自身业务素质,提升对Symbol字符的识别与防范。
随着融合出版的深入发展,各个期刊都建立了包括适应不同载体的数字出版矩阵,国内期刊已能够实现基于XML格式数据的全媒体发表[5]。然而由于不同载体、不同出版平台的解码结构不同,同一个XML数据文件最终的展示状态会有所不同。因此,应注意在数字期刊出版平台开发中尽可能兼容非Unicode编码,同时尽快建立数字出版质量控制的机制,避免差错产生。