Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] TR : [Grouper API] problem with special characters in displayName

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] TR : [Grouper API] problem with special characters in displayName

Chronological Thread 
  • From: Dominique Petitpierre <>
  • To: Gagné Sébastien <>
  • Cc: Chris Hyzer <>, Nicolas Forney <>, <>
  • Subject: Re: [grouper-users] TR : [Grouper API] problem with special characters in displayName
  • Date: Wed, 19 Jun 2013 00:25:37 +0200
  • Authentication-results:; dkim=neutral (message not signed) header.i=none
  • Organization: University of Geneva


On 06/17/2013 03:02 PM, Gagné Sébastien wrote:
The source of the problem is that the grouper DB field is 255 BYTES, not
255 CHARS, accent characters use 2 Bytes, hence the larger value (some
other like the apostrophe take 3)

This would be true if one uses a database encoding like UTF-8. In
Nicolas' case, the database for Grouper is Oracle DB, with a database
encoding ISO8859-1 (WE8ISO8859P1 in Oracle speak), which stores one
byte for every character.

We can see it with the following SQL request for a display_extension
of exactly one character: "é" (e-acute).

SELECT dump(display_extension,1016)
FROM grouper_groups
WHERE display_extension='é';

Typ=1 Len=1 CharacterSet=WE8ISO8859P1: e9

This result shows that the length of the stored value is 1 byte and the
character is encoded with the byte e9 (hexadecimal) which is the code
of e-acute in the ISO8859-1 character set (cf. "man iso_8859-1" on

So the problem that Nicolas was reporting is not caused by the
database encoding. (i.e. display_extension has a data_type
VARCHAR2(255 BYTE) and will accept up to 255 iso_8859-1 encoded
The problem is "up stream", probably in the grouper-ws application
that he was using.

Best regards,
Mr Dominique Petitpierre, user=Dominique.Petitpierre
IT Division, University of Geneva, Switzerland

Archive powered by MHonArc 2.6.16.

Top of Page