Каковы последствия использования latin1 вместо utf8 для таблиц MySQL, созданных для использования OAuth?

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

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

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

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

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

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

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

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


person Robert Oschler    schedule 19.04.2011    source источник
comment
utf8 обычно не требует 3 байта на символ, требуется от 1 до 5 в зависимости от символа. все в обычном диапазоне ASCII точно такое же в utf8.   -  person jcomeau_ictx    schedule 19.04.2011


Ответы (1)


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

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

person jcomeau_ictx    schedule 19.04.2011