Return-Path: Delivered-To: apmail-hadoop-avro-dev-archive@minotaur.apache.org Received: (qmail 86226 invoked from network); 20 Jun 2009 01:36:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 20 Jun 2009 01:36:20 -0000 Received: (qmail 91384 invoked by uid 500); 20 Jun 2009 01:36:31 -0000 Delivered-To: apmail-hadoop-avro-dev-archive@hadoop.apache.org Received: (qmail 91356 invoked by uid 500); 20 Jun 2009 01:36:31 -0000 Mailing-List: contact avro-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: avro-dev@hadoop.apache.org Delivered-To: mailing list avro-dev@hadoop.apache.org Received: (qmail 91346 invoked by uid 99); 20 Jun 2009 01:36:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 20 Jun 2009 01:36:31 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 20 Jun 2009 01:36:28 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 96C7029A0020 for ; Fri, 19 Jun 2009 18:36:07 -0700 (PDT) Message-ID: <65597909.1245461767616.JavaMail.jira@brutus> Date: Fri, 19 Jun 2009 18:36:07 -0700 (PDT) From: "Scott Carey (JIRA)" To: avro-dev@hadoop.apache.org Subject: [jira] Commented: (AVRO-36) binary default values do not decode base64 In-Reply-To: <654448859.1243021245595.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/AVRO-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12722118#action_12722118 ] Scott Carey commented on AVRO-36: --------------------------------- {quote}URL encoding is more compact in some cases, but transforms many textual characters, like turning spaces to pluses.{quote} Only if it is required that the string be fully URL encoded. It merely needs to be able to be URL decoded properly. So spaces, slashes, dots, colons and other things illegal in an URL don't have to be url encoded -- its only the decoder that has to work, so I think only '%', '+', and anything that can't go inside a JSON string are illegal printable characters that have to be escaped. Therefore, [0,65,66, 20,67,255] could be valid as: "%00AB+C%FF" OR "%00AB C%FF" OR "%00AB%20%FF" And "This is a default !? /$#@()" would be valid as well in the URL encoding case Furthermore, this is not incompatible with the code point proposal. Unprintable bytes could be represented with code points or url encode escapes. Only "+" and "%" are required to be escaped. The built-in JSON string converter would parse out code points and other stuff ( does it turn \t into tab and \n into newline, etc?), and a url decode pass could convert the rest. I guess this really just complicates it, but it is an option. > binary default values do not decode base64 > ------------------------------------------ > > Key: AVRO-36 > URL: https://issues.apache.org/jira/browse/AVRO-36 > Project: Avro > Issue Type: Bug > Components: java > Reporter: Doug Cutting > Assignee: Doug Cutting > > The specification says that default values for binary data are base64 encoded text, but the Java implementation uses the raw bytes of the textual value, and does not perform base64 decoded as specified. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.