1
Posted on 下午9:22:00 by Fan Zhang and filed under

  今天我新买的笔记本发现一个问题,插着网线开机可以连上网络,但是如果开机后才插上网线,就连接不上。我一开始以为是没有检测到网络自动把网卡关闭了,但是后来发现不是这样,因为有的时候多插拔几次也能连上。

  在网卡中设置电源管理或者禁用网卡重新启用,也能连上,但是重启后故障依旧。

  换了网线也是如此。

  我怀疑可能是路由器问题,于是换了网线,不接路由器,就正常了。

0
Posted on 上午11:24:00 by Fan Zhang and filed under

本文在 github 中的镜像:Python 的 and-or 技巧

布尔上下文

在 Python 中,可以在布尔上下文中使用几乎所有类型的表达式。通常的数据类型的“空值”都为 False。

  • None 为假值
  • 数值 00.0 等为假值
  • 空串 "" 为假值
  • 空列表 [] 为假值
  • 空元组 () 为假值
  • ...

逻辑演算

在 Python 中,and 和 or 按照下面的规则执行布尔逻辑演算:

对于 and,从左到右运算:

  • 如果所有表达式都为真,则 and 返回最后一个表达式。
  • 否则,and 返回第一个假值。

对于 or,从左到右运算:

  • 如果有一个为真,则 or 立刻返回该值。
  • 否则,or 返回最后一个表达式。
  • or 找到第一个真值后会忽略计算剩余的表达式。

注意到:返回的并不是布尔值,而是其中某个参与比较的表达式值。

and-or 技巧

在 C 中,表达式 bool ? a : b 表示当 bool 为真时结果为 a,其它值则为 b。在 Python 中可以使用 and-or 实现类似的功能。

 
((test and [x]) or [y])[0]

在这个 Python 表达式中,如果 test 为真,则返回 x,否则返回 y。

这里使用列表将 x 和 y 括起来是为了防止 x 为空值的情况,比如想要实现:“如果 test 为真,则取 0,如果 test 为假,则取 1”,如果不将 0 括起来则为:

 
(test and 0) or 1

不论 test 是真是假,都只会返回 1。

0
Posted on 下午11:40:00 by Fan Zhang and filed under

行结束符

一个文本文件是由行组成的,本文所说的就是行与行之间用来表示新行(newline)的间隔,一般称作断行符(link break)或者行结束符(end-of-line, EOF)。

由于历史的原因,不同的操作系统用来表示换行的字符不同,这就给跨操作系统编辑文件带来不便。

操作系统中的差异

使用下面的 Unicode 标准定义的符号:

  • LF: Line Feed, U+000A, '\n'
  • CR: Carriage Return, U+000D, '\r'

不同的操作系统使用的行结束符:

  • Windows 使用 CR+LF,也就是 '\r\n'
  • Linux/Unix 系列使用 LF,也就是 '\n'

特别的,目前 Mac OS X 是基于 Unix 的,所以行结束符也是 LF。只有 v9 之前 Mac OS 才是用 '\r'。

历史

为什么对“另起一行”的处理有这样的差异,是因为早期的电传打字机(teletype)从左至右打完一行的时候,需要给打印机头重新移回左边界的时间,在一个字符的时间内,不足以让打印机头移动到正确的位置,这样会影响下一个字符的打印。所以就需要在一行结束的时候额外传递一个 CR 字符令装置 carriage 归位。

进一步阅读:Wikipedia: Newline

对不同换行符的处理

一般操作系统的运行库决定了文本文件的换行格式,在一个平台上使用另一种换行符的文件通常会有问题。大部分编辑器会自动识别换行符类型,并带有换行转换的功能。

比如某些 FTP 软件在进行文本传输的时候会对换行符进行转换(这样修改了原文件)。

Python 使用 "Universal Newline" 处理这个问题。在以文本方式 open() 的时候,会对换行符进行识别并一致处理成 '\n',在文件写入的时候,也只要 write('\n') 即可,Python 会根据操作系统自动处理。有关文档:

