Каковы последствия использования latin1 вместо utf8 для таблиц MySQL, созданных для использования OAuth? - PullRequest
1 голос
/ 19 апреля 2011

Я нахожусь в процессе настройки поддержки OAuth на общем сервере.Библиотека OAuth на стороне сервера, которую я пытаюсь установить, является следующей:

http://code.google.com/p/oauth-php/downloads/list

И я следую указаниям по установке, найденным здесь:

http://code.google.com/p/oauth-php/wiki/ConsumerHowTo

В примечаниях был совет по использованию сценария SQL, найденного в пакете установки, для настройки таблиц и баз данных.Когда я попытался выполнить сценарий с помощью функции импорта (SQL), найденной в phpMyAdmin, я получил ошибку «Слишком длинный ключ» в одной из таблиц.Другими словами, я запустил smack в ограничение максимальной длины ключа, найденное при использовании таблиц MySQL / InnoDB.

Чтобы обойти эту проблему, я заменил все экземпляры "charset = utf8" на "charset = latin1", так как utf8требуется 3 байта на символ, а latin1 равен 1 байту на символ.Сценарий выполнялся нормально, и все таблицы были созданы правильно.

Насколько я вижу, все поля, используемые в таблицах, не требуют поддержки многобайтовых международных символов.Единственный способ увидеть возникновение проблемы - это если одна из служб, подключенных к OAuth, к которым у меня есть доступ, использует международные символы в их ключе или секрете потребителя, и я до сих пор не сталкивался с такой ситуацией.

Может кто-нибудьскажите, будет ли этот обходной путь кусать меня в заднюю часть в любое время и где это может быть?Кроме того, если у кого-то есть лучшее решение для исправления проблемы «слишком длинный ключ» без ущерба для использования набора символов utf8, я бы хотел об этом знать.

1 Ответ

1 голос
/ 19 апреля 2011

Технически, все строки должны быть сначала кодированы в utf8, а не в urlencoding.См. Раздел 5.1 спецификации OAuth 1.0: все имена и значения параметров экранируются с использованием механизма [RFC3986] процентного кодирования (% xx).Символы, не входящие в незарезервированный набор символов (раздел 2.3 [RFC3986]), ДОЛЖНЫ быть закодированы.Символы в незарезервированном наборе символов НЕ ДОЛЖНЫ быть закодированы.Шестнадцатеричные символы в кодировках ДОЛЖНЫ быть в верхнем регистре.Имена и значения текста ДОЛЖНЫ быть закодированы как октеты UTF-8, прежде чем они будут кодироваться в процентах согласно [RFC3629].

Так что если у вас есть какие-либо символы Latin-1, которые также не являются ASCII (бит 7 = 0),вам придется перекодировать строки как UTF-8 после извлечения их из БД и перед их использованием в протоколе OAuth.

...