本文为静态镜像，内容以交互版为准在交互式文档中心打开 →

技術標準

概要: アダプタ標準化ガイド —— 標準化原則、標準マップ、命名規則、差異処理モード、および開発者チェックリスト。新しいアダプタまたは新しい機能は、まずこれを読んでください。

このドキュメントは、ErisPulse の技術標準規格を含み、各コンポーネント間の一貫性と互換性を確保します。

標準ドキュメントリスト

セッションタイプ標準 - ErisPulse セッションタイプの定義とマッピング規格
イベント変換標準 - プラットフォームイベント変換規格、拡張命名規則、メッセージセグメント標準
API レスポンス標準 - アダプタ API レスポンス形式の標準および拡張要件
送信メソッド仕様 - Send クラスメソッドの命名、パラメータ規格、および逆変換要件
リクエスト操作仕様 - リクエストイベントフィールド要件、HandleRequest DSL、およびアダプタ実装要件
API アクション標準 - OneBot12 標準 API アクションの統一インターフェース（ユーザー/グループ/チャンネル/メッセージ管理/ファイル含む分片/メタアクション）
アダプタ標準化ガイド（概要） - 標準化原則/ワークフロー/命名規則 + 交互コンポーネント標準（ボタンキーボード/インタラクティブコールバックイベント）および各プラットフォームマッピング

標準の概要

ErisPulse は OneBot12 をコアイベント標準として採用し、その上で拡張と細分化を行っています。

コア原則

互換性: すべての標準は OneBot12 標準と互換性を保つ必要があります
拡張性: プラットフォーム固有の機能はプレフィックス方式で拡張し、衝突を避ける
一貫性: タイムスタンプ、ID 形式などの重要なフィールドは統一処理を行う
追跡可能性: デバッグや問題調査のために元のデータを保持する

なぜ標準が必要なのか？

1. 跨プラットフォーム互換性の確保

異なるプラットフォームのイベント形式はそれぞれ異なり、標準化された変換により以下が保証されます：

モジュールコードは一度書けばすべてのプラットフォームで実行可能
イベント処理ロジックが一貫性を持つ
開発および保守コストの削減

2. API インターフェースの規範化

統一された API レスポンス形式により以下が保証されます：

モジュールは一貫して API エラーを処理できる
エラーメッセージは統一され、理解しやすい
戻り値のデータ構造が一貫する

3. コード品質の向上

標準規格により以下が可能になります：

コードスタイルの一貫性を保つ
命名衝突を減らす
コードの可読性を向上

標準を遵守するメリット

アダプタ開発者にとって

明確な変換ルール
統一されたレスポンス形式
デバッグおよびテストが容易

モジュール開発者にとって

一貫したイベントインターフェース
予測可能な API 動作
跨プラットフォーム開発が簡素化

最終ユーザーにとって

穏やかなシステム動作
統一されたメッセージ形式
良好な互換性

標準遵守チェックリスト

イベント変換

すべての標準フィールドが正しくマッピングされている
プラットフォーム固有のフィールドにプレフィックスが追加されている
タイムスタンプが10桁の秒単位に変換されている
元のデータは {platform}_raw に保存されている
元のイベントタイプは {platform}_raw_type に保存されている
メッセージセグメントの alt_message が生成されている
リクエストイベントに request_id フィールドが含まれている

API レスポンス

status フィールドが含まれている
retcode フィールドが含まれている
data フィールドが含まれている
message_id フィールドが含まれている
message フィールドが含まれている
戻りコードは OneBot12 規格に従っている

送信メソッド命名

PascalCase（大文字キャメルケース）を使用している
Task オブジェクトを返している
修飾メソッドは self を返している
パラメータ命名が規格に従っている

メディア送信（Image / Voice / Video / File）

file パラメータはすべての形式に対応している：HTTP(S) URL / 本地パス / bytes
形態判定順序は規格に従っている（bytes → URL → file:// → パス）
File のファイル名は推論順序に従って生成される（明示的な filename > URL の basename > パスの basename > プラットフォームのデフォルト）
プラットフォームのメディア制限はアダプタドキュメントに宣言されている
対応していないメディアタイプは降格階梯で処理される（近縁タイプの降格または retcode=10002、例外をスローしない、静かに破棄しない）

詳細なプロトコルは送信メソッド仕様 §2.1 を参照してください

リクエスト操作

HandleRequest クラスは _do_accept / _do_reject を実装している
操作は標準 API レスポンス形式を返している
対応していない操作は retcode=10002 を返している