1.首先,咱们需要返回到win8系统的传统桌面位置,然后在win8系统中找到自己想要设置的软件图标,之后,咱们右键点击这个软件图标,在弹出来的下滑菜单中,咱们选择属性. 2.之后,咱们就可以看到如下图中所示的属性窗口了,小编这里以咱们比较熟悉的QQ程序为例,在打开的属性窗口中,咱们可以看到快捷键这一栏,咱们直接在这里填写自己想要用来快速开启程序的几个快捷键的组合就可以了. 不过需要注意的是,这个快捷键的组合不要和咱们Windows系统中自带的快捷键组合重复就好了 注:更多精彩教程请关注电脑教程栏
输入法是每一台电脑所电脑所需要必备工具，这是由输入法本身功能特点所决定的，它能辅助用户输 入文字、标点符号。同时输入法本身脱离不了操作系统所提供的平台，我们知道，在过去的Windows操作系统中，输入法始终默默无闻地服务于系统中。那 么，对于最新版的Win8系统中，是否所有输入法都能完美地运行? 输入法的需求是来源于键盘的限度。键盘原在打字机时代为英文字母而设计，但键盘只有一百多个按键，在没有软件的帮助下它是无法输入中文或其他大型形意文 字的语言。不同语言、国家、或地区，有多种不同的输入
大家会不会觉得自己的win8系统中的字体太小了呢?其实我们是可以自己调节它的大小的哦! 1、首先登陆Windows8 Metro界面，单击左下角桌面图标; 2、进入桌面后，在空白处点击鼠标右键，选择“个性化”; 3、进入个性化后，左键单击左下角的显示图标; 4、进入显示界面窗口，此界面可以选择系统默认的两种比例，默认为：较小(S)，选择中等(M)-应用(A)会出现如下提示：“你必须注销计算机才能应用这些更改”; 5、选择立即注销后重新登录界面，图标或文本设置生效; 6、也可设置自定义文本大小，参
微软为跨平台操作系统Windows 8提供了两种界面，一种是方便触控屏操作的Windows新界面（原名Metro界面），另一种就是我们熟悉的传统Windows桌面。对于没有触控设备的用户以及一些工作需求，为Win8系统打造熟悉顺手的传统Windows桌面是非常重要的。 启动Win8系统之后我们会直接进入布满五彩动态磁贴的开始屏幕，点击“桌面”磁贴或者按下“Win+D”即可进入Win8系统的传统Windows桌面。 找回Win8系统图标 首次进入Win8的传统桌面，我们只能看到“回收站
常规的电脑图标，在经过多年的一成不变后也会变得腻味，但是在Metro应用可以美化图标，来达到一定的图标效果。那么在win8 系统中的Metro应用图标美化使用技巧要怎么的使用呢？我们一起来看看吧！ Metro应用不像传统桌面图标那样能右键-属性-修改图标。只能通过修改替换图标文件来美化。 打开：C:/Program Files/WindowsApps 文件夹 ，非管理员用户默认无法打开，需要获取权限。WindowsApps 文件夹 – 右键属性 – 安全 – 更改 – 选择用户和组 – 高级 –
win8系统怎么设置隐藏分区：随着win8系统多功能的使用，越来越多用户喜欢用隐藏功能来保护私密文件，如果没有对文件进行保护，那么我们的重要文件很容易被泄露。在win8系统中就有隐藏分区功能将电脑上的某个磁盘隐藏起来，让文件处于安全的环境、下面小编就为大家讲解怎么设置win8的隐藏分区。 1、在Win 8系统里右击“计算机”，点击“管理”，然后选择“磁盘管理”。 2、在“磁盘管理”里右键要引藏的分区，接着更改驱动器号和路径，最后把要隐藏的分区删除即可。 3、现在就已经把其中一个分
在Win8开始屏幕状态下按快捷键“Win+X”，屏幕左下角会出现一个系统功能菜单，选择“控制面板”即可快速进入传统桌面与Windows控制面板。 图示：在Win8开始屏幕状态下按快捷键“Win+X” 图示：打开Win8控制面板 从Win8电脑设置进入传统控制面板 我们知道，在Win8开始屏幕中将鼠标移动到屏幕右上角或者左上角，在Charm菜单中选择齿轮图标“设置”选项，再选择“更改电脑设置”即可进入Win8系统的“电脑设置”界面。 图示：从Win8开始屏幕进入电脑设置 　
在win8 的系统中，出现了一个不知名的账户，使得在进行电脑操作时，变得很烦恼，还受到限制。这个不知名的账户是，(s-1-5-21---03)，那么要怎么的删除这个账号呢?我们现在一起去看看吧! 出现的具体情况如下： 解决方法： 就开始网上各种搜了。。说是以前系统账号遗留下来的问题，管他呢，能删掉就行 试了方法一：首先选中一个分区，然后选择右键——安全——选择高级按钮——选择所有者标签——选择编辑——然后选中管理员组(adminis
在win8 系统中的网络共享内有内置承载的网络，但是要进行设置。可是要怎么的设置呢!现在我们一起去看看具体的操作吧! Windows 8 系统也与Windows 7系统一样，内置了网络共享的方式。下面主要看看如何设置： 1. 查看电脑是否支持网络共享 在命令提示符(打开方式看文章最后)中输入：netsh wlan show drivers，然后回车。如下： 找到“支持的承载网络”一项，如果后面显示的是“是”，恭喜你，你的电脑支持承载网络可以共享，否则，就另想他法了! 2. 设置共享网络的用户名与
word工具是我们在日常办公中经常会使用到的办公软件,它对我们的重要性不言而喻.但是,最近却有不少Win8系统用户反映自己在打开office2003的时候,系统提示&无法访问&.经过分析后发现是稿纸加载项上出了问题,我们只有选择卸载才能解决,但是用户在卸载时又发现根本无法卸载.那么,遇到这种情况我们该怎么办呢?接下来,小编就向大家分享win8系统中Word稿纸加载项无法卸载的处理方法. 1.首先,咱们需要返回到win8系统的传统桌面位置,之后,咱们同时按下键盘上的win+R快捷键打开电
1.咱们这里暂且以咱们win8系统中的IE浏览器为例吧,之后,咱们从win8系统的开始屏幕中,或者是返回到win8系统的传统桌面菜单中,打开win8系统中的IE浏览器,之后,咱们点击窗口上方的工具-Internet选项. 2.在打开的Internet选项窗口中,咱们将界面切换到高级这一栏中,然后然后鼠标拉动滑动按钮找到加速的图形,然后将&使用软件呈现而不是用GPU呈现&前面的勾取消掉. 3.完成设置之后,咱们点击窗口下方的应用-确定按钮保存设置,这样,咱们关闭浏览器,然后重启开启,搜索
1.进入hosts文件所在的文件夹; 2.右键hosts文件,弹出菜单,选择属性; 3.属性窗口中选择安全选项卡; 4.单击高级按钮; 5.在hosts高级安全 设置中选择更改权限; 6.点击禁用继承,在弹出选项中,选择第一项; 7.选择列表中的Users,点击添加按钮; 8.进入其权限配置,将各个权限勾选,然后确定; 9.返回窗口中,点击应用,此时弹窗,选择是,然后确定; 10.此时hosts文件修改就可以保存了. 根据上面的解决步骤进行操作,我们就能解决win8系统中hosts文件修改后无法
插件,似乎很多用户在听到这个名字的时候就会感觉到很不舒服,因为一般情况下,插件都是Windows系统中被迫捆绑安装的程序,属于流氓软件的一种,但是实际上,却并非是所有的插件软件都是无用的,例如咱们比较熟悉的Flash插件,便是插件的一种,但是也是播放软件的一种,很多时候,这个插件的缺失会造成Flash文件无法播放,下面,小编要介绍的便是如何在咱们的win8系统中添加Flash插件. 1.首先,咱们返回到win8系统的传统桌面位置,之后,咱们在桌面找到这台电脑图标,咱们双击打开这个图标,这样就可以
升级到win8系统之后,这个磁贴功能似乎就成为了整个系统的亮点了,因为就连传统的开机显示屏幕都变了,满屏都被这个磁贴所取代了,那么大家是否值得,这个磁贴中,其实还蕴含了大量的信息,metro界面中展示的很多信息都是与咱们的个人信息所绑定好的,例如咱们的邮件等等,这样是不是会让大家觉得个人私密随时有可能被泄露呢?其实,解决的办法很简单,咱们只需要对win8系统中的磁贴进行缓存处理就可以了,下面,小编就来介绍一下具体的操作方法吧. 1.首先,咱们返回到win8系统的传统桌面位置,之后,咱们同时按下w
如今很多人逐渐开始用上Windows 8系统，但使用中也发现了一些问题。很多用户表示在Win8系统中，exe格式的视频课件无法播放，因此造成很大的麻烦。这种情况该怎么解决呢? 解决方法 点击课件下载后，注意浏览器下边栏，如下图： 可以单击保存右边的下拉箭头，选择另存为，保存到指定的位置 另存的时候，文件名框中是没有扩展名的，需要手动添加“.exe”扩展名 下载完成后，会提示文件不安全，点击查看下载，如下图： 接着单击鼠标右键，运行 单击“更多信
什么叫做"启动项"呢?其实就是随系统开机启动的程序.....那么在Win8系统中我们如何来管理开机启动项呢?下面小编就为大家介绍一下! 很多人知道"启动项"但不一定了解"启动"文件夹。只要将程序的快捷方式复制到这里，就能让它随系统一同启动。在Win8系统中出于安全考虑是隐藏这个文件夹的，不过如果您有要设置的启动项，不妨跟小编学下这招。 1.首先按下Win+R组合键; 2.输入：%USERPROFILE%/AppData/Roaming/Microsoft/Windows/Star
metro界面是win8系统中的开始桌面。操作方式和平板无疑，如果我们的电脑显示屏不是触摸的，使用鼠标操作依旧可以体验到不错的体验，但是metro界面的应用必须到应用商店下载才能安装使用，最近小编就是越到了一种这样的情况，在应用商店安装的QQ突然变成了一种颜色，点击进去后却是应用商店，而且还找不到删除选项，这就难受了，还不能覆盖安装！其实，这种情况在win8中叫做程序坏死，可以通过Windows PowerShell卸载，几个指令就能OK哦。下面小编就跟大家分享一下是如何操作的。 1.在metr
第一步、首先需要在VPN服务站点申请VPN账号，这部分需要读者自己进行探索。 在取得VPN网络账户后，使用步骤与PPPoE宽带接入类似，打开网络和共享中心，在选择连接选项时选择“连接到工作区”，然后单击“使用我的Internet连接(VPN)”。 第二步、最后在Internet地址中输入VPN服务商提供的地址，单击“创建”即可;设置完毕后，单击系统托盘网络图标，在右侧边栏即可看到VPN连接，单击“连接”即可进入VPN网络。 通过以上2个步骤，就可以在win8系统中设置VPN啦!
找不到某个文件夹?也许被小伙伴给隐藏了也不一定。在Win8系统中查看隐藏文件稍微变得简洁了那么一点点，下面系统之家小编就为您介绍一下。 我们点击上方工作栏中的"查看"勾选"隐藏的项目"就能让隐藏文件显示出来啦~ 不过隐藏如此简单，显示隐藏也同样简单，这功能还有什么意义呢。
你还在使用第三方工具查看电脑预装Win8系统中的产品密匙么?下面系小编为大家介绍一下如何只通过一条命令就能查看电脑预装Win8系统中的产品密匙。 该方法适用于预装 Windows RT、Windows 8、Windows 8.1 及 Windows Server 2012 等采用 OA 3.0 技术的电脑。首先： 1.运行 Windows PowerShell，键入以下命令并回车： (Get-WmiObject -query ‘select * from SoftwareLicensingSer为什么特殊阿拉伯字符串能造成iOS系统和OS X下应用崩溃？解决方案是什么？15年重现bug。
更新：15年5月14日，微信朋友出现字符串：
? ? ? ?。一旦查看该字符串，微信，手q，陌陌，来往等多个IOS应用崩溃。——分割线——（乌云）此特殊阿拉伯字符串的搜索结果 Warning：前两个链接所指向页面的评论区和第三个链接的页面都含有此字符串，iOS 6 和 OSX 10.8 用户请勿打开，若需查看请更换运行 Windows/Linux/Android 等其他操作系统的设备，或者使用 Firefox 浏览器。
按投票排序
先说结论吧：、 和
的答案都是片面的。导致这个 bug 的元凶，在 iOS 6 上是 WebCore，在 OS X 10.8 上是 CoreText。========以下是反驳
的观点：这是那个越狱补丁的源码：很明显是给 WebCore 打的补丁。代码的注释里提到了 WebCore 的 characterRangeCodePath() 函数会在处理 U+0600 ~ U+109F 的字符（其中 U+0600 ~ U+06FF、U+0750 ~ U+077F 是阿拉伯字母）时当成复杂类型，而它调用的 ComplexTextController::adjustGlyphsAndAdvances() 方法在处理这种类型的文字时却出错了。以下代码来自 WebKit 源码（）：float Font::getGlyphsAndAdvancesForComplexText(const TextRun& run, int from, int to, GlyphBuffer& glyphBuffer, ForTextEmphasisOrNot forTextEmphasis) const
float initialAdvance;
ComplexTextController controller(this, run, false, 0, forTextEmphasis);
controller.advance(from);
float beforeWidth = controller.runWidthSoFar();
controller.advance(to, &glyphBuffer);
if (glyphBuffer.isEmpty())
float afterWidth = controller.runWidthSoFar();
if (run.rtl()) {
initialAdvance = controller.totalWidth() + controller.finalRoundingWidth() - afterWidth;
glyphBuffer.reverse(0, glyphBuffer.size());
initialAdvance = beforeWidth;
return initialAdvance;
它构造了一个 ComplexTextController 类型的对象，这个对象在初始化时崩溃了。这个类是 WebCore 框架的，根据
和匿名用户的回答（），这里并没有更深的调用栈（也不排除调用了内联函数），基本可以认定是 WebCore 的 bug。我并不同意
说异常栈可能不完整的问题，因为汇编代码都显示出来了，在哪崩溃是很显而易见的。补丁给出的解决办法是将类型设为自动，也就不会调用上述方法了。但这种解决办法也许会引来其他的 bug（主要是显示方面，对不用阿拉伯语的人应该没影响）；只是我对阿拉伯语不了解，也就不妄做判断了。更直接的依据是
的回答：iOS 6 的 CoreText 是能正常显示这段文字的。========但上述结论也并不代表 CoreText 就没问题，我今天在测试时发现某些字符组合甚至可以让 OS X 10.8 的 Terminal 崩溃，而它是不太可能使用 WebCore 的。此外，这个 bug 并不是在 iOS 7 和 OS X 10.9 上就不存在了，在某些情况下仍能造成 crash。例如用那串文字做文件名，那么 Finder 在显示这个文件时就会崩溃。这也让我觉得 CoreText 很可疑。以 Mac Safari 的崩溃异常栈为例，它是在 CoreText 里崩溃的；虽然也用到了 WebCore，但崩溃的位置和 iOS 下不一样：Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
libvDSP.dylib
0x00007fff8efdbadb 0x7fff8efbf000 + 117467
com.apple.CoreText
0x00007fff8e6c1d5c TRun::TRun(TRun const&, CFRange, TRun::SubrangingStyle) + 850
com.apple.CoreText
0x00007fff8e6c19ee CTGlyphRun::CloneRange(CTRun const*, CFRange, TRun::SubrangingStyle) + 142
com.apple.CoreText
0x00007fff8e6d0764 TLine::SetLevelRange(CFRange, unsigned char, bool) + 162
com.apple.CoreText
0x00007fff8e6d1e2c TLine::SetTrailingWhitespaceLevel(unsigned char) + 70
com.apple.CoreText
0x00007fff8e6d1d58 TRunReorder::ReorderRuns(TBidiLevelsProvider const&, TLine&) + 122
com.apple.CoreText
0x00007fff8e6d1bfe TTypesetter::FinishLineFill(TLine&, double, double) const + 142
com.apple.CoreText
0x00007fff8e6c1775 CTTypesetterCreateLine + 131
com.apple.WebCore
0x00007fff8f7f1f1a WebCore::ComplexTextController::collectComplexTextRunsForCharactersCoreText(unsigned short const*, unsigned int, unsigned int, WebCore::SimpleFontData const*) + 1562
com.apple.WebCore
0x00007fff8f7f176a WebCore::ComplexTextController::collectComplexTextRuns() + 522
这是 Mac QQ 崩溃的异常栈，受伤的也是 CoreText：Exception Type:
EXC_CRASH (SIGSEGV)
Exception Codes: 0x0
Application Specific Information:
Performing @selector(paste:) from sender NSMenuItem 0x6b85170
Thread 0:: Dispatch queue: com.apple.main-thread
com.apple.CoreText
0x9568e48f TStorageRange::SetStorageSubRange(CFRange) + 307
com.apple.CoreText
0x9568cdf7 TRun::TRun(TRun const&, CFRange, TRun::SubrangingStyle) + 853
com.apple.CoreText
0x9568ca8e CTGlyphRun::CloneRange(CTRun const*, CFRange, TRun::SubrangingStyle) + 166
com.apple.CoreText
0x TLine::SetLevelRange(CFRange, unsigned char, bool) + 157
com.apple.CoreText
0x TLine::SetTrailingWhitespaceLevel(unsigned char) + 86
com.apple.CoreText
0x9569aee7 TRunReorder::ReorderRuns(TBidiLevelsProvider const&, TLine&) + 107
com.apple.CoreText
0x9569ad8c TTypesetter::FinishLineFill(TLine&, double, double) const + 122
com.apple.CoreText
0x TTypesetter::FillLine(TLine&, CFRange, double, double) const + 90
com.apple.CoreText
0x9568c7ff CTTypesetterCreateLine + 185
com.apple.AppKit
0x98085a9a -[NSATSLineFragment layoutForStartingGlyphAtIndex:characterIndex:minPosition:maxPosition:lineFragmentRect:] + 802
com.apple.AppKit
0x9808452c -[NSATSTypesetter _layoutLineFragmentStartingWithGlyphAtIndex:characterIndex:atPoint:renderingContext:] + 2254
com.apple.AppKit
0x980a91cb -[NSATSTypesetter layoutParagraphAtPoint:] + 147
com.apple.AppKit
0x98645f21 -[NSTypesetter _layoutGlyphsInLayoutManager:startingAtGlyphIndex:maxNumberOfLineFragments:maxCharacterIndex:nextGlyphIndex:nextCharacterIndex:] + 3403
com.apple.AppKit
0x980a813a -[NSTypesetter layoutCharactersInRange:forLayoutManager:maximumNumberOfLineFragments:] + 215
com.apple.AppKit
0x980a8011 -[NSATSTypesetter layoutCharactersInRange:forLayoutManager:maximumNumberOfLineFragments:] + 1185
com.apple.AppKit
0x980a69c5 -[NSLayoutManager(NSPrivate) _fillLayoutHoleForCharacterRange:desiredNumberOfLines:isSoft:] + 738
com.apple.AppKit
0x980d9f1e _NSFastFillAllLayoutHolesForGlyphRange + 227
com.apple.AppKit
0x980a4f95 -[NSLayoutManager textContainerForGlyphAtIndex:effectiveRange:] + 198
com.apple.AppKit
0x97ee4a80 -[NSTextView(NSPrivate) _ensureLayoutCompleteToEndOfCharacterRange:] + 125
com.apple.AppKit
0x97ee442b -[NSTextView(NSSharing) didChangeText] + 159
com.apple.AppKit
0x97ee1f71 -[NSTextView insertText:replacementRange:] + 2261
com.tencent.qq
0x003ed850 -[TXTypingTextView insertText:replacementRange:] + 163
com.apple.AppKit
0x985b57f0 -[NSTextView insertText:] + 319
com.tencent.qq
0x003cfd6c -[TXBaseTextView AddAttributedString:] + 69
com.tencent.qq
0x003d2a0c -[TXBaseTextView ReadFromPasteborad:] + 392
com.tencent.qq
0x003ee97f -[TXTypingTextView paste:] + 98
libobjc.A.dylib
0x96dbc5d3 -[NSObject performSelector:withObject:] + 70
com.apple.AppKit
0x98110ad2 -[NSApplication sendAction:to:from:] + 436
com.apple.AppKit
0x9824d2fc -[NSMenuItem _corePerformAction] + 529
com.apple.AppKit
0x9824cf8b -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 163
com.apple.AppKit
0x -[NSMenu _performActionWithHighlightingForItemAtIndex:sendAccessibilityNotification:] + 79
com.apple.AppKit
0x -[NSMenu _performActionWithHighlightingForItemAtIndex:] + 48
com.apple.AppKit
0x9824bac5 -[NSMenu performKeyEquivalent:] + 306
com.tencent.qq
0x0053233e -[TXMenu performKeyEquivalent:] + 503
com.apple.AppKit
0x9824ae7c -[NSApplication _handleKeyEquivalent:] + 915
com.apple.AppKit
0x98100de1 -[NSApplication sendEvent:] + 5512
com.apple.AppKit
0x9801a62c -[NSApplication run] + 951
com.apple.AppKit
0x97fbd5f6 NSApplicationMain + 1053
com.tencent.qq
0x start + 53
这就说明在 OS X 10.8 上，CoreText 才是真凶。因此 iOS 和 OS X 上各有不同的 bug，而不能想当然地认为凶手只有一个。
转自果壳：看上去是IOS6的complex text layout render engine的问题。在计算机中，阿拉伯文，天城文，越南文这类文字被称为complex text，主要的特征就是字符会因为所在的位置，或者附加符号而产生形变。比如阿拉伯文的同一个字母，会因为所处的位置有4种不同的形态。越南的国语字(Ch? Qu?c Ng?)虽然是以拉丁字母为基础，但是复杂的音调系统会造成字符变形，所以也属于complex text. 对于人来说，complex text就是一个死记硬背的过程。而对于计算机来说，就变成一个麻烦事儿。因为保存在存储器上的文本，无法直接逐字符呈现给用户看。举例比如梵文中佛陀(buddha)一词，存储的时候会逐字存储为 ? ? ? ? ?五个字符，但是如果直接这么画出来，谁都看不懂。 所以这就需要一个complex text layout render engine，它的作用就是把存储的complex text组合后画出来，变成可以正常阅读的形式。 比如Windows下的uniscribe，就是这么个东西。 这个render engine依赖于两个东西来工作。第一是逐语言的规则。也就是说，藏文一套规则，阿拉伯文一套规则，印地语一套规则，梵文一套规则..... 所以包含了多少种语言的规则，就可以按规则对字符组合，画出来多少种语言的文字来。第二是字体文件内部的合字规则(ligature)，OpenType和AAT字体支持ligature。 同样的，Unicode标准提供了一系列用于进行组合的字符，其中一部分就是为了支持complex text的。比如上面看到的? ? 就是天城体中的元音附记。 那么绕回来，为什么IOS6可能出问题。看上去就是它的complex text layout render engine的规则出问题了。上边的字串中包含了3个Unicode组合字符。U+0310, U+0334, U+0337. 而不幸的是，这三个字符都不用于阿拉伯语。U+0310叫新月点，一般用于转写天城文，孟加拉文等时标记在拉丁字符上的。U+0334是用于国际音标中标记鼻化元音的那个小波浪线，学法语的同学肯定很熟悉。 U+0337是短删除线。 这几个字符都不是用在阿拉伯语中的。 所以当IOS6的engine（原谅我，懒得敲那么长了）在处理这一串字符的时候，会根据字符的范围，判定为阿拉伯字符，再根据字符出现的概率选择一种规则（这步可能没有，但是因为很多语言使用阿拉伯字符，比如乌尔都语，所以这步其实有必要），假定为选择了阿拉伯语规则。那么规则里发现找不到这三个组合字符，伤不起啊有木有！ 然后，挂了....... 从程序猿角度来说，没有default fall through处理嘛，bug！原文链接：
不完全同意
的答案，iOS 6 上即使是 UILabel 也是用 WebCore 渲染的。我倾向于 CoreText 和 WebCore 各自都有问题。这个 bug 应该归结为苹果从 WebCore 到 CoreText 都存在设计缺陷，对从右往左的编辑方向支持的不好，设计上没有考虑这种字符序列，而不能单纯说 WebCore 或者 CoreText 的某个地方有个小 bug。我们看一下它们 crash 在什么地方。从 iOS 和 OSX 的 crash 上看它们 crash 在不同的地方。iOS crash 在 WebCore 的 ComplexTextController::adjustGlyphsAndAdvances()，OSX 则 crash 在 CoreText 的
TRun::TRun(TRun const&, CFRange, TRun::SubrangingStyle) 或者 TRun::TruncateUnorderedEnd(CFRange, bool, TCharStream const&) 等地方。因为不知道 binary 对应的源码版本，不确定 iOS adjustGlyphsAndAdvances crash 在源码的哪一行上。OSX 虽然 crash 在 CoreText 上，也不能排除是 WebCore 调用 CoreText 的 CTTypesetterCreateLine 函数时传的 typesetter 参数有问题。10.9 上部分控件同样有这个问题，当把一个文件的文件名设为这段字符的时候 Finder 崩溃（如果你把这个文件放在桌面上……）。那么，为什么说这个问题不是单独由 CoreText 引起的呢？首先，OSX 10.8 使用 Firefox 是不会 crash 的。其次，OSX 10.8 上只修改 WebCore，可以绕过这个 bug（注释掉这个 if 的前一半）：//
if (!m_mayUseNaturalWritingDirection || m_run.directionalOverride()) {
static const void* optionKeys[] = { kCTTypesetterOptionForcedEmbeddingLevel };
const short ltrForcedEmbeddingLevelValue = 0;
const short rtlForcedEmbeddingLevelValue = 1;
static const void* ltrOptionValues[] = { CFNumberCreate(kCFAllocatorDefault, kCFNumberShortType, &ltrForcedEmbeddingLevelValue) };
static const void* rtlOptionValues[] = { CFNumberCreate(kCFAllocatorDefault, kCFNumberShortType, &rtlForcedEmbeddingLevelValue) };
static CFDictionaryRef ltrTypesetterOptions = CFDictionaryCreate(kCFAllocatorDefault, optionKeys, ltrOptionValues, WTF_ARRAY_LENGTH(optionKeys), &kCFCopyStringDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
static CFDictionaryRef rtlTypesetterOptions = CFDictionaryCreate(kCFAllocatorDefault, optionKeys, rtlOptionValues, WTF_ARRAY_LENGTH(optionKeys), &kCFCopyStringDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
//#if PLATFORM(IOS) || __MAC_OS_X_VERSION_MIN_REQUIRED &= 1070
ProviderInfo info = { cp, length, stringAttributes.get() };
RetainPtr&CTTypesetterRef& typesetter = adoptCF(wkCreateCTTypesetterWithUniCharProviderAndOptions(&provideStringAndAttributes, 0, &info, m_run.ltr() ? ltrTypesetterOptions : rtlTypesetterOptions));
RetainPtr&CFStringRef& string = adoptCF(CFStringCreateWithCharactersNoCopy(kCFAllocatorDefault, cp, length, kCFAllocatorNull));
RetainPtr&CFAttributedStringRef& attributedString = adoptCF(CFAttributedStringCreate(kCFAllocatorDefault, string.get(), stringAttributes.get()));
RetainPtr&CTTypesetterRef& typesetter = adoptCF(CTTypesetterCreateWithAttributedStringAndOptions(attributedString.get(), m_run.ltr() ? ltrTypesetterOptions : rtlTypesetterOptions));
line = adoptCF(CTTypesetterCreateLine(typesetter.get(), CFRangeMake(0, 0)));
ProviderInfo info = { cp, length, stringAttributes.get() };
line = adoptCF(wkCreateCTLineWithUniCharProvider(&provideStringAndAttributes, 0, &info));
修改后这段字符串可以正常显示：另外，另外，在 iOS 6 上直接用 CoreText 渲染这段文字，是没有问题的（有图有真相）：10.8 上 Safari crash 在 WebCore 调用 CoreText 里:10.9 上 Finder 崩溃的部分异常栈：Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
libvDSP.dylib
0x00007fff8df210b3 0x7fff8deb4000 + 446643
com.apple.CoreText
0x00007fff853b7ce7 TRun::TruncateUnorderedEnd(CFRange, bool, TCharStream const&) + 1207
com.apple.CoreText
0x00007fff853b77ed TTruncator::AppendTruncatedRun(TLine&, CTRun const*, CFRange, bool) + 109
com.apple.CoreText
0x00007fff853b7261 TTruncator::TruncateEndChars(long, double, TLine&, bool*) + 425
com.apple.CoreText
0x00007fff853c7b92 TTruncator::MiddleTruncate(double, __CTRun const* (__CTLine const*, CFRange*, __CFDictionary const*) block_pointer) + 342
com.apple.CoreText
0x00007fff853b6939 CTLineCreateTruncatedLineWithTokenHandler + 236
com.apple.CoreText
0x00007fff853b6847 CTLineCreateTruncatedLineWithTokenCallback + 81
com.apple.AppKit
0x00007fff83be9ff4 -[NSATSLineFragment layoutForStartingGlyphAtIndex:characterIndex:minPosition:maxPosition:lineFragmentRect:] + 2372
com.apple.AppKit
0x00007fff83be825a -[NSATSTypesetter _layoutLineFragmentStartingWithGlyphAtIndex:characterIndex:atPoint:renderingContext:] + 2777
com.apple.AppKit
0x00007fff83ebdddf -[NSSingleLineTypesetter
iOS 6 的 crash 只 crash 在 WebCore 里: 4
libsystem_platform.dylib
0x992ebdeb _sigtramp + 43
0xffffffff 0x0 +
0x04936db7 _ZN7WebCore21ComplexTextControllerC2EPKNS_4FontERKNS_7TextRunEbPN3WTF7HashSetIPKNS_14SimpleFontDataENS7_7PtrHashISB_EENS7_10HashTraitsISB_EEEEb + 855
0x04936a5a _ZN7WebCore21ComplexTextControllerC1EPKNS_4FontERKNS_7TextRunEbPN3WTF7HashSetIPKNS_14SimpleFontDataENS7_7PtrHashISB_EENS7_10HashTraitsISB_EEEEb + 58
0x04b71216 _ZNK7WebCore4Font34getGlyphsAndAdvancesForComplexTextERKNS_7TextRunEiiRNS_11GlyphBufferENS0_20ForTextEmphasisOrNotE + 70
0x04b713fd _ZNK7WebCore4Font15drawComplexTextEPNS_15GraphicsContextERKNS_7TextRunERKNS_10FloatPointEii + 173
0x04b69058 _ZNK7WebCore4Font8drawTextEPNS_15GraphicsContextERKNS_7TextRunERKNS_10FloatPointEii + 296
0x04bd9c68 _ZN7WebCore15GraphicsContext12drawBidiTextERKNS_4FontERKNS_7TextRunERKNS_10FloatPointEPNS_10BidiStatusEi + 968
0x _ZL11drawAtPointPKtiRKN7WebCore10FloatPointERKNS1_4FontEPNS1_15GraphicsContextEbPNS1_10BidiStatusEi + 326
总结起来，CoreText 和 WebCore 都有问题。
========更新=========== 大神亲自在Mac上编译了WebKit，然后发现了问题的触发点，就是WebCore里面的对于自然语言排版的判断存在问题，相关代码我引用一下：//
if (!m_mayUseNaturalWritingDirection || m_run.directionalOverride()) {
static const void* optionKeys[] = { kCTTypesetterOptionForcedEmbeddingLevel };
const short ltrForcedEmbeddingLevelValue = 0;
const short rtlForcedEmbeddingLevelValue = 1;
static const void* ltrOptionValues[] = { CFNumberCreate(kCFAllocatorDefault, kCFNumberShortType, &ltrForcedEmbeddingLevelValue) };
static const void* rtlOptionValues[] = { CFNumberCreate(kCFAllocatorDefault, kCFNumberShortType, &rtlForcedEmbeddingLevelValue) };
static CFDictionaryRef ltrTypesetterOptions = CFDictionaryCreate(kCFAllocatorDefault, optionKeys, ltrOptionValues, WTF_ARRAY_LENGTH(optionKeys), &kCFCopyStringDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
static CFDictionaryRef rtlTypesetterOptions = CFDictionaryCreate(kCFAllocatorDefault, optionKeys, rtlOptionValues, WTF_ARRAY_LENGTH(optionKeys), &kCFCopyStringDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
//#if PLATFORM(IOS) || __MAC_OS_X_VERSION_MIN_REQUIRED &= 1070
ProviderInfo info = { cp, length, stringAttributes.get() };
RetainPtr&CTTypesetterRef& typesetter = adoptCF(wkCreateCTTypesetterWithUniCharProviderAndOptions(&provideStringAndAttributes, 0, &info, m_run.ltr() ? ltrTypesetterOptions : rtlTypesetterOptions));
RetainPtr&CFStringRef& string = adoptCF(CFStringCreateWithCharactersNoCopy(kCFAllocatorDefault, cp, length, kCFAllocatorNull));
RetainPtr&CFAttributedStringRef& attributedString = adoptCF(CFAttributedStringCreate(kCFAllocatorDefault, string.get(), stringAttributes.get()));
RetainPtr&CTTypesetterRef& typesetter = adoptCF(CTTypesetterCreateWithAttributedStringAndOptions(attributedString.get(), m_run.ltr() ? ltrTypesetterOptions : rtlTypesetterOptions));
line = adoptCF(CTTypesetterCreateLine(typesetter.get(), CFRangeMake(0, 0)));
ProviderInfo info = { cp, length, stringAttributes.get() };
line = adoptCF(wkCreateCTLineWithUniCharProvider(&provideStringAndAttributes, 0, &info));
注释掉的代码应该就是问题所在报错的位置就在line = adoptCF(CTTypesetterCreateLine(typesetter.get(), CFRangeMake(0, 0)));
这一行对于这个终极解答，我个人认为这个表明，WebCore处理自然语言的时候存在问题，CoreText也存在问题不过就WebCore是在处理完了之后丢给CoreText的时候出的问题，我觉得CoreText应该要负主要责任。至于CoreText，这货只要苹果不开源，我们永远不知道他到底是怎么『杀人』的……=========顶部注明==========感觉有些乱了，和 还有 两位知乎iOS大神交流也不太通畅，似乎是因为周六他们都在泡妹子的原因……（穷苦Loser蹲家里）这个注明主要是为了指出一个区别，那就是Mac OSX上面我说的CoreText，和iOS上我说的CoreText，指的都是系统对于文字的绘制和排版底层库，而不是传说中iOS上的CoreText.framework。我个人认为，iOS和Mac OSX上，CoreText和WebKit都是具有绝对的排版功能的，但是在层级上，CoreText应该是作为WebKit的底层存在的，如果说CoreText有问题，那么WebKit和其中的WebCore也会出现问题。然后iOS上面的CoreText.framework和Mac OSX上面的实现应该是完全不一样的。iOS上面CoreText.framework可能为了更加方便的使用和复用库，将AttributeString部分交给了UIWebDocumentView，也就是Webkit中的WebCore去处理。而Mac OSX上，整个处理过程可能是完全依赖于底层CoreText库的。说白了，就是iOS上面的CoreText.framework只是我们看到的一个苹果玩的Trick，他并没有连接到底层的CoreText实现，只是一个建立在WebKit上面的封装。然后，由于WebKit和CoreText都具有排版能力，在完全交给WebCore来排版的时候不会出问题『@祝博韬 的回答』，但是一旦涉及到了底层CoreText来进行排版，那就会出错。==========注明完毕===========首先，我个人觉得，这个问题的真正原因在于：[1]Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
libvDSP.dylib
0x00007fff9080ead6 0x7fff907f2000 + 117462
com.apple.CoreText
0x00007fff8892cd5c TRun::TRun(TRun const&, CFRange, TRun::SubrangingStyle) + 850
com.apple.CoreText
0x00007fff8892c9ee CTGlyphRun::CloneRange(CTRun const*, CFRange, TRun::SubrangingStyle) + 142
com.apple.CoreText
0x00007fff TLine::SetLevelRange(CFRange, unsigned char, bool) + 162
com.googlecode.iterm2
0xce63 -[PTYTextView(Private) drawRun:ctx:initialPoint:] + 99
com.googlecode.iterm2
0xd498 -[PTYTextView(Private) _drawRuns:runs:] + 344
com.googlecode.iterm2
0x1bd4 start + 52
CoreText！CoreText是用来干什么的呢？基本上你在iOS和Mac OSX上面看到的所有字符，都是通过CoreText来进行渲染的。所以CoreText的这个Bug，会导致所有显示字符的地方都会因为这串字符而崩溃。当然，由于iOS的特殊性，这个崩溃看上去更像是由WebCore导致的[2]Thread 2 name:
Thread 2 Crashed:
0x382fe95a WebCore::ComplexTextController::adjustGlyphsAndAdvances() + 522
0x382fb94e WebCore::ComplexTextController::ComplexTextController(WebCore::Font const*, WebCore::TextRun const&, bool, WTF::HashSet&WebCore::SimpleFontData const*, WTF::PtrHash&WebCore::SimpleFontData const*&, WTF::HashTraits&WebCore::SimpleFontData const*& &*, bool) + 318
0x382fb806 WebCore::ComplexTextController::ComplexTextController(WebCore::Font const*, WebCore::TextRun const&, bool, WTF::HashSet&WebCore::SimpleFontData const*, WTF::PtrHash&WebCore::SimpleFontData const*&, WTF::HashTraits&WebCore::SimpleFontData const*& &*, bool) + 18
0x382ff990 WebCore::Font::getGlyphsAndAdvancesForComplexText(WebCore::TextRun const&, int, int, WebCore::GlyphBuffer&, WebCore::Font::ForTextEmphasisOrNot) const + 56
0x382ff862 WebCore::Font::drawComplexText(WebCore::GraphicsContext*, WebCore::TextRun const&, WebCore::FloatPoint const&, int, int) const + 150
（WTF这个……Apple的开发人员啊……）这里由于我粘贴复制的原因，Gist和引用的可能有些不同，这里提供一个另外的Gist，来自于我自己测试的结果[5]（178行报错）。至于引用部分，来自[1]中的讨论串，Gist部分来自讨论串下面的链接。为了引用的完整性，我就不另作处理了，详细问题大家可以去[1]中找到作者链接询问作者。这里会有同学问道为什么iOS的特性会导致看上去像是WebCore的错误，这里我贴上一张图片[3]：这张图片的进程显示出iOS在处理Text的一个Trick，那就是富文本内容实际上会被NSHTMLWriter处理。当然非富文本作为富文本的子集自然也是通过这条路的（可能），HTML相关嘛，当然会被WebCore拿走咯，结果就是在WebCore的时候死掉了……当然这个只是推测，详细的估计还是得把整个Bug发生流程拆了才知道。这张图片的进程显示出iOS在处理Text的一个Trick，那就是富文本内容实际上会被NSHTMLWriter处理。当然非富文本作为富文本的子集自然也是通过这条路的（可能），HTML相关嘛，当然会被WebCore拿走咯，结果就是在WebCore的时候死掉了……当然这个只是推测，详细的估计还是得把整个Bug发生流程拆了才知道。今天有很多同学都在质疑iOS 上 CoreText是否是决定性元凶，各种代码和Error Log都展现出WebCore的嫌疑（名侦探柯南既视感……），看到这么多同学的质疑，说实在我有点吃不消……亚历山大……但是刚才我看到一个Chromium在Mac OSX上面的Error Log [6]，从这个Error Log上，我们可以发现这货： 1 Google Chrome Framew0.894.0.0
0x012f8451 WebCore::ComplexTextController::adjustGlyphsAndAdvances + 0x7 (ComplexTextController.cpp:479)
adjustGlyphsAndAdvance这货看上去是不是很熟悉，和iOS上面WebCore报错的那玩意一模一样吧根据大神提供的Mac OSX上Safari的Error Log：Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
libvDSP.dylib
0x00007fff8efdbadb 0x7fff8efbf000 + 117467
com.apple.CoreText
0x00007fff8e6c1d5c TRun::TRun(TRun const&, CFRange, TRun::SubrangingStyle) + 850
com.apple.CoreText
0x00007fff8e6c19ee CTGlyphRun::CloneRange(CTRun const*, CFRange, TRun::SubrangingStyle) + 142
com.apple.CoreText
0x00007fff8e6d0764 TLine::SetLevelRange(CFRange, unsigned char, bool) + 162
com.apple.CoreText
0x00007fff8e6d1e2c TLine::SetTrailingWhitespaceLevel(unsigned char) + 70
com.apple.CoreText
0x00007fff8e6d1d58 TRunReorder::ReorderRuns(TBidiLevelsProvider const&, TLine&) + 122
com.apple.CoreText
0x00007fff8e6d1bfe TTypesetter::FinishLineFill(TLine&, double, double) const + 142
com.apple.CoreText
0x00007fff8e6c1775 CTTypesetterCreateLine + 131
com.apple.WebCore
0x00007fff8f7f1f1a WebCore::ComplexTextController::collectComplexTextRunsForCharactersCoreText(unsigned short const*, unsigned int, unsigned int, WebCore::SimpleFontData const*) + 1562
com.apple.WebCore
0x00007fff8f7f176a WebCore::ComplexTextController::collectComplexTextRuns() + 522
WebCore报错的根本还是在于CoreText一样的WebCore Function，我觉得苹果然两个WebKit实现机制一致实在是可能性太高了但是限于沙盒机制（待验证），CoreText的报错被隐藏了，就像Chromium的报错一样，你看不到CoreText，但实际上CoreText就站在那里，拿着带血的小匕首。当然，鉴于iOS和Mac OSX的处理机制存在一定差异，最终解释还要看苹果内部有没有人愿意站出来说明一下了。再补充一个新的证据，根据 和我本人的实验，在UILabel长度不足以显示完整整个字符串的时候，这个Bug是不会被触发的，根据WebKit相关代码[7]，我个人认为WebKit的排版不会负责对于显示空间的判断，所以CoreText在绘制部分出错的可能性更高。就和所有文字排版导致的问题一样，这次出现的这串字符也有一个很有趣的效应，详细大家可以去看看我这个项目：这小玩意挺好玩的，而且我相信这个项目对于帮助大家理解这次Bug和UILabel处理文字排版的机制也是很有帮助的。[注明：以上所有分析都存在一个绝对假设：Bug只存在一处。如果Bug存在WebCore和CoreText等多处，或者说Bug来自于苹果开发人员对于整个字段理解错误，那么上面的所有分析几乎都不成立。]那么关于发生Bug的根本原因呢？通过上面的所有Log，我们至少可以得出一个结论，那就是万恶的Range检测失败了。在苹果的系统中，一般来说对于文字内容的检测都是分成一个个Range来细化处理的，这次的字符串很有可能是一个需要被联合到一起处理的内容，但是由于种种原因，对于处理区域的检测判定失败了（或者重叠了），所以产生了不可避免的错误。如果大家有幸在Mac OSX 10.8上面看到这串字符而且没有使得闪退的话，应该会发现在某些时候这段字符自动换行了，也许就是这个被强加的换行处理和换行字符的连续处理两个渲染重叠产生了问题。如果说要详细研究的话，就得去研究这串阿拉伯文的语义和相关语法了……之后呢？由于WP和Android用户，还有广大人民群众对于iOS和Mac OSX用户深深的恶意，还有诸如 等大V无心的传播，导致从早上到下午，无数的iOS和Mac OSX用户中枪。上午我在公司的时候，QQ开着，基本上每个QQ群都在刷，浏览了一下各种科技网站，满目这串字符，微信朋友圈一阵哀嚎，还有无数转发微博在那里求证、攻击……最后的结果就是，无数的人短信打不开了，微信打不开了，QQ打不开了……好在大部分电脑小白都给Macbook Pro装了Windows，不然杀伤人数会增加更多。至于iOS用户，那真是只能自求多福。当然除了自求多福之外，还有些事情是可以做的。升级iOS7。iOS7正在进行最后一个Beta，现在升级并不需要去淘宝或者找其他开发者要开发者权限，直接在威锋或者其他网站上下一个就好了，然后按照教程升级即可。（说得巧，今天下午威锋刚好论坛升级，直接导致某些淘宝卖家赚了不少黑心钱）越狱用户可以安装 提到的那个补丁对于微信，可以在接收到这个字符之后，通过Windows上的诸如iTools等软件的微信查看功能来删除对应聊天记录；短信可以通过某些苹果助手内置的短信编辑功能来删除对应字符（需要关闭iCloud之后才可操作）Mac用户可以修改系统字体，字体修改之后似乎可以绕过这个Bug[4]当然，之后也许你应该把给你发这段字符的人给拉黑，或者直接起诉他或者苹果公司（如果有重大利益损失并且你可以证明的话）再之后呢？在之后我们似乎应该想想，为什么会发生下午这个状况。略带恶意的玩笑？无心的调侃？亦或者宣泄不满的攻击？还是说是苹果为了让iOS 6用户尽快升级留下的黑手？想象空间太大了。虽然我的设备都升级到了iOS 7 Beta，Macbook Pro也做了响应的保护性处理（关闭所有推送，转发所有收到的信息到Windows电脑或者iOS 7设备），但是想着我母上大人手中的iPhone可能因此而没法看短信，没法看微信，说真的我恨愤怒。我不在她身边，也没有办法远程解决这个不太好解决的问题，如果她中招，那么接下来，她可能得被迫放弃iPhone和里面的所有资料。想到她可能的焦虑，我很无力，很愤怒。我懒得再去猜测那么还在疯狂转发那段纯攻击性的阿拉伯字符的人的想法了。人的恶意，真的是无法揣测的。[1][2][3][4][5][6][7]
我觉得，可能是系统不够清真的缘故。大家知道的，美国佬都是异教徒，异教徒的东西，对阿拉伯人民来说，简直是大罪孽。
今天发现了一条有关 iOS6 的bug, 只要在 iOS6的手机上出现某特定字符串,就会引起闪退,比如微信朋友圈,只要有人在朋友圈中发了那条指定字符串,他的朋友一打开朋友圈就会闪退,还有手机 QQ,短信,备忘录等,都会出现这种情况,据有人分析可能是因为 iOS6的字库有漏洞,导致只要显是该字符串就会出现闪退(未证实,不确定)
我就很好奇的开始了实验,首先通过MBP里面的备忘录,存了这条字符串,我的备忘录是通过 iCloud 同步的,然后从手机上打开备忘录,发现直接闪退...然后我准备通过网页版微信给自己发这条字符串,发现刚复制到对话框,网页直接崩溃...接着我在电脑上的 QQ 群里面发了这条字符串,通过手机 QQ 去看,手机 QQ 直接被废.我同事的手机升级了 iOS7,我让他给我发微信,他发给我之后我的微信也被废了,直接无法打开.然后他给我发短信,这条字符串通过推送出现在手机屏幕上的时候我的手机直接重启了,之后短信就无法打开,经过以上手贱的实验,发现这个漏洞实在是杀伤力巨大....总的原则就是只要你的手机显示了这条字符串,就会崩溃.
我说一下初步的解决方案,如果在朋友圈中有人发送了这条消息,那么可以等到你朋友圈中的其他人发的消息把该字符串给刷掉,也就是说只要你朋友圈中一个屏幕内没有这条字符串,就不会崩溃,但是当你往下翻,翻出了这条字符串,照旧会闪退,只有当发布该字符串的人删除了这条消息,才会没事.而如果对方是通过微信或者 手机 QQ 单独发送给你这条字符串,你需要删除微信或者 QQ,重新安装,目的是删除存在本地的聊天记录,只要手机不显示该字符串,就不会闪退.至于短信,让发送者给你再发一条短信,然后让另一个人也给你发一条短信,这样就能打开短信了,然后你把包含该字符串那个对话给删除就可以了
最彻底的解决方案就是升级 iOS7...但是需要开发者帐号,所以不具备普遍意义,我觉得如此严重的 bug,苹果应该会很快发布升级补丁,所以各位也不用惊慌,这个这个补丁从技术上推测应该是很简单解决的(楼主的手机已经彻底被自己玩坏掉了...现在正在升级 iOS7)
对于那个说是core text导致crash的答案，我存在一些疑惑，理由如下：最底下是我自己用mobile safari查看这个阿拉伯字符串拿到的crash log，可以清楚的看到crash的线程就是WebCore，stack trace里面也没有core text framework的调用。从这个文章看，webkit在osx和iOS有使用core text做文字渲染
如果有问题，只可能是这一步有问题说coretext导致崩溃的那个答案的引文2中的gist和我这个crash log几乎一致,但是和答案中贴的crash log不一致。而该答案中引用的crash log从引文1中看应该是在使用iTerms2的时候的crash log，而非浏览器本身，而且从上层调用中看到的PTYTextView我google了一下好像是iTerms2的私有类，所以是否iTerms中看到core text在stack trace上仅仅是个例，会不会是iTerms2中的PTYTextView自身有bug？说coretext导致崩溃的那个答案中引文1的那个论坛，楼下很多都回复使用iTerms无法重现该crash，让我更加怀疑是不是个案。我并不是说一定就不是core text的问题，只是认为那个答案的论证方法存在漏洞，而且夹带大量私货，对于技术问题的讨论这样是不恰当的，尤其是在有非技术人员会浏览的论坛。Exception Type:
EXC_BAD_ACCESS (SIGSEGV)Exception Codes: KERN_INVALID_ADDRESS at 0xCrashed Thread:
2Thread 0 name:
Dispatch queue: com.apple.main-threadThread 0:0
libsystem_kernel.dylib
0x3a309e30 mach_msg_trap + 201
libsystem_kernel.dylib
0x3a309fd0 mach_msg + 482
CoreFoundation
0x __CFRunLoopServiceMachPort + 1263
CoreFoundation
0x320fefd6 __CFRunLoopRun + 8144
CoreFoundation
0x CFRunLoopRunSpecific + 3525
CoreFoundation
0x CFRunLoopRunInMode + 1006
GraphicsServices
0x35c51336 GSEventRunModal + 707
0x33f8e2b4 UIApplicationMain + 11168
MobileSafari
0x000e736e 0xda000 + 541269
libdyld.dylib
0x3a253b1c start + 0Thread 1 name:
Dispatch queue: com.apple.libdispatch-managerThread 1:0
libsystem_kernel.dylib
0x3a30a5d0 kevent64 + 241
libdispatch.dylib
0x3a245d22 _dispatch_mgr_invoke + 8062
libdispatch.dylib
0x3a241374 _dispatch_mgr_thread + 32Thread 2 name:
WebThreadThread 2 Crashed:0
0x382f295a WebCore::ComplexTextController::adjustGlyphsAndAdvances() + 5221
0x382ef94e WebCore::ComplexTextController::ComplexTextController(WebCore::Font const*, WebCore::TextRun const&, bool, WTF::HashSet&WebCore::SimpleFontData const*, WTF::PtrHash&WebCore::SimpleFontData const*&, WTF::HashTraits&WebCore::SimpleFontData const*& &*, bool) + 3182
0x382ef806 WebCore::ComplexTextController::ComplexTextController(WebCore::Font const*, WebCore::TextRun const&, bool, WTF::HashSet&WebCore::SimpleFontData const*, WTF::PtrHash&WebCore::SimpleFontData const*&, WTF::HashTraits&WebCore::SimpleFontData const*& &*, bool) + 183
0x382f3990 WebCore::Font::getGlyphsAndAdvancesForComplexText(WebCore::TextRun const&, int, int, WebCore::GlyphBuffer&, WebCore::Font::ForTextEmphasisOrNot) const + 564
0x382f3862 WebCore::Font::drawComplexText(WebCore::GraphicsContext*, WebCore::TextRun const&, WebCore::FloatPoint const&, int, int) const + 1505
0x WebCore::Font::drawText(WebCore::GraphicsContext*, WebCore::TextRun const&, WebCore::FloatPoint const&, int, int) const + 2006
0x381d8e04 WebCore::paintTextWithShadows(WebCore::GraphicsContext*, WebCore::Font const&, WebCore::TextRun const&, WTF::AtomicString const&, int, int, int, int, WebCore::FloatPoint const&, WebCore::FloatRect const&, WebCore::ShadowData const*, bool, bool) + 3007
0x381d7b2a WebCore::InlineTextBox::paint(WebCore::PaintInfo&, WebCore::IntPoint const&, int, int) + 22508
0x381d34a0 WebCore::InlineFlowBox::paint(WebCore::PaintInfo&, WebCore::IntPoint const&, int, int) + 7809
0x381d311a WebCore::RootInlineBox::paint(WebCore::PaintInfo&, WebCore::IntPoint const&, int, int) + 2610
0x3810cb8e WebCore::RenderLineBoxList::paint(WebCore::RenderBoxModelObject*, WebCore::PaintInfo&, WebCore::IntPoint const&) const + 27411
0x3810955c WebCore::RenderBlock::paintObject(WebCore::PaintInfo&, WebCore::IntPoint const&) + 23212
0x WebCore::RenderBlock::paint(WebCore::PaintInfo&, WebCore::IntPoint const&) + 16813
0x38109a38 WebCore::RenderBlock::paintChildren(WebCore::PaintInfo&, WebCore::IntPoint const&) + 36014
0x WebCore::RenderBlock::paintObject(WebCore::PaintInfo&, WebCore::IntPoint const&) + 24415
0x WebCore::RenderBlock::paint(WebCore::PaintInfo&, WebCore::IntPoint const&) + 16816
0x WebCore::RenderLayer::paintLayerContents(WebCore::RenderLayer*, WebCore::GraphicsContext*, WebCore::IntRect const&, unsigned int, WebCore::RenderObject*, WebCore::RenderRegion*, WTF::HashMap&WebCore::OverlapTestRequestClient*, WebCore::IntRect, WTF::PtrHash&WebCore::OverlapTestRequestClient*&, WTF::HashTraits&WebCore::OverlapTestRequestClient*&, WTF::HashTraits&WebCore::IntRect& &*, unsigned int) + 176017
0x38107c3a WebCore::RenderLayer::paintLayer(WebCore::RenderLayer*, WebCore::GraphicsContext*, WebCore::IntRect const&, unsigned int, WebCore::RenderObject*, WebCore::RenderRegion*, WTF::HashMap&WebCore::OverlapTestRequestClient*, WebCore::IntRect, WTF::PtrHash&WebCore::OverlapTestRequestClient*&, WTF::HashTraits&WebCore::OverlapTestRequestClient*&, WTF::HashTraits&WebCore::IntRect& &*, unsigned int) + 108218
0x381084ba WebCore::RenderLayer::paintLayerContents(WebCore::RenderLayer*, WebCore::GraphicsContext*, WebCore::IntRect const&, unsigned int, WebCore::RenderObject*, WebCore::RenderRegion*, WTF::HashMap&WebCore::OverlapTestRequestClient*, WebCore::IntRect, WTF::PtrHash&WebCore::OverlapTestRequestClient*&, WTF::HashTraits&WebCore::OverlapTestRequestClient*&, WTF::HashTraits&WebCore::IntRect& &*, unsigned int) + 214619
0x38107c3a WebCore::RenderLayer::paintLayer(WebCore::RenderLayer*, WebCore::GraphicsContext*, WebCore::IntRect const&, unsigned int, WebCore::RenderObject*, WebCore::RenderRegion*, WTF::HashMap&WebCore::OverlapTestRequestClient*, WebCore::IntRect, WTF::PtrHash&WebCore::OverlapTestRequestClient*&, WTF::HashTraits&WebCore::OverlapTestRequestClient*&, WTF::HashTraits&WebCore::IntRect& &*, unsigned int) + 108220
0x WebCore::RenderLayer::paint(WebCore::GraphicsContext*, WebCore::IntRect const&, unsigned int, WebCore::RenderObject*, WebCore::RenderRegion*, unsigned int) + 5221
0x WebCore::FrameView::paintContents(WebCore::GraphicsContext*, WebCore::IntRect const&) + 52022
0x389ab6aa -[WebFrame(WebInternal) _drawRect:contentsOnly:] + 35423
0x389ab4d0 -[WebHTMLView drawSingleRect:] + 13224
0x389ab3fe -[WebHTMLView drawRect:] + 3025
0x38106f4e -[WAKView _drawRect:context:lockFocus:] + 27426
0x -[WAKView _drawRect:context:lockFocus:] + 58627
0x -[WAKView _drawRect:context:lockFocus:] + 58628
0x -[WAKView _drawRect:context:lockFocus:] + 58629
0x -[WAKView _drawRect:context:lockFocus:] + 58630
0x38106e2e -[WAKView displayRect:] + 9431
0x38106dc6 -[WAKWindow displayRect:] + 5032
0x38106ad0 WebCore::TileCache::drawLayer(TileLayer*, CGContext*) + 90033
QuartzCore
0x33cf39f8 CABackingStoreUpdate_ + 208834
QuartzCore
0x33cf3032 CA::Layer::display_() + 97035
QuartzCore
0x33cea0b2 CA::Layer::display_if_needed(CA::Transaction*) + 19836
QuartzCore
0x33ce9fdc CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 2037
QuartzCore
0x33ce99be CA::Context::commit_transaction(CA::Transaction*) + 23438
QuartzCore
0x33ce97d0 CA::Transaction::commit() + 31239
QuartzCore
0x33ce9634 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 5640
CoreFoundation
0x3210093e __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 1841
CoreFoundation
0x320fec34 __CFRunLoopDoObservers + 27242
CoreFoundation
0x3207225e CFRunLoopRunSpecific + 39043
CoreFoundation
0x CFRunLoopRunInMode + 10044
0x RunWebThread(void*) + 44045
libsystem_c.dylib
0x3a2730de _pthread_start + 30646
libsystem_c.dylib
0x3a272fa4 thread_start + 4Thread 3 name:
com.apple.NSURLConnectionLoaderThread 3:0
libsystem_kernel.dylib
0x3a309e30 mach_msg_trap + 201
libsystem_kernel.dylib
0x3a309fd0 mach_msg + 482
CoreFoundation
0x __CFRunLoopServiceMachPort + 1263
CoreFoundation
0x320ff02c __CFRunLoopRun + 9004
CoreFoundation
0x CFRunLoopRunSpecific + 3525
CoreFoundation
0x CFRunLoopRunInMode + 1006
Foundation
0x329bf888 +[NSURLConnection(Loader) _resourceLoadLoop:] + 3047
Foundation
0x32a4322c __NSThread__main__ + 9688
libsystem_c.dylib
0x3a2730de _pthread_start + 3069
libsystem_c.dylib
0x3a272fa4 thread_start + 4Thread 4 name:
Safari::SafeBrowsingManagerThread 4:0
libsystem_kernel.dylib
0x3a309e30 mach_msg_trap + 201
libsystem_kernel.dylib
0x3a309fd0 mach_msg + 482
CoreFoundation
0x __CFRunLoopServiceMachPort + 1263
CoreFoundation
0x320ff02c __CFRunLoopRun + 9004
CoreFoundation
0x CFRunLoopRunSpecific + 3525
CoreFoundation
0x CFRunLoopRunInMode + 1006
MobileSafari
0x000f1086 0xda000 + 943427
JavaScriptCore
0x WTF::wtfThreadEntryPoint(void*) + 128
libsystem_c.dylib
0x3a2730de _pthread_start + 3069
libsystem_c.dylib
0x3a272fa4 thread_start + 4Thread 5 name:
WebCore: CFNetwork LoaderThread 5:0
libsystem_kernel.dylib
0x3a309e30 mach_msg_trap + 201
libsystem_kernel.dylib
0x3a309fd0 mach_msg + 482
CoreFoundation
0x __CFRunLoopServiceMachPort + 1263
CoreFoundation
0x320ff02c __CFRunLoopRun + 9004
CoreFoundation
0x CFRunLoopRunSpecific + 3525
CoreFoundation
0x CFRunLoopRunInMode + 1006
0x38114ccc WebCore::runLoaderThread(void*) + 1407
JavaScriptCore
0x WTF::wtfThreadEntryPoint(void*) + 128
libsystem_c.dylib
0x3a2730de _pthread_start + 3069
libsystem_c.dylib
0x3a272fa4 thread_start + 4Thread 6 name:
com.apple.CFSocket.privateThread 6:0
libsystem_kernel.dylib
0x3a31a594 __select + 201
CoreFoundation
0x __CFSocketManager + 6762
libsystem_c.dylib
0x3a2730de _pthread_start + 3063
libsystem_c.dylib
0x3a272fa4 thread_start + 4Thread 7 name:
JavaScriptCore::BlockFreeThread 7:0
libsystem_kernel.dylib
0x3a31a08c __psynch_cvwait + 241
libsystem_c.dylib
0x3a26bafc _pthread_cond_wait + 6442
libsystem_c.dylib
0x3a26b870 pthread_cond_timedwait + 403
JavaScriptCore
0x36047df6 WTF::ThreadCondition::timedWait(WTF::Mutex&, double) + 1024
JavaScriptCore
0x JSC::BlockAllocator::blockFreeingThreadMain() + 785
JavaScriptCore
0x WTF::wtfThreadEntryPoint(void*) + 126
libsystem_c.dylib
0x3a2730de _pthread_start + 3067
libsystem_c.dylib
0x3a272fa4 thread_start + 4Thread 8 name:
JavaScriptCore::MarkingThread 8:0
libsystem_kernel.dylib
0x3a31a08c __psynch_cvwait + 241
libsystem_c.dylib
0x3a26bafc _pthread_cond_wait + 6442
libsystem_c.dylib
0x3a275cf8 pthread_cond_wait + 363
JavaScriptCore
0x360ed6dc JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode) + 1404
JavaScriptCore
0x360ed620 JSC::MarkStackThreadSharedData::markingThreadMain() + 1405
JavaScriptCore
0x WTF::wtfThreadEntryPoint(void*) + 126
libsystem_c.dylib
0x3a2730de _pthread_start + 3067
libsystem_c.dylib
0x3a272fa4 thread_start + 4Thread 9 name:
WebCore: LocalStorageThread 9:0
libsystem_kernel.dylib
0x3a31a08c __psynch_cvwait + 241
libsystem_c.dylib
0x3a26bafc _pthread_cond_wait + 6442
libsystem_c.dylib
0x3a275cf8 pthread_cond_wait + 363
JavaScriptCore
0x36047dc8 WTF::ThreadCondition::timedWait(WTF::Mutex&, double) + 564
0x3828ee7c WTF::PassOwnPtr&WebCore::StorageTask& WTF::MessageQueue&WebCore::StorageTask&::waitForMessageFilteredWithTimeout&bool (WebCore::StorageTask*)&(WTF::MessageQueueWaitResult&, bool (&)(WebCore::StorageTask*), double) + 525
0x3828ee30 WebCore::StorageThread::threadEntryPoint() + 1206
JavaScriptCore
0x WTF::wtfThreadEntryPoint(void*) + 127
libsystem_c.dylib
0x3a2730de _pthread_start + 3068
libsystem_c.dylib
0x3a272fa4 thread_start + 4Thread 10 name:
WebCore: LocalStorageThread 10:0
libsystem_kernel.dylib
0x3a31a08c __psynch_cvwait + 241
libsystem_c.dylib
0x3a26bafc _pthread_cond_wait + 6442
libsystem_c.dylib
0x3a275cf8 pthread_cond_wait + 363
JavaScriptCore
0x36047dc8 WTF::ThreadCondition::timedWait(WTF::Mutex&, double) + 564
0x3828ee7c WTF::PassOwnPtr&WebCore::StorageTask& WTF::MessageQueue&WebCore::StorageTask&::waitForMessageFilteredWithTimeout&bool (WebCore::StorageTask*)&(WTF::MessageQueueWaitResult&, bool (&)(WebCore::StorageTask*), double) + 525
0x3828ee30 WebCore::StorageThread::threadEntryPoint() + 1206
JavaScriptCore
0x WTF::wtfThreadEntryPoint(void*) + 127
libsystem_c.dylib
0x3a2730de _pthread_start + 3068
libsystem_c.dylib
0x3a272fa4 thread_start + 4Thread 11:0
libsystem_kernel.dylib
0x3a31ad98 __workq_kernreturn + 81
libsystem_c.dylib
0x3a268ad6 _pthread_workq_return + 142
libsystem_c.dylib
0x3a2687f2 _pthread_wqthread + 3623
libsystem_c.dylib
0x3a268680 start_wqthread + 4Thread 12:0
libsystem_kernel.dylib
0x3a31a08c __psynch_cvwait + 241
libsystem_c.dylib
0x3a26bafc _pthread_cond_wait + 6442
libsystem_c.dylib
0x3a275cf8 pthread_cond_wait + 363
MobileSafari
0xxda000 + 5891244
Foundation
0x32a4322c __NSThread__main__ + 9685
libsystem_c.dylib
0x3a2730de _pthread_start + 3066
libsystem_c.dylib
0x3a272fa4 thread_start + 4Thread 13:0
libsystem_kernel.dylib
0x3a31ad98 __workq_kernreturn + 81
libsystem_c.dylib
0x3a268ad6 _pthread_workq_return + 142
libsystem_c.dylib
0x3a2687f2 _pthread_wqthread + 3623
libsystem_c.dylib
0x3a268680 start_wqthread + 4Thread 14:0
libsystem_kernel.dylib
0x3a31ad98 __workq_kernreturn + 81
libsystem_c.dylib
0x3a268ad6 _pthread_workq_return + 142
libsystem_c.dylib
0x3a2687f2 _pthread_wqthread + 3623
libsystem_c.dylib
0x3a268680 start_wqthread + 4Thread 15:0
libsystem_kernel.dylib
0x3a31ad98 __workq_kernreturn + 81
libsystem_c.dylib
0x3a268ad6 _pthread_workq_return + 142
libsystem_c.dylib
0x3a2687f2 _pthread_wqthread + 3623
libsystem_c.dylib
0x3a268680 start_wqthread + 4Thread 2 crashed with ARM Thread State (32-bit):
r0: 0x0000001e
r1: 0x3a47dffc
r2: 0x0cf1d46a
r3: 0x24b2a7c4
r4: 0xffffffff
r5: 0x0000001f
r7: 0x017b4340
r11: 0x0ce49500
sp: 0x017b4210
lr: 0x382f2ba3
pc: 0x382f295a
可能是WebCore漏洞另引用今天国外hacker的讨论「This isn't a bug inside WebKit. It's a bug inside Apples CoreText font rendering framework.」或者二者兼有(无论WebCore还是CoreText问题都是目前的猜测，论据不明？)我就是看热闹的。放点干货各位自行判断:代码：感谢一位hacker赐教～解决办法@Fenng 针对微信朋友圈给出的方法：如果是微信朋友圈崩溃，你可以从微信「我」-「我的相册」进去，点击「今天」那里的相机，发张照片即可恢复。iMessage中招就请你的朋友给你发条正常短信过来。或是。。。升级你手机或mac系统版本以上对策来自 weibo @乌云—漏洞报告平台
3、如果是微信朋友圈崩溃，你可以从微信「我」-「我的相册」进去，点击「今天」那里的相机，发张照片即可恢复。不可恢复的说~谁还有办法？
題外話，這不是iOS的問題，甚至這個不是Apple的問題，在任何平台任何app中都有可能因為這段阿拉伯字符導致崩潰，不相信的可以做個實踐。打開word2013複製這段阿拉伯字符進去（純文本）加大這段阿拉伯字符的字號word一樣會崩潰。//
16：48修改在PC上才發現知乎可以傳圖，那麼來一張，證實一下在windows下，個別App也存在這個問題。不過圖片上來，居然被壓縮成jpg了。 gif走這裡：
我歪个楼大家不要没事只复制最后一句发朋友圈，不仅你自己开不了朋友圈，你的前好友们也开不了。别问我为什么是前好友...
ipad弄这个导致qq崩溃了,重新下载程序也没用,后来换了个小号登陆了一下没事,退出再登陆平常用的主号后就好了.不过奇怪的是,我开始就是在电脑上用小号发的这窜字符导致主号崩溃,可是登陆小号调出的聊天记录查看这窜字符却不崩溃,不知道为什么.
问题原因楼上有人分析了，我说一下解决方案。针对短信，微信，如果只是朋友恶作剧，让你朋友发一条新的短信过来就可以，微信的话多发十几条新的微信把代码刷出屏幕范围，然后 记得清除记录 ，否则不小心划过去又看到了。其他应用直接删除重新安装，空间这一类的，先用其他系统手机电脑把这个发代码说说的人拉黑，然后手机上重装app。
解决方法是升级IOS7
非程序猿的IOS使用者弱弱的说一句…IOS8暂时没中招，已经有人发过这种东西了但是没问题
自己发了个微信朋友圈 然后无法删除 有什么方法解决？
奔溃可能原因：解析有问题临时解决方案：1、找一个朋友发一条普通的短信2、如果是ipad/mac用户，卸载，重新安装，先用小号登陆，然后注销，最后再用大号登陆即可。3、如果是微信朋友圈崩溃，你可以从微信「我」-「我的相册」进去，点击「今天」那里的相机，发张照片即可恢复。解决方案1、3来自：
这都几年了？？？？？至少13年之前卧槽。。。果然是坟}