Почему распространенная практика заключается в кодировании курсоров разбиения на страницы или значений идентификаторов в виде строки?

Например, API-интерфейс Facebook: почему after и before закодированные номера base64?

{
  "data": [
     ... Endpoint data is here
  ],
  "paging": {
    "cursors": {
      "after": "MTAxNTExOTQ1MjAwNzI5NDE=",
      "before": "NDMyNzQyODI3OTQw"
    },
    "previous": "https://graph.facebook.com/me/albums?limit=25&before=NDMyNzQyODI3OTQw"
    "next": "https://graph.facebook.com/me/albums?limit=25&after=MTAxNTExOTQ1MjAwNzI5NDE="
  }
}

Какие преимущества он мог бы противопоставить простым номерам?

Как показывает следующий журнал python, преимущества не могут быть коротким представлением данных или данных, содержащих небезопасные символы:

>>> base64.b64decode("MTAxNTExOTQ1MjAwNzI5NDE=")
'10151194520072941'
>>> len('10151194520072941')
17
>>> len("MTAxNTExOTQ1MjAwNzI5NDE=")
24

ОТВЕТЫ

Ответ 1

Максимально возможное число в JavaScript - 9007199254740992 в соответствии с вопросом, заданным в StackOverflow Что такое максимальное целочисленное значение JavaScript, которое число может идти без потери точности?

Если вы сравниваете эти значения

9007199254740992    // the JS maximum
10151194520072941   // the Base64 encoded number

Если, конечно, похоже, что Facebook внутри - по причинам, которые мы не знаем, - сохраняя значения, которые слишком велики для точности числа JavaScript для обработки.

Таким образом, мне кажется, что у них не было другой возможности, кроме как обрабатывать числа как строки.

Конечно, они могли бы просто использовать "10151194520072941" как число в строчном формате, но некоторые программисты могли бы путать это как число. Несмотря на то, что это редко случается, они, вероятно, думали, что Base64, кодирующий число, избегает проблемы кого-то, переводящего строку в целое число.

Кроме того, поскольку это функция Public API, она не используется их собственными инженерами, поэтому риск еще выше, потому что люди, использующие API, поступают из разных образов. Они могут случайно использовать, например, parseInt или похожи на число, приводящее к ненужным запросам обслуживания клиентов.

EDIT: Использование очень больших чисел может также служить другой цели: выявление целенаправленного злоупотребления API. Если они будут использовать, например, случайные значения UUID или последовательные числовые значения, любое близкое значение может быть потенциально легальным. Если это UUID, они сначала должны сделать запрос, чтобы убедиться, что это законная запись. Имея большую базу чисел, может случиться так, что только каждый 1000-й является законным или они следуют некоторому другому математическому правилу, которое может быть обнаружено одним сервером, без запросов на другой сервер, сортировка клиентов, которые целенаправленно обрабатывают запросы с незаконными значениями, становится намного больше эффективны и, возможно, могут быть отфильтрованы до того, как они попадут в базы данных.

Ответ 2

 Если вы имеете в виду использование базы 10 (десятичной), когда вы говорите простые цифры, то преимущества в том, что база 64 более компактна, используя меньшее количество цифр (10-разрядное базовое 10-числовое число (например, 1 000 000 000) может быть выражено всего в 5 цифрах в базе 64 (например, F9eEA)), а также (как вы говорите), скрывая детали реализации.

Если вы имеете в виду использование необработанных двоичных данных, когда вы говорите простые цифры, база 64 использует символы, которые почти всегда безопасны для передачи через Интернет, в URL-адресах и т.д., не имея некоторых символов, интерпретируемых как контрольные символы (что представляет собой риск при передаче необработанных двоичных данных). см. этот другой вопрос для получения дополнительной информации.

В любом случае есть преимущества использования base64.Забастовкa >

EDIT:

Я понимаю, что вы имеете в виду, ранее перечисленные преимущества не применяются в этом случае. Facebook, вероятно, использовал base64 для согласованности с другими функциями API, а также для скрытия деталей реализации. Также может быть полезно, если они изменят его в будущем, чтобы позволить другим персонажам, а также переносить потенциальные искаженные запросы (предполагая, что ошибка произошла до преобразования base64).