没有一点点防备的开端

某年某月的某一天，翻译返回了多语言 xliff 文件之后，我就像往常一样稀疏平常地导入到 Xcode 中，编译...，就在起身准备去茶水间倒水的时候，马德，什毛，编译报错了，赶紧放下手中的保温杯打开日志看了下编译报错的原因。

Xcode .strings 文件编译报错 .strings:0: error: read failed: The data couldn’t be read because it isn’t ..._第1张图片

企业微信截图_88a48af2-fc96-49c1-a9b7-ce839bb1fb66.png

WTF

What？这是什么鬼？不就是正常的多语言文案导入嘛？我的操作没错呀 ...

Xcode .strings 文件编译报错 .strings:0: error: read failed: The data couldn’t be read because it isn’t ..._第2张图片

timg.jpg

陷入僵菊

第一步：确定是否是导入流程中的操作出错了

这对多语言文案导入工程师来说这当然是不可能的，在 Git 中 Discard 掉所有的 Changes，并且，和组内其它 iOS 开发小伙伴们都确认过眼神，是对的操作流程，之后，我又重新导入了一遍，But, Xcode build failed again ...

说明不是导入流程出错

第二步：查

请教了公司诸多的大牛，他们纷纷表示没有碰到过如此神奇的画面，而后我又转战 Google，找到了类似的情况， .strings 文件中某一行分号忘记写了的文章，于是打开了报错的该 .strings 文件，用搜索分号一行一行地用我的钛合金写轮眼扫描过去 ...

但是发现分号也是一行不落的。

第三步：排除法

排除了以上所有的问题产生可能，我仔细地再思考了这个问题的本质之后，我发现了以下很有趣的画面：

别种语言的 .strings 文件没问题，就英文的翻译有问题。
把英文 .strings 文件里的内容清空之后编译是没有问题的。

所以，可以得出的结论就是：问题出现在返回的英文译文上。

所以我采用了最笨、花费时间最长但是却最有效的方法：排除法。
我一行一行译文地注释，我就不信了，抓不着你 ...

I got you

Xcode .strings 文件编译报错 .strings:0: error: read failed: The data couldn’t be read because it isn’t ..._第3张图片

企业微信截图_63aebb10-77d3-403e-96c2-72ca704ab0e0.png

。。。
无 Fuck 可说。。。

返回的译文中包含了双引号，双引号中出现未转译的双引号就会导致编译报错。

Xcode .strings 文件编译报错 .strings:0: error: read failed: The data couldn’t be read because it isn’t ..._第4张图片

timg2.jpg

解决方案

1, 把双引号中的 " 全部使用 \" 替换。
2, 和负责多语言文案翻译的同学同步此情况，之后如果译文中包含双引号记得在前面加个反斜杠，返回译文之前自己先多 Check 下。
3, 同步给公司内其它 iOS 开发小伙伴这个奇葩问题的前世今生。
4, 写成 MarkDown 分享给更多 iOS 同行。

终于编译成功了，科科~

THE END
谢谢收看！！

Xcode .strings 文件编译报错 .strings:0: error: read failed: The data couldn’t be read because it isn’t ...