Re: [VCARDDAV] Questions about text handling in vCard 4.0 (rev 11)

[Daisuke Miyakawa <[e-mail]>]

Please let me add two actual cases we can refer and I'd like to know your
opinion about

1) Java
http://java.sun.com/javase/technologies/core/basic/intl/faq.jsp

s1=hello there
s2=\u3053\u3093\u306b\u3061\u306f

<http://java.sun.com/javase/technologies/core/basic/intl/faq.jsp>
Java has been aware of Unicode and allows both format, though they don't use
UTF-8 but UTF-16.
I usually don't see \u format since it is not readable, but I sometimes see
it in comments, which are appropriately handled by javadoc and emitted as
human-readable html.

2) ICU4C

I'm not familiar with ICU library at a whole, but I have experience looking
at its collator config.
For example, icu4c/data/coll/ja.txt says...

ja{
    Version{"2.0.41.26"}
    collations{
        standard{
            Sequence{
                " [strength 3 ] [hiraganaQ on ]"
                "&ヽ=ゝ"
...

 "<條<梛<梃<檮<梹<桴<梵<梠<梺<椏<梍<桾<椁<棊<椈<棘<椢<椦<棡<椌<棍<棔<棧<棕<椶<椒<椄<棗<棣<椥<棹<棠<棯<椨"
...
                "&←=￩"
                "&↑=￪"
                "&→=￫"
                "&↓=￬"
                "&│=￨"
                "&■=￭"
                "&○=￮"
                "&、=､"
                "&。=｡"
                "&「=｢"
                "&」=｣"
                "&ん<'\u0020'<'!'<'\"'<'#'<'
...


In zh.txt, I can see '\uE84D'.

Even ICU4C, a reliable library for Unicode developed by Unicode authority,
is allowing this kind of format (though it uses \u or \U, not \x), so I
think it is worth considering vCard's supporting this kind of format.

Thanks,

2010年7月6日23:54 Daisuke Miyakawa <[e-mail]>:

>
>
> 2010/7/6 Simon Perreault <[e-mail]>
>
> On 2010-07-06 10:25, Daisuke Miyakawa wrote:
>> > One proposal I can do is that composer side are allowed (but not
>> > recommended) to use the format only when they cannot emit the word (like
>> > when users want to edit foreign friends name without an appropriate IME)
>> > but know codepoint for that characters.
>> > Receiver side MUST be able to decode \xNNNN to appropriate Unicode form.
>> > This is a kind of dirty compromise but there's no technical difficulty
>> > nor theoretically insufficiency. I suppose I can implement
>> > sender/receiver easily.
>>
>> I think you are confusing encoding with how a particular implementation
>> renders the text.
>
>
>
>> It is perfectly fine for an implementation to render text as \xNNNN when
>> e.g. a font is unavailable.
>>
>> It is also perfectly fine for an implementation to take \xNNNN as input.
>>
>> But what goes on the wire is pure UTF-8. How it gets rendered or how it
>> is input by a user is completely irrelevant for the vCard data format.
>
>
> Well, I think we should also take care of actual use cases vCard is treated
> by users, not only from the view of purity of UTF-8. I know \xNNNN makes the
> text dirtier.
>
> This is my understanding: If we have contact application with 100%
> capability, we don't need to take care of \xNNNN topic at all. But my
> (short) experience tells me that, really often, I had to look at bare data
> with emacs, vi, or notepad.
> At that stage, adding \xNNNNNNNN is really practically useful fallback for
> reading/editing the data.
>
> Feel free to correct me. I know my saying is really biased toward "how it
> can be implemented and be used",
> not "how it should be written as a specification".
>
> Thanks!
>
>
>
>>  Simon
>> --
>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
>> STUN/TURN server        --> http://numb.viagenie.ca
>> vCard 4.0               --> http://www.vcarddav.org
>>
>
>
>
> --
> Daisuke Miyakawa (宮川大輔)
> [e-mail]
>



-- 
Daisuke Miyakawa (宮川大輔)
[e-mail]