在node.js中高效地将Buffer转换为Buffer的Base64解码

Question

我目前在noVNC中拥有wsproxy的python和C版本(将WebSockets转换为普通的TCP socket代理)。我想创建一个使用node.js的wsproxy版本。一个关键因素(也是我不仅仅使用现有的node WebSocket代码的原因)是，直到WebSocket标准具有二进制编码，wsproxy和浏览器/客户端之间的所有流量都必须被编码(base64解码/编码在浏览器中快速而容易)。

缓冲区类型支持base64编码，但这是从一个缓冲区到一个字符串，反之亦然。如何在两个缓冲区之间进行base64编解码而无需首先转换为字符串？

限制条件:

• 直接进行缓冲区到缓冲区操作(除非您可以证明Buffer->string->Buffer与此同样快)。
• 由于node内置了base64支持，我希望使用它而不是外部模块。
• 在单个缓冲区内进行原地编码/解码是可以接受的。

这里是有关node中base64支持的讨论，但从我所看到的并没有回答我的问题。

- kanaka

---

这个问题的唯一问题不是Flash回退变得非常缓慢吗？否则，二进制就可以正常工作，尽管在协议中存在UTF-8编码/解码开销，但这总是存在的。无论如何，buffer.copy在复制时不会应用编码，并且在快速测试中使用toString()会慢150倍。您可能需要在Node上报告一个缓冲区复制的错误，该错误会在指定的编码中进行复制。 - Ivo Wetzel

由于WebSockets数据目前仅限于UTF-8（希望在未来的修订中会有所改变），代理必须对原始套接字数据进行某种编码。Flash回退添加了一个曲折，即您无法发送零字节（从技术上讲，这是合法的UTF-8）。将每个字节编码为UTF-8需要150％的空间（任何其他UTF-8编码都太慢以至于无法在Javascript中解码）。Base64为133％，因此在空间和处理方面更有效率。 - kanaka

Answer 1

你应该能够使用流来完成这个，但首先阅读有关UTF-8解码的博客，因为你可能会遇到类似的问题。我不是建议你进行UTF-8编码/解码，如果你不需要它，而是要看看这段代码如何处理一个单个字符跨越多个由块边界分隔的字节的问题。

- Michael Dillon

---

我在问题中可能没有表达清楚，为了速度，我不想要JavaScript实现（已经有代码了），而是想要一个本地的Base64解码例程。我已经有一种使用本地Base64例程的方法，但它们首先遍历字符串，我想摆脱这个过程。 - kanaka

如果你需要C++代码，为什么不使用现有的Base64编码/解码代码来构建你的扩展呢？顺便说一下，标签不是很清楚，所以我删除了一些并添加了一些。这可能会让你得到更多的答案。 - Michael Dillon