「、」が行頭に落ちた — Rork が組んだ名言カードと日本語の禁則処理

WORD JOINER で折り返し位置そのものを封じる

プラットフォームの設定を頼るのをやめました。禁則が必要な箇所に、改行してはいけないという情報を文字列自身へ埋め込む方針に変えています。

使うのは U+2060 WORD JOINER です。幅ゼロで、その位置での改行を禁止します。

よく使われる U+200B ZERO WIDTH SPACE は逆の意味（改行してよい位置）なので、ここでは誤りになります。また、 （U+00A0）は幅を持ってしまうため、日本語の約物の前に入れると字間が空きます。

// kinsoku.ts
const WJ = "⁠"; // WORD JOINER: 幅ゼロ・改行禁止
 
const LINE_START_FORBIDDEN =
  "、。，．・：；？！ヽヾゝゞ々ー’”）〕］｝〉》」』】…‥" +
  "ぁぃぅぇぉっゃゅょゎァィゥェォッャュョヮヵヶ";
 
const LINE_END_FORBIDDEN = "‘“（〔［｛〈《「『【";
 
// 結合が長く続くと1語扱いになり、はみ出しや極端な行長を生む。上限を設ける
const MAX_BIND_RUN = 4;
 
export function applyKinsoku(input: string): string {
  const chars = Array.from(input); // サロゲートペアを壊さない
  let out = "";
  let run = 0;
 
  for (let i = 0; i < chars.length; i++) {
    const cur = chars[i];
    const next = chars[i + 1];
    out += cur;
 
    if (next === undefined) break;
    if (cur === "\n" || next === "\n") { run = 0; continue; }
 
    const bind =
      LINE_START_FORBIDDEN.includes(next) || LINE_END_FORBIDDEN.includes(cur);
 
    if (bind && run < MAX_BIND_RUN) {
      out += WJ;
      run += 1;
    } else {
      run = 0;
    }
  }
  return out;
}

MAX_BIND_RUN は実測から入れました。上限なしで実装したとき、「……」「!?」「』」が連続する箇所で7文字が1語として扱われ、狭い幅ではみ出しました。4に置いたのは、120本のうち最長の禁則連続が3文字だったためです。

Array.from を使っているのは、絵文字や異体字セレクタを含む引用文でインデックスが壊れないようにするためです。for (let i = 0; i < input.length; i++) にすると、サロゲートペアの途中に WORD JOINER が入り、文字が化けます。これは実際に一度やりました。

コピペと読み上げを壊さないための一手間

ここが一番の落とし穴でした。

WORD JOINER は不可視です。ユーザーがカードの文言を長押しコピーして SNS に貼ると、見えない文字が付いていきます。多くのアプリでは無害ですが、検索フィールドに貼られると一致しなくなります。

さらに VoiceOver は、埋め込んだ文字列をそのまま解釈しようとします。表示用と意味用を分けるのが正解でした。

// QuoteCard.tsx
import { Text } from "react-native";
import { applyKinsoku } from "./kinsoku";
 
export function QuoteCard({ quote }: { quote: string }) {
  return (
    <Text
      style={{ fontSize: 22, lineHeight: 36 }}
      lineBreakStrategyIOS="push-out"   // 事前結合の取りこぼしを拾う保険
      textBreakStrategy="balanced"      // Android 側の行長を均す
      accessibilityLabel={quote}        // 読み上げには原文をそのまま渡す
    >
      {applyKinsoku(quote)}
    </Text>
  );
}

accessibilityLabel に原文を渡す。この一行を入れるまで、VoiceOver の読み上げに不自然な間が入っていました。

コピー機能を自前で持っている場合は、Clipboard.setStringAsync(quote) のように原文を渡します。表示している文字列を渡してはいけません。

共有画像を生成している箇所も同じです。私のアプリでは react-native-view-shot でカードを画像化していますが、画像化の経路は表示文字列のままで問題ありません。テキストとして外へ出る経路だけを原文に戻す、という切り分けです。

いつ適用するか — 実行時か、ビルド時か

applyKinsoku は文字列長に比例するだけの処理です。120文字程度なら計測上0.1ms未満で、実行時に呼んで支障はありませんでした。

それでもビルド時に寄せた理由が2つあります。

ひとつは、名言データが JSON で配信されていて、端末側のロジック更新には App Store と Google Play の審査が挟まること。禁則テーブルの一文字を直したいだけで審査を待つのは、避けたいところでした。

もうひとつは、監査を CI に置けることです。配信前に違反ゼロを確認できれば、実機で気付く事態そのものが消えます。

// scripts/kinsoku-build.mjs — 配信前にJSONへ適用し、結果を検証する
import { readFileSync, writeFileSync } from "node:fs";
import { applyKinsoku } from "../src/text/kinsoku.js";
 
const WJ = "⁠";
const src = JSON.parse(readFileSync("data/quotes.ja.json", "utf8"));
 
const out = src.map((q) => ({
  ...q,
  // 表示用と原文を両方持たせる。原文はコピー・読み上げ・検索に使う
  bodyRaw: q.body,
  body: applyKinsoku(q.body),
}));
 
