其中，整个项目最复杂的地方就是 axml 转换 xml 的实现。
因为 AndroidManifest.xml 并非是一个真正的 XML，而是一个 axml 格式的文件，需要借助特殊的工具解析、转换到 XML。

在 npm 上找了半天，没找到符合我要求的库。

NPM 上 axml 那个库和 Android 的 XML 完全没有关系！

没办法，只能自己动手实现一下了！

借鉴了 https://github.com/xgouchet/AXML 的源代码，我迁移了一个 JavaScript 版本的 axml2xml。伸手党可以直接用下面的命令添加这个库：

1

npm install axml2xml --save

转换一个 axml 文件为 xml 文件的示例：

1
2
3

const Axml2Xml = require('axml2xml');
const buf = fs.readFileSync('./tests/AndroidManifest.xml');
console.log(Axml2Xml.convert(buf));

转换得到的 XML 可以用其他库去解析，非常方便。

更多的使用方法可以 查看项目的NPM 介绍，源代码参见 https://github.com/micblo/axml2xml。

崩溃堆栈类似下面：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

pid: 2938, tid: 2940, name: crasher64  >>> crasher64 <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x5f2ced24a8
Cause: execute-only (no-read) memory access error; likely due to data in .text.
    x0  0000000000000000  x1  0000005f2cecf21f  x2  0000000000000078  x3  0000000000000053
    x4  0000000000000074  x5  8000000000000000  x6  ff71646772607162  x7  00000020dcf0d16c
    x8  0000005f2ced24a8  x9  000000781251c55e  x10 0000000000000000  x11 0000000000000000
    x12 0000000000000014  x13 ffffffffffffffff  x14 0000000000000002  x15 ffffffffffffffff
    x16 0000005f2ced52f0  x17 00000078125c0ed8  x18 0000007810e8e000  x19 00000078119fbd50
    x20 00000078125d6020  x21 00000078119fbd50  x22 00000b7a00000b7a  x23 00000078119fbdd8
    x24 00000078119fbd50  x25 00000078119fbd50  x26 00000078119fc018  x27 00000078128ea020
    x28 00000078119fc020  x29 00000078119fbcb0
    sp  00000078119fba40  lr  0000005f2ced1b94  pc  0000005f2ced1ba4

backtrace:
      #00 pc 0000000000003ba4  /system/bin/crasher64 (do_action+2348)
      #01 pc 0000000000003234  /system/bin/crasher64 (thread_callback+44)
      #02 pc 00000000000e2044  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
      #03 pc 0000000000083de0  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)

通过 Bugly 上报的数据发现，这个 SEGV_ACCERR 的崩溃（无访问权限）发生在读取 libc.so 的代码段(.text)内存的时候。
观察其他信息发现，libc.so的代码段权限只剩下 --xp。
怪不得我们一访问就崩溃，是因为代码段没有可读权限了！
同样的问题也发生在其他系统库上。

当时的解决方案是，通过读取 /proc/self/maps 避开系统库无可读权限的用户。

直到我不小心看到了这个文档……

只执行内存违规（仅限 Android 10）

仅对于 Android 10 中的 arm64，二进制文件和库的可执行部分会映射到只执行（不可读取）内存，作为防范代码重用攻击的一种安全强化技术。此缓解方法与其他缓解方法产生了不良互动，后已被移除。

将代码设为不可读会导致故意或意外读入已标记为只执行的内存段抛出 SIGSEGV，并且代码为 SEGV_ACCERR。这可能是因为错误、漏洞、混合了代码的数据（例如文字池）或故意进行的内存自省导致的。

编译器会假设代码和数据不是混合在一起的，但是手写程序集会导致出现问题。在许多情况下，只需将常量移动到 .data 部分，即可解决这些问题。如果可执行代码段绝对有必要进行代码内省，应首先调用 mprotect(2) 以将该代码标记为可读，然后在操作完成后重新将该代码标记为不可读。

寻思这不是Android系统你在搞事情啊！
Android 官方提供的解决方案是访问之前先 mprotect 一下需要读的内存，给他们加上可读权限。

提供一个伪代码:

1
2
3
4
5
6

auto lib = dlopen('libc.so');
auto fn_open = dlsym(lib, 'open');
auto page_start = (fn_open >> 12) << 12;
mprotect(page_start, 0x1000, PROT_READ | PROT_EXEC);
int *code = fn_open;
printf("code: 0x%X", *code);

亲测该方案是有效的。
不过为了保守，我们用完了记得把权限设置回去只可执行，以避免一些未知的意外崩溃。

在2020的现在，当年的那些PowerPoint里面的Flash已经无法在Office 2016以及更高的版本播放了。更糟糕的是，你想直接导出文件也变得极度困难。

目前网上常见的招数是使用WinHex之类的软件直接硬导出 .ppt 内的文件。该方法虽然在一定程度上可行，但是过于硬核，实际操作难度非常大。

为了解决这个问题，我从另一个角度提取PPT中的Flash文件。

这种方法必须将PowerPoint文件转成 .pptx 格式。原因是 .pptx 格式的本质是一个 .zip 的压缩包，我们可以使用压缩工具解压里面的资源文件。

使用压缩工具打开 .pptx 文件后，可以在 ppt/activeX 文件夹找到PowerPoint中所有的 ActiveX 插件对应的原始的原始文件。其名称类似于 activeX{数字}.bin。

那如何识别这个 .bin 文件原本是什么文件呢？很简单，该文件后缀为 .xml 的资源配置文件里面就有答案。

1
2

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<ax:ocx ax:classid="{D27CDB6E-AE6D-11CF-96B8-444553540000}" ax:persistence="persistStorage" r:id="rId1" xmlns:ax="http://schemas.microsoft.com/office/2006/activeX" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"/>

上面是一个Flash文件的资源配置文件内容，其中 classid 的值是代表该文件被什么 ActiveX 插件使用。

然后，classid 为 D27CDB6E-AE6D-11CF-96B8-444553540000 时，代表该 .bin 文件内存有的是 Flash 文件（.swf）。

是的，你没有听错，这个 .bin 文件还不是 .swf 格式的！我们还需要从里面提取文件。

使用 WinHex 打开这些 .bin 文件，我们可以发现它们的文件头都是 D0CF11E0A1B11AE1。

通过Google这个文件头，可以很容易发现这些 .bin 文件都是 .cfb 格式的文件 （The Microsoft Compound File Binary (CFB) file format）。

知道了这个线索之后，我们就可以找一些现成的 .cfb 格式的库来提取里面的文件了。

为了实现的方便，特意使用 GoLang 实现了 .cfb 格式的提取。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

package main

import (
"fmt"
"github.com/richardlehane/mscfb"
"io/ioutil"
"os"
"strings"
)

func main() {
info, err := ioutil.ReadDir("./") // 搜索当前文件夹里面所有文件
if err != nil {
fmt.Printf("Failed to read path\n")
return
}

for i := 0; i < len(info); i++ {
// 只有 ActiveX{数字}.bin 的文件名才是cfb文件
if strings.HasPrefix(info[i].Name(), "activeX") == false ||
strings.HasSuffix(info[i].Name(), ".bin") == false {
continue
}

// 打开这个CFB文件
file, _ := os.Open("./" + info[i].Name())
doc, err := mscfb.New(file)
if err != nil {
_ = file.Close()
fmt.Printf("Failed to read file %s\n", info[i].Name())
continue
}

// 遍历导出里面的文件
for entry, err := doc.Next(); err == nil; entry, err = doc.Next() {
buf, err := ioutil.ReadAll(entry)
if err != nil {
fmt.Printf("Failed to read content from CFB file. filename = %s, contentName = %s\n",
info[i].Name(), entry.Name)
continue
}

// 设置导出的文件的文件名，将数据写出到该文件中
outputName := info[i].Name() + "_" + info[i].Name() + ".swf"
// 需要从第8个字节开始提取，前八个字节非文件原始数据
err = ioutil.WriteFile(outputName, buf[8:], os.ModePerm) 
if err != nil {
fmt.Printf("Failed to read content from CFB file. filename = %s, contentName = %s, output = %s\n",
info[i].Name(), entry.Name, outputName)
continue
}
}
}
}

上述代码可以非常轻易把程序运行目录下全部的 ActiveX 的 .bin 文件里面的真实文件提取出来。此处假设都是Flash文件，所以格式都是 .swf。

看了一下网上还没有人提出这个方法，所以写出来分享给大家，有兴趣可以试验一下哈哈哈。

语音合成（Text To Speech，TTS）可以实现网页文章的阅读。通过它，我们可以不需要看文字，就可以听新闻、听小说。

目前国内的主流的语音合成解决方案无非是以下几种：

1. 科大讯飞
2. Google
3. 云服务（阿里云、腾讯云……）

上述的方案，音质不错，语音包选择多。但是都有一定的免费配额或者语言的限制（如科大讯飞的试用语音包），没有完全免费的方案。

开源免费的方案的效果比较差，而且需要利用自己的服务器资源，需要考虑额外的成本。

那有没有什么免费可以使用的方案呢？还是有的！

这里就要搬出来 Web API 里面的 SpeechSynthesis。这个接口是浏览器原生支持的语音合成。

基本上现在主流的现代浏览器都支持这个接口。具体的浏览器支持情况可以查阅上面链接里的文档。

如何使用？

下面就是一个简单例子：

1
2
3
4

const ss = new window.SpeechSynthesisUtterance();
ss.text = "你好，世界！";
ss.lang = "zh-CN";
window.speechSynthesis.speak(ss);

SpeechSynthesisUtterance 是配置语音合成内容和参数的类，有以下参数可以配置：

• lang：文本所属语言，默认使用 <html> 里面的 lang
• pitch：音调（0-2.0），默认是 1
• rate：播放速率（0.1-10.0），默认是 1
• text：需要说出来的文本
• voice：语音包名称
• volume：音量大小（0-1.0），默认是 1

同时可以配置以下事件：

• onerror：出现错误
• onstart：开始播放
• onboundary：句子结束时触发
• onend：播放完成
• onmark：SSML 的 mark 标记触发
• onpause：被暂停播放
• onresume：被恢复播放

speechSynthesis 类实现语音合成的方法：

• SpeechSynthesis.getVoices()：获取全部可以播放的语音包（含语言）
• SpeechSynthesis.speak()：按 SpeechSynthesisUtterance 配置播放合成语音
• SpeechSynthesis.cancel()：移除 SpeechSynthesis 播放队列里面的全部待播放语音
• SpeechSynthesis.pause()：暂停播放某个语音
• SpeechSynthesis.resume()：恢复播放某个语音

具体的文档可以查看 MDN。

以 macOS 下的 Google Chrome 为例，通过 window.speechSynthesis.getVoices() 可以获取全部语音包，下面是一部分的输出：

1
2
3
4
5
6
7
8
9
10
11
12
13

[{
  "voiceURI": "Ting-Ting",
  "name": "Ting-Ting",
  "lang": "zh-CN",
  "localService": true,
  "default": true
}, {
  "voiceURI": "Google 普通话（中国大陆）",
  "name": "Google 普通话（中国大陆）",
  "lang": "zh-CN",
  "localService": false,
  "default": false
}]

上述数组是 SpeechSynthesisVoice 的实例数组，SpeechSynthesisVoice 的参数如下：

• voiceURI：语音合成服务的URL
• name：语音包名称
• lang：语言（符合BCP 47规范）
• localService：是本地语言包（离线）还是远程语言包（网络）
• default：是否为默认的语音包

通过观察，可以发现，Google Chrome 在 macOS 下可以使用的语音包有 macOS 自带的本地语音包和谷歌提供的在线语音包。如苹果的「Ting-Ting」和谷歌的「Google 普通话（中国大陆）」。

在构建 SpeechSynthesisUtterance 的时候，传入支持的语音包的 lang 和 voice （对应 SpeechSynthesisVoice 的 name）就可以选择语音包了。

通过这个接口，我们可以给使用 Google Chrome 的浏览器用户提供来自谷歌的语音合成功能。

探索 SpeechSynthesis 的原理

下面，我们通过 Chromium 的源代码探索 Google Chrome 的 SpeechSynthesis 是怎么实现的。

Chromium 里面的 SpeechSynthesis 类都是在 speech 模块 中实现的。其中，该模块包含 语音识别（speechRecognizer）和 语音合成 （SpeechSynthesis）两大功能的实现。

看语音合成的头文件就大概知道有哪些功能：

• speech_synthesis_impl.h: SpeechSynthesis 实现的后端，分派任务给 TTS Conreoller
• tts_controller_impl.h: 语音合成的控制器，集成了获取语音包、设置引擎、播放、暂停等功能
• tts_platform_impl.h: 管理平台相关的语音包，具体的实现在

语音包怎么来的？

我们可以先看 tts_controller_impl 里面的 GetVoices 实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

void TtsControllerImpl::GetVoices(BrowserContext* browser_context,
                                  std::vector<VoiceData>* out_voices) {
  TtsPlatform* tts_platform = GetTtsPlatform(); // 获取操作系统相关的 TTS
  if (tts_platform) { // 当前平台存在 TTS
    // Ensure we have all built-in voices loaded. This is a no-op if already
    // loaded.
    tts_platform->LoadBuiltInTtsEngine(browser_context); // 加载本地的 TTS
    if (tts_platform->PlatformImplAvailable())
      tts_platform->GetVoices(out_voices);
  }

  if (browser_context) {
    TtsControllerDelegate* delegate = GetTtsControllerDelegate();
    if (delegate && delegate->GetTtsEngineDelegate()) // 浏览器自带的 TTS
      delegate->GetTtsEngineDelegate()->GetVoices(browser_context, out_voices);
  }
}

简单来说，SpeechSynthesis 的语音包来自两大地方——操作系统自带和浏览器自带。所以我们才发现 window.speechSynthesis.getVoices() 拿到的语音包存在一部分是 Apple 提供的，一部分是 Google 提供的。

本地语音包的实现

下面分开看不同的语音包是怎么调用的，先看操作系统自带的。

观察源代码，我们发现 tts_platform_impl.h 的实现是跟操作系统有关，不同的操作系统下的实现不一样：

• tts_android.cc：安卓本地语音的实现，本质上是通过JNI调用 android.speech.tts.TextToSpeech，具体实现点我查看，该接口与安卓系统「语音引擎」设置有关，原生安卓系统是 Pico TTS，国内大多是科大讯飞引擎
• tts_fuchsia.cc：Fuchsia 本地语音的实现
• tts_linux.cc：Linux 本地语音的实现，本质上是使用 libspeechd.so.2 库
• tts_mac.mm：macOS 本地语音的实现，本质上是调用 NSSpeechSynthesizerDelegate，集成了 Apple 的语音包

上述代码通过不同的操作系统下的本地语音合成调用方法完成了本地语音包的调用，此处不着墨过多，有兴趣的小伙伴可以看源代码深入了解。

在线语音包的实现

浏览器自带的在线语音包是通过 TtsEngineDelegate 类封装的。这个东西在 Chromium 里面是由 tts_extension 实现的。因此，在线的语音包是以插件的形式存在于 Chrome 里面。

我们可以查阅 tts_engine_extension_api.cc 的 GetVoicesInternal 实现，发现在线语音包的获取方式。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// Get the voices for an extension, checking the preferences first
// (in case the extension has ever called UpdateVoices in the past),
// and the manifest second.
std::unique_ptr<std::vector<extensions::TtsVoice>> GetVoicesInternal(
    content::BrowserContext* context,
    const extensions::Extension* extension) {
  // 首先尝试从扩展的prefs里面拿到保存好的语音包数据集
  auto* extension_prefs = extensions::ExtensionPrefs::Get(context);
  const base::ListValue* voices_data = nullptr;
  // kPrefTtsVoices = "tts_voices"
  // 从 tts_voices 字段读取一个语音包列表
  if (extension_prefs->ReadPrefAsList(extension->id(), kPrefTtsVoices,
                                      &voices_data)) {
    const char* error = nullptr;
    return ValidateAndConvertToTtsVoiceVector(
        extension, *voices_data,
        /* return_after_first_error = */ false, &error);
  }

  // Fall back on the extension manifest.
  auto* manifest_voices = extensions::TtsVoices::GetTtsVoices(extension);
  if (manifest_voices)
    return std::make_unique<std::vector<extensions::TtsVoice>>(
        *manifest_voices);
  return std::make_unique<std::vector<extensions::TtsVoice>>();
}

}  // namespace

大概锁定到这个在线语音包的扩展在 pref 里面存储语音包的信息。

那么我们可以去 chrome://prefs-internals/ 找一下这个扩展。然后就会惊奇发现到这个隐藏的插件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

