Są różni, jak inni już odpowiedzieli.
static void Main(string[] args)
{
string s1 = null;
string s2 = string.Empty;
string s3 = "";
Console.WriteLine(s1 == s2);
Console.WriteLine(s1 == s3);
Console.WriteLine(s2 == s3);
}
results:
false - since null is different from string.empty
false - since null is different from ""
true - since "" is same as string.empty
Problem z zarządzaniem ciągami pustymi w porównaniu z ciągami zerowymi staje się problemem, gdy trzeba zachować go w płaskim pliku lub przesłać go za pomocą komunikacji, więc uważam, że może być przydatne dla innych, którzy odwiedzają tę stronę, aby dać dobre rozwiązanie ten konkretny problem.
W celu zapisania łańcuchów do pliku lub komunikacji:
prawdopodobnie będziesz chciał przekonwertować łańcuch na bajty.
dobrą praktyką, którą polecam, jest dodanie 2 segmentów bajtów nagłówka do przekonwertowanego ciągu.
segment 1 - metainformacja, która jest przechowywana w 1 bajcie i opisuje długość następnego segmentu.
segment 2 - zawiera długość zapisywanego ciągu.
przykład:
string "abcd" - dla uproszczenia przekonwertuję go za pomocą kodera ASCII i otrzymam {65,66,67,68}.
Oblicz segment 2 da 4 - więc 4 bajty to długość przekonwertowanego ciągu.
obliczyć segment 1 daje 1 - ponieważ tylko 1 bajt został użyty do przechowywania informacji o długości przekonwertowanej informacji ciągu (czyli 4, tj. gdyby było to 260, dostałbym 2)
Nowy pasek bajtów będzie miał teraz wartość {1,4,65,66,67,68}, który można zapisać do pliku.
Zaletą w odniesieniu do tematu jest to, że gdybym miał pusty ciąg do zapisania, otrzymałbym z konwersji pustą tablicę bajtów o długości 0 i po obliczeniu segmentów otrzymam {1,0}, które może być zapisane, a później załadowane i zinterpretowane z powrotem w pusty łańcuch. Z drugiej strony, gdybym miał wartość null w swoim ciągu, miałbym tylko {0} jako moją tablicę bajtów do zapisania, a po załadowaniu można zinterpretować z powrotem do null.
Istnieje więcej korzyści, takich jak wiedza o rozmiarze do załadowania lub zgromadzenia, jeśli zerwasz wiele ciągów.
Wracając do tematu - to… cóż, w pewnym sensie zanieczyści stos, ponieważ te same opisane zasady są używane przez każdy system do rozróżniania wartości null od pustych .. więc tak, string.Empty zajmuje więcej pamięci niż null, chociaż nie zrobiłbym tego nazwij to zanieczyszczeniem ... to tylko 1 bajt więcej.