String Encoding Verständnisproblem

[SuperPCFan]

Ich benutze in einer Java App die BlueCove Bibliothek um einen Bluetooth HID Dienst zu erstellen. Dabei habe ich das Problem, dass das Bluetooth Attribut "ClassDescriptorData" im Attribut "HIDDescriptorList" nicht korrekt von der Bibliothek interpretiert wird.

Die Hid Spec auf Seite 87 sagt dazu:

The second element, called ClassDescriptorData, is a byte array that contains the descriptor identified by the first element. Descriptors are 8-bit unsigned arrays (Data Element Type = Text String (4), Data Element Size = array (5, 6, or 7)).

Ich soll also einen String bereitstellen, der aus unsigned Bytes bestehen soll.

Zum einfachen Testen habe das erstmal mit konstanten Dateninhalt in verschiedenen Zahlenbereichen umgesetzt (der Dateninhalt des Descriptors ist nicht "gültig", würde der Bluetooth Stack sagen wenn sich ein Client darauf verbindet)

byte[] test = new byte[]{(byte)0x01,(byte)0x05,(byte)0x08,(byte)0x7f,(byte)0x80,(byte)0x81, (byte)0xc0,(byte)0xa5};
btHIDDescriptor.addElement(new DataElement(DataElement.STRING, new String(test, StandardCharsets.ISO_8859_1)));

Gemäß der BlueCove Beschreibung der Datentypen füge ich ein String Element hinzu, wobei die Bytes gemäß dem "ISO_8859_1" Encoding als einzelne Bytes enthalten sein sollten.

Das Ergebnis wenn ich das Attribut "HIDDescriptorList" des so konfigurierten/erstellten Bluetooth Service von der sddb auf meinen RPi4 mit Raspbian GNU/Linux 10 (buster) in XML zurücklese ist:

<attribute id="0x0206">
    <sequence>
        <sequence>
            <uint8 value="0x22" />
            <text encoding="hex" value="0105087fc280c281c380c2a5" />
        </sequence>
    </sequence>
</attribute>

Irgendwie erweitert das Encoding (das eigentlich nur ein Byte benutzen darf) alle negativen Byte-Werte um ein zweites vorangestelltes Byte?!

Warum passiert das? Gibt es ein anderes Encoding das wirklich nur ein Byte benutzt?
Liegt das vielleicht am XML export?

Oder habe ich die Spec missverstanden? Wenn ich die Bytes nicht als Byte sondern als Ascii Symbole (0-f) übergebe, fehlt im XML die Angabe "encoding="hex"". Das scheint mir aber auch falsch zu sein, weil in allen Beispielen für XML Descriptoren dieses Attribut immer "encoding="hex"" enthält.

 

[kneitzel]

Im Augenblick kann ich Dir nicht ganz folgen und ich fürchte, dass dies nicht das ist, was Du machen willst.

Du hast den Hin-Weg im Blick, d.h. Du willst jemand anderes ein String im ISO_8859_1 Format geben?

Wenn Du eine Java Schnittstelle hast und diese einen String entgegen nimmt, dann muss die Schnittstelle das intern richtig machen. Da das Gerät über Bluetooth die Bytes im ISO_8859_1 Format haben will, könnte die Schnittstelle aus Deinem String z.B. getBytes mit dem Charset ISO_8859_ aufrufen.

Das was Du da im Code gemacht hast, wäre der Rückweg: Du bekommst ein Byte-Array eines Textes im ISO_8859_1 codierung und machst daraus einen String.
Ein String wird aber immer gleich gespeichert, egal wie Du ihn erstellst. Und das ist ein UTF-16 Format. (String Beschreibung besagt z.B. "A String represents a string in the UTF-16 format")
Damit ist es erst einmal egal, wie Du den String erstellst.

Wenn Du den String weiter gibst, dann ist aber die Frage, wie Du dies machst. Da findet dann in der Regel das Standard Encoding Anwendung. Das kann von System zu System unterschiedlich sein.