{
"neajdppkdcdipfabeoofebfddakdcjhd": {
"active_permissions": {
"api": ["systemPrivate", "ttsEngine"],
"explicit_host": ["https://www.google.com/*"],
"manifest_permissions": []
},
"events": ["ttsEngine.onPause", "ttsEngine.onResume", "ttsEngine.onSpeak", "ttsEngine.onStop"],
"manifest": {
"background": {
"persistent": false,
"scripts": ["tts_extension.js"]
},
"description": "Component extension providing speech via the Google network text-to-speech service.",
"manifest_version": 2,
"name": "Google Network Speech",
"permissions": ["systemPrivate", "ttsEngine", "https://www.google.com/"],
"tts_engine": {
"voices": [{
"event_types": ["start", "end", "error"],
"gender": "female",
"lang": "zh-CN",
"remote": true,
"voice_name": "Google 普通话（中国大陆）"
}, {
"event_types": ["start", "end", "error"],
"gender": "female",
"lang": "zh-HK",
"remote": true,
"voice_name": "Google 粤語（香港）"
}, {
"event_types": ["start", "end", "error"],
"gender": "female",
"lang": "zh-TW",
"remote": true,
"voice_name": "Google 國語（臺灣）"
}]
},
"version": "1.0"
}
}
}

你会发现这里的 voices 和 window.speechSynthesis.getVoices() 里面的谷歌的语音包一模一样，所以就是这个插件负责了 Google Chrome 的在线语音包。

Google Network Speech 这个扩展的源代码可以在 Chromium 的项目里面找到，源代码在此自取。

本质上，这个在线语音包调用的是 Google Cloud 的语音合成模块。

接口是 https://www.google.com/speech-api/v2/synthesize

谷歌中国 www.google.cn 也是有这个接口可以使用的（明显是为了解决国内用户无法调用语音合成模块的问题）。

Query 参数分别是：

• key: Google API Key，请到 Google Developers Console 的凭据页面申请，并开通文字到语音的接口权限
• text: 需要合成语音的文本，对应 SpeechSynthesisUtterance.text
• lang: 语言，对应 SpeechSynthesisUtterance.lang
• name: 语音包名称，对应 SpeechSynthesisUtterance.name（可选）
• speed: 播放速率，对应 SpeechSynthesisUtterance.rate（可选）
• pitch: 音调，对应 SpeechSynthesisUtterance.pitch（可选）
• enc: 默认是 mpeg
• client: 默认是 chromium

每个用户每个月可以享受400万字符的免费配额（一个中文字也算一个字符），配额超过后每100万字符收4美元。

关于这个服务的更多介绍，可以查看 Google Cloud 上的介绍信息。

总结

1. 对于谷歌浏览器的用户，我们可以使用 window.speechSynthesis 享受原生的免费语音合成
2. 对于其他浏览器的场景，我们可以使用 Google Cloud 的语音合成模块实现语音合成，有一定的免费配额
3. 针对苹果用户，苹果系统自带了各种离线语音包，可以免费使用
4. 针对安卓用户，安卓系统设置的语音包决定了 window.speechSynthesis 的能力，如华为内置的科大讯飞离线语音包

我的老战神K670D-i7风光依旧，里面装有了Nvidia的 GTX870M 显卡，算力为 3.0。

这个算力跑 TensorFlow 是不行的了，但是还是可以干点别的事情。

想装个 CUDA 调通某个开源的项目，结果就是不断触雷。

下面就是我的老设备排雷之旅。

条件

最开始的软件条件为：

• Windows 10
• VS 2017 Community 15.9.7 (平台工具集: Visual Studio 2017 (v141))
• CUDA 9.0

第一坑：折腾旧显卡驱动

按照套路，先到 NVIDIA 控制中心 里面的“系统信息”查看 CUDA 驱动的版本。

最开始找到是 CUDA 9.0，所以理所当然的就安装了 CUDA Toolkit 9.0。

结果就遇到第一个大坑 —— CUDA 9.0 不支持 VS2017！

一开始，按照套路在 VS2017 创建 CUDA 9.0 的工程。，
它会自动按照模板生成一个类似 Hello 的基础工程。

编译的时候就会出现一个错误 ——

1
2

fatal error C1189: #error: --
unsupported Microsoft Visual Studio version! Only the versions 2012, 2013, 2015 and 2017 are supported!

大概的意思就是，VS版本不支持。

经过Google，很容易找到魔改的办法。

简单来说就是把 CUDA 原本拿来检查 VS版本的代码改到可以通过。

把原本这样的代码：

1

#if _MSC_VER < 1600 || _MSC_VER > 1911

改成这样代码：

1

#if _MSC_VER < 1600 || _MSC_VER > 1920

就不会因为 VS版本太高被判定不可以编译了。

改好了之后重新编译，还是会出错！！！

错误变成了 expression must have a constant value，
报错的位置在 VC Toolkit 里面。

网上说了两种办法：

1. 安装 VC 2015 的 Toolkit，改平台工具集
2. 复制 Toolkit 的 .prop 文件到自己项目目录，然后改配置

我只能说，以上方法都是错误的！都不可以！！

唯一适配最新版 VS2017 的办法就是，升级你的N卡驱动和CUDA！

第二坑：升级N卡驱动

我以前的N卡驱动，也经是2017年的了，年代久远。

记得曾经在 NVIDIA EXPERIENCE 里面升级过，失败了。

结果这次还是失败，不讲道理那种。

白费我等待下载和安装的时间。

遇到这种升级卡BUG的情况，需要做到以下几点：

1.确保C盘腾出足够多的空间，即便你的临时文件夹不在C盘它也是会回C盘的
2.直接去官网下载，而不要用NVIDIA EXPERIENCE

我就靠这两点，成功把显卡驱动升级到目前最新的 425.31。

425.31 对应的是 CUDA 10.1，
因此我们要去 CUDA Toolkit 10.1 的下载界面下载这个版本。

CUDA Toolkit 是向下兼容 CUDA 驱动的，但是因为我们的驱动是 CUDA 10.1 的，
所以被迫也要用最新版的 CUDA Toolkit。

安装好这些东西就意味着你已经快要成功了。

第三坑：VS2017配置

装完了全部必要的软件，就要去 VS2017 亲自试一下项目编译啦。

注意！此处有个坑！

你在 CUDA 9.0 创建的项目不一定是可以编译的，
此时需要重新创一个 CUDA 10.1 的项目。

直接去编译是不一定可以的！

你可以见到下面的错误：

1

addKernel launch failed: no kernel image is available for execution on the device

这是因为项目配置中的算力配置和显卡不匹配导致的。

请到“项目”菜单的“设置”里面的 CUDA C/C++ 里面的 Code Generation 设置与你的显卡相匹配的算力信息。

好比说，GTX 870M 就是 compute_30,sm_30。

在这个地方，可以找到你的算力配置对照表，但是需要注意实际写上去的时候一定要 computer 在前，sm 在后。

弄完了这些东西，编译就真的可以通过，运行也Ok啦~

当你看到下面的输出，就说明测试的DEMO跑通了。

1

{1,2,3,4,5} + {10,20,30,40,50} = {11,22,33,44,55}

最近迫于无奈，帮忙研究了一下 ESTARFM 和 STARFM 算法，
需要用到一个处理遥感图像的软件 —— ENVI。

为了怕自己再遇到类似情况不会解决，因此写这篇小文章记录一下。

ENVI（The Environment for Visualizing Images）是一个完整的遥感图像处理平台，应用汇集中的软件处理技术覆盖了图像数据的输入/输出、图像定标、图像增强、纠正、正射校正、镶嵌、数据融合以及各种变换、信息提取、图像分类、基于知识的决策树分类、与GIS的整合、DEM及地形信息提取、雷达数据处理、三维立体显示分析。

错误清单

envi_open_file 等函数不存在 或者 提示 Fid = fid 之类的语法不对

这是因为 ENVI 程序没启动，
或者被关掉了。

启动的时候一定要启动那个 ENVI + IDL，
它会自动打开 ENVI 和 IDL。

WIDGET_BASE: Invalid widget identifier: 19

也是因为 ENVI 程序没启动，同前一个错误。

Error: "OPENW:Error opening file. Unit: 100, File: XXXXX" THe result may be invalid

这个错误说明打开文件不存在，或者保存的文件路径不合法（ENVI不会自己创建文件夹，或者盘符不存在等）

坑人按钮

千万要注意！这个“停止调试”千万别按！！

按了的话，ENVI就会被关掉，
就会遇到前面错误清单所看到的，
第一种和第二种错误。

为了方便批量转换源代码，写了下面的 Node.js 脚本，可以批量对 Discuz、UCenter 等PHP程序转换 UTF-8。

