扩展程序可以使用类似于其他消息传递 API 的 API 与原生应用交换消息。支持此功能的原生应用必须注册一个可以与扩展程序通信的原生消息主机。Chrome 在单独的进程中启动主机，并使用标准输入流和标准输出流与主机进行通信。
原生消息传递主机
如需注册原生消息传递主机，应用必须保存用于定义原生消息传递主机配置的文件。
该文件的示例如下所示：
{
"name": "com.my_company.my_application",
"description": "My Application",
"path": "C:\\Program Files\\My Application\\chrome_native_messaging_host.exe",
"type": "stdio",
"allowed_origins": ["chrome-extension://knldjmfmopnpolahpmmgbagdohdnhkik/"]
}
原生消息传递主机清单文件必须是有效的 JSON，并且包含以下字段：
name- 本地消息传递主机的名称。客户端会将此字符串传递给
runtime.connectNative()或runtime.sendNativeMessage()。此名称只能包含小写字母数字字符、下划线和点。名称不能以英文句点开头或结尾，英文句点后面也不能再跟英文句点。 description- 简短的应用说明。
path- 原生消息传递主机二进制文件的路径。在 Linux 和 macOS 上，路径必须是绝对路径。在 Windows 上，它可以相对于包含清单文件的目录。启动主机进程时，将当前目录设置为包含主机二进制文件的目录。例如，如果此参数设置为
C:\Application\nm_host.exe，则将使用当前目录“C:\Application”启动。 type- 用于与原生消息传递主机通信的接口类型。此参数只有一个可能值：
stdio。它指示 Chrome 应使用stdin和stdout与主机通信。 allowed_origins- 应有权访问原生消息传递主机的扩展程序的列表。
allowed-origins值不能包含通配符。
原生消息传递主机位置
清单文件的位置取决于平台。
在 Windows 上，清单文件可以位于文件系统中的任何位置。应用安装程序必须创建一个注册表项（HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.my_company.my_application 或 HKEY_CURRENT_USER\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.my_company.my_application），并将该项的默认值设置为清单文件的完整路径。例如，使用以下命令：
REG ADD "HKCU\Software\Google\Chrome\NativeMessagingHosts\com.my_company.my_application" /ve /t REG_SZ /d "C:\path\to\nmh-manifest.json" /f
或者使用以下 .reg 文件：
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\com.my_company.my_application]
@="C:\\path\\to\\nmh-manifest.json"
当 Chrome 查找原生消息传递主机时，会先查询 32 位注册表，然后再查询 64 位注册表。
在 macOS 和 Linux 上，原生消息传递主机的清单文件的位置因浏览器（Google Chrome 或 Chromium）而异。系统级原生即时通讯主机在固定位置进行查找，而用户级原生即时通讯主机在用户个人资料目录的 NativeMessagingHosts/ 子目录中进行查找。
- macOS（系统级）
- Google Chrome：
/Library/Google/Chrome/NativeMessagingHosts/com.my_company.my_application.json - Chromium：
/Library/Application Support/Chromium/NativeMessagingHosts/com.my_company.my_application.json - macOS（用户专用，默认路径）
- Google Chrome：
~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.my_company.my_application.json - Chromium：
~/Library/Application Support/Chromium/NativeMessagingHosts/com.my_company.my_application.json - Linux（系统级）
- Google Chrome：
/etc/opt/chrome/native-messaging-hosts/com.my_company.my_application.json - Chromium：
/etc/chromium/native-messaging-hosts/com.my_company.my_application.json - Linux（用户专用，默认路径）
- Google Chrome：
~/.config/google-chrome/NativeMessagingHosts/com.my_company.my_application.json - Chromium：
~/.config/chromium/NativeMessagingHosts/com.my_company.my_application.json
原生消息传递协议
Chrome 会在单独的进程中启动每个原生消息传递主机，并使用标准输入 (stdin) 和标准输出 (stdout) 与其通信。发送消息时，无论是发送到哪个方向，都使用相同的格式；每个消息都使用 JSON 进行序列化，采用 UTF-8 编码，并在前面附加 32 位消息长度（采用原生字节顺序）。来自原生消息主机的单个消息的大小上限为 1 MB，这主要是为了保护 Chrome 免受行为异常的原生应用的影响。发送到原生消息传递主机的消息大小上限为 4 GB。
原生消息传递主机的第一个参数是调用方的来源，通常为 chrome-extension://[ID of allowed extension]。这样一来，当原生消息传递主机清单中的 allowed_origins 键中指定多个扩展程序时，原生消息传递主机便可识别消息来源。
在 Windows 上，系统还会向原生消息传递主机传递一个命令行参数，其中包含对调用 Chrome 原生窗口的句柄：--parent-window=<decimal handle value>。这样，原生消息传递主机就可以创建具有正确父级的原生界面窗口。请注意，如果调用上下文是服务工件，则此值将为 0。
使用 runtime.connectNative() 创建消息传递端口时，Chrome 会启动原生消息传递主机进程，并使其保持运行状态，直到端口被销毁为止。另一方面，如果使用 runtime.sendNativeMessage() 发送消息，而未创建消息端口，Chrome 会为每条消息启动一个新的原生消息传递主机进程。在这种情况下，主机进程生成的第一个消息会被视为对原始请求的响应，Chrome 会将其传递给调用 runtime.sendNativeMessage() 时指定的响应回调。在这种情况下，系统会忽略本地消息传递主机生成的所有其他消息。
连接到原生应用
向原生应用发送和接收消息与跨扩展程序消息传递非常相似。主要区别在于，使用的是 runtime.connectNative()（而非 runtime.connect()）和 runtime.sendNativeMessage()（而非 runtime.sendMessage()）。
如需使用这些方法，必须在扩展程序的清单文件中声明“nativeMessaging”权限。
这些方法无法在内容脚本中使用，只能在扩展程序的页面和 Service Worker 中使用。如果您希望从内容脚本与原生应用通信，请将消息发送到您的 Service Worker，以便将其传递给原生应用。
以下示例创建了一个连接到原生消息传递主机 com.my_company.my_application 的 runtime.Port 对象，开始监听该端口中的消息，并发送一条出站消息：
var port = chrome.runtime.connectNative('com.my_company.my_application');
port.onMessage.addListener(function (msg) {
console.log('Received' + msg);
});
port.onDisconnect.addListener(function () {
console.log('Disconnected');
});
port.postMessage({text: 'Hello, my_application'});
使用 runtime.sendNativeMessage 向原生应用发送消息，而无需创建端口，例如：
chrome.runtime.sendNativeMessage(
'com.my_company.my_application',
{text: 'Hello'},
function (response) {
console.log('Received ' + response);
}
);
调试原生消息传递
发生某些原生消息传递失败时，系统会将输出写入 Chrome 的错误日志。这包括当原生消息传递主机无法启动、向 stderr 写入数据或违反通信协议时。在 Linux 和 macOS 上，您可以通过从命令行启动 Chrome 并在终端中查看其输出来访问此日志。在 Windows 上，请按照如何启用日志记录中的说明使用 --enable-logging。
以下是一些常见错误和解决办法：
未能启动原生消息传递主机。
检查您是否有足够的权限来执行原生消息传递主机文件。
指定的原生消息传递主机名无效。
检查名称是否包含无效字符。仅允许使用小写字母数字字符、下划线和英文句点。名称不能以英文句点开头或结尾，英文句点后面也不能再跟英文句点。
原生主机已退出。
在 Chrome 读取消息之前，指向原生消息传递主机的管道已断开。此操作很可能从您的原生消息传递主机发起。
未找到指定的原生即时通讯主机。
请检查以下事项：
- 名称在扩展程序和清单文件中是否拼写正确？
- 清单是否位于正确的目录中且名称是否正确？如需了解预期格式，请参阅原生消息传递主机位置。
- 清单文件的格式是否正确？具体而言，JSON 是否有效且格式正确，值是否与原生消息传递主机清单的定义相符？
path中指定的文件是否存在？在 Windows 上，路径可以是相对路径，但在 macOS 和 Linux 上，路径必须是绝对路径。
原生即时通讯主机主机名未注册。（仅适用于 Windows）
在 Windows 注册表中找不到原生即时通讯主机。使用 regedit 仔细检查密钥是否真的已创建，以及是否符合原生消息传递主机位置中所述的所需格式。
禁止访问指定的原生即时通讯主机。
扩展程序的来源是否已列在 allowed_origins 中？
与原生消息传递主机通信时出错。
这表示原生消息传递主机中通信协议的实现有误。
- 确保
stdout中的所有输出均遵循原生消息传递协议。如果要输出某些数据以进行调试，请将数据写入stderr。 - 确保 32 位消息长度采用平台的原生整数格式（小端/大端）。
- 消息长度不得超过 1024*1024。
- 消息大小必须等于消息中的字节数。这可能与字符串的“长度”不同，因为字符可以由多个字节表示。
- 仅限 Windows：确保将程序的 I/O 模式设置为
O_BINARY。默认情况下，I/O 模式为O_TEXT，这会导致消息格式损坏，因为换行符 (\n=0A) 会被替换为 Windows 风格的换行符 (\r\n=0D 0A)。可以使用__setmode设置 I/O 模式。