V8 Node v24.15.0, V8 13.6.233.17 上でパーサーを実行して確認しました。
Unterminated string in JSON at position N (line L column C)
パーサーは開きのダブルクォートを読み、対応する閉じ引用符を見つけないまま入力の末尾に達しました。報告される位置は文字列が始まった場所です。それが役に立つ位置だからです。存在しない閉じ引用符には、そもそも位置がありません。
JSONを貼り付けて、壊れている箇所を正確に確認する
入力
貼り付けたものがブラウザの外に出ることはありません。 connect-src の許可リストにより、これは約束ではなくブラウザによる保証になっています。 自分で確かめる
実際の原因
どれが答えになることが多いか、その順に並べています。
-
01 値の中にあるエスケープされていないダブルクォート
内側の最初の引用符が文字列を終わらせ、そのあとに続くものがパーサーを混乱させます。「JSONは妥当に見えるのに妥当でない」典型例です。
壊れる例
{ "note": "she said "hello"" }動く例
{ "note": "she said \"hello\"" } -
02 末尾のバックスラッシュ
バックスラッシュで終わるWindowsのパスは閉じ引用符をエスケープしてしまい、文字列がドキュメントの残り全体へ流れ込みます。
壊れる例
{ "dir": "C:\logs\" }動く例
{ "dir": "C:\\logs\\" } -
03 本当に引用符が抜けている
場所さえ分かれば直すのは簡単です。行と列はまさにそのためにあります。
-
04 文字列の途中でファイルが切れている
接続の切断や、値の途中でドキュメントを断ち切ったサイズ制限などです。
ほかのランタイムでの同じ間違い
根本にある問題は同一で、違うのは文言だけです。同僚がこれらのどれかを報告してきたなら、見ているものはあなたと同じです。
| Python | Unterminated string starting at: line 1 column 6 (char 5) |
|---|
よくある質問
- なぜ位置が文字列の先頭を指すのですか？
- そこが問題を診断できる場所だからです。パーサーが異常に気づくのは入力を使い切ったときで、それは数千文字先かもしれません。開きの引用符を指し示すことで、どの文字列を見ればよいかが分かります。