IntegerField值已转换为某些数字的字符串

本文介绍了IntegerField值已转换为某些数字的字符串的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

具有带有整数字段的Cloud Endpoints(ProtoRPC)消息类，例如

Having a Cloud Endpoints (ProtoRPC) message class with an integer field, e.g.

TestMsg(messages.Message): int_field = messages.IntegerField(1)

和方法:

@endpoints.method(VoidMessage, TestMsg) def test_int_field(): return TestMsg(int_field=1234567890123)

在本地开发服务器上的JSON响应正确导致:

On local dev server JSON response correctly results in:

{ int_field: 1234567890123 }

在生产中，由于某种原因，数字被转换为字符串:

Whereas in production the number gets converted to a string for some reason:

{ int_field: "1234567890123" }

对于较小的数字，整数似乎并没有转换为字符串.

For smaller numbers integers don't seem to be converted to strings though.

这是预期的行为吗?任何人都可以复制吗? (以防万一:我正在欧盟数据中心中运行此代码)

Is this expected behaviour? Anyone can repro? (In case it matters: I'm running this code in EU datacenters)

推荐答案

我猜@proppy是正确的.另外，它以发现格式明确指出

I guess @proppy is right. Also, it clearly states in the discovery format that

32位带符号整数(整数"类型，int32格式).最小值为-2,147,483,648，并且 最大值为2,147,483,647(含)

A 32-bit signed integer ("integer" type, int32 format). It has a minimum value of -2,147,483,648 and a maximum value of 2,147,483,647 (inclusive)

和

32位无符号整数(整数"类型，uint32格式).最小值为0，最大值为 价值4,294,967,295(含).

A 32-bit unsigned integer ("integer" type, uint32 format). It has a minimum value of 0 and a maximum value of 4,294,967,295 (inclusive).

所有其他类型的int/bigint/任何值都表示为具有不同格式的字符串"类型.更多信息: developers.google/discovery/v1/type-format

All other kinds of int/bigint/whatever values are repesented as "string" types with different formats. More info: developers.google/discovery/v1/type-format

因此，1234567890123数字实际上不能以整数"类型表示.只是开发服务器不会自动将整数转换为字符串(就像生产基础结构一样)，而且我没有意识到在本地测试时该数字有多大.

So, 1234567890123 number cannot in fact be represented in "integer" type. It's just the dev server doesn't convert integers to strings automatically (like the production infrastructure does), and I didn't realize how big the number was while testing locally.

事实证明，Google的一个团队已经在努力使其保持一致: code.google/p/googleappengine/issues/detail?id=9173

It turns out a team at Google is already working on making it consistent: code.google/p/googleappengine/issues/detail?id=9173