| Вопрос: Нужен совет по быстрому чтению файла | Добавлено: 07.10.06 19:39 |
Автор вопроса:  Neco | Web-сайт: neco.pisem.net | ICQ: 247906854 |
| Ответы | Всего ответов: 22 |
|
Номер ответа: 16 Автор ответа:  vito Разработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #16 | Добавлено: 09.10.06 23:33 |
|
Neco
На самом деле для абонента А отведено 9 байт (2 на кол-во цифр, 16 на номер) для абонента Б - 18 (2 на кол-во, 34 на номер).
Вообще ничего не понятно. Почему для записи номера телефона отводится разное количество байт? Может имеется в виду величина смещения от начала? Первая запись заканчивается на 9 байте, вторая на 18 и т.д.? (только с изменённым порядком байт - в них даются размеры блоков и записей),
Или это способ шифрования такой? Потому как быстрый доступ к записи (по смещению) при таком неструктурированном формате невозможен. А следовательно такая форма записи несет несколько другую функциональную нагрузку. 
|
||
|
Номер ответа: 17 Автор ответа: NecoICQ: 247906854 Вопросов: 133 Ответов: 882 |
Web-сайт: Профиль | | #17 | Добавлено: 09.10.06 23:55 |
| скинул скрин | ||
|
Номер ответа: 18 Автор ответа: HOOLIGAN Вопросов: 0 Ответов: 1066 |
Профиль | | #18 | Добавлено: 10.10.06 00:16 |
|
ну если у тебя вперемешку идут номера, описания блоков и размеров, да и ещё и фамилиями всё это разбавлено, то самое тормозное будет не преобразовать номер с читабельную строку, а определение, где номер, а где всё остальное.
Хотя файла не видать - без него трудно что-то определенное сказать. |
||
|
Номер ответа: 19 Автор ответа: NecoICQ: 247906854 Вопросов: 133 Ответов: 882 |
Web-сайт: Профиль | | #19 | Добавлено: 10.10.06 00:32 |
| формат строго стуктурирован - просто у полей несколько форматов - для группы полей свой алгоритм разбора. это далеко не самый худший формат хранения из тех что я видел, я бы даже сказал "совсем неплохой". | ||
|
Номер ответа: 20 Автор ответа: vitoРазработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #20 | Добавлено: 10.10.06 00:57 |
|
Neco
Если говорить о форматах то это мне кажется упакованный десятичный или (что для номера телефона неважно) шестнадцатиричный формат. Т.е. упакованный - значит каждый байт содержит две значащие цифры. Для работы с упакованным форматом на асме есть свои команды. Тогда понятно зачем нужно знать количество цифр в телефоне. Но все равно не понятно почему запись второго номера происходит с другим смещением. Но об этом можно долго гадать.
|
||
|
Номер ответа: 21 Автор ответа: NecoICQ: 247906854 Вопросов: 133 Ответов: 882 |
Web-сайт: Профиль | | #21 | Добавлено: 10.10.06 01:31 |
| номер абонента Б может содержать префиксы выходов на сторонних операторов и ещё много всякого хлама, о котором я ничего пока не знаю. а абонент А как правило десятизначный. | ||
|
Номер ответа: 22 Автор ответа: vitoРазработчик Offline Client Вопросов: 23 Ответов: 879 |
Web-сайт: Профиль | | #22 | Добавлено: 10.10.06 03:53 |
|
Тода преобразование будет вылядеть примерно так. На скорости это не отразилось.
char t[2];
for (int i=0; i< fileSize; i++) { __asm { mov eax, dword ptr [pPtr] movzx eax, byte ptr [eax]// загружаем байт mov edx,eax // сохраняем копию //mov ebx,hexx// заружаем указатель на таблицу преобразований and al,11110000b // сбрасываем биты shr al,4 // сдвиаем вправо //xlat or ax,0x3030 // преобразуем в символ (получается быстрее чем с xlat) mov t[0],al // сохраняем в условном массиве mov eax, edx // восстанавливаем значение and al,00001111b or ax,0x3030 //xlat mov t[1],al } pPtr += sizeof( char ); } |
||