本文 github 中的镜像

0
Posted on 下午3:46:00 by Fan Zhang and filed under

可以访问本文镜像

为什么要引入本地存储

这个问题也是在做 Web App 的时候自然注意到,HTTP 的传输是无状态的(stateless),所以为了给用户个性化体验就必须在客户端存储一些数据。比如,网站的登录过程,事实上就是利用 Cookie 在客户端保存了用户的验证信息,在用户每一次发送 Request 的时候都会在 Header 部分加入 cookie 的信息,从而让网站服务器得知用户已经登录,并提供用户所需的信息。

Cookie 的缺点

Cookie 已经实现了在客户端储存资料,不过它有几点不足:

  • Cookie 的设计限制了大小为 4KB;
  • Cookie 每次 HTTP Request 都要传输一遍,并且通常不加密传输(可以使用 SSL 加密);
  • Cookie 通常存储了用户的浏览行为和隐私相关的信息,有可能造成安全隐患。

快速入门

如今知名的浏览器都已经支持了 HTML5 Storage,不过对国内来说 IE 的版本才是最大的问题(IE8 以上才支持)。并且包括 iPhone 和 Android 在内的手机浏览器也支持。

以下文章可以快速了解 HTML5 Storage 的特性和用法:

localStorage 和 sessionStorage

localStorage 可以认为不主动清除则一直存在。

sessionStorage 则是和会话相关,刷新页面不会清除,但是关闭浏览器则会清除。所以浏览器崩溃后,通常 sessionStorage 还可以存在。

更多参考

1
Posted on 下午3:28:00 by Fan Zhang and filed under , ,

可以访问:本文镜像

为什么要用 VimWiki

个人 Wiki 个性化的程度比较严重,所以千挑万选总也找不到好用的。Vim 虽然学习成本很高,但是我想既然已经到使用个人 Wiki 了,应该不会在乎这点投资。

Wiki 形式的文档好处在于易于写作,纯文本的管理,即使是源文件也有很强的可读性,可以方便地导出规范的 HTML 文件。

Wiki 的格式也很多,比如 Markdown,reStructuredText 等等,这都被称作 Lightweight markup language,在这个维基词条上也有些简单的对比。Travis 的主页有文章对这些做了总结(文章提到,选择太多,很难总结完善)。我个人依照我的喜好选择了 Google Code Wiki,其实我也觉得,如果不是写书,其实哪种 Wiki 形式都一样,重要的是开始写,选一个喜欢的语法和实现,并且保证用的人比较多的就行。

说了半天还没有介绍 VimWiki,它是一个 Vim 的开源插件,采用类似 Google Code Wiki 的语法,所有的文档组织就是利用 Wiki 格式的纯文本。结合 Dropbox 可以轻松实现同步。我觉得 Wiki 就不用版本控制了,简单在文中标注下必要的更新说明就是。

Quick Start

为了快速上手,下面各种操作不多做解释,官方文档能提供所有的解答,也有中文文档。另外,这个软件的更新较快,网上的一些设置介绍可能过时,需要及时查阅官方的文档。

下载安装

方法一:下载 .vba 是 Vimball 的安装文件,打开后使用 :so % 即可。

方法二:也可以直接使用 zip 文件,解压复制到相应路径。

注意:Vim 中涉及到的路径最好不要含有比较特殊的字符(比如空格,括号等),以免出现各种错误。

配置 vimrc

安装官方文档的要求,需要确保 vimrc 文件中有如下的设置:

 
    set nocompatible
    filetype plugin on
    syntax on

另外就是要设置个人 Wiki 库的存放地址和 HTML 模板:

 
let g:vimwiki_list = [{'path': 'D:\Link\Wiki\wiki\',
      \ 'path_html': 'D:\Link\Wiki\html\',
      \ 'template_path': 'D:\Link\Wiki\templates\',
      \ 'template_default': 'def_template',
      \ 'template_ext': '.html',
      \ 'css_name': '',
      \ 'auto_export': 1,
      \ 'diary_link_count': 5}]

