fix: write and read figure JSON as UTF-8

[LukeTheoJohnson]

Problem

pio.write_json(fig, path) raises UnicodeEncodeError for a figure whose text contains a character outside the platform's default codec, on platforms whose default text encoding is not UTF-8. On Windows the default is cp1252:

import plotly.graph_objects as go
import plotly.io as pio

fig = go.Figure(layout_title_text="μ 中文")   # Greek mu + CJK
pio.write_json(fig, "fig.json")
# UnicodeEncodeError: 'charmap' codec can't encode character 'μ'
#                     in position ...: character maps to <undefined>

read_json has the matching bug: it reads the file without specifying an encoding, so a UTF-8 JSON file is decoded with the platform codec (cp1252) and the text comes back mangled — or raises UnicodeDecodeError on byte sequences cp1252 leaves undefined. This works on macOS/Linux only because their default encoding is already UTF-8.

What actually triggers it

Two conditions both have to hold, which is why it is easy to miss:

1. The text contains a character that is not in the platform codec. Latin-1 accents and common symbols are inside cp1252 — é, ö, °, the micro sign µ (U+00B5), the em-dash — so they do not raise. It takes a character outside cp1252, such as Greek μ (U+03BC), CJK (中文), or an emoji, to trip it.
2. The active engine is orjson (the default when orjson is installed). orjson emits real UTF-8, so the string handed to write_text still contains the non-ASCII characters. The pure-Python json engine uses ensure_ascii=True, escaping everything to \uXXXX, so its output is pure ASCII — it never trips the codec on write and reads back cleanly.

Root cause

plotly/io/_json.py opened the file without an encoding on both sides:

• write_json: path.write_text(json_str)
• read_json: path.read_text()

write_html already does this correctly (path.write_text(html_str, "utf-8")), and the same class of bug was previously fixed for HTML output (#3898). The JSON I/O path was simply missed.

Fix

Pass "utf-8" explicitly in both write_json and read_json, matching write_html. JSON is UTF-8 by default per RFC 8259.

- path.write_text(json_str)
+ path.write_text(json_str, "utf-8")
...
- json_str = path.read_text()
+ json_str = path.read_text("utf-8")

Verification

On Windows (locale.getpreferredencoding(False) → cp1252, orjson installed):

• Before: write_json of a figure titled μ 中文 raises UnicodeEncodeError: 'charmap' codec can't encode character 'μ'.
• After: the same figure writes, and read_json returns the original title unchanged.
• Updated test_write_json_pathlib / test_read_json_from_pathlib assert the "utf-8" argument is passed; both fail on the unpatched source and pass with the fix.
• tests/test_io/test_to_from_json.py otherwise shows only the pre-existing FigureWidget ImportErrors (anywidget not installed) — no new regressions.

Scope

Two-line source change plus test assertions. No behavior change on platforms that already default to UTF-8, or when the json engine is in use.

[eeshsaxena]

This looks correct to me - JSON is UTF-8 per RFC 8259, and pinning the encoding on both the write and read path fixes the round-trip on cp1252/Windows. I confirmed the pathlib signatures line up:

• Path.write_text(self, data, encoding=None, ...) -> write_text(json_str, "utf-8") sets encoding="utf-8" ✓
• Path.read_text(self, encoding=None, ...) -> read_text("utf-8") sets encoding="utf-8" ✓

so both calls do what's intended, and scoping the change to the pathlib branch (leaving the file-object else branch to the caller's own encoding) is the right call. The symmetric write/read test assertions are a nice touch.

One small consistency suggestion: write_html already sets this via the keyword form - bundle_path.write_text(get_plotlyjs(), encoding="utf-8") in plotly/io/_html.py. Using encoding="utf-8" here too (rather than the positional "utf-8") would match that existing house style and reads a bit more clearly, especially for read_text where encoding is the first positional arg. Purely cosmetic - the behaviour is already correct.

Deferring to the maintainers for the final review.