Bein einer Schnittstelle würde ich erwarten, dass die das dann entsprechend darstellt.

Was dann bei Dir passiert ist, ist einfach: 0x80, 0x81 und so sind einfach las spezielle Control Sequenzen definiert. Daher kommt da vermutlich nicht das raus, was Du erwartet hast. Schau Dazu einfach einmal http://www.gymel.com/charsets/ISO8859-1.html an.

Edit: Das "nicht definiert" habe ich korrigiert. Es ist natürlich definiert, aber da stecken keine Zeichen sondern Control Anweisungen dahinter. 0x80 wäre z.B. ein "<control> (BREAK PERMITTED HERE)"

 

[SuperPCFan]

Ich bin immer unsicher wie weit ich ausholen muss damit das Problem verständlich wird, aber der Text auch kein Buch füllt.

Der Descriptor (die Informationsquelle) kommt später unter anderem z.b. aus einer Textdatei in der die Bytes immer aus zwei ASCII-zeichen (0-f) bestehen und durch Leerzeichen getrennt sind. (z.B. "01 05 08..."). Diese unterschiedlichen Quellen lese ich ein und standardisiere sie zu einem byte[]. Das ist nicht das Problem. Für meinen Versuch habe ich die Quelle (das byte[]) nur durch ein konstantes Array mit bestimmten markanten Werten ersetzt.

Die Bytes in dem Aarray können alle Werte annehmen, die mit einem Byte möglich sind (0-255).

Das Problem ist, dass nach meinem Verständnis der BlueCove Bibliothek (hier kann schon ein Denkfehler sein) der Element Konstruktor für das Attribut zwangsläufig einen String erwartet. char[] oder byte[] werden mit einer IllegalArgumentException abgelehnt.

Ich muss also der HID-Spec nach (auch hier kann ein Denkfehler sein) in einem String ein byte[] abbilden, ohne dass das Encoding irgendwas an der Anzahl oder dem Inhalt der Bytes verändert.

Bei allen Konstellationen für das Encoding beim Erstellen des Strings die ich bisher versucht habe, erhalte ich beim Zurücklesen des durch die Bibliothek erstellen Datensatzes immer diese "erweiterten" Strings.

Ich hoffe ich habe das verständlich erklärt.

 

[Barista]

Das PDF enthält die Specifikation auf Binär-Ebene, hat also mit Java nichts zu tun.

Wie ist den die Javadoc der Java-Methode btHIDDescriptor.addElement ?

 

[SuperPCFan]

Hier ist die Doku:
http://javadox.com/net.sf.bluecove/bluecove/2.1.0/javax/bluetooth/DataElement.html

Für mein Verständnis dürfte nur "String" in Frage kommen.

"Sequence" habe ich trotzdem auch getestet. Dabei werden die Bytes natürlich nicht verändert.
Dafür ist dann aber die Struktur falsch.

 

[SuperPCFan]

Mich wundert auch, dass ich in der ganzen Bluecove Bibliothek keine Methode gefunden habe, um einfach einen XML Descriptor zu laden.
Das scheint mir der eher übliche Weg bei anderen Bluetooth-Implementierungen zu sein, als sich die Attribute mühsam einzeln "zusammenbauen" zu müssen.

 

[Barista]

Hier ist die Doku:
http://javadox.com/net.sf.bluecove/bluecove/2.1.0/javax/bluetooth/DataElement.html

Für mein Verständnis dürfte nur "String" in Frage kommen.

Soll heissen, dass das aktuelle Datenelement den Typ String hat und der String im zweiten Parameter die Daten enthält.
Nun ist aber die Frage, wie ist dieser String encodet, denn wahrscheinlich ist es kein Java-16-Bit-Char-String.

 

[Barista]

<attribute id="0x0206"> <sequence> <sequence> <uint8 value="0x22" /> <text encoding="hex" value="0105087fc280c281c380c2a5" /> </sequence> </sequence>

