"Упакованное число" - что бы это могло быть?

← →
Мирон © (2005-02-23 00:58) [0]

Здрасте всем, давненько сюда не заглядывал...

Тут такое дело... Надо прочитать файл.. Есть его описание...

struct.dat
---
Набор записей следующего вида:
1 байт - раздел рубрикатора (цифры "0", "1" или "2")
255 байт - название раздела
4 байта - упакованное число, кол-во вопросов,
принадлежащих данному разделу
4 байта - упакованное число, смещение в файле sections.ref
до перечня номеров вопросов, приписанных
к данному разделу

Вот что дает первая запись: "0 Грамматические трудности -1425932288 -1339424768" (остальное - того же типа)...
Первое и второе - верно, третье и четвертое - хрень какая-то...

Читаем так:

var ID: String; Size: Integer; Name: String; QCount, SRef: Integer; begin SetLength(ID, 1); AStream.Read(ID[1], 1); Size := 255; SetLength(Name, Size); AStream.Read(Name[1], Size); AStream.Read(QCount, SizeOf(Integer)); AStream.Read(SRef, SizeOf(Integer));

Так вот... Если "упакованное число" в данном случае не "Integer", то что это может быть?

← →
GanibalLector © (2005-02-23 01:37) [1]

Вот разница между Integer и 4 байтами :
MessageDlg( "Ineteger:"+inttostr(High(Integer))+#10#13+ "DWord :"+inttostr(High(DWord)),mterror,[MbOk],0);

← →
Мирон © (2005-02-23 01:49) [2]

GanibalLector © (23.02.05 1:37) [1]
Ну, ладно... Имеем разницу в один бит, используемый под знак...
Только это не спасло комбинатора...

... QCount, SRef: DWord; ...

имеем

"0 Грамматические трудности 2869035008 2955542528"

Или я не так понял намек?

← →
GanibalLector © (2005-02-23 02:15) [3]

>Или я не так понял намек?
Правильно понял ;)
З.Ы.Извини,но мне в лом ... Я тут отдыхаю ;)

← →
GanibalLector © (2005-02-23 02:21) [4]

А нафига тебе этот AStream сдался?
ИМХО у тебя с ним проблемы. Попробуй стандартно считать...должно получиться.
З.Ы.Я вот например не пользуюсь ТStream.А обычно в потоке на АПИ читаю\пишу.Пока нравиться и мне пофиг,что думают об этом остальные.

← →
Мирон © (2005-02-23 02:54) [5]

GanibalLector © (23.02.05 2:21) [4]
Не... А че Stream-то сразу?
Первые 256 байт каждой записи считываются правильно ведь.... Проблема в том, что непонятно как в следующих 8 байтах хранятся 2 целых числа...

К слову, чувак, который генерил этот файл, генерил его из MySQl-вской базы... Не знаю правда чем он точно пользовался, но не "нормальными" средствами разработки приложений... На Perl"e, что-ли делал... хрен его знает, какие они там эти "упакованные"...

← →
GanibalLector © (2005-02-23 02:58) [6]

А что хоть должно получиться?Тебе известно?
Может перевернуть надо или еще чего...

← →
GanibalLector © (2005-02-23 03:01) [7]

Кстати,где-то я это встечал : "упакованные"
Толи в схемотехнике,толи в логике.Что-то такое было...

← →
Мирон © (2005-02-23 03:04) [8]

GanibalLector © (23.02.05 2:58) [6]
Ну, конкретные значения не известны... Но по логике - это не большие величины...
Он присылал один скриншот, с изображением того как это должно выглядеть в конечном итоге...
Так вот, там в разделе "Грамматических трудностей" значится 140 вопросов... Видимо, и здесь должна быть эта цифра..
Ну а вторая цифра (смещение) - там размер файла всего 50 кб, так что не больше 50*1024...

← →
GanibalLector © (2005-02-23 03:13) [9]

Кстати,ты бы спросил... какое оно упакованное?
в шестнадцатеричной AB020000 2869035008 B02A0000 2955542528
Судя по всему последние два байта выкидывай и попробуй что-нибудь...

← →
Мирон © (2005-02-23 03:33) [10]

GanibalLector © (23.02.05 3:13) [9]
:) Ну, если до четверга не разберусь, буду спрашивать, ессно... Когда он на работу выйдет..

← →
Мирон © (2005-02-23 03:38) [11]

хм.. прикольно.. в файле всего 86 записей и в каждой последние два байта последних двух чисел - нули...

но... первые два тоже не дают ничего вразумительного

← →
SammIk © (2005-02-23 03:39) [12]

Поисчи про двоичнодесятичные чмсла.
Там есть упакованые и нет, может поможет).
Ищи - BCD числа

← →
begin...end © (2005-02-23 08:01) [13]

> Мирон © (23.02.05 0:58)

> Если "упакованное число" в данном случае не "Integer",
> то что это может быть?