使用前请 npm install iconv-lite 来安装依赖。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

const iconv = require('iconv-lite');
const fs = require('fs');
const Path = require('path');

const INPUT_ROOT = './wwwroot'; // 等待转换的文件夹
const OUTPUT_ROOT = './dist/'; // 输出到哪个文件夹

if (!fs.existsSync(OUTPUT_ROOT)) {
    fs.mkdirSync(OUTPUT_ROOT);
}

// 以下的格式将会转换编码
const FORMATS = ['.htm', '.php', '.js', '.txt', '.html', '.css', '.xml', '.json'];

tree(INPUT_ROOT);

function tree(dir) {
    fs.mkdirSync(OUTPUT_ROOT + dir);
    fs.readdirSync(dir).forEach(v => {
        const path = dir + '/' + v;
        const stat = fs.statSync(path);
        if (stat.isDirectory()) {
            tree(path);
        } else {
            const format = Path.extname(v);
            if (FORMATS.indexOf(format) === -1) {
                fs.copyFileSync(path, OUTPUT_ROOT + path);
                return;
            }

            fs.createReadStream(path)
                .pipe(iconv.decodeStream('gbk'))
                .pipe(iconv.encodeStream('utf8'))
                .pipe(fs.createWriteStream(OUTPUT_ROOT + path));

            console.log(path);
        }
    });
}

不少做机器学习的小伙伴需要把它编译并用在 Matlab 的环境，尤其是在 Windows 系统下，特别多麻烦。

下面我归纳出来的安装方法，适用于 Windows + GCC。

安装 TDM-GCC

LIBSVM 毕竟是一个 C语言 写的库，因此需要使用编译器编译出接口让 Matlab 调用。

Matlab 的 mex 支持多种编译器。在 Windows 上支持 Visual Studio，但是我已经安装了最新的 Visual Studio，不想再去折腾旧版的VS。因此我选择使用 GCC 的方案。

在 Windows 下可以使用的 GCC 编译链 有 MinGW64、CygWin、TDM-GCC。
很可惜的是，老是折腾不上 MinGW64，最终就选择了 Matlab 推荐的 TDM-GCC。

如果你是正版的 Matlab （好比说我），直接可以去 Mathworks 官网下载，一键安装：
https://www.mathworks.com/matlabcentral/fileexchange/52848-matlab-support-for-mingw-w64-c-c-compiler

如果你是盗版的 Matlab，就需要手动来安装啦。 直接去 TDM-GCC 的官网下载: http://tdm-gcc.tdragon.net/download。
最新版也是可以用于 Matlab 的。下载好了，直接按流程安装就OK了。

此处有个需要注意的地方，如果你需要使用 OpenMP 做并行计算，请记得在安装功能的时候勾上！！！

安装完了还没结束，请到系统的环境变量那里，变量名设置 MW_MINGW64_LOC，变量值为你的 TDM-GCC 的安装目录，好比说：C:/TDM-GCC-64。设置完了重开一次 Matlab 就可以使用 mex 编译啦。

测试 mex

在 Matlab 的命令行窗口（Command Window）处输入：mex -setup

看到输出 MEX configured to use 'MinGW64 Compiler (C) 差不多的话，就说明安装成功啦。

编译 LIBSVM

到 LIBSVM 的 Github 页面，在 Release 处下载最新版的源代码压缩包。

下载完成后，建议把压缩包解压到 Matlab 的安装目录下的 toolbox 目录。
然后使用 主页 - 设置路径 里面的 添加文件夹，把刚刚我们解压到 toolbox 的 LIBSVM 文件夹下的 matlab 文件夹加入。
最后加入的搜索路径大概长这个样子：

1

C:\Matlab\toolbox\libsvm\matlab

完成这个事情之后，就可以切换 Matlab 的工作目录到上面的目录了。只需要一个命令就可以完成编译：

1

make

make 其实运行的是 make.m 那个编译脚本

如果你是 Windows 系统，这样是肯定编译不了的，会出现下面的错误。

1
2
3
4
5

使用 'MinGW64 Compiler (C)' 编译。
Error: C:\matlab\toolbox\libsvm\matlab\make.m failed (line 13)
gcc: error: \-fexceptions: No such file or directory

=> Please check README for detailed instructions.

怎么解决呢？网上写的解决方法都是不好的，那个改 COMPFLAGS 的 Issue 并不是最好的，因为丢了 CFLAGS。

下面是我总结出来的独家的解决方法：

其实问题在于 Windows 下的 $ 是没有语义的，因此不需要 \$ 做转义。因此！只需要把 make.m 下面的 \$CFLAGS 全部替换为 $CFLAGS，也就是删掉 \ 就可以在保留 CFLAGS 的基础上编译通过了。

下面是可以直接编译成功的 make.m：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

% This make.m is for MATLAB and OCTAVE under Windows, Mac, and Unix
function make()
try
    % This part is for OCTAVE
    if (exist ('OCTAVE_VERSION', 'builtin'))
        mex libsvmread.c
        mex libsvmwrite.c
        mex -I.. svmtrain.c ../svm.cpp svm_model_matlab.c
        mex -I.. svmpredict.c ../svm.cpp svm_model_matlab.c
    % This part is for MATLAB
    % Add -largeArrayDims on 64-bit machines of MATLAB
    else
        mex CFLAGS="$CFLAGS -std=c99" -largeArrayDims libsvmread.c
        mex CFLAGS="$CFLAGS -std=c99" -largeArrayDims libsvmwrite.c
        mex CFLAGS="$CFLAGS -std=c99" -I.. -largeArrayDims svmtrain.c ../svm.cpp svm_model_matlab.c
        mex CFLAGS="$CFLAGS -std=c99" -I.. -largeArrayDims svmpredict.c ../svm.cpp svm_model_matlab.c
    end
catch err
    fprintf('Error: %s failed (line %d)\n', err.stack(1).file, err.stack(1).line);
    disp(err.message);
    fprintf('=> Please check README for detailed instructions.\n');
end

改完之后再运行一次 make 就可以啦。

测试 LIBSVM

将 LIBSVM 文件夹下的测试数据集 heart_scale libsvm\matlab 下。

切换工作目录到 libsvm\matlab 目录，在命令窗口（Command Window）运行以下命令。

1
2
3

[heart_scale_label,heart_scale_inst] = libsvmread('heart_scale');
model = svmtrain(heart_scale_label, heart_scale_inst) ;
[predict_label,accuracy,dec_values] = svmpredict(heart_scale_label, heart_scale_inst, model);

看到输出 Accuracy = 86.6667% 类似的文字就说明你的 LIBSVM 成功编译并可以使用啦！

生成 CA 私钥

1

openssl genrsa -out ca.key 4096

此处用到的是 4096位的RSA私钥，可以选择 2048位，不建议使用 1024位

生成 CA 证书请求

1

openssl req -new -days 365 -key cb.key -out cb.csr

CA 自签名

1

openssl ca -selfsign -in ca.csr -out ca.crt -keyfile ca.key -cert ca.crt

生成服务器私钥

1

openssl genrsa -out server.key 2048

生成服务器证书请求

1

openssl req -new -days 365 -key server.key -out server.csr

使用 CA 签名服务器证书

1

openssl ca -in server.csr -out server.crt -keyfile ca.key -cert ca.crt

可能遇到的问题

1. I am unable to access the ./demoCA/newcerts directory

解决方法：

1
2
3
4

mkdir -p ./demoCA/{private,newcerts} && \
touch ./demoCA/index.txt && \
touch ./demoCA/serial && \
echo 00 > ./demoCA/serial

2. The organizationName field needed to be the same in the CA certificate

解决方法：

到 /usr/lib/ssl/openssl.cnf，搜索 policy_match ，将内容改为：

1
2
3
4
5
6
7

[ policy_match ]
countryName             = supplied
stateOrProvinceName     = supplied
organizationName        = supplied
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

countryName、stateOrProvinceName、organizationName 都设置为 supplied

在我的 MacBook 里面，可以很顺利跑测试。但是，改到 Ubuntu 16.04 的服务器上就炸了。

老是提示 XXXX.so not found。

这就奇怪了！明明用 go 编译和链接库都成功了，但是实际上运行还是不行。

试过了加 CGO_ENABLED="1" 环境变量也不可以，程序放在 .so 的相同目录下运行也不行，ldd 也是提示 not found。

最后发现问题之所在，一定要运行一次

1

ldconfig

