การรับส่งข้อความแบบเดิม

ส่วนขยายสามารถแลกเปลี่ยนข้อความกับแอปพลิเคชันดั้งเดิมได้โดยใช้ 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/"]
}

ไฟล์ Manifest ของโฮสต์การรับส่งข้อความดั้งเดิมต้องเป็น JSON ที่ถูกต้องและมีช่องต่อไปนี้

name

ชื่อของโฮสต์การรับส่งข้อความดั้งเดิม ไคลเอ็นต์จะส่งสตริงนี้ไปยัง runtime.connectNative() หรือ runtime.sendNativeMessage() ชื่อนี้มีได้เฉพาะอักขระที่เป็นตัวอักษรและตัวเลขคละกันตัวพิมพ์เล็ก ขีดล่าง และจุด ชื่อต้องไม่ขึ้นต้นหรือลงท้ายด้วยจุด และจุดต้องไม่ตามด้วยจุดอีกจุด

description

คำอธิบายแอปพลิเคชันแบบย่อ

path

เส้นทางไปยังไบนารีของโฮสต์การรับส่งข้อความในเครื่อง ใน Linux และ macOS เส้นทางต้องเป็นค่าสัมบูรณ์ ใน Windows เส้นทางนี้อาจสัมพันธ์กับไดเรกทอรีที่มีไฟล์ Manifest กระบวนการโฮสต์จะเริ่มต้นโดยตั้งค่าไดเรกทอรีปัจจุบันเป็นไดเรกทอรีที่มีไบนารีของโฮสต์ เช่น หากตั้งค่าพารามิเตอร์นี้เป็น C:\Application\nm_host.exe ระบบจะเริ่มต้นด้วยไดเรกทอรีปัจจุบัน `C:\Application`

type

ประเภทของอินเทอร์เฟซที่ใช้ในการสื่อสารกับโฮสต์การรับส่งข้อความดั้งเดิม พารามิเตอร์นี้มีค่าที่เป็นไปได้ค่าเดียวคือ stdio ซึ่งระบุว่า Chrome ควรใช้ stdin และ stdout เพื่อสื่อสารกับโฮสต์

allowed_origins

รายการส่วนขยายที่ควรมีสิทธิ์เข้าถึงโฮสต์การรับส่งข้อความที่มาพร้อมระบบ ค่า allowed-origins ต้องไม่มีไวลด์การ์ด

ตำแหน่งโฮสต์การรับส่งข้อความในเครื่อง

ตำแหน่งของไฟล์ Manifest จะขึ้นอยู่กับแพลตฟอร์ม

ใน Windows คุณวางไฟล์ Manifest ไว้ที่ใดก็ได้ในระบบไฟล์ โปรแกรมติดตั้งแอปพลิเคชัน ต้องสร้างคีย์รีจิสทรี ไม่ว่าจะเป็น HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.my_company.my_application หรือ HKEY_CURRENT_USER\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.my_company.my_application และ ตั้งค่าเริ่มต้นของคีย์นั้นเป็นเส้นทางแบบเต็มไปยังไฟล์ Manifest เช่น ใช้คำสั่งต่อไปนี้

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 ตำแหน่งของไฟล์ Manifest ของโฮสต์การรับส่งข้อความดั้งเดิมจะแตกต่างกันไปตาม เบราว์เซอร์ (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) ระบบจะใช้รูปแบบเดียวกันในการส่งข้อความใน ทั้ง 2 ทิศทาง โดยจะมีการซีเรียลไลซ์ข้อความแต่ละรายการโดยใช้ JSON, เข้ารหัส UTF-8 และนำหน้าด้วยความยาวของข้อความ 32 บิต ในลำดับไบต์ดั้งเดิม ขนาดสูงสุดของข้อความเดียวจากโฮสต์การรับส่งข้อความดั้งเดิมคือ 1 MB ซึ่งส่วนใหญ่มีไว้เพื่อปกป้อง Chrome จากแอปพลิเคชันดั้งเดิมที่ทำงานไม่ถูกต้อง ขนาดสูงสุดของ ข้อความที่ส่งไปยังโฮสต์การรับส่งข้อความดั้งเดิมคือ 64 MiB

อาร์กิวเมนต์แรกของโฮสต์การรับส่งข้อความดั้งเดิมคือต้นทางของผู้เรียก ซึ่งโดยปกติคือ chrome-extension://[ID of allowed extension] ซึ่งจะช่วยให้โฮสต์การรับส่งข้อความที่มาพร้อมระบบระบุแหล่งที่มาของข้อความได้เมื่อมีการระบุส่วนขยายหลายรายการในคีย์ allowed_origins ในไฟล์ Manifest ของโฮสต์การรับส่งข้อความที่มาพร้อมระบบ

