Stare pliki INI

2010-06-24 15:47

Jest coś takiego jak aplikacje typu portable. Charakteryzują się tym, że nie wymagają instalacji i nie zostawiają żadnych “śladów” w systemie poza swoim własnym folderem. Takie programy są praktyczne, jeśli musimy korzystać z wielu różnych, nieswoich komputerów – wtedy można je przenieść na nośniku typu pendrive i uruchamiać bezpośrednio z niego.

Oczywiście nasze własne aplikacje nie muszą należeć do tej kategorii. Inaczej musielibyśmy na przykład zrezygnować z możliwości zapisywania ustawień programu w Rejestrze… Hmm, ale czy akurat tutaj jest czego żałować? :)
Ano niekoniecznie. Dawno, dawno temu popularnym sposobem przechowywania konfiguracji były pliki o rozszerzeniu .ini. Są to bardzo proste pliki tekstowe, zawierające pary klucz-wartość pogrupowane w sekcje. Składnia takiego pliku wygląda następująco:

  1. [Sekcja1]
  2. Klucz1=42
  3. Klucz2="wartość"
  4.  
  5. [Sekcja2]
  6. Klucz="Ala ma kota"

W Windows API wciąż istnieje interfejs pozwalający na odczytywanie i zapisywanie danych z takich plików, chociaż jest on trzymany podobno tylko dla kompatybilności. Obejmuje on funkcje specjalizujące się w obsłudze konkretnego pliku – mianowicie win.ini z głównego katalogu Windows – ale także dowolnego pliku .ini o podanej przez nas nazwie. Tymi bardziej elastycznymi funkcjami są:

  • do odczytywania wartości różnych typów: GetPrivateProfileInt, GetPrivateProfileString, GetPrivateProfileStruct
  • do zapisywania wartości: WritePrivateProfileString, WritePrivateProfileStruct
  • do pobierania listy sekcji w pliku .ini (GetPrivateProfileSectionNames) oraz listy kluczy w sekcji (GetPrivateProfileSection)

Ich użycie jest dość proste. Jeśli na przykład chcielibyśmy pobrać wartość liczbową z powyższego pliku, to wystarczy poniższe wywołanie, o ile jest on zapisany w bieżącym katalogu jako plik.ini:

  1. int value = GetPrivateProfileInt("Sekcja1", "Klucz1", 0, "plik.ini");

Dość podobnie wygląda korzystanie z pozostałych funkcji operujących na pojedynczych wartościach.

Dzisiaj pliki .ini są już trochę reliktem przeszłości, ale wydaje mi się, że do niektórych prostych zastosowań nadają się całkiem dobrze. A jeśli zdarzy się ten niefortunny przypadek, iż w którejś z przyszłych wersji Windows support dla nich zostanie porzucony, to cóż… składniowo są one na tyle proste, że ich parsowanie nie powinno być problemem ;-)

Tags: ,
Author: Xion, posted under Applications, Programming »


