view release on metacpan or  search on metacpan

RIPGREP-STUDY.md  view on Meta::CPAN

### 3.1 `--json` 出力（実測確認済み）

```json
{"type":"match","data":{"path":{"text":"sample.txt"},
 "lines":{"text":"foo 高速 bar\n"},"line_number":1,"absolute_offset":0,
 "submatches":[{"match":{"text":"高速"},"start":4,"end":10}]}}
```

- `absolute_offset` は行頭の絶対バイトオフセット、`submatches` の `start/end` は行内バイトオフセット。
- **トランスコード時（`-E euc-jp` や BOM 検出時）のオフセットは、変換後 UTF-8 バイト列基準**
  （EUC-JP ファイルで実測確認: `高速` → start:4, end:10 = UTF-8 バイト位置）。
  `--pre` フィルタや解凍も同様に変換後基準。
- 非 UTF-8 データは base64（`bytes` キー）で表現される。

したがって「rg の出すオフセットは常に UTF-8 バイト単位」とみなせ、greple の文字オフセットへの
変換は数学的には整合的に定義できる（オフセットは昇順に届くので O(N) の一回走査で変換可能）。
**位置変換そのものは技術的障害ではない**。障害は次節以降で述べるコスト構造にある。

### 3.2 案 B の実測: JSON 経由のオーバーヘッド