注意到有关模板我使用的是 Dev (2010-12-27) 版本,所以和当前的 1.1.1 的设置有所不同。 因为 VimWiki 可以定义 css,所以有一个 css_name 的设置,应该是保存在文档中定义的 css(不确定)。

使用

这部分请看VimWiki 介绍中第二节。

在 Vim 中,键入 <leader>ww 三个键即可进入第一个 Wiki 库的首页(index.wiki)。其中 <leader> 一般是 \ 字符。

在首页中就可以随意输入了,使用类似 NewPage 之类的驼峰词可以创建新页面。如果需要创建中文词条可以使用: [[中文]] 或者 [[文件名|中文描述]] 的方法。

<tab> 和 <shift> + <tab> 键可以在词条之间跳转,<enter> 可以进入词条进行编辑,<backspace> 可以返回。注意到,通常情况下 VimWiki 会自动存盘。

使用 :Vimwiki2HTML 和 :VimwikiAll2HLML 可以导出 HTML 格式的网页。

Tips

  • 可配置多个 Wiki 库。访问第二个 Wiki 库可以键入 2<leader>ww,或者通过 <leader>ws 进行选择。
  • Wiki 中的 CamelCase 会自动转换为 link,按 <enter> 即可进入编辑,按 <backspace> 回到前一页。
     
    " 不需要驼峰英文成为维基词条
    let g:vimwiki_camel_case = 0
    
  • 可以设置在存档后自动更新 HTML 文件,在 vimwiki_list 中的 auto_export 属性。
  • 可以建立 to-do list,只不过默认的快捷键 <C-space> 和中文输入法切换的热键冲突,可以重新映射。比如下面映射成 <leader>tt,
     
    :map <leader>tt <Plug>VimwikiToggleListItem
    
  • 方便的日记功能,使用 <leader>w<leader>w 就可以开启一个以今天日期命名的 diay page,还可以结合 Calendar 插件,以日历形式显示日记。

发布

通过 HTML 模板,可以把 VimWiki 当做 Blog 和个人 Wiki 的发布工具使用,而且文档编辑简单,内容和样式分离,非常省心。 目前一个选择是使用 githubPages feature。本来 github 是代码托管服务,但是允许作者发布静态的网页作为主页。

对此不再赘述,可以参考:

0
Posted on 上午12:23:00 by Fan Zhang and filed under

  有的时候需要在局域网内调试 GAE 的程序,比如调试手机应用程序的时候,需要通过 WiFi 访问应用程序。

  默认的 dev_appserver 使用的地址是 localhost,如果需要其他计算机也能访问,则需要再启动的时候加入参数 --address= ... 设置服务器的主机地址,使用 0.0.0.0 则允许本地主机访问和主机名访问。参见:The Python Development Server: Command-Line Arguments

  如果使用的是 GAE Launcher,则是在 Application Settings 中在 Extra Command Line Flags 中加入:

 
