UPDATE ( SELECT t1.value, t2.CODE
FROM table1 t1
INNER JOIN table2 t2 ON t1.Value = t2.DESC
WHERE t1.UPDATETYPE='blah')
SET t1.Value= t2.CODE
There is a W3 (not-yet-released) standard named EXI (Efficient XML Interchange).
Should become THE data format for compressing XML data in the future (claimed to be the last necessary binary format). Being optimized for XML, it compresses XML more ways more efficient than any conventional compression algorithm.
With EXI, you can operate on compressed XML data on the fly (without the need to uncompress or re-compress it).
EXI = (XML + XMLSchema) as binary.
And here you go with the opensource implementation (don't know if it's already stable):
Exificient
Похоже, вас больше интересует сжатие, а не шифрование. Так ли это? Если так, то это может оказаться интересным для чтения, хотя и не является точным решением.
Между прочим, сценарий таков: я создаю стандарт для документов, таких как ODF или MS Office XML, которые содержат файлы XML, упакованные в .zip .
то я бы посоветовал вам использовать сжатие .zip, иначе ваши пользователи запутаются.
Надеюсь, я правильно понял, что вам нужно сделать ... Первое, что я хотел бы сказать, это то, что нет хорошего или плохого сжатия алгоритмы для текста - zip, bzip, gzip, rar, 7zip достаточно хороши для сжатия все, что имеет низкую энтропию - т.е. большой файл с небольшим набором символов. Если бы мне пришлось их использовать, я бы выбрал 7zip на свой первый выбор, rar как второй и третий. Но разница очень мала, поэтому стоит попробовать все, что вам будет проще. Во-вторых, я не мог понять, что вы пытаетесь зашифровать. Предположим, что это XML-файл, тогда вы должны сначала сжать его, используя свой любимый алгоритм сжатия, а затем зашифровать его с помощью вашего любимого шифрования алгоритм. В большинстве случаев любой современный алгоритм, реализованный, например, в PGP будет достаточно безопасным для чего угодно. Надеюсь, это поможет.
Ваши альтернативы:
Another alternative to "compress" XML would be FI (Fast Infoset).
XML, stored as FI, would contain every tag and attribute only once, all other occurrences are referencing the first one, thus saving space.
See:
Very good article on java.sun.com, and of course
the Wikipedia entry
The difference to EXI from the compression point of view is that Fast Infoset (being structured plaintext) is less efficient.
Other important difference
is: FI is a mature standard with many implementations.
One of them: Fast Infoset Project @ dev.java.net