阿里云内容设计中心

阿里云原生售前支持3群 群号：33609450

进入ali-oss/example执行 npm run start。

可以将checkpoint保存到浏览器的localstorage，下次再调用的时候传入checkpoint参数，就可以实现断点续传功能。

将 base64 内容转换成 File 对象，再调用接口上传至 OSS 服务器。

 function dataURLtoFile(dataurl, filename) {
    let arr = dataurl.split(','), mime = arr[0].match(/:(.*?);/)[1],
      bstr = atob(arr[1]), n = bstr.length, u8arr = new Uint8Array(n);
    while(n--){
      u8arr[n] = bstr.charCodeAt(n);
    }
    return new File([u8arr], filename, {type:mime});
  }

  let file = dataURLtoFile('<base64 content>', '');

  client.multipartUpload('<oss file name>', file).then( (res)=> {
    console.log(res)
  }).catch((err) => {
    console.log(err)
  });
			

Node.js SDK 中可根据下载流的大小来计算进度。

初始化 SDK 时，只需要指定 secure 的值为 true，则默认进行 HTTPS 访问。

Python SDK自身没有重试机制。在网络状况不好的情况下，可能会出现请求失败的情况。此时，建议您参考如下代码自行添加重试策略。

def test_get_object():
    MAX_RETRIES = 3
    retry_count = 0
    while True:
        try:
            retry_count += 1
            # yourObjectName表示不包含Bucket名称在内的OSS文件的完整路径，例如abc/efg/example.jpg。
            # yourFileName表示下载到本地文件的完整路径，例如/users/local/example.jpg。
            bucket.get_object_to_file("yourObjectName", "yourFileName")
            break
        except Exception:
            if retry_count >= MAX_RETRIES:
                raise

客户端部署tcpdump抓包，然后通过tcp报文排查是否由于Header信息不正确导致计算签名与服务端不匹配。

POST /ttsservice%2Fpasswd?uploadId=D468E486D1D94D90A1AB8885A4E32AE0 HTTP/1.1
Host: rokid.oss-cn-hangzhou.aliyuncs.com
Accept-Encoding: identity
Accept: text/html
Content-Length: 137
date: Sat, 29 Dec 2018 07:32:34 GMT
authorization: OSS LTAIknFr:r2KPR0y4E0G5tnU/MYdcvXHP****
Content-Type: application/x-www-form-urlencoded
User-Agent: aliyun-sdk-python/2.6.0(Linux/4.4.0-31-generic/x86_64;3.4.3)

<CompleteMultipartUpload><Part><PartNumber>1</PartNumber><ETag>"3195544E19D99658706D5****"</ETag></Part></CompleteMultipartUpload>HTTP/1.1 403 Forbidden

Server: AliyunOSS
Date: Sat, 29 Dec 2018 07:33:43 GMT
Content-Type: application/xml
Content-Length: 1122
Connection: keep-alive
x-oss-request-id: 5C2723573183****
x-oss-server-time: 0

<?xml version="1.0" encoding="UTF-8"?>
<Error>
 <Code>SignatureDoesNotMatch</Code>
 <Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message>
 <RequestId> 5C2723573183A12D </RequestId>
 <HostId>rokid.oss-cn-hangzhou.aliyuncs.com</HostId>
 <OSSAccessKeyId> LTAXXX </OSSAccessKeyId>
 <SignatureProvided>r2KPR0y4E0G5tnU/MYdc****</SignatureProvided>
 <StringToSign>POST
application/x-www-form-urlencoded
Sat, 29 Dec 2018 07:32:34 GMT
/rokid/ttsservice/passwd?uploadId=D468E486D1D94D90A1AB8885A4E3****</StringToSign>
 <StringToSignBytes>50 4F 53 54 0A 0A 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 2D 77 77 77 2D 66 6F 72 6D 2D 75 72 6C 65 6E 63 6F 64 65 64 0A 53 61 74 2C 20 32 39 20 44 65 63 20 32 30 31 38 20 30 37 3A 33 32 3A 33 34 20 47 4D 54 0A 2F 72 6F 6B 69 64 2D 6F 70 73 2D 6D 6F 64 65 6C 2F 74 74 73 73 65 72 76 69 63 65 2F 70 61 73 73 77 64 3F 75 70 6C 6F 61 64 49 64 3D 44 34 36 38 45 34 38 36 44 31 44 39 34 44 39 30 41 31 41 42 38 38 38 35 41 34 45 33 32 41 45 30 </StringToSignBytes>