-a 0.0.0.0
0
Posted on 上午11:44:00 by Fan Zhang and filed under , ,

  本文的经验建立在理科专业并使用 LaTeX 的基础上。文献管理的软件和服务很多,我没有用过此类的收费软件,免费的也没有全部仔细试用。因为这类软件或服务的个性化太强,很难找到一个能完全符合我的喜好。本文可以当做一个对最知名的免费的文献管理软件和服务的简要介绍和主观评价。

  首先是我个人的偏好:

  • 不能处理中文虽然不好,但是无所谓。
  • 如果带有自动获取题录的功能,最好能指定来源,获取准确和全面。
  • 理想中的情况是在有多个数据来源的情况下,可以供用户选择较优的。
  • 只要支持 BibTeX 就行。
  • 社会化功能无所谓。
  • 注释功能无所谓。
  • 能否自动获取全文无所谓。

  在线的文献管理服务:

  • CiteULike:Richard Cameron 编写的文献管理服务。个人感觉比较好,支持网站众多,支持 tag,导入和导出都比较方便,分享功能也很完善。可以从 CrossRef 更新数据,并且提示哪些条目更改了。只不过操作不是很方便,批量处理比较麻烦。 或许研究下 API 比较好。
  • Connotea: 后台是 Nature 出版集团,当然这个也说明不了什么,因为 Elsevier 旗下的 2collab 就停止服务了。Connotea 要求文献来源必须提供 URI、DOI、PMID、ASIN 这类索引性信息,但是比如早期的期刊文献并没有 DOI 数据。这对其所能管理的文献有很大的限制。
  • 新科学:国内的服务,用的人不多,但是功能还不错,对于国内的数据库的文献导入支持得比较好。

  注:CrossRef 的信息也不全是正确的,作者名称通常只是简称。此外使用 CrossRef 搜索题录应该是收费的,虽然可以利用 CiteULike 的数据吧...

  完全本地的文献管理软件:

  • JabRef:开源。只能管理 BibTeX 格式,需要 Java 运行环境,界面不好看。但这是我最终一直在使用的软件,它的自动生成 BibTeX key 的功能非常好用,另外自动查找相关文件(需要靠文件名)的功能也很有用。论功能,JabRef 完全可以满足我的所有需求。
  • Bibus:开源,还是 Python 开发的。但是经历了一次安装失败,就没用...

  下面介绍的是在线服务和本地客户端整合的软件,主要功能集中在客户端,网络服务上可以备份数据并提供社会化功能:

  • Zotero:是 Firefox 的一个扩展,现在也有独立运行版本(感觉是基于 Firefox 剪裁的)。对惯用 Firefox 的人来说,这是非常好的一个选择。它通过 DOI 等信息获取题录应该也是来自 CrossRef。我非常喜欢的是它能标出获取的数据来源,虽然并没有提供多个来源的选择。
  • Mendeley: 非常适合在积攒了大量的 PDF 文件时处理,因为这个软件可以识别 PDF 中包含的 citation 信息(虽然准确率一般般)。也可以通过 DOI 数据从 CrossRef (我猜测)获取信息。可惜不方便的地方在于,它从 DOI 更新数据的时候,没有提示就直接覆盖了之前的数据。往往获取的数据并不太好,这点使我的体验不是太好,期待之后的改进。此外,Mendeley 可以导入 CiteULike 的数据。
0
Posted on 下午9:16:00 by Fan Zhang and filed under

  买了新手机、新笔记本的同学往往特别在乎电池,尤其是笔记本,喜欢用各种软件去查看电池损耗。本文希望能简要介绍一些我能所知的锂电池使用和保养的方法。物理也不怎么好,以下所有论断都是查阅资料后的判断。

  首先说一下常见的误区:

  1. 满充满放三次,充电12小时,刻意满充满放,都是对锂电池有损害的方式,这些是对镍氢电池的。
  2. 充满了继续插着对锂电池没什么用,充电电路会停止充电的。
  3. 边充电边工作对锂电池影响不大,之所以不建议边充边工作的原因是高温环境对电池损害大。除非笔记本天天不关温度较高,去掉电池可能有点好处。一般情况下,边用边用没有问题。

  正确的使用方法是随时充电,想用就用,避免过放。当然,如果有可能,遵循下面的使用方式会有些好处:

  1. 浅充浅放。也就是说放电和充电的程度都不要太大,所以在条件允许的情况下随手充电就是很好的习惯。
  2. 避免高温。
  3. 避免过充和过放。因为锂电池都有保护电路,所以一般情况下,这种情况也不会发生。除非长时间不用,可能就过放了。

  长时间不用怎么办?

  1. 电量在 40%~60% 的程度保存。
  2. 尽量在低温环境下保存。

  此外涉及到充电器的问题:

  1. 现在很少有把电源管理 IC 放在充电器上,一般都在锂电池上或者设备上。所以充电器只要电压符合,就可以充电。
  2. 至于充电器的标称电流,代表充电器的输出功率,使用多少是由电源管理 IC 控制的,所以功率大小只会影响充电快慢,使用超过设备所需的大功率充电器充电,也只会依据设备的电源管理 IC 的设置进行充电,通常也不会充得快。特别指出,用 iPad 的 10W 充电器给 iPhone 充电完全没有问题。Apple 网站和下面提供的参考资料中都有回答和验证。
  3. 充电器电压一般都高于 5V,浮动 0.2V 没有关系,由电源管理 IC 控制提供给电池的电压。
  4. 尽量不用座充,这是因为市面上的万能充不怎么好。详细介绍见下面的参考资料。

  iPad 充电要求比较高,一方面是需要 10W 功率的充电器才能合理的时间充电(否则就太慢了),另一方面,Apple 的充电器的 USB 接口额外有一个识别电阻。没有这个识别电阻,可能会让 iPad 显示"不在充电"。

  参考资料如下:

0
Posted on 下午9:15:00 by Fan Zhang and filed under

  这个东西到底怎么叫呢?插线板,接线板,插排,电源转换器好多名字,英文怎么说?不管了。

  为什么要选择一个好的插线板,两点考虑:用电安全和保护电器。

  先说结论:

  • 不在乎的用什么都行。
  • 想用便宜没有过多要求的,用航嘉、公牛、可来博等等你听说过的牌子。
  • 需要防浪涌等功能,就选择:APC、贝尔金、突破(保镖系列),不建议用航嘉、秋叶原、飞利浦等带防浪涌的型号,既然都在乎了,就买个好点的。比如飞利浦的低端电源做工不错,带防雷击的型号就比较差。
  • 特有钱没地方花的,选择电源净化器、UPS等。

  国内大部分插线板(包括品牌的),假冒伪劣(比如不接地线)的就不说了,即使能用的,在做工和用料上往往也不令人满意。设计和用材不好的插线板,自然有安全隐患。

  1. 线缆铜丝截面积至少应为 3×0.75 平方毫米。如果截面积太小,插线板所接电器功率过大时,线就会发热。有的插线板线很粗,但是里面铜丝确很细。
  2. 内部走线美观,做工精致。用铜排的当然最好,如果都用焊接方式的,走线美观也不错。一体式内芯有利于减少内阻,避免虚焊,从而降低损耗。
  3. 插口使用磷青铜接触弹片。使用其他材质的,多次插拔后夹持力就下降了。
  4. 使用银触点开关。普通铜触点开关容易引起电弧,也就是开关过程中看见的火花。煤气泄漏不要按开关就是说这个。

  插线板除了基本功能以外,还有些个性化要求,比如我喜欢:

  1. 每个插孔独立开关的。
  2. 插孔间距大。
  3. 插孔有插入保护,可以防止儿童误插或者异物落入。
  4. 高阻燃、耐冲击外壳。

  插线板骗我们钱,自然是从更高级的功能上来的:

  1. 过电压保护,过载保护,漏电保护:这些从功能上有了应该不会骗人,算是比较好检测的保护,区别就在于敏感度和承载量,不过一般有这些功能的区别不会太大。
  2. 浪涌保护,防雷击保护:别想着能防直击雷,对于感应雷和普通浪涌,目前的插线板都是使用压敏电阻 MOV 和放电管来保护的。区别在于用的 MOV 好不好。其实不用太在意浪涌,家用大型电器设计的时候一般都考虑了保护功能(如果没有说明电器不好...)。
  3. 滤波功能:防浪涌可以削弱尖峰,但是对于电源中的噪声应该无能为力。如果有一个 EMI 滤波器自然更好。如果对音响的性能比较敏感,就多花些钱买电源净化器吧。当然了,真正的HIFI烧友只用雅鲁藏布江的水电,我作为外行就不讨论了。

  泡泡网有一个系列文章:帮助你了解电源,可以看看。

