使用AngularJS和ASP.NET Web API上传/下载字节数组

Question

我花了几天的时间研究和研究用于上传/下载byte的解决方案。我已经接近了，但是还有一个问题似乎在我的AngularJS代码块中。

在陈述问题之前，这里有一些背景信息来设置上下文。

1. 我试图创建一个通用的客户端/服务器接口来上载和下载byte []，它们被用作专有服务器数据库的一部分。
2. 我在客户端上使用TypeScript，AngularJS，JavaScript和Bootstrap CSS创建单页应用程序（SPA）。
3. 我在服务器上使用ASP.NET Web API / C＃。

正在开发SPA来替代在Silverlight中开发的现有产品，因此将SPA限制为现有系统要求。SPA还需要针对各种设备（从移动设备到台式机）和主要操作系统。

借助一些在线资源（在下面列出），我的大部分代码都可以正常工作。我正在使用下面的Byte Rot链接中的byte []的异步多媒体格式化程序。

http://byterot.blogspot.com/2012/04/aspnet-web-api-series-
part-5.html

从ASP.NET WebAPI中的控制器返回二进制文件

1. 我正在使用转换为Uint8Array的jpeg作为客户端上的测试用例。
2. 实际的系统字节数组将包含压缩为预定义数据包的混合内容。但是，我需要能够处理任何有效的字节数组，以便图像是有效的测试用例。
3. 使用下面显示的客户端和服务器代码以及字节循环格式化程序将数据正确传输到服务器（未显示，但可在其网站上找到）。
4. 我已经验证了jpeg作为字节[]与字符串参数元数据一起在服务器上正确接收。
5. 我已经使用Fiddler来验证是否将正确的响应发送回了客户端。
   • 大小正确
   • 该图像在Fiddler中可见。

6. 我的问题是，以下所示的Angular客户端代码中的服务器响应不正确。

   • 不正确的 意思是我的 大小错误（〜10K与〜27.5K）， 并且 对于UintArray构造函数 ，它 不被识别为有效值 。当我将光标放在下面的客户端代码中显示的返回的“响应”上时，Visual Studio显示JFIF，但是没有其他可见的内容指示符。

/服务器代码/ 在[FromBody] byte[]之后将丢失的项目添加到代码中

public class ItemUploadController : ApiController{ 
[AcceptVerbs("Post")]
    public HttpResponseMessage Upload(string var1, string var2, [FromBody]byte[] item){
        HttpResponseMessage result = new HttpResponseMessage(HttpStatusCode.OK);
        var stream = new MemoryStream(item);
        result.Content = new StreamContent(stream);
        result.Content.Headers.ContentType = new MediaTypeHeaderValue("application/octet-stream");
        return result;
    }
}

/ 示例客户代码 /

我从代码中省略的唯一一件事是实际的变量参数。

$http({
url: 'api/ItemUpload/Upload',
    method: 'POST',
    headers: { 'Content-Type': 'application/octet-stream' },// Added per Byte Rot blog...
    params: {
        // Other params here, including string metadata about uploads
        var1: var1,
        var2: var2
    },
data: new Uint8Array(item),
// arrybuffer must be lowecase. Once changed, it fixed my problem.
responseType: 'arraybuffer',// Added per http://www.html5rocks.com/en/tutorials/file/xhr2/
transformRequest: [],
})
.success((response, status) => {
    if (status === 200) {
        // The response variable length is about 10K, whereas the correct Fiddler size is ~27.5K.
        // The error that I receive here is that the constructor argument in invalid.
        // My guess is that I am doing something incorrectly with the AngularJS code, but I
        // have implemented everything that I have read about. Any thoughts???
        var unsigned8Int = new Uint8Array(response);
        // For the test case, I want to convert the byte array back to a base64 encoded string
        // before verifying with the original source that was used to generate the byte[] upload.
        var b64Encoded = btoa(String.fromCharCode.apply(null, unsigned8Int));
        callback(b64Encoded);
    }
})
.error((data, status) => {
    console.log('[ERROR] Status Code:' + status);
});

/ ******** ** /

任何帮助或建议，将不胜感激。

谢谢…

编辑以包含更多诊断数据

首先，我使用angular.isArray函数确定响应值不是数组，我认为应该是。

其次，我使用以下代码询问响应，该响应似乎是不可见的字符串。前导字符似乎不对应于图像字节数组代码中的任何有效序列。

var buffer = new ArrayBuffer(response.length);
var data = new Uint8Array(buffer);
var len = data.length, i;
for (i = 0; i < len; i++) {
    data[i] = response[i].charCodeAt(0);
}

实验结果

我通过在下载的服务器上创建0到255之间的字节数组值来进行实验。AngularJS客户端正确接收了前128个字节（即0,1，…，126,127），但其余值在Internet
Explorer
11中为65535，在Chrome和Firefox中为65533。Fiddler显示通过网络发送了256个值，但是AngularJS客户端代码中仅收到217个字符。如果我仅使用0-127作为服务器值，那么一切似乎都可以正常工作。我不知道是什么原因引起的，但是客户端响应似乎更符合带符号的字节，我认为这是不可能的。

来自服务器的Fiddler
Hex数据显示256个字节，其值的范围是00,01，…，EF，FF，这是正确的。如前所述，我可以返回图像并在Fiddler中正确查看它，因此Web
API服务器接口可用于POST和GET。

我正在尝试香草XMLHttpRequest，看看我可以在AngularJS环境之外工作。

XMLHttpRequest测试更新

我已经能够确认香草XMLHttpRequest是否可以与GET服务器配合使用，并且能够返回正确的字节码和测试图像。

好消息是我可以在AngularJS周围乱搞，以使系统正常工作，但坏消息是我不喜欢这样做。我希望与Angular一起进行所有客户端服务器通信。

我将在Stack Overflow上打开一个单独的问题，该问题仅处理AngularJS遇到的GET byte
[]问题。如果可以解决，则将出于历史目的使用解决方案更新此问题，以帮助他人。

更新资料

Google网上论坛的Eric Eslinger给我发送了一个小段代码，突出显示responseType应该为“
arraybuffer”（全部小写）。我更新了上面的代码块以显示小写值并添加了注释。

谢谢…

Answer 1

我终于收到了来自Google Group的Eric Eslinger的回复。他指出他使用

$http.get('http://example.com/bindata.jpg', {responseType: 'arraybuffer'}).

他提到，骆驼案可能很重要。更改了一个字符，整个流程现在可以正常工作。

一切归功于Eric Eslinger。