Se pare, care este problema?
Excel înțelege formatul DBF, ar trebui, în orice caz. Pe de altă parte, DBF este formatul ArcView nativ, acesta conține atributele pentru file shapefile. Creați-vă un fișier în Excel și transferați-l în ArcView. Cu toate acestea, pe această "cale" masa de gropi și șanțuri, da, astfel încât chiar și utilizatorii cu experiență uneori poticni. De ce trece prin asta și ce să facă? Creați un tabel, de exemplu, cu numărul de puncte, nume, coordonate.
Da, Excel este capabil să scrie date direct la DBF, dar. încărcarea mesei în ArcView, veți găsi imediat în ea:
1. Semnele cifrelor "după virgulă" sunt pierdute;
2. Tipurile de date din coloane sunt confuze;
3. Codificarea literelor rusești este distorsionată etc.
După ce ai condus un pic, vei înțelege că nu e vina lui ArcView, și anume Axel. De ce se întâmplă acest lucru și cum? Primele două probleme se datorează faptului că Excel este un procesor simplu de tabel, nu un sistem de baze de date, deci nu știe cum să aibă grijă de tipurile de date. Și DBF nu este un tabel simplu, este un fișier de bază de date și are o structură strictă - este fixat în antetul DBF. Pentru bazele de date din MS Office, Access este proiectat și scrie corect DBF, acceptă aproape ca format nativ, funcționează cu DBF "mai corect". Problemele 1 și 2 sunt practic absente acolo. Dar multe, cu toate acestea, calcule dragoste în stil tabular, liber! Piesa din Excel este necesară! Cum să o călcați în picioare?
Tipuri de date
Să analizăm mai întâi tipurile de date. Excel definește tipurile de date pentru fiecare coloană de pe liniile de sus, deci atunci când faci masa, procedează astfel:
- Linia superioară, sub rubricile coloanelor, după cum se arată în prima figură. Mai bine dacă numele sunt fără spații, latine și nu mai mult de 10 caractere sunt cerințele formularului DBF.
- Verificați dacă datele dvs. sunt scrise corect, mai ales în liniile de top. În cazul în care numerele sunt separator zecimal greșit sau litera „O“ în loc de la zero, Excel va anunța textul lor, și o coloană în DBF va primi un tip de text, cu toate consecințele sale.
- În cazul în care liniile de top în unele coloane, nu există date sau acestea nu sunt orientative ale coloanei (de exemplu, textul de coloană și liniile de sus au ajuns, din păcate, unele numere), apoi trageți a doua linie special pentru eșantioane de valori: secol, astfel spokon înșelat DBF experimentat -schiki. Această linie este apoi ușor de eliminat din DBF, bine, deja în ArcView.
Pagini de cod
Cu toate acestea, măsurile de mai sus vor contribui la limitarea doar a tipurilor de date. Întrebarea cu litere rusești este mai vicleană. Ei "zboară", deoarece Excel scrie cu încăpățânare DBF într-o veche codificare Dos (este, de asemenea, numită ASCII, probabil ați auzit). El pare să creadă că formatul DBF este foarte vechi, pură Dosovsky patrimoniu. ArcView este implicit la vindovsovskim format DBF, și a citit-o ca și cum ar fi fost într-un Windows de codificare (este, de asemenea, numit ANSI). Deci, există aceste două programe, cum ar fi doi tauri, înclinându-și frunțile :)
Să încercăm să ne dăm seama ce este trucul. Secretul se află în antetul lui DBF. În el, timp de un secol, există un loc în care este stocată referința la pagina de cod. ArcView "știe" despre acest lucru și dacă fișierul DBF este "corect", adică codificarea este indicată corect, atunci ArcView o va înțelege și o va citi în mod corespunzător. Dezvoltatorii Microsoft au uitat complet despre acest lucru, iar în Excel aceste detalii suplimentare de cod nu sunt incluse. Mai mult decât atât, acesta curăță curând instrucțiunile pentru pagina de cod, de îndată ce ajunge la ea.
Modul de rezolvare a problemelor unui fișier Excel cu tipuri de date și codificări printr-o conexiune SQL este descris aici.
Cum sunt lucrurile în ArcMap? Și exact la fel. Tabelele DBF nu sunt citite fără efort și toate recomandările de mai sus sunt relevante. În mod similar, corecția paginii de cod produce un efect magic în mod obișnuit: