An outlier problem with Apple Contacts

TidBITS Talk
1

I’ve just had a frustrating time trying to order a package in France. The story has a happy ending but really?

In the shipping section of the order they requested the mobile number at the delivery address. I entered it. It failed verification. Remembering that mobile numbers in France differ if you’re calling from outside the country or inside (no, it’s not just adding the country code) I looked up the differences. Nope, I had it right. Tried again with slight variations. Nope. Gave up. Sent a note to the vendor.

The next morning they replied and asked me to enter the address and phone directly in the order instead of the address book. Nope.

What was I doing? Was I transposing things without realizing it? Was I including a return when copying the number from Contacts? Nope. Then I tried a couple online number verification services. Failed them, too.

I messaged my friend (at the number :blush: ) and asked her to text me her mobile number exactly as she would give it to a French person. Copied it from the message and, you guessed it, it worked. But it looked exactly the same! What on earth?

So, I fired up Python in the terminal ready to execute “my Number”==“herNumber”. Didn’t even have to press return. When myNumber was pasted-in the Terminal escaped the two invisible, zero-width characters at the beginning and end of the mobile number: U+202D myNumber U+202C.

Mac Contacts appears to enclose all phone numbers, not just furrin ones, with those two characters when you copy them. It doesn’t do it when you export a VCF. And, I just tried once but it appears IOS doesn’t do this.

What are those two pesky characters? U+202D is a Left Right Override and U+202C is a Pop Directional Formatting. In other words it’s probably exempting the phone number from the surrounding text flow direction—an issue if the surrounding text is Hebrew or Arabic (or Japanese or Chinese :blush:).

They’re zero-width so you can’t see them when you select them and it is impossible to omit them by drag-selecting.

The reason, obviously, the copy failed verification is because multiple website developers aren’t filtering their inputs. Well, they do, sorta, by asking you to omit various and sundry characters yourself rather than writing a straight-forward regex. :blush:

The moral of the story is that when things fail that look exactly the same, key it in manually (Why do we use these computer-things again?).

Edit: This is with macOS Ventura 13.0.1 and the behavior occurs when you copy a number directly from a contacts card.

2 Likes
2

Now I know why, when I was cutting and pasting a friend’s number into a form, it added some weird formatting and seemed to truncate the number until I typed it in by hand.

3

I’ve seen the same thing when copy/pasting some Terminal output to other apps (including the TidBiTS Talk editor). For example, the output from diskutil list:

> diskutil list
...
/dev/disk5 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +100.0 MB   disk5
                                 Physical Store disk4s1
   1:                APFS Volume <U+2068>My Disk<U+2069>                 24.6 KB    disk5s1

The above text includes hidden characters that don’t show up in the editor or the preview panel, but do show up when I submit the message (as you can see above).

The U+2068 and U+2069 characters are First Strong Isolate and Pop Directional Isolate. These characters set-off a block of text such that the direction (left-to-right or right-to-left) of that text should be computed as if it was a separate paragraph, isolated from the directionality of the surrounding text.

This is how, for example, it can render a Hebrew volume name:

> diskutil list
...
/dev/disk5 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +100.0 MB   disk5
                                 Physical Store disk4s1
   1:                APFS Volume <U+2068>דשק שלי<U+2069>                 24.6 KB    disk5s1

But without those characters, it would get the direction wrong. The Hebrew text is rendered correctly (because they are strong characters) but the following whitespace and numbers (which are neutral and weak characters, respectively, and therefore determine their direction from the most recent strong character) end up being processed in the wrong direction until the next strong character (the “K” in “KB”). The result is that the volume name ends up right-aligned and its size ends up to the left of it:

> diskutil list
...
/dev/disk5 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +100.0 MB   disk5
                                 Physical Store disk4s1
   1:                APFS Volume דשק שלי                  24.6 KB   disk5s1

(But I think Discourse shouldn’t be displaying those characters. It should just use them.)

See also:

1 Like
4

This is kind of freaky and could be something to share in TidBITS. Does this happen with all phone numbers that you copy from Contacts, or just this one and others somehow like it? How could I reproduce the problem here?

@tom3, have you heard of things like this happening due to invisible Unicode characters?

1 Like
5

I was filling out a recommendation form for a colleague a few weeks ago and could not figure out why the phone numbers would not paste into an online form. Other people’s numbers I was referencing in the same form came out fine. They all have the same country code (USA) but his phone number would have parentheses in the wrong spot and cut off 2 digits short. Only by completely deleting the field and typing it in by hand did I notice that that worked. It had to do with the input parsing of that particular field. I would assume an operation would strip everything but the digits and then format them to the correct format based on the number of digits, but this tried to work with all (even invisible) inputs. I didn’t know why it happened until the OP brought it up.

1 Like
6

Yes, it appears to happen with all phone numbers whether US or international.

It doesn’t occur with addresses or emails.

Reproduction is easy: just drag-select a number, copy it, and paste it into Terminal.

The big word processors should handle these codes easily (cough), it’s pasting them into web fields where the developers haven’t written a good input filter that they become a problem.

Dave

7

Got it, and I can reproduce easily now. Thanks!

I think there’s an article here. Most apps will do the input filtering properly, but clearly it’s not universal. For what it’s worth, copying phone numbers out of Cardhop, which is what I use for contacts, does not suffer from this problem.

8

Well, I think the difference lies in the fact that Apple supports well-past a hundred languages and Cardhop supports six explicitly and probably many others simply by using Unicode.

It’s been awhile since I was swimming daily in Unicode but the one thing I remember is that there are a surprising number of “hidden” punctuation and typesetting codes that handle the languages beyond English.Here, for example, is data on one of the characters I found U+202C: https://util.unicode.org/UnicodeJsps/character.jsp?a=202C

(Gasp.)

So, I think this may be one of those damned if you do; damned if you don’t cases. The bounding characters do protect the numbers when plunked into non-English text flows and for all we know millions of people may appreciate that even if they have no idea how it works. Equally, there are large numbers of people who have been deeply confused when that plain 'ol phone number is rejected when they’re registering for class. . . . :slight_smile:

The problem could be Apple’s to fix. Check the current OS language and only insert the characters when necessary (people who regularly use text in multiple languages be damned). Or, it may require a world-wide effort to persuade every web developer to actually use robust filters on their forms. :face_with_monocle:

Dave