更新一下动态链接库名字列表，程序在运行的时候才可以顺利找到SO库。

注意！编译链接和运行时候的链接是两码事儿，运行的时候还是得看 /etc/ld.so.cache 的！

哎，真是坑惨了。

装上去之后，按照标准例子，怎么搞都编译不了，提示下面的错误：

1

Invoke-customs are only supported starting with Android O (--min-api 26)

字面意思就是只有 Android O 以及以上的API才支持。

那不可能啊！OKhttp3 明明说了，>= Android 5 都支持，怎么可能要我设置更高的API版本。

最后查了一下，是JDK的版本问题，得设置 1.8 才可以正常使用。

用 Gradle 的小伙伴只需要在自己用到了 OKhttp3 的项目中的 build.gradle 加上下面的 compileOptions 配置就好了。

1
2
3
4
5
6

android {
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}

但是！吊诡的是，直接卡在这个界面了。
多次点击“Accept”，都没有反应。
只剩下“Disagree”，可以选，按了就会自动退出Xcode。

而且，在这里也有老哥遇到一样的问题，重装也是完全无解。

解决方法很粗暴，在终端直接接受协议就可以了。

1

sudo xcodebuild -license accept

真的是太坑了！

以太坊的钱包是基于椭圆曲线数字签名算法ECDSA保护的。

因此每一个钱包对应的是一个ECDSA的密钥对。

这个密钥对在 go-ethereum 项目的 crypto/crypto.go 的 GenerateKey() 函数生成，
生成后得到一个ECDSA的私钥 (ecdsa.PrivateKey)。

以太坊所采用的椭圆曲线是 secp256k1。由于其特殊构造的特殊性，其优化后的实现比其他曲线性能上可以提高30%，有明显以下两个优点：

1. 占用很少的带宽和存储资源，密钥的长度很短；
2. 让所有的用户都可以使用同样的操作完成域运算。

生成钱包私钥代码：

1
2
3

func GenerateKey() (*ecdsa.PrivateKey, error) {
  return ecdsa.GenerateKey(S256(), rand.Reader)
}

得到私钥后，可以使用 ecdsa.PrivateKey 的 Public() 方法取得公钥 ecdsa.PublicKey。

生成一般的钱包地址

以太坊钱包地址长度为20字节，来源于前面我们生成的钱包公钥 ecdsa.PublicKey。

简单来说就是计算一下钱包公钥的 Keccak256 哈希值，再取出末尾20字节作为钱包地址（本身 Keccak256 输出32字节）。

生成钱包地址源代码：

1
2
3
4
5
6
7
8
9
10
11

func FromECDSAPub(pub *ecdsa.PublicKey) []byte {
  if pub == nil || pub.X == nil || pub.Y == nil {
    return nil
  }
  return elliptic.Marshal(S256(), pub.X, pub.Y)
}

func PubkeyToAddress(p ecdsa.PublicKey) common.Address {
  pubBytes := FromECDSAPub(&p)
  return common.BytesToAddress(Keccak256(pubBytes[1:])[12:])
}

生成智能合约的地址

智能合约的地址其实与拥有者用户钱包有关。但由于我们不可能直接拿钱包的公钥作为智能合约地址（这样就会与钱包地址冲突），所以就需要在原钱包地址的基础上增加一个唯一的独立数 Nonce。
这样就可以确保某个钱包的拥有者可以生成出不同的智能合约地址啦。

注意，智能合约的 Nonce 与生成该智能合约的交易 Tx 的交易 nonce 有关。因为每一笔交易的nonce都是独立的，所以可以智能合约的nonce也是可以视为独立的。

生成智能合约的地址源码：

1
2
3
4

func CreateAddress(b common.Address, nonce uint64) common.Address {
  data, _ := rlp.EncodeToBytes([]interface{}{b, nonce})
  return common.BytesToAddress(Keccak256(data)[12:])
}

生成智能合约地址使用参考：

1
2
3
4
5
6

// The contract address can be derived from the transaction itself
if transactions[j].To() == nil {
  // Deriving the signer is expensive, only do if it's actually needed
  from, _ := types.Sender(signer, transactions[j]) // 获取一下发送者的公钥
  receipts[j].ContractAddress = crypto.CreateAddress(from, transactions[j].Nonce()) // 直接将Tx的Nonce作为智能合约的Nonce
}

以上是以太坊专题第一部分钱包地址的内容。

之前就已经知道，如果想在Native层上混用C语言和C++所写的代码，就必须要在C++的函数声明上增加 extern "C" 的标识，或者使用 extern "C" {} 包含多个C++的函数声明。

如果不这么做，会导致编译时出现链接器无法链接函数的问题，所提示的错误类似于
error: undefined reference to 'init(int)'。

除此之外，还有几个坑点需要注意！

使用 extern "C" {} 时，务必要把你需要链接到的C语言的库的头文件也包含在里面，如：

1
2
3
4
5
6

extern "C" {
    // C语言所写的库
    #include <openssl/xxx.h>

    void init(int id); // C++函数声明
}

并且，需要把类似于 map 这样的使用了模板的C++库放在 extern "C" 的外部。下面是错误示范：

1
2
3
4
5
6
7
8
9
10

extern "C" {
    // C++使用了模板的库
    #include <map>

    // C语言所写的库
    #include <openssl/xxx.h>

    void init(int id); // C++函数声明
}

这样会引发类似下面的错误： error: templates must have C++ linkage

下面是正确示范：

1
2
3
4
5
6
7
8
9
10
11

// C++使用了模板的库
#include <map>

extern "C" {

    // C语言所写的库
    #include <openssl/xxx.h>

    void init(int id); // C++函数声明
}

希望大家注意这些问题。

.so 文件是什么

.so 文件是 Shared Object 文件的后缀，
直白的说就是Linux系统中的“动态链接库” ，
就和Windows系统下的 .dll 文件（Dynamic Link Library）类似。

.so 文件实则是 ELF 格式的文件，和Linux的可执行文件的格式一致。

ELF 文件结构

ELF 格式的文件中的“数据”实际上是以“段”（节，英文：Section）的形式存储的。
其顺序大致符合下面的排序：

• ELF Header：ELF头部
• .dynsym：保存动态链接相关符号，记录其偏移值
• .dynstr：.dynsym 的辅助段
• .hash：快速查找符号的哈希表，类似 .dynstr
• .rel.got：数据引用修正，修正到 .got
• .rel.plt：函数引用修正，修正到 .got.plt
• .text：代码段
• 其他自定义的代码段
• .rodata：字符串常量段
• .fini_array：终止函数段
• .init_array：初始化函数段
• .dynamic：动态链接库特有，存储动态链接用到的表信息
• .got：函数的绝对地址
• .data：存放已经初始化的全局变量，静态内存分配相关
• .bss：存放未初始化的全局变量，静态内存分配相关

ELF 头部：ELF Header

其中，一切的起点都在ELF头部，其偏移量（offset）为 0。
ELF头部的结构体为 elf32_hdr 或 elf64_hdr，
在Android系统源代码的 /bionic/libc/kernel/uapi/linux/elf.h 可以找到。

以32位程序的ELF头部为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

06#define EI_NIDENT 16
typedef struct elf32_hdr {
  unsigned char e_ident[EI_NIDENT];
  Elf32_Half e_type;
  Elf32_Half e_machine;
  Elf32_Word e_version;
  Elf32_Addr e_entry;
  Elf32_Off e_phoff;
  Elf32_Off e_shoff;
  Elf32_Word e_flags;
  Elf32_Half e_ehsize;
  Elf32_Half e_phentsize;
  Elf32_Half e_phnum;
  Elf32_Half e_shentsize;
  Elf32_Half e_shnum;
  Elf32_Half e_shstrndx;
} Elf32_Ehdr;

e_ident

ELF格式文件的识别区域，固定为 16Bytes 的字符串。
下面是这串字符串各个字节的含义。

EI_MAG

• Offset: 0 - 3 (EI_MAG0)
• Length: 4 (SELFMAG)
• Type: String

ELF Identification 的前四个字节为魔数（Magic Number），
内容为 {0x7F, 'E', 'L', 'F'}。

如果魔数不一致，在Android系统会报错“has bad ELF magic”，
终止 load_library并APP闪退。

相关代码可以查询源码 /xref/bionic/linker/linker_phdr.cpp

EI_CLASS

• Offset: 4 (EI_CLASS)
• Length: 1
• Type: Number

判断 ELF 文件是 32位的 还是 64位的。

常量定义：

