История изменений

Ах. если бы всё было так просто...

Нет, для импорта частных CSV, которые генерируются другими программами и телефонами, такая схема сойдёт. Но ни один из тех вариантов, которые я видел, не является vCard-полным. А вот если задаться задачей сохранить в CSV всё, что заполнено в контакте...

Начать с того, что в контакте может быть произвольное число телефонов. Каждому из них может быть присвоен либо стандартный тип из RFC, либо комбинация этих стандартных типов. Конечно, в большинстве случаев тип выбирается из набора (home, work, cell, voice), один из которых может комбинироваться с типом «предпочтительный». Но никто не запрещает и другие произвольные комбинации. Ещё более запутывает ситуацию то, что реально почти любое современное устройство с тем же Андроидом на борту позволяет задать и нестандартные типы.

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

А вот теперь подумаем, как всю эту хреновину (это же ОДИН контакт) вместить в ОДНУ строчку CSV так, чтобы файл оказался читаемым как для машины, так и для человека, и при этом обратимым. Задача нетривиальная, у меня в голове по крайней мере два алгоритма её реализации, и ни один из них не идеален.

(Под RFC я имел в виду, в основном, RFC 2426, регламентирующий vCard 3.0. Вообще уже давно появился vCard 4.0, но в него мало кто пишет - в обороте либо 3.0, либо 2.1, причём с годом выпуска аппарата номер версии коррелирует крайне слабо.)

Ах. если бы всё было так просто...

Нет, для импорта частных CSV, которые генерируются другими программами и телефонами, такая схема сойдёт. Но ни один из тех вариантов, которые я видел, не является vCard-полным. А вот если задаться задачей сохранить в CSV всё, что заполнено в контакте...

Начать с того, что в контакте может быть произвольное число телефонов. Каждому из них может быть присвоен либо стандартный тип из RFC, либо комбинация этих стандартных типов. Конечно, в большинстве случаев тип выбирается из набора (home, work, cell, voice), один из которых может комбинироваться с типом «предпочтительный». Но никто не запрещает и другие произвольные комбинации. Ещё более запутывает ситуацию то, что реально почти любое современное устройство с тем же Андроидом на борту позволяет задать и нестандартные типы.

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

А вот теперь подумаем, как всю эту хреновину (это же ОДИН контакт) вместить в ОДУ строчку CSV так, чтобы файл оказался читаемым как для машины, так и для человека, и при этом обратимым. Задача нетривиальная, у меня в голове по крайней мере два алгоритма её реализации, и ни один из них не идеален.

(Под RFC я имел в виду, в основном, RFC 2426, регламентирующий vCard 3.0. Вообще уже давно появился vCard 4.0, но в него мало кто пишет - в обороте либо 3.0, либо 2.1, причём с годом выпуска аппарата номер версии коррелирует крайне слабо.)