8 comments for post “Stare pliki INI”.
  1. vashpan:
    June 25th, 2010 o 15:14

    A tam przestarzale… Spelniaja swoja role, wiec czemu ich nie uzywac ? Do jakiejs prostej konfiguracji gdzie taki XML moze byc zbyt przerosniety i zaciemniajacy, czemu nie….

    Co do tego API obecnego w Windowsie, warto podkreslic ze kazda taka funkcja parsuje caly plik od nowa, co moze miec znaczenie gdy bedziemy odwolywac sie wiele razy do takiej zmiennej badz miec spory plik .ini ;)

  2. Sharp:
    June 25th, 2010 o 17:25

    Tak właściwie to zawsze się zastanawiałem w czym właściwie rejestr jest lepszy od plików ini… fakt, wygodnie się dzięki niemu grzebie w systemie, ale po niedługim czasie jest zaśmiecony kluczami utworzonymi przez oprogramowanie, w tym to które już zostało usunięte. Rozrasta się to i tylko spowalnia wszystko ;P

  3. jewsjews:
    June 25th, 2010 o 18:40

    po co bawić się w takie antyki skoro od dawna do c++ są dobre biblioteki do xmla (a w c# to już wogle jest poezja).

  4. TeMPOraL:
    June 25th, 2010 o 19:14

    Bo XML jest duży, brzydki i nieczytelny :).
    W przypadku prostych aplikacji XML to totalny overkill, a w przypadku ciut bardziej złożonych wolałbym już widzieć s-expressions (z grubsza to samo, tylko nie tak przeładowane tekstem). Może to kwestia osobistej preferencji, ale ja XMLa nigdy nie lubiłem :).

  5. Xion:
    June 25th, 2010 o 19:16

    @vashpan: W Delphi była (jest?) klasa TMemIniFile, która ładowała cały plik INI do pamięci i go tam buforowała, więc takiego problemu w niej nie było. Zapewne jednak nie korzystała ona z funkcji, które opisałem.

    @Sharp: Chyba największą wadą plików INI jest to, że sekcje nie mogą tworzyć hierarchii (czyli nie można ich zagnieżdżać). Kiedyś opracowałem nawet coś w rodzaju ulepszonego formatu INI (opartego trochę na DirectX-owych plikach X), który to ograniczenie usuwał, oczywiście za cenę trochę innej składni. Będę musiał wygrzebać kod parsera i może go zamieścić :)

    @jewjews: Popularność rozwiązań takich jak YAML czy JSON dowodzi, że rozwlekły XML nie wszędzie może/powinien być stosowany. A odrzucanie jakiegoś rozwiązania tylko dlatego, że jest stare, jest niespecjalnie logiczne.

  6. Liosan:
    June 26th, 2010 o 12:40

    iii tam, przesadzacie trochę z tą alergią na XMLa. Jak się dobrze zdefiniuje format, to wychodzi jakieś 5 znaków więcej na linijce niż .ini, a jednocześnie mamy całe dobrodziejstwo hierarchiczności.

    Z drugiej strony, kompletnie nie widzę sensu używania tej funkcji. Napisanie takiego parsera samemu to pół godziny roboty, nie mamy problemu z dodawanie nowych funkcjonalności (wczytywanie całego pliku, dodatkowe rodzaje danych), nie mamy problemu z wieloplatformowością (Linux albo Windows 12), no i (w moim przypadku) nie musimy wygrzebywać jakiegoś dziwnego API ;)

  7. vashpan:
    June 27th, 2010 o 12:08

    @Liosan, tylko po co mam definiowac jakis format XML jak potrzebna mi jest prosta konfiguracja, bez zadnej hierarchii czy innych pierdol ? Sporo softu uzywa nadal plikow .ini i .ini-podobnych i jakos nikt nie placze :) , nawet jezeli do innych celow uzywa sie XML. Zreszta porownywanie XML i starych pliczkow .ini nie ma wiekszego sensu bo w sumie maja nieco inne zastosowanie, mimo ze XML mozna uzyc do tego do czego najlepiej nadaje sie .ini…

    @Sharp Rejestr nie jest zly, jego idea byla dobra :) Zintegrowana konfiguracja zamiast gazyliona plikow .ini czy roznorakich pliczkow w gazylionie roznych formatow, jak w Uniksach… Problem w tym ze sie troche rozrosl, nie ma jakiegos zintegrowanego zarzadzania nim przez system i jego struktura nie jest zbyt “intuicyjna”

  8. dynax:
    June 27th, 2010 o 12:27

    Powinni zakazać używania tych okropnych, brzydkich i nieprzenośnych funkcji do plików .ini z WinAPI. W kilka sekund można przecież napisać własny parser korzystający na przykład z kliku klas z STL’a.

Comments are disabled.
 


© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with QuickLaTeX.com.