• ELFCLASSNONE = 0：无定义【非法】
• ELFCLASS32 = 1：32位
• ELFCLASS64 = 2：64位
• ELFCLASSNUM = 3：未知【非法】

在Android <5 的系统上，由于当年的系统不支持64位的指令集，
因此只要不是32位，就输出错误 “not 32-bit”，并APP闪退。

在Android >=5 系统上，已经出现了64位的指令集
，如 arm64_v8a、x86_64。
若32位的指令集遇到64位的SO库，
会输出错误 “is 64-bit instead of 32-bit”，
并APP闪退；
若32位的指令集遇到64位的SO库，
会输出错误 “is 32-bit instead of 64-bit”，
并APP闪退；
若出现非法的 ELFCLASS，
会输出错误 “has unknown ELF class: ?”，
并APP闪退。

EI_DATA

• Offset: 5 (EI_DATA)
• Length: 1
• Type: Number (unsigned char)

这个是判断 ELF文件是 LSB(Little-endian，低字节序)
还是 MSB(Big-endian，高字节序)。

常量定义：

• ELFDATANONE = 0：无定义【非法】
• ELFDATA2LSB = 1：LSB
• ELFDATA2MSB = 2：MSB【非法】

安卓系统只允许 LSB，因此只要不是 1，
就输出错误 “not little-endian”，
并APP闪退。

EI_VERSION

• Offset: 6
• Length: 1
• Type: Number (unsigned char)

顾名思义，是 ELF 文件格式的版本号，默认是 EV_CURRENT（= 1）。

Android系统不从这里检测 Version，而在 e_version 上检测，因此修改无影响。

EI_OSABI

• Offset: 7
• Length: 1
• Type: Number (unsigned char)

指出来该 ELF 文件可以在什么操作系统运行，参考：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#define ELFOSABI_NONE       0   /* UNIX System V ABI */
#define ELFOSABI_SYSV       0   /* Alias.  */
#define ELFOSABI_HPUX       1   /* HP-UX */
#define ELFOSABI_NETBSD     2   /* NetBSD.  */
#define ELFOSABI_LINUX      3   /* Linux.  */
#define ELFOSABI_SOLARIS    6   /* Sun Solaris.  */
#define ELFOSABI_AIX        7   /* IBM AIX.  */
#define ELFOSABI_IRIX       8   /* SGI Irix.  */
#define ELFOSABI_FREEBSD    9   /* FreeBSD.  */
#define ELFOSABI_TRU64      10  /* Compaq TRU64 UNIX.  */
#define ELFOSABI_MODESTO    11  /* Novell Modesto.  */
#define ELFOSABI_OPENBSD    12  /* OpenBSD.  */
#define ELFOSABI_ARM_AEABI  64  /* ARM EABI */
#define ELFOSABI_ARM        97  /* ARM */
#define ELFOSABI_STANDALONE 255 /* Standalone (embedded) application */

Android系统下的 SO文件 此处的值默认为 0，
而且加载时不检测，修改无影响。

EI_ABIVERSION

• Offset: 8
• Length: 1
• Type: Number (unsigned char)

指出该 ELF 文件可以在哪个API版本下运行，Android下的默认值是 0。

此处加载时不检测，修改无影响。

EL_PAD

• Offset: 9
• Length: 7

填充位，无检测，修改无影响。

技巧

Android >= 6 的系统版本只针对 0x00 - 0x05 之间的字节进行检测，
0x06 - 0x0F 之间的字节（10 Bytes）无检测，
因此可以任意修改，存放想要存放的数据。

e_type

• Offset: 0x10
• Length: 2
• Type: unsigned short

ELF文件类型，如：

1
2
3
4

#define ET_NONE 0 /* 无定义【非法】 */
#define ET_REL 1 /* 已编译未链接 */
#define ET_EXEC 2 /* 已编译已链接的可执行程序 */
#define ET_DYN 3 /* 已编译已链接的动态链接库 */

ET_REL 指的是 Relocatable file，
缺少 Program Header，
不可以加载到内存中，
gcc 编译时候生成的 .o 文件就是 REL文件。

ET_EXEC 指的是可执行程序，
存在程序入口，
有 Program Header，
可以加载到内存中运行，
在 Linux 下的可执行程序都是这样的。

ET_DYN 特指动态链接库。

由于Android的SO库本质就是动态链接库，
因此SO库编译后 e_type = ET_DYN。

Android系统会检测 e_type。
若不为 ET_DYN，则抛出错误 has unexpected e_type，
并APP闪退。

e_machine

• Offset: 0x12
• Length: 2
• Type: unsigned short

ELF 文件的CPU平台属性（指令集）。

参考：

1
2
3
4
5
6
7
8
9
10
11

#if defined(__arm__)
  return EM_ARM;
#elif defined(__aarch64__)
  return EM_AARCH64;
#elif defined(__i386__)
  return EM_386;
#elif defined(__mips__)
  return EM_MIPS;
#elif defined(__x86_64__)
  return EM_X86_64;
#endif

Android系统会使用 GetTargetElfMachine 函数
检测SO库的 e_machine 和现在的系统是否一致。
若不一致，则抛出错误 has unexpected e_machine，
并APP闪退。

e_version

• Offset: 0x14
• Length: 4
• Type: unsigned int

顾名思义，是 ELF 文件格式的版本号，默认是 EV_CURRENT（= 1）。

Android系统会检测 e_version。
若不为 EV_CURRENT，则抛出错误 has unexpected e_version，
并APP闪退。

e_entry

• Offset: 0x18
• Length: 4 (32bits)
• Type: unsigned int

ELF程序的入口虚拟地址。仅用于可执行程序加载完成后，从此处开始执行进程指令。

动态链接库不存在入口地址，所以Android系统不检测。

e_phoff

• Offset: 0x1C
• Length: 4 (32bits)
• Type: unsigned int

程序头表的偏移，涉及“连接视图”和“执行视图”。

与实际SO库中代码的指令执行相关，不允许修改。

e_shoff

• Offset: 0x20
• Length: 4 (32bits)
• Type: unsigned int

段表在文件中的偏移，涉及读取段表。

Android <7 时，读取段表依靠视图，使用的是 e_phoff，而非 e_shoff，
因此可以随意修改。

涉及 linker_phdr.cpp 的 phdr_table_get_dynamic_section 函数

Android >=7 时，读取段表依靠 e_shoff，
修改为其他值会导致无法定位 .dynamic 段，
抛出错误 “.dynamic section header was not found”。

涉及 linker_phdr.cpp 的 ElfReader::ReadDynamicSection 函数

为什么要强调这个？因为看雪里面的这个文章是不兼容新的OS的，内容过时了。

e_flags

• Offset: 0x24
• Length: 4 (32bits)
• Type: unsigned int

ELF标志位，用来标志一些ELF文件平台相关的属性。

Android 系统不使用也不检测此参数。

e_ehsize

• Offset: 0x28
• Length: 2
• Type: unsigned short

ELF头部的长度。

Android 系统不使用也不检测此参数。

e_phentsize

• Offset: 0x2A
• Length: 2
• Type: unsigned short

程序头的大小。

Android 系统不使用也不检测此参数。

e_phnum

• Offset: 0x2C
• Length: 2
• Type: unsigned short

在执行视图中，Segments的数量。

Android 系统对其进行检测，并且严格到实际的数目。
若不一致，则抛出错误 “has invalid e_phnum”、“has invalid phdr offset/size”
或者 “phdr mmap failed”等。

涉及函数 ElfReader::ReadProgramHeaders 和 ElfReader::ReadProgramHeader。

e_shentsize

• Offset: 0x2E
• Length: 2
• Type: unsigned short

段表描述符的大小，= sizeof(ElfW(Shdr))。

Android <= 6 系统不使用也不检测此参数。

Android >= 7 系统检测此参数。
若与 sizeof(ElfW(Shdr)) 不相等，
则抛出错误 “has unsupported e_shentsize”。

e_shnum

• Offset: 0x30
• Length: 2
• Type: unsigned short

段表描述符的数量。这个值等于ELF文件中拥有的段（section）的数量。

Android <= 6 系统不使用也不检测此参数。

Android >= 7 系统检测并使用此参数。
若为0，则抛出错误 “has no section headers”。
若超出文件大小范围，则抛出错误 “has invalid shdr offset/size”。

参考函数 ElfReader::ReadSectionHeaders。

e_shstrndx

• Offset: 0x32
• Length: 2
• Type: unsigned short

段表字符串表所在的段在段表中的下标，一般是 = e_shnum - 1。

