In our application we have implemented that all dates and values should be presented using the browsers locale.
However when selecting Danish as the locale/language in any web browser the date formatting is wrong.
We see no errors for English, Swedish, Norwegian formatting, only for Danish.
The dates are formatted as "20/08/15" but should be "20-08-2015"
The server is a Domino 9.0.1 version using Server Locale and when testing the locale output I see that it is serving "da". When changing to Browser Locale on server the setting do not change the date formatting.
This issue has been reported on our servers in different countries.
I have tried to locate an explanation and/or answer to our problem but failed.
The application has no locale specific formatting on any fields, view columns… and we'd like to keep it that way. Our application is run in different countries so not controlling the locale formatting is our preferred way. However we'd like to present the dates and numbers in the language specific correct way.
We do not explicitly use any Dojo components, only plain date fields and view columns in a view panel. We do not have any International Options set.
I have tried to set the locale as #Sven Hasselbach answer in another question but failed. Haven't tried his Xsnippet…
an example of header:
GET /demo/tradesec.nsf HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, sdch
Accept-Language: da,sv;q=0.8,no;q=0.6,en-US;q=0.4,en;q=0.2,nl;q=0.2
DNT: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/45.0.2454.37 Safari/537.36
X-Chrome-UMA-Enabled: 1
X-Client-Data: CJe2yQEIo7bJAQicksoBCOeUygEI/ZXKAQi8mMoB
HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Length: 8956
Content-Type: text/html;charset=UTF-8
Date: Mon, 17 Aug 2015 07:59:43 GMT
Expires: -1
Keep-Alive: timeout=10, max=100
Tradechannel: Work_and_fun_professionally_done
X-Pad: avoid browser bug
Please advice, thanks!
/M
XPages is using the ICU4J library for date formatting. That library is using '/' as the separator for the Danish short date format.
So code like this:
com.ibm.icu.text.DateFormat.getDateInstance(
com.ibm.icu.text.DateFormat.SHORT,
new java.util.Locale("da")).toPattern()
gives date patterns like:
en: M/d/yy
da: dd/MM/yy
sv: yyyy-MM-dd
nb: dd.MM.yy
You might try using the long date format instead:
da (long): d. MMM yyyy
output: 17. aug 2015
da (medium): dd/MM/yyyy
output: 17/08/2015
by setting dateStyle="long" on the converter.
Or if you do need to override the language-specific pattern for Danish then the code would be like:
<xp:viewColumn columnName="_MainTopicsDate" id="viewColumn3">
<xp:viewColumnHeader value="Date" id="viewColumnHeader3"></xp:viewColumnHeader>
<xp:this.converter>
<xp:convertDateTime dateStyle="short"
pattern="${javascript: ('da' == context.getLocale().getLanguage())?
'd-MM-yyyy': null}">
</xp:convertDateTime>
</xp:this.converter>
</xp:viewColumn>
Just a quick thing to check - are there any settings in the browser that you are using that could make any trouble here? Can you confirm that it works correctly using a non-XPages webpage with the correct locale?
I know I have had issues with browsers trying to be "clever" in other situations - so I think it would be a good idea to try and establish if the browser or the XPage is the culprit ;-)
/John
Related
This question already has an answer here:
WinHttpRequest gzip response parsing
(1 answer)
Closed 1 year ago.
I am using Excel 2007 (12.0.4518.1014)
I have been using the WinHttpRequest Object to perform API GET Requests on a web service that hosts data for me.
Everything else works properly and it grabs the JSON formatted data from the web service and puts it into a string with the .ResponseText property.
The issue I am having is that inside that string, all of the Unicode characters are turned into gibberish like â?? instead of ✓ (U+2713). Which means that when I do MyRange.Value = .ResponseText the cell value becomes â??.
If I set the GET request to ask for Xml format, I get �?? instead of ✓
I have confirmed by repeating the GET request in Chrome, the web service is outputting the correct Unicode symbol, and Chrome was able to show me ✓. So this is an issue with VBA or WinHttp.
Excel by itself is able to generate Unicode symbols and VBA is able to do it as well ChrW(10003).
How can I preserve Unicode symbols during a GET request? Is it possible with WinHttp or do I need to change methods?
Edit:
Here are the headers during a standard response:
{
"access-control-allow-headers": "Content-Type",
"access-control-allow-methods": "GET, POST, PUT, DELETE, OPTIONS",
"access-control-allow-origin": "*",
"cache-control": "private",
"content-encoding": "gzip",
"content-security-policy": "frame-ancestors 'self', default-src * 'unsafe-inline' 'unsafe-eval' data: blob:;",
"content-type": "application/json",
"date": "Wed, 23 Jun 2021 18:08:53 GMT",
"expect-ct": "max-age=0;",
"referrer-policy": "strict-origin-when-cross-origin",
"strict-transport-security": "max-age=31536000; includeSubDomains; preload",
"vary": "Accept-Encoding",
"x-content-type-options": "nosniff",
"x-frame-options": "SAMEORIGIN",
"x-stackifyid": "V2|80002f92-0000-3100-b63f-84710c7967bb|C61313|CD10436"
}
Update: RESOLVED!
I have solved my problem with advice from #GSerg and wonderful insight from #JoelCoeHoorn. I will write how it was solved here since my question was closed.
WinHTTPRequest was swapped out for an XMLHTTP Object. This Object can be used in VBA with similar commands to WinHTTPRequest, as shown in the link about halfway down the page. But the XMLHTTP object was able to return Unicode characters with no issues.
To use it in VBA, you can create it with the line:
Dim http As Object
Set http = CreateObject("Microsoft.XMLHTTP")
And then you're ready to go with .open and .setRequestHeader and .Send similar to the WinHttpRequest object.
I know of five ways this can happen relative to an HTTP transaction:
The response has a header that includes what specific encoding is used. If the chosen encoding doesn't have the ability to display all the character points used in the text, this is what you get.
This is also what you get if text of the response is set directly and not mapped to the encoding specified in the header, so the encoding says the text should be different than what it is.
For historical reasons, there are some encodings that are system dependent, where the upper region of the encoding depends on the locally installed language packs/settings. So you can see this effect if the header chooses a system-specific encoding and the text is set on a system where this upper region is interpreted differently than the client, even though both ends used the same encoding.
The fourth way this can happen is with UTF-8 when a byte order mark is used incorrectly, ignored, or interpreted as text.
Finally, (and this is the most likely of these options to fit your situation) this can happen when an encoding is used in one place that is not supported in the other. VBA pre-dates the widespread adoption of unicode, and does not have good unicode support. Especially older versions of VBA, like you might encounter in, say, the long unsupported Excel 2007.
These problems all tend to manifest only for unicode characters and leave simple latin characters alone, because many encodings all handle the simple latin characters in the exact same way.
I am trying to use Microsoft Translator API to translate text from Polish to any other language. In Polish, there are a couple of special characters like "ą", "ś", "ż" etc. When I send the HTTP request with no special characters:
POST /translate?api-version=3.0&from=pl&to=en HTTP/1.1
Ocp-Apim-Subscription-Key: ********
Ocp-Apim-Subscription-Region: ******
Content-Length: 21
Host: api.cognitive.microsofttranslator.com
Connection: close
User-Agent: Apache-HttpClient/4.5.10 (Java/15.0.2)
Accept-Encoding: gzip, deflate
[{"Text": "Gramatyka"}]
I receive a correct translation:
[{"translations":[{"text":"grammar","to":"en"}]}]
However, it is likely that a Polish word or sentence contains special characters:
POST /translate?api-version=3.0&from=pl&to=en HTTP/1.1
Ocp-Apim-Subscription-Key: ********
Ocp-Apim-Subscription-Region: ********
Content-Length: 21
Host: api.cognitive.microsofttranslator.com
Connection: close
User-Agent: Apache-HttpClient/4.5.10 (Java/15.0.2)
Accept-Encoding: gzip, deflate
[{"Text": "Roślina"}]
This request results in error code 400000:
{"error":{"code":400000,"message":"One of the request inputs is not valid."}}
If I change the special characters to standard ones (like change "ś" into "s"), the API does not give a proper translation. For example:
[{"Text": "Roslina"}]
results in:
[{"translations":[{"text":"Roslina","to":"en"}]}]
Whereas "roślina" should translate to "plant".
This problem applies to other languages too. For example German:
[{"Text": "Wörterbuch"}]
results in an 400000 error as well.
Has anyone found a solution to this?
Did you try checking the language detect score, to just understand if it is taking it as Polish. Can you try without "From" attribute. Make sure you put all headers.
curl -X POST "https://api.cognitive.microsofttranslator.com/translate?api-version=3.0&to=zh-Hans" -H "Ocp-Apim-Subscription-Key: " -H "Content-Type: application/json; charset=UTF-8" -d "[{'Text':'Hello, what is your name?'}]"
Given a typical webserver log file that contains a mixture of absolute URLs, relative URLs, human requests and bots (some sample lines):
112.77.167.177 - - [01/Apr/2016:22:40:09 +1100] "GET /bad-credit-loans/abc/ HTTP/1.1" 200 7532 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"
189.181.124.177 - - [31/Mar/2016:23:10:47 +1100] "GET /build/assets/css/styles-1a879e1b.css HTTP/1.1" 200 31654 "https://www.abc.com.au/customer-reviews/" "Mozilla/5.0 (iPhone; CPU iPhone OS 9_2_1 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Version/9.0 Mobile/13D15 Safari/601.1"
110.76.15.146 - - [01/Apr/2016:00:25:09 +1100] "GET http://www.abc.com.au/car-loans/low-doc-car-loans/ HTTP/1.1" 301 528 "-" "Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)"
I'm looking to list all the URI's requested with status code (200, 302 etc.) and total count of requests i.e.
http://www.abc.com.au 301 3,900
/bad-credit-loans/abc/ 200 123
/bad-credit-loans/abc/ 302 7
Were it not for the presence of the varying IP addresses, timestamps, referring URLs, and user agents, I would be able to combine uniq and sort in the standard fashion. Or if I knew all the URLs in advance, I could simply loop over each URL-status code combo with grep in its simplest form.
How do we disregard the varying items (user agents, timestamps etc.) and extract just the URLs and their frequency of status code?
You should just recognize taht the interesting parts are always on constant filed positions (with respect to space separated fields).
URL is at position 7 and status code is at position 9.
The rest is trivial. You may e.g. use:
awk '{sum[$7 " " $9]++;tot++;} END { for (i in sum) { printf "%s %d\n", i, sum[i];} printf "TOTAL %d\n", tot;}' LOGFILES
And then sort using sort the result if you need the outpout sorted.
I export a csv in Scala/Spray and it works nice on my Windows machine but fails on Linux machine.
The response from both OS are identical:
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:X-Requested-With, Cache-Control, Pragma, Origin, Authorization, Content-Type, Auth-Token
Access-Control-Allow-Methods:GET, POST, DELETE, OPTIONS, PUT
Access-Control-Allow-Origin:*
Access-Control-Expose-Headers:Auth-Token
Content-Disposition:attachment; filename=Enter report title.csv
Content-Length:229
Content-Type:text/csv; charset=ISO-8859-1
Date:Fri, 07 Feb 2014 22:17:40 GMT
Server:spray-can/1.2.0
I am wondering why the OS can make a difference?
When exporting from linux after jar is deployed, diacritics are replaced with strange chars.
For instance this Café macchiato
is fine when exporting from Windows but it appears like Café macchiato
when exporting from Linux.
To help Excel recognize character encoding you can add a BOM to the beginning of the file. For example:
def prepareBomOutputStream(outputFile: String) = {
val os = new FileOutputStream(outputFile)
os.write(239)
os.write(187)
os.write(191)
os
}
You can also check if in both cases you get exact same encoding and not a subset of the encoding. For instance on Windows you might get ISO-8859-15 instead. You can most likely set encoding explicitly in your CSV export code/library. To check encoding on Linux you can use:
$ file -ib /tmp/test.csv
text/plain; charset=utf-8
or even something like hexdump.
Please never ever use Excel for text-oriented files. It screws up stuff. Use an editor like vim or Notepad++ where you can inspect the bytes and actually see whether your stuff is correct or not.
I've a small java web app in which I send messages on a service bus queue when a user click on a button. I want to display the messages on my jsp page. But when I make the call
resultQM = service.receiveQueueMessage(queueName, opts);
I get the following exception. Thanks in advance for your help.
java.lang.IllegalArgumentException: org.codehaus.jackson.map.JsonMappingException: Can not construct instance of java.util.Date from String value 'Sun, 03 Jun 2012 13:54:40 GMT': not a valid representation (error: Can not parse date "Sun, 03 Jun 2012 13:54:40 GMT": not compatible with any of standard forms ("yyyy-MM-dd'T'HH:mm:ss.SSSZ", "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", "EEE, dd MMM yyyy HH:mm:ss zzz", "yyyy-MM-dd"))
at [Source: [B#8719e; line: 1, column: 70] (through reference chain: com.microsoft.windowsazure.services.serviceBus.implementation.BrokerProperties["LockedUntilUtc"])
com.microsoft.windowsazure.services.serviceBus.implementation.BrokerPropertiesMapper.fromString(BrokerPropertiesMapper.java:41)
com.microsoft.windowsazure.services.serviceBus.implementation.ServiceBusRestProxy.receiveMessage(ServiceBusRestProxy.java:187)
com.microsoft.windowsazure.services.serviceBus.implementation.ServiceBusRestProxy.receiveQueueMessage(ServiceBusRestProxy.java:151)
com.microsoft.windowsazure.services.serviceBus.implementation.ServiceBusExceptionProcessor.receiveQueueMessage(ServiceBusExceptionProcessor.java:108)
messaging.QueueListener.getMessage(QueueListener.java:22)
org.apache.jsp.index_jsp._jspService(index_jsp.java:116)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
I think the exception is clear enough? There is a message that holds a string containing a date, and the library can't parse the string to a valid date.
"Sun, 03 Jun 2012 13:54:40 GMT": not compatible with any of standard forms ("yyyy-MM-dd'T'HH:mm:ss.SSSZ", "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", "EEE, dd MMM yyyy HH:mm:ss zzz", "yyyy-MM-dd")
I suggest you to check if your local machine's clock is correct. Also try to create a SimpleDateFormat, as described on Jersey + Jackson deserialization failure with date object (a similar exception).
Set the default system locale to US before calling receiveQueueMessage:
Locale.setDefault(Locale.US);
Cause:
The Windows Azure SDK for Java uses Jackson, which uses the default system locale when creating SimpleDateFormat objects for parsing dates. Windows Azure Service Bus returns dates formatted to string using RFC-1123 and ENGLISH locale. RFC-1123 date format contains day of the week and the parser fails when your default locale is not ENGLISH and has different day of week names.
Source: Alexander Racheev's answer in the MSDN Forum.
In the latest version of Windows Azure SDK for Java, Version 0.4.2. This should have been fixed, let us know if anyone can still repro this.