2005 versie van de CD-Foongids (5)

Weerman · 7 mei 2005 om 18:26

Vrienden van het Telefoonboek!

Even de hand opsteken, wie denkt dat je de roze en witte databestanden op de nieuwe CD-foongids 2005/2006 zomaar onderling kan verwisselen? Precies wat ik zelf ook dacht, maar het kan wel.

Even kort vooraf:
Verschil tussen roze en wit: de abonnees in het witte katern willen niet zomaar gebeld worden maar degene die voor geld in het roze deel, de Bedrijvengids is gaan staan, die wil graag dat je belt.

Misschien dat het zoeken in roze daarom ook wat losser geregeld is, bij 1 ingetikte letter komt er al wat en dat mag in “Heel Nederland”. Kan natuurlijk ook vanwege de ‘performance’ zijn want jammer genoeg voor DTG, in roze staat ruwweg maar een tiende van het aantal witte vermeldingen dus kan er minder selectief in gezocht worden zonder dat je de hele gids in één keer terugkrijgt.

Zou je aan de roze kant in wit kunnen zoeken? Simpelweg in de “Data”-map op de CD-foon alles wat met de p van pink cdp.* heet ‘renamen’ naar cdw.* en andersom de bestandsnamen van de oorspronkelijke cdw’s op hun beurt veranderen in cdp.zus en cdp.zo.

Weet ik veel, vanwege de compressie en de versleuteling is vaak toch niet duidelijk wat erin zit, ik doe hetzelfde met de de cdc- en cdt-bestanden, van cdc maak ik cdt en omgekeerd. Geluk gehad, ik hoefde er maar eentje terug te draaien en daarna werkte het, er kwam opeens strooikaas uit de gehaktmolen. Bij 1 letter in ‘Bedrijfsnaam’ kreeg ik onmiddellijk van alles terug uit “heel Nederland”.

Het werkte een-soort-van zag ik al snel, want merkwaardig fenomeen, je begint iets in te voeren bij ‘Bedrijfsnaam’, de zoekhulp klapt open, je kan ook zoals in wit dezelfde selectie uit de abonnee-namen maken en dan gaat de CD-foongids blij aan het werk. Komt ie terug met een lijst abonnees, die wel lang is maar nergens op slaat in termen van het zoekargument.

Wat blijkt, het zijn de straatnamen die voldoen aan het achternaam-criterium. Het ding is toch van slag en keert raar maar waar met z’n naam-opdracht terug in de straat-kolom, een brug te ver in de Resultatenlijst.

Maar we klagen niet en kijken nog even verder: voor de hand liggende drieletter-combinaties geven consistent lange lijsten vermeldingen in dezelfde straat(-naamdelen) in de verschillende plaatsen met zo’n straat(-naamdeel). Zoals gebruikelijk in eerste instantie op achternaam gesorteerd, als je er doorheen wil lopen kan je dat aanpassen, bijv. sorteren op plaatsnaam of postcode.

Of op een “achter”-naam zoeken waarvan je weet dat het ook de straatnaam is, zoals bijvoorbeeld “Erasmushuis” in “Goes” levert keurig alle bewoners A… tot en met W… van deze serviceflats.

Weerman · 7 mei 2005 om 18:31

Leuk geweest, doe maar weer terug? Misschien, maar iemand die graag wil weten hoe de CD-foongids in elkaar steekt kan hiermee in principe weer een stap verder. Met de notie van hoe het
http://forums.virtualconspiracy.com/foondump/viewtopic.php?p=823#823][u]XML[/u
-schema eruitziet en deze aanvullende mogelijkheid om gecontroleerd blokken vermeldingen te genereren zou hij meer grond onder de voeten kunnen krijgen.

We nemen even aan dat de gegevens zowel gecomprimeerd als versleuteld op de CD staan.

In het verleden was de verzender onherroepelijk de pineut als iemand die al kon meeluisteren de beschikking kreeg over "
http://www.objectsspace.com/encyclopedia/index.php/Known-plaintext_attack]"[u]known-plaintext[/u
. Dan was het alleen nog maar een kwestie van cryptografie-recepten toepassen en de boodschappen werden leesbaar. Dat zou hieranders kunnen liggen omdat ze intussen niet stil gezeten hebben en bijv. ook omdat er voor de encryptie al compressie gehanteerd is. Maar bijvoorbeeld het bekende “ZIP”-formaat is tot op de dag van vandaag kwetsbaar op dat punt.

Is dat zo, is het spul daadwerkelijk gecomprimeerd en versleuteld?

Compressie: net als bij die in beslag genomen auto uit de “French Connection” kan je het netto gewicht proberen te vergelijken, de laatste CD uit 2004 had 465 Mb aan data (zonder die voor de routeplanner), 20 Mb meer dan nu, weer zonder routeplanner en POI, points-of-interest. Als je al es wat geprobeerd had met dat details.xsl dan heb je gemerkt hoe die XML-bestanden die eruit komen kunnen uitdijen, dat gaat heel hard. Daar staat tegenover dat ze vanwege het repeterende karakter van die tags heel goed te comprimeren zijn, je haalt zomaar ratio’s van over de 90%.

