gowy222

> 这确实是个问题，还得好好研究一下 > […](#) 官方回复: you'll have to build ONNX Runtime from source, since the prebuilt binaries target the (dynamically linked) GNU libc. 大佬，musl 彻底编译一个onnx?

@86maid 大佬参考下 https://github.com/RapidAI/OnnxruntimeBuilder

大佬有空参考下..    

> 这个 main 函数只是一个简单的例子，达到抛砖引玉的效果，写的比较粗糙 > […](#) 曾经一直想着有机会精简构建产物size，今天看到了rust版本，大佬+1

Updating nodejs to 20+ LTS (fro now v20.9.0) fixed the issue, THX! @climba03003 You chose to close this issue later because it seems that others haven't solved it yet :p

不是nginx的bug，是admin_api get返回的商品数据结构和put更新产品的数据结构完全不统一导致的， https://github.com/beikeshop/beikeshop/blob/master/beike/Admin/Http/Resources/ProductResource.php 这个里面get 商品信息的时候为何需要做一次转换？ 返回的: ``` { "product": { "id": 868, "name": "test123", "description": "test222", "meta_title": "", "meta_keywords": "", "meta_description": "", "brand_id": 0, "brand_name": "", "video": "", "images": [...

的确是接口bug， get请求返回的字段丢失很多，尤其是商品名称，默认只有英文的 参考默认初始化示范商品1的数据 ``` { "product": { "id": 1, "name": "European station summer new FASHION casual shorts hot pants female pants sports furniture pure cotton Korean version loose pants", "description":...

My nextjs ssr project relies on D1 data to render components. Every time I modify the UI, I can only re-publish it, including changing a css to see the effect,...

听劝，编码问题这个别瞎折腾... ``` 探寻迷宫：JavaScript和Rust中缓冲数据与CJK语言文本编码检测的深度解析 执行摘要 文本编码检测在软件开发中仍然是一个复杂且常令人沮丧的挑战，尤其是在处理原始字节流（缓冲区）以及东亚语言（CJK）多样且历史悠久的字符集时。本报告深入探讨了JavaScript和Rust环境中特有的痛点，并评估了Rust（特别是通过WebAssembly，WASM）在解决乱码和相邻误判等常见问题方面的可行性。 尽管不存在单一的、普遍“彻底”或万无一失的自动编码检测方案（因为这需要外部元数据），但Rust，尤其是在通过WASM利用时，在鲁棒性、性能和显式处理方面比JavaScript的本地能力具有显著优势。编码固有的模糊性，特别是对于CJK语言，要求采取多层方法，将启发式检测与强大的错误处理、显式声明和策略性回退机制相结合。 文本编码的持久挑战 1.1. 理解字符编码：ASCII、ISO-8859与Unicode的兴起 字符编码是确保数据在不同设备和平台间保持一致性、效率和安全性的基础 1。ASCII作为一种基础的7位编码，能表示128个字符（字母、数字、符号），并已深入集成到现代标准中 1。ISO-8859系列在ASCII基础上扩展了8位编码，其中ISO-8859-1（Latin-1）曾是HTML4和许多旧版POSIX系统的标准，但如今已被Unicode广泛取代 2。 Unicode旨在通过单一字符编码支持所有历史和现代书写系统 3。它定义了超过110万个可能的码点，并将其组织成17个平面 5。基本多语言平面（BMP，U+0000到U+FFFF）包含了最常用的符号，而辅助平面（U+010000到U+10FFFF）则包含不常用字符、历史脚本和表情符号 3。 Unicode通过多种编码格式实现： UTF-8： 一种可变长度编码，与ASCII完全兼容，每个字符使用1到4个字节。由于其对英文字符的高效性和广泛支持，它是目前网络上使用最广泛的编码 1。 UTF-16： 每个字符使用2或4个字节。它使用一个16位码元表示BMP字符，使用两个16位码元（“代理对”）表示辅助平面字符。它是Windows的默认编码 1。 UTF-32： 每个字符固定使用4个字节，这使其内存占用较高，但简化了字符索引。通常，UTF-32编码的文件体积最大 1。 正确的编码对于确保系统间的兼容性、正确显示文本（尤其是国际语言和表情符号）以及在存储或传输过程中保持数据完整性至关重要 1。错误的编码会导致“乱码”（mojibake），即显示为 ???或``等不可读的输出，甚至可能引入跨站脚本（XSS）或SQL注入等安全漏洞...