「2000字以内」と「原稿用紙2000字相当」は、同じ数え方ではありません。テキストエディタ 文字数を確認するときは、まず入稿先が求める単位を読みます。Rune Studioの公開資料には「全角1・半角0.5」と生の文字数を使い分ける表示が記載されています。一方、今回の実測はCLIで読み戻した24文字と、明示式から独立再計算した14.0だけです。本文はアプリ画面が14.0を表示したとは主張せず、読者が自分のMacで確かめる手順までを分けて説明します。
24文字を「原文」と「計算対象」に分ける
検証に使ったのは、UTF-8・LFの短い合成ファイルです。SHA-256はfc82d74efa90d066f6b7786e6a15a8f24e9e16631381e32edce67829ae0999ea、読み取った生文字数は改行を除いて24でした。この24を先に固定しないと、あとで計算式が合っても、違う文を数えた可能性が残ります。
作業票の左側に実際の24文字、右側に文字ごとの分類を書きます。ここでの「半角」は見た目の細さではなくASCIIかどうかという、今回の再計算の定義です。半角カナや結合文字を別ルールで数える入稿先には、この式をそのまま渡せません。
14.0は画面から拾った数字ではない
分類表の非ASCII件数をF、ASCII件数をHとし、F + H × 0.5を計算した結果が14.0でした。この値は固定標本を独立に再計算した結果です。Rune Studioの現行Mac版に文字数の表示機能があることは公開資料で確認できますが、このCLI試験では「全角1・半角0.5」のグラフィカル表示を操作していません。
つまり、証拠欄に書けるのは「raw characterCount=24」と「明示式での再計算=14.0」までです。「Rune Studio画面が14.0と表示した」とは書けません。画面を確かめる読者は、同じSHAの標本を現行Mac版で開き、選択を解除した状態で生文字数と換算値を記録します。次に改行を含む範囲と含まない範囲を別々に選び、IMEの未確定文字がないことを確かめて値を採取します。画面名、アプリ版、選択範囲、表示単位を一組で残し、14.0と異なる場合はその値を保持して公開資料の分類規則と再照合します。
数がずれたら原稿ではなく三つの分類を疑う
第一の原因は改行の数え込みです。第二はASCIIか非ASCIIかの分類違い、第三は0.5単位の丸め方です。ずれた数字を見て本文を削る前に、同じ24文字からこの三点を再計算します。入力文を変えると、計数ルールの誤りを内容修正で覆い隠してしまいます。
復旧試行は別の計算票にし、元の14.0を消しません。分類ごとの件数、計算式、結果を並べ、どこを変えたかを一つにしぼります。同じ24文字から同じ14.0を作れるまで、本番原稿へ広げません。
入稿先へは「14.0字」だけを渡さない
納品表には、対象SHA、文字の分類定義、改行の除外、式、結果14.0を一組で書きます。相手の規定が「Unicodeコードポイント数」なのか「原稿用紙換算」なのかも付記します。それがなければ、同じ14.0という数字でも別の意味に読まれます。
受入条件は、別担当者が同じ標本と24を読み、同じ定義で14.0を得られることです。未実測のUIは空欄のまま残します。数が再現でき、その数が何を数えているかを言葉で説明できれば、この換算試験は合格です。
URLや品番が増えた版は別の試行にする
本番原稿で半角相当の要素が増えるのは、URL、ISBN、品番、英数字の見出しなどです。標本の式が通ったからといって、別の原稿に14.0の比率をそのまま乗せてはいけません。実原稿のSHAを取り、同じASCII境界で文字ごとに数え、未分類の文字を0件にします。
特に全角英数字は見た目だけで半角に分類しないよう注意します。まずコードポイントで非ASCIIとして扱い、入稿先が別の「幅」定義を持つときだけ、その仕様の比較表を作ります。
選択範囲の数え方も独立した条件にする
エディタにはファイル全体と選択範囲の両方を数える設計があり得ます。画面実測では選択前の全体値、選択した冒頭語と末尾語、選択後の値を分けます。IMEの未確定文字が選択内にある場合は確定後にもう一度取得し、入力中の表示を納品値にしません。
今回の24と14.0はファイル固定標本の計算であり、選択表示の試験ではありません。対象を書かない数字は流用できないという原則を守れば、全体と選択範囲を取り違えずに済みます。
改行コードを変えた比較版で境界を確かめる
行区切りを除外する規則は、単に「改行は数えない」と書くだけでは再現できません。LF版とCRLF版を別ファイルにし、本文24文字が同一で、ファイルのバイト列とSHAだけが異なる比較票を用意します。両方から区切りを除いた計算が14.0になるなら、式が改行コードのバイト数を文字量へ混ぜていないことを確かめられます。
もしCRLF版だけ0.5または1.0増えたら、その失敗値を残し、読み込み時にCRとLFを二つの文字として分類していないかを調べます。復旧は原稿の改行を消すことではありません。区切りを計算対象から外す実装または集計表へ直し、同じ二つの入力を再実行します。本文文字数24、換算14.0が両方で一致したら合格です。
ただし今回の保存済み実測はLF標本一つです。CRLF比較は次回の検証手順であり、すでに一致を観測したとは扱いません。実施後は二つのSHA、物理バイト数、区切り件数、分類件数を同じ記録に載せます。
納品値は原稿版と一対一にする
換算後に一文字でも校正したら、14.0という値をそのまま添付しません。保存後の原稿を再読込して新しいSHAを取り、24という生文字数から更新します。計算票の版番号と原稿の版番号が一致しない場合は、数値が妥当に見えても受入不可です。
この運用により、計数の後でURLを追加した、末尾の空白を削除した、見出しを英数字へ変えた、といった小さな編集も追跡できます。最終票は入力、除外条件、分類、式、結果の五点を一組にし、未実測の画面値を混ぜずに引き渡します。