Encryptie: van
http://forums.virtualconspiracy.com/foondump/viewtopic.php?p=775#775]alles
wijst erop, je kan bijvoorbeeld zoals [u]RGJ[/u dat deed in de samenstellende delen van het programma kijken en dan kom je dit tegen:

Z:\ctwork_voorgezet\tgi_relaunch_encrypted_20041012.…

Weerman · 7 mei 2005 om 18:39

Nog één ander dingetje voor we het programma in de oude staat terugbrengen*), we kunnen nu immers op straatnaam zoeken?

Eventjes kijken hoe het zit met
http://www.foondump.nl/download/spooknummers.html][u]wijngummetje[/u
and friends…

Gone! Waren deze adressen - in verzetstermen - stuk, dus onbruikbaar geworden omdat ze in dit forum gepubliceerd waren? Alleen daar waar KPN-dochters of aan de KPN gelieerde ondernemingen gevestigd zijn rammelt het nog beetje, op de Delflandlaan 15 (hoofdkantoor DTG bv) blijft 's avonds als iedereen naar huis is ene Stekelenburg achter. Heeft niet eens een telefoonnummer maar staat dus wel tot in 2006 op de CM-versie van de CD-foongids.

Komt er niet uit bij Telefoongid.nl, wat altijd al een veeg teken was.

Wie daar nu wel uit komt is Eck, Rinus van met als adres Europalaan 200 in Utrecht waar volgens mij vroeger het hoofdkantoor van KPN-dochter SNT zat waaronder o.a. de nummerinformatiedienst valt/viel? Eck van stond al eerder op de CD en op de spooklijst met 020-4086180 (in Utrecht) en ook 06-511345087 (een digit teveel) en nu opnieuw met dat laatste nummer.

*) gebruikte een
http://download.microsoft.com/download/7/b/6/7b6abd84-7841-4978-96f5-bd58df02efa2/winxpvirtualcdcontrolpanel_21.exe][u]cdrom-emulator[/u
van Microsoft waarin ik de geprepareerde ISO-bestanden kon laden die ik met ander hulpmiddel, cdimage, samenstelde. Allemaal omdat DTGWin zich niet liet vermurwen: zonder CD-rom in de speler wil die niet, ook niet als ik het dataidx:-pad veranderde in het configuratiebestand dtgwin.ini. Maar je hoeft dus niet twee of drie nieuwe CD’s te branden om wat te experimenteren.

skysoft · 8 mei 2005 om 19:30

Hmm, een opmerkelijk experiment. Het geeft op een aantal punten wel een blik onder de motorkap, ook al is het voor nu met 1 oog voor een paar seconden. :shock:

het staat voor mij in ieder geval inmiddels vast dat er een vorm van encryptie wordt gebruikt. Als je de functies van de dll’s exporteert en bekijkt zie je termen als : encrypt, decrypt, password etc. voorbij komen. Ook tijdens het opvragen van een record, roept het hoofdprogramma verschillende keren de cd-rom aan met het verzoek tot opgave van de lengte van een bepaals file (naam weet ik ffe niet) om er daarna niets mee te doen. Dit herhaalt zich geregeld.

Nu kan er niet zo’n heel sterke encryptie en compressie plaatsvinden, als je bedenkt hoe snel het programma is.

Morgen eens een softijsje afstoffen, kijken of we dan verder komen… :lol:

//edit : ik voel trouwens weer nachtwerk aankomen…

rgj · 8 mei 2005 om 21:15

Kijk, dat klinkt goed!
Ben ondanks chronisch tijdsgebrek ook begonnen met het ‘droog’ analyseren van de datafiles. Ik stel voor om bevindingen in dit forum uit te wisselen.

Weerman · 9 mei 2005 om 19:37

Zie wel wat… :o)

met Visual Basic wrapper voor Zlib.dll

Attribute VB_Name = "modTest"
Sub main()
Dim zl As clsZL, b() As Byte, succes As Long

  Set zl = New clsZL
  Debug.Print "[code]"
  Debug.Print "met Visual Basic wrapper voor Zlib.dll"
  Debug.Print
  Debug.Print readFN("modTest.bas", 4096)
  Debug.Print "[/code]"
  b = getBinaryFile("Z:\Install\program files\De Telefoongids\CD-foongids\Data\cdp.ddb")
  Debug.Print "[code]"
  Debug.Print "cdp.ddb:"
  Debug.Print
  Debug.Print HexDump(StrPtr(b), 512)
  Debug.Print "[/code]"
  succes = zl.DecompressData(b, UBound(b))
  Debug.Print "[code]"
  Debug.Print "idem decompressed:"
  Debug.Print
  Debug.Print HexDump(StrPtr(b), 512)
  Debug.Print "[/code]"
  Debug.Print "[code]"
  Debug.Print "corresponderende XML??"
  Debug.Print
  Debug.Print readFN("nawt.xml", 4096); "..."
  Debug.Print "[/code]"
   
End Sub

Function readFN(fn As String, n As Long)
  With New FileSystemObject
    With .OpenTextFile(fn)
      readFN = .Read(n)
    End With
  End With
