Decode Protobuf Text - go

I have some Protobuf text that I'm receiving via an http response from a website. The text roughly looks like this:
1 {
2: some value
7: {
12: some value
}
8: some value
}
except the content is much larger. I don't want to paste the actual text for security purposes.
Anyways, how can I "decode" this so that I can see the schemas?

At the moment it is impossible to obtain a perfectly accurate schema from a protobuf message.
That being said, you can get semi-close. There are some tools like protobuf-inspector that can print out a bit more information about the structure of the message.
Some important caveats about this tool (and in general) as to why it's not possible to obtain the full schema, taken from the README of the tool:
[...] the field names are obviously lost, together with some high-level details such as:
whether a varint uses zig-zag encoding or not (will assume no zig-zag by default)
whether a 32-bit/64-bit value is an integer or float (both shown by default)
signedness (auto-detect by default)

Related

What is the point of google.protobuf.StringValue?

I've recently encountered all sorts of wrappers in Google's protobuf package. I'm struggling to imagine the use case. Can anyone shed the light: what problem were these intended to solve?
Here's one of the documentation links: https://developers.google.com/protocol-buffers/docs/reference/csharp/class/google/protobuf/well-known-types/string-value (it says nothing about what can this be used for).
One thing that will be different in behavior between this, and simple string type is that this field will be written less efficiently (a couple extra bytes, plus a redundant memory allocation). For other wrappers, the story is even worse, since the repeated variants of those fields will be written inefficiently (official Google's Protobuf serializer doesn't support packed encoding for non-numeric types).
Neither seems to be desirable. So, what's this all about?
There's a few reasons, mostly to do with where these are used - see struct.proto.
StringValue can be null, string often can't be in a language interfacing with protobufs. e.g. in Go strings are always set; the "zero value" for a string is "", the empty string, so it's impossible to distinguish between "this value is intentionally set to empty string" and "there was no value present". StringValue can be null and so solves this problem. It's especially important when they're used in a StructValue, which may represent arbitrary JSON: to do so it needs to distinguish between a JSON key which was set to empty string (StringValue with an empty string) or a JSON key which wasn't set at all (null StringValue).
Also if you look at struct.proto, you'll see that these aren't fully fledged message types in the proto - they're all generated from message Value, which has a oneof kind { number_value, string_value, bool_value... etc. By using a oneof struct.proto can represent a variety of different values in one field. Again this makes sense considering what struct.proto is designed to handle - arbitrary JSON - you don't know what type of value a given JSON key has ahead of time.
In addition to George's answer, you can't use a Protobuf primitive as the parameter or return value of a gRPC procedure.

Primitive type as data structure for API Blueprint

I want to use primitive type for describe data structure. Like so:
# Data Structures
## Video Delete (enum[number])
+ `0` - Successful deletion.
+ `1` - Error occured.
And the output is.
{
"enum": [
1,
0
],
"$schema": "http://json-schema.org/draft-04/schema#"
}
So description is missing. I've tried to put description in different places. I did a lot of things (do not wanna talk about them). Also I've tried to add info to enum values like so:
+ `0` (number) - Successful deletion.
I do not know whether this problem deals with MSON syntax or Aglio generator.
The syntax above is supported by MSON as far as I can tell. The problem is that Aglio doesn't do anything with the description, and when I went to look into adding it I realized that it isn't really supported in JSON Schema. There seem to be two methods people use to get around that fact:
Add the enumerated value descriptions to the main description, the Olio theme 1.6.2 has support for this but the C++ parser seems to still have some bugs around this feature:
## Video Delete (enum[number]) - 0 for success, 1 for error
Use a weird oneOf syntax where you create sets of single enums with a description. I don't recommend this.
Unfortunately the first option requires work on your part and can't easily be done in Aglio. Does anyone else have a better description and some samples of MSON input -> JSON Schema output?

Bestw.d format syntax in SAS

I am converting a character variable to a numeric variable. I am using a bestw.d format. I also tried just best. as the format in the input statement and this worked fine. I cant find any mention of just using best. instead of bestw. in SAS help, though I know from SAS help that the d can be omitted. I have been playing around with using just the best.and I am wondering if there is a default w assigned when just using best..
All formats have a default w. It is not generally good practice to use best. (or <format>.) in most cases, as you should know and plan for the specific width needed, but it always exists.
Also, informat and format have different defaults in many cases where there are identically named informat and format.
In the case of bestw., the default length is 12. See this documentation page for details.
I always find it's worth using a worked example, this shows the different outcomes when using lengths on the BEST. format:
data _NULL_;
a=1031564321300.302;
put '==================================';
put 'Different "BEST" formats';
put '==================================';
put 'BEST8. - ' a best8.;
put 'BEST12. - ' a best12.;
put 'BEST13. - ' a best13.;
put '==================================';
put 'BEST. - ' a best.;
put '==================================';
run;
You can run this in your environment and check the outcome. On my machine it looks like this:
==================================
Different "BEST" formats
==================================
BEST8. - 1.032E12
BEST12. - 1.0315643E12
BEST13. - 1031564321300
==================================
BEST. - 1.0315643E12
==================================
i.e. It looks like BEST12. is the matching format when no width is specified.

Convert to E164 only if possible?

Can I determine if the user entered a phone number that can be safely formatted into E164?
For Germany, this requires that the user started his entry with a local area code. For example, 123456 may be a subscriber number in his city, but it cannot be formatted into E164, because we don't know his local area code. Then I would like to keep the entry as it is. In contrast, the input 089123456 is independent of the area code and could be formatted into E164, because we know he's from Germany and we could convert this into +4989123456.
You can simply convert your number into E164 using libphonenumber
and after conversion checks if both the strings are same or not. If they're same means a number can not be formatted, otherwise the number you'll get from library will be formatted in E164.
Here's how you can convert
PhoneNumberUtil phoneUtil = PhoneNumberUtil.getInstance();
String formattedNumber = phoneUtil.format(inputNumber, PhoneNumberFormat.E164);
Finally compare formattedNumber with inputNumber
It looks as though you'll need to play with isValidNumber and isPossibleNumber for your case. format is certainly not guaranteed to give you something actually dialable, see the javadocs. This is suggested by the demo as well, where formatting is not displayed when isValidNumber is false.
I also am dealing with this FWIW. In the context of US numbers: The issue is I'd like to parse using isPossibleNumber in order to be as lenient as possible, and store the number in E164. However then we accept, e.g. +15551212. This string itself even passes isPossibleNumber despite clearly (I think) not being dialable anywhere.

Java applet - Real-time textfield input verification

I'm trying to develop an input real-time verification on a textfield in a Java applet.
The idea would be to have an input field that, if empty, once the user clicks in it it would show something like "0,00". Once the user starts to press the keys, only numbers should be accepted, and it would start to fill the text like this (imagine I input the numbers:
1,2,3,4,5,6):
"0,01" -> "0,12" -> "1,23" -> "12,34" -> "123,45" -> "1.234,56".
If the field is not empty the user can change the values but there will always be a "," dividing the decimal numbers.
I've been able to allow only numbers to be accepted but how can produce this kind of behavior? I know this may be a very specific question but any links or examples would be much appreciated. Thank you.
You will have to provide an input handler, that not only filters the input, but also calls a preset callback (made by you), that will update the required field in the way you want it to be updated.
You can use some functions, that can format numbers, given a specific format.
Basically, just keep a count on number of digits, already input, then parse it as a plain integer then multiply it by a power of 10, derived from the format, in your example would be something like 10 raised to the power of (numberOfInputDigits -2).

Resources