Warum ist hier uint8 value="0x22", sollte das nicht 0x20 sein?

 

[Barista]

Was willst Du eigentlich in dem String codieren?

Dieser String-Datentyp eignet sich wahrscheinlich nur für ASCII-Daten, zum Beispiel "Mein tolles Bluetooth-Geraet"

Kein deutscher Umlaut möglich bzw. wie in ISO_8859_1 festgelegt.

 

[SuperPCFan]

Das steht auch auf Seite 87 der Hid Spec. Es gibt nur 0x22 oder 0x23 für den Type des Descriptors.
Damit ist aber nicht der Datentyp des Descriptors gemeint sondern der Typ des Descriptors als ganzes.

 

[SuperPCFan]

Ich bin nichtmal sicher ob "String" für dieses Attribut der richtige Datentyp ist.
Das ist nur der Typ mit dem der Aufbau des XML Report(beim Rücklesen) am dichtestens an die Beispiele aus dem Netz kommt (bis auf die zu vielen Bytes)

 

[SuperPCFan]

Was willst Du eigentlich in dem String codieren?

Der Descriptor (die Informationsquelle) kommt später unter anderem z.b. aus einer Textdatei in der die Bytes immer aus zwei ASCII-zeichen (0-f) bestehen und durch Leerzeichen getrennt sind. (z.B. "01 05 08..."). Diese unterschiedlichen Quellen lese ich ein und standardisiere sie zu einem byte[]. Das ist nicht das Problem. Für meinen Versuch habe ich die Quelle (das byte[]) nur durch ein konstantes Array mit bestimmten markanten Werten ersetzt.

Die Bytes in dem Aarray können alle Werte annehmen, die mit einem Byte möglich sind (0-255).

 

[Barista]

Ich bin nichtmal sicher ob "String" für dieses Attribut der richtige Datentyp ist.
Das ist nur der Typ mit dem der Aufbau des XML Report(beim Rücklesen) am dichtestens an die Beispiele aus dem Netz kommt (bis auf die zu vielen Bytes)

Du musst zum Beschreiben (Deskriptor) die Spezifikation ab Seite 82 abarbeiten, da steht nirgendwo der Datentyp String.

Dein hex-String enthält wahrscheinlich den Deskriptor in seiner binären Darstellung als Gesamtes.

 

[SuperPCFan]

Die ganzen Attribute die vor Seite 87 und auch danach gelistet sind, sind in meinem Programm auch enthalten. Die habe ich der Übersichtlichkeit halber nicht dargestellt. Diese Attribute werden auch beim Rücklesen korrekt im XML Report ausgegeben. Ich gehe also davon aus das dort kein Fehler besteht.

Mein Problem bezieht sich einzig auf das Attribut "0x0206" "HIDDescriptorList":

The second element, called ClassDescriptorData, is a byte array that contains the descriptor identified by the first element. Descriptors are 8-bit unsigned arrays (Data Element Type = Text String (4), Data Element Size = array (5, 6, or 7)).

Dort steht "String" mit unsigned byte "Array".

Ich finde nur keine Doku die nun zweifelsfrei beschreibt welcher Datentyp in der Bluecove Lib damit gemeint ist.

"Array" gibt es nicht.
"Sequence" führt zu einer falschen Struktur.
"String" ist der einzige Datentyp bei dem die XML Struktur zumindest so aussieht wie in den Projekten die man so im Netz findet:

Typ "text" , encoding "hex":

[CODE lang="xml" title="Mein XML"]<text encoding="hex" value="0105087fc280c281c380c2a5" />[/CODE]

https://github.com/AnesBenmerzoug/Bluetooth_HID/blob/master/sdp_record.xml / Zeile 92:

[CODE lang="xml" title="Beispiel XML"]<text encoding="hex" value="05010906A1018501A100050719E029E71500250175019508810295017508810195087508150025650507190029658100C0C005010902A10185020901A1000509190129031500250175019503810275059501810105010930093109381581257F750895038106C0C0"/>[/CODE]

 

