V8 Node v24.15.0, V8 13.6.233.17 上でパーサーを実行して確認しました。
Unexpected non-whitespace character after JSON at position N (line L column C)
JSONドキュメントが持てるトップレベルの値はちょうど1つです。パーサーは完結した値を1つ読み終えたあとで、その後ろに別のものを見つけました。報告される位置は余分な内容が始まる場所であり、たいていは2件目のレコードの先頭です。
JSONを貼り付けて、壊れている箇所を正確に確認する
入力
貼り付けたものがブラウザの外に出ることはありません。 connect-src の許可リストにより、これは約束ではなくブラウザによる保証になっています。 自分で確かめる
実際の原因
どれが答えになることが多いか、その順に並べています。
-
01 入力がNDJSONまたはJSON Lines
1行に1つの完結したJSON値が並び、カンマも全体を包む配列もありません。ログのパイプライン、BigQueryのエクスポート、Elasticsearchのbulk操作、ストリーミングのLLM APIが使う形式です。壊れたJSONではなく、1行ずつ読むべき別の形式です。
壊れる例
{"event":"login"} {"event":"logout"}動く例
const records = text .split('\n') .filter((line) => line.trim()) .map((line) => JSON.parse(line)); -
02 2つのレスポンスが連結された
置き換えずに追記してしまったリトライや、2つのチャンクを区切らずにつないでしまったストリームの読み取りなど。
-
03 デバッグ出力がボディに追記された
消し忘れたprint、出力された警告、あるいはJSONのあとに書き出されたプロファイリング結果など。ドキュメントは余分なテキストが始まる直前まで問題なくパースでき、位置が指しているのはまさにその地点です。
-
04 値が二重エンコードされている
JSONを含むJSON文字列を、1回少なく、あるいは1回多く展開してしまった場合です。当サイトのアンエスケープツールは、値が何重にエンコードされているかを検出します。
ほかのランタイムでの同じ間違い
根本にある問題は同一で、違うのは文言だけです。同僚がこれらのどれかを報告してきたなら、見ているものはあなたと同じです。
| Python | Extra data: line 2 column 1 (char 8) |
|---|---|
| Firefox | JSON.parse: unexpected non-whitespace character after JSON data |
よくある質問
- 自分のファイルがNDJSONかどうか、どう見分けますか?
- 空でない各行がそれ単体で完結したJSONとしてパースでき、レコード間にカンマがなく、全体を包む[ ]もありません。当サイトのバリデーターに貼り付ければそう伝えたうえで、レコードを配列にまとめる操作も提案します。
- 角括弧で囲んでカンマを足すだけではだめですか?
- それでも構いませんし、小さなファイルならそれが一番早い直し方です。大きなファイルでは1行ずつ読むほうがメモリ使用量がはるかに少なく、そもそもこの形式が存在する理由もそこにあります。