Android <= 6 系统不使用也不检测此参数。

Android >= 7 系统检测此参数。
若为0，则抛出错误 “has invalid e_shstrndx”。

参考函数 ElfReader::VerifyElfHeader。

偷就完事了

在ELF头部，有这些地方可以疯狂偷空间：

1. 0x06 - 0x0F 合计 10Bytes
2. 0x18 - 0x1B 合计 4Bytes
3. 0x24 - 0x2B 合计 8Bytes

无限制存储空间合计为 22Bytes。

以下地方，只有Android <=6 才可以偷空间存东西：

1. 0x20 - 0x23 合计 4Bytes
2. 0x2E - 0x33 合计 6Bytes

存在版本限制存储空间合计为 10Bytes。

为什么要偷空间出来存数据？
主要还是为了方便SO库的打包工具做一些附加数据的存储，
偷出来的地方是随SO库加载而加载，可以在内存直接读取的。

值得学习

Android 系统源码提供了很多很好玩的设计思路，下面展示一些：

Code A

根据不同的指令集，使用不同的结构体：

1
2
3
4
5
6
7
8

// 如果是 64bits 的系统
#if defined(__LP64__)
#define ElfW(type) Elf64_ ## type
#else
#define ElfW(type) Elf32_ ## type
#endif

// ElfW(Ehdr) === Elf32_Ehdr

Code B

一些关于指令集的宏定义：

1
2
3
4
5
6
7
8
9

// __arm__ -> armeabi, armeabi-v7a [32bits]
// __aarch64__ -> arm64-v8a [64bits]
// __i386__ -> x86 [32bits]
// __mips__ -> mips, mips64 [32 / 64bits]
// __x86_64__ -> x86_64 [64bits]

#if defined(__arm__)
  printf("This is ARM Architecture!");
#endif

趁着有一点点空的时间把之前的一些idea都记录下来。

这个idea来源于PPT的浏览和打印。

有些PPT非常的“直男设计”，配色异常奇葩。

好比说黄色字白色底，黑色底棕色字，灰常不利于阅读。

那怎么办呢？第一时间想到的就是在Powerpoint上批量换色。

但是问题来了，Powerpoint似乎是没有选择全部“对象”的功能的。

上百页的PPT，这么多的文本框，怎么搞啊。

这时我就想到了 .pptx 是一个Zip压缩文件，用XML描述一个PPT。

讲道理，
可以对PPT里面的每一页里面的颜色的节点做一个字符串的替换，
这样就可以实现批量换色了。

那就动手吧~

基础装备

你需要一个压缩和解压 Zip 的工具，我选择 BandiZip。

你还需要一个脚本语言，我选择无敌的 Node.js。

当然，最关键的是需要一个Powerpoint，至少也要2007以后的吧。

开始动手

保存 .pptx

首先，我们需要把PPT另存为为 .pptx 格式的，
因为 .ppt 不是用 XML 描述一个PPT的。

如果本来就是 .pptx 那就无视上面那一步。

确认要替换的颜色的RGB值

第二，我们确认一下需要替换的颜色和替换到什么颜色。

这个需要我们在Powerpoint中选中有目标颜色的文本，
在“字体颜色”那儿选择“其他颜色”，
弹出的框框选自定义就可以看到颜色的RGB值了。

在这里颜色是红绿蓝的RGB的十进制数。
所以你会看到类似“红色 255 绿色 128 蓝色 0”这样的东西。

但是我们得转化成十六进制的RGB颜色值呀~

所以下面我提供了一个小函数方便大家转换（用控制台即可使用）：

1
2
3
4
5
6

function toRGBCode(r, g, b){
  return `#${pad(r)}${pad(g)}${pad(b)}`;
  function pad(num) { 
    return (Array(2).join("0") + num.toString(16)).slice(-2); 
  }
}

直接调用 toRGBCode 这个函数，分别传入红色、蓝色、绿色的值即可。

如：toRGBCode(255, 0, 0) 会输出 "#ff0000"

提取每一页的XML

使用解压工具把你要搞的 XXXX.pptx 解压了，
找到 ppt/slides 这个文件夹，
把整个文件夹解压出来，
这个就是每一页的PPT的 XML文件。

解压完毕之后，请看一下最后一个文件的需要是多少。

好比说，slide27.xml 是序号最大的文件，就说明这个PPT有 27 页。

好啦，记下来多少页之后就可以上脚本了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

const fs = require('fs');

const start = 1; // 开始的页码
const end = 44; // 需要替换颜色的最大页码

const path = './slides/'; // Slide的XML文件夹位置
run(path, start, end);

function run(path, start, end) {
  for(let i = start; i <= end; i++) {
    worker(path, i);
  }

  console.info('ok!');
}

function worker(path, page) {
  let data = fs.readFileSync(`${path}slide${page}.xml`).toString();
  data = replaceColor(data, 'FF0000', '000000'); // 替换红色为黑色
  data = replaceColor(data, 'FFFF00', '000000'); // 替换黄色为黑色
  fs.writeFileSync(`${path}slide${page}.xml`, data);
}

function replaceColor(data, srcColor, targetColor) {
  return data.replace(
    new RegExp(`<a:srgbClr val="${srcColor.toUpperCase()}"/>`, 'g'),
    `<a:srgbClr val="${targetColor.toUpperCase()}"/>`
  )
}

记得看一下脚本的注释，把该修改的地方都给改了。

好比说页码、Slides文件夹路径、需要替换的颜色和目标颜色，一定一定要改！！

脚本保存后运行一下就可以啦~

打包回去

还是用 BandiZip，我们把刚刚处理完的Slides文件夹整个压缩回去。

用 BandiZip 打开 .pptx文件后，用“添加”功能就可以啦~

Ok！ 赶紧打开 Powerpoint 看一下效果吧！

备份脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#!/bin/bash  
sourcepath=''
targetpath='/home/ubuntu/backup_db'
# 改成你自己的备份目录
nowtime=$(date +%Y%m%d)

start()
{
  ${sourcepath}mongodump --host 127.0.0.1 --port 27017 --out ${targetpath}/${nowtime}
  # 备份 127.0.0.1:27017 的整个MongoDB数据库
  # 输出到目标目录下的当前日期目录
  # 如：/backup_db/20171003/
}
execute()  
{
  start
  if [ $? -eq 0 ]
  then
    echo "back successfully!"  
  else
    echo "back failure!"  
  fi
}

if [ ! -d "${targetpath}/${nowtime}/" ]
then
 mkdir ${targetpath}/${nowtime}
fi
execute
echo "============== back end ${nowtime} =============="

使用前记得改一下脚本里面的参数，按照需求调整目录

删除过期备份

1
2
3
4
5
6
7
8
9

#!/bin/bash  
targetpath='/home/ubuntu/backup_db'
nowtime=$(date -d '-7 days' "+%Y%m%d")
if [ -d "${targetpath}/${nowtime}/" ]
then
  rm -rf "${targetpath}/${nowtime}/"
  echo "=======${targetpath}/${nowtime}/===删除完毕=="  
fi
echo "===$nowtime ==="

哈哈，只是把命令改成 rm -rf 了而已。记得按照需求调整参数里面的目录

自动备份和删除备份

不得不说我们的主角 crontab -e

Cron 可以实现定时任务的功能。

1
2

10 04 * * * /home/ubuntu/cron-shell/mongobak 1 > /var/log/cron/crontab_mongo_back.log &
10 02 * * * /home/ubuntu/cron-shell/mongobak_delete 1 > /var/log/cron/crontab_mongo_delete.log &

半夜三更的时候，定时任务就会执行 mongobak 和 mongobak_delete 两个脚本啦~

并且两个脚本的输出也会保存到 /var/log/cron/ 的日志文件里面，方便你后期检查。

上面的命令请根据实际需要调整喔

使用 ES6 的类，类中有两个方法彼此会相互调用，那怎么办?

听到这个问题的时候，我是一头雾水的，不是用 this 就好了吗。

然后他就给了个场景，让我来怼。

场景伪代码

照着大哥的想法，我撸了一个伪代码。

1
2
3
4
5
6
7
8
9
10
11
12
13

class Fetch{
  static 检查返值() {
    检查;
    如果签名过期，get（）
  }
  static get() {
    请求
    .then(检查返回值)
    
  }
}

Fetch.get();

可以看到就一个类 Fetch，里面有两个静态方法——检查返值 和 get。

类的外面只有一行代码——Fetch.get()，用于调用 Fetch 的静态方法 get。

