I receive this error when adding a QBO Customer with a name that has greater/less than characters ('>', '<'). I've looked through the documentation and can't find a lit of unacceptable characters. How do I know what is and is not acceptable? I just need to know what to look for to sanitize our local data before uploading.
The API is XML-based, right? That means you need to either escape the characters into ">" and "<" respectively, probably with a standard library available in your environment; or filter the 5 characters listed here.
Related
Currently, I am using the below code to set parameters to retrieve data from PACS.
DcmDataset findParams = DcmDataset();
findParams.putAndInsertString(DCM_QueryRetrieveLevel, "SERIES");
findParams.putAndInsertString(DCM_SpecificCharacterSet, "ISO_IR 192");
However, just wanted to check can we provide support multiple characters set to import data at the same time, Code will look like something below, I am trying to check whether this is possible or not as I dont have the facility to verify the same.
findParams.putAndInsertString(DCM_SpecificCharacterSet, "ISO_IR 192" ,"ISO_IR 100");
I think that what you want to express is that "this Query SCU can accept responses in the following character sets". This is plainly not possible. See a discussion in the DICOM newsgroup for reference. It ends with a proposal to add character set negotiation to the association negotiation. But such a supplement has not been submitted yet, and I am not aware of anyone working on it currently.
The semantics of the attribute Specific Character Set (0008,0005) in the context of the Query Retrieve Service Class:
PS3.4, C.4.1.1.3.1 Request Identifier Structure
Conditionally, the Attribute Specific Character Set (0008,0005). This Attribute shall be included if expanded or replacement character sets may be used in any of the Attributes in the Request Identifier. It shall not be included otherwise
I.e. it describes nothing but the character encoding of your request dataset.
and
C.4.1.1.3.2 Response Identifier Structure
Conditionally, the Attribute Specific Character Set (0008,0005). This Attribute shall be included if expanded or replacement character sets may be used in any of the Attributes in the Response Identifier. It shall not be included otherwise. The C-FIND SCP is not required to return responses in the Specific Character Set requested by the SCU if that character set is not supported by the SCP. The SCP may return responses with a different Specific Character Set.
I.e. you cannot control the character set in which the SCP will send you the responses. Surprising but a matter of fact.
Sending multiple values for the attribute is possible but has different semantics. It means that the request contains characters from different character sets which are switched using Code Extension Techniques as defined in ISO 2022. An illustrative example how this would look like and what it would mean is found in PS3.5, H.3.2
What implementors usually do to avoid character set compatibility issues is configuring "the one and only" character set for a particular installation (=hospital) in a locale configuration that is configured upon system setup. It works pretty well, for e.g. an installation in Russia will very likely support Cyrillic (ISO_IR 144) or UNICODE (ISO_IR 192) or both. In case of "both", you can select the character set that you prefer for configuring your system.
I would like to determine the Thousand Separator used while running a VBA Code on a target machine without resolving to calling system built-in functions such as (Separator = Application.ThousandsSeparator).
I am using the following simple code using 'Format':
ThousandSeparator = Mid(Format(1000, "#,#"), 2, 1)
The above seems to work fine, and would like to confirm if this is a safe method of doing it without resorting to system calls.
I would expect the result to be a single char string in the form of , or . or ' or a Space as applicable to the locale on the machine.
Please note that I want to only use a language statement such as Format or similar (no sys calls). Also this relates to Thousands Separator not Decimal Separator. This article Using VBA to detect which decimal sign the computer is using does not help or answer my question. Thanks
Thanks in advance.
The strict answer to whether it is safe to use Format to get the thousands separator is No.
E.g. on Windows, it is possible to enter up to three characters into the Thousands Separator field in the regional settings in the control panel.
Suppose you enter asd and click OK.
If you now call Format(1000, "#,#") it will give you 1a000. That is only the first letter of your thousands separator. You have failed to retrieve it correctly.
Reading the registry:
? CreateObject("WScript.Shell").RegRead("HKCU\Control Panel\International\sThousand")
you get back asd in full.
To be fair, the Excel international properties do not seem to be of much help either. Application.International(xlThousandsSeparator) in this situation will return the separator originally defined in your computer's locale, not the value you've overridden it to.
Having that said, the practical answer is Yes, because it would appear (and if you happen to know for sure, please post an answer here) that there is no culture with multi-char thousand separator (even in China where scary things like 1億2345万6789 or 1億2345萬6789 exist, they happen to be represented with just one UTF-16 character), and you probably are happy to ignore the people who decided to play with their locale settings in that fashion.
I have strange in my view problem. I have UITextField which contains username. When it contains apostrophe (') the service cannot read username properly. I suppose it is connected with Unicode. I try to see what are the codes and I get:
L'TEST - contains code 8217
' - is 39
` - is 96
can anyone explains to me why this happens so I can fix this issue
L'TEST - contains code 8217
That would be L’TEST with U+2019 ‹’› \N{RIGHT SINGLE QUOTATION MARK}. If you look closely, in most fonts this character is displayed with a slight curl. It's not an apostrophe, but misused as one.
can anyone explains to me why this happens
Common causes:
"The Fool" Some mischievous input system silently substituted apostrophe for quotation mark. Word processors and mobile OS on-screen keyboards do that. It's well-meaning, but sometimes produces the wrong result.
"The Clueless" User is ignorant how to correctly type an apostrophe and picked the similar looking quotation mark.
"The Angry" Your UI text field (or something else in the chain originating from the user) forbids entry of apostrophes for some retarded reason. The user absolutely refuses to write something orthographically incorrect and manually substitutes apostrophe for quotation mark in order to work around the defect software.
so I can fix this issue
This is a social problem, not a software problem.
Since a SOAP service is based on XML and single quotes are a delineator in XML, you need to escape your single quotes by replacing "'" with "\'" in all text fields. It's a very common issue.
Basic question but couldn't find an answer to this.
There is fake API testing tool located here
https://jsonplaceholder.typicode.com/todos
When I add a query like this
https://jsonplaceholder.typicode.com/todos?userId=4
I get a response
When I change the query to this
https://jsonplaceholder.typicode.com/todos?userId<4
it returns null
How would I query in the url userId that is less than 4?
You need to encode the '<' sign as a special character with its hexadecimal code ('<' is 3c) so your query becomes:
https://jsonplaceholder.typicode.com/todos?userId%3c4
Any special character in a url can be coded as % followed by its two-digit hexadecimal code.
EDIT: After trying the URL with my change, I was able to get the '<' sign decoded as I mentioned above. However, it doesn't seem to provide the expected return (all user IDs less than 4). It returns more user IDs than this. Maybe need to check the API docs to make sure that 'userId<4' is a correct field definition.
I am working on a ASP.NET MVC app.
This app displays a detail information regarding a product.
The product name can have any special chars like single quote, the percentage symbol, the Registered symbol the one with a circle and 'R' inside, the Trademark symbol etc.
Currently all these are replaced with a '-'.
If the name is like this:
Super - Men's 100% Polyester Knit Shirts
It appears like this in the URL:
8080/super---men-s-100-polyester-knit-shirts/maverick
- men-s-100-polyester-knit-shirts
This is done in Js like so:
Name.replace(/([~!##$%^&*()_+=`{}\[\]\|\\:;'"<>,.\/? ])+/g, '-').replace(/^(-)+|(-)+$/g, '');
So the question is, should the name be displayed as-is in the URL?
If yes, some pointers please.
If no, please provide some valid reasons like standards as followed today that will help me put the point across the table.
Regards.
The short answer is not to fiddle with it. It's as good as it gets out of the box.
The Url can only contain a small number of alphanumeric letters. which basically means you can only have 0-9 a-z and - _ . ~.
All other characters need to be encoded. Now that you can have arabic url's too it has gotten a little more complicated.
But assuming your website is indo-european this is it. So you will never be able to have full product names in your url.
And renaming them as something more cool like replacing % with "percent" in the url can bring desaster upon your url's as in some cases the "fake" names may not end up unique and therefore end up with unreliable routing.
look at URI characters on wiki