End Function

Function getBinaryFile(strFilePath)
Dim oStream As ADODB.Stream, TypeBinary
  TypeBinary = 1
  With New ADODB.Stream
    .Open
    .Type = TypeBinary
    .LoadFromFile strFilePath
  getBinaryFile = .Read(.Size)
  End With
End Function

cdp.dbb:

========================================================================
0000  78 DA ED 7D D9 6E 1B 59  96 60 BC F7 4C B7 64 9B  x..}.n.Y.`..L.d.
0010  B6 D3 53 33 BE A2 48 C9  76 59 36 83 BB 12 68 8C  ..S3..H.vY6...h.
0020  83 8B 48 ED 34 49 51 4B  3D 8C 82 E4 15 19 E2 12  ..H.4IQK=.......
0030  74 44 50 B4 84 7E B0 D3  76 7A 79 92 95 99 74 56  tDP..~..vzy...tV
0040  A1 81 B6 D3 CE 15 68 20  31 E8 97 7C 9C 82 D1 ED  ......h 1..|....
0050  0F 48 A0 5E EA 07 1A F3  38 3F 30 E7 DC 08 32 82  .H.^....8?0...2.
0060  D4 62 49 96 6D A9 92 85  82 D3 0E DE B8 E7 DC B3  .bI.m...........
0070  9F 73 CF BD 71 F6 DF FA  FE F7 D3 7E 8F 3D C2 5D  .s..q......~.=.]
0080  B4 BB 88 DB 3B E2 71 7B  88 CB EF 1A 25 31 5A CE  ....;.q{....%1Z.
0090  53 45 25 B1 B2 A8 DA 09  E7 8C 4D 09 2E 9F 03 FF  SE%.......M.....
00A0  C5 5D 4D 4F CF 90 F1 B0  90 8C 70 FF 2A AE 6D DC  .]MO......p.*.m.
00B0  F9 79 D0 FB F0 4F 1C AF  3F F9 AB 98 BE E1 0B 87  .y...O..?.......
00C0  FF D7 D4 F8 4C D4 11 8F  46 C7 D2 64 8E C0 CB A9  ....L...F..d....
00D0  54 38 2E 44 A2 E4 7F 72  ED 5F 43 D1 29 12 4B 0A  T8.D...r._C.).K.
00E0  E9 F1 14 71 05 5D AE 11  97 DB 4D 78 9E 78 3C E6  ...q.]....Mx.x<.
00F0  90 79 5A 2E 51 52 00 A8  AA 2C 2B 1A A9 13 59 2E  .yZ.QR...,+...Y.
0100  91 06 AD AA 1A B9 76 ED  DA 55 73 64 9E 6E D0 F2  ......v..Usd.n..
0110  4A 9E 92 BC 58 20 05 5A  A6 6B 54 C9 13 5A 85 BF  J...X .Z.kT..Z..
0120  57 E4 AA 46 F1 5F 03 30  5C 1F 6D BE 17 8B 4E 45  W..F._.0\.m...NE
0130  A2 C9 14 43 91 7C 6A 3E  17 C2 E1 E8 4C 9A CC 26  ...C.|j>....L..&
0140  48 2A 9A CC 8C 87 A3 5C  60 DC F8 A9 D1 68 5C 2B  H*.....\`....h\+
0150  E8 E4 41 CC AE 55 CB D6  79 8D B5 D1 32 29 28 A2  ..A..U..y...2)(.
0160  26 A9 A4 02 43 4B 62 85  2A DC 5F C8 AF 3A B1 F3  &...CKb.*._..:..
0170  8B DC F9 0E CA 77 2C 7F  1B ED 81 74 5E 9F 23 95  .....w,....t^.#.
0180  2B 4A EC 79 96 E6 15 69  75 8D 56 75 4E 4C 05 43  +J.y...iu.VuNL.C
0190  C9 B0 C7 64 C5 0B EE AF  37 AF F4 78 F0 36 1E FC  ...d....7..x.6..
01A0  A5 6F 61 46 70 4C 8A 55  0D 56 45 66 A4 D5 0A 2D  .oaFpL.U.VEf...-
01B0  00 49 7F F5 85 85 5B CF  0F C8 A0 4C 34 19 0C 3A  .I....[....L4..:
01C0  32 54 D9 A0 25 AA 48 D5  C2 6E BC F9 A6 C7 9B A3  2T..%.H..n......
01D0  E0 CD D9 03 F0 26 39 3B  05 86 2B 29 97 CB 75 A9  .....&9;..+)..u.
01E0  04 EB 85 FF 2B 72 B9 48  4B A5 6D 4C DA F8 FC 39  ....+r.HK.mL...9
01F0  32 E9 DB 4E 26 8D 45 47  66 93 48 32 51 2C 00 FD  2..N&.EGf.H2Q,..
========================================================================

idem decompressed:

========================================================================
0000  16 B4 10 B2 91 11 33 22  44 00 1F 22 30 20 32 34  ......3"D.."0 24
0010  2D 33 32 33 20 30 36 30  39 20 47 65 6C 64 65 72  -323 0609 Gelder
0020  73 20 47 6C 61 73 22 20  00 25 47 4C 41 30 35 24  s Glas" .%GLA05$
0030  47 6C 61 73 00 2C 54 4D  4E 20 49 43 41 52 44 00  Glas.,TMN ICARD.
0040  AD 61 76 7A 80 B0 23 34  87 9A 00 31 49 43 41 52  .avz..#4...1ICAR
0050  44 00 DC 61 54 40 35 43  43 5F 4C 49 4E 45 24 48  D..aT@5CC_LINE$H
0060  45 45 46 54 20 55 20 47  4C 41 53 53 43 48 41 44  EEFT U GLASSCHAD
0070  45 20 3F 00 35 43 43 5F  4C 49 4E 45 24 42 45 4C  E ?.5CC_LINE$BEL
0080  20 47 52 41 54 49 53 20  30 38 30 30 2D 30 32 32   GRATIS 0800-022
0090  20 31 31 20 33 33 00 35  43 43 5F 4C 49 4E 45 24   11 33.5CC_LINE$
00A0  57 65 6C 6B 65 20 67 6C  61 73 73 6F 6F 72 74 20  Welke glassoort 
00B0  75 20 6F 6F 6B 20 77 65  6E 73 74 20 2E 2E 2E 2C  u ook wenst ...,
00C0  00 35 43 43 5F 4C 49 4E  45 24 64 65 7A 65 6C 66  .5CC_LINE$dezelf
00D0  64 65 20 64 61 67 20 67  65 6C 65 76 65 72 64 20  de dag geleverd 
00E0  65 6E 20 67 65 6D 6F 6E  74 65 65 72 64 20 21 00  en gemonteerd !.
00F0  35 43 5F 4C 49 4E 45 24  00 35 43 43 5F 4C 49 4E  5C_LINE$.5CC_LIN
0100  45 24 47 45 4C 44 45 52  53 20 47 4C 41 53 20 3A  E$GELDERS GLAS :
0110  00 35 43 43 5F 4C 49 4E  45 24 41 43 43 45 4E 54  .5CC_LINE$ACCENT
0120  20 4F 50 20 53 45 52 56  49 43 45 00 37 49 43 5F   OP SERVICE.7IC_
0130  4C 49 4E 45 24 77 77 77  2E 67 65 6C 64 65 72 73  LINE$www.gelders
0140  67 6C 61 73 2E 6E 6C 00  35 43 5F 4C 49 4E 45 24  glas.nl.5C_LINE$
0150  00 35 43 5F 4C 49 4E 45  24 42 65 6C 20 67 72 61  .5C_LINE$Bel gra
0160  74 69 73 20 6D 65 6C 64  6B 61 6D 65 72 00 D7 20  tis meldkamer.. 
0170  D4 91 11 33 22 44 00 64  59 00 18 B4 10 B2 91 11  ...3"D.dY.......
0180  33 22 44 00 1F 22 30 20  38 30 30 2D 30 32 32 20  3"D.."0 800-022 
0190  31 31 20 33 33 20 47 65  6C 64 65 72 73 20 47 6C  11 33 Gelders Gl
01A0  61 73 22 20 00 25 53 43  48 34 35 24 53 63 68 69  as" .%SCH45$Schi
01B0  6C 64 65 72 73 62 65 64  72 69 6A 76 65 6E 00 2C  ldersbedrijven.,
01C0  54 4D 4E 20 4C 38 42 52  43 33 00 AD 61 76 7A 80  TMN L8BRC3..avz.
01D0  B0 23 34 87 A1 00 DC 51  2A 40 35 43 43 5F 4C 49  .#4....Q*@5CC_LI
01E0  4E 45 24 48 45 45 46 54  20 55 20 47 4C 41 53 53  NE$HEEFT U GLASS
01F0  43 48 41 44 45 20 3F 00  35 43 43 5F 4C 49 4E 45  CHADE ?.5CC_LINE
========================================================================

corresponderende XML??

<xmliresponse>
   <tginlstatus>
      <action>pink</action>
      <internet>true</internet>
   </tginlstatus>
   <basiclisting line_type="T_LINE">
      <recordid>AAKTlDTUXszdsVScQdba</recordid>
      <area_code>0800</area_code>
      <phone_no>0221133</phone_no>
      <display_name>
         <print_name2>"0 24-323 0609 Gelders Glas" </print_name2>
      </display_name>
      <classification_info>
         <trade_name key="GLA05">Glas</trade_name>
      </classification_info>
      <connectivity>
         <url line_type="IC_LINE">www.geldersglas.nl</url>
      </connectivity>
      <layout_info>
         <item_label_logo>TMN ICARD</item_label_logo>
         <yp_logo_id>5065697</yp_logo_id>
         <indicator>ICARD</indicator>
         <foreign_id>12237689</foreign_id>
      </layout_info>
      <extra_info>
         <text line_type="CC_LINE">HEEFT U GLASSCHADE ?</text>
         <text line_type="CC_LINE">BEL GRATIS 0800-022 11 33</text>
         <text line_type="CC_LINE">Welke glassoort u ook wenst ...,</text>
         <text line_type="CC_LINE">dezelfde dag geleverd en gemonteerd !</text>
         <text line_type="C_LINE"></text>
         <text line_type="CC_LINE">GELDERS GLAS :</text>
         <text line_type="CC_LINE">ACCENT OP SERVICE</text>
         <url line_type="IC_LINE">www.geldersglas.nl</url>
         <text line_type="C_LINE"></text>
         <text line_type="C_LINE">Bel gratis meldkamer</text>
      </extra_info>
      <sublistings>
         <sublisting line_type="T_LINE_BOLD">
            <area_code>0800</area_code>
            <phone_no>0221133</phone_no>
         </sublisting>
      </sublistings>
   </basiclisting>
</xmliresponse>
<xmliresponse>
   <tginlstatus>
      <action>pink</action>
      <internet>true</internet>
   </tginlstatus>
   <basiclisting line_type="T_LINE">
      <recordid>AHTSfCMWdu7UoZNcNUdZ</recordid>
      <area_code>0800</area_code>
      <phone_no>0221133</phone_no>
      <display_name>
         <print_name2>"0 800-022 11 33 Gelders Glas" </print_name2>
      </display_name>
      <classification_info>
         <trade_name key="SCH45">Schildersbedrijven</trade_name>
      </classification_info>
      <connectivity>
         <url line_type="IC_LINE">www.geldersglas.nl</url>
      </connectivity>
      <layout_info>
         <item_label_logo>TMN L8BRC3</item_label_logo>
         <yp_logo_id>5065697</yp_logo_id>
         <foreign_id>12237690</foreign_id>
      </layout_info>
      <extra_info>
         <text line_type="CC_LINE">HEEFT U GLASSCHADE ?</text>
         <text line_type="CC_LINE">...

Anonymous · 10 mei 2005 om 10:07

Ziet er interessant uit. Ik heb zelf ook wat zitten kijken en uitproberen (met PHP), maar ik kan met behulp van de zlib-library niet de gedecodeerde gegevens eruitkrijgen. Zou je daar wat meer over kunnen vertellen?

Ook vraag je op het eind de mogelijke corresponderende XML op uit een bestand genaamd ‘nawt.xml’. Hoe kom je aan de inhoud van dat bestand? Ik zie geen directe vertaalslag tussen de gedecomprimeerde DDB en het XML-bestand.

Wel goed om te zien dat er mensen zijn die toch weer altijd achter de gebruikte techniek kunnen komen :).

alkema_jm · 10 mei 2005 om 16:41

Hoi Weerman,

We nemen even aan dat de gegevens zowel gecomprimeerd als versleuteld op de CD staan.

Ik denk niet dat het versleuteld is, want:

Ik zie geen encryptie procedures in de bestanden. Zou er iets in zitten dan komt het m.i. veel terug.
Ze gaan prat op de snelste zoek engine te zijn, zelfs sneller dan internet. Snelheid en encryptie gaan m.i. niet samen.

Ik geloof dat een paar plaatsnamen in exe staan zag staan en ook een stuk wat leek op huisnummerbestand in een executable.

Ik denk dat ze alle attributen erg hebben genormaliseerd in ‘aparte’ bestanden, zoals een huisnummerbestand. Het grote bestand cdw.dbb is m.i. het koppelbestand met de verschillende attribuutbestanden.

De vriendelijke groet Jan Marco

Weerman · 10 mei 2005 om 19:00

‘Beginners-luck’ maar voortaan moet je nu wel u tegen me zeggen :o)

Met behulp van deze
http://www.vbaccelerator.com/home/VB/Code/Libraries/Compression/Compressing_and_Expanding_With_zLib/VB6_CompressZ-It_Code_zip_CompressZIt_cls.asp][u]code[/u
had ik rondom zlib wat in elkaar geflansd, eigenlijk gereduceerd tot alleen de functie ‘DecompressData’ om de zlib-uncompress-call te kunnen maken. Er staan bij mij op de PC een stuk of wat zlib’s verspreid over verschillende applicaties maar “whereis zlib.dll” komt met “windir\system32\zlib.dll” en dat is versie “1.1.4.0”.

Het werkte bij “cdp.ddb” alleen als ik om decompressie van 65508 of meer bytes vroeg en ik kreeg ook alleen maar die hoeveelheid terug, voor “cdw.ddb” was de grootte 65475. Proef herhaald met een commerciële compressie-component, zie ik dat effect weer dus daar is iets mee, misschien is deze taak eigenlijk weggelegd voor “TCustomZStream” in “dtgwin.exe”. Er staat me bij dat ik
http://forums.virtualconspiracy.com/foondump/viewtopic.php?p=775#775][u]destijds[/u
aparte “SchemaHandles” in de trant van 655369, 655378, enz. terugkreeg voor de verschillende databestanden dus misschien dat die er iets mee te maken hebben.

Ik was een beetje verbluft dat het zomaar werkte maar ook omdat wat erin zit op het eerste gezicht helemaal geen xml is, waar ze toch reclame voor gemaakt hadden:

We hebben natuurlijk niet het hele plaatje maar als je erover nadenkt kon het ook niet, die CD-zoek-engine wordt
http://forums.virtualconspiracy.com/foondump/viewtopic.php?p=775#775][u]zo te zien[/u
toch op dezelfde manier ingezet als op andere, oudere c-c-producten en daar was nooit sprake van xml.

Of ik zie het niet en gaat het hier om xml met tokens ipv tags zoals bijv. in een
Use Online Dating Websites And Applications][u]opzet[/u
als deze:

01 01 6A 00 C5 05 03 "Anonymous" 06 05 01 46 C1 C7 07 C2 01 01 C1 01 C7 07 C2 02 01 C1 01 C8 08 03 "Nice picture" 01 C3 .. .. 01 01
Maar anders is het wel een beetje potsierlijk, pas halverwege de zoekopdracht worden de resultaten alsnog van xml-tags voorzien: echte aardappelen gemaakt van puree.

Maar misschien zit het wel zo: ze kijken wel uit, dat beproefde spul zomaar weggooien, daar is jaren aan ontwikkeld. Voorlopig wordt - we raden maar - in overleg met de opdrachtgever het deel dat al klaar is geimproviseerd aan de oude cdserver geknoopt en pas als ze er helemaal klaar voor zijn volgt ook voor de cdroms een integrale aanpak met xml.

Op basis van - ik zit nog steeds te speculeren - het masterplan dus dat zij gepresenteerd hebben of gepresenteerd kregen toen C-Content door DTG voor de
http://www.telefoongids.nl/popup_colofon.html]techniek
achter “telefoongids.nl” gevraagd werd, die wel door-en-door xml zou hanteren? Zodat DTG uiteindelijk de output beter op de productie van EN de papieren gids, EN de cdroms EN de website kan afstemmen. Beter dan nu het geval is, denk nog es aan die [u]dubbele records[/u, onmisbaar voor de papieren gids maar ballast voor de electronische gidsen op cdrom en het net.

Nee? Dan zou die Snyder aan z’n secretaresse moeten vragen of zij het contract er nog eens bij wil pakken.

Een bestand als nawt.xml kan je zoals
http://forums.virtualconspiracy.com/foondump/viewtopic.php?p=823#823][u]beschreven[/u
zelf maken.

rgj · 10 mei 2005 om 19:26

Onder Unix, met zlib:

[code]#include <stdio.h>
#include “zlib.h”

int main (int argc, char **argv)
{
unsigned char buf[1024], uncomp[102400];
unsigned long comprLen, uncomprLen;
int err, i;
FILE *fp;

    fp = fopen (argv[1], "rb");
    fread (buf, 1024, 1, fp);
    comprLen = 1024;
    uncomprLen = 102400;
    err = uncompress(uncomp, &uncomprLen, buf, comprLen);
    fclose (fp);

    for (i=0; i<uncomprLen; i++) {
            printf ("%c", uncomp[i]);
    }

}[/code]

compile & link:

cc -O -c -o ddbfile.o ddbfile.c cc -O -o ddbfile ddbfile.o libz.a

Anonymous · 11 mei 2005 om 11:50

Vreemd. Bij cdp.ddb hoef ik maar 12158 bytes in de buffer te gooien en dan krijg ik er 65509 terug. Als ik meer bytes geef dan krijg ik niet meer terug, wanneer ik minder invoer dan blijft de uitvoerparameter op mijn opgegeven buffergrootte staan. De decompressiecode knalt er dan dus uit omdat de inputbuffer leeg is.

Zoeken op 78 DA in de gecomprimeerde stream levert (mogelijke) startmarkeringen op. Op offset 12158 staat er inderdaad netjes zo-een.

Nu nog uitvinden waar de tabel met startmarkeringen en bloklengtes staat. De ‘oude’ (2002) foon werkte overigens analoog.

Inderdaad lijkt de ddb file complete records te bevatten in een soort tagged formaat. Wanneer de hoogste bit 1 is (80-9f range tags) wordt verwezen naar een index, wanneer de hoogste bit 0 is (00-1f range) dan volgt een string.

000000 08 b4 10 b2 31 47 39 83 20 1f 20 41 6c 62 65 72 >....1G9. . Alber< <-- 1f = naam 000010 74 73 20 65 6e 20 43 6f 70 70 65 6e 73 00 90 34 >ts en Coppens..4< <-- 90=strnaam als ref 000020 66 00 92 46 00 15 31 30 31 31 4b 54 00 96 10 a3 >f..F..1011KT....< <-- 92=huisnr als ref 000030 10 09 b4 10 b2 72 33 a9 37 80 0c 54 65 74 73 6a >.....r3.7..Tetsj< <-- 0c=voornaam 000040 65 00 1f 53 74 72 69 6b 77 65 72 64 61 00 10 47 >e..Strikwerda..G< <-- 10 = strnaam als string 000050 65 65 72 74 20 4b 6e 6f 6c 77 65 67 00 92 49 00 >eert Knolweg..I.< 000060 15 38 35 30 31 4d 4b 00 96 33 50 a3 10 0b b4 10 >.8501MK..3P.....< 000070 b2 81 41 a7 74 50 1f 22 42 4d 22 20 41 64 6d 69 >..A.tP."BM" Admi< 000080 6e 69 73 74 72 61 74 69 65 6b 61 6e 74 6f 6f 72 >nistratiekantoor< 000090 20 00 90 22 aa 00 92 77 60 15 32 35 34 35 44 4b > .."...w`.2545DK< <-- 90 = straatnaam als ref 0000a0 00 96 30 2c 54 4d 4e 20 47 56 00 b0 25 49 91 47 >..0,TMN GV..%I.G< 0000b0 00 a3 20 a5 a0 0b b4 10 b2 47 64 46 99 10 1f 22 >.. ......GdF..."< 0000c0 43 61 72 65 20 26 20 44 65 73 69 67 6e 22 20 53 >Care & Design" S< 0000d0 74 75 64 69 6f 20 00 10 4d 61 72 67 61 20 4b 6c >tudio ..Marga Kl< 0000e0 6f 6d 70 65 68 6f 66 00 92 8a 00 15 31 33 31 34 >ompehof.....1314< 0000f0 57 52 00 96 24 00 2c 54 4d 4e 20 47 56 00 b0 25 >WR..$.,TMN GV..%< 000100 49 5a 17 00 a3 20 a5 23 00 0b b4 10 b2 81 46 15 >IZ... .#......F.<

Anonymous · 11 mei 2005 om 12:01

Nee, de wrapper code is ruk:

[code]lBufferSize = OrigSize + 1
ReDim bTempBuffer(0 To lBufferSize - 1) As Byte

'Decompress data
lResult = uncompress(bTempBuffer(0), lBufferSize, TheData(0),
UBound(TheData) + 1)[/code]

De decompressiebuffer wordt even groot gemaakt als de compressiebuffer+1 (sic!)
Bij minder dan 65508 bytes input data is je outputbuffer dus te klein. Verander de bovenste regel maar eens in lBufferSize = OrigSize * 100

Weerman · 11 mei 2005 om 15:57

Oeps, dat had ik beter meteen kunnen doen, namelijk even bij C-Content op de
http://www.c-content.nl/][u]website[/u
kijken:

[quote][…]

In 2003 De Telefoongids (DTG) in the Netherlands, former subsidiary of Dutch KPN Telecom, used C-CONTENT’s technology to launch an entirely new e-publishing platform based on XML. This system powers the popular, top 5 Internet website of DTG “www.detelefoongids.nl”.

Furthermore, a range of on-line applications on mobile devices (I-mode SMS, ect.) and off-line applications on CD-ROM are served by this XML communication layer. Large savings on applications development costs and a drastically reduced time to market of new applications are only two of the advatages of using C-CONTENT’s software. In the meantime all on-, off-line publications and mobile services of DTG run on C-CONTENT’s technology, using the above-mentioned XML e-publishing platform.

