Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

to_typed_array_spec encodes bdata in host byte order; plotly.js always decodes it as little-endian

未关闭 适合新手
  • 哪里不对？
#5,837 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 3 天内回复

@Vikram12301 已经在做这个了。

开始于 2026年10月22日。

  • #5838 来自 @Vikram12301 —— 未关闭

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
79/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
numpy, python
领域
backend, data-visualization

调研方向

从 _plotly_utils/utils.py 中的 to_typed_array_spec（约第 84 行）开始，追踪数组 dtype 的选择方式以及字节的编码方式。检查 little endian 和 big endian 数组的行为，包括提供的复现示例。完成标准是：编码后的数据按 little-endian 解码后得到原始数值，并且有一个回归测试覆盖所报告的情况。

由索引模型根据 Issue 内容生成。

描述

Summary

to_typed_array_spec (_plotly_utils/utils.py:84) does:

arrObj = {
    "dtype": plotlyjsShortTypes[dtype],
    "bdata": base64.b64encode(v).decode("ascii"),
}

with no explicit byte-order normalization before encoding, so bdata follows whatever byte order the array's dtype naturally has, which for an array built without an explicit </> prefix is the host's native order.

plotly.js decodes bdata with new Float64Array(buffer), which always reads in the platform's native order, little-endian in every real browser. On a big-endian host, this means bdata ships bytes that no browser can read correctly.

Repro (confirmed on real big-endian hardware: z/OS/s390x, numpy 2.5.3)

Through the actual function, not just a standalone simulation:

import numpy as np
from _plotly_utils.utils import to_typed_array_spec

v = np.array([1.1, 2.3, 3.5])
spec = to_typed_array_spec(v)
print(spec)

import base64
raw = base64.b64decode(spec["bdata"])
as_little = np.frombuffer(raw, dtype="<f8")  # what plotly.js's Float64Array reads
print("decoded as browser Float64Array would read it:", as_little)
print("matches original:", np.array_equal(v, as_little))

Output:

{'dtype': 'f8', 'bdata': 'P/GZmZmZmZpAAmZmZmZmZkAMAAAAAAAA'}
decoded as browser Float64Array would read it: [-1.54234871e-180  1.90359857e+185  1.54938987e-320]
matches original: False

So any big-endian host produces charts with silently corrupted numeric data.

Suggested fix

Normalize v to little-endian before encoding, e.g. v = v.astype(v.dtype.newbyteorder("<")) immediately before the base64.b64encode(v) call. Verified this resolves it on the same hardware:

v_fixed = v.astype(v.dtype.newbyteorder("<"))
bdata_fixed = base64.b64encode(v_fixed).decode("ascii")
raw_fixed = base64.b64decode(bdata_fixed)
as_little_fixed = np.frombuffer(raw_fixed, dtype="<f8")
print(np.array_equal(v, as_little_fixed))  # True

Originally spotted by @chrikrah in #5833;

主要语言
Python
星标
18.9k
派生
2.9k
平均合并
5 天 1 小时
30 天内合并 PR
14

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

plotly/plotly.py 的其他 Issue

查看 plotly/plotly.py 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。