Это, как уже сказал SammIk, может быть BCD-число (двоично-десятичное). Принцип формирования неупакованных BCD-чисел такой: берётся очередная цифра десятичного числа, под неё выделяется один байт, и в этот байт записывается значение этой цифры. Очевидно, что старшая тетрада байта при этом останется незаполненной. Вот так, например, будет выглядеть десятичное число 39 в неупакованном формате:

- в шестнадцатеричной системе: 03 09 - в двоичной системе: 00000011 00001001

В упакованном BCD-числе используется ещё и старшая тетрада байта, т.е. в одном байте умещаются две десятичные цифры. То же число 39 будет выглядеть так:

- в шестнадцатеричной системе: 3 9 - в двоичной системе: 0011 1001

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

← →
VMcL © (2005-02-23 08:33) [14]

>>begin...end © (23.02.05 08:01) [13]

>берётся очередная цифра десятичного числа, под неё выделяется один байт

полубайт

← →
SammIk © (2005-02-23 09:28) [15]

2 14
Полубайт это для упакованных))

← →
Набережных С. © (2005-02-23 09:29) [16]

> VMcL © (23.02.05 08:33) [14]

Нет, под НЕупакованные - байт, begin...end прав.

← →
Anatoly Podgoretsky © (2005-02-23 09:34) [17]

Мирон © (23.02.05 00:58)
Привел бы хекс значения пары строк ланных и реальные значения чисел если известно.

← →
Мирон © (2005-02-23 11:10) [18]

Anatoly Podgoretsky © (23.02.05 9:34) [17]

первая пара чисел AB020000 B02A0000 (GanibalLector был прав)...
в фаре эти 8 байт выглядят несколько иначе 00 00 02 AB 00 00 2A BO

ну еще строчка 64010000 5С350000
в фаре 00 00 01 64 00 00 35 5С

На счет точных значений не уверен, но предположительно, что первое число первой пары "140", как я уже и говорил...

← →
Мирон © (2005-02-23 11:42) [19]

begin...end © (23.02.05 8:01) [13]

почитал про BCD-числа.... получается, что в шестнадцатиричном представлении такого числа не может быть разрядов, содержащих a..f (кроме самой страшей триады)..
А здесь это есть...

← →
begin...end © (2005-02-23 11:43) [20]

> Мирон © (23.02.05 11:10) [18]

Ну что ж... Теперь понятно, что это явно не BCD.

А в Фаре они нормально выглядят - сначала младший байт, потом старший и т.д.

Теряюсь в догадках.

← →
begin...end © (2005-02-23 11:47) [21]

> Мирон © (23.02.05 11:42) [19]

> получается, что в шестнадцатиричном представлении такого
> числа не может быть разрядов, содержащих a..f

Верно.

> кроме самой страшей триады

Где Вы это прочитали?

← →
Мирон © (2005-02-23 11:54) [22]

begin...end © (23.02.05 11:47) [21]
ссылку не дам, не помню... :)
читал, что эта тетрада используется под знак 1010 "+" 1011 "-"
или наоборот

← →
Anatoly Podgoretsky © (2005-02-23 12:10) [23]

То есть ни какими упаковаными BCD здесь и не пахнет

← →
Мирон © (2005-02-23 12:17) [24]

Anatoly Podgoretsky © (23.02.05 12:10) [23]
угу.. и не упакованными тоже....

← →
Anatoly Podgoretsky © (2005-02-23 12:51) [25]

Тебе надо преобрести или паяльник или утюг и к автору в гости, расколется как миленький.

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

дозвонился-таки до этого чела... он поведал, что это "большое целое, упакованное php-функцией до 4 байт"...
завтра обещал выслать порядок байт для распаковки... и че было так мудрить....

Похоже это просто Word -> dWord, возможно со смененым порядкоа байт по этому младшии байты равны нулю. Во всяком случае надо выяснять, желательно с примерами чисел.

Вот какое значит дело... Цитирую...
----------8<--------------------

Теперь по поводу упакованного числа.
Формат: 32 bit, порядок следования байтов - big endian
Другими словами, число получается, если произвести следующие операции:
байт0 * (2 в степени 24) +
байт1 * (2 в степени 16) +
байт2 * (2 в степени 8) +
байт3 * (2 в степени 0)

Я проверил, числа распаковываются.
Но, поскольку это стандартный формат хранения большого целого,
думаю, предусмотрены какие-то стандартные функции для его получения
(в PHP, например, это unpack()).

----------8<--------------------

Много народу слышало про этот "стандартный формат"? Я -нет...

Обратный порядок байт, поменяй порядок и получишь обычный integer.

64 01 00 00 -> 00 00 01 64 -> 356
5С 35 00 00 -> 00 00 35 5c -> 13360

Стандарные Windows - htonl, ntohl
Стандарные - не знаю, видимо нет.

function unpack(I: DWORD): DWORD;
asm
BSWAP EAX
end;

PЗабавно, а почему поменяв направления байт - назвали упакованным?

Оставим на совести называльщика.

"Упакованное число" - что бы это могло быть? Найти похожие ветки