http://www.c-content.nl/casestudies_yellowpagescompanydirectoriesx.html?9][u]http://www.c-content.nl/casestudies_yellowpagescompanydirectoriesx.html?9[/u
[/quote]

Over de “consumers”- en “business”-CD-foons en XML:

[quote][…]

All the CD-ROM applications are based on Directory Access. Directory Access is a unique XML-based and powerful medium-independent e-publishing tool specifically developed by C-CONTENT for company directory and list-brokers. Positioned between the central database and end-user applications, it acts as an intelligent search-interface that enables the creation of application interfaces as well.

http://www.c-content.nl/news_latestnews_newdutchtelephonedirectorycdromproductlineonthemarketx.html?9][u]http://www.c-content.nl/news_latestnews_newdutchtelephonedirectorycdromproductlineonthemarketx.html?9[/u
[/quote]
.

Weerman · 11 mei 2005 om 16:50

[quote=“rgj.”]Verander de bovenste regel maar eens in lBufferSize = OrigSize * 100[/quote]100 is te gek, 4 of zo is genoeg, denk ik, maar het helpt niet. Je krijgt bijv. bij die “cdp.dbb” (CM) toch gewoon max. 65508 terug. Deed die Xceed-dll waar ik het daarna mee probeerde ook en die beheert z’n eigen buffers.

Maar maakt niet uit, ik heb het werkend. De clou is inderdaad dat je achter die die infobytes, 78 DA aanhobbelt en zo aan de porties komt die zlib wil hebben. Als je zlib niet vertelt hoe veel het na expansie wel zal worden dan krijg je dat genoemde effect. Weet jij hoe ze dat op de CD doen? Nu trim ik op meer dan 3 nullen in de outputbuffer.

alkema_jm · 11 mei 2005 om 18:27

Hoi Weerman, RGJ,

Als je naar cdt.ref kijkt begint deze met “77 3F” en dit getal komt “blokgewijs” weer terug. Is dit bestand niet opdezelfde manier gezipt als cdp.ddb alleen niet is de blokwaarde “77 3F”.

Even file pointer van “77 3F”:

0x0000:
0xA84d:
0xd5f4:
0x10000
.
.

Beetje vreemd dat blokwaarde na drie blokken op een mooi getal van 0x10000=65536 komt!

De vriendelijke groet Jan Marco

Anonymous · 11 mei 2005 om 18:32

Ik heb ook nog wat zitten puzzelen, en ben er ook achtergekomen dat de meeste records met 78 DA beginnen. Ik heb de eerste 30 matches op 78 DA gepakt en gedecomprimeerd en gekeken wat er uit is gekomen. De resultaten:

