Pliki INI, rejestr lub pliki osobiste?

19

Chcę zapisać konfigurację mojego projektu, która obejmuje

  1. Rozmiar ekranu
  2. Pozycja ekranu
  3. Ścieżki folderów
  4. Ustawienia użytkowników i tak dalej.

Standardowe miejsca, w których można je zapisać, to wartości konfiguracji:

  1. Rejestr
  2. Pliki INI
  3. Pliki osobiste (jak * .cfg)

Jak wybierasz między tymi miejscami? Ponadto, czy są jakieś zalety i wady korzystania z któregokolwiek z nich?

Shirish11
źródło
2
Z jakich narzędzi korzystasz? Niektóre technologie są wyposażone w całkiem niezłe narzędzia do zarządzania konfiguracją.
@ Pierre303 obecnie używa VS 2008 dla VC ++
Shirish11
Czy użytkownicy będą musieli wprowadzić zmiany?
JeffO
1
Czy zastanawiałeś się nad YAML, dostajesz to, co najlepsze, ini i xml en.wikipedia.org/wiki/YAML
JF Dion

Odpowiedzi:

20

Czy są też plusy i minusy korzystania z któregokolwiek z nich?

Rejestr:

  • + Stosunkowo standardowy w środowisku Windows.
  • + Ogólnie dobre wsparcie ze strony instalatorów itp.
  • - API specyficzne dla platformy, jeśli kiedykolwiek chcesz przenieść swoją aplikację.
  • - Niezbyt czytelny dla człowieka.

Pliki INI:

  • + Prosty format.
  • + Przenośny.
  • + Czytelny dla człowieka.
  • - Przechowywanie bardziej złożonych informacji (np. Wszystkiego zagnieżdżonego na głębokości większej niż dwa poziomy) może być trudne.
  • ?Może trzeba napisać własny parser (choć nie jest to trudne) lub użyć zewnętrznej biblioteki, takiej jak SimpleIni (dzięki Jonathan Merlet za komentarz).

Pliki XML (domyślam się, że jest to opcja .cfg):

  • + Standardowy format.
  • + Przenośny.
  • + Obsługuje głęboko zagnieżdżone struktury.
  • - Niezbyt czytelny dla człowieka.

Osobiście dla aplikacji Windows zwykle używam C # i idę z osobistym plikiem dla użytkownika, przechowywanym jako XML. Robię to zwykle, ponieważ czytelność dla ludzi nie jest zwykle priorytetem w rodzajach aplikacji, które piszę (a aplikacja powinna mieć edytor konfiguracji, w każdym przypadku), a w środowisku .NET bardzo łatwo jest pracować z XML. Bardzo często kończę na obiekcie UserConfiguration, który jest po prostu serializowany do i z pliku konfiguracyjnego - prawie nie wymaga programowania (parsowanie, rzutowanie), a twoja konfiguracja jest gotowa do użycia w środowisku o silnym typie.

Daniel B.
źródło
Użyłem SimpleIni do parsowania plików INI jakiś czas temu i działało to ładnie.
Jonathan Merlet
@JonathanMerlet dzięki, dodałem SimpleIni do postu.
Daniel B
15

Wybrałbym pliki INI, są one bardziej przyjazne dla człowieka:

[window]
width       = 600
height      = 350
position.x  = 400
position.y  = 200

[paths]
path1       = "/some/random/path/"
path2       = "/some/other/random/path/"

[user]
name        = "Yannis"
preference  = "INI"

XML może być dobrą opcją, ale nie może pobić prostoty i elegancji INI:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <window>
        <width>600</width>
        <height>350</height>
        <position>
            <x>400</x>
            <y>200</y>
        </position>
    </window>
    <paths>
        <path1>/some/random/path/</path1>
        <path2>/some/other/random/path/</path1>
    </paths>
    <user>
        <name>Robert</name>
        <preference>XML</preference>
    </user>
</configuration>

INI są również bardzo dobrze rozumiane i niezależne od platformy. Prawdopodobnie nie ma dla nich tylu narzędzi, co w przypadku plików XML, bo cóż, kto potrzebuje specjalistycznego narzędzia do odczytu i edycji pliku INI?

Yannis
źródło
2
Zabawne, ale uważam, że XML jest ładniejszy i łatwiejszy do odczytania. Dla tych, którzy nie lubią gadatliwości, JSON jest odpowiednią alternatywą.
Robert Harvey
3
@RobertHarvey JSON Lubię (i użyłbym, gdybym potrzebował głębszego zagnieżdżenia), ale XML tak naprawdę nie jest moją filiżanką herbaty ...
yannis
2
XML można ulepszyć, łącząc wartości w atrybuty. Na przykład<window width="600" height="350" />
Robert Harvey,
Jestem właściwie zaskoczony, że nikt jeszcze nie wspomniał o YAML. Uważam, że jest to dotyk bardziej przyjazny dla człowieka niż JSON, ale dość podobny pod względem możliwości i składni. Witryna yaml.org prawdopodobnie odstrasza każdego, kto jeszcze jej nie zna.
Daniel B
@DanielB Ktoś wspomniał o YAML ;)
yannis 16.04. O
6

Preferuję pliki XML. Są hierarchiczne, możesz je naginać według własnej woli w prawie każdy możliwy do wyobrażenia sposób, są one dobrze zrozumiałe, niezależne od platformy, a także dostępny jest szeroki wachlarz oprogramowania do ich odczytu i zapisu.

Robert Harvey
źródło
6
Ale okropnie gadatliwy i zazwyczaj nie jest czytelny dla ludzi (nie myśl, że nie jest wcięty lub nadęty z deklaracjami przestrzeni nazw i innymi bs).
Manjabes,
1
@Manjabes: cechy, które prawdopodobnie nie będą znaczące dla plików konfiguracyjnych.
Robert Harvey
@robert harvey: bardzo ważne, gdzie mieszkam. Do podstawowego wtrącania się w ustawienia używasz GUI, dla ustawień zaawansowanych edytujesz INI.
Pieter B
6

Aby rozwinąć sugestię JAMA D Jeffa D. , oto krótkie wprowadzenie.

YAML jest podobny do JSON (w rzeczywistości JSON jest podzbiorem YAML od wersji 1.2 standardu YAML, a zatem może być przetwarzany prawidłowy JSON przez parsery YAML). Na pierwszy rzut oka główna różnica polega na tym, że YAML (domyślnie) używa wcięć zamiast nawiasów kwadratowych do wyświetlenia hierarchii. Zauważalny jest również brak cudzysłowów dla ciągów. Szybki przykład z góry:

configuration:
  window: 
    width:       600
    height:      350
    position:
      x:         400
      y:         200
  paths:
    path1:       some/random/path
    path2:       some/other/random/path
  user:
    name:        Joe Soap
    preference:  YAML

Lepsze przykłady można znaleźć na stronie YAML Wikipedii . Obsługa YAML istnieje dla większości głównych języków (szczegóły na stronie yaml.org ).

Daniel B.
źródło
3

Zapomniałeś opcji: Baza danych. Jest to najczęściej używane w scenariuszach, w których użytkownicy logują się do aplikacji, gdy aplikacja nie może polegać na zalogowanym użytkowniku systemu Windows. Dzieje się tak na przykład, gdy aplikacja działa w systemie Windows w trybie kiosku.

Pieter B.
źródło
Może być potrzebny plik INI lub klucz rejestru do przechowywania szczegółów połączenia / ciągu z bazą danych
Class Skeleton
@CamelCase Inifile lub klucz rejestru został już wspomniany w pytaniu, ale nie baza danych. Nie chciałem powiedzieć, że nie możesz używać wielu metod jednocześnie.
Pieter B
1

Moje osobiste preferencje to pliki XML:

W większości przypadków nie oczekuję, że użytkownik będzie musiał edytować ustawienia konfiguracji, więc problem czytelności nie jest w tym przypadku argumentem.

Jeśli będą musieli je edytować, możesz udostępnić narzędzie do edycji - dzięki temu użytkownik nie zrobi nic dziwnego z danymi. Jeśli chcą przywrócić ustawienia domyślne, możesz po prostu powiedzieć im, aby usunęli plik x, co zrobi większość użytkowników.

Pamiętaj, że nadal musisz uważać, aby mieć uprawnienia do przechowywania pliku, ponieważ niektóre lokalizacje domyślnie nie mają dostępu do zapisu w systemie Windows 7 itp.


Pliki INI są dobrym standardowym sposobem przechowywania konfiguracji i są wypróbowane i przetestowane, ale wydają mi się trochę „Windows 3.1”!

Prawdopodobnie najlepsza opcja, jeśli chcesz, aby użytkownik majstrował przy swoich danych


Osobiście oderwałbym się od rejestru. Po pierwsze, nie możesz zagwarantować, że użytkownik ma niezbędne uprawnienia do odczytu / zapisu w dowolnym miejscu, w którym chcesz przechowywać swoje dane.

W nowszych systemach operacyjnych, w których występuje wirtualizacja rejestru, może to powodować poważne zamieszanie, ponieważ nie można „zobaczyć” zwirtualizowanych ustawień - to nas ugryzło niejednokrotnie, gdy spędziliśmy godziny próbując dowiedzieć się, dlaczego coś nie działa.

Matt Wilko
źródło
3
Jeśli martwisz się o uprawnienia do lokalizacji rejestru, prawdopodobnie próbujesz przechowywać je w niewłaściwym miejscu. Użytkownik powinien mieć uprawnienia do gałęzi HKey_Current_User i tam powinny znajdować się ustawienia poszczególnych użytkowników!
Neil White
@NeilWhite - zgodził się, że powinni mieć uprawnienia, ale nadgorliwy administrator IT może to zmienić (lub udzielić uprawnień do odczytu / zapisu, ale nie tworzyć uprawnień). Również OP nie wspomniał, że te ustawienia były koniecznie dla użytkownika , mogą być dla jednego komputera.
Matt Wilko,
Rejestr może mieć również limit rozmiaru. Pliki nie.
linquize 16.04.13