</Error>

如果服务端收到的签名（Signature）和客户端计算的签名信息不一致，说明请求的内容已被改动，建议使用HTTPS的方式上传。

以上是客户端抓取的报文信息。请将获取的请求头信息带入以下脚本，并将计算结果与SDK进行比较。

import base64
import hmac
import sha
mac = hmac.new("<Secretkey>","POST\n\napplication/x-www-form-urlencoded\nSat, 29 Dec 2018 07:32:34 GMT\n/rokid/ttsservice/passwd?uploadId=D468E486D1D94D90A1AB8885A4E3****", sha)
Signature = base64.b64encode(mac.digest())
print(Signature)

如果抓包数据和脚本计算的结果一致，则说明SDK计算正确。如果抓包数据和脚本计算的结果不一致，可能是因为SDK在Ubuntu平台编译的适配问题导致MD5值不一样。

解决方法如下：

• 先确认是直接上传到OSS，还是通过其他proxy传输到OSS（类似CDN）。如果经过CDN再上传到OSS，需要在OSS中配置跨域的HTTP Header，例如Access-Control-Allow-Origin、Access-Control-Allow-Mehtods、Access-Control-Allow-Headers等，并暴露ETag。更多信息，请参见PutBucketcors。

• 如果是网络超时导致上传失败，建议使用断点续传来替代普通上传。断点续传支持并行上传以及自定义分片大小。如果捕获到异常，需要详细查看并分析捕获到的SDK异常信息。

• 清理上传失败的碎片文件再重新上传。

如果以上方案仍旧没有解决您的问题，需要将以下信息提供给阿里云：

• SDK返回异常中的requestID。

• 客户端部署tcpdump，然后重新运行代码上传，并保存抓包。

tcpdump -i <网卡出口名称> -s0 host <访问oss的域名> -w faild.pcap

Apache Log4j定义了不同级别的日志，包括OFF、FATAL、ERROR、WARN、INFO、DEBUG、TRACE、 ALL。

通过配置log4j的属性选择开启或者关闭SDK日志：

• 错误原因

int类型溢出，导致2038年时间戳问题。

超出URL设置的过期时间后发起上传请求。

• 解决方法

如果是int类型溢出，建议Java SDK中过期时长不要超过2038年。

如果因超出URL设置的过期时间后发起上传请求，建议设置合理的过期时间，确保过期时间大于您的发起请求时间。

使用OSS PostObject的callback没有触发回调，但是通过PutObject用同样的callback触发了回调。一般情况下，如果JSON格式有误或者回调失败，都会返回相应的消息，这里需要分别测试Put和Post回调效果：

• 错误原因

发送请求时callback参数在file下面。

• 解决方法

调整callback参数与file的位置。

此时测试结果显示业务服务器成功抓取请求。

• 错误原因

可能是socket在init阶段就失败了，导致请求没有到达OSS。

• 解决方法

建议从以下几个方面进行排查：

出现问题时是否出现网络抖动。

主机的socket连接数是否占满。

确认出现问题时连接数是否超过SDK中设置的maxconnection，如果连接数超过maxconnection设置，也会出现socket异常。

如果以上都没有问题，建议您部署tcpdump或者wireshark抓包，问题复现后再分析数据包。

• 错误原因

用户端并发请求STS过高。

网络到Server端超时。

所使用的STS SDK以及SDK core不是最新版本。

• 解决方法

用户端并发请求STS过高，而用户端的ECS或者本地PC不足以承载当时的并发，降低OSS并发。

用户的网络到Server端有超时现象可以进行抓包验证。

建议将STS SDK及SDK core升级至最新版本。

• 错误原因

原因是ossClient后台线程IdleConnectionReaper会定时关闭闲置连接。

IdleConnectionReaper在Sleep时，调用ossClient.shutdown，就会报上面的异常。

• 解决方法

使用如下代码，忽略该异常：

try {
    ossClient.shutdown();
} catch(Exception e) {
}
                    

• 错误原因

ossClient没有关闭导致。

• 解决方法

主动关闭已执行完毕的ossClient或使用单例模式。

• 错误原因

使用过期的连接会导致上述错误，该错误仅在Java SDK 2.1.2之前的版本出现。

• 解决方法

请升级OSS Java SDK到2.1.2及以后版本。

• 错误原因1

1、AccessKey ID和AccssKey Secret不一致。

