JSONを読めたら表示してよい？文字列を文字列のまま扱うための確認手順

JSONの取り込みに成功したことと、その中身を画面に表示してよいことは別です。取り込み機能を作るときは、入力の形式だけでなく、最後にどの仕組みで表示するかまで確認します。ここでは、装飾を残しながら入力を文字列として扱う判断と、確認に使える小さな手順をまとめます。

形式を読めたことは、表示内容の保証ではない

JSON.parse が確認するのはJSONとして読めるかどうかです。値に山括弧や引用符が含まれること自体は異常ではありません。商品名、メモ、ファイル名にも記号は入ります。その文字をHTMLの組み立てに使うと、データとして読んだものを、別の文法でもう一度解釈させることになります。

JSON.stringify で文字列へ戻しても、HTML向けに安全な表示へ変わるわけではありません。JSON、HTML、コマンドの文字列は、それぞれ別の文法です。「一度エスケープしたから全部に使える」と考えないことが出発点になります。

表示をすべて一枚のテキストにすれば単純ですが、見出しや注意書きの強調まで失います。そこで、作者が決めた構造と、利用者から受け取る文字列を分けます。見出しや枠はコード側で作り、値はその中へテキストとして置きます。

例えば、要素を作ったあとに label.textContent = value とすれば、値はHTMLではなく文字として表示されます。複数の区画が必要なら、要素を分けて追加します。テキストを表示するだけの場所でHTML文字列を組み立てないほうが、後から読んだ人にも意図が伝わります。

既存のテンプレートに強調タグがあり、構造を保ちたい場合は、入力由来の値だけをHTMLのテキスト文脈に合う形へ変換します。ただし、この変換をURLやイベント属性、コマンドへ使い回すことはできません。適切な方法は、値を置く場所ごとに決める必要があります。

変更後は、表示の安全性と、普段の使い方を分けて確認します。記号を消してしまえば問題が見えなくなることがありますが、それでは利用者のデータも変わります。画面で読めること、コピーやテキスト保存でも元の文字が残ることが大切です。

確認は架空のデータで行います。本物のトークンや機密ファイルをテストへ持ち込む必要はありません。入力の種類を一つずつ変えると、どの表示経路が原因なのかも切り分けやすくなります。

「この一行を安全にして」だけだと、同じ値が別の場所へ出る経路を見落としやすくなります。私が指示で重視するのは、入力を読むところから表示・保存までを追い、同じ値を使う場所を確認することです。

指示の例：入力の読み込みから表示までを追ってください。利用者の文字列は文字列として保持し、既存の見出しと強調は残してください。通常の入力、記号、日本語、繰り返し取り込み、テキスト出力をそれぞれ確認してください。

小さな機能でも、読み込み、変換、表示、出力の順に境界を分けると、確認項目がはっきりします。「変な文字を消す」ではなく、「受け取った文字を、別の意味に変えずに渡す」。この方針は、特定のツールに限らず使えます。