[Barista]

<text encoding="hex" value="0105087fc280c281c380c2a5" />

Das ist wahrscheinlich die ClassDescriptorData (zweiter Teil der HIDDescriptorList).

Diese besteht wiederum aus mehreren

Descriptors are 8-bit unsigned arrays (Data Element Type = Text String (4), Data Element Size = array (5, 6, or 7)).

Die musst Du wahrscheinlich als String zusammenbauen.

Wenn dein String die ClassDescriptorData bereits als Hex-String (je zwei Chars 0..F) enthält, dann wandle eventuell jedes Hex-Char-Paar in ein Java-char um und hänge dies an einen StringBuilder, den Du dann in java.lang.String umwandelst.

 

[SuperPCFan]

Das ist genau der Punkt wo mir das Encoding in die Suppe spuckt.

Aus:

StringBuilder btHIDDescriptor_Data = new StringBuilder();
byte[] test = new byte[]{(byte)0x01,(byte)0x05,(byte)0x08,(byte)0x7f,(byte)0x80,(byte)0x81, (byte)0xc0,(byte)0xa5};
for (byte b : test){
    btHIDDescriptor_Data.append((char)b);
}
btHIDDescriptor.addElement(new DataElement(DataElement.STRING, btHIDDescriptor_Data.toString()));

Wird:

<text encoding="hex" value="0105087fefbe80efbe81efbf80efbea5" />

Die zusätzlichen Bytes unterscheiden sich, je nachdem welches Encoding ich auswähle. Aber selbst bei den Encodings die gemäß Spec nur aus einem Byte bestehen sollen (z.b. ISO-8859-1), werden bei negativen Byte Werten zusätzliche Bytes eingefügt.

 

[Barista]

[CODE lang="java" title="HexStringToString"]public class HexStringToString {

public static void main(String[] args)
{
final String hexStr = "0105087fefbe80efbe81efbf80efbea5";
System.out.println( hexStr );

final StringBuilder buff = new StringBuilder( hexStr.length() / 2 );

for ( int i = 0 ; i < hexStr.length() ; i += 2 )
{
buff.append(
(char) Integer.parseInt(
//str
hexStr.substring(
//beginIndex
i ,
//endIndex
i + 2 ) ,
//radix
16 ) );
}

final String binStr = buff.toString();
System.out.println( binStr );

final String backToHexStr =
convertToHexStr(
binStr );
System.out.println( backToHexStr );

if ( ! hexStr.toLowerCase().equals( backToHexStr.toLowerCase() ) )
{
throw new RuntimeException( "failed" );
}
System.out.println( "ok" );
}

private static String convertToHexStr(
final String binStr )
{
final StringBuilder buff = new StringBuilder( binStr.length() * 2 );

for ( final char binChar : binStr.toCharArray() )
{
buff.append(
padWithLeadingZerosToLength2(
Integer.toHexString( binChar ) ) );
}

return buff.toString();
}

private static String padWithLeadingZerosToLength2(
String str )
{
while ( str.length() < 2 )
{
str = "0" + str;
}

return str;
}

}
[/CODE]

 

[SuperPCFan]

Das Problem ist nicht die Umwandlung von Literals in Bytes.
Die Datenquelle liegt schon in Byte-Form vor.

Das Problem ist das String Encoding/Decoding was die Stringklasse intern durchführt.

Ich habe hier einen Testfall gebaut, der das verdeutlicht:

// Datenquelle kann beliebig viele Bytes mit Werten von 0-255 enthalten
byte[] inputData = new byte[]{(byte)0x01,(byte)0x05,(byte)0x08,(byte)0x7f,(byte)0x80,(byte)0x81, (byte)0xc0,(byte)0xa5};
       
// Die Bluecove lib erwartet die Bytes als String im U_Int8 format
String attributeData = new String(inputData, StandardCharsets.ISO_8859_1);
byte[] attributeRawBytes = attributeData.getBytes();

