python - Boto "get byte range"返回超过预期

Question

这是我的第一个问题，因为我是这个世界的新手!我花了几天时间试图自己解决这个问题，但到目前为止还没有找到任何有用的信息。

我正在尝试从存储在 S3 中的文件中检索字节范围，使用类似的方法:

S3Key.get_contents_to_file(tempfile, headers={'Range': 'bytes=0-100000'}

我要从中恢复的文件是视频文件，特别是 MXF。当我请求一个字节范围时，我在临时文件中得到的信息比请求的多。例如，使用一个文件，我请求 100,000 字节并返回 100,451。

关于 MXF 文件需要注意的一件事是它们合法地包含 0x0A(ASCII 换行)和 0x0D(ASCII 回车)。

我仔细研究了一下，发现只要文件中存在 0D 字节，检索到的信息就会添加 0A 0D 而不仅仅是 0D，因此似乎检索到的信息比所需的多。

例如，原始文件包含以下十六进制字符串:

02 03 00 00 00 00 3B 0A 06 0E 2B 34 01 01 01 05

但是从 S3 下载的文件有:

02 03 00 00 00 00 3B 0D 0A 06 0E 2B 34 01 01 01 05

我已经尝试调试代码并按照我的方式完成 Boto 逻辑，但我在这方面相对较新，所以很容易迷路。

我创建这个是为了测试，它显示了问题

from boto.s3.connection import S3Connection
from boto.s3.connection import Location
from boto.s3.key import Key
import boto
import os


## AWS credentials
AWS_ACCESS_KEY_ID = 'secret key'
AWS_SECRET_ACCESS_KEY = 'access key'

## Bucket name and path to file
bucketName = 'bucket name'
filePath = 'path/to/file.mxf'

#Local temp file to download to
tempFilePath = 'c:/tmp/tempfile'


## Setup the S3 connection and create a Key to access the file specified
## in filePath
conn = S3Connection(AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
bucket = conn.get_bucket(bucketName)
S3Key = Key(bucket)
S3Key.key = filePath

def testRangeGet(bytesToRead=100000): # default read of 100K
    tempfile = open(tempFilePath, 'w')
    rangeString = 'bytes=0-' + str(bytesToRead -1)  #create byte range as string
    rangeDict = {'Range': rangeString} # add this to the dictionary
    S3Key.get_contents_to_file(tempfile, headers=rangeDict) # using Boto
    tempfile.close()
    bytesRead = os.path.getsize(tempFilePath)
    print 'Bytes requested = ' + str(bytesToRead)
    print 'Bytes recieved = ' + str(bytesRead)
    print 'Additional bytes = ' + str(bytesRead - bytesToRead)

我猜 Boto 代码中有一些东西正在寻找某些 ASCII 转义字符并修改它们，但我找不到任何方法来指定只将其视为二进制文件。

有没有人遇到过类似的问题，可以分享解决方法吗？

谢谢

蒂姆

Answer 1

将输出文件作为二进制文件打开。否则写入该文件会自动将 LF 转换为 CR/LF。

tempfile = open(tempFilePath, 'wb')

当然只有在 Windows 系统上才需要。 Unix 不会转换任何内容，无论文件是作为文本文件还是二进制文件打开。

上传时您也应该小心，不要首先将类似损坏的数据导入 S3。