Comment 2 for bug 1045455

This isn't really a bug - the UTF-8 encoding comes into play in how the actual response body string is encoded "on the wire, " not how the string values are displayed. The "\u2122" is the unicode code point which is independent of the actual encoding and is more universal. To test this, I ran it through Javascript with both the code point as currently returned and with the UTF-8 notation:

<script>
var j1 = {"status": "active", "name": "cirros-0.3.0-x86_64-uec-kernel", "tags": ["\u2122"], "container_format": "aki", "created_at": "2012-08-30T23:41:04Z", "disk_format": "aki", "updated_at": "2012-09-03T18:34:34Z", "visibility": "public", "id": "5fe4ddf1-4228-4d2d-8c1a-ffe5db9bc4f2", "protected": false, "min_ram": 0, "file": "/v2/images/5fe4ddf1-4228-4d2d-8c1a-ffe5db9bc4f2/file", "checksum": "cfb203e7267a28e435dbcb05af5910a9", "min_disk": 0, "size": 4731440, "self": "/v2/images/5fe4ddf1-4228-4d2d-8c1a-ffe5db9bc4f2", "schema": "/v2/schemas/image"};

var j2 = {"status": "active", "name": "cirros-0.3.0-x86_64-uec-kernel", "tags": ["\xe2\x84\xa2"], "container_format": "aki", "created_at": "2012-08-30T23:41:04Z", "disk_format": "aki", "updated_at": "2012-09-03T18:34:34Z", "visibility": "public", "id": "5fe4ddf1-4228-4d2d-8c1a-ffe5db9bc4f2", "protected": false, "min_ram": 0, "file": "/v2/images/5fe4ddf1-4228-4d2d-8c1a-ffe5db9bc4f2/file", "checksum": "cfb203e7267a28e435dbcb05af5910a9", "min_disk": 0, "size": 4731440, "self": "/v2/images/5fe4ddf1-4228-4d2d-8c1a-ffe5db9bc4f2", "schema": "/v2/schemas/image"};

window.alert("j1.tags[0]: " + j1.tags[0]);

window.alert("j2.tags[0]: " + j2.tags[0]);

</script>

If you load that up in a web browser, you'll see that the first representation (\u2122) is properly interpreted, while the UTF-8 representation displays garbage.