DecodeProto

Operacja wyodrębnia pola z serializowanego protokołu buforującego wiadomość do tensorów.

Uwaga: ten interfejs API został zaprojektowany z myślą o ortogonalności, a nie o przyjazności dla człowieka. Można go używać do ręcznego analizowania wejściowych protosów, ale jest on przeznaczony do użycia w wygenerowanym kodzie.

Operacja `decode_proto` wyodrębnia pola z serializowanego protokołu buforującego wiadomość do tensorów. Pola w `nazwa_pola` są dekodowane i konwertowane na odpowiednie `typy_wyjściowe`, jeśli to możliwe.

Aby zapewnić kontekst nazw pól, należy podać nazwę „typ_wiadomości”. Rzeczywisty deskryptor komunikatu można sprawdzić w puli połączonych deskryptorów lub w nazwie pliku dostarczonej przez osobę wywołującą przy użyciu atrybutu `źródło_deskryptu`.

Każdy tensor wyjściowy jest tensorem gęstym. Oznacza to, że jest dopełniony tak, aby pomieścić największą liczbę powtarzających się elementów widzianych w minipartii wejściowej. (Kształt jest również dopełniany o jeden, aby zapobiec wymiarom zerowym). Rzeczywistą liczbę powtórzeń dla każdego przykładu w minipartii można znaleźć w wynikach `sizes`. W wielu przypadkach wynik `decode_proto` jest natychmiast wprowadzany do tf.squeeze, jeśli brakujące wartości nie stanowią problemu. Używając tf.squeeze, zawsze jawnie podawaj wymiar ściśnięcia, aby uniknąć niespodzianek.

W większości przypadków mapowanie między typami pól Proto i typami TensorFlow jest proste. Istnieje jednak kilka szczególnych przypadków:

- Pole proto zawierające podkomunikat lub grupę można przekonwertować jedynie na `DT_STRING` (serializowany podkomunikat). Ma to na celu zmniejszenie złożoności interfejsu API. Wynikowy ciąg znaków może zostać użyty jako dane wejściowe innej instancji operacji decode_proto.

- TensorFlow nie obsługuje liczb całkowitych bez znaku. Operacje reprezentują typy uint64 jako `DT_INT64` z tym samym wzorcem bitowym z uzupełnieniem do dwóch (w oczywisty sposób). Wartości int32 bez znaku można dokładnie przedstawić, określając typ `DT_INT64` lub używając uzupełnienia dwójkowego, jeśli wywołujący określi `DT_INT32` w atrybucie `output_types`.

- Pola `mapy` nie są bezpośrednio dekodowane. Traktowane są jako pola „powtarzane” odpowiedniego typu wpisu. Protokompilator definiuje typy wpisów dla każdego pola mapy. Nazwa typu to nazwa pola przekonwertowana na „CamelCase” z dołączonym „Entry”. Komunikat tf.train.Features.FeatureEntry jest przykładem jednego z tych ukrytych typów „Entry”.

- Pola `enum` należy czytać jako int32.

Obsługiwane są zarówno serializacje binarne, jak i tekstowe, które można wybrać za pomocą atrybutu „format”.

Atrybut `descriptor_source` wybiera źródło deskryptorów protokołu, z których należy korzystać podczas wyszukiwania `message_type`. To może być:

- Pusty ciąg znaków lub „local://”, w którym to przypadku tworzone są deskryptory protokołu dla definicji proto C++ (nie Pythona) połączonych z plikiem binarnym.

- Plik, w którym to przypadku tworzone są deskryptory protokołu z pliku, który powinien zawierać `FileDescriptorSet` serializowany jako ciąg znaków. UWAGA: Możesz zbudować plik `źródło_deskryptu`, używając opcji `--descriptor_set_out` i `--include_imports` do kompilatora protokołu `protoc`.

- A „bajty:// ", w którym tworzone są deskryptory protokołów z ` `, który powinien być `FileDescriptorSet` serializowanym jako ciąg znaków.