// Darstellung und Test
System.out.println("Quelle: " + Arrays.toString(inputData));
System.out.println("String für Bluecove als Bytes: " + Arrays.toString(attributeRawBytes));
if (Arrays.equals(inputData, attributeRawBytes)){
    System.out.println("Speicherabbild korrekt!");
} else {
    System.out.println("Encoding/Decoding hat die Daten verändert!");
}

 

[kneitzel]

Ich hatte es einmal versucht zu erklären: Der String Konstruktor wird alles umwandeln in UTF-16, denn das ist das Format, in dem intern Strings aufbewahrt werden. wobei das vollkommen egal ist, denn wichtig ist ja, was Du für Methoden aufrufst.

Und String::getBytes gibt den String im default character Set aus:

Encodes this String into a sequence of bytes using the platform's default charset, storing the result into a new byte array.

Daher auch meine klare Aussage: Wenn da eine Library einen String entgegen nimmt, dann muss die Library die bytes entsprechend kodieren.

Egal, wie Du den String erstellst: Du veränderst Da nichts an der Codierung! Dafür ist die Stelle verantwortlich, die den String entgegen nimmt.

Dein Test funktioniert übrigens, wenn Du das default charset auf ISO_8859_1 setzt.... Falls da (verkehrter Weise) immer das default Encoding auch von der Library verwendet wird, dann könnte es evtl. etwas bringen, das zu ändern, also Start mit Option -Dfile.encoding=ISO_8859_1 oder so.

 

[SuperPCFan]

Alleine das Roh Bytes als String erwartet werden, zeigt ja schon das die Lib an dieser Stelle etwas "komisch drauf" ist.
Es würde mich nicht wunden, wenn die Lib da unsauber arbeitet. Da ich die Lib aber nicht verändern kann, versuche ich das Problem außerhalb zu lösen.

Welche Möglichkeiten habe ich denn das Default CharSet zu setzen/vorzugeben?

Die Anwendung mit der Startoption zu starten dürfte wieder neue Probleme an den Stellen machen, an denen das Standard-Standard-Charset erwartet wird.

 

[kneitzel]

Also erst einmal erwartet die Java Library da ein String so wie ich Dich verstanden habe. Das eigentliche Interface muss genau beschreiben, was erwartet wird und das auf Byte Ebene. Denn das ist ja unabhängig von jeder Sprache.

Und bezüglich default Charset würde ich nichts vermuten. Generell sollte es egal sein. Eine Applikation, die da etwas bestimmtes erwartet und sonst nicht funktioniert wäre schlecht. Daher kann das ein Versuch wert sein. Und das ist ja kein exotisches Charset. Früher war sowas durchaus üblich.

Ansonsten steht es Dir frei, die doch die verwendeten Libraries im Code anzusehen. Nur eben ich kenne sie nicht und werde daher nicht viel mehr helfen können.

 

[SuperPCFan]

In der Klasse "DataElement.class" hatte ich schon geschaut. Dort steht nur auskommentierter Assemblercode.
Ich nehme mal an, dass es sich schon dieser Ebene um das Native Interface handelt.
Aber ich finde nirgendwo in der Lib die zugehörigen implementierungen, von denen ich etwas erfahren könnte.

