Feature Overview
Object is the basic unit of storage in COS, which can be understood as data in any format, such as images, documents, and audio/video files. Bucket is the carrier of objects. One bucket can contain any number of objects. Different storage classes can be specified for objects in COS. For more information, see Storage Class Overview.
Each object consists of an object key (ObjectKey), an object value (Value), and object metadata (Metadata).
Object Key (ObjectKey): The object key is the unique identifier of an object within a bucket, which can be understood as the file path. In API and SDK examples, the naming format for objects is
<ObjectKey>.Value: The uploaded object itself, which can be commonly understood as the object content.
Metadata: A set of key-value pairs, which can be regarded as file attributes, such as file modification time and storage class. You can query them after uploading the object.
Object key
In Tencent Cloud COS, objects must have a valid object key. The object key (ObjectKey) is the unique identifier of an object within a bucket. For example, in the object access URL
examplebucket-1250000000.cos.ap-guangzhou.myqcloud.com/folder/picture.jpg, the object key is folder/picture.jpg.Naming conventions
You can use any UTF-8 characters in an object key name. However, we recommend you use letters and digits to ensure optimal compatibility with other applications..
The encoded length can be up to 850 bytes.
Cannot start with a forward slash
/ or a backslash \.An object key cannot contain certain ASCII control characters, including upward arrow (↑), downward arrow (↓), rightward arrow (→), and leftward arrow (←), corresponding to CAN (24), EM (25), SUB (26), and ESC (27) respectively.
Refrain from using special symbols such as
* and % in the filename.Note
If the name of the uploaded file or folder contains Chinese characters, the Chinese part will be converted to percent encoding according to the URL Encode rules when accessing and requesting the file or folder. For example, when accessing
document.doc, the object key is: document.doc, and the actual percent encoding according to the URL Encode rules is: %e6%96%87%e6%a1%a3.doc.The following are examples of valid object key names:
doc/exampleobject
my.great_photos-2016/01/me.jpg
videos/2016/birthday/video.wmv
Special symbols
Certain characters may need to be URL-encoded or referenced in the hexadecimal format. Some of them are non-printable characters, and your browser may not be able to handle them. They require special handling as detailed below:
， | : | ; | = |
& | $ | @ | + |
? | ASCII character ranges: 00–1F hexadecimal (0–31 decimal) and 7F (127 decimal) | (space) | |
There are also some characters that require significant special handling to maintain consistency across all applications, so we recommend you avoid them directly as detailed below:
` | ^ | " | \ |
{ | } | [ | ] |
~ | % | # | | |
* | > | < | ASCII 128–255 decimal |
Object access address
The access address of an object is composed of the bucket access address and the object key, with the structure
<bucket domain>/<object key>.
For example: If you upload the object exampleobject.txt to the bucket examplebucket-1250000000 in Guangzhou (South China), the access address for exampleobject.txt would be: examplebucket-1250000000.cos.ap-guangzhou.myqcloud.com/exampleobject.txt.Folder and directory
As COS comes with no folders or directories, it will not create a
project folder for uploading the object project/a.txt. To make it easier for you to get started, COS simulates the display mode of "folder" or "directory" in the console and graphical tools such as COSBrowser. This is implemented by creating an empty object with a key value of project/ and displaying it as a traditional folder.For example, when you upload the object
project/doc/a.txt via APIs or SDKs, the separator / simulates the display mode of "folder", and you can see the folders project and doc in the console. The folder doc is displayed under the folder project and contains the file a.txt.Note
Objects in the bucket are evenly distributed among distributed clusters. Therefore, you cannot directly get the size of all objects with a specified object key prefix. Instead, you can accumulate the size of each object to get the full size.
Deleting folders and directories is relatively complicated as detailed below:
Deletion Method | Delete Object or Folder | Result |
Console | Folder project | All objects with the object key prefix project/ will be deleted. |
Console | Object project/doc/a.txt | Project and Doc folders will still be retained. |
API、SDK | Object project/ or project/doc/ | The object project/doc/a.txt will be retained. If you want to delete the objects in the folder, use code traversal to delete them. |
Object metadata
Object metadata (or HTTP header) is a set of key-value pairs in an object. It is the string sent by the server before the server sends HTML data over the HTTP protocol to the browser. Modifying the HTTP header when uploading an object can alter page response forms or communicate configuration information, such as modifying caching time.
There are two types of metadata: system metadata and user-defined metadata.
Note
Modifying the HTTP Header of an object does not alter the object itself.
System metadata
This refers to the attribute information of an object, such as object modification time, object size, and storage class.
Name | Note |
Content-Length | HTTP request length (in bytes) defined in RFC 2616. |
Last-Modified | The creation date or last modified date of an object (whichever is later). |
x-cos-version-id | Object version ID. If versioning is enabled for a bucket, the version ID of the object will be returned to identify the historical versions of the object. |
ETag | The MD5 value of an object uploaded by calling PUT Object, or the unique ID of an object uploaded by multipart upload or a legacy API (which cannot perform check though). |
User-defined metadata
This refers to customizable parameters of an object, such as Content-Type, Cache-Control, Expires, x-cos-meta-* and so on. For more information, see Custom Object Headers.
Name | Note |
Cache-Control | The caching policy as defined in RFC 2616, which is saved as part of the object metadata. |
Content-Disposition、 Content-Encoding、 Content-Type | The filename/encoding format/content type (MIME) as defined in RFC 2616, which are saved as part of the object metadata. |
Expires | The cache expiration time as defined in RFC 2616, which is saved as part of the object metadata. |
x-cos-acl | ACL attributes of an object. Valid values: private, public-read-write, public-read. Default value: private. |
x-cos-grant-* | Grants the grantee permissions. |
x-cos-meta-* | User-defined header, which is returned as part of the object metadata with a size up to 2 KB. |
x-cos-storage-class | Storage class of an object. Enumerated values: STANDARD, STANDARD_IA, ARCHIVE. Default value: STANDARD. |
x-cos-server-side-encryption | Specifies whether to enable server-side encryption for the object and the encryption method. |
Actions on objects
You can manage objects through the Tencent Cloud console, tools, APIs, and SDKs.
Note
Use simple upload for objects less than 5 GB in size.
Multipart upload is limited to no more than 10,000 parts (each in 5 GB) and a maximum object size of around 48.82 TB. For more information on the use limits, see Specifications and Limits.
After uploading objects, you can configure them in the console. For more information, see:
Object Subresource
COS has subresources that are associated with buckets and objects. Subresources are subordinates to objects, so they do not exist on their own. They are always associated with other entities such as objects or buckets. An ACL is the access control information list for a specific COS object, which is a subresource of the object.
An ACL contains an authorization list that identifies authorized users and the granted permissions to implement access control on the object. When an object is created, the ACL identifies the object owner who can fully control the object. You can search for the object ACL or replace it with a new one.
Note
You can update an ACL only by replacing it.
Access Permission Types
COS supports two types of object permissions: Public Permissions and User Permissions.
Public Permissions: Include inherited permissions, private read/write, and public read/private write.
Inherit: The object inherits the access permission of the bucket. When you access an object with the inherited bucket permission, COS will match the bucket permission to respond to the access request. A new object inherits the permission from its bucket by default.
Private Read/Write: When you access an object with the private read/write permission, the object can only be accessed with a request signature, regardless of the bucket access permission.
Public Read/Private Write: When you access an object with the public read permission, the object can be directly downloaded, regardless of the bucket access permission.
User permissions: A root account has all the permissions (full access) of buckets by default. In addition, you can add sub-accounts and grant them permissions to read/write data and permissions and even get full access.
Scenarios
You can set the specified object which allow public access in a private read/write bucket, or the specified objects which only allow access after authentication in a public read/write bucket.