先从 Fetch 的静态方法 get 入手，我们可以看到 get 方法内只有一行代码，里面的 then 暴露了“请求”是一个 Promise 的实例。

可以发现，“请求”接收到 resolved 信号时，需要执行 Fetch 的静态方法 检查返值。

在检查反值中，程序系那个会判定“请求”resolve 时带上的参数。如果里面的参数不符合规定，则重新进行一次 Fetch.get()。

锁定毒瘤

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

class Fetch{
  static check(value) {
    if (!value.isCert) {
      this.get();
    } else {
      console.log("Get it!");
    }
  }
  static get() {
    request()
      .then(this.check)
  }
}

// Start to fetch
Fetch.get();

大哥的代码有毒，问题发生在 request().then() 上。

大哥的做法是 request().then(this.check)。

虽然 check 方法还是可以执行，但是它只能执行一次。因为 Promise 的 then 内的作用域默认是全局 (global/windows)，而且在严格模式下是 undefined，因此，this 指向(call)的不是 Fetch。所以在执行 this.check 函数时，check 内的 this 并不是 Fetch 对象，this.get() 取出来的是 undefined，故 this.get(); 是无法执行的，达不到大哥的需求。

动手修改

既然 this.check 它 call 的不是 Fetch 本身，那么我们可以用 .call、.apply、.bind等可以调整函数的 this 的方式实现作用域的传递。

.call

我们知道，call() 方法在使用一个指定的this值和若干个指定的参数值的前提下调用某个函数或方法。

1
2

request()
    .then((v) => this.check.call(this, v))

.apply

类似于 .call ，只是它传递参数值靠数组。

1
2

request()
    .then((v) => this.check.apply(this, [v]))

.bind

bind() 方法会创建一个新函数。

当这个新函数被调用时，bind()的第一个参数将作为它运行时的 this, 之后的一序列参数将会在传递的实参前传入作为它的参数。

1
2
3
4
5

request()
    .then((v) => this.check.bind(this)(v))
    
request()
    .then((v) => this.check.bind(this, v)())

不用 this

不用 this 就相当于直接指向 Fetch 本身。

1
2
3
4
5
6
7

static check(value) {
    if (!value.isCert) {
        Fetch.get();
    } else {
        console.log("Get it!");
    }
  }

但是这样的做法，不是很好，可维护性比较差。

修改后的代码

最后，我们选择了最简洁的 .call 来实现这个需求。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

function request() {
  return new Promise(function (resolve, reject) {
    setTimeout(() => resolve(Math.round(Math.random() * 5)), 500)
  });
}

class Fetch{
  static cnt = 1;
  static check(value) {
    if (value) {
      console.log(`Fail!`);
      this.get();
    } else {
      console.log("Get it!");
    }
  }
  static get() {
    console.log(`Get now! count: ${this.cnt++}`);
    request()
      .then((v) => this.check.call(this, v)); //here
  }
}

// Start to fetch
Fetch.get();

功能

• 可以定时开关网站, 默认设定为早8点~晚21点开放；
• 被关闭的网站访问时会被强行中断连接；
• 设定 geo 的 white_list_ips 可以允许白名单IP不受闭站影响；
• 设定 map 的 white_list_websites 可以允许特定的网站(域名)不受闭站影响。

条件

• 需要一个 nginx 服务器软件
• nginx 需要编译带上 ngx_http_lua_module 模块

由于我们的服务器使用 openresty，因此符合以上条件。

Lua 脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

--
-- 定时关闭服务器脚本
-- Uer: Micblo
-- Date: 2017/3/3
-- Time: 14:26
--

local time = os.time()

-- 两会: 2017-03-12 解封 --
if (
    1489276800 > time and
    ngx.var.white_list_ips == "0" and
    ngx.var.white_list_websites == "0"
) then
    local now_hour = tonumber(os.date("%H", time))
    -- 每日 8 ~ 21 点开放 --
    if (now_hour < 8 or now_hour >= 21) then
        ngx.exit(444)
    end
end

在需要管控的网站的 server {} 下附上 access_by_lua_file lua/cron-block.lua; 调用这个Lua文件。

注意文件路径需要改成你实际存放这个脚本的位置，相对路径的起始目录为 nginx 的根目录。

white_list_ips 设置白名单IP

由于业务需要，两会期间依然允许一部分内网IP访问这些关闭的网站。

我们使用 geo 来存放这些IP。

1
2
3
4
5

geo $remote_addr $white_list_ips {
    default 0;
    10.0.0.0/8 1;
    192.168.0.0/16 1;
}

这样，在 10.0.0.0/8 和 192.168.0.0/16 网段的小伙伴就可以不受限制访问到网站了。

white_list_websites 设置域名白名单

由于业务需要，两会期间依然允许一部分网站可以被访问。

我们使用 map 来存放这些网站的域名。

1
2
3
4
5

map $server_name $white_list_websites {
    default 0;
    example.com 1;
    system.example.com 1;
}

这样，在 example.com 和 system.example.com 这两个网站可以不被关闭。

综合

最后我们把代码揉在一起：

1
2
3
4
5
6
7
8
9
10
11
12
13

geo $remote_addr $white_list_ips {
    default 0;
    10.0.0.0/8 1;
    192.168.0.0/16 1;
}

map $server_name $white_list_websites {
    default 0;
    example.com 1;
system.example.com 1;
}

access_by_lua_file lua/cron-block.lua;

建议把这个代码单独放到一个通用的配置文件里面，让全部的 server 都 include 它。

这样全部的 server 都可以适用这个规则。

如果不需要用这个脚本，直接注释掉 access_by_lua_file 那行即可。

前端一般就是 React、 Vue + webpack + gulp 之类的单页网站。

后端就丰富多啦，Node.js + Express 或者 Python + flask 甚至 PHP 之类的。

这样就会带来一个问题，就是前端的代码和后端的代码本身就是拆开开发的。

因此要实现前端和后端优雅地结合在一起是一个很关键的事情。

传统法 - Copy && Paste 战胜一切

好比说 Node.js，有的人习惯直接把前端的静态文件全部丢到 public 目录下面。

那么问题来了，这样不可避免就会在后端的文件夹出现前端的东西，其实很不优雅啊。

软链接 - 跨平台的选择

熟悉 Linux 系统的小伙伴应该知道“软链接”(Symbolic Link)。

它是一个文件，可以实现把这个文件和另一个文件或者文件夹“虚拟”绑定，比硬链接更加灵活。

好比说，我在 /home/payne/ 下创建了软链接文件 www，该软链接文件和 /var/www 绑定。

那么，我访问 /home/payne/www/ 就相当于访问 /var/www。

我用 cat /home/payne/www/apple/index.html 就相当于执行 cat /var/www/apple/index.html。

软链接的建立方式

*nix 系统

ln -s {sourse} {target}

• sourse: 就是源文件或者文件夹的路径
• target: 要生成的软链接文件的路径，不填就默认在当前目录下创建与源文件或者文件夹的名字相同的软链接文件。

下面打个比方：

我的 Nginx 配置目录在：/usr/local/openresty/nginx/conf

我想在 /etc/nginx 就可以访问到这个目录，你可以：

1
2

cd /etc
ln -s /usr/local/openresty/nginx/conf nginx

你也可以：

1

ln -s /usr/local/openresty/nginx/conf /etc/nginx

操作完了就可以直接 vi /etc/nginx/nginx.conf 更改默认的 Nginx 配置文件啦~~

Windows 系统

mklink {sourse} {target}

和 *nix 差不多，就是不用加上 flag 而已。

项目实操

我有一个 Node.js 的项目，叫 RedPacket。

在 Express 上，已经绑定静态目录是 public，代码如下所示：

1

app.use(express.static(path.join(__dirname, 'public')));

假设在服务器上，Node.js 的后端在: /var/www/redpacket/backend

前端项目目录在 /var/www/redpacket/frontend。

那么，我们就需要在 /var/www/redpacket/backend 下做一个软链接文件 public 绑定到 /var/www/redpacket/frontend。

很简单，执行下面的命令就可以了。

1

ln -s /var/www/redpacket/frontend /var/www/redpacket/backend/public

如果你在 /var/www/redpacket/backend 目录下，就更简单了：

1

ln -s ../frontend public

很关键，在 Windows 的开发环境下，也做一样的操作，并且把 public 加入 .gitignore 就可以防止 Git 带上这个软链接文件。

这样就很顺利地把前后端的目录绑定好啦，而且条理清晰，优雅地分离前后端地代码。

你学会了吗?