QR code with URL, does it *REALLY* need the http://? - mobile-website

It seems like most (if not all) QR readers on my iPhone handle URLs without the http:// just fine but I was wondering if that is universal? Android? BlackBerry? Is there an RFC somewhere that I should be reading
I'm building a QR management/url shortener system and was wondering if it was absolutely necessary. If not, I can drop 7 characters from my QR's URLs and make them the lowest level of complexity (16 characters or less). Which, from everything I've read, is a Good Thing™.


I haven't found any absolute documentation that says it must have it. But... After testing a number of QR reader apps, it's clear that many of them will 'guess' at a url if there is no http:// in it. But many do not and display it as just a string. Since it's a URL, it really does need it. And if any apps won't read it, then I have to bow to them and add it for all of them.


Hey Dan I am the dev of Barcode Scanner and just saw your question. I have a few more tidbits of info which may help.
There is no real 'standard' for this; I suppose the HTTP specification is the closest thing and technically it does say you need "http://". This wiki has everything we think we know about standards and de facto standards in this area.
I can tell you that QR codes have special modes to encode digits only, and alphanumeric-only text. The alpha mode includes only capital letters, but does include key punctuation like colon and slash. So, HTTP://EXAMPLE.ORG/BAR ought to be encodable in QR codes in fewer bytes than http://example.org/bar.
URLs themselves are case-sensitive however. It's not necessarily OK to uppercase a URL. But the server application may be case-insensitive. If you control the endpoints and know you can use all uppercase, this is a way to perhaps squeeze into version 1.
Finally I'll say that version 1 QR codes are a little weird since they have no alignment pattern. Without a fourth point to find, it can't (well, the dumb-but-effective process employed by Barcode Scanner and by extension a lot of scanners) account for perspective distortion. It happens to work with only small tilt. But version 2 actually has a small advantage for decodability with that alignment pattern.


QR readers usually identify as a URL any text that conform to ANY of this conditions:
Text starts with http:// (or HTTP://)
Text starts with www.
Text starts with MEBKM: (NTT DoCoMo format for web bookmark)
You should be fine without http if your url starts with www. but it's not your case.
As Sean points out, you should use all-caps urls instead.
You can fit up to 24 alphanumeric characters in a Version 1 level L QR, wich is just enought for a url shortener.
Example:
HTTP://1QR.ES/AAAAAAAAAA


Fun fact: Samsung Galaxy phones (e.g. S8 and S9) will open a QR code with a URL that has "HTTP" or "HTTPS" (in uppercase) in their text editor. Create the same URL with lowercase "http" or "https" and the same URL and it will open in a browser as expected.

Related

Adding &js_fast_load=0&css_fast_load=0&strip=0 to URL triggers mojibake

I have a Liferay 6.2 page that shows fine.
For debug purposes, I added &js_fast_load=0&css_fast_load=0&strip=0 o the URL (production server that I can not modify).
Problem: By doing so, the page's encoding gets mixed up (mojibake)
What could be triggering the problem, and how to solve it?

I don't know what is the root cause of the problem.
But as it is for debug (these URL parameters are only used for debugging), an easy way to "solve" it is to manually switch the page encoding to UTF-8.
Any better solution is very welcome!

You mention in your own answer that switching to UTF-8 fixes the issue. I'd add to it that this issue points to a general problem with encoding on some level. I always recommend to always strictly and everywhere standardize on the same encoding: From Database/Filesystem/appserver to the HTTP/HTML layer. Mixing up encoding is a recipe for disaster, mainly because it will only be detected in edge cases unless you happen to work in non-latin character sets routinely.
My favorite way to test with non-latin character sets that make sense to you when you only speak languages that use latin alphabet is to utilize http://fliptitle.com to generate test data. If that goes through, odds are that all of your configuration is correct.

iOS URL Scheme Length

Is there a limitation on the length of a URL Scheme for an iOS App?
We have a number of apps and want to prefix them with the name of our 14 character company name to prevent ambiguity. I don't see any mention of a limitation in the documentation and I can enter an arbitrarily long string in Xcode.
I know that the shorter schemes are preferred but is there a limit on the length of the scheme?

I'm pretty sure that its the same as the normal URL scheme.
This question goes over a similar topic, you might find more information in here.