[quote]Filesize of record block 1 is 65509
Filesize of record block 2 is 65411
Filesize of record block 3 is 65534
Filesize of record block 4 is 65424
Filesize of record block 5 is 65439
Filesize of record block 6 is 0
Filesize of record block 7 is 0
Filesize of record block 8 is 0
Filesize of record block 9 is 65509
Filesize of record block 10 is 65485
Filesize of record block 11 is 65404
Filesize of record block 12 is 65525
Filesize of record block 13 is 65420
Filesize of record block 14 is 65518
Filesize of record block 15 is 65480
Filesize of record block 16 is 65515
Filesize of record block 17 is 65526
Filesize of record block 18 is 65100
Filesize of record block 19 is 0
Filesize of record block 20 is 0
Filesize of record block 21 is 65499
Filesize of record block 22 is 65454
Filesize of record block 23 is 0
Filesize of record block 24 is 0
Filesize of record block 25 is 65454
Filesize of record block 26 is 65477
Filesize of record block 27 is 65456
Filesize of record block 28 is 0
Filesize of record block 29 is 0
Filesize of record block 30 is 0
Filesize of record block 31 is 65450
Filesize of record block 32 is 65525
Filesize of record block 33 is 65395[/quote]

Zoals te zien is, pakt-ie er een aantal goed. Een aantal ook niet. Het ‘toevallige’ is ook dat zodra er eentje niet wordt gepakt, er meteen ook meerdere achter elkaar niet gepakt worden.