ใน Windows โฮสต์การรับส่งข้อความในเครื่องจะได้รับอาร์กิวเมนต์บรรทัดคำสั่งที่มีแฮนเดิลไปยัง หน้าต่างในเครื่องของ Chrome ที่เรียกใช้: --parent-window=<decimal handle value> ซึ่งจะช่วยให้โฮสต์การรับส่งข้อความในเครื่องสร้างหน้าต่าง UI ในเครื่องที่เชื่อมโยงกับองค์ประกอบหลักได้อย่างถูกต้อง โปรดทราบว่าค่านี้จะเป็น 0 หากบริบทการเรียกเป็น Service Worker

เมื่อสร้างพอร์ตการรับส่งข้อความโดยใช้ runtime.connectNative() Chrome จะเริ่มกระบวนการโฮสต์การรับส่งข้อความดั้งเดิม และจะเรียกใช้ต่อไปจนกว่าจะทำลายพอร์ต ในทางกลับกัน เมื่อส่งข้อความโดยใช้ runtime.sendNativeMessage() โดยไม่ได้สร้างพอร์ตการรับส่งข้อความ Chrome จะเริ่มกระบวนการโฮสต์การรับส่งข้อความดั้งเดิมใหม่สำหรับแต่ละข้อความ ในกรณีดังกล่าว ระบบจะถือว่าข้อความแรกที่สร้างโดยกระบวนการโฮสต์ เป็นคำตอบสำหรับคำขอเดิม และ Chrome จะส่งข้อความดังกล่าวไปยังโปรแกรมเรียกกลับการตอบกลับที่ระบุเมื่อมีการเรียกใช้ runtime.sendNativeMessage() ระบบจะไม่สนใจข้อความอื่นๆ ทั้งหมดที่โฮสต์การรับส่งข้อความดั้งเดิมสร้างขึ้นในกรณีดังกล่าว

การเชื่อมต่อกับแอปพลิเคชันเริ่มต้น

การส่งและรับข้อความไปยังและจากแอปพลิเคชันดั้งเดิมจะคล้ายกับการรับส่งข้อความข้ามส่วนขยายเป็นอย่างมาก ความแตกต่างหลักคือใช้ runtime.connectNative() แทน runtime.connect() และใช้ runtime.sendNativeMessage() แทน runtime.sendMessage()

หากต้องการใช้วิธีการเหล่านี้ คุณต้องประกาศสิทธิ์ "nativeMessaging" ในไฟล์ Manifest ของส่วนขยาย

วิธีการเหล่านี้ใช้ใน Content Script ไม่ได้ แต่ใช้ได้เฉพาะในหน้าและ Service Worker ของส่วนขยาย หากต้องการสื่อสารจาก Content Script ไปยังแอปพลิเคชันเนทีฟ ให้ส่งข้อความไปยัง Service Worker เพื่อส่งต่อข้อความไปยังแอปพลิเคชันเนทีฟ

ตัวอย่างต่อไปนี้สร้างออบเจ็กต์ runtime.Port ที่เชื่อมต่อกับโฮสต์การรับส่งข้อความดั้งเดิม com.my_company.my_application เริ่มฟังข้อความจากพอร์ตนั้น และส่งข้อความขาออก

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 จะอ่านข้อความ ซึ่งมักจะเริ่มจากโฮสต์การรับส่งข้อความที่มาพร้อมระบบ

ไม่พบโฮสต์การรับส่งข้อความที่มาพร้อมระบบที่ระบุ

โปรดตรวจสอบสิ่งต่อไปนี้

• ชื่อสะกดถูกต้องในส่วนขยายและในไฟล์ Manifest ไหม
• ไฟล์ Manifest อยู่ในไดเรกทอรีที่ถูกต้องและมีชื่อที่ถูกต้องใช่ไหม ดูรูปแบบที่คาดไว้ได้ที่โฮสต์การรับส่งข้อความที่มาพร้อมระบบ ตำแหน่ง
• ไฟล์ Manifest อยู่ในรูปแบบที่ถูกต้องหรือไม่ โดยเฉพาะอย่างยิ่ง JSON ถูกต้องและมีรูปแบบที่ถูกต้องหรือไม่ และค่าต่างๆ ตรงกับคำจำกัดความของ Manifest ของโฮสต์การรับส่งข้อความดั้งเดิมหรือไม่
• มีไฟล์ที่ระบุใน path หรือไม่ ใน Windows เส้นทางอาจเป็นแบบสัมพัทธ์ แต่ใน macOS และ Linux เส้นทางต้องเป็นแบบสัมบูรณ์

ไม่ได้ลงทะเบียนชื่อโฮสต์ของโฮสต์การรับส่งข้อความที่มาพร้อมระบบ (Windows เท่านั้น)