19 Replies Latest reply on Jun 30, 2011 5:56 PM by Antony

    XEP-147 (URI scheme) not working with 8 bit chars




      Thanks for making those changes for this.  We've tried this, but it seems it does not handle 8 bit characters properly


      We have a roster URI, which is 



      This represents the name "Ääkkönen Öky" and it is utf-8 encoded and then pct-encoded.  This follows step 2 of section 3.1 of RFC 3987, which states


      Step 2.  For each character in 'ucschar' or 'iprivate', apply steps

                  2.1 through 2.3 below.


             2.1.  Convert the character to a sequence of one or more octets

                   using UTF-8 [RFC3629].


             2.2.  Convert each octet to %HH, where HH is the hexadecimal

                   notation of the octet value.  Note that this is identical

                   to the percent-encoding mechanism in section 2.1 of
      .  To reduce variability, the hexadecimal notation

                   SHOULD use uppercase letters.


             2.3.  Replace the original character with the resulting character

                   sequence (i.e., a sequence of %HH triplets).


      If the data is sent with no utf-8 encoding, i.e. the 8 bit characters are sent as is, then the name will appear in the Nickname.


      The %20 is decoded to a space.  Looking at UriIManager, it does not do any decoding of the String apart from the call to replace for the %20 encoding. 


      I am not sure of the fix for this as I don't know how the command line parameters are handled, but from my reading of the RFC, all the URI mapping handlers should actually be treating the Java uriMapping String as a pct-encoded utf-8 byte stream, so they should be doing something like


      a) Decode pct-encoding to byte

      b) Create byte array from command line including decoded bytes

      c) Create java String from byte array with new String (byte[], Charset.forName("UTF-8"));


      Do you agree?


        • Re: XEP-147 (URI scheme) not working with 8 bit chars

          you should post a patch



          also it shouldnt work for the other commands, because they dont convert 8bit chars either

            • Re: XEP-147 (URI scheme) not working with 8 bit chars

              Set up Eclipse to checkout project from SVN, but it does not set up library build path in Eclipse project.  I can build with ant build.xml, but cannot debug as Eclipse complains about unresolved compilation problems.  I followed the doc here http://community.igniterealtime.org/docs/DOC-1040  but that still ends up with the same issue.  I'm using Helios with Subversive.


              I can add jars from build/lib I guess until the problems go away, but is there an update to that doc that deals with the Eclipse side a bit better?

              • Re: XEP-147 (URI scheme) not working with 8 bit chars

                Wolf_P. wrote:


                you should post a patch

                I've changed ChatManager and URIManager, attached here.  I couldn't test it properly because I can't get it built properly and make the exe, but at least I can partially debug it. Don't know how you do your testing and what test cases exist, but I tested it in the debugger and it seems to do the right thing, e.g. URI of




                will convert to äää@atacama/spark/?subscribe;name=Haha


                Just uses java.net.URI class.  Tested with JDK 1.6.  Not sure what the required JDK is for Spark, so don't know if URI class has changed in previous versions.



              • XEP-147 (URI scheme) not working with 8 bit chars

                ant -f sparksourcefolder/build/build.xml jar


                cp sparksourcefolder/target/build/lib/spark.jar yousparkinstallfolder/lib/spark.jar


                you dont need to build an exe, the spark.jar file is enough

                  • Re: XEP-147 (URI scheme) not working with 8 bit chars

                    Thanks, OK, all works now.

                    One comment about the subscribe implementation:  Currently it just sends the presence packet.  The XEP for subscribe says http://xmpp.org/extensions/xep-0147.html#actions-sub that


                    the invoked XMPP application SHOULD first send a roster add stanza as shown below (this is consistent with the recommendations in RFC 3921)


                    Also, it would be nice if Spark could control whether the 'Add contact' window was displayed when receiving these types of URL.  As it stands, you don't know if anything has happened because the user's not added to the roster in the client display and there's no indication the presence packet is sent.


                    I think the solution should be that the Add Contact window is shown by default, allowing nickname and group to be set before doing the protocal stuff.


                    Can you give me an idea where to look so I can try to achieve this?