public DataElement(int valueType, Object value) {
        // <editor-fold defaultstate="collapsed" desc="Compiled Code">
        /* 0: aload_0
         * 1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         * 4: aload_2
         * 5: ifnonnull     18
         * 8: new           #5                  // class java/lang/IllegalArgumentException
         * 11: dup
         * 12: ldc           #46                 // String value param is null
         * 14: invokespecial #13                 // Method java/lang/IllegalArgumentException."<init>":(Ljava/lang/String;)V
         * 17: athrow
         * 18: iload_1
         * 19: lookupswitch  { // 6
         * 11: 110
         * 12: 140
         * 20: 140
         * 24: 93
         * 32: 76
         * 64: 76
         * default: 170
         * }
         * 76: aload_2
         * 77: instanceof    #47                 // class java/lang/String
         * 80: ifne          205
         * 83: new           #5                  // class java/lang/IllegalArgumentException
         * 86: dup
         * 87: ldc           #48                 // String value param should be String
         * 89: invokespecial #13                 // Method java/lang/IllegalArgumentException."<init>":(Ljava/lang/String;)V
         * 92: athrow
         * 93: aload_2
         * 94: instanceof    #49                 // class javax/bluetooth/UUID
         * 97: ifne          205
         * 100: new           #5                  // class java/lang/IllegalArgumentException
         * 103: dup
         * 104: ldc           #50                 // String value param should be UUID
         * 106: invokespecial #13                 // Method java/lang/IllegalArgumentException."<init>":(Ljava/lang/String;)V
         * 109: athrow
         * 110: aload_2
         * 111: instanceof    #51                 // class "[B"
         * 114: ifeq          130
         * 117: aload_2
         * 118: checkcast     #51                 // class "[B"
         * 121: checkcast     #51                 // class "[B"
         * 124: arraylength
         * 125: bipush        8
         * 127: if_icmpeq     205
         * 130: new           #5                  // class java/lang/IllegalArgumentException
         * 133: dup
         * 134: ldc           #52                 // String value param should be byte[8]
         * 136: invokespecial #13                 // Method java/lang/IllegalArgumentException."<init>":(Ljava/lang/String;)V
         * 139: athrow
         * 140: aload_2
         * 141: instanceof    #51                 // class "[B"
         * 144: ifeq          160
         * 147: aload_2
         * 148: checkcast     #51                 // class "[B"
         * 151: checkcast     #51                 // class "[B"
         * 154: arraylength
         * 155: bipush        16
         * 157: if_icmpeq     205
         * 160: new           #5                  // class java/lang/IllegalArgumentException
         * 163: dup
         * 164: ldc           #53                 // String value param should be byte[16]
         * 166: invokespecial #13                 // Method java/lang/IllegalArgumentException."<init>":(Ljava/lang/String;)V
         * 169: athrow
         * 170: new           #5                  // class java/lang/IllegalArgumentException
         * 173: dup
         * 174: new           #6                  // class java/lang/StringBuffer
         * 177: dup
         * 178: invokespecial #7                  // Method java/lang/StringBuffer."<init>":()V
         * 181: ldc           #42                 // String type
         * 183: invokevirtual #9                  // Method java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;
         * 186: iload_1
         * 187: invokestatic  #10                 // Method typeToString:(I)Ljava/lang/String;
         * 190: invokevirtual #9                  // Method java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;
         * 193: ldc           #54                 // String  can\'t be represented by Object
         * 195: invokevirtual #9                  // Method java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;
         * 198: invokevirtual #12                 // Method java/lang/StringBuffer.toString:()Ljava/lang/String;
         * 201: invokespecial #13                 // Method java/lang/IllegalArgumentException."<init>":(Ljava/lang/String;)V
         * 204: athrow
         * 205: aload_0
         * 206: aload_2
         * 207: putfield      #2                  // Field value:Ljava/lang/Object;
         * 210: aload_0
         * 211: iload_1
         * 212: putfield      #14                 // Field valueType:I
         * 215: return
         *  */
        // </editor-fold>
    }

 

[SuperPCFan]

Alle Einstellungen die ich im Hinblick auf Encoding versuche (Lib-extern oder Lib-intern) und auch alle Varianten beim Inhalt des String (Text, Literals, chars, roh-Bytes, mit padding oder ohne) führen immer zu einer Fehlinterpretation. Die Lib fügt grundsätzlich immer noch Bytes ein.

Danke euch für die Diskussion. Ich habe gerade ein Issue beim Ersteller der Lib eröffnet. Vielleicht kann mir dort weitergeholfen werden.