Ook is me opgevallen dat een enkel bestand meerdere (stuk of 20 à 30, lijkt het) records bevat. Het lijkt dat het om blokken records gaat met een max. grootte van 2^16 (65.536), die elk een aantal records bevat.

Het enige wat ik nog niet begrijp is waarom een aantal records niet ‘gepakt’ wordt.

rgj · 11 mei 2005 om 21:04

Het is niet zo dat de meeste records met 78 DA beginnen, zoals jij zegt. Alle records beginnen met 78 DA. Alleen kan 78 DA ook elders voorkomen.

Je komt dus ‘fake’ start markers tegen. Het kan namelijk zijn dat 78 DA ook gewoon toevallig in de gecomprimeerde stream voorkomt.

78 DA block uitgepakt offset lengte lengte 0 12158 65509 12158 22377 65411 34535 24924 65534 59459 16809 65424 76268 22660 65439 98928 22579 65509 100800 - 103518 - 121507 21456 65485

Je ziet dat 98928 + 22579 = 121507. Oftewel de 78 DA markers op
offsets 100800 en 103518 zitten gewoon in de byte stream van het block
wat op 98928 begint.

Anonymous · 11 mei 2005 om 23:08

Je hebt gelijk. Ik had het op die manier nog niet bekeken. Ik had gewoon een eenvoudig splitsroutine geschreven die naar alle 78 DA’s zoekt.

Maar dan blijf je wel met het probleem zitten hoe te bepalen of een 78 DA wel of geen echte recordstart is. Zoeken naar record blocks met een gecomprimeerde blocklengte tussen 10.000 en 25.000 (ruwweg)? Lijkt me geen goede manier.

Hoe bepaal je bijvoorbeeld dat de blocklengte op positie 98928 het aantal van 22579 tekens bevat (gecomprimeerd). Zoals ik er naar kijk lijkt het meer trial & error dan dat er een waterdichte logica achter zit, maar ik kan me uiteraard vergissen.

Maar in ieder geval bedankt voor de aanwijzingen. Ik ga verder zoeken, op zoeken naar het formaat van de bestanden icm met de andere bestanden (relaties e.d.).

alkema_jm · 12 mei 2005 om 01:53

Hoi Dezo,

Maar dan blijf je wel met het probleem zitten hoe te bepalen of een 78 DA wel of geen echte recordstart is.

Lijkt mij niet handig dat ze bijvoorbeeld cdw.ddb (170 Mb) vanaf begin gaan unzippen. Dat duurt namelijk erg lang.

Aannemelijker is dat er een “ind bestand” is met de pointers naar de unzipte blokken.

De vriendelijke groet Jan Marco

rgj · 12 mei 2005 om 06:30

Dezo: inderdaad was dit trial-and-error. Wat ik nu doe is steeds proberen of een blok met een lengte van 65536 bytes (aangenomen bovengrens) , beginnende op een marker, resultaat oplevert in uncompress().
Als dat zo is was het een goede marker en schrijf je het blok weg.
Dan probeer je de volgende, etc. etc.

Jan Marco

Ja. Enige kleine ieniemienie probleempje is dat ik me al 2 dagen scheel zoek naar dat bestand. Vermoedelijk zit e.e.a. in het *.doc bestand (daar wordt in gezocht vlak voordat het ddb bestand wordt geopend) maar ik kan het niet vinden. Tot die tijd doe ik het dus zoals boven beschreven.