I'm having an issue where the API is translating the number 15 into the german literal string "fünfzehn" instead of leaving it as a number. It is only the number 15 and no other. It's formatted the same way as other numbers, nothing special about it.
We're sending html, so I had a look at the tags - not the issue either. We'd like to avoid wrapping numbers in a "notranslate" tag since it's only happening for 15.
Has anyone stumbled upon the same thing?
Related
I am using Mozilla's webRequest StreamFilter to read http requests
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/filterResponseData
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/StreamFilter/ondata
As long as the requests are not cached in the browser, the decoded text from the typed array is decoded correctly, but the problem arises when the data comes from cache. When that happens, this becomes the output for the same data that was being previously decoded with success:
����������20180901034956%������������������������������������������������ ����~�������v�a�r
That's only a small sample, the string is quite huge. I am using TextDecoder for this purpose with the UTF-8 encoding option set.
After some digging I discovered the cached data type array is filled with zeros, so when reading the unicode of that string it translates to the following, which I believe to be null in string:
\u0000\u0000\u0000\u0000\u0000\u0000\u000e\u0000\u0000\u000020180901034956%\u0000\u0000\u0000\u0005\u0000\u0000\u0000\u0001\u0000\u0000\u0000\u0014\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0002\u0000\u0000\u0000\u0001\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0002\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0005 \u0003\u0000\u0001\u0000~�\u0013\u0000\u0000\u0000\u0000\u0000v\u0000a\u0000r
A quick "solution" that was applied was to just remove the zeros from the typedarray or the nulls from the string, without any awareness of how it might affect the original data, resulting in the following:
�20180901034956%������� ��~��var
And the respective unicode version
\u000e20180901034956%\u0005\u0001\u0014\u0002\u0001\u0002\u0005 \u0003\u0001~�\u0013var
Searching some of those characters online showed that some of those are control characters and now I am stuck not knowing why this is happening at all - besides that this is cached data - and how to decoded it correctly.
I've tried reaching for Firefox's channels for some help, but it appears no one is answering after 3 straight days so I am posting this question here.
How can I decode the cache data the right way and also can anyone explain why it is showing like this? All the other data that is not cached is being decoded correctly.
EDIT: After more digging I confirmed the data is the one being read from the Firefox cached file. I was able to locate the right file and inside it contains the following information sample (this was opened in notepad):
20180901034956% ~ÿ v a r
The text following "v a r" follows the same format of each character followed by a "space", if that is even a space. So it is confirmed this is data being passed from the cached file, so how can I decode it correctly? I believe removing the spaces is not a proper solution seeing that it could also remove spaces that are part of the original data information.
EDIT2: The data is suppose to look like this:
var
Nothing behind that and no spaces in between each characters.
Looks like this is indeed a Firefox bug and the workaround I was already using is the only way to "fix" this by ourselves until Firefox decides to correct the problem itself.
Forgot to add the link to the bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1530408#c6
It looks like this bug will be fixed in Firefox 76.
What are accepted character sets in name fields in PassengerDetailsRQ?
I can't find relevant information about character sets in https://developer.sabre.com/docs/soap_apis/management/itinerary/Passenger_Details/resources/
For example, umlaut characters complicate the issue and leaves me wondering if I need to force only latin characters.
From my testing, "-", ".", numbers are not allowed. The request fails with ".FRMT.NOT ENT BGNG WITH" message.
I'm interested in the complete list of accepted character sets because I'm not sure what symbols can be entered in.
Using UTF-8 would be correct, as no hyphens, numbers, umlauts, accent marks, apostrophes, or special characters like ñ.
Since PassengerDetails works following the same mandates native Sabre does, it might be useful checking the native Sabre help site, called Format Finder. For this situation in particular, you may check here. (To login there, you can use the same credentials you use for creating sessions).
Let's say that, being abstract from any language, we have some ontology made of triples (e.g. subject (S) - predicate (P) - object (O))
Now if I want to, for some reason, annotate any of these triples (nodes), than I'd like to keep links to them that I can use in web documents.
Here are some conditions:
1) Such link must be in a form of one line of text
2) Such link should be easily parseable both by machine and person
3) Sections of such links should be delimited
4) Such link must be easy to grep, which IMO means they should be wrapped in some distinct letters or characters to make them easy to regex from any web or other document
5) Such link can be used in URL pathnames or query strings, thus has to comply with URL syntax
6) Characters used in such link must not be reserved for URL pathnames, query strings or hashes (e.g. not "/", ";" "?", "#")
My ideas so far were as follows:
a) Start and end such link with some distinct, constant set of letters, e.g. STK_....._OVRFLW
b) Separate sections with dashes "-", e.g. Subject-Predicate-Object
So it would look like:
STK_S1234-P123-O1234_OVRFLW
You have better ideas?
I'm with #msalvadores on this one - this seems to be a classic use of semantic web / linked data (albeit in a rather complex form), and your example seems to be more related to URI design rather than anthing else.
# is dealt with extensively in the semantic web lit, also there are javascript libraries for querying rdf through sparql - it just makes more sense to stick with the standard.
To link to a triple, the standard method is to use reification - essentially naming a triple (to keep with the triple model, it ends up creating 4 triples, but I would consider it the "correct" method in this situation). There is also the "named graph" method, which isn't a standard, but probably has more widespread adoption.
The link will be 1 line of text
It will be easily machine parsable, to make it human parsable, it might be necessary to give some thought to URI design.
Delimitation is once again on URI design
easy grepping - URI design
URL syntax - tick
no "/", ";" "?", "#" - I would try to incorporate it into a url instead of pushing it out
I would consider www.stackoverflow.com/statement/S1234_P123_O123, where S1234 etc. are unique labels (I don't necessarily agree with human readable uris, but I guess they'll have to stay until humans don't have to read uris). The beautiful thing is that it should dereference and give a nice human vs machine readable representation
I've created a couple views showing e.g. the latest news and events. However, when the username contains "special characters" (but still common in Finland), for example 'ä' or 'ö', the view shows the empty text instead of the real data.
For example my events view has two fields (node title and time of the event) and three filters (published = yes, node type = event and event time >= now). Nothing closely related filtering with the username added by myself.
Is there a workaround to get the view working?
Sounds like a problem with character encoding. I would recommend UTF8, works with almost every language.
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets
Whatever you do, make sure you use always the same encoding and use it everywhere.
I'm going to rely on the saying that no question is a dumb question, but I have a slightly dumb one to ask.
EDIT:
Seems that this question has been asked and answered a few times on here already, though using titles I didn't come across when searching for duplicates. Here are some related posts:
Double to string conversion without scientific notation
How to convert double to string without the power to 10 representation (E-05)
Place with an answer (Jon Skeet): http://www.yoda.arachsys.com/csharp/DoubleConverter.cs
Original Question:
I've got an app that sometimes stores some decently small numbers, such as 0.000023425. These numbers get loaded up in TextBox controls for users to edit. The following contrived example shows my issue:
Dim number As Double = 0.000023425
someTextBox.Text = number.ToString() ' Shows "2.3425E-05"
As mentioned, the text that shows is 2.3425E-05, which isn't exactly intuitive for the user to see, plus I have numbers even more precise (out to 19 decimal places). I would like the output to be fixed point. Of course I could easily and cleanly do:
number.ToString("F20") ' Shows "0.00002342500000000000"
But then there's an annoying number of zeros left over. So, to fix that, I could do:
number.ToString("#,##0.####################") ' Shows "0.000023425"
Which is what I want, but is there any better way to do it than to have that giant ugly format string there? So, ok, it's not that ugly, but surely there's a different way, right? My goal is to show the raw value being stored in the DB in a friendly way, and I would rather not have to force a format on the number at all.
Thanks!
UPDATE
Perhaps I said a bit too much in the post. After some experimentation, I found that changing the underlying datatype to Decimal solves the issue.
Dim number As Decimal = 0.000023425
someTextBox.Text = number.ToString() ' Shows "0.000023425" instead of "2.3425E-05"
So it sounds like Doubles aren't precise enough to be displayed normally?
EDIT
I found a post (albeit with no upvotes) that simply casts the the Double value as a Decimal before doing a .ToString() on it, which has the desired effect. Is there any reason why I wouldn't want to do that? Perhaps the cast to Decimal has the potential to end with a different value than the Double (even though it's a negligible amount), so perhaps the #,##0.#################... format string is safer.
Make your format string a constant (say in your resource file) and use it by name. You avoid seeing the ugly format and gain consistency from control to control in your format (i.e., if you change your mind, all controls will gain the new look).
As an alternative (or in conjunction), derive a custom control from the text box and have properties that invoke the different formatting strings you wish to use in an easier syntax.
Either way your goal should be not repeat yourself... by placing the configuration in one place you avoid mistyping it eventually and having to track down a strange formatting bug.
We do something similar by creating "percent" and "currency" text controls that encapsulate all the formatting and parsing requirements. They work just like text controls otherwise.