0
Posted on 上午11:13:00 by Fan Zhang and filed under

  总不能在标题上就写如何盗链吧...

  Referer 是 HTTP Header 的一个字段(wiki),包含在向服务器发送的请求中,记录访客的来源URI。

  很多网站用辨识 Referer 来防止盗链,比如百度、网易相册。以猫扑上的图片为例,如果我们直接访问,或者外链到其他网站,就会显示不出。因为猫扑的服务器判断 Referer 信息,发现不是来自自身网站,就对该请求予以拒绝。

  如果网站的防盗链措施只是基于 Referer 判断,可以通过伪造 Referer 来实现外链。比如 Firefox 的 RefControl 扩展。但是依据安全性(The setRequestHeader() method),不能要求用户浏览器发送伪造的 Referer。

  所以早期使用 JavaScript 利用 XMLHttpRequest 设置 Referer,早期的 Flash 通过 ActionScript 构造请求的时候,自定义 Referer 的方法现在都被禁止了。

  既然不能强制客户端设置 Referer,那只能通过服务器中转的方式,因为在服务器端就可以构造自定义请求了。

  对于网站管理者来说,防止盗链的方式就很多了,比如利用 Session,判断 IP,生成随机码等等方式...

0
Posted on 上午3:10:00 by Fan Zhang and filed under

  Python 允许通过 exec 和 eval 执行以字符串形式表示的代码片段,这体现了动态语言的特性。利用这种特性,可以让代码变得更灵活。不过一直以来,我对这种"动态"的用法不太"适应",因为:

  1. 让代码引入了某些不安定因素,这些代码片段执行后可能对全局造成影响。尤其是当使用全局名称空间时,它的作用范围难以控制。
  2. 对执行的效率也有影响。Python 在执行代码之前也是要预编译的,比如 pyc 文件。因此这些字符串形式的代码片段在执行的时候,需要编译的过程,哪怕是使用 compile 编译后重复使用,第一次的编译是难以避免的。

  很多人也倾向于避免这种用法,比如:Use of eval in Python?

  不过最近在写网站解析程序的时候,发现为了实现目的,最好的解决方案还是引入这种字符串形式的代码片段。这个问题具体描述是:我需要对一系列类似的网站进行解析。整体的解析过程是相似的,所以我建立了一个框架,使用 XML 保存每个站点各自的解析属性,通常是 XPath 和正则表达式。但是某些内容各个网站的表现方式有很大差别,这些内容想要解析出来只使用 XPath 和正则表达式是不够的。因此对这些例外情形,最好的方式是直接利用代码片段来计算。

  此外,现有的项目,比如 Genshi 之类模板引擎也采用了类似的处理手段。

  用户使用程序如果能执行自己的代码片段,这往往是有潜在危险的,尤其是在网络服务中,因此我们在使用的字符串代码片段的时候,要严格限制名称空间。对这个问题的讨论,可以参考 Using eval() safely in python,这里做一个简要的总结。

  默认的,eval 和 exec 所运行的代码都位于当前的名称空间中,它们也可以接受一个或两个可选字典参数作为代码执行的全局名称空间和局部名称空间。

  eval 的用法最严格的限制(注意对 builtins 的处理)是:

eval(user_func,{"__builtins__":None},{"x":x,"sin":sin})

  如果希望允许使用某些变量和函数,可以采用下面的方法:

eval(user_func,{"__builtins__":None},{"x":x,"sin":sin})

  有关使用 exec 和 eval 的注意事项,文章 Be careful with exec and eval in Python 进行了细致的讨论。首次编译是不可避免的,使用预编译后重复使用可以提高效率。另外使用局部空间因此可以加快变量的查询速度,所以执行会快。

  下面还有几个需要注意的地方:

  能避免使用的时候,还是应该采用其他方式,比如转换字符串的时候,使用 int() 而不是 eval(),因为如果转换的这个字符串是用户输入的,危险的情况是 eval() 会执行恶意输入的条命令。详细的解释参考:Python之eval()函数的危险

  尽量避免使用 eval 来获取变量名,想要实现动态变量名,使用 globals(),locals() 以及 vars()。

a = 123 
s1 = locals()['a'] 
s2 = vars()['a'] 
print s1, s2

  类似的情况也出现在 JSON 格式的解析上,参见 Running JSON through Python's eval()?

0
Posted on 下午9:24:00 by Fan Zhang and filed under ,

  ReadTxT 是基于 Google App Engine 编写的阅读网络小说的工具,初衷是为了使阅读网络小说更方便而设计的。它支持常见的网络文学站点,比如:起点中文网、纵横中文网、飞库电子书等。用户可以在登录后统一管理各个站点自己喜欢的书目,并保存阅读书签,实现一站式阅读。主要的特点有:

  • 支持多个主流小说网站。
  • 自动抓取最新的章节。
  • 无广告。
  • 支持手机阅读,并针对 iPhone 优化。
  • 提供下载和订阅功能。

  项目主页:http://code.google.com/p/bookreader/

  部署需要对 Google App Engine 有一点点了解,如果只是希望使用,可以直接进入:

  可以保证上述部署的应用是最新版本,除非调整数据库结构,书签信息不会清空(有的时候清空了数据...请不要怪我)。 需要补充说明的是,本人不负责使用代码或者应用本身所带来的网络小说版权问题。

0
Posted on 下午11:03:00 by Fan Zhang and filed under

  我用 iPhone4,号码是联通的186号段。出问题时候的症状是只能收不能发,无法调出设置中的"蜂窝数据网络"。彩信在手机上未显示发送异常,那些未成功送达的彩信也没出现在账单上。

  一句话解决:应该是联通自身的问题,过一天就好了。

  下面是折腾记录,谨献给我浪费的时间。

  1. 能不能发彩信和是否越狱无关。
  2. 联通网络已经设置好了 APN 信息,所以苹果觉得没必要显示出来。如果是移动用户,可能需要设置 APN,这个是由手机系统里面的 /System/Library/Carrier Bundles/ 决定的。
  3. 针对2,如果没有"蜂窝数据网络"的设置,就别折腾了,折腾出来你会发现内置的数据也是对的。
  4. 我觉得没用的所谓技巧:拔卡再插卡;电话号码去掉+86。
  5. 可能有影响,我不确认的设置:"短信"设置是否带主题,彩信是否写文字。(能发我就没管了,懒得试,一条0.9元)

  可能有用的链接,不同系统、不同运营商不一样,仅供参考:

0
Posted on 上午7:58:00 by Fan Zhang and filed under ,

  家里一个 iPad 开机花屏,出现一条条的彩道,无法操作,于是拿去维修了。

  1. 在官方网站预约 Genius Bar,恰好有人取消预约,选择了一个中午的时间。
  2. 到了苹果店确认了预约,然后等待。只带了机器,没带括发票、充电器、数据线。
  3. 准时开始,负责接待的是一个漂亮姑娘,记得名字是 Endless。
  4. 先问我是不是破解了,我说没有。问我是否摔了,我说没有。问我是否进水了,我说没有。我说就是放着就坏了。
  5. 问我是否有重要资料,我说没有,然后连电脑重置,过程正常,但是问题依旧。
  6. 判断是内部硬件问题。(虽然我早知道...我觉得是屏线问题)
  7. 给我换了一台,我打开后是4.2.1版本,外观有一点点无关紧要的瑕疵。
  8. 再次更换了一台,系统是3.2.2。
  9. 签字,说保修3个月,但是我本身质保也是3个月后过期。