i18n(ja): Add Japanese texts for Concept section (#3197)

Co-authored-by: Ayres Vitor <gitkey@virtuaires.com.br>
This commit is contained in:
Junichi TAKAI (たかい じゅんいち)
2025-03-30 03:57:42 +09:00
committed by GitHub
parent 0100420e8e
commit 7ad426226c
12 changed files with 1456 additions and 16 deletions

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 74 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 85 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 90 KiB

File diff suppressed because one or more lines are too long

After

Width:  |  Height:  |  Size: 93 KiB

View File

@@ -0,0 +1,36 @@
---
title: ブラウンフィールド型Brownfield Pattern
i18nReady: true
---
_**デフォルトの IPC パターンです**_
このパターンは、Tauri を使用する上で最も明快で分かりやすいものです。というのも、既存のフロントエンド・プロジェクトと可能な限り互換性を持たせようとしているからです。手短に言えば、既存の Web フロントエンドがブラウザー内で使用するもの以外には、他に何も必要としないようになっているということです。
ただ、これは既存のブラウザー・アプリケーションで動作する _**すべて**_ が、そのまま動作するというわけではありません。
一般的な「ブラウンフィールド」型のソフトウェア開発について馴染みがない場合は、Wikipedia の記事 [Brownfield Wikipedia article](日本語版なし)に判りやすい概説があります。
Tauri の場合、(ブラウンフィールド型開発の対象となる)既存のソフトウェアとは、レガシー・システムではなく、現行ブラウザーのサポートと動作です。
## 設定
ブラウンフィールド型開発はデフォルトのパターンなので、設定オプションを指定する必要はありません。
明示的に設定するには、`tauri.conf.json` 構成ファイル内の `tauri > pattern` オブジェクトを使用します。
```json
{
"tauri": {
"pattern": {
"use": "brownfield"
}
}
}
```
_**ブラウンフィールド型では追加の設定オプションはありません。**_
[brownfield wikipedia article]: https://en.wikipedia.org/wiki/Brownfield_(software_development)
<div style="text-align:right">
【※ この日本語版は、「Feb 22, 2025 英語版」に基づいています】<br />
Doc-JP 2.00.00
</div>

View File

@@ -0,0 +1,100 @@
---
title: プロセス間通信
sidebar:
label: Overview
order: 1
i18nReady: true
---
import { CardGrid, LinkCard } from '@astrojs/starlight/components';
「プロセス間通信 Inter-Process Communication」IPCは、単独のプロセスが安全に通信することを可能にし、より複雑なアプリケーションを構築するための鍵となります。
具体的な「プロセス間通信IPC」の型パターンについては、次の説明内容を参照してください
<CardGrid>
<LinkCard
title="Brownfield<br>ブラウンフィールド型"
href="/ja/concept/inter-process-communication/brownfield/"
/>
<LinkCard
title="Isolation<br>アイソレーション型"
href="/ja/concept/inter-process-communication/isolation/"
/>
</CardGrid>
Tauri は、[Asynchronous Message Passing](非同期メッセージ・パッシング、[日本語版リンク](<https://ja.wikipedia.org/wiki/メッセージ_(コンピュータ)>)と呼ばれる特別なスタイルのプロセス間通信を使用します。この方法では、プロセス同士が単純なデータ表現を使用してシリアル化された「_リクエスト_要求」と「_レスポンス_応答」をやり取りします。メッセージ・パッシングは、インターネット上のクライアント・サーバー通信に使用される仕組みであるため、Web 開発の経験がある人なら誰でも馴染みがあるはずです。
また、メッセージ・パッシングは受信者が必要に応じて「リクエスト」を拒否または破棄できるため、「共有メモリ方式」や「直接関数アクセス方式」よりも安全な手法です。たとえば、Tauri コア・プロセスが「リクエスト」を悪意のあるものと判断した場合、そのリクエストは破棄され、対応する関数処理は実行されません。
以下では、Tauri の二つの「IPC プリミティブ(同期基本命令)」、すなわち「イベント `Events` 」と「コマンド `Commands` 」について詳しく説明します。
## イベント
「イベント」は、自動追尾型・一方向性の「IPC メッセージ」で、ライフサイクル中の各イベントと状態の変化を伝達するのに最適です。
「[コマンド](#コマンド)」とは異なり、「イベント」はフロントエンドと Tauri Coreコア部の両方から発行できます。
<figure>
```d2 sketch pad=50
shape: sequence_diagram
Frontend: {
shape: rectangle
label: "Webview\nFrontend"
}
Core: {
shape: rectangle
label: "Core\nBackend"
}
Frontend -> Core: "イベント"{style.animated: true}
Core -> Frontend: "イベント"{style.animated: true}
```
<figcaption>コア部と Webview 間でやり取りされるイベント</figcaption>
</figure>
## コマンド
Tauri は、また、「IPC メッセージ」に加えて、[foreign function interface](外部関数インターフェース、[日本語版リンク](https://ja.wikipedia.org/wiki/Foreign_function_interface))のような抽象化も提供します[^1]。基本主要 API である `invoke` は、ブラウザの `fetch` API に似ており、フロントエンドが Rust 関数を呼び出し、引数を渡して、データを受信できるようにします。
このメカニズムは、内部で [JSON-RPC] のようなプロトコルを使用してリクエストとレスポンスをシリアル化するので、すべての引数と戻り値データは JSON の規格に従ってシリアル化可能である必要があります。
<figure>
```d2 sketch pad=50
shape: sequence_diagram
Frontend: {
label: "Webview\nFrontend"
}
Core: {
label: "Core\nBackend"
}
InvokeHandler: {
label: "Invoke\nHandler"
}
Frontend -> Core: "IPC リクエスト"{style.animated: true}
Core -> InvokeHandler: "コマンド 呼び出し"{style.animated: true}
InvokeHandler -> Core: "戻り値 シリアル化"{style.animated: true}
Core -> Frontend: "レスポンス"{style.animated: true}
```
<figcaption>コマンド呼び出しに関与する IPC メッセージ</figcaption>
</figure>
[^1]: コマンドは、内部ではメッセージ・パッシングを使用しているため、実際の「外部関数インターフェースFFI」と同じようなセキュリティ上の落とし穴はありません。
[Asynchronous Message Passing]: https://en.wikipedia.org/wiki/Message_passing#Asynchronous_message_passing
[json-rpc]: https://www.jsonrpc.org
[foreign function interface]: https://en.wikipedia.org/wiki/Foreign_function_interface
<div style="text-align:right">
【※ この日本語版は、「Feb 22, 2025 英語版」に基づいています】
<br />
Doc-JP 2.00.00
</div>

View File

@@ -0,0 +1,121 @@
---
title: アイソレーション型Isolation Pattern
i18nReady: true
---
アイソレーション(分離・隔絶)型は、フロントエンドから送信された Tauri API メッセージが Tauri コア部に到達する前に、JavaScript を使用して傍受・変更する方法です。アイソレーション型で挿入される安全な JavaScript コードは、アイソレーション型アプリケーションと呼ばれます。
## アイソレーション型の必要性
アイソレーション型の目的は、Tauri コア部への望ましくないあるいは悪意のあるフロントエンドからの呼び出しから、アプリケーションを保護するための仕組みを開発者に提供することです。アイソレーション型が必要となったのは、フロントエンドで実行される信頼できないコンテンツから生じる脅威に対応するために生まれました。このような脅威は多くの依存関係を持つアプリケーションによくあるケースです。アプリケーションが遭遇する可能性のある多くの脅威源のリストについては、[セキュリティ:脅威モデル] を参照してください。
上記の最大の脅威モデルは「開発時の脅威」でしたが、このような脅威は、アイソレーション型を設計する際に念頭に置かれていたものです。多くのフロントエンドのビルド・ツールが、しばしば深くネスト化された数十(もしくは数百)の依存関係で成り立っているだけではなく、複雑なアプリケーション側にも、数多くの(こちらもしばしば深くネスト化された)依存関係があり得るので、最終出力版にバンドルされるのです。
## アイソレーション型を使用する局面
Tauri は、アイソレーション型が使用できる場合には常に使用することを強く推奨しています。アイソレーション型のアプリケーションではフロントエンドからの _**すべての**_ メッセージを「捕捉」(インターセプト)するため、アイソレーション型が _常に_ 使用されます。
さらに Tauri では、外部の Tauri API を使用するときは常に、アプリケーションを「封鎖」(ロックダウン)することを強く推奨しています。アプリの開発者は、安全なアイソレーション型アプリケーションを利用して IPC 入力を検証し、その入力内容が確実に想定されるパラメータの範囲内にあることを確かめます。事例としては、ファイルの読み取りまたは書き込みの呼び出しが、そのアプリケーションの想定外の場所へのパスにアクセスしようとしていないかを確認したり、あるいは、Tauri API の「HTTP フェッチコール」が 「Origin ヘッダー」にそのアプリケーションが想定しているもののみを設定しているかを確認したりすることです。
とはいえ、フロントエンドからの _**すべての**_ メッセージを捕捉するため、常時動作 API、たとえば [Events] など、でも動作します。一部のイベントでは、アプリ独自の Rust コードにアクションを実行させる可能性があるので、それにも同様の検証手法で対応することができます。
## アイソレーション型の適用
アイソレーション型で重要なのは、フロントエンドと Tauri Coreタウリ・コア部との間に安全なアプリケーションを挿入して、IPC 受信メッセージを捕捉し修正することです。これには、`<iframe>` のサンドボックス機能(隔離機能)を使用して、メインのフロントエンド・アプリケーションと並行して JavaScript を安全に実行することで実現します。Tauri は、ページの読み込み中にアイソレーション型を発動し、Tauri Core に対するすべての IPC 呼び出しを、直接ではなく、サンドボックス化隔離化されたアイソレーション型アプリケーション経由で行なうように強制的にルートを切り替えます。Tauri Core に渡されるメッセージの準備が整うと、メッセージはブラウザ実装の [SubtleCrypto] を使用して暗号化され、メインのフロントエンド・アプリケーションに返されます。
フロントエンドに戻されるとすぐに、メッセージは直接 Tauri Core に渡され、そこで通常どおりに復号化されて読み取られます。
誰かがアプリケーションの特定のバージョンのキーを手動で読み取り、暗号化後にそのキーを用いてメッセージの変更を行なえないことを確実にするために、アプリケーションが実行されるたびに新しいキーが生成されます。
### IPC メッセージのおおよその手順
動作の流れを判りやすくするために、アイソレーション型の IPC メッセージが Tauri Core に送信されるときに実行されるおおよその手順を、順序付きリストで以下に示します:
1. Tauri の IPC ハンドラーがメッセージを受け取ります
2. IPC ハンドラー → アイソレーション型アプリケーション
3. `[sandbox]` アイソレーション型アプリケーションのフックが実行され、メッセージの変更を行なう可能性があります。
4. `[sandbox]` メッセージは「実行時に生成されるキー」を使用して AES-GCM で暗号化されます
5. `[encrypted]` アイソレーション型アプリケーション  IPC ハンドラー
6. `[encrypted]` IPC ハンドラー  Tauri Core
_注記 矢印は、メッセージ・パッシング受け渡しを示します。_
### パフォーマンスへの影響
安全なアイソレーション型アプリケーションは、メッセージの暗号化が行なわれるため、何も行なわない場合ですら [ブラウンフィールド型] と比較して追加のオーバーヘッド・コストが発生します。(適切なパフォーマンスを維持するために、慎重に保守され依存関係も少ないであろう)パフォーマンス重視のアプリケーションを除けば、ほとんどのアプリケーションは比較的小型で AES-GCM 暗号化方式も比較的高速であるため、IPC メッセージの暗号化/復号化の実行時コストを意識する必要はありません。もし AES-GCM について馴染みがないとしても、ここで関連するのは、それが [SubtleCrypto] に含まれる唯一の認証モード・アルゴリズムであり、おそらく「[TLS][transport_layer_security] 暗号化プロトコル」の内部で既に毎日使用しているということだけです。
Tauri アプリケーションが起動されるたびに一度、暗号化された安全なキーも生成されますが、システムがすでに十分なエントロピー(ランダム性)を備えていて、即座に十分な乱数を返すのであれば、この処理には通常気付きません。これは「デスクトップ環境」では極めて一般的です。「ヘッドレス環境」で [WebDriver との統合テスト] などを実行する場合で、オペレーティング・システムにエントロピー生成サービス《訳注: 「乱数生成」機能》が含まれていない場合には、`haveged` などの何らかのエントロピー生成サービスをインストールすることをお勧めします。<sup>Linux 5.6 (March 2020) 版から、投機的実行によるエントロピー生成が含まれるようになりました。</sup>
### 制限事項
アイソレーション型には、プラットフォームとの不整合から生じる制限事項がいくつかあります。最も重大な制限は、Windows 上のサンドボックス化された `<iframes>` 内に外部ファイルが正しく読み込まれないことによるものです。このため、アイソレーション型アプリケーションに関連するスクリプトの内容を取得してインラインに挿入する、ビルド時の簡単なスクリプト・インライン化手順を実装しました。つまりこれは、`<script src="index.js"></script>` のようなファイルの典型的なバンドル、あるいは単純な挿入は依然として正常に機能しますが、ES ModulesECMAScript Modulesなどの新しいメカニズムは上手く読み込ま**ない**ということを意味します。
## 推奨事項
アイソレーション型アプリケーションの目的は開発時の脅威から保護することであるため、アイソレーション型アプリケーションはできる限り簡素化しておくことを強くお勧めします。依存関係を最小限に抑えるよう努めるだけでなく、必要なビルド手順を最小限に抑えることを検討する必要もあります。これにより、フロントエンド・アプリケーションを覆っているアイソレーション型アプリケーションへのサプライ・チェーン攻撃には心配する必要がなくなります。
## アイソレーション型アプリケーションの作成
次の例では、小さな「hello-world」のようなアイソレーション型アプリケーションを作成し、それを仮に既存の Tauri アプリケーションに接続することを想定します。このアプリでは、通過するメッセージの検証は行なわれず、WebView コンソールに内容が出力されるだけです。
この事例の目的のため、`tauri.conf.json` と同じディレクトリにあると仮定します。既存の Tauri アプリケーションの `distDir``../dist` に設定されています。
`../dist-isolation/index.html`:
```html
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<title>Isolation Secure Script</title>
</head>
<body>
<script src="index.js"></script>
</body>
</html>
```
`../dist-isolation/index.js`:
```javascript
window.__TAURI_ISOLATION_HOOK__ = (payload) => {
// 何も検証や修正せず、ただ hook から内容を印字するだけです。
console.log('hook', payload);
return payload;
};
```
あとは、アイソレーション型を使用するように `tauri.conf.json` の[設定](#設定) を変更し、ブート処理経路を [ブラウンフィールド型] からアイソレーション型に切り替えるだけです。
## 設定
メインのフロントエンド `distDir``../dist` に設定されていると仮定します。また、アイソレーション型アプリケーションを `../dist-isolation` に出力します。
```json
{
"build": {
"distDir": "../dist"
},
"app": {
"security": {
"pattern": {
"use": "isolation",
"options": {
"dir": "../dist-isolation"
}
}
}
}
}
```
[transport_layer_security]: https://ja.wikipedia.org/wiki/Transport_Layer_Security
[セキュリティ:脅威モデル]: /ja/security/lifecycle/
[events]: /ja/reference/javascript/api/namespaceevent/
[subtlecrypto]: https://developer.mozilla.org/ja-JP/docs/Web/API/SubtleCrypto
[ブラウンフィールド型]: /ja/concept/inter-process-communication/brownfield/
[WebDriver との統合テスト]: /ja/develop/tests/webdriver/
<div style="text-align:right">
[※ この日本語版は、「Feb 22, 2025 英語版」に基づいています]<br />
Doc-JP 2.00.00
</div>

View File

@@ -0,0 +1,193 @@
---
title: Tauri アーキテクチャ
sidebar:
order: 0
i18nReady: true
---
## はじめに
Tauri は、非常に構築しやすく、且つ、エンジニアがさまざまなアプリケーションを作成できる、多言語対応の汎用ツールキットです。Rust のツール群と Webview でレンダリングされる HTML の組み合わせを用いて、デスクトップ・コンピューター用アプリケーションの構築に利用されます。Tauri で構築されたアプリには、JavaScript API Rust API をいくつでも同梱できるので、Webview はメッセージ・パッシング〔送受信〕機能を介してシステムを制御できます。開発者は、デフォルトの API を独自の機能で拡張し、Webview と Rust ベースのバックエンドを簡単に繋ぐことができます。
Tauri のアプリは、[トレイ型インターフェース](/ja/learn/system-tray/)(システムトレイ/タスクトレイ)が利用できます。また、アプリは [アプリの自動更新](/ja/plugin/updater/) を利用することで、期待通りに使用中のオペレーティング・システムによって管理されるようになります。OS の WebView を使用するため、アプリ・サイズは非常に小さく、最終バイナリ(アプリ実行ファイル)が Rust からコンパイルされるため、ランタイム(実行時ファイル)は提供されません。このため、[Tauri アプリの逆解析は簡単ではありません](/ja/security/)。
### Tauri は 〜ではない
Tauri は軽量のカーネル・ラッパーという訳ではありません。そうではなく、OS へのシステム・コールを実行する際に、WebView レンダリング・ライブラリーの [ライ WRY](#wryライ) とウィンドウ生成ライブラリーの [タオ TAO](#taoタオ) を直接使用して、重く手間のかかる処理を実行しています。
Tauri は バーチャル・マシンVMや仮想環境という訳でもありません。そうではなく、WebView OS アプリケーションを作成できるアプリケーション・ツールキットなのです。
## コア・エコシステム
<figure>
```d2 sketch pad=50
direction: up
Core: {
shape: rectangle
"tauri": {
"tauri-runtime"
"tauri-macros"
"tauri-utils"
}
"tauri-build"
"tauri-codegen"
"tauri-runtime-wry"
}
Upstream: {
shape: rectangle
direction: right
WRY
TAO
}
Core."tauri"."tauri-runtime" -> Core."tauri-runtime-wry"{style.animated: true}
Upstream.WRY -> Upstream.TAO{style.animated: true}
Core."tauri-runtime-wry" -> Upstream.Wry {style.animated: true}
```
<figcaption>Tauri アーキテクチャの構成略図</figcaption>
</figure>
### tauriタウリ
[GitHub で閲覧](https://github.com/tauri-apps/tauri/tree/dev/crates/tauri)
「tauri 部」がすべてをまとめる主要クレートです。ここで、ランタイム、マクロ、ユーティリティ、API を一つの最終製品にまとめます。コンパイル時に [`tauri.conf.json`](/reference/config/) ファイルを読み込み、機能の導入とアプリの実際の構成設定を(さらにはプロジェクト・フォルダー内の `Cargo.toml` ファイル設定さえも行ないます。実行時にはスクリプトの挿入を処理しpolyfill コードやプロトタイプの改訂用)、システム操作用の API をホスト(実行可能に)し、更新プロセスをも管理します。
### tauri-runtimeタウリ・ランタイム
[GitHub で閲覧](https://github.com/tauri-apps/tauri/tree/dev/crates/tauri-runtime)
「tauri-runtime」は、Tauri 本体と下位レベルの Webview ライブラリとを接合するレイヤーです。
### tauri-macrosタウリ・マクロ
[GitHub で閲覧](https://github.com/tauri-apps/tauri/tree/dev/crates/tauri-macros)
「tauri-macros」は、[`tauri-codegen`](https://github.com/tauri-apps/tauri/tree/dev/crates/tauri-codegen) クレートを活用して、コンテキスト、ハンドラー、およびコマンドのマクロを作成します。
### tauri-utilsタウリ・ユーティリティ
[GitHub で閲覧](https://github.com/tauri-apps/tauri/tree/dev/crates/tauri-utils)
「tauri-utils」は、設定ファイルの解析、動作環境三大プラットフォームの検出、CSPクラウド・サービス・プロバイダの挿入、アセットの管理など、多くの場所で再利用され、便利なユーティリティを提供する共通のコードです。
### tauri-buildタウリ・ビルド
[GitHub で閲覧](https://github.com/tauri-apps/tauri/tree/dev/crates/tauri-build)
「tauri-build」は、ビルド時にマクロを適用して、`cargo` に必要ないくつかの特別な機能を装備します。
### tauri-codegenタウリ・コードジェン
[GitHub で閲覧](https://github.com/tauri-apps/tauri/tree/dev/crates/tauri-codegen)
「tauri-codegen」は、アプリのアイコンやシステム・トレイなどを含むアセットデジタル資産を埋め込み、ハッシュ化し、圧縮します。コンパイル時に [`tauri.conf.json`](/ja/reference/config/) を解析し、Config 構造体を生成するコード生成ツールです。
### tauri-runtime-wryタウリ・ランタイム・ライ
[GitHub で閲覧](https://github.com/tauri-apps/tauri/tree/dev/crates/tauri-runtime-wry)
「tauri-runtime-wry」。このクレートは、印刷・モニター検出・その他のウィンドウ関連のタスクなど、特に WRY 用の直接的なシステム・レベルでの「対話型操作」(インタラクション)を開始します。
## Tauri Toolingタウリ・ツール
### API (JavaScript / TypeScript)
[GitHub で閲覧](https://github.com/tauri-apps/tauri/tree/dev/packages/api)
Typescript のライブラリで、`cjs`CommonJS モジュール)および `esm`ECMAScript モジュール)という JavaScript 標準入出力エンドポイントを作成して、フロントエンドユーザー・インターフェイスのフレームワークにインポートします。これにより、Webview がバックエンド(プログラム内部処理)でのアクティビティを呼び出して(コール)・応答待機(リッスン)できるようになります。また、いくつかのフレームワークではより最適な形態である、純然たる Typescript のみの形でも出荷されます。このライブラリは Webview からそれぞれのホスト(接続先)へのメッセージ・パッシング機能(処理依頼)を使用します。
### Bundler (Rust / Shell)
[GitHub で閲覧](https://github.com/tauri-apps/tauri/tree/dev/crates/tauri-bundler)
Bundlerバンドラーは、検出または通知されたプラットフォームos用の Tauri アプリを構築するライブラリです。現在は macOS、Windows、Linux をサポートしていますが、近い将来にはモバイル・プラットフォームもサポートされる予定です。Tauri プロジェクト以外でも使用できる可能性があります。
### cli.rs (Rust)
[GitHub で閲覧](https://github.com/tauri-apps/tauri/tree/dev/crates/tauri-cli)
この Rust 実行可能ファイルは、CLIコマンドライン・インターフェイスが必要なすべてのアクティビティに対する完全なインターフェースを提供します。このプログラムは macOS、Windows、Linux のいずれでも動作します。
### cli.js (JavaScript)
[GitHub で閲覧](https://github.com/tauri-apps/tauri/tree/dev/packages/cli)
cli.js は、[`napi-rs`](https://github.com/napi-rs/napi-rs) を使用して [`cli.rs`](https://github.com/tauri-apps/tauri/blob/dev/crates/tauri-cli) をどのプラットフォームosでも利用できるようにしたラッパーで、npm パッケージNode.js Package Managerを生成します。
### create-tauri-app (JavaScript)
[GitHub で閲覧](https://github.com/tauri-apps/create-tauri-app)
このツールキットは、選択したフロントエンド・フレームワークを用いて、技術チームが新しい `tauri-apps` のプロジェクトを迅速に構築できるようにするためのものです(設定が行なわれている場合)。
## 上流のクレート
Tauri-Apps の構造には、Tauri の「上流」に二つのクレート、つまりアプリケーション・ウィンドウの作成と管理を行なう「TAOタオ」と、ウィンドウ内の Webview と連動する「wryライ」を管理しています。
### TAOタオ
[GitHub で閲覧](https://github.com/tauri-apps/tao)
「Taoタオ」は、Rust のクロスプラットフォームのアプリケーション・ウィンドウ作成ライブラリで、Windows、macOS、Linux、iOS、Android など、すべての主要プラットフォームをサポートしています。Rust で書かれており、メニュー・バーやシステム・トレイなど、Tauri 独自のニーズに合わせて拡張された [winit](https://github.com/rust-windowing/winit) のフォークです。
### WRYライ
[GitHub で閲覧](https://github.com/tauri-apps/wry)
「WRYライ」は、Rust のクロスプラットフォーム WebView レンダリング・ライブラリで、Windows、macOS、Linux など主要なデスクトップ・プラットフォームをすべてサポートしています。
Tauri は WRY を抽象レイヤーとして使用し、どの Webview が使用されるか(およびどのようにインタラクション/相互交信が行なわれるか)を決定する役割を担っています。
## その他のツール
### tauri-actionタウリ・アクション
[GitHub で閲覧](https://github.com/tauri-apps/tauri-action)
tauri-action は、すべてのプラットフォーム向けの Tauri バイナリをビルドする GitHub ワークフロー自動化プロセスです。Tauri が設定されていない場合でも、非常に簡単なTauri アプリを作成できます。
### tauri-vscode
[GitHub で閲覧](https://github.com/tauri-apps/tauri-vscode)
このツールは、いくつかの「あると便利な機能」で Visual Studio Code のインターフェイスを強化します。
### vue-cli-plugin-tauri
[GitHub で閲覧](https://github.com/tauri-apps/vue-cli-plugin-tauri)
このツールを使用すると、vue-cli プロジェクトに手早く Tauri をインストールできます。
## プラグイン
[Tauri プラグイン・ガイド](/develop/plugins/)
一般的に言えば、プラグインはサードパーティによって作成されています(公式のサポートされているプラ​​グインが存在する場合もありますが)。プラグインは通常、次の三つのことを行ないます:
1. Rust のコードを「何かを行なうため」に実行可能にします
2. アプリへの統合を容易にするインターフェースのグルー機能glueを提供します
3. Rust コードとのインターフェース用 JavaScript API を提供します
以下は、Tauri のプラグイン例です:
- [tauri-plugin-fs](https://github.com/tauri-apps/tauri-plugin-fs)
- [tauri-plugin-sql](https://github.com/tauri-apps/tauri-plugin-sql)
- [tauri-plugin-stronghold](https://github.com/tauri-apps/tauri-plugin-stronghold)
## ライセンス
Tauri 自体は MIT または Apache-2.0 のライセンスの下で配布されています。あなたが Tauri を再パッケージ化してソース・コードを変更する場合、すべての上流のライセンスに準拠していることを確認する責任は、あなたにあります。Tauri は現状のまま無保証で提供され、どのような目的に対してもその適合性について明確に表明するものではありません。
こちらで、 [ソフトウェア状態 管理表](https://app.fossa.com/projects/git%2Bgithub.com%2Ftauri-apps%2Ftauri) の詳細を確認することができます。
<div style="text-align:right">
【※ この日本語版は、「Feb 22, 2025 英語版」に基づいています】
<br />
Doc-JP 2.00.00
</div>

View File

@@ -0,0 +1,45 @@
---
title: 基本設計思想
sidebar:
order: 0
label: 概要
i18nReady: true
---
import { CardGrid, LinkCard } from '@astrojs/starlight/components';
Tauri には、中核となる設計思想がいくつかあります。これらの項目はアプリケーションを開発する際に開発者が知っておくべきものです。以下が、Tauri のフレームワークを最大限に活用するために、より詳しく理解しておくべき概念です。
<CardGrid>
<LinkCard
title="Tauri アーキテクチャ"
href="/ja/concept/architecture/"
description="基本設計とエコシステム"
/>
<LinkCard
title="プロセス間通信IPC"
href="/ja/concept/inter-process-communication/"
description="プロセス間通信の内部構造"
/>
<LinkCard
title="安全性"
href="/ja/security/"
description="Tauri の安全性強化施策"
/>
<LinkCard
title="プロセス・モデル"
href="/ja/concept/process-model/"
description="Tauri が管理するプロセスとその理由"
/>
<LinkCard
title="アプリのサイズ"
href="/ja/concept/size/"
description="アプリ・サイズを最小化する方法"
/>
</CardGrid>
<div style="text-align: right">
【※ この日本語版は、「Feb 22, 2025 英語版」に基づいています】
<br />
Doc-JP 2.00.00
</div>

View File

@@ -0,0 +1,88 @@
---
title: プロセス・モデル
sidebar:
order: 0
i18nReady: true
---
Tauri は、Electronエレクトロンや多くの最新 Web ブラウザのような、マルチプロセス・アーキテクチャを採用しています。このガイドでは、こうした設計方針の選択理由と、なぜそれが安全なアプリケーションを作成する上で重要であるのかについて説明します。
## マルチプロセスである理由
GUIグラフィカル・ユーザー・インターフェースアプリケーションの初期には、計算・インターフェイスの描画・ユーザー入力への反応を一つのプロセスで実行するのが一般的でした。ご想像のとおり、このプロセスは、時間の掛かる高負荷の計算処理によってユーザー・インターフェイスが無応答のままになったり、さらに悪いことには、一つのアプリ・コンポーネントの障害がアプリ全体のクラッシュを引き起こしてしまったりすることを意味していました。
この結果、より強靭なアーキテクチャが必要であることは明らかで、アプリケーションは異なるコンポーネントを異なるプロセスで実行するようになりました。これにより、最新のマルチコア CPU をより有効に活用し、はるかに安全なアプリケーションが作成できます。各コンポーネントは異なるプロセスに分散されて実行されているため、一つのコンポーネントでクラッシュが発生しても、システム全体に影響が及ぶことはありません。プロセスが無効な状態になった場合は簡単にそのプロセスを再起動できるのです。
また、各プロセスに、そのジョブをが完了するのに必要な最小限の権限のみを付与することで、潜在的な弱点箇所の影響範囲を制限することもできます。このやり方は [最小権限の原則] として知られており、現実世界ではよく見られます。生け垣の手入れに庭師が来た場合、庭の鍵を渡しますが、家の鍵は**渡さない**でしょう(家の中への出入りは庭師には必要ないですよね)? 同じ考え方がコンピュータ・プログラムにも当てはまります。アクセス権を少なくすればするほど、侵入されたときの被害が少なくなります。
## コア・プロセス
各 Tauri アプリケーションには「コア・プロセス」があり、これがアプリケーションの「エントリ・ポイント」として機能します。コア・プロセスは、オペレーティング・システムにフル・アクセスできる唯一のコンポーネントです。
この「コア部」の第一の役割は、そのアクセス権を用いて「アプリケーション・ウィンドウ」、「システムトレイ・メニュー」、および「通知」を作成・調整することです。Tauri は、このような処理を簡単にするために必要となるクロス・プラットフォームの抽象化を実装しています。また、すべての [プロセス間通信]IPCを「コア・プロセス」経由で転送し、IPC メッセージをこの中央部分一箇所で傍受し、フィルター処理を行ない、操作できるようにします。
「コア・プロセス」は、設定やデータベースの接続のような「グローバル状態」の管理も担当する必要があります。これにより、ウィンドウ間の状態を簡単に同期し、フロントエンドで覗き見しようとする外部の不審な目からビジネス上の機密データを保護できます。
私達が Tauri の実装に Rust を選択したのは、[所有権]の概念により、
優れたパフォーマンスを維持する一方で、メモリの安全性が保証されるからです。
<figure>
```d2 sketch pad=50
direction: right
Core: {
shape: diamond
}
"Events & Commands 1": {
WebView1: WebView
}
"Events & Commands 2": {
WebView2: WebView
}
"Events & Commands 3": {
WebView3: WebView
}
Core -> "Events & Commands 1"{style.animated: true}
Core -> "Events & Commands 2"{style.animated: true}
Core -> "Events & Commands 3"{style.animated: true}
"Events & Commands 1" -> WebView1{style.animated: true}
"Events & Commands 2" -> WebView2{style.animated: true}
"Events & Commands 3" -> WebView3{style.animated: true}
```
<figcaption>Tauri プロセス・モデルの略図。一つの「コア・プロセス」が一つ以上の WebView プロセスを制御します。</figcaption>
</figure>
## WebView プロセス
「コア・プロセス」が実際のユーザー・インターフェイスUIをレンダリングしているわけではありません。オペレーティング・システムによって提供される WebView ライブラリを利用して、WebView プロセスを起動しているのです。WebView はブラウザーのような環境で、あなたが作成した HTML、CSS、JavaScript を実行しているのです。
このことはつまり、従来の Web 開発で使用されているほとんどの技法とツールが Tauri アプリケーションの作成で使用できるということです。たとえば、Tauri の参考事例の多くが、[Svelte] フロントエンド・フレームワークと [Vite] バンドラーを使用して作成されています。
セキュリティ面でも最良の方法が取られています: たとえば、ユーザー入力を常にサニタイズ(無害化)し、フロントエンドでは決して機密情報を処理しないようにし、理想的には、攻撃対象領域を小さく保つために可能な限り多くのビジネス・ロジック(業務処理手順)を「コア・プロセス」に委ねる必要があります。
他の類似した方法とは異なり、WebView ライブラリは最終的な実行可能ファイルには**含まれず**、実行時に動的にリンクされます[^1]。これにより、アプリケーションは*大幅に*小さくなりますが、従来の Web 開発と同様に、プラットフォームの違いに留意する必要があるということも意味しています。
[^1]:
現時点では、Tauri は、Windows では [Microsoft Edge WebView2] を、macOS では [WKWebView] を、
Linux では [webkitgtk] を使用しています。
[最小権限の原則]: https://ja.wikipedia.org/wiki/最小権限の原則
[プロセス間通信]: /ja/concept/inter-process-communication/
[所有権]: https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html
[microsoft edge webview2]: https://docs.microsoft.com/ja-jp/microsoft-edge/webview2/
[wkwebview]: https://developer.apple.com/documentation/webkit/wkwebview
[webkitgtk]: https://webkitgtk.org
[svelte]: https://svelte.dev/
[vite]: https://vitejs.dev/
<div style="text-align: right;">
【※ この日本語版は、「Feb 22, 2025 英語版」に基づいています】<br />
Doc-JP 2.00.00
</div>

View File

@@ -0,0 +1,77 @@
---
title: アプリのサイズ
sidebar:
order: 0
i18nReady: true
---
import { Tabs, TabItem } from '@astrojs/starlight/components';
Tauri はデフォルトで非常に小さなバイナリ・サイズになりますが、その一方で、その限界点を少し押し広げても問題はないでしょう。ここでは、最適な結果を得るためのヒントとコツをいくつか紹介します。
## Cargo の設定
作業中のプロジェクトに対して、フロントエンドに依存しないで行なえる最も簡単なサイズ改善の一つが、「Cargo プロファイル」を追加することです。
Stable 版(安定版)の Rust ツールチェーンを使用するか、Nightly 版(ナイトリー版/最新開発版)の Rust ツールチェーンを使用するかによって、利用できるオプションが若干異なります。上級ユーザーでない限り、安定版のツールチェーンを使用することをお勧めします。
<Tabs>
<TabItem label="Stable">
```toml
# src-tauri/Cargo.toml
[profile.dev]
incremental = true # Compile your binary in smaller steps.
[profile.release]
codegen-units = 1 # Allows LLVM to perform better optimization.
lto = true # Enables link-time-optimizations.
opt-level = "s" # Prioritizes small binary size. Use `3` if you prefer speed.
panic = "abort" # Higher performance by disabling panic handlers.
strip = true # Ensures debug symbols are removed.
````
</TabItem>
<TabItem label="Nightly">
```toml
# src-tauri/Cargo.toml
[profile.dev]
incremental = true # Compile your binary in smaller steps.
rustflags = ["-Zthreads=8"] # Better compile performance.
[profile.release]
codegen-units = 1 # Allows LLVM to perform better optimization.
lto = true # Enables link-time-optimizations.
opt-level = "s" # Prioritizes small binary size. Use `3` if you prefer speed.
panic = "abort" # Higher performance by disabling panic handlers.
strip = true # Ensures debug symbols are removed.
trim-paths = "all" # Removes potentially privileged information from your binaries.
rustflags = ["-Cdebuginfo=0", "-Zthreads=8"] # Better compile performance.
````
</TabItem>
</Tabs>
### 参考情報
:::note
以下のリストは、利用可能なすべてのオプションを載せた全体版ではなく、特に注目していただきたいオプションを記載したものです。
:::
- [incremental:](https://doc.rust-lang.org/cargo/reference/profiles.html#incremental) バイナリをより細かな単位毎にコンパイルします。
- [codegen-units:](https://doc.rust-lang.org/cargo/reference/profiles.html#codegen-units) コンパイル時間の最適化を犠牲にしてコンパイル時間を短縮します。
- [lto:](https://doc.rust-lang.org/cargo/reference/profiles.html#lto) リンク時の最適化を有効にします。
- [opt-level:](https://doc.rust-lang.org/cargo/reference/profiles.html#opt-level) コンパイラのフォーカス内容を決定します。「パフォーマンス」の最適化には `3` を、「サイズ」の最適化には `z` を、 その「中間」には `s` を指定します。
- [panic:](https://doc.rust-lang.org/cargo/reference/profiles.html#panic) エラー・ハンドリング時の「パニック・アンワインド」(異常・巻き戻し情報)を削除してサイズを縮小します。
- [strip:](https://doc.rust-lang.org/cargo/reference/profiles.html#strip) バイナリからシンボルまたはデバッグ情報を削除します。
- [rpath:](https://doc.rust-lang.org/cargo/reference/profiles.html#rpath) バイナリ内に必要情報を書き込む(ハード・コーディングする)ことで、バイナリに必要な動的ライブラリを見つける手助けをします。
- [trim-paths:](https://rust-lang.github.io/rfcs/3127-trim-paths.html) バイナリから部外秘の可能性がある情報を削除します。
- [rustflags:](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-rustflags-option) プロファイル毎に Rust コンパイラ・フラグを設定します。
- `-Cdebuginfo=0` ビルドに「debuginfo シンボル」を含めるかどうかを指定します。
- `-Zthreads=8`: コンパイル時に使用されるスレッドの数を増やします。
<div style="text-align: right;">
【※ この日本語版は、「Feb 22, 2025 英語版」に基づいています】
<br />
Doc-JP 2.00.00
</div>

View File

@@ -1,16 +1,16 @@
---
title: Tauri Doc 日本語版 改訂記録メモ <br> Memorundom on Doc-JP Rev Control
title: Tauri Doc 日本語版 改訂記録メモ | Memorundom on Doc-JP Rev Control
---
- Rev Status Control of Japanese Translation Documents <br> 日本語訳文書の改訂履歴メモ
- Rev Status Control of Japanese Translation Documents <br /> 日本語訳文書の改訂履歴メモ
## Basic Procedure of JP Translation邦訳基本手順
1. Use On-line Translation for the inital translation. <br>オンライン翻訳にて初期翻訳。
1. Checks on the auto-translation result. Inappropriate translations shall be corrected (such as "Tauri" - which is often translated as the name of the zodiac sign "the Bull"). <br>自動翻訳の内容確認。f不適切な訳語は修正例えば「牡牛座」と訳された "Tauri" など)。
1. Products names, trade names and proper names such as Tauri, Windows, macOS etc. are shown as they are. <br>商品名、会社名、固有名詞などは、
1. Use On-line Translation for the inital translation. <br />オンライン翻訳にて初期翻訳。
1. Checks on the auto-translation result. Inappropriate translations shall be corrected (such as "Tauri" - which is often translated as the name of the zodiac sign "the Bull"). <br />自動翻訳の内容確認。f不適切な訳語は修正例えば「牡牛座」と訳された "Tauri" など)。
1. Products names, trade names and proper names such as Tauri, Windows, macOS etc. are shown as they are. <br />商品名、会社名、固有名詞などは、
そのまま英語表記とする(必要に応じて括弧書きで「読み」を表示)。
1. The technical terms shall be checked on the on-line terminology sites (Microsoft Terminology Search, etc.) <br>技術専門用語類は、オンライン用語検索サイト(マイクロソフト社等)に記載されている一般的なものを採用するが、カタカナ語に関しては適宜和語に置き換える倍もある。
1. The technical terms shall be checked on the on-line terminology sites (Microsoft Terminology Search, etc.) <br />技術専門用語類は、オンライン用語検索サイト(マイクロソフト社等)に記載されている一般的なものを採用するが、カタカナ語に関しては適宜和語に置き換える倍もある。
## Rev Numbering System Configuration: x.xx.xx
@@ -20,9 +20,9 @@ Example Numbering番号体系例 2.00.01
- Middle Digits中央の二桁= English Doc Status: "00" --> EN Doc Status #00(英語版文書番号)
- Last Digits最後の二桁 = JP Doc Status: "01" --> JP Doc Status #01(日本語文書番号)
For the details of EN/JP doc status, see the listing below: <br> 文書番号の詳細は以下のリストを参照して下さい。
For the details of EN/JP doc status, see the listing below: <br /> 文書番号の詳細は以下のリストを参照して下さい。
**NOTE** This Rv Control number is for JP translation purpose only and does not necessarily represent the actuarl revision history of each document.<br>
**NOTE** This Rv Control number is for JP translation purpose only and does not necessarily represent the actual revision history of each document.<br />
**《注意》** この変更履歴番号は、日本語翻訳管理用であり、各文書の実際の変更履歴を反映しているものではありません。
## EN/JP Doc Status listEN/JP 文書簡易比較表)
@@ -97,7 +97,7 @@ For the details of EN/JP doc status, see the listing below: <br> 文書番号の
| :------: | :---------- | :------: | :---------- |
| **00** | 2024/11/01 | **00** | 2025/01/07 |
#### frontend/sveltekit.
#### frontend/sveltekit.mdx
| EN Doc # | EN Doc Date | JP Doc # | JP Doc Date |
| :------: | :---------- | :------: | :---------- |
@@ -139,42 +139,42 @@ For the details of EN/JP doc status, see the listing below: <br> 文書番号の
| EN Doc # | EN Doc Date | JP Doc # | JP Doc Date |
| :------: | :---------- | :------: | :---------- |
| **00** | 2024/10/01 | **00** | 2025/02/05 |
| **00** | 2025/02/22 | **00** | 2025/03/07 |
### concept/architecture.mdx
| EN Doc # | EN Doc Date | JP Doc # | JP Doc Date |
| :------: | :---------- | :------: | :---------- |
| **00** | 2024/11/11 | **00** | 2025/01/15 |
| **00** | 2025/02/22 | **00** | 2025/03/06 |
### concept/process-model.mdx
| EN Doc # | EN Doc Date | JP Doc # | JP Doc Date |
| :------: | :---------- | :------: | :---------- |
| **00** | 2024/10/01 | **00** | 2025/01/16 |
| **00** | 2025/02/22 | **00** | 2025/03/06 |
### concept/size.mdx
| EN Doc # | EN Doc Date | JP Doc # | JP Doc Date |
| :------: | :---------- | :------: | :---------- |
| **00** | 2024/10/01 | **00** | 2025/01/16 |
| **00** | 2025/02/22 | **00** | 2025/03/07 |
### concept/I-P-C/index.mdx
| EN Doc # | EN Doc Date | JP Doc # | JP Doc Date |
| :------: | :---------- | :------: | :---------- |
| **00** | 2024/11/27 | **00** | 2025/01/18 |
| **00** | 2025/02/22 | **00** | 2025/03/07 |
### concept/I-P-C/brownfield.md
| EN Doc # | EN Doc Date | JP Doc # | JP Doc Date |
| :------: | :---------- | :------: | :---------- |
| **00** | 2024/10/01 | **00** | 2025/01/18 |
| **00** | 2025/02/22 | **00** | 2025/03/07 |
### concept/I-P-C/isolation.md
| EN Doc # | EN Doc Date | JP Doc # | JP Doc Date |
| :------: | :---------- | :------: | :---------- |
| **00** | 2024/10/15 | **00** | 2025/01/27 |
| **00** | 2025/02/22 | **00** | 2025/03/09 |
Cont.