Действительно простое сжатие коротких струн

Я думаю, что ключевой вопрос здесь: «Почему вы хотите сжимать URL-адреса?»

Пытаетесь сократить длинные URL-адреса в адресной строке?

Вам лучше где-нибудь сохранить исходный URL-адрес (база данных, текстовый файл ...) вместе с хэш-кодом части, не относящейся к домену (MD5 в порядке). Затем у вас может быть простая страница (или какой-нибудь HTTPModule, если вы чувствуете себя броско) для чтения MD5 и поиска реального URL-адреса. Так работают TinyURL и другие.

Например:

http://mydomain.com/folder1/folder2/page1.aspx

Может быть замкнут на:

http://mydomain.com/2d4f1c8a

Использование библиотеки сжатия для этого не сработает. Строка будет сжата в более короткое двоичное представление, но преобразование ее обратно в строку, которая должна быть действительной как часть URL-адреса (например, Base64), сведет на нет любую выгоду, которую вы получили от сжатия.

Храните много URL-адресов в памяти или на диске?

Используйте встроенную библиотеку сжатия в System.IO.Compression или библиотеку ZLib, которая проста и невероятно хороша. Поскольку вы будете хранить двоичные данные, сжатый вывод будет в порядке как есть. Вам нужно будет распаковать его, чтобы использовать в качестве URL-адреса.

Как предлагается в принятом ответе, использование сжатия данных не работать над сокращением уже довольно коротких URL-путей.

DotNetZip имеет класс DeflateStream, который предоставляет статический (общий в VB) CompressString. Это однострочный способ сжатия строки с помощью DEFLATE (RFC 1951). Реализация DEFLATE полностью совместима с System.IO.Compression .DeflateStream, но DotNetZip сжимает лучше. Вот как это можно использовать:

string[] orig = {
    "folder1/folder2/page1.aspx",
    "folderBB/folderAA/page2.aspx",
};
public void Run()
{
    foreach (string s in orig)
    {
        System.Console.WriteLine("original    : {0}", s);
        byte[] compressed = DeflateStream.CompressString(s);
        System.Console.WriteLine("compressed  : {0}", ByteArrayToHexString(compressed));
        string uncompressed = DeflateStream.UncompressString(compressed);
        System.Console.WriteLine("uncompressed: {0}\n", uncompressed);
    }
}

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

original    : folder1/folder2/page1.aspx
compressed  : 4bcbcf49492d32d44f03d346fa0589e9a9867a89c5051500
uncompressed: folder1/folder2/page1.aspx

original    : folderBB/folderAA/page2.aspx
compressed  : 4bcbcf49492d7272d24f03331c1df50b12d3538df4128b0b2a00
uncompressed: folderBB/folderAA/page2.aspx

Таким образом, вы можете видеть, что «сжатый» байтовый массив, представленный в шестнадцатеричном формате, длиннее оригинала, примерно в 2 раза больше. Причина в том, что шестнадцатеричный байт на самом деле состоит из двух символов ASCII.

Вы можете немного компенсировать это, используя base-62 вместо base-16 (шестнадцатеричный) для представления числа. В этом случае a-z и A-Z также являются цифрами, что дает вам 0-9 (10) + a-z (+26) + A-Z (+26) = всего 62 цифры. Это значительно сократит вывод. Я этого не пробовал. пока что.

РЕДАКТИРОВАТЬ
Хорошо, я протестировал кодировщик Base-62. Он укорачивает шестигранную строку примерно наполовину. Я подумал, что это сократит его до 25% (62/16 = ~ 4), но я думаю, что я что-то теряю с дискретизацией. В моих тестах результирующая строка в кодировке base-62 примерно такой же длины, как и исходный URL. Итак, нет, использование сжатия и затем кодирования base-62 по-прежнему не является хорошим подходом. вам действительно нужно хеш-значение.

Я бы посоветовал поискать в пространстве имен System.IO.Compression < / а>. Есть статья о CodeProject, которая может помочь.

Я только что создал схему сжатия, нацеленную на URL-адреса и обеспечивающую сжатие около 50% (по сравнению с представлением исходного текста URL-адреса в формате base64).

см. http://blog.alivate.com.au/packed-url/

Было бы здорово, если бы кто-нибудь из крупной технологической компании построил это должным образом и опубликовал для всех. Google выступает за буферы протокола. Этот инструмент может сэкономить много места на диске для кого-то вроде Google, оставаясь при этом поддающимся сканированию. А может, сам великий капитан? https://twitter.com/capnproto

Технически я бы назвал это схемой двоичной (побитовой) сериализации данных, лежащих в основе URL. Рассматривайте URL-адрес как текстовое представление концептуальных данных, затем сериализуйте эту концептуальную модель данных с помощью специализированного сериализатора. В результате, конечно же, получилась более сжатая версия оригинала. Это сильно отличается от того, как работает алгоритм сжатия общего назначения.

Какая у тебя цель?

• Более короткий URL? Попробуйте сократить URL-адреса, например http://tinyurl.com/ или http://is.gd
• Пространство для хранения? Проверьте System.IO.Compression. (Или SharpZipLib)

Вы можете использовать алгоритм дефляции напрямую, без контрольных сумм заголовков или нижних колонтитулов, как описано в этом вопросе: Python: Реализации Inflate и Deflate

В моем тесте это сокращает URL-адрес с 4100 символов до 1270 символов base64, что позволяет ему уместиться в пределах 2000 IE.

Я бы начал с одной из существующих (бесплатных или с открытым исходным кодом) zip-библиотек, например http://www.icsharpcode.net/OpenSource/SharpZipLib/

Zip должен хорошо работать с текстовыми строками, и я не уверен, стоит ли применять алгоритм сжатия на вашем сервере ...

Вы пробовали просто использовать gzip?

Не знаю, будет ли он эффективно работать с такими короткими струнами, но я бы сказал, что это, вероятно, ваш лучший выбор.

Библиотека с открытым исходным кодом SharpZipLib проста в использовании и предоставит вам инструменты сжатия

Почему? Вероятно, есть лучший способ сделать то, о чем вы просите.