Традиционными способами Guid записывается очень неудобно. Его невозможно выделить, просто ткнув 2 раза мышью (как слово) и надо то писать то не писать кавычки, то " в c# то ' в sql. Скопировать несколько штук guid'ов превращается в какой-то индийский танец на клавиатуре.
Многие участники форума занимаются созданием средств разработки. Предлагаю начать внедрять новый формат, что-то вроде:
"u" + guid, закодированный в Base64 (24 символа вместо обычных 36).
(например ujpRGpgxW4Q6AtxKfEQy7Sckw)
И обязательно без кавычек (в трансляторах — всё что начинается с U и имеет длину 25 символов — считается guid'ом и окрашивается своим цветом).
Здравствуйте, Osaka, Вы писали:
O>Многие участники форума занимаются созданием средств разработки. Предлагаю начать внедрять новый формат, что-то вроде: O>"u" + guid, закодированный в Base64 (24 символа вместо обычных 36). O>(например ujpRGpgxW4Q6AtxKfEQy7Sckw) O>И обязательно без кавычек (в трансляторах — всё что начинается с U и имеет длину 25 символов — считается guid'ом и окрашивается своим цветом).
Здравствуйте, Osaka, Вы писали:
O>Традиционными способами Guid записывается очень неудобно. Его невозможно выделить, просто ткнув 2 раза мышью (как слово) и надо то писать то не писать кавычки, то " в c# то ' в sql. Скопировать несколько штук guid'ов превращается в какой-то индийский танец на клавиатуре.
O>Многие участники форума занимаются созданием средств разработки. Предлагаю начать внедрять новый формат, что-то вроде: O>"u" + guid, закодированный в Base64 (24 символа вместо обычных 36).
Base64 тут не подойдёт из-за допустимости в нём символов типа '/' и '+'. Подбирать аналоги неудобно. Если взять base62 (26+26+10), получится: логарифм 2**128 по основанию 62 равен 21.497, значит, 22 хватит для собственно тела и плюс 'U' впереди — получится 23 символа.
Да, такое будет работать. Но вот писать такую арифметику во всех причастных средствах — народ не обрадуется.
O>(например ujpRGpgxW4Q6AtxKfEQy7Sckw) O>И обязательно без кавычек (в трансляторах — всё что начинается с U и имеет длину 25 символов — считается guid'ом и окрашивается своим цветом).
Теперь, как в анекдоте, осталось уговорить Рокфеллера (Microsoft и всех прочих).
Здравствуйте, gegMOPO4, Вы писали:
MOP>26.12.11 09:12, netch80 написав(ла): >> Base64 тут не подойдёт из-за допустимости в нём символов типа '/' и '+'. Подбирать аналоги неудобно.
MOP>RFC3548 предлагает альтернативу с '-' и '_' вместо '+' и '/'.
Для описанной задачи не годится.
MOP> Там же описаны Base32 и Base16. MOP>А ещё можно вспомнить UUENCODE и RADIX50.
Все названные, кроме base32, заведомо менее эффективны и ущербны. UUE кроме того страдает проблемами с кодами символов ещё хуже, чем base64 (которая собственно и родилась как исправленный UUE).
26.12.11 17:47, netch80 написав(ла): > Здравствуйте, gegMOPO4, Вы писали: > MOP> Там же описаны Base32 и Base16. > MOP>А ещё можно вспомнить UUENCODE и RADIX50. > Все названные, кроме base32, заведомо менее эффективны и ущербны.
Чем же это Base16 заведомо менее эффективен и ущербен? RADIX50, конечно, придётся немного доработать. Зато дань традициям.
В наше время вообще пора переходить к Base2048, Base8192 или что-то такое. Уж несколько тысяч хорошо различимых цифро-буквенных символов в Уникоде найдётся.
Здравствуйте, netch80, Вы писали:
MOP>> Там же описаны Base32 и Base16. MOP>>А ещё можно вспомнить UUENCODE и RADIX50. N>Все названные, кроме base32, заведомо менее эффективны и ущербны.
Base16 это обычный HEX, если что. Та же самая каноническая запись, только без дефисов и {}
Здравствуйте, gegMOPO4, Вы писали:
MOP>26.12.11 17:47, netch80 написав(ла): >> Здравствуйте, gegMOPO4, Вы писали: >> MOP> Там же описаны Base32 и Base16. >> MOP>А ещё можно вспомнить UUENCODE и RADIX50. >> Все названные, кроме base32, заведомо менее эффективны и ущербны.
MOP>Чем же это Base16 заведомо менее эффективен и ущербен?
$ bc -lq
l(62)/l(16)
1.48854907759671880220
Удлинение в полтора раза на ровном месте — плохо, мягко говоря.
MOP> RADIX50, конечно, придётся немного доработать. Зато дань традициям.
В таком виде — нет. Если же его дорабатывать, он превратится в условное Base40. И чем это лучше Base62?
Для текста в пару килобайт, конечно, был бы смысл, но не для 16-байтной строки.
MOP>В наше время вообще пора переходить к Base2048, Base8192 или что-то такое. Уж несколько тысяч хорошо различимых цифро-буквенных символов в Уникоде найдётся.
Начинаем зависеть от качества чтения юзерами китайских иероглифов, деванагари и индейских узловых письменностей.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, netch80, Вы писали:
MOP>>> Там же описаны Base32 и Base16. MOP>>>А ещё можно вспомнить UUENCODE и RADIX50. N>>Все названные, кроме base32, заведомо менее эффективны и ущербны.
Кё>Base16 это обычный HEX, если что.