Is it possible to customize Recaptcha image language?

Is it possible to customize Recaptcha to display text in English only words?
As recently, I found that text could be displayed in other language like Hebrew.
Here is example:
To be honest it is not possible to type such words for ordinary users having keyboard with Roman alphabet and not many know that image can be redrawn.

AFAIK, via the API you may only customize the interface, not the images.
reCAPTCHA uses scans from the real books, so sometimes, even in latin books there are some non latin characters too.
But there should be no problem here. reCAPTCHA displays always two words: one unknown even for the reCAPTCHA (probably the Hebrew in this case), and the other one, which is really checked.
So the user may misspell the Hebrew, but it's OK when he types the other one (latin) word as expected.
(Only guesses, but I think that's how this thing works).

Have you looked at: http://code.google.com/apis/recaptcha/docs/customization.html#i18n?
That's the API. It talks about setting the translation, but I've never used it, so I'm not 100% sure whether it can do what you want.
Due to where Recaptcha gets its captcha string from (text scanned from books), it could very well be limited to languages that use the Latin alphabet.
I bet that Reviled is the challenge word (the one scanned from the book) and the other is the test word (the one it uses to verify whether or not the person who typed the challenge word is actually typing something legitimate or not).

How to put the Amazon Kindle Web Browser into Article Mode

How do you put the Amazon Kindle web browser into Article Mode via HTML or Javascript?
Editor's note: Some pages are not automatically detected as "articles" by the Kindle 3 browser, and give an error message when trying to go into Article mode. What does the Article mode use to determine what portion of the page to display?

Is this related at all to Readability?
http://lifehacker.com/5163401/readability-bookmarklet-quick+formats-pages-for-smoother-text
Actual JavaScript code for Readability, which is heuristic based:
// Study all the paragraphs and find the chunk that has the most <p>'s and keep it:
This also appears to be related to Safari 5's Reader mode. Here is what is required for Safari Reader:
This definitely needs more investigating, but so far, these appear to be the most important factors for Safari’s Reader functionality to kick in:
Use the right markup, i.e. make sure the most important content is wrapped inside a container element. Whether you use <article>, <div> or even <span> doesn’t seem to matter — as long as it’s not <p>.
The content needs to be long enough. Use enough words, use enough paragraphs, use enough punctuation. Every paragraph should have at least 100 characters.
Reader doesn’t work for local documents.

http://www.wired.com/gadgetlab/2010/09/simple-tip-turns-kindle-into-ultimate-news-reader/ - The "f" key feature outlined above or some other feature? Not quite sure what article mode means.

It means that the browser will try to identify if the page you are looking at has a main body of text (is an article), parse it out and then display only that text without clutter and for easy scrolling.
I don't think you can force it via the web page's code

As far as I know, once the website has loaded (and if you are on an specific topic) you can turn on the "Article Mode" from the menu.
I've seen similar JS tools for Chrome too, so I assume it's part of webkit.

How to enable iOS 5 Safari Reader on my website?

How does the Reader function of Mobile Safari in iOS 5 work? How do I enable it on my site. How do I tell it what content on my page is an article to trigger this function?

A lot of the answers posted here contain false information. Here are some corrections/clarifications:
The <article> element works fine as a wrapper; Safari Reader recognizes it. My site is an example. It doesn’t matter which wrapper element you choose, as long as there is one, other than <body> or <p>. You can use <article>, <div>, <section>; or elements that are semantically incorrect for this purpose, like <nav>, <aside>, <footer>, <header>; or even inline elements like <span> (!).
No headings are required for Reader to work. Here’s an example of a document without any <h*> elements on which Reader works fine: http://mathiasbynens.be/demo/safari-reader-test-3
I posted some more details regarding my findings here: http://mathiasbynens.be/notes/safari-reader

I've tested 100 or so variations of this on my iPhone in order to figure out what triggers this elusive Reader state. My conclusions are as follows:
Here is what I found had an impact:
Having around 200 or more words (or 1000 characters including whitespace) in the article you want to trigger the "Reader" seems necessary
The reader was NEVER triggered when I had less than 170 words; although it was sometimes triggered when I had 180 or 190 words.
Text inside certain elements such as <ol> or <ul> (that are not typically used to contain a story) will not count towards the 200 words (they will however be displayed in the reader if the reader is triggered for other reasons)
Wrapping the 200 words in a block element such as a <div> or <article> seems necessary (that said, I'd be surprised if there were any websites where that was not already the case)
For full disclosure, here is what I found did NOT have an impact:
Whether using a header or not
Whether wrapping the text in a <p> or letting it flow freely
Punctuations (ie removing all periods, commas, etc, did not have an impact)

It seems the algorithm it is based on is looking for p-Tags and it counts delimiters like "." in the innerText. The section (div) with the most points gets the focus.
see:
http://lab.arc90.com/experiments/readability/
Seems to be the base for the Reader-mode, at least Safari attributes it in the Acknowledgements, see:
file:///C:/Program%20Files/Safari/Safari.resources/Help/Acknowledgments.html
Arc90 ( Readability )
Copyright © Arc90 Inc.
Readability is licensed under the Apache License, Version 2.0.

This question (How to disable Safari Reader in a web page) has more details. Copied here:
I'm curious to know more about what triggers the Reader option in Safari and what does not. I wouldn't plan to implement anything that would disable it, but curious as a technical exercise.
Here is what I've learned so far with some basic playing around:
You need at least one H tag
It does not go by character count alone but by the number of P tags and length
Probably looks for sentence breaks '.' and other criteria
Safari will provide the 'Reader' if, with a H tag, and the following:
1 P tag, 2417 chars
4 P tags, 1527 chars
5 P tags, 1150 chars
6 P tags, 862 chars
If you subtract 1 character from any of the above, the 'Reader' option is not available.
I should note that the character count of the H tag plays a part but sadly did not realize this when I determined the results above. Assume 20+ characters for H tag and fixed throughout the results above.
Some other interesting things:
Setting for P tags removes them from the count
Setting display to none, and then showing them 230ms later with Javascript avoided the Reader option too
I'd be interested if anyone can determine this in full.

Both Firefox and Chrome have the similar plugin named iReader. Here is its project with source code.
http://code.google.com/p/ireader-extension/
Read the code to get more.

I was struggling with this. I finally took out the <ul> markings in my story, and viola! it started working.
I didn't put any wrapper around the body, but may have done it by accident.

HTML5 article tag doesn't trigger it on my tests. It also doesn't seem to work on offline content (i.e. pages saved on your local machine).
What does seem to trigger it is a div block with a lot of p's with a lot of text.

The p tag theory sounds good. I think it also detects other elements as well. One of our pages with 6 paragraphs didn't trigger the Reader, but one with 4 paragraphs and an img tag did.
It's also smart enough to detect multi-page articles. Try it out on a multi-page article on nytimes.com or nymag.com. Would be interested to know how it detects that as well.

Surprising though it may be, it indeed does not pay any attention to the HTML5 article tag, particularly disappointing given that Safari 5 has complete support for article, section, nav, etc in CSS--they can be styled just like a div now, and behave the same as any block level element.
I had specifically set up a site with an article tag and several inner section tags, in prep for semantic HTML5 labeling for exactly such a purpose, so I was really hoping that Safari 5 would use that for Reader. No such luck--probably should file a bug on this, as it would make a great deal of sense. It in fact completely ignores most of the h2 level subheads on the page, each marked as a section, only displaying the single div that adheres to the criteria mentioned previously.
Ironically, the old version of the same site, which has neither article, section, nor separating div tags, recognizes the whole body for display in Reader.

See Article Publishing Guidelines.
Here are APIs about how to read and parse: Readability Developer APIs. There's already a project you can refer: ruby-readability.
A brief history:
The Safari Reader feature since Apple's Safari 5 browser embeded a codebase named Readability, and Readability started off as a simple, Javascript-based reading tool that turned any web page into a customizable reading view. It was released by Arc90 (as an Arc90 Lab experiment), a New York City-based design and technology shop, back in early 2009. It's also embeded in Amazon Kindle and popular iPad applications like Flipboard and Reeder.

I am working on algorithms for cleaning web-sites from information "waste" similar to Safari Reader feature. It's not so good as readability but has some cool stuff.
You can learn more at smartbrowser.codeplex.com project page.