как узнать длину ХМЛ строки в байтах
 

Ваяю приложение для контакта,
Нужно сохранить небольшой хмл на сервере контакта.
Разрешено сохранять 480 переменных по 255байт, итого чуть менее 120кб.
ХМЛ может быть разной длины, итого появляется задачи:
во-первых проверить размер данных необходимых для хранения ХМЛ строки,
во-вторых разбить его на кусочки по 255 байт и сохранить, а затем считать обратно.

Подскажите пожалуйста, кто сталкивался с подобными вопросами.

в хмл могут быть русские буквы))

Если русские буквы, то юникод и 2 байта на символ. Берем длину строки и умножаем на 2.

А лучше не извращаться и сделать нормальную серверную часть.

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

Мне как-то ссыкотно связываться с вконтактовским хранилищем :)
1. Оно ущербно
2. Вконтакт может что-нибудь поменять, или вообще убрать его по причине ущербности
3. Сохраняемые значения не защищены. При желании можно декомпилировать флэшку, вытащить оттуда api_secret и получить полный доступ к переменным приложения.

можно попробовать через ByteArray#writeUTF() или ByteArray#writeUTFBytes( ). В первом случае записывается длина строки UTF-8 в байтах (в виде 16-разрядного целого числа), а во втором не записывается, но узнать длину можно через свойство ByteArray#length.

1. Почему?
2. Хранилище используется уже больше чем пол года, пользователей больше миллиона. Ничего не менялось.
3. Не оч понял о каких переменных можно трястись, но заливать файлы на сервера вконтакта можно и через не проверенные приложения.

2. "Моя страница" контакта весит больше, чем полмегабайта. Их "фото начали грузиться быстрее" — это тупое прелоадинг фото в фоном режиме. Будь у меня не анлим я бы их зарезал. Пользователей IE они прямо просят поставить нормальный браузер (где-то страничка была от них, вроде редиректит если что-то не так). А их "образцовые" флеш-приложения-примеры с точки зрения кода это кошмар. А теперь им ещё и регистрацию прикрыли. Кстати, официально поддерживаемый враппер серьезно страдает по функционалу. Адекватности и "ничего не поменяется"... я не стал бы наедятся на это.

3. Хранить такие большие объемы данных скорее всего нужно не просто так. Там будут содержаться какие-то важные данные, а получить к ним доступ будет как ать-два.

4. Контакт периодически сбрасывает эти переменные. Сам не сталкивался, но слухи-духи так говорят.

Ага, периодически откатывались данные. Бессистемно, но неприятно, хотя хранили там только одноразовые показы окошек.

Потому, что его видимо зафигачили в черновом варианте сразу после запуска платформы для приложений, а вот доработать либо убрать уже рука не поднялась.

Потому, что его размер жестко ограничен до смешного предела в районе 1 мегабайта.

Потому, что оно очень похоже на кусок сырого дискового пространства с кластерами по 255 байт, и для хранения больших объемов данных разработчик должен реализовать поверх него аналог файловой системы либо базы данных, включая всякие вкусности типа дефрагментаторов, которые веб-разработчики пишут лучше всего.

Потому, что оно напоминает адресное пространство данных какого-нибудь микроконтроллера Гарвардской архитектуры, в которое объединена вся его перефирия: каждый раз нужно несколько раз подумать и перечитать даташит, прежде чем записать или считать байт, ведь по одним адресам значения зависят от фазы луны, по другим просто меняются с большой скоростью, в третьи можно только писать, причем это проецируется еще куда-нибудь, а при сочетании определенных значений в определенных ячейках, питание с землей внутри соединяется накоротко, и камень выпускает жалобную струйку дыма.

Фигурально выражаясь.

Архитектура тут не при чем.

Добавлено через 4 минуты
Э! Мы от темы отвлеклись. Пост номер пять ответил на вопрос.