// 冪等性の確認: 二重適用でWJが増えないこと
const doubled = out.filter((q) => applyKinsoku(q.body) !== q.body);
if (doubled.length > 0) {
  throw new Error(`二重適用で差分が出ました: ${doubled.length}件`);
}
 
// サロゲートペア破壊の検出
const broken = out.filter((q) => q.body.replaceAll(WJ, "") !== q.bodyRaw);
if (broken.length > 0) {
  throw new Error(`WJ除去で原文に戻りません: ${broken.length}件`);
}
 
writeFileSync("data/quotes.ja.json", JSON.stringify(out, null, 2));
console.log(`適用: ${out.length}件`);

冪等性のチェックは、実際に事故を防いでくれました。パイプラインを組み直した際にスクリプトが二度走り、WORD JOINER が重なった状態のデータが出来ています。表示は変わらないので気付けません。「二重適用で差分が出ないこと」を条件にすれば、そこで止まります。

body.replaceAll(WJ, "") === bodyRaw の検証も同様です。これが通れば、少なくとも原文は無傷だと言い切れます。

Rork Max（SwiftUI 生成）ではどうなるか

Rork Max の生成コードでも同じカードを組んでみました。

SwiftUI の Text は TextKit 2 の経路を通るため、React Native よりも素直に禁則が効きます。読点・句点・閉じ括弧はほぼ行頭に落ちません。

ただし完全ではありませんでした。長音符「ー」は同じように落ちます。押し出しを明示すると解消します。

// QuoteText.swift — 段落スタイルで押し出しを明示する
import SwiftUI
 
struct QuoteText: View {
    let quote: String
 
    var body: some View {
        Text(attributed)
            .font(.system(size: 22))
            .lineSpacing(14)
            .accessibilityLabel(quote) // 読み上げは原文
    }
 
    private var attributed: AttributedString {
        var a = AttributedString(quote)
        let style = NSMutableParagraphStyle()
        style.lineBreakStrategy = .pushOut  // 押し出しで禁則を回避
        style.lineBreakMode = .byWordWrapping
        a.paragraphStyle = style
        return a
    }
}

lineBreakStrategy = .pushOut は、禁則対象が行頭に来る場合に前の文字ごと次行へ送ります。行数が増えることがあるので、行数固定のカードでは minimumScaleFactor との併用を検討する必要があります。

React Native 版と Rork Max 版で挙動が違う。この差は、両方を運用する場合に効いてきます。

Rork Max を使うなら禁則の面倒は減ります。React Native 版を選ぶなら、文字列側で解く前提を最初から持っておくほうが安全でした。

段階的に入れた手順

6本のアプリへ一度に入れるのは避けました。個人開発で並行運用していると、判断を誤ったときの巻き戻しが6回分になります。順序はこうです。

1. 監査だけを先に入れる（onTextLayout で違反を計測し、開発ビルドでのみ console.warn）。数字が出るまで実装しない
2. 1本のアプリ・日本語のみに事前結合を適用し、実機4幅で目視確認する
3. CI に冪等性と原文一致の検証を追加する。ここを飛ばすと二重適用に気付けない
4. accessibilityLabel とコピー経路を原文へ戻す。VoiceOver で1本読み上げて確認する
5. 残り5本へ展開し、MAX_BIND_RUN の上限に触れる文言がないか監査ログで見る

3番を2番より後に置いたのは順序として失敗でした。適用を先にしたため、二重適用のデータを一度配信しています。表示は正常なので、監査を書いてから初めて気付きました。検証を先に置いてから適用するほうが確実です。

中国語・韓国語を含む場合

私のアプリは16言語対応なので、この点も確認しました。

禁則テーブルは言語ごとに違います。日本語のテーブルを中国語へそのまま当てると、簡体字の約物は全角の位置調整が別ルールのため、意図しない結合が起きます。

言語コードで分岐して、日本語以外は素通しにしました。

export function applyKinsokuFor(locale: string, input: string): string {
  // 日本語以外は各プラットフォームの既定に委ねる
  if (!locale.startsWith("ja")) return input;
  return applyKinsoku(input);
}

韓国語は単語間にスペースがあるため、そもそも折り返し位置の問題が起きにくい構造でした。中国語は独自テーブルが必要ですが、私のアプリでは中国語圏の名言が短文中心で違反が観測されなかったため、今回は対象外としています。必要になったら測ってから足す方針です。

多言語の扱い全般については、翻訳の抜けとフォールバック設計にまとめています。右横書きの言語を含む場合はアラビア語対応で踏んだ RTL の落とし穴のほうが近いはずです。

生成されたコードの、その先

Rork が組んだ画面は正しく動いていました。バグではありません。

日本語として読めるかどうかは、フレームワークの守備範囲の外にあります。動くことと、読めること。この二つは別の基準です。

生成されたコードをそのまま出すか、一度日本語の目で見るか。その差が、名言カードのような「文字そのものが商品」の画面では大きく出ます。

まず onTextLayout の監査を1本入れて、自分のアプリの違反率を測ってみてください。数字が出れば、直すかどうかは自然に決まります。

私自身、iPhone SE の実機が手元になければ、しばらく気付かないままでした。実装の参考になれば幸いです。