2、有关获取AccessKey ID和AccssKey Secret的操作步骤，请参见获取AccessKey。

• 错误原因2

签名URL使用不正确。错误示例如下：

GeneratePresignedUrlRequest request = new GeneratePresignedUrlRequest(bucketName, object);
request.setExpiration( new Date(new Date().getTime() + 3600 * 1000));
request.addUserMetadata("author");
URL url = ossClient.generatePresignedUrl(request);

Map<String, String> header = new HashMap<String, String>();
header.put("author");
ossClient.putObject(url, new ByteArrayInputStream("Hello OSS".getBytes()), -1, header);

未指定Method参数时，默认使用GET方法。以上为PutObject请求，应指定Method参数并设置为PUT方法。

通过PutObject发送请求时，请求Header中自定义的元数据必须以x-oss-meta-为前缀。以上示例中自定义元数据应改为x-oss-meta-author。

解决方法：

指定Method，并修改Header：

request.addUserMetadata("author");
request.setMethod(HttpMethod.PUT);
URL url = ossClient.generatePresignedUrl(request);

Map<String, String> header = new HashMap<String, String>();
header.put("x-oss-meta-" + "author");
ossClient.putObject(url, new ByteArrayInputStream("Hello OSS".getBytes()), -1, header);

• 错误原因3

1、使用了低于3.7.0版本的OSS SDK，项目中引入了4.5.9及以上版本的httpclient。

2、上传的文件名中包含+字符，而4.5.9版本的httpclient不会对+进行URLEncode编码，从而造成客户端与服务端计算的签名不一致而报错。

解决方法：

1、OSS SDK建议升级为3.11.1及以上版本， 以兼容4.5.9版本的httpclient。

2、移除多余的httpclient依赖。引入OSS SDK时会自动引入httpclient依赖，如果是第三方库另外引入了httpclient，请参见包冲突解决方案。

• 错误原因4

HttpClient 4.5.10版本不支持Header中包含ISO/9959-1标准以外的字符，但在项目中引入了4.5.10以上的httpclient，并在请求Header中包含了ISO/9959-1标准以外的字符，例如x-oss-meta-开头的自定义元数据中传入了中文字符。

解决方法：

1、参见包冲突解决方案，移除冲突的httpclient版本。

2、在请求Header中传入符合ISO/9959-1标准的字符。

OSS Java SDK依赖下列包：

1. aliyun-sdk-oss-2.2.1.jar
2. hamcrest-core-1.1.jar
3. jdom-1.1.jar
4. commons-codec-1.9.jar
5. httpclient-4.4.1.jar
6. commons-logging-1.2.jar
7. httpcore-4.4.1.jar
8. log4j-1.2.15.jar

其中log4j-1.2.15.jar是可选的，需要日志功能的时候加入该包，其它包都是必需的。

• 解决方法

在您的工程中加入OSS Java SDK依赖的包。加入方法如下：

1. 如果您的工程在Eclipse中，请参见Java SDK使用手册中的安装方式二。

2. 如果您的工程在Ant中，请把OSS Java SDK依赖的包放入工程的lib目录中。

3. 如果您直接使用.javac或.java文件，请使用-classpath或-cp命令指定OSS Java SDK依赖的包路径，或把OSS Java SDK依赖的包放入classpath路经下。

各个ftp客户端一般都有超时设置，可以设置为不超时。以FileZilla工具为例，在设置->连接里，可以将超时设置为0。

由于ftp协议的控制端口和数据端口不同，当ftpserver工作在被动模式下，每当需要传输数据时，ftpserver会打开1个随机端口，等待客户端来连接。所以当ftpserver所在机器有端口限制时，可能会导致数据无法正常传输。

解决办法是当运行ftpserver.py时，通过指定--passive_ports_start和--passive_ports_end参数来设置本地端口的起止范围，然后将该范围的端口都打开。

原因一般是Bucket根目录下的文件数或文件夹过多。 登录ftp后，ftpserver会尝试将Bucket根目录下的所有文件／文件夹List出来，每次可以List出1000个文件／文件夹。如果根目录下有100万以上的文件／文件夹，则会导致1000次以上的http请求，非常容易超时。

此类错误通常是因为本地的中文编码有问题。在将要运行start.sh的终端中输入下面的命令，然后再重新启动即可。

$ export LC_ALL=en_US.UTF